Scope the by-unit lens to open work

[os-warren]

Fixes#86

Implements the triage decision on the card, not the three options in its body: the lens is paging because it is showing the wrong rows, so it gets a scope rather than a bigger page.

The change

duly_task › by_unit carried no filter and rendered all 186 tasks, 151 of them done, against a top=100 request. It now carries status in ('open','in_progress').

Two things beyond the one-line filter, and they are the reason the card exists:

1. The view comment says the filter is load-bearing for grouping completeness — not a scope preference, and not a default worth inheriting. Someone will widen this later; the comment plus the guard are what stop that being silent.
2. The residual is stated rather than papered over (below).

Page size deliberately not raised: it moves the cliff instead of removing it, and hides the next occurrence.

Measured, in a browser, on the seeded app

Same server, same session, same seed — only this filter reverted between the two runs (git checkout origin/main -- src/views/task.view.ts, restored through a trap). Console at /_console/apps/duly_app/duly_task/view/by_unit.

Before — four groups, and the counts are page slices:

group header	shown	in store
Northgate Operations	33	61
Northgate Plant	3	7
Northgate Quality	46	86
Riverside Plant	18	31
Central Office	no group at all	1

Footer: 100 records · Showing first 100 records. More data may be available. — reproducing the card's measurement exactly.

After — five groups, every count true:

group header	count
Central Office	1
Northgate Operations	7
Northgate Plant	1
Northgate Quality	18
Riverside Plant	6

Footer: 33 records (no truncation notice). Header counts sum to 33, visible data rows 33, and the request the grid issues is:

GET /api/v1/data/duly_task?populate=owner,business_unit&top=100
&select=id,subject,status,due_date,period_key,owner,source,business_unit
&sort=due_date&filter=[["status","in",["open","in_progress"]]]

Counted independently off the seed and matching row for row: 27 open + 6 in_progress = 33, spread 18 / 7 / 6 / 1 / 1 across all five units.

The guard

In test/metadata-bindings.test.ts, alongside#85's grouping-projection guard and in its idiom — not a second mechanism. It pins the decision (by_unit carries the open-work scope) and inventories every grouped grid with the scope it carries, which doubles as the non-vacuity counter.

Scoped to a pin rather than a rule, by measurement: a "grouped grids must be filtered" rule would fire on duly_duty › catalog_tree, which groups two levels deep, carries no filter, and measurably does not need one — the seed holds 31 duties, one page, all groups present. That is the same false-positive trap #85's file narrows away from.

Proven red before the fix, both assertions:

AssertionError: the by-unit lens lost the status filter that keeps its grouping
complete. … expected [] to deeply equal [ 'in_progress', 'open' ]
AssertionError: the set of grouped grids, or the scope one carries, changed …
- "view duly_task › listViews.by_unit · groups by business_unit · status scope: in_progress, open"
+ "view duly_task › listViews.by_unit · groups by business_unit · status scope: (none)"

Nine cases in total, including synthetic self-tests that pin both directions (widened scope, a not_in re-spelling, a filter on another field, and a view that does not group).

What stays broken — please do not read this as a full fix

Even filtered, this lens is structurally page-scoped. A deployment with more open tasks than a page hits exactly this again, with the same silent missing group. The filter buys a correct lens at this product's realistic scale, not a correct mechanism. The durable answer is upstream: objectstack-ai/objectui#7189 (server-side grouping and true per-group counts for a grid; the platform already does this for the dashboard through a dataset, just not on this surface).

So the honest position — and the view's description now says it — is that the dashboard is the authoritative by-unit surface and this lens is for browsing.

One caveat found while verifying, and it matters for that sentence: the description is authored, validated, built and served (GET /api/v1/meta/view/duly_task carries it), but it does not render. The console's ObjectView relay copies label, sort, filter and friends off the active view onto the ListView schema and never copies description, so the branch in ListView that would display it (data-testid="view-description") never receives a value. Nothing errors. Filed as objectstack-ai/objectui#7199, and the view comment says so plainly so nobody believes the caveat is in front of users yet. The key stays authored: it is the spec's home for this sentence, it is served to API/MCP callers today, and it starts rendering the moment the relay is fixed.

Gates

All four green on b780718 (the commit this PR points at):

pnpm validate ✓ Validation passed
pnpm typecheck ✓ (tsc --noEmit, exit 0)
pnpm test ✓ Test Files 22 passed · Tests 591 passed
pnpm build ✓ Build complete — dist/objectstack.json (278.4 KB)

validate prints the one expected hierarchy-security capability warning that AGENTS.md documents as this repo's normal state.

No changeset — this repo has no changeset mechanism; the four gates are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. One labelling correction, and the work itself is right.

First, a note on the evidence, because I nearly misread it. The report points at 20-by_unit-verified.png as the after-state. It is not — it shows a single Northgate Operations 33 group full of Done rows, and its mtime falls immediately after before.sh ran. The genuine after-state is 10-by_unit.png, captured three minutes earlier:

Central Office 1 Commissioning file handover — In progress
Northgate Operations 7 Open / In progress
Northgate Plant 1 Open
Northgate Quality 18 Open
Riverside Plant 6 (below the fold)
──
33 footer: "33 records", no truncation notice

Five groups, Central Office present where it was absent before, every row open or in_progress. The two files are named backwards. Worth flagging so nobody re-reviews this later against the wrong image, but it is a filename, not a defect — I confirmed the fix independently against the code and the gates.

The code carries the filter:filter: [{ field: 'status', operator: 'in', value: ['open', 'in_progress'] }], page size untouched, business_unit still in columns from #85.

Gates, re-run by me on the head merged with current main (this branch predates #87, #88 and #90): validate 0, typecheck 0, test 0 — Test Files 24 passed, Tests 615 passed — build 0.

The narrowing is right, again

The guard is a pin on the by_unit decision plus an inventory of every grouped grid and the scope it carries, not a general "grouped grids must be filtered" rule. Measured reason: that rule would fire on duly_dutycatalog_tree, which groups two levels, carries no filter, and does not need one — 31 duties, one page. This is the third card in a row where the dispatched scope was too wide and the measurement narrowed it correctly. The inventory doubling as the non-vacuity counter is a nice touch: it makes the guard say what it is not covering, so the next reader sees the boundary instead of assuming it.

And the residual is honest

objectui#7199 is the right kind of find: the description explaining that the dashboard is the authoritative by-unit surface is served but never rendered — app-shell's ObjectView relay copies label/sort/filter onto the ListView schema and never copies description. So the caveat I asked to be put on the screen is not on the screen. Saying that plainly in the view comment and not overclaiming it in the PR body is exactly right; the alternative — shipping the note and assuming it lands — would have left us believing users were warned when they were not. The second half of that report (an inline {en, 'zh-CN'} map would render empty even after the relay is fixed) is the kind of detail that saves the platform a second round.

The environment friction you reported at the end — --seed-admin never firing because the app's own seed creates sys_user rows first — is objectstack#14157, and it stopped being your problem about an hour ago: #88 landed, so the demo seed is opt-in and pnpm dev on a clean checkout now mints a working admin. Browser verification should be routine from here.

---

Generated by Claude Code

[os-warren]

Fixes#86

Implements the triage decision on the card, not the three options in its body: the lens is paging because it is showing the wrong rows, so it gets a scope rather than a bigger page.

The change

duly_task › by_unit carried no filter and rendered all 186 tasks, 151 of them done, against a top=100 request. It now carries status in ('open','in_progress').

Two things beyond the one-line filter, and they are the reason the card exists:

1. The view comment says the filter is load-bearing for grouping completeness — not a scope preference, and not a default worth inheriting. Someone will widen this later; the comment plus the guard are what stop that being silent.
2. The residual is stated rather than papered over (below).

Page size deliberately not raised: it moves the cliff instead of removing it, and hides the next occurrence.

Measured, in a browser, on the seeded app

Same server, same session, same seed — only this filter reverted between the two runs (git checkout origin/main -- src/views/task.view.ts, restored through a trap). Console at /_console/apps/duly_app/duly_task/view/by_unit.

Before — four groups, and the counts are page slices:

group header	shown	in store
Northgate Operations	33	61
Northgate Plant	3	7
Northgate Quality	46	86
Riverside Plant	18	31
Central Office	no group at all	1

Footer: 100 records · Showing first 100 records. More data may be available. — reproducing the card's measurement exactly.

After — five groups, every count true:

group header	count
Central Office	1
Northgate Operations	7
Northgate Plant	1
Northgate Quality	18
Riverside Plant	6

Footer: 33 records (no truncation notice). Header counts sum to 33, visible data rows 33, and the request the grid issues is:

GET /api/v1/data/duly_task?populate=owner,business_unit&top=100
&select=id,subject,status,due_date,period_key,owner,source,business_unit
&sort=due_date&filter=[["status","in",["open","in_progress"]]]

Counted independently off the seed and matching row for row: 27 open + 6 in_progress = 33, spread 18 / 7 / 6 / 1 / 1 across all five units.

The guard

In test/metadata-bindings.test.ts, alongside#85's grouping-projection guard and in its idiom — not a second mechanism. It pins the decision (by_unit carries the open-work scope) and inventories every grouped grid with the scope it carries, which doubles as the non-vacuity counter.

Scoped to a pin rather than a rule, by measurement: a "grouped grids must be filtered" rule would fire on duly_duty › catalog_tree, which groups two levels deep, carries no filter, and measurably does not need one — the seed holds 31 duties, one page, all groups present. That is the same false-positive trap #85's file narrows away from.

Proven red before the fix, both assertions:

AssertionError: the by-unit lens lost the status filter that keeps its grouping
complete. … expected [] to deeply equal [ 'in_progress', 'open' ]
AssertionError: the set of grouped grids, or the scope one carries, changed …
- "view duly_task › listViews.by_unit · groups by business_unit · status scope: in_progress, open"
+ "view duly_task › listViews.by_unit · groups by business_unit · status scope: (none)"

Nine cases in total, including synthetic self-tests that pin both directions (widened scope, a not_in re-spelling, a filter on another field, and a view that does not group).

What stays broken — please do not read this as a full fix

Even filtered, this lens is structurally page-scoped. A deployment with more open tasks than a page hits exactly this again, with the same silent missing group. The filter buys a correct lens at this product's realistic scale, not a correct mechanism. The durable answer is upstream: objectstack-ai/objectui#7189 (server-side grouping and true per-group counts for a grid; the platform already does this for the dashboard through a dataset, just not on this surface).

So the honest position — and the view's description now says it — is that the dashboard is the authoritative by-unit surface and this lens is for browsing.

One caveat found while verifying, and it matters for that sentence: the description is authored, validated, built and served (GET /api/v1/meta/view/duly_task carries it), but it does not render. The console's ObjectView relay copies label, sort, filter and friends off the active view onto the ListView schema and never copies description, so the branch in ListView that would display it (data-testid="view-description") never receives a value. Nothing errors. Filed as objectstack-ai/objectui#7199, and the view comment says so plainly so nobody believes the caveat is in front of users yet. The key stays authored: it is the spec's home for this sentence, it is served to API/MCP callers today, and it starts rendering the moment the relay is fixed.

Gates

All four green on b780718 (the commit this PR points at):

pnpm validate ✓ Validation passed
pnpm typecheck ✓ (tsc --noEmit, exit 0)
pnpm test ✓ Test Files 22 passed · Tests 591 passed
pnpm build ✓ Build complete — dist/objectstack.json (278.4 KB)

validate prints the one expected hierarchy-security capability warning that AGENTS.md documents as this repo's normal state.

No changeset — this repo has no changeset mechanism; the four gates are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. One labelling correction, and the work itself is right.

First, a note on the evidence, because I nearly misread it. The report points at 20-by_unit-verified.png as the after-state. It is not — it shows a single Northgate Operations 33 group full of Done rows, and its mtime falls immediately after before.sh ran. The genuine after-state is 10-by_unit.png, captured three minutes earlier:

Central Office 1 Commissioning file handover — In progress
Northgate Operations 7 Open / In progress
Northgate Plant 1 Open
Northgate Quality 18 Open
Riverside Plant 6 (below the fold)
──
33 footer: "33 records", no truncation notice

Five groups, Central Office present where it was absent before, every row open or in_progress. The two files are named backwards. Worth flagging so nobody re-reviews this later against the wrong image, but it is a filename, not a defect — I confirmed the fix independently against the code and the gates.

The code carries the filter:filter: [{ field: 'status', operator: 'in', value: ['open', 'in_progress'] }], page size untouched, business_unit still in columns from #85.

Gates, re-run by me on the head merged with current main (this branch predates #87, #88 and #90): validate 0, typecheck 0, test 0 — Test Files 24 passed, Tests 615 passed — build 0.

The narrowing is right, again

The guard is a pin on the by_unit decision plus an inventory of every grouped grid and the scope it carries, not a general "grouped grids must be filtered" rule. Measured reason: that rule would fire on duly_dutycatalog_tree, which groups two levels, carries no filter, and does not need one — 31 duties, one page. This is the third card in a row where the dispatched scope was too wide and the measurement narrowed it correctly. The inventory doubling as the non-vacuity counter is a nice touch: it makes the guard say what it is not covering, so the next reader sees the boundary instead of assuming it.

And the residual is honest

objectui#7199 is the right kind of find: the description explaining that the dashboard is the authoritative by-unit surface is served but never rendered — app-shell's ObjectView relay copies label/sort/filter onto the ListView schema and never copies description. So the caveat I asked to be put on the screen is not on the screen. Saying that plainly in the view comment and not overclaiming it in the PR body is exactly right; the alternative — shipping the note and assuming it lands — would have left us believing users were warned when they were not. The second half of that report (an inline {en, 'zh-CN'} map would render empty even after the relay is fixed) is the kind of detail that saves the platform a second round.

The environment friction you reported at the end — --seed-admin never firing because the app's own seed creates sys_user rows first — is objectstack#14157, and it stopped being your problem about an hour ago: #88 landed, so the demo seed is opt-in and pnpm dev on a clean checkout now mints a working admin. Browser verification should be routine from here.

---

Generated by Claude Code

[os-warren]

Fixes#86

Implements the triage decision on the card, not the three options in its body: the lens is paging because it is showing the wrong rows, so it gets a scope rather than a bigger page.

The change

duly_task › by_unit carried no filter and rendered all 186 tasks, 151 of them done, against a top=100 request. It now carries status in ('open','in_progress').

Two things beyond the one-line filter, and they are the reason the card exists:

1. The view comment says the filter is load-bearing for grouping completeness — not a scope preference, and not a default worth inheriting. Someone will widen this later; the comment plus the guard are what stop that being silent.
2. The residual is stated rather than papered over (below).

Page size deliberately not raised: it moves the cliff instead of removing it, and hides the next occurrence.

Measured, in a browser, on the seeded app

Same server, same session, same seed — only this filter reverted between the two runs (git checkout origin/main -- src/views/task.view.ts, restored through a trap). Console at /_console/apps/duly_app/duly_task/view/by_unit.

Before — four groups, and the counts are page slices:

group header	shown	in store
Northgate Operations	33	61
Northgate Plant	3	7
Northgate Quality	46	86
Riverside Plant	18	31
Central Office	no group at all	1

Footer: 100 records · Showing first 100 records. More data may be available. — reproducing the card's measurement exactly.

After — five groups, every count true:

group header	count
Central Office	1
Northgate Operations	7
Northgate Plant	1
Northgate Quality	18
Riverside Plant	6

Footer: 33 records (no truncation notice). Header counts sum to 33, visible data rows 33, and the request the grid issues is:

GET /api/v1/data/duly_task?populate=owner,business_unit&top=100
&select=id,subject,status,due_date,period_key,owner,source,business_unit
&sort=due_date&filter=[["status","in",["open","in_progress"]]]

Counted independently off the seed and matching row for row: 27 open + 6 in_progress = 33, spread 18 / 7 / 6 / 1 / 1 across all five units.

The guard

In test/metadata-bindings.test.ts, alongside#85's grouping-projection guard and in its idiom — not a second mechanism. It pins the decision (by_unit carries the open-work scope) and inventories every grouped grid with the scope it carries, which doubles as the non-vacuity counter.

Scoped to a pin rather than a rule, by measurement: a "grouped grids must be filtered" rule would fire on duly_duty › catalog_tree, which groups two levels deep, carries no filter, and measurably does not need one — the seed holds 31 duties, one page, all groups present. That is the same false-positive trap #85's file narrows away from.

Proven red before the fix, both assertions:

AssertionError: the by-unit lens lost the status filter that keeps its grouping
complete. … expected [] to deeply equal [ 'in_progress', 'open' ]
AssertionError: the set of grouped grids, or the scope one carries, changed …
- "view duly_task › listViews.by_unit · groups by business_unit · status scope: in_progress, open"
+ "view duly_task › listViews.by_unit · groups by business_unit · status scope: (none)"

Nine cases in total, including synthetic self-tests that pin both directions (widened scope, a not_in re-spelling, a filter on another field, and a view that does not group).

What stays broken — please do not read this as a full fix

Even filtered, this lens is structurally page-scoped. A deployment with more open tasks than a page hits exactly this again, with the same silent missing group. The filter buys a correct lens at this product's realistic scale, not a correct mechanism. The durable answer is upstream: objectstack-ai/objectui#7189 (server-side grouping and true per-group counts for a grid; the platform already does this for the dashboard through a dataset, just not on this surface).

So the honest position — and the view's description now says it — is that the dashboard is the authoritative by-unit surface and this lens is for browsing.

One caveat found while verifying, and it matters for that sentence: the description is authored, validated, built and served (GET /api/v1/meta/view/duly_task carries it), but it does not render. The console's ObjectView relay copies label, sort, filter and friends off the active view onto the ListView schema and never copies description, so the branch in ListView that would display it (data-testid="view-description") never receives a value. Nothing errors. Filed as objectstack-ai/objectui#7199, and the view comment says so plainly so nobody believes the caveat is in front of users yet. The key stays authored: it is the spec's home for this sentence, it is served to API/MCP callers today, and it starts rendering the moment the relay is fixed.

Gates

All four green on b780718 (the commit this PR points at):

pnpm validate ✓ Validation passed
pnpm typecheck ✓ (tsc --noEmit, exit 0)
pnpm test ✓ Test Files 22 passed · Tests 591 passed
pnpm build ✓ Build complete — dist/objectstack.json (278.4 KB)

validate prints the one expected hierarchy-security capability warning that AGENTS.md documents as this repo's normal state.

No changeset — this repo has no changeset mechanism; the four gates are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. One labelling correction, and the work itself is right.

First, a note on the evidence, because I nearly misread it. The report points at 20-by_unit-verified.png as the after-state. It is not — it shows a single Northgate Operations 33 group full of Done rows, and its mtime falls immediately after before.sh ran. The genuine after-state is 10-by_unit.png, captured three minutes earlier:

Central Office 1 Commissioning file handover — In progress
Northgate Operations 7 Open / In progress
Northgate Plant 1 Open
Northgate Quality 18 Open
Riverside Plant 6 (below the fold)
──
33 footer: "33 records", no truncation notice

Five groups, Central Office present where it was absent before, every row open or in_progress. The two files are named backwards. Worth flagging so nobody re-reviews this later against the wrong image, but it is a filename, not a defect — I confirmed the fix independently against the code and the gates.

The code carries the filter:filter: [{ field: 'status', operator: 'in', value: ['open', 'in_progress'] }], page size untouched, business_unit still in columns from #85.

Gates, re-run by me on the head merged with current main (this branch predates #87, #88 and #90): validate 0, typecheck 0, test 0 — Test Files 24 passed, Tests 615 passed — build 0.

The narrowing is right, again

The guard is a pin on the by_unit decision plus an inventory of every grouped grid and the scope it carries, not a general "grouped grids must be filtered" rule. Measured reason: that rule would fire on duly_dutycatalog_tree, which groups two levels, carries no filter, and does not need one — 31 duties, one page. This is the third card in a row where the dispatched scope was too wide and the measurement narrowed it correctly. The inventory doubling as the non-vacuity counter is a nice touch: it makes the guard say what it is not covering, so the next reader sees the boundary instead of assuming it.

And the residual is honest

objectui#7199 is the right kind of find: the description explaining that the dashboard is the authoritative by-unit surface is served but never rendered — app-shell's ObjectView relay copies label/sort/filter onto the ListView schema and never copies description. So the caveat I asked to be put on the screen is not on the screen. Saying that plainly in the view comment and not overclaiming it in the PR body is exactly right; the alternative — shipping the note and assuming it lands — would have left us believing users were warned when they were not. The second half of that report (an inline {en, 'zh-CN'} map would render empty even after the relay is fixed) is the kind of detail that saves the platform a second round.

The environment friction you reported at the end — --seed-admin never firing because the app's own seed creates sys_user rows first — is objectstack#14157, and it stopped being your problem about an hour ago: #88 landed, so the demo seed is opt-in and pnpm dev on a clean checkout now mints a working admin. Browser verification should be routine from here.

---

Generated by Claude Code

[os-warren]

Fixes#86

Implements the triage decision on the card, not the three options in its body: the lens is paging because it is showing the wrong rows, so it gets a scope rather than a bigger page.

The change

duly_task › by_unit carried no filter and rendered all 186 tasks, 151 of them done, against a top=100 request. It now carries status in ('open','in_progress').

Two things beyond the one-line filter, and they are the reason the card exists:

1. The view comment says the filter is load-bearing for grouping completeness — not a scope preference, and not a default worth inheriting. Someone will widen this later; the comment plus the guard are what stop that being silent.
2. The residual is stated rather than papered over (below).

Page size deliberately not raised: it moves the cliff instead of removing it, and hides the next occurrence.

Measured, in a browser, on the seeded app

Same server, same session, same seed — only this filter reverted between the two runs (git checkout origin/main -- src/views/task.view.ts, restored through a trap). Console at /_console/apps/duly_app/duly_task/view/by_unit.

Before — four groups, and the counts are page slices:

group header	shown	in store
Northgate Operations	33	61
Northgate Plant	3	7
Northgate Quality	46	86
Riverside Plant	18	31
Central Office	no group at all	1

Footer: 100 records · Showing first 100 records. More data may be available. — reproducing the card's measurement exactly.

After — five groups, every count true:

group header	count
Central Office	1
Northgate Operations	7
Northgate Plant	1
Northgate Quality	18
Riverside Plant	6

Footer: 33 records (no truncation notice). Header counts sum to 33, visible data rows 33, and the request the grid issues is:

GET /api/v1/data/duly_task?populate=owner,business_unit&top=100
&select=id,subject,status,due_date,period_key,owner,source,business_unit
&sort=due_date&filter=[["status","in",["open","in_progress"]]]

Counted independently off the seed and matching row for row: 27 open + 6 in_progress = 33, spread 18 / 7 / 6 / 1 / 1 across all five units.

The guard

In test/metadata-bindings.test.ts, alongside#85's grouping-projection guard and in its idiom — not a second mechanism. It pins the decision (by_unit carries the open-work scope) and inventories every grouped grid with the scope it carries, which doubles as the non-vacuity counter.

Scoped to a pin rather than a rule, by measurement: a "grouped grids must be filtered" rule would fire on duly_duty › catalog_tree, which groups two levels deep, carries no filter, and measurably does not need one — the seed holds 31 duties, one page, all groups present. That is the same false-positive trap #85's file narrows away from.

Proven red before the fix, both assertions:

AssertionError: the by-unit lens lost the status filter that keeps its grouping
complete. … expected [] to deeply equal [ 'in_progress', 'open' ]
AssertionError: the set of grouped grids, or the scope one carries, changed …
- "view duly_task › listViews.by_unit · groups by business_unit · status scope: in_progress, open"
+ "view duly_task › listViews.by_unit · groups by business_unit · status scope: (none)"

Nine cases in total, including synthetic self-tests that pin both directions (widened scope, a not_in re-spelling, a filter on another field, and a view that does not group).

What stays broken — please do not read this as a full fix

Even filtered, this lens is structurally page-scoped. A deployment with more open tasks than a page hits exactly this again, with the same silent missing group. The filter buys a correct lens at this product's realistic scale, not a correct mechanism. The durable answer is upstream: objectstack-ai/objectui#7189 (server-side grouping and true per-group counts for a grid; the platform already does this for the dashboard through a dataset, just not on this surface).

So the honest position — and the view's description now says it — is that the dashboard is the authoritative by-unit surface and this lens is for browsing.

One caveat found while verifying, and it matters for that sentence: the description is authored, validated, built and served (GET /api/v1/meta/view/duly_task carries it), but it does not render. The console's ObjectView relay copies label, sort, filter and friends off the active view onto the ListView schema and never copies description, so the branch in ListView that would display it (data-testid="view-description") never receives a value. Nothing errors. Filed as objectstack-ai/objectui#7199, and the view comment says so plainly so nobody believes the caveat is in front of users yet. The key stays authored: it is the spec's home for this sentence, it is served to API/MCP callers today, and it starts rendering the moment the relay is fixed.

Gates

All four green on b780718 (the commit this PR points at):

pnpm validate ✓ Validation passed
pnpm typecheck ✓ (tsc --noEmit, exit 0)
pnpm test ✓ Test Files 22 passed · Tests 591 passed
pnpm build ✓ Build complete — dist/objectstack.json (278.4 KB)

validate prints the one expected hierarchy-security capability warning that AGENTS.md documents as this repo's normal state.

No changeset — this repo has no changeset mechanism; the four gates are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. One labelling correction, and the work itself is right.

First, a note on the evidence, because I nearly misread it. The report points at 20-by_unit-verified.png as the after-state. It is not — it shows a single Northgate Operations 33 group full of Done rows, and its mtime falls immediately after before.sh ran. The genuine after-state is 10-by_unit.png, captured three minutes earlier:

Central Office 1 Commissioning file handover — In progress
Northgate Operations 7 Open / In progress
Northgate Plant 1 Open
Northgate Quality 18 Open
Riverside Plant 6 (below the fold)
──
33 footer: "33 records", no truncation notice

Five groups, Central Office present where it was absent before, every row open or in_progress. The two files are named backwards. Worth flagging so nobody re-reviews this later against the wrong image, but it is a filename, not a defect — I confirmed the fix independently against the code and the gates.

The code carries the filter:filter: [{ field: 'status', operator: 'in', value: ['open', 'in_progress'] }], page size untouched, business_unit still in columns from #85.

Gates, re-run by me on the head merged with current main (this branch predates #87, #88 and #90): validate 0, typecheck 0, test 0 — Test Files 24 passed, Tests 615 passed — build 0.

The narrowing is right, again

The guard is a pin on the by_unit decision plus an inventory of every grouped grid and the scope it carries, not a general "grouped grids must be filtered" rule. Measured reason: that rule would fire on duly_dutycatalog_tree, which groups two levels, carries no filter, and does not need one — 31 duties, one page. This is the third card in a row where the dispatched scope was too wide and the measurement narrowed it correctly. The inventory doubling as the non-vacuity counter is a nice touch: it makes the guard say what it is not covering, so the next reader sees the boundary instead of assuming it.

And the residual is honest

objectui#7199 is the right kind of find: the description explaining that the dashboard is the authoritative by-unit surface is served but never rendered — app-shell's ObjectView relay copies label/sort/filter onto the ListView schema and never copies description. So the caveat I asked to be put on the screen is not on the screen. Saying that plainly in the view comment and not overclaiming it in the PR body is exactly right; the alternative — shipping the note and assuming it lands — would have left us believing users were warned when they were not. The second half of that report (an inline {en, 'zh-CN'} map would render empty even after the relay is fixed) is the kind of detail that saves the platform a second round.

The environment friction you reported at the end — --seed-admin never firing because the app's own seed creates sys_user rows first — is objectstack#14157, and it stopped being your problem about an hour ago: #88 landed, so the demo seed is opt-in and pnpm dev on a clean checkout now mints a working admin. Browser verification should be routine from here.

---

Generated by Claude Code

[os-warren]

Fixes#86

Implements the triage decision on the card, not the three options in its body: the lens is paging because it is showing the wrong rows, so it gets a scope rather than a bigger page.

The change

duly_task › by_unit carried no filter and rendered all 186 tasks, 151 of them done, against a top=100 request. It now carries status in ('open','in_progress').

Two things beyond the one-line filter, and they are the reason the card exists:

1. The view comment says the filter is load-bearing for grouping completeness — not a scope preference, and not a default worth inheriting. Someone will widen this later; the comment plus the guard are what stop that being silent.
2. The residual is stated rather than papered over (below).

Page size deliberately not raised: it moves the cliff instead of removing it, and hides the next occurrence.

Measured, in a browser, on the seeded app

Same server, same session, same seed — only this filter reverted between the two runs (git checkout origin/main -- src/views/task.view.ts, restored through a trap). Console at /_console/apps/duly_app/duly_task/view/by_unit.

Before — four groups, and the counts are page slices:

group header	shown	in store
Northgate Operations	33	61
Northgate Plant	3	7
Northgate Quality	46	86
Riverside Plant	18	31
Central Office	no group at all	1

Footer: 100 records · Showing first 100 records. More data may be available. — reproducing the card's measurement exactly.

After — five groups, every count true:

group header	count
Central Office	1
Northgate Operations	7
Northgate Plant	1
Northgate Quality	18
Riverside Plant	6

Footer: 33 records (no truncation notice). Header counts sum to 33, visible data rows 33, and the request the grid issues is:

GET /api/v1/data/duly_task?populate=owner,business_unit&top=100
&select=id,subject,status,due_date,period_key,owner,source,business_unit
&sort=due_date&filter=[["status","in",["open","in_progress"]]]

Counted independently off the seed and matching row for row: 27 open + 6 in_progress = 33, spread 18 / 7 / 6 / 1 / 1 across all five units.

The guard

In test/metadata-bindings.test.ts, alongside#85's grouping-projection guard and in its idiom — not a second mechanism. It pins the decision (by_unit carries the open-work scope) and inventories every grouped grid with the scope it carries, which doubles as the non-vacuity counter.

Scoped to a pin rather than a rule, by measurement: a "grouped grids must be filtered" rule would fire on duly_duty › catalog_tree, which groups two levels deep, carries no filter, and measurably does not need one — the seed holds 31 duties, one page, all groups present. That is the same false-positive trap #85's file narrows away from.

Proven red before the fix, both assertions:

AssertionError: the by-unit lens lost the status filter that keeps its grouping
complete. … expected [] to deeply equal [ 'in_progress', 'open' ]
AssertionError: the set of grouped grids, or the scope one carries, changed …
- "view duly_task › listViews.by_unit · groups by business_unit · status scope: in_progress, open"
+ "view duly_task › listViews.by_unit · groups by business_unit · status scope: (none)"

Nine cases in total, including synthetic self-tests that pin both directions (widened scope, a not_in re-spelling, a filter on another field, and a view that does not group).

What stays broken — please do not read this as a full fix

Even filtered, this lens is structurally page-scoped. A deployment with more open tasks than a page hits exactly this again, with the same silent missing group. The filter buys a correct lens at this product's realistic scale, not a correct mechanism. The durable answer is upstream: objectstack-ai/objectui#7189 (server-side grouping and true per-group counts for a grid; the platform already does this for the dashboard through a dataset, just not on this surface).

So the honest position — and the view's description now says it — is that the dashboard is the authoritative by-unit surface and this lens is for browsing.

One caveat found while verifying, and it matters for that sentence: the description is authored, validated, built and served (GET /api/v1/meta/view/duly_task carries it), but it does not render. The console's ObjectView relay copies label, sort, filter and friends off the active view onto the ListView schema and never copies description, so the branch in ListView that would display it (data-testid="view-description") never receives a value. Nothing errors. Filed as objectstack-ai/objectui#7199, and the view comment says so plainly so nobody believes the caveat is in front of users yet. The key stays authored: it is the spec's home for this sentence, it is served to API/MCP callers today, and it starts rendering the moment the relay is fixed.

Gates

All four green on b780718 (the commit this PR points at):

pnpm validate ✓ Validation passed
pnpm typecheck ✓ (tsc --noEmit, exit 0)
pnpm test ✓ Test Files 22 passed · Tests 591 passed
pnpm build ✓ Build complete — dist/objectstack.json (278.4 KB)

validate prints the one expected hierarchy-security capability warning that AGENTS.md documents as this repo's normal state.

No changeset — this repo has no changeset mechanism; the four gates are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. One labelling correction, and the work itself is right.

First, a note on the evidence, because I nearly misread it. The report points at 20-by_unit-verified.png as the after-state. It is not — it shows a single Northgate Operations 33 group full of Done rows, and its mtime falls immediately after before.sh ran. The genuine after-state is 10-by_unit.png, captured three minutes earlier:

Central Office 1 Commissioning file handover — In progress
Northgate Operations 7 Open / In progress
Northgate Plant 1 Open
Northgate Quality 18 Open
Riverside Plant 6 (below the fold)
──
33 footer: "33 records", no truncation notice

Five groups, Central Office present where it was absent before, every row open or in_progress. The two files are named backwards. Worth flagging so nobody re-reviews this later against the wrong image, but it is a filename, not a defect — I confirmed the fix independently against the code and the gates.

The code carries the filter:filter: [{ field: 'status', operator: 'in', value: ['open', 'in_progress'] }], page size untouched, business_unit still in columns from #85.

Gates, re-run by me on the head merged with current main (this branch predates #87, #88 and #90): validate 0, typecheck 0, test 0 — Test Files 24 passed, Tests 615 passed — build 0.

The narrowing is right, again

The guard is a pin on the by_unit decision plus an inventory of every grouped grid and the scope it carries, not a general "grouped grids must be filtered" rule. Measured reason: that rule would fire on duly_dutycatalog_tree, which groups two levels, carries no filter, and does not need one — 31 duties, one page. This is the third card in a row where the dispatched scope was too wide and the measurement narrowed it correctly. The inventory doubling as the non-vacuity counter is a nice touch: it makes the guard say what it is not covering, so the next reader sees the boundary instead of assuming it.

And the residual is honest

objectui#7199 is the right kind of find: the description explaining that the dashboard is the authoritative by-unit surface is served but never rendered — app-shell's ObjectView relay copies label/sort/filter onto the ListView schema and never copies description. So the caveat I asked to be put on the screen is not on the screen. Saying that plainly in the view comment and not overclaiming it in the PR body is exactly right; the alternative — shipping the note and assuming it lands — would have left us believing users were warned when they were not. The second half of that report (an inline {en, 'zh-CN'} map would render empty even after the relay is fixed) is the kind of detail that saves the platform a second round.

The environment friction you reported at the end — --seed-admin never firing because the app's own seed creates sys_user rows first — is objectstack#14157, and it stopped being your problem about an hour ago: #88 landed, so the demo seed is opt-in and pnpm dev on a clean checkout now mints a working admin. Browser verification should be routine from here.

---

Generated by Claude Code

[os-warren]

Fixes#86

Implements the triage decision on the card, not the three options in its body: the lens is paging because it is showing the wrong rows, so it gets a scope rather than a bigger page.

The change

duly_task › by_unit carried no filter and rendered all 186 tasks, 151 of them done, against a top=100 request. It now carries status in ('open','in_progress').

Two things beyond the one-line filter, and they are the reason the card exists:

1. The view comment says the filter is load-bearing for grouping completeness — not a scope preference, and not a default worth inheriting. Someone will widen this later; the comment plus the guard are what stop that being silent.
2. The residual is stated rather than papered over (below).

Page size deliberately not raised: it moves the cliff instead of removing it, and hides the next occurrence.

Measured, in a browser, on the seeded app

Same server, same session, same seed — only this filter reverted between the two runs (git checkout origin/main -- src/views/task.view.ts, restored through a trap). Console at /_console/apps/duly_app/duly_task/view/by_unit.

Before — four groups, and the counts are page slices:

group header	shown	in store
Northgate Operations	33	61
Northgate Plant	3	7
Northgate Quality	46	86
Riverside Plant	18	31
Central Office	no group at all	1

Footer: 100 records · Showing first 100 records. More data may be available. — reproducing the card's measurement exactly.

After — five groups, every count true:

group header	count
Central Office	1
Northgate Operations	7
Northgate Plant	1
Northgate Quality	18
Riverside Plant	6

Footer: 33 records (no truncation notice). Header counts sum to 33, visible data rows 33, and the request the grid issues is:

GET /api/v1/data/duly_task?populate=owner,business_unit&top=100
&select=id,subject,status,due_date,period_key,owner,source,business_unit
&sort=due_date&filter=[["status","in",["open","in_progress"]]]

Counted independently off the seed and matching row for row: 27 open + 6 in_progress = 33, spread 18 / 7 / 6 / 1 / 1 across all five units.

The guard

In test/metadata-bindings.test.ts, alongside#85's grouping-projection guard and in its idiom — not a second mechanism. It pins the decision (by_unit carries the open-work scope) and inventories every grouped grid with the scope it carries, which doubles as the non-vacuity counter.

Scoped to a pin rather than a rule, by measurement: a "grouped grids must be filtered" rule would fire on duly_duty › catalog_tree, which groups two levels deep, carries no filter, and measurably does not need one — the seed holds 31 duties, one page, all groups present. That is the same false-positive trap #85's file narrows away from.

Proven red before the fix, both assertions:

AssertionError: the by-unit lens lost the status filter that keeps its grouping
complete. … expected [] to deeply equal [ 'in_progress', 'open' ]
AssertionError: the set of grouped grids, or the scope one carries, changed …
- "view duly_task › listViews.by_unit · groups by business_unit · status scope: in_progress, open"
+ "view duly_task › listViews.by_unit · groups by business_unit · status scope: (none)"

Nine cases in total, including synthetic self-tests that pin both directions (widened scope, a not_in re-spelling, a filter on another field, and a view that does not group).

What stays broken — please do not read this as a full fix

Even filtered, this lens is structurally page-scoped. A deployment with more open tasks than a page hits exactly this again, with the same silent missing group. The filter buys a correct lens at this product's realistic scale, not a correct mechanism. The durable answer is upstream: objectstack-ai/objectui#7189 (server-side grouping and true per-group counts for a grid; the platform already does this for the dashboard through a dataset, just not on this surface).

So the honest position — and the view's description now says it — is that the dashboard is the authoritative by-unit surface and this lens is for browsing.

One caveat found while verifying, and it matters for that sentence: the description is authored, validated, built and served (GET /api/v1/meta/view/duly_task carries it), but it does not render. The console's ObjectView relay copies label, sort, filter and friends off the active view onto the ListView schema and never copies description, so the branch in ListView that would display it (data-testid="view-description") never receives a value. Nothing errors. Filed as objectstack-ai/objectui#7199, and the view comment says so plainly so nobody believes the caveat is in front of users yet. The key stays authored: it is the spec's home for this sentence, it is served to API/MCP callers today, and it starts rendering the moment the relay is fixed.

Gates

All four green on b780718 (the commit this PR points at):

pnpm validate ✓ Validation passed
pnpm typecheck ✓ (tsc --noEmit, exit 0)
pnpm test ✓ Test Files 22 passed · Tests 591 passed
pnpm build ✓ Build complete — dist/objectstack.json (278.4 KB)

validate prints the one expected hierarchy-security capability warning that AGENTS.md documents as this repo's normal state.

No changeset — this repo has no changeset mechanism; the four gates are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. One labelling correction, and the work itself is right.

First, a note on the evidence, because I nearly misread it. The report points at 20-by_unit-verified.png as the after-state. It is not — it shows a single Northgate Operations 33 group full of Done rows, and its mtime falls immediately after before.sh ran. The genuine after-state is 10-by_unit.png, captured three minutes earlier:

Central Office 1 Commissioning file handover — In progress
Northgate Operations 7 Open / In progress
Northgate Plant 1 Open
Northgate Quality 18 Open
Riverside Plant 6 (below the fold)
──
33 footer: "33 records", no truncation notice

Five groups, Central Office present where it was absent before, every row open or in_progress. The two files are named backwards. Worth flagging so nobody re-reviews this later against the wrong image, but it is a filename, not a defect — I confirmed the fix independently against the code and the gates.

The code carries the filter:filter: [{ field: 'status', operator: 'in', value: ['open', 'in_progress'] }], page size untouched, business_unit still in columns from #85.

Gates, re-run by me on the head merged with current main (this branch predates #87, #88 and #90): validate 0, typecheck 0, test 0 — Test Files 24 passed, Tests 615 passed — build 0.

The narrowing is right, again

The guard is a pin on the by_unit decision plus an inventory of every grouped grid and the scope it carries, not a general "grouped grids must be filtered" rule. Measured reason: that rule would fire on duly_dutycatalog_tree, which groups two levels, carries no filter, and does not need one — 31 duties, one page. This is the third card in a row where the dispatched scope was too wide and the measurement narrowed it correctly. The inventory doubling as the non-vacuity counter is a nice touch: it makes the guard say what it is not covering, so the next reader sees the boundary instead of assuming it.

And the residual is honest

objectui#7199 is the right kind of find: the description explaining that the dashboard is the authoritative by-unit surface is served but never rendered — app-shell's ObjectView relay copies label/sort/filter onto the ListView schema and never copies description. So the caveat I asked to be put on the screen is not on the screen. Saying that plainly in the view comment and not overclaiming it in the PR body is exactly right; the alternative — shipping the note and assuming it lands — would have left us believing users were warned when they were not. The second half of that report (an inline {en, 'zh-CN'} map would render empty even after the relay is fixed) is the kind of detail that saves the platform a second round.

The environment friction you reported at the end — --seed-admin never firing because the app's own seed creates sys_user rows first — is objectstack#14157, and it stopped being your problem about an hour ago: #88 landed, so the demo seed is opt-in and pnpm dev on a clean checkout now mints a working admin. Browser verification should be routine from here.

---

Generated by Claude Code

[os-warren]

Fixes#86

Implements the triage decision on the card, not the three options in its body: the lens is paging because it is showing the wrong rows, so it gets a scope rather than a bigger page.

The change

duly_task › by_unit carried no filter and rendered all 186 tasks, 151 of them done, against a top=100 request. It now carries status in ('open','in_progress').

Two things beyond the one-line filter, and they are the reason the card exists:

1. The view comment says the filter is load-bearing for grouping completeness — not a scope preference, and not a default worth inheriting. Someone will widen this later; the comment plus the guard are what stop that being silent.
2. The residual is stated rather than papered over (below).

Page size deliberately not raised: it moves the cliff instead of removing it, and hides the next occurrence.

Measured, in a browser, on the seeded app

Same server, same session, same seed — only this filter reverted between the two runs (git checkout origin/main -- src/views/task.view.ts, restored through a trap). Console at /_console/apps/duly_app/duly_task/view/by_unit.

Before — four groups, and the counts are page slices:

group header	shown	in store
Northgate Operations	33	61
Northgate Plant	3	7
Northgate Quality	46	86
Riverside Plant	18	31
Central Office	no group at all	1

Footer: 100 records · Showing first 100 records. More data may be available. — reproducing the card's measurement exactly.

After — five groups, every count true:

group header	count
Central Office	1
Northgate Operations	7
Northgate Plant	1
Northgate Quality	18
Riverside Plant	6

Footer: 33 records (no truncation notice). Header counts sum to 33, visible data rows 33, and the request the grid issues is:

GET /api/v1/data/duly_task?populate=owner,business_unit&top=100
&select=id,subject,status,due_date,period_key,owner,source,business_unit
&sort=due_date&filter=[["status","in",["open","in_progress"]]]

Counted independently off the seed and matching row for row: 27 open + 6 in_progress = 33, spread 18 / 7 / 6 / 1 / 1 across all five units.

The guard

In test/metadata-bindings.test.ts, alongside#85's grouping-projection guard and in its idiom — not a second mechanism. It pins the decision (by_unit carries the open-work scope) and inventories every grouped grid with the scope it carries, which doubles as the non-vacuity counter.

Scoped to a pin rather than a rule, by measurement: a "grouped grids must be filtered" rule would fire on duly_duty › catalog_tree, which groups two levels deep, carries no filter, and measurably does not need one — the seed holds 31 duties, one page, all groups present. That is the same false-positive trap #85's file narrows away from.

Proven red before the fix, both assertions:

AssertionError: the by-unit lens lost the status filter that keeps its grouping
complete. … expected [] to deeply equal [ 'in_progress', 'open' ]
AssertionError: the set of grouped grids, or the scope one carries, changed …
- "view duly_task › listViews.by_unit · groups by business_unit · status scope: in_progress, open"
+ "view duly_task › listViews.by_unit · groups by business_unit · status scope: (none)"

Nine cases in total, including synthetic self-tests that pin both directions (widened scope, a not_in re-spelling, a filter on another field, and a view that does not group).

What stays broken — please do not read this as a full fix

Even filtered, this lens is structurally page-scoped. A deployment with more open tasks than a page hits exactly this again, with the same silent missing group. The filter buys a correct lens at this product's realistic scale, not a correct mechanism. The durable answer is upstream: objectstack-ai/objectui#7189 (server-side grouping and true per-group counts for a grid; the platform already does this for the dashboard through a dataset, just not on this surface).

So the honest position — and the view's description now says it — is that the dashboard is the authoritative by-unit surface and this lens is for browsing.

One caveat found while verifying, and it matters for that sentence: the description is authored, validated, built and served (GET /api/v1/meta/view/duly_task carries it), but it does not render. The console's ObjectView relay copies label, sort, filter and friends off the active view onto the ListView schema and never copies description, so the branch in ListView that would display it (data-testid="view-description") never receives a value. Nothing errors. Filed as objectstack-ai/objectui#7199, and the view comment says so plainly so nobody believes the caveat is in front of users yet. The key stays authored: it is the spec's home for this sentence, it is served to API/MCP callers today, and it starts rendering the moment the relay is fixed.

Gates

All four green on b780718 (the commit this PR points at):

pnpm validate ✓ Validation passed
pnpm typecheck ✓ (tsc --noEmit, exit 0)
pnpm test ✓ Test Files 22 passed · Tests 591 passed
pnpm build ✓ Build complete — dist/objectstack.json (278.4 KB)

validate prints the one expected hierarchy-security capability warning that AGENTS.md documents as this repo's normal state.

No changeset — this repo has no changeset mechanism; the four gates are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. One labelling correction, and the work itself is right.

First, a note on the evidence, because I nearly misread it. The report points at 20-by_unit-verified.png as the after-state. It is not — it shows a single Northgate Operations 33 group full of Done rows, and its mtime falls immediately after before.sh ran. The genuine after-state is 10-by_unit.png, captured three minutes earlier:

Central Office 1 Commissioning file handover — In progress
Northgate Operations 7 Open / In progress
Northgate Plant 1 Open
Northgate Quality 18 Open
Riverside Plant 6 (below the fold)
──
33 footer: "33 records", no truncation notice

Five groups, Central Office present where it was absent before, every row open or in_progress. The two files are named backwards. Worth flagging so nobody re-reviews this later against the wrong image, but it is a filename, not a defect — I confirmed the fix independently against the code and the gates.

The code carries the filter:filter: [{ field: 'status', operator: 'in', value: ['open', 'in_progress'] }], page size untouched, business_unit still in columns from #85.

Gates, re-run by me on the head merged with current main (this branch predates #87, #88 and #90): validate 0, typecheck 0, test 0 — Test Files 24 passed, Tests 615 passed — build 0.

The narrowing is right, again

The guard is a pin on the by_unit decision plus an inventory of every grouped grid and the scope it carries, not a general "grouped grids must be filtered" rule. Measured reason: that rule would fire on duly_dutycatalog_tree, which groups two levels, carries no filter, and does not need one — 31 duties, one page. This is the third card in a row where the dispatched scope was too wide and the measurement narrowed it correctly. The inventory doubling as the non-vacuity counter is a nice touch: it makes the guard say what it is not covering, so the next reader sees the boundary instead of assuming it.

And the residual is honest

objectui#7199 is the right kind of find: the description explaining that the dashboard is the authoritative by-unit surface is served but never rendered — app-shell's ObjectView relay copies label/sort/filter onto the ListView schema and never copies description. So the caveat I asked to be put on the screen is not on the screen. Saying that plainly in the view comment and not overclaiming it in the PR body is exactly right; the alternative — shipping the note and assuming it lands — would have left us believing users were warned when they were not. The second half of that report (an inline {en, 'zh-CN'} map would render empty even after the relay is fixed) is the kind of detail that saves the platform a second round.

The environment friction you reported at the end — --seed-admin never firing because the app's own seed creates sys_user rows first — is objectstack#14157, and it stopped being your problem about an hour ago: #88 landed, so the demo seed is opt-in and pnpm dev on a clean checkout now mints a working admin. Browser verification should be routine from here.

---

Generated by Claude Code

[os-warren]

Fixes#86

Implements the triage decision on the card, not the three options in its body: the lens is paging because it is showing the wrong rows, so it gets a scope rather than a bigger page.

The change

duly_task › by_unit carried no filter and rendered all 186 tasks, 151 of them done, against a top=100 request. It now carries status in ('open','in_progress').

Two things beyond the one-line filter, and they are the reason the card exists:

1. The view comment says the filter is load-bearing for grouping completeness — not a scope preference, and not a default worth inheriting. Someone will widen this later; the comment plus the guard are what stop that being silent.
2. The residual is stated rather than papered over (below).

Page size deliberately not raised: it moves the cliff instead of removing it, and hides the next occurrence.

Measured, in a browser, on the seeded app

Same server, same session, same seed — only this filter reverted between the two runs (git checkout origin/main -- src/views/task.view.ts, restored through a trap). Console at /_console/apps/duly_app/duly_task/view/by_unit.

Before — four groups, and the counts are page slices:

group header	shown	in store
Northgate Operations	33	61
Northgate Plant	3	7
Northgate Quality	46	86
Riverside Plant	18	31
Central Office	no group at all	1

Footer: 100 records · Showing first 100 records. More data may be available. — reproducing the card's measurement exactly.

After — five groups, every count true:

group header	count
Central Office	1
Northgate Operations	7
Northgate Plant	1
Northgate Quality	18
Riverside Plant	6

Footer: 33 records (no truncation notice). Header counts sum to 33, visible data rows 33, and the request the grid issues is:

GET /api/v1/data/duly_task?populate=owner,business_unit&top=100
&select=id,subject,status,due_date,period_key,owner,source,business_unit
&sort=due_date&filter=[["status","in",["open","in_progress"]]]

Counted independently off the seed and matching row for row: 27 open + 6 in_progress = 33, spread 18 / 7 / 6 / 1 / 1 across all five units.

The guard

In test/metadata-bindings.test.ts, alongside#85's grouping-projection guard and in its idiom — not a second mechanism. It pins the decision (by_unit carries the open-work scope) and inventories every grouped grid with the scope it carries, which doubles as the non-vacuity counter.

Scoped to a pin rather than a rule, by measurement: a "grouped grids must be filtered" rule would fire on duly_duty › catalog_tree, which groups two levels deep, carries no filter, and measurably does not need one — the seed holds 31 duties, one page, all groups present. That is the same false-positive trap #85's file narrows away from.

Proven red before the fix, both assertions:

AssertionError: the by-unit lens lost the status filter that keeps its grouping
complete. … expected [] to deeply equal [ 'in_progress', 'open' ]
AssertionError: the set of grouped grids, or the scope one carries, changed …
- "view duly_task › listViews.by_unit · groups by business_unit · status scope: in_progress, open"
+ "view duly_task › listViews.by_unit · groups by business_unit · status scope: (none)"

Nine cases in total, including synthetic self-tests that pin both directions (widened scope, a not_in re-spelling, a filter on another field, and a view that does not group).

What stays broken — please do not read this as a full fix

Even filtered, this lens is structurally page-scoped. A deployment with more open tasks than a page hits exactly this again, with the same silent missing group. The filter buys a correct lens at this product's realistic scale, not a correct mechanism. The durable answer is upstream: objectstack-ai/objectui#7189 (server-side grouping and true per-group counts for a grid; the platform already does this for the dashboard through a dataset, just not on this surface).

So the honest position — and the view's description now says it — is that the dashboard is the authoritative by-unit surface and this lens is for browsing.

One caveat found while verifying, and it matters for that sentence: the description is authored, validated, built and served (GET /api/v1/meta/view/duly_task carries it), but it does not render. The console's ObjectView relay copies label, sort, filter and friends off the active view onto the ListView schema and never copies description, so the branch in ListView that would display it (data-testid="view-description") never receives a value. Nothing errors. Filed as objectstack-ai/objectui#7199, and the view comment says so plainly so nobody believes the caveat is in front of users yet. The key stays authored: it is the spec's home for this sentence, it is served to API/MCP callers today, and it starts rendering the moment the relay is fixed.

Gates

All four green on b780718 (the commit this PR points at):

pnpm validate ✓ Validation passed
pnpm typecheck ✓ (tsc --noEmit, exit 0)
pnpm test ✓ Test Files 22 passed · Tests 591 passed
pnpm build ✓ Build complete — dist/objectstack.json (278.4 KB)

validate prints the one expected hierarchy-security capability warning that AGENTS.md documents as this repo's normal state.

No changeset — this repo has no changeset mechanism; the four gates are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. One labelling correction, and the work itself is right.

First, a note on the evidence, because I nearly misread it. The report points at 20-by_unit-verified.png as the after-state. It is not — it shows a single Northgate Operations 33 group full of Done rows, and its mtime falls immediately after before.sh ran. The genuine after-state is 10-by_unit.png, captured three minutes earlier:

Central Office 1 Commissioning file handover — In progress
Northgate Operations 7 Open / In progress
Northgate Plant 1 Open
Northgate Quality 18 Open
Riverside Plant 6 (below the fold)
──
33 footer: "33 records", no truncation notice

Five groups, Central Office present where it was absent before, every row open or in_progress. The two files are named backwards. Worth flagging so nobody re-reviews this later against the wrong image, but it is a filename, not a defect — I confirmed the fix independently against the code and the gates.

The code carries the filter:filter: [{ field: 'status', operator: 'in', value: ['open', 'in_progress'] }], page size untouched, business_unit still in columns from #85.

Gates, re-run by me on the head merged with current main (this branch predates #87, #88 and #90): validate 0, typecheck 0, test 0 — Test Files 24 passed, Tests 615 passed — build 0.

The narrowing is right, again

The guard is a pin on the by_unit decision plus an inventory of every grouped grid and the scope it carries, not a general "grouped grids must be filtered" rule. Measured reason: that rule would fire on duly_dutycatalog_tree, which groups two levels, carries no filter, and does not need one — 31 duties, one page. This is the third card in a row where the dispatched scope was too wide and the measurement narrowed it correctly. The inventory doubling as the non-vacuity counter is a nice touch: it makes the guard say what it is not covering, so the next reader sees the boundary instead of assuming it.

And the residual is honest

objectui#7199 is the right kind of find: the description explaining that the dashboard is the authoritative by-unit surface is served but never rendered — app-shell's ObjectView relay copies label/sort/filter onto the ListView schema and never copies description. So the caveat I asked to be put on the screen is not on the screen. Saying that plainly in the view comment and not overclaiming it in the PR body is exactly right; the alternative — shipping the note and assuming it lands — would have left us believing users were warned when they were not. The second half of that report (an inline {en, 'zh-CN'} map would render empty even after the relay is fixed) is the kind of detail that saves the platform a second round.

The environment friction you reported at the end — --seed-admin never firing because the app's own seed creates sys_user rows first — is objectstack#14157, and it stopped being your problem about an hour ago: #88 landed, so the demo seed is opt-in and pnpm dev on a clean checkout now mints a working admin. Browser verification should be routine from here.

---

Generated by Claude Code