People lands on all users, and My week's row link is the task

[os-warren]

Closes#118

Two metadata fixes, both re-measured in a browser on this branch rather than reasoned about. All four gates green at 8d1711d.

1. nav_people → viewName: 'all_users'

The entry named sys_user with no viewName, so the Console opened that object's default view — me, "My Profile", filtered id == {current_user_id} with pageSize: 1. A manager who followed the Duty-health dashboard to People in order to look at other people got exactly one row: themselves.

all_users is the platform's own unfiltered lens (@objectstack/platform-objects, sys_user.listViews.all_users) — named, not redeclared, because the views of a runtime-provided object are not ours to author and a local copy would drift.

Measured on the running demo, signed in as the dev admin:

what	rows
/sys_user (the default view nav used to open)	1
/sys_user/view/all_users (what the nav entry points at now)	13

The nav entry's href is now /_console/apps/ai.objectstack.duly/sys_user/view/all_users, breadcrumb User / All Users, first row Ana Ferreira · ana.ferreira@ardenline.example.

One correction to the card: all_users renders Name / Email / Phone Number / Email Verified / Identity Source / Two-Factor Enabled / Created At — not "Name / Email / Business unit". The column set is the platform's, so it is not something this PR chooses; the row count, which is the defect, is exactly the 13 the card predicted.

2. my_week leads with subject; attachments dropped

The first column is not merely the leftmost one — two renderers read it as the row's identity, so status leading made the state of a thing stand in for the thing. Both halves confirmed fixed:

• Desktop grid. Headers are now # · Task · Status · Source · Due · Latest progress · Actions, and the row's a[href*="/record/"] is in the Task cell with the subject as its text — e.g. Emissions return — Northgate → /duly_task/record/rWCkoZEut6a7ngu2. Open is plain text beside it, no longer the only clickable thing on the row.
• 390px cards. Cards are now titled Emissions return — Northgate, Waste transfer log review — Northgate, Keep up with regulator bulletins — not open / in_progress.

attachments is dropped from this lens only: it was a dash on every row of the busiest screen in the product. The field is untouched, the shared columns array still carries it on the other four grids, and the upload #108 built is still on the record page's "Progress and attachments" group.

late, stalled and by_unit already led with subject and are unchanged.

Guards

Both walked rather than listed by name, so a lens added later is covered on the day it lands.

• test/views.test.ts — the my_week order pin is updated, and a new test asserts the rule that outlives the exact column list: everyduly_task grid leads with subject. The defect was one lens disagreeing with the other four, which a per-view pin would not have said. It reaches the container default (list) too, which byName cannot address.
• test/member-page.test.ts — pins nav_people.viewName, so dropping it is a red test rather than a silently-refiltered screen.
• test/metadata-bindings.test.ts — this is the app's first nav reference across the platform-object boundary, and that file pins boundaries to an exact zero, by design, to "fail the day one is authored". It did. Widening the pin would have been the wrong answer: a platform object's fields genuinely cannot be judged from @objectstack/spec, but its views can, because @objectstack/platform-objects is a devDependency that ships them on disk. So the walk now resolvessys_user.all_users for real and boundaries stays zero — which means a typo'd platform view name is now a finding instead of an unjudgeable gap. That is the same silent-fallback defect this PR fixes, so the guard covers the surface where it was just measured. Three self-tests cover the branch's three outcomes (resolves / fires on a typo / still records a boundary when no map is supplied).

Reverse-verification

Each new guard was mutated on the committed tree and observed failing, then restored (tree confirmed clean afterwards):

mutation	result
drop viewName from nav_people	member-page red — expected undefined to be 'all_users'
put status back first in my_week	views red on both the order pin and the new leading-column guard
viewName: 'all_userz'	metadata-bindings red — "the platform object sys_user declares no list view named all_userz … Declared: all_users, banned, me, two_factor, unverified"

That third message lists the five real SysUser.listViews names, which is the evidence the walk reads the platform package rather than a hand-copied list.

Gates

Run on the final tree at 8d1711d:

pnpm validate ✓ Validation passed (445ms)
pnpm typecheck exit 0
pnpm test Test Files 32 passed (32) · Tests 837 passed (837)
pnpm build ✓ Build complete

validate prints the one expected hierarchy-security capability warning, which AGENTS.md §7 says is this repo's normal state and must not be silenced.

Not in this card

Bulk confirm / approve / return on the duty views, board card tweaks, and dashboard number formatting are all untouched, as the issue directs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

---

Generated by Claude Code

[os-warren]

Closes#118

Two metadata fixes, both re-measured in a browser on this branch rather than reasoned about. All four gates green at 8d1711d.

1. nav_people → viewName: 'all_users'

The entry named sys_user with no viewName, so the Console opened that object's default view — me, "My Profile", filtered id == {current_user_id} with pageSize: 1. A manager who followed the Duty-health dashboard to People in order to look at other people got exactly one row: themselves.

all_users is the platform's own unfiltered lens (@objectstack/platform-objects, sys_user.listViews.all_users) — named, not redeclared, because the views of a runtime-provided object are not ours to author and a local copy would drift.

Measured on the running demo, signed in as the dev admin:

what	rows
/sys_user (the default view nav used to open)	1
/sys_user/view/all_users (what the nav entry points at now)	13

The nav entry's href is now /_console/apps/ai.objectstack.duly/sys_user/view/all_users, breadcrumb User / All Users, first row Ana Ferreira · ana.ferreira@ardenline.example.

One correction to the card: all_users renders Name / Email / Phone Number / Email Verified / Identity Source / Two-Factor Enabled / Created At — not "Name / Email / Business unit". The column set is the platform's, so it is not something this PR chooses; the row count, which is the defect, is exactly the 13 the card predicted.

2. my_week leads with subject; attachments dropped

The first column is not merely the leftmost one — two renderers read it as the row's identity, so status leading made the state of a thing stand in for the thing. Both halves confirmed fixed:

• Desktop grid. Headers are now # · Task · Status · Source · Due · Latest progress · Actions, and the row's a[href*="/record/"] is in the Task cell with the subject as its text — e.g. Emissions return — Northgate → /duly_task/record/rWCkoZEut6a7ngu2. Open is plain text beside it, no longer the only clickable thing on the row.
• 390px cards. Cards are now titled Emissions return — Northgate, Waste transfer log review — Northgate, Keep up with regulator bulletins — not open / in_progress.

attachments is dropped from this lens only: it was a dash on every row of the busiest screen in the product. The field is untouched, the shared columns array still carries it on the other four grids, and the upload #108 built is still on the record page's "Progress and attachments" group.

late, stalled and by_unit already led with subject and are unchanged.

Guards

Both walked rather than listed by name, so a lens added later is covered on the day it lands.

• test/views.test.ts — the my_week order pin is updated, and a new test asserts the rule that outlives the exact column list: everyduly_task grid leads with subject. The defect was one lens disagreeing with the other four, which a per-view pin would not have said. It reaches the container default (list) too, which byName cannot address.
• test/member-page.test.ts — pins nav_people.viewName, so dropping it is a red test rather than a silently-refiltered screen.
• test/metadata-bindings.test.ts — this is the app's first nav reference across the platform-object boundary, and that file pins boundaries to an exact zero, by design, to "fail the day one is authored". It did. Widening the pin would have been the wrong answer: a platform object's fields genuinely cannot be judged from @objectstack/spec, but its views can, because @objectstack/platform-objects is a devDependency that ships them on disk. So the walk now resolvessys_user.all_users for real and boundaries stays zero — which means a typo'd platform view name is now a finding instead of an unjudgeable gap. That is the same silent-fallback defect this PR fixes, so the guard covers the surface where it was just measured. Three self-tests cover the branch's three outcomes (resolves / fires on a typo / still records a boundary when no map is supplied).

Reverse-verification

Each new guard was mutated on the committed tree and observed failing, then restored (tree confirmed clean afterwards):

mutation	result
drop viewName from nav_people	member-page red — expected undefined to be 'all_users'
put status back first in my_week	views red on both the order pin and the new leading-column guard
viewName: 'all_userz'	metadata-bindings red — "the platform object sys_user declares no list view named all_userz … Declared: all_users, banned, me, two_factor, unverified"

That third message lists the five real SysUser.listViews names, which is the evidence the walk reads the platform package rather than a hand-copied list.

Gates

Run on the final tree at 8d1711d:

pnpm validate ✓ Validation passed (445ms)
pnpm typecheck exit 0
pnpm test Test Files 32 passed (32) · Tests 837 passed (837)
pnpm build ✓ Build complete

validate prints the one expected hierarchy-security capability warning, which AGENTS.md §7 says is this repo's normal state and must not be silenced.

Not in this card

Bulk confirm / approve / return on the duty views, board card tweaks, and dashboard number formatting are all untouched, as the issue directs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

---

Generated by Claude Code

[os-warren]

Closes#118

Two metadata fixes, both re-measured in a browser on this branch rather than reasoned about. All four gates green at 8d1711d.

1. nav_people → viewName: 'all_users'

The entry named sys_user with no viewName, so the Console opened that object's default view — me, "My Profile", filtered id == {current_user_id} with pageSize: 1. A manager who followed the Duty-health dashboard to People in order to look at other people got exactly one row: themselves.

all_users is the platform's own unfiltered lens (@objectstack/platform-objects, sys_user.listViews.all_users) — named, not redeclared, because the views of a runtime-provided object are not ours to author and a local copy would drift.

Measured on the running demo, signed in as the dev admin:

what	rows
/sys_user (the default view nav used to open)	1
/sys_user/view/all_users (what the nav entry points at now)	13

The nav entry's href is now /_console/apps/ai.objectstack.duly/sys_user/view/all_users, breadcrumb User / All Users, first row Ana Ferreira · ana.ferreira@ardenline.example.

One correction to the card: all_users renders Name / Email / Phone Number / Email Verified / Identity Source / Two-Factor Enabled / Created At — not "Name / Email / Business unit". The column set is the platform's, so it is not something this PR chooses; the row count, which is the defect, is exactly the 13 the card predicted.

2. my_week leads with subject; attachments dropped

The first column is not merely the leftmost one — two renderers read it as the row's identity, so status leading made the state of a thing stand in for the thing. Both halves confirmed fixed:

• Desktop grid. Headers are now # · Task · Status · Source · Due · Latest progress · Actions, and the row's a[href*="/record/"] is in the Task cell with the subject as its text — e.g. Emissions return — Northgate → /duly_task/record/rWCkoZEut6a7ngu2. Open is plain text beside it, no longer the only clickable thing on the row.
• 390px cards. Cards are now titled Emissions return — Northgate, Waste transfer log review — Northgate, Keep up with regulator bulletins — not open / in_progress.

attachments is dropped from this lens only: it was a dash on every row of the busiest screen in the product. The field is untouched, the shared columns array still carries it on the other four grids, and the upload #108 built is still on the record page's "Progress and attachments" group.

late, stalled and by_unit already led with subject and are unchanged.

Guards

Both walked rather than listed by name, so a lens added later is covered on the day it lands.

• test/views.test.ts — the my_week order pin is updated, and a new test asserts the rule that outlives the exact column list: everyduly_task grid leads with subject. The defect was one lens disagreeing with the other four, which a per-view pin would not have said. It reaches the container default (list) too, which byName cannot address.
• test/member-page.test.ts — pins nav_people.viewName, so dropping it is a red test rather than a silently-refiltered screen.
• test/metadata-bindings.test.ts — this is the app's first nav reference across the platform-object boundary, and that file pins boundaries to an exact zero, by design, to "fail the day one is authored". It did. Widening the pin would have been the wrong answer: a platform object's fields genuinely cannot be judged from @objectstack/spec, but its views can, because @objectstack/platform-objects is a devDependency that ships them on disk. So the walk now resolvessys_user.all_users for real and boundaries stays zero — which means a typo'd platform view name is now a finding instead of an unjudgeable gap. That is the same silent-fallback defect this PR fixes, so the guard covers the surface where it was just measured. Three self-tests cover the branch's three outcomes (resolves / fires on a typo / still records a boundary when no map is supplied).

Reverse-verification

Each new guard was mutated on the committed tree and observed failing, then restored (tree confirmed clean afterwards):

mutation	result
drop viewName from nav_people	member-page red — expected undefined to be 'all_users'
put status back first in my_week	views red on both the order pin and the new leading-column guard
viewName: 'all_userz'	metadata-bindings red — "the platform object sys_user declares no list view named all_userz … Declared: all_users, banned, me, two_factor, unverified"

That third message lists the five real SysUser.listViews names, which is the evidence the walk reads the platform package rather than a hand-copied list.

Gates

Run on the final tree at 8d1711d:

pnpm validate ✓ Validation passed (445ms)
pnpm typecheck exit 0
pnpm test Test Files 32 passed (32) · Tests 837 passed (837)
pnpm build ✓ Build complete

validate prints the one expected hierarchy-security capability warning, which AGENTS.md §7 says is this repo's normal state and must not be silenced.

Not in this card

Bulk confirm / approve / return on the duty views, board card tweaks, and dashboard number formatting are all untouched, as the issue directs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

---

Generated by Claude Code

[os-warren]

Closes#118

Two metadata fixes, both re-measured in a browser on this branch rather than reasoned about. All four gates green at 8d1711d.

1. nav_people → viewName: 'all_users'

The entry named sys_user with no viewName, so the Console opened that object's default view — me, "My Profile", filtered id == {current_user_id} with pageSize: 1. A manager who followed the Duty-health dashboard to People in order to look at other people got exactly one row: themselves.

all_users is the platform's own unfiltered lens (@objectstack/platform-objects, sys_user.listViews.all_users) — named, not redeclared, because the views of a runtime-provided object are not ours to author and a local copy would drift.

Measured on the running demo, signed in as the dev admin:

what	rows
/sys_user (the default view nav used to open)	1
/sys_user/view/all_users (what the nav entry points at now)	13

The nav entry's href is now /_console/apps/ai.objectstack.duly/sys_user/view/all_users, breadcrumb User / All Users, first row Ana Ferreira · ana.ferreira@ardenline.example.

One correction to the card: all_users renders Name / Email / Phone Number / Email Verified / Identity Source / Two-Factor Enabled / Created At — not "Name / Email / Business unit". The column set is the platform's, so it is not something this PR chooses; the row count, which is the defect, is exactly the 13 the card predicted.

2. my_week leads with subject; attachments dropped

The first column is not merely the leftmost one — two renderers read it as the row's identity, so status leading made the state of a thing stand in for the thing. Both halves confirmed fixed:

• Desktop grid. Headers are now # · Task · Status · Source · Due · Latest progress · Actions, and the row's a[href*="/record/"] is in the Task cell with the subject as its text — e.g. Emissions return — Northgate → /duly_task/record/rWCkoZEut6a7ngu2. Open is plain text beside it, no longer the only clickable thing on the row.
• 390px cards. Cards are now titled Emissions return — Northgate, Waste transfer log review — Northgate, Keep up with regulator bulletins — not open / in_progress.

attachments is dropped from this lens only: it was a dash on every row of the busiest screen in the product. The field is untouched, the shared columns array still carries it on the other four grids, and the upload #108 built is still on the record page's "Progress and attachments" group.

late, stalled and by_unit already led with subject and are unchanged.

Guards

Both walked rather than listed by name, so a lens added later is covered on the day it lands.

• test/views.test.ts — the my_week order pin is updated, and a new test asserts the rule that outlives the exact column list: everyduly_task grid leads with subject. The defect was one lens disagreeing with the other four, which a per-view pin would not have said. It reaches the container default (list) too, which byName cannot address.
• test/member-page.test.ts — pins nav_people.viewName, so dropping it is a red test rather than a silently-refiltered screen.
• test/metadata-bindings.test.ts — this is the app's first nav reference across the platform-object boundary, and that file pins boundaries to an exact zero, by design, to "fail the day one is authored". It did. Widening the pin would have been the wrong answer: a platform object's fields genuinely cannot be judged from @objectstack/spec, but its views can, because @objectstack/platform-objects is a devDependency that ships them on disk. So the walk now resolvessys_user.all_users for real and boundaries stays zero — which means a typo'd platform view name is now a finding instead of an unjudgeable gap. That is the same silent-fallback defect this PR fixes, so the guard covers the surface where it was just measured. Three self-tests cover the branch's three outcomes (resolves / fires on a typo / still records a boundary when no map is supplied).

Reverse-verification

Each new guard was mutated on the committed tree and observed failing, then restored (tree confirmed clean afterwards):

mutation	result
drop viewName from nav_people	member-page red — expected undefined to be 'all_users'
put status back first in my_week	views red on both the order pin and the new leading-column guard
viewName: 'all_userz'	metadata-bindings red — "the platform object sys_user declares no list view named all_userz … Declared: all_users, banned, me, two_factor, unverified"

That third message lists the five real SysUser.listViews names, which is the evidence the walk reads the platform package rather than a hand-copied list.

Gates

Run on the final tree at 8d1711d:

pnpm validate ✓ Validation passed (445ms)
pnpm typecheck exit 0
pnpm test Test Files 32 passed (32) · Tests 837 passed (837)
pnpm build ✓ Build complete

validate prints the one expected hierarchy-security capability warning, which AGENTS.md §7 says is this repo's normal state and must not be silenced.

Not in this card

Bulk confirm / approve / return on the duty views, board card tweaks, and dashboard number formatting are all untouched, as the issue directs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

---

Generated by Claude Code

[os-warren]

Closes#118

Two metadata fixes, both re-measured in a browser on this branch rather than reasoned about. All four gates green at 8d1711d.

1. nav_people → viewName: 'all_users'

The entry named sys_user with no viewName, so the Console opened that object's default view — me, "My Profile", filtered id == {current_user_id} with pageSize: 1. A manager who followed the Duty-health dashboard to People in order to look at other people got exactly one row: themselves.

all_users is the platform's own unfiltered lens (@objectstack/platform-objects, sys_user.listViews.all_users) — named, not redeclared, because the views of a runtime-provided object are not ours to author and a local copy would drift.

Measured on the running demo, signed in as the dev admin:

what	rows
/sys_user (the default view nav used to open)	1
/sys_user/view/all_users (what the nav entry points at now)	13

The nav entry's href is now /_console/apps/ai.objectstack.duly/sys_user/view/all_users, breadcrumb User / All Users, first row Ana Ferreira · ana.ferreira@ardenline.example.

One correction to the card: all_users renders Name / Email / Phone Number / Email Verified / Identity Source / Two-Factor Enabled / Created At — not "Name / Email / Business unit". The column set is the platform's, so it is not something this PR chooses; the row count, which is the defect, is exactly the 13 the card predicted.

2. my_week leads with subject; attachments dropped

The first column is not merely the leftmost one — two renderers read it as the row's identity, so status leading made the state of a thing stand in for the thing. Both halves confirmed fixed:

• Desktop grid. Headers are now # · Task · Status · Source · Due · Latest progress · Actions, and the row's a[href*="/record/"] is in the Task cell with the subject as its text — e.g. Emissions return — Northgate → /duly_task/record/rWCkoZEut6a7ngu2. Open is plain text beside it, no longer the only clickable thing on the row.
• 390px cards. Cards are now titled Emissions return — Northgate, Waste transfer log review — Northgate, Keep up with regulator bulletins — not open / in_progress.

attachments is dropped from this lens only: it was a dash on every row of the busiest screen in the product. The field is untouched, the shared columns array still carries it on the other four grids, and the upload #108 built is still on the record page's "Progress and attachments" group.

late, stalled and by_unit already led with subject and are unchanged.

Guards

Both walked rather than listed by name, so a lens added later is covered on the day it lands.

• test/views.test.ts — the my_week order pin is updated, and a new test asserts the rule that outlives the exact column list: everyduly_task grid leads with subject. The defect was one lens disagreeing with the other four, which a per-view pin would not have said. It reaches the container default (list) too, which byName cannot address.
• test/member-page.test.ts — pins nav_people.viewName, so dropping it is a red test rather than a silently-refiltered screen.
• test/metadata-bindings.test.ts — this is the app's first nav reference across the platform-object boundary, and that file pins boundaries to an exact zero, by design, to "fail the day one is authored". It did. Widening the pin would have been the wrong answer: a platform object's fields genuinely cannot be judged from @objectstack/spec, but its views can, because @objectstack/platform-objects is a devDependency that ships them on disk. So the walk now resolvessys_user.all_users for real and boundaries stays zero — which means a typo'd platform view name is now a finding instead of an unjudgeable gap. That is the same silent-fallback defect this PR fixes, so the guard covers the surface where it was just measured. Three self-tests cover the branch's three outcomes (resolves / fires on a typo / still records a boundary when no map is supplied).

Reverse-verification

Each new guard was mutated on the committed tree and observed failing, then restored (tree confirmed clean afterwards):

mutation	result
drop viewName from nav_people	member-page red — expected undefined to be 'all_users'
put status back first in my_week	views red on both the order pin and the new leading-column guard
viewName: 'all_userz'	metadata-bindings red — "the platform object sys_user declares no list view named all_userz … Declared: all_users, banned, me, two_factor, unverified"

That third message lists the five real SysUser.listViews names, which is the evidence the walk reads the platform package rather than a hand-copied list.

Gates

Run on the final tree at 8d1711d:

pnpm validate ✓ Validation passed (445ms)
pnpm typecheck exit 0
pnpm test Test Files 32 passed (32) · Tests 837 passed (837)
pnpm build ✓ Build complete

validate prints the one expected hierarchy-security capability warning, which AGENTS.md §7 says is this repo's normal state and must not be silenced.

Not in this card

Bulk confirm / approve / return on the duty views, board card tweaks, and dashboard number formatting are all untouched, as the issue directs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

---

Generated by Claude Code

[os-warren]

Closes#118

Two metadata fixes, both re-measured in a browser on this branch rather than reasoned about. All four gates green at 8d1711d.

1. nav_people → viewName: 'all_users'

The entry named sys_user with no viewName, so the Console opened that object's default view — me, "My Profile", filtered id == {current_user_id} with pageSize: 1. A manager who followed the Duty-health dashboard to People in order to look at other people got exactly one row: themselves.

all_users is the platform's own unfiltered lens (@objectstack/platform-objects, sys_user.listViews.all_users) — named, not redeclared, because the views of a runtime-provided object are not ours to author and a local copy would drift.

Measured on the running demo, signed in as the dev admin:

what	rows
/sys_user (the default view nav used to open)	1
/sys_user/view/all_users (what the nav entry points at now)	13

The nav entry's href is now /_console/apps/ai.objectstack.duly/sys_user/view/all_users, breadcrumb User / All Users, first row Ana Ferreira · ana.ferreira@ardenline.example.

One correction to the card: all_users renders Name / Email / Phone Number / Email Verified / Identity Source / Two-Factor Enabled / Created At — not "Name / Email / Business unit". The column set is the platform's, so it is not something this PR chooses; the row count, which is the defect, is exactly the 13 the card predicted.

2. my_week leads with subject; attachments dropped

The first column is not merely the leftmost one — two renderers read it as the row's identity, so status leading made the state of a thing stand in for the thing. Both halves confirmed fixed:

• Desktop grid. Headers are now # · Task · Status · Source · Due · Latest progress · Actions, and the row's a[href*="/record/"] is in the Task cell with the subject as its text — e.g. Emissions return — Northgate → /duly_task/record/rWCkoZEut6a7ngu2. Open is plain text beside it, no longer the only clickable thing on the row.
• 390px cards. Cards are now titled Emissions return — Northgate, Waste transfer log review — Northgate, Keep up with regulator bulletins — not open / in_progress.

attachments is dropped from this lens only: it was a dash on every row of the busiest screen in the product. The field is untouched, the shared columns array still carries it on the other four grids, and the upload #108 built is still on the record page's "Progress and attachments" group.

late, stalled and by_unit already led with subject and are unchanged.

Guards

Both walked rather than listed by name, so a lens added later is covered on the day it lands.

• test/views.test.ts — the my_week order pin is updated, and a new test asserts the rule that outlives the exact column list: everyduly_task grid leads with subject. The defect was one lens disagreeing with the other four, which a per-view pin would not have said. It reaches the container default (list) too, which byName cannot address.
• test/member-page.test.ts — pins nav_people.viewName, so dropping it is a red test rather than a silently-refiltered screen.
• test/metadata-bindings.test.ts — this is the app's first nav reference across the platform-object boundary, and that file pins boundaries to an exact zero, by design, to "fail the day one is authored". It did. Widening the pin would have been the wrong answer: a platform object's fields genuinely cannot be judged from @objectstack/spec, but its views can, because @objectstack/platform-objects is a devDependency that ships them on disk. So the walk now resolvessys_user.all_users for real and boundaries stays zero — which means a typo'd platform view name is now a finding instead of an unjudgeable gap. That is the same silent-fallback defect this PR fixes, so the guard covers the surface where it was just measured. Three self-tests cover the branch's three outcomes (resolves / fires on a typo / still records a boundary when no map is supplied).

Reverse-verification

Each new guard was mutated on the committed tree and observed failing, then restored (tree confirmed clean afterwards):

mutation	result
drop viewName from nav_people	member-page red — expected undefined to be 'all_users'
put status back first in my_week	views red on both the order pin and the new leading-column guard
viewName: 'all_userz'	metadata-bindings red — "the platform object sys_user declares no list view named all_userz … Declared: all_users, banned, me, two_factor, unverified"

That third message lists the five real SysUser.listViews names, which is the evidence the walk reads the platform package rather than a hand-copied list.

Gates

Run on the final tree at 8d1711d:

pnpm validate ✓ Validation passed (445ms)
pnpm typecheck exit 0
pnpm test Test Files 32 passed (32) · Tests 837 passed (837)
pnpm build ✓ Build complete

validate prints the one expected hierarchy-security capability warning, which AGENTS.md §7 says is this repo's normal state and must not be silenced.

Not in this card

Bulk confirm / approve / return on the duty views, board card tweaks, and dashboard number formatting are all untouched, as the issue directs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

---

Generated by Claude Code

[os-warren]

Closes#118

Two metadata fixes, both re-measured in a browser on this branch rather than reasoned about. All four gates green at 8d1711d.

1. nav_people → viewName: 'all_users'

The entry named sys_user with no viewName, so the Console opened that object's default view — me, "My Profile", filtered id == {current_user_id} with pageSize: 1. A manager who followed the Duty-health dashboard to People in order to look at other people got exactly one row: themselves.

all_users is the platform's own unfiltered lens (@objectstack/platform-objects, sys_user.listViews.all_users) — named, not redeclared, because the views of a runtime-provided object are not ours to author and a local copy would drift.

Measured on the running demo, signed in as the dev admin:

what	rows
/sys_user (the default view nav used to open)	1
/sys_user/view/all_users (what the nav entry points at now)	13

The nav entry's href is now /_console/apps/ai.objectstack.duly/sys_user/view/all_users, breadcrumb User / All Users, first row Ana Ferreira · ana.ferreira@ardenline.example.

One correction to the card: all_users renders Name / Email / Phone Number / Email Verified / Identity Source / Two-Factor Enabled / Created At — not "Name / Email / Business unit". The column set is the platform's, so it is not something this PR chooses; the row count, which is the defect, is exactly the 13 the card predicted.

2. my_week leads with subject; attachments dropped

The first column is not merely the leftmost one — two renderers read it as the row's identity, so status leading made the state of a thing stand in for the thing. Both halves confirmed fixed:

• Desktop grid. Headers are now # · Task · Status · Source · Due · Latest progress · Actions, and the row's a[href*="/record/"] is in the Task cell with the subject as its text — e.g. Emissions return — Northgate → /duly_task/record/rWCkoZEut6a7ngu2. Open is plain text beside it, no longer the only clickable thing on the row.
• 390px cards. Cards are now titled Emissions return — Northgate, Waste transfer log review — Northgate, Keep up with regulator bulletins — not open / in_progress.

attachments is dropped from this lens only: it was a dash on every row of the busiest screen in the product. The field is untouched, the shared columns array still carries it on the other four grids, and the upload #108 built is still on the record page's "Progress and attachments" group.

late, stalled and by_unit already led with subject and are unchanged.

Guards

Both walked rather than listed by name, so a lens added later is covered on the day it lands.

• test/views.test.ts — the my_week order pin is updated, and a new test asserts the rule that outlives the exact column list: everyduly_task grid leads with subject. The defect was one lens disagreeing with the other four, which a per-view pin would not have said. It reaches the container default (list) too, which byName cannot address.
• test/member-page.test.ts — pins nav_people.viewName, so dropping it is a red test rather than a silently-refiltered screen.
• test/metadata-bindings.test.ts — this is the app's first nav reference across the platform-object boundary, and that file pins boundaries to an exact zero, by design, to "fail the day one is authored". It did. Widening the pin would have been the wrong answer: a platform object's fields genuinely cannot be judged from @objectstack/spec, but its views can, because @objectstack/platform-objects is a devDependency that ships them on disk. So the walk now resolvessys_user.all_users for real and boundaries stays zero — which means a typo'd platform view name is now a finding instead of an unjudgeable gap. That is the same silent-fallback defect this PR fixes, so the guard covers the surface where it was just measured. Three self-tests cover the branch's three outcomes (resolves / fires on a typo / still records a boundary when no map is supplied).

Reverse-verification

Each new guard was mutated on the committed tree and observed failing, then restored (tree confirmed clean afterwards):

mutation	result
drop viewName from nav_people	member-page red — expected undefined to be 'all_users'
put status back first in my_week	views red on both the order pin and the new leading-column guard
viewName: 'all_userz'	metadata-bindings red — "the platform object sys_user declares no list view named all_userz … Declared: all_users, banned, me, two_factor, unverified"

That third message lists the five real SysUser.listViews names, which is the evidence the walk reads the platform package rather than a hand-copied list.

Gates

Run on the final tree at 8d1711d:

pnpm validate ✓ Validation passed (445ms)
pnpm typecheck exit 0
pnpm test Test Files 32 passed (32) · Tests 837 passed (837)
pnpm build ✓ Build complete

validate prints the one expected hierarchy-security capability warning, which AGENTS.md §7 says is this repo's normal state and must not be silenced.

Not in this card

Bulk confirm / approve / return on the duty views, board card tweaks, and dashboard number formatting are all untouched, as the issue directs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

---

Generated by Claude Code

[os-warren]

Closes#118

Two metadata fixes, both re-measured in a browser on this branch rather than reasoned about. All four gates green at 8d1711d.

1. nav_people → viewName: 'all_users'

The entry named sys_user with no viewName, so the Console opened that object's default view — me, "My Profile", filtered id == {current_user_id} with pageSize: 1. A manager who followed the Duty-health dashboard to People in order to look at other people got exactly one row: themselves.

all_users is the platform's own unfiltered lens (@objectstack/platform-objects, sys_user.listViews.all_users) — named, not redeclared, because the views of a runtime-provided object are not ours to author and a local copy would drift.

Measured on the running demo, signed in as the dev admin:

what	rows
/sys_user (the default view nav used to open)	1
/sys_user/view/all_users (what the nav entry points at now)	13

The nav entry's href is now /_console/apps/ai.objectstack.duly/sys_user/view/all_users, breadcrumb User / All Users, first row Ana Ferreira · ana.ferreira@ardenline.example.

One correction to the card: all_users renders Name / Email / Phone Number / Email Verified / Identity Source / Two-Factor Enabled / Created At — not "Name / Email / Business unit". The column set is the platform's, so it is not something this PR chooses; the row count, which is the defect, is exactly the 13 the card predicted.

2. my_week leads with subject; attachments dropped

The first column is not merely the leftmost one — two renderers read it as the row's identity, so status leading made the state of a thing stand in for the thing. Both halves confirmed fixed:

• Desktop grid. Headers are now # · Task · Status · Source · Due · Latest progress · Actions, and the row's a[href*="/record/"] is in the Task cell with the subject as its text — e.g. Emissions return — Northgate → /duly_task/record/rWCkoZEut6a7ngu2. Open is plain text beside it, no longer the only clickable thing on the row.
• 390px cards. Cards are now titled Emissions return — Northgate, Waste transfer log review — Northgate, Keep up with regulator bulletins — not open / in_progress.

attachments is dropped from this lens only: it was a dash on every row of the busiest screen in the product. The field is untouched, the shared columns array still carries it on the other four grids, and the upload #108 built is still on the record page's "Progress and attachments" group.

late, stalled and by_unit already led with subject and are unchanged.

Guards

Both walked rather than listed by name, so a lens added later is covered on the day it lands.

• test/views.test.ts — the my_week order pin is updated, and a new test asserts the rule that outlives the exact column list: everyduly_task grid leads with subject. The defect was one lens disagreeing with the other four, which a per-view pin would not have said. It reaches the container default (list) too, which byName cannot address.
• test/member-page.test.ts — pins nav_people.viewName, so dropping it is a red test rather than a silently-refiltered screen.
• test/metadata-bindings.test.ts — this is the app's first nav reference across the platform-object boundary, and that file pins boundaries to an exact zero, by design, to "fail the day one is authored". It did. Widening the pin would have been the wrong answer: a platform object's fields genuinely cannot be judged from @objectstack/spec, but its views can, because @objectstack/platform-objects is a devDependency that ships them on disk. So the walk now resolvessys_user.all_users for real and boundaries stays zero — which means a typo'd platform view name is now a finding instead of an unjudgeable gap. That is the same silent-fallback defect this PR fixes, so the guard covers the surface where it was just measured. Three self-tests cover the branch's three outcomes (resolves / fires on a typo / still records a boundary when no map is supplied).

Reverse-verification

Each new guard was mutated on the committed tree and observed failing, then restored (tree confirmed clean afterwards):

mutation	result
drop viewName from nav_people	member-page red — expected undefined to be 'all_users'
put status back first in my_week	views red on both the order pin and the new leading-column guard
viewName: 'all_userz'	metadata-bindings red — "the platform object sys_user declares no list view named all_userz … Declared: all_users, banned, me, two_factor, unverified"

That third message lists the five real SysUser.listViews names, which is the evidence the walk reads the platform package rather than a hand-copied list.

Gates

Run on the final tree at 8d1711d:

pnpm validate ✓ Validation passed (445ms)
pnpm typecheck exit 0
pnpm test Test Files 32 passed (32) · Tests 837 passed (837)
pnpm build ✓ Build complete

validate prints the one expected hierarchy-security capability warning, which AGENTS.md §7 says is this repo's normal state and must not be silenced.

Not in this card

Bulk confirm / approve / return on the duty views, board card tweaks, and dashboard number formatting are all untouched, as the issue directs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SqkTcrxUFci7nqXdbBSe2p

---

Generated by Claude Code