Fetch the fields the grouped grids group by, and guard it

[os-warren]

Fixes#76

Both grouped grids bucketed by a field they never fetched. by_unit rendered one(empty) group holding all 186 rows; duty's grouped lens collapsed on both levels. The rows were right, nothing errored, and all four gates were green.

Cause, re-measured on this branch's own boot

The grid builds its query projection from columnsalone. Captured off the page load at 19a0306:

GET /api/v1/data/duly_task?select=id,subject,status,due_date,period_key,owner,source
→ business_unit: undefined (on all 186 rows)

business_unit was the grouping field and not a column, so it was never requested, so buildSegmentLabel took its first line — if (value === undefined || …) return '(empty)' — for every row. Read off the shipped console bundle, $select is [id, ...columns, ...fields referenced by action / conditional-formatting predicates]; grouping is not in that union.

Upstream: objectstack-ai/objectui#7179 — the projection should union the grouping fields rather than making authors mirror them in columns. Not waiting on it, and this is not a wart: on a by-X view the X column is worth showing anyway.

1. The views

• task.view.ts › by_unit — the shared six plusbusiness_unit ([...columns, …], the same idiom stalled already uses). The other five task lenses keep the shared const untouched.
• duty.view.ts › catalog_tree — its own list gains business_unit and owner, listed in the grouping's own order so the row reads the way the hierarchy nests.

2. The guard — the actual deliverable

test/metadata-bindings.test.ts gains a second, independent stopgap, deleted when objectui#7179 lands and not with the reference walk above it (that one goes with objectstack#14105 / #14107 / #14108).

Why the existing guard could not catch this: it resolves business_unit against duly_task's schema and it resolves — a real, populated, correctly-typed lookup. Every binding was valid. The defect is a relationship between two config keys, not a dangling reference.

Proven red first. On 19a0306 with the views unfixed, npx vitest run test/metadata-bindings.test.ts exited 1:

AssertionError: a grouped grid buckets rows by a field its `columns` do not carry …
+ "view duly_task › listViews.by_unit · grouping.fields[0].field groups by \"business_unit\",
columns: subject, status, due_date, period_key, owner, source"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[0].field groups by \"business_unit\", …"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[1].field groups by \"owner\", …"

The transcript is recorded in the test's own comment, and synthetic fixtures pin both directions permanently (fires / does not fire, multi-level, bare-string column shorthand).

One measured deviation from the card's scope

The card asks the guard to cover kanban-grouping too, on the reading that the kanban board is "fine by luck" because its group field happens to be displayed. It is not luck, and status is not one of the board's columns. Ablated against a booted app one leg at a time, each mutation confirmed on disk and reverted through a restore trap:

leg	mutation	resulting select
A	board kanban.groupByField → business_unit	…,source,business_unit,status
B	A + business_unit added to kanban.columns	unchanged from A
C	schedule gantt.groupByField → business_unit	…,due_date,business_unit
D	recent gains timeline.groupByField: business_unit	…,business_unit,due_date

So kanban / gantt / timelinegroupByField are each unioned into the projection by their own adapter — the grid's grouping block is the one that is not, which is exactly the gap objectui#7179 names. The guard therefore covers grouping.fields[] only; widening it to three keys that measurably work would be the same mistake the card warns against for sort. The other group keys are still inventoried by the walk, so adding one fails a tripwire and lands in front of a human. Legs A/B also pin where a field must go: kanban.columns is the card face (cardFields), never the projection.

3. sort — left alone, as instructed

No measurement showed a sort failing, and sorting is applied server-side ($orderby in the same request), so a sort field outside columns is a different mechanism. Not touched, not guarded.

Browser verification

objectstack dev on port 3100 from this worktree, #75 seed (186 tasks, 31 duties, 5 business units), logged in as admin.

Before — one (empty) bucket holding every row:

After — by_unit, one group per unit, counts 33 + 3 + 46 + 18 = 100 = the visible row total (the seed's fifth unit has no rows on page 1 of 100):

After — duty's lens grouping on both levels (Ardenline Group → Nadia Ilves, Northgate Operations → Marek Dvorak 2 / Sami Okonkwo 3):

Post-fix requests: select=id,subject,status,due_date,period_key,owner,source,business_unit and select=id,name,form,frequency,business_unit,owner,source,status. Zero (empty) labels on either lens, no console errors, no 4xx.

The screenshots live on the throwaway branch claude/issue-76-evidence so no binaries enter this diff or main — delete it whenever.

Gates

All four green at df6b114 (this PR's head):

pnpm validate exit 0 ⚠ one expected warning: hierarchy-security is enterprise-edition (AGENTS.md rule 7)
pnpm typecheck exit 0
pnpm test exit 0 20 files, 545 tests
pnpm build exit 0 dist/objectstack.json 276.2 KB

No changeset: this repo has no .changeset/ directory in git log --all, no @changesets/* dependency and no changeset script — creating one would mint a mechanism nothing here reads.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The deviation from my scope is a correction to my card, and it is right.

Gates, re-run by me on df6b114 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 20 passed, Tests 545 passed), build 0.

I wrote in scope item 2 that "the kanban groupByFields are fine by luck: status (board) and owner (assignments) both happen to be displayed columns." That was wrong on both halves — status is not one of the board's columns, and they are not fine by luck. Four browser ablation legs with the captured select= string in each show kanban, gantt and timeline each union their groupByField into the projection through their own adapter, needing no column at all; leg B further shows kanban.columns is the card face and has nothing to do with the fetch.

So the grid's grouping block is the only projection-blind path. Scoping the guard to grouping.fields[] and inventorying the other three behind a tripwire is exactly right: widening it would have made it fire on views that measurably work, which is the mistake item 3 warns about one paragraph earlier. Good catch that my own card contained the error item 3 was written to prevent.

Two more things worth recording:

• Red-first was proven on 19a0306, not asserted — expected [ …(3) ] to deeply equal [] naming by_unit grouping.fields[0] and catalog_tree grouping.fields[0] and [1], with the other 42 tests in the file still passing so only the new assertion moved. And the guard is filed for deletion against objectui#7179, not against the #14105/#14107/#14108 walk — two stopgaps with different expiry dates, correctly kept apart.
• The browser acceptance is the real proof. Before: by_unit one (empty) group holding all 186 rows, catalog_tree(empty) nested inside (empty). After: Northgate Operations 33 / Northgate Plant 3 / Northgate Quality 46 / Riverside Plant 18, each labelled with the unit's name, and catalog_tree grouping on both levels. Screenshots kept on a throwaway branch so no binaries enter the diff — the right call.

I have posted your kanban/gantt/timeline measurement to objectui#7179, since I had told the platform team those were worth checking and you have now checked them.

#86 (page-scoped group counts) is a real finding and correctly out of scope here — this card's own acceptance treated the counts as page-scoped, so fixing it would have been scope creep. Triaging it separately.

---

Generated by Claude Code

[os-warren]

Fixes#76

Both grouped grids bucketed by a field they never fetched. by_unit rendered one(empty) group holding all 186 rows; duty's grouped lens collapsed on both levels. The rows were right, nothing errored, and all four gates were green.

Cause, re-measured on this branch's own boot

The grid builds its query projection from columnsalone. Captured off the page load at 19a0306:

GET /api/v1/data/duly_task?select=id,subject,status,due_date,period_key,owner,source
→ business_unit: undefined (on all 186 rows)

business_unit was the grouping field and not a column, so it was never requested, so buildSegmentLabel took its first line — if (value === undefined || …) return '(empty)' — for every row. Read off the shipped console bundle, $select is [id, ...columns, ...fields referenced by action / conditional-formatting predicates]; grouping is not in that union.

Upstream: objectstack-ai/objectui#7179 — the projection should union the grouping fields rather than making authors mirror them in columns. Not waiting on it, and this is not a wart: on a by-X view the X column is worth showing anyway.

1. The views

• task.view.ts › by_unit — the shared six plusbusiness_unit ([...columns, …], the same idiom stalled already uses). The other five task lenses keep the shared const untouched.
• duty.view.ts › catalog_tree — its own list gains business_unit and owner, listed in the grouping's own order so the row reads the way the hierarchy nests.

2. The guard — the actual deliverable

test/metadata-bindings.test.ts gains a second, independent stopgap, deleted when objectui#7179 lands and not with the reference walk above it (that one goes with objectstack#14105 / #14107 / #14108).

Why the existing guard could not catch this: it resolves business_unit against duly_task's schema and it resolves — a real, populated, correctly-typed lookup. Every binding was valid. The defect is a relationship between two config keys, not a dangling reference.

Proven red first. On 19a0306 with the views unfixed, npx vitest run test/metadata-bindings.test.ts exited 1:

AssertionError: a grouped grid buckets rows by a field its `columns` do not carry …
+ "view duly_task › listViews.by_unit · grouping.fields[0].field groups by \"business_unit\",
columns: subject, status, due_date, period_key, owner, source"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[0].field groups by \"business_unit\", …"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[1].field groups by \"owner\", …"

The transcript is recorded in the test's own comment, and synthetic fixtures pin both directions permanently (fires / does not fire, multi-level, bare-string column shorthand).

One measured deviation from the card's scope

The card asks the guard to cover kanban-grouping too, on the reading that the kanban board is "fine by luck" because its group field happens to be displayed. It is not luck, and status is not one of the board's columns. Ablated against a booted app one leg at a time, each mutation confirmed on disk and reverted through a restore trap:

leg	mutation	resulting select
A	board kanban.groupByField → business_unit	…,source,business_unit,status
B	A + business_unit added to kanban.columns	unchanged from A
C	schedule gantt.groupByField → business_unit	…,due_date,business_unit
D	recent gains timeline.groupByField: business_unit	…,business_unit,due_date

So kanban / gantt / timelinegroupByField are each unioned into the projection by their own adapter — the grid's grouping block is the one that is not, which is exactly the gap objectui#7179 names. The guard therefore covers grouping.fields[] only; widening it to three keys that measurably work would be the same mistake the card warns against for sort. The other group keys are still inventoried by the walk, so adding one fails a tripwire and lands in front of a human. Legs A/B also pin where a field must go: kanban.columns is the card face (cardFields), never the projection.

3. sort — left alone, as instructed

No measurement showed a sort failing, and sorting is applied server-side ($orderby in the same request), so a sort field outside columns is a different mechanism. Not touched, not guarded.

Browser verification

objectstack dev on port 3100 from this worktree, #75 seed (186 tasks, 31 duties, 5 business units), logged in as admin.

Before — one (empty) bucket holding every row:

After — by_unit, one group per unit, counts 33 + 3 + 46 + 18 = 100 = the visible row total (the seed's fifth unit has no rows on page 1 of 100):

After — duty's lens grouping on both levels (Ardenline Group → Nadia Ilves, Northgate Operations → Marek Dvorak 2 / Sami Okonkwo 3):

Post-fix requests: select=id,subject,status,due_date,period_key,owner,source,business_unit and select=id,name,form,frequency,business_unit,owner,source,status. Zero (empty) labels on either lens, no console errors, no 4xx.

The screenshots live on the throwaway branch claude/issue-76-evidence so no binaries enter this diff or main — delete it whenever.

Gates

All four green at df6b114 (this PR's head):

pnpm validate exit 0 ⚠ one expected warning: hierarchy-security is enterprise-edition (AGENTS.md rule 7)
pnpm typecheck exit 0
pnpm test exit 0 20 files, 545 tests
pnpm build exit 0 dist/objectstack.json 276.2 KB

No changeset: this repo has no .changeset/ directory in git log --all, no @changesets/* dependency and no changeset script — creating one would mint a mechanism nothing here reads.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The deviation from my scope is a correction to my card, and it is right.

Gates, re-run by me on df6b114 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 20 passed, Tests 545 passed), build 0.

I wrote in scope item 2 that "the kanban groupByFields are fine by luck: status (board) and owner (assignments) both happen to be displayed columns." That was wrong on both halves — status is not one of the board's columns, and they are not fine by luck. Four browser ablation legs with the captured select= string in each show kanban, gantt and timeline each union their groupByField into the projection through their own adapter, needing no column at all; leg B further shows kanban.columns is the card face and has nothing to do with the fetch.

So the grid's grouping block is the only projection-blind path. Scoping the guard to grouping.fields[] and inventorying the other three behind a tripwire is exactly right: widening it would have made it fire on views that measurably work, which is the mistake item 3 warns about one paragraph earlier. Good catch that my own card contained the error item 3 was written to prevent.

Two more things worth recording:

• Red-first was proven on 19a0306, not asserted — expected [ …(3) ] to deeply equal [] naming by_unit grouping.fields[0] and catalog_tree grouping.fields[0] and [1], with the other 42 tests in the file still passing so only the new assertion moved. And the guard is filed for deletion against objectui#7179, not against the #14105/#14107/#14108 walk — two stopgaps with different expiry dates, correctly kept apart.
• The browser acceptance is the real proof. Before: by_unit one (empty) group holding all 186 rows, catalog_tree(empty) nested inside (empty). After: Northgate Operations 33 / Northgate Plant 3 / Northgate Quality 46 / Riverside Plant 18, each labelled with the unit's name, and catalog_tree grouping on both levels. Screenshots kept on a throwaway branch so no binaries enter the diff — the right call.

I have posted your kanban/gantt/timeline measurement to objectui#7179, since I had told the platform team those were worth checking and you have now checked them.

#86 (page-scoped group counts) is a real finding and correctly out of scope here — this card's own acceptance treated the counts as page-scoped, so fixing it would have been scope creep. Triaging it separately.

---

Generated by Claude Code

[os-warren]

Fixes#76

Both grouped grids bucketed by a field they never fetched. by_unit rendered one(empty) group holding all 186 rows; duty's grouped lens collapsed on both levels. The rows were right, nothing errored, and all four gates were green.

Cause, re-measured on this branch's own boot

The grid builds its query projection from columnsalone. Captured off the page load at 19a0306:

GET /api/v1/data/duly_task?select=id,subject,status,due_date,period_key,owner,source
→ business_unit: undefined (on all 186 rows)

business_unit was the grouping field and not a column, so it was never requested, so buildSegmentLabel took its first line — if (value === undefined || …) return '(empty)' — for every row. Read off the shipped console bundle, $select is [id, ...columns, ...fields referenced by action / conditional-formatting predicates]; grouping is not in that union.

Upstream: objectstack-ai/objectui#7179 — the projection should union the grouping fields rather than making authors mirror them in columns. Not waiting on it, and this is not a wart: on a by-X view the X column is worth showing anyway.

1. The views

• task.view.ts › by_unit — the shared six plusbusiness_unit ([...columns, …], the same idiom stalled already uses). The other five task lenses keep the shared const untouched.
• duty.view.ts › catalog_tree — its own list gains business_unit and owner, listed in the grouping's own order so the row reads the way the hierarchy nests.

2. The guard — the actual deliverable

test/metadata-bindings.test.ts gains a second, independent stopgap, deleted when objectui#7179 lands and not with the reference walk above it (that one goes with objectstack#14105 / #14107 / #14108).

Why the existing guard could not catch this: it resolves business_unit against duly_task's schema and it resolves — a real, populated, correctly-typed lookup. Every binding was valid. The defect is a relationship between two config keys, not a dangling reference.

Proven red first. On 19a0306 with the views unfixed, npx vitest run test/metadata-bindings.test.ts exited 1:

AssertionError: a grouped grid buckets rows by a field its `columns` do not carry …
+ "view duly_task › listViews.by_unit · grouping.fields[0].field groups by \"business_unit\",
columns: subject, status, due_date, period_key, owner, source"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[0].field groups by \"business_unit\", …"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[1].field groups by \"owner\", …"

The transcript is recorded in the test's own comment, and synthetic fixtures pin both directions permanently (fires / does not fire, multi-level, bare-string column shorthand).

One measured deviation from the card's scope

The card asks the guard to cover kanban-grouping too, on the reading that the kanban board is "fine by luck" because its group field happens to be displayed. It is not luck, and status is not one of the board's columns. Ablated against a booted app one leg at a time, each mutation confirmed on disk and reverted through a restore trap:

leg	mutation	resulting select
A	board kanban.groupByField → business_unit	…,source,business_unit,status
B	A + business_unit added to kanban.columns	unchanged from A
C	schedule gantt.groupByField → business_unit	…,due_date,business_unit
D	recent gains timeline.groupByField: business_unit	…,business_unit,due_date

So kanban / gantt / timelinegroupByField are each unioned into the projection by their own adapter — the grid's grouping block is the one that is not, which is exactly the gap objectui#7179 names. The guard therefore covers grouping.fields[] only; widening it to three keys that measurably work would be the same mistake the card warns against for sort. The other group keys are still inventoried by the walk, so adding one fails a tripwire and lands in front of a human. Legs A/B also pin where a field must go: kanban.columns is the card face (cardFields), never the projection.

3. sort — left alone, as instructed

No measurement showed a sort failing, and sorting is applied server-side ($orderby in the same request), so a sort field outside columns is a different mechanism. Not touched, not guarded.

Browser verification

objectstack dev on port 3100 from this worktree, #75 seed (186 tasks, 31 duties, 5 business units), logged in as admin.

Before — one (empty) bucket holding every row:

After — by_unit, one group per unit, counts 33 + 3 + 46 + 18 = 100 = the visible row total (the seed's fifth unit has no rows on page 1 of 100):

After — duty's lens grouping on both levels (Ardenline Group → Nadia Ilves, Northgate Operations → Marek Dvorak 2 / Sami Okonkwo 3):

Post-fix requests: select=id,subject,status,due_date,period_key,owner,source,business_unit and select=id,name,form,frequency,business_unit,owner,source,status. Zero (empty) labels on either lens, no console errors, no 4xx.

The screenshots live on the throwaway branch claude/issue-76-evidence so no binaries enter this diff or main — delete it whenever.

Gates

All four green at df6b114 (this PR's head):

pnpm validate exit 0 ⚠ one expected warning: hierarchy-security is enterprise-edition (AGENTS.md rule 7)
pnpm typecheck exit 0
pnpm test exit 0 20 files, 545 tests
pnpm build exit 0 dist/objectstack.json 276.2 KB

No changeset: this repo has no .changeset/ directory in git log --all, no @changesets/* dependency and no changeset script — creating one would mint a mechanism nothing here reads.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The deviation from my scope is a correction to my card, and it is right.

Gates, re-run by me on df6b114 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 20 passed, Tests 545 passed), build 0.

I wrote in scope item 2 that "the kanban groupByFields are fine by luck: status (board) and owner (assignments) both happen to be displayed columns." That was wrong on both halves — status is not one of the board's columns, and they are not fine by luck. Four browser ablation legs with the captured select= string in each show kanban, gantt and timeline each union their groupByField into the projection through their own adapter, needing no column at all; leg B further shows kanban.columns is the card face and has nothing to do with the fetch.

So the grid's grouping block is the only projection-blind path. Scoping the guard to grouping.fields[] and inventorying the other three behind a tripwire is exactly right: widening it would have made it fire on views that measurably work, which is the mistake item 3 warns about one paragraph earlier. Good catch that my own card contained the error item 3 was written to prevent.

Two more things worth recording:

• Red-first was proven on 19a0306, not asserted — expected [ …(3) ] to deeply equal [] naming by_unit grouping.fields[0] and catalog_tree grouping.fields[0] and [1], with the other 42 tests in the file still passing so only the new assertion moved. And the guard is filed for deletion against objectui#7179, not against the #14105/#14107/#14108 walk — two stopgaps with different expiry dates, correctly kept apart.
• The browser acceptance is the real proof. Before: by_unit one (empty) group holding all 186 rows, catalog_tree(empty) nested inside (empty). After: Northgate Operations 33 / Northgate Plant 3 / Northgate Quality 46 / Riverside Plant 18, each labelled with the unit's name, and catalog_tree grouping on both levels. Screenshots kept on a throwaway branch so no binaries enter the diff — the right call.

I have posted your kanban/gantt/timeline measurement to objectui#7179, since I had told the platform team those were worth checking and you have now checked them.

#86 (page-scoped group counts) is a real finding and correctly out of scope here — this card's own acceptance treated the counts as page-scoped, so fixing it would have been scope creep. Triaging it separately.

---

Generated by Claude Code

[os-warren]

Fixes#76

Both grouped grids bucketed by a field they never fetched. by_unit rendered one(empty) group holding all 186 rows; duty's grouped lens collapsed on both levels. The rows were right, nothing errored, and all four gates were green.

Cause, re-measured on this branch's own boot

The grid builds its query projection from columnsalone. Captured off the page load at 19a0306:

GET /api/v1/data/duly_task?select=id,subject,status,due_date,period_key,owner,source
→ business_unit: undefined (on all 186 rows)

business_unit was the grouping field and not a column, so it was never requested, so buildSegmentLabel took its first line — if (value === undefined || …) return '(empty)' — for every row. Read off the shipped console bundle, $select is [id, ...columns, ...fields referenced by action / conditional-formatting predicates]; grouping is not in that union.

Upstream: objectstack-ai/objectui#7179 — the projection should union the grouping fields rather than making authors mirror them in columns. Not waiting on it, and this is not a wart: on a by-X view the X column is worth showing anyway.

1. The views

• task.view.ts › by_unit — the shared six plusbusiness_unit ([...columns, …], the same idiom stalled already uses). The other five task lenses keep the shared const untouched.
• duty.view.ts › catalog_tree — its own list gains business_unit and owner, listed in the grouping's own order so the row reads the way the hierarchy nests.

2. The guard — the actual deliverable

test/metadata-bindings.test.ts gains a second, independent stopgap, deleted when objectui#7179 lands and not with the reference walk above it (that one goes with objectstack#14105 / #14107 / #14108).

Why the existing guard could not catch this: it resolves business_unit against duly_task's schema and it resolves — a real, populated, correctly-typed lookup. Every binding was valid. The defect is a relationship between two config keys, not a dangling reference.

Proven red first. On 19a0306 with the views unfixed, npx vitest run test/metadata-bindings.test.ts exited 1:

AssertionError: a grouped grid buckets rows by a field its `columns` do not carry …
+ "view duly_task › listViews.by_unit · grouping.fields[0].field groups by \"business_unit\",
columns: subject, status, due_date, period_key, owner, source"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[0].field groups by \"business_unit\", …"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[1].field groups by \"owner\", …"

The transcript is recorded in the test's own comment, and synthetic fixtures pin both directions permanently (fires / does not fire, multi-level, bare-string column shorthand).

One measured deviation from the card's scope

The card asks the guard to cover kanban-grouping too, on the reading that the kanban board is "fine by luck" because its group field happens to be displayed. It is not luck, and status is not one of the board's columns. Ablated against a booted app one leg at a time, each mutation confirmed on disk and reverted through a restore trap:

leg	mutation	resulting select
A	board kanban.groupByField → business_unit	…,source,business_unit,status
B	A + business_unit added to kanban.columns	unchanged from A
C	schedule gantt.groupByField → business_unit	…,due_date,business_unit
D	recent gains timeline.groupByField: business_unit	…,business_unit,due_date

So kanban / gantt / timelinegroupByField are each unioned into the projection by their own adapter — the grid's grouping block is the one that is not, which is exactly the gap objectui#7179 names. The guard therefore covers grouping.fields[] only; widening it to three keys that measurably work would be the same mistake the card warns against for sort. The other group keys are still inventoried by the walk, so adding one fails a tripwire and lands in front of a human. Legs A/B also pin where a field must go: kanban.columns is the card face (cardFields), never the projection.

3. sort — left alone, as instructed

No measurement showed a sort failing, and sorting is applied server-side ($orderby in the same request), so a sort field outside columns is a different mechanism. Not touched, not guarded.

Browser verification

objectstack dev on port 3100 from this worktree, #75 seed (186 tasks, 31 duties, 5 business units), logged in as admin.

Before — one (empty) bucket holding every row:

After — by_unit, one group per unit, counts 33 + 3 + 46 + 18 = 100 = the visible row total (the seed's fifth unit has no rows on page 1 of 100):

After — duty's lens grouping on both levels (Ardenline Group → Nadia Ilves, Northgate Operations → Marek Dvorak 2 / Sami Okonkwo 3):

Post-fix requests: select=id,subject,status,due_date,period_key,owner,source,business_unit and select=id,name,form,frequency,business_unit,owner,source,status. Zero (empty) labels on either lens, no console errors, no 4xx.

The screenshots live on the throwaway branch claude/issue-76-evidence so no binaries enter this diff or main — delete it whenever.

Gates

All four green at df6b114 (this PR's head):

pnpm validate exit 0 ⚠ one expected warning: hierarchy-security is enterprise-edition (AGENTS.md rule 7)
pnpm typecheck exit 0
pnpm test exit 0 20 files, 545 tests
pnpm build exit 0 dist/objectstack.json 276.2 KB

No changeset: this repo has no .changeset/ directory in git log --all, no @changesets/* dependency and no changeset script — creating one would mint a mechanism nothing here reads.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The deviation from my scope is a correction to my card, and it is right.

Gates, re-run by me on df6b114 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 20 passed, Tests 545 passed), build 0.

I wrote in scope item 2 that "the kanban groupByFields are fine by luck: status (board) and owner (assignments) both happen to be displayed columns." That was wrong on both halves — status is not one of the board's columns, and they are not fine by luck. Four browser ablation legs with the captured select= string in each show kanban, gantt and timeline each union their groupByField into the projection through their own adapter, needing no column at all; leg B further shows kanban.columns is the card face and has nothing to do with the fetch.

So the grid's grouping block is the only projection-blind path. Scoping the guard to grouping.fields[] and inventorying the other three behind a tripwire is exactly right: widening it would have made it fire on views that measurably work, which is the mistake item 3 warns about one paragraph earlier. Good catch that my own card contained the error item 3 was written to prevent.

Two more things worth recording:

• Red-first was proven on 19a0306, not asserted — expected [ …(3) ] to deeply equal [] naming by_unit grouping.fields[0] and catalog_tree grouping.fields[0] and [1], with the other 42 tests in the file still passing so only the new assertion moved. And the guard is filed for deletion against objectui#7179, not against the #14105/#14107/#14108 walk — two stopgaps with different expiry dates, correctly kept apart.
• The browser acceptance is the real proof. Before: by_unit one (empty) group holding all 186 rows, catalog_tree(empty) nested inside (empty). After: Northgate Operations 33 / Northgate Plant 3 / Northgate Quality 46 / Riverside Plant 18, each labelled with the unit's name, and catalog_tree grouping on both levels. Screenshots kept on a throwaway branch so no binaries enter the diff — the right call.

I have posted your kanban/gantt/timeline measurement to objectui#7179, since I had told the platform team those were worth checking and you have now checked them.

#86 (page-scoped group counts) is a real finding and correctly out of scope here — this card's own acceptance treated the counts as page-scoped, so fixing it would have been scope creep. Triaging it separately.

---

Generated by Claude Code

[os-warren]

Fixes#76

Both grouped grids bucketed by a field they never fetched. by_unit rendered one(empty) group holding all 186 rows; duty's grouped lens collapsed on both levels. The rows were right, nothing errored, and all four gates were green.

Cause, re-measured on this branch's own boot

The grid builds its query projection from columnsalone. Captured off the page load at 19a0306:

GET /api/v1/data/duly_task?select=id,subject,status,due_date,period_key,owner,source
→ business_unit: undefined (on all 186 rows)

business_unit was the grouping field and not a column, so it was never requested, so buildSegmentLabel took its first line — if (value === undefined || …) return '(empty)' — for every row. Read off the shipped console bundle, $select is [id, ...columns, ...fields referenced by action / conditional-formatting predicates]; grouping is not in that union.

Upstream: objectstack-ai/objectui#7179 — the projection should union the grouping fields rather than making authors mirror them in columns. Not waiting on it, and this is not a wart: on a by-X view the X column is worth showing anyway.

1. The views

• task.view.ts › by_unit — the shared six plusbusiness_unit ([...columns, …], the same idiom stalled already uses). The other five task lenses keep the shared const untouched.
• duty.view.ts › catalog_tree — its own list gains business_unit and owner, listed in the grouping's own order so the row reads the way the hierarchy nests.

2. The guard — the actual deliverable

test/metadata-bindings.test.ts gains a second, independent stopgap, deleted when objectui#7179 lands and not with the reference walk above it (that one goes with objectstack#14105 / #14107 / #14108).

Why the existing guard could not catch this: it resolves business_unit against duly_task's schema and it resolves — a real, populated, correctly-typed lookup. Every binding was valid. The defect is a relationship between two config keys, not a dangling reference.

Proven red first. On 19a0306 with the views unfixed, npx vitest run test/metadata-bindings.test.ts exited 1:

AssertionError: a grouped grid buckets rows by a field its `columns` do not carry …
+ "view duly_task › listViews.by_unit · grouping.fields[0].field groups by \"business_unit\",
columns: subject, status, due_date, period_key, owner, source"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[0].field groups by \"business_unit\", …"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[1].field groups by \"owner\", …"

The transcript is recorded in the test's own comment, and synthetic fixtures pin both directions permanently (fires / does not fire, multi-level, bare-string column shorthand).

One measured deviation from the card's scope

The card asks the guard to cover kanban-grouping too, on the reading that the kanban board is "fine by luck" because its group field happens to be displayed. It is not luck, and status is not one of the board's columns. Ablated against a booted app one leg at a time, each mutation confirmed on disk and reverted through a restore trap:

leg	mutation	resulting select
A	board kanban.groupByField → business_unit	…,source,business_unit,status
B	A + business_unit added to kanban.columns	unchanged from A
C	schedule gantt.groupByField → business_unit	…,due_date,business_unit
D	recent gains timeline.groupByField: business_unit	…,business_unit,due_date

So kanban / gantt / timelinegroupByField are each unioned into the projection by their own adapter — the grid's grouping block is the one that is not, which is exactly the gap objectui#7179 names. The guard therefore covers grouping.fields[] only; widening it to three keys that measurably work would be the same mistake the card warns against for sort. The other group keys are still inventoried by the walk, so adding one fails a tripwire and lands in front of a human. Legs A/B also pin where a field must go: kanban.columns is the card face (cardFields), never the projection.

3. sort — left alone, as instructed

No measurement showed a sort failing, and sorting is applied server-side ($orderby in the same request), so a sort field outside columns is a different mechanism. Not touched, not guarded.

Browser verification

objectstack dev on port 3100 from this worktree, #75 seed (186 tasks, 31 duties, 5 business units), logged in as admin.

Before — one (empty) bucket holding every row:

After — by_unit, one group per unit, counts 33 + 3 + 46 + 18 = 100 = the visible row total (the seed's fifth unit has no rows on page 1 of 100):

After — duty's lens grouping on both levels (Ardenline Group → Nadia Ilves, Northgate Operations → Marek Dvorak 2 / Sami Okonkwo 3):

Post-fix requests: select=id,subject,status,due_date,period_key,owner,source,business_unit and select=id,name,form,frequency,business_unit,owner,source,status. Zero (empty) labels on either lens, no console errors, no 4xx.

The screenshots live on the throwaway branch claude/issue-76-evidence so no binaries enter this diff or main — delete it whenever.

Gates

All four green at df6b114 (this PR's head):

pnpm validate exit 0 ⚠ one expected warning: hierarchy-security is enterprise-edition (AGENTS.md rule 7)
pnpm typecheck exit 0
pnpm test exit 0 20 files, 545 tests
pnpm build exit 0 dist/objectstack.json 276.2 KB

No changeset: this repo has no .changeset/ directory in git log --all, no @changesets/* dependency and no changeset script — creating one would mint a mechanism nothing here reads.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The deviation from my scope is a correction to my card, and it is right.

Gates, re-run by me on df6b114 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 20 passed, Tests 545 passed), build 0.

I wrote in scope item 2 that "the kanban groupByFields are fine by luck: status (board) and owner (assignments) both happen to be displayed columns." That was wrong on both halves — status is not one of the board's columns, and they are not fine by luck. Four browser ablation legs with the captured select= string in each show kanban, gantt and timeline each union their groupByField into the projection through their own adapter, needing no column at all; leg B further shows kanban.columns is the card face and has nothing to do with the fetch.

So the grid's grouping block is the only projection-blind path. Scoping the guard to grouping.fields[] and inventorying the other three behind a tripwire is exactly right: widening it would have made it fire on views that measurably work, which is the mistake item 3 warns about one paragraph earlier. Good catch that my own card contained the error item 3 was written to prevent.

Two more things worth recording:

• Red-first was proven on 19a0306, not asserted — expected [ …(3) ] to deeply equal [] naming by_unit grouping.fields[0] and catalog_tree grouping.fields[0] and [1], with the other 42 tests in the file still passing so only the new assertion moved. And the guard is filed for deletion against objectui#7179, not against the #14105/#14107/#14108 walk — two stopgaps with different expiry dates, correctly kept apart.
• The browser acceptance is the real proof. Before: by_unit one (empty) group holding all 186 rows, catalog_tree(empty) nested inside (empty). After: Northgate Operations 33 / Northgate Plant 3 / Northgate Quality 46 / Riverside Plant 18, each labelled with the unit's name, and catalog_tree grouping on both levels. Screenshots kept on a throwaway branch so no binaries enter the diff — the right call.

I have posted your kanban/gantt/timeline measurement to objectui#7179, since I had told the platform team those were worth checking and you have now checked them.

#86 (page-scoped group counts) is a real finding and correctly out of scope here — this card's own acceptance treated the counts as page-scoped, so fixing it would have been scope creep. Triaging it separately.

---

Generated by Claude Code

[os-warren]

Fixes#76

Both grouped grids bucketed by a field they never fetched. by_unit rendered one(empty) group holding all 186 rows; duty's grouped lens collapsed on both levels. The rows were right, nothing errored, and all four gates were green.

Cause, re-measured on this branch's own boot

The grid builds its query projection from columnsalone. Captured off the page load at 19a0306:

GET /api/v1/data/duly_task?select=id,subject,status,due_date,period_key,owner,source
→ business_unit: undefined (on all 186 rows)

business_unit was the grouping field and not a column, so it was never requested, so buildSegmentLabel took its first line — if (value === undefined || …) return '(empty)' — for every row. Read off the shipped console bundle, $select is [id, ...columns, ...fields referenced by action / conditional-formatting predicates]; grouping is not in that union.

Upstream: objectstack-ai/objectui#7179 — the projection should union the grouping fields rather than making authors mirror them in columns. Not waiting on it, and this is not a wart: on a by-X view the X column is worth showing anyway.

1. The views

• task.view.ts › by_unit — the shared six plusbusiness_unit ([...columns, …], the same idiom stalled already uses). The other five task lenses keep the shared const untouched.
• duty.view.ts › catalog_tree — its own list gains business_unit and owner, listed in the grouping's own order so the row reads the way the hierarchy nests.

2. The guard — the actual deliverable

test/metadata-bindings.test.ts gains a second, independent stopgap, deleted when objectui#7179 lands and not with the reference walk above it (that one goes with objectstack#14105 / #14107 / #14108).

Why the existing guard could not catch this: it resolves business_unit against duly_task's schema and it resolves — a real, populated, correctly-typed lookup. Every binding was valid. The defect is a relationship between two config keys, not a dangling reference.

Proven red first. On 19a0306 with the views unfixed, npx vitest run test/metadata-bindings.test.ts exited 1:

AssertionError: a grouped grid buckets rows by a field its `columns` do not carry …
+ "view duly_task › listViews.by_unit · grouping.fields[0].field groups by \"business_unit\",
columns: subject, status, due_date, period_key, owner, source"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[0].field groups by \"business_unit\", …"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[1].field groups by \"owner\", …"

The transcript is recorded in the test's own comment, and synthetic fixtures pin both directions permanently (fires / does not fire, multi-level, bare-string column shorthand).

One measured deviation from the card's scope

The card asks the guard to cover kanban-grouping too, on the reading that the kanban board is "fine by luck" because its group field happens to be displayed. It is not luck, and status is not one of the board's columns. Ablated against a booted app one leg at a time, each mutation confirmed on disk and reverted through a restore trap:

leg	mutation	resulting select
A	board kanban.groupByField → business_unit	…,source,business_unit,status
B	A + business_unit added to kanban.columns	unchanged from A
C	schedule gantt.groupByField → business_unit	…,due_date,business_unit
D	recent gains timeline.groupByField: business_unit	…,business_unit,due_date

So kanban / gantt / timelinegroupByField are each unioned into the projection by their own adapter — the grid's grouping block is the one that is not, which is exactly the gap objectui#7179 names. The guard therefore covers grouping.fields[] only; widening it to three keys that measurably work would be the same mistake the card warns against for sort. The other group keys are still inventoried by the walk, so adding one fails a tripwire and lands in front of a human. Legs A/B also pin where a field must go: kanban.columns is the card face (cardFields), never the projection.

3. sort — left alone, as instructed

No measurement showed a sort failing, and sorting is applied server-side ($orderby in the same request), so a sort field outside columns is a different mechanism. Not touched, not guarded.

Browser verification

objectstack dev on port 3100 from this worktree, #75 seed (186 tasks, 31 duties, 5 business units), logged in as admin.

Before — one (empty) bucket holding every row:

After — by_unit, one group per unit, counts 33 + 3 + 46 + 18 = 100 = the visible row total (the seed's fifth unit has no rows on page 1 of 100):

After — duty's lens grouping on both levels (Ardenline Group → Nadia Ilves, Northgate Operations → Marek Dvorak 2 / Sami Okonkwo 3):

Post-fix requests: select=id,subject,status,due_date,period_key,owner,source,business_unit and select=id,name,form,frequency,business_unit,owner,source,status. Zero (empty) labels on either lens, no console errors, no 4xx.

The screenshots live on the throwaway branch claude/issue-76-evidence so no binaries enter this diff or main — delete it whenever.

Gates

All four green at df6b114 (this PR's head):

pnpm validate exit 0 ⚠ one expected warning: hierarchy-security is enterprise-edition (AGENTS.md rule 7)
pnpm typecheck exit 0
pnpm test exit 0 20 files, 545 tests
pnpm build exit 0 dist/objectstack.json 276.2 KB

No changeset: this repo has no .changeset/ directory in git log --all, no @changesets/* dependency and no changeset script — creating one would mint a mechanism nothing here reads.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The deviation from my scope is a correction to my card, and it is right.

Gates, re-run by me on df6b114 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 20 passed, Tests 545 passed), build 0.

I wrote in scope item 2 that "the kanban groupByFields are fine by luck: status (board) and owner (assignments) both happen to be displayed columns." That was wrong on both halves — status is not one of the board's columns, and they are not fine by luck. Four browser ablation legs with the captured select= string in each show kanban, gantt and timeline each union their groupByField into the projection through their own adapter, needing no column at all; leg B further shows kanban.columns is the card face and has nothing to do with the fetch.

So the grid's grouping block is the only projection-blind path. Scoping the guard to grouping.fields[] and inventorying the other three behind a tripwire is exactly right: widening it would have made it fire on views that measurably work, which is the mistake item 3 warns about one paragraph earlier. Good catch that my own card contained the error item 3 was written to prevent.

Two more things worth recording:

• Red-first was proven on 19a0306, not asserted — expected [ …(3) ] to deeply equal [] naming by_unit grouping.fields[0] and catalog_tree grouping.fields[0] and [1], with the other 42 tests in the file still passing so only the new assertion moved. And the guard is filed for deletion against objectui#7179, not against the #14105/#14107/#14108 walk — two stopgaps with different expiry dates, correctly kept apart.
• The browser acceptance is the real proof. Before: by_unit one (empty) group holding all 186 rows, catalog_tree(empty) nested inside (empty). After: Northgate Operations 33 / Northgate Plant 3 / Northgate Quality 46 / Riverside Plant 18, each labelled with the unit's name, and catalog_tree grouping on both levels. Screenshots kept on a throwaway branch so no binaries enter the diff — the right call.

I have posted your kanban/gantt/timeline measurement to objectui#7179, since I had told the platform team those were worth checking and you have now checked them.

#86 (page-scoped group counts) is a real finding and correctly out of scope here — this card's own acceptance treated the counts as page-scoped, so fixing it would have been scope creep. Triaging it separately.

---

Generated by Claude Code

[os-warren]

Fixes#76

Both grouped grids bucketed by a field they never fetched. by_unit rendered one(empty) group holding all 186 rows; duty's grouped lens collapsed on both levels. The rows were right, nothing errored, and all four gates were green.

Cause, re-measured on this branch's own boot

The grid builds its query projection from columnsalone. Captured off the page load at 19a0306:

GET /api/v1/data/duly_task?select=id,subject,status,due_date,period_key,owner,source
→ business_unit: undefined (on all 186 rows)

business_unit was the grouping field and not a column, so it was never requested, so buildSegmentLabel took its first line — if (value === undefined || …) return '(empty)' — for every row. Read off the shipped console bundle, $select is [id, ...columns, ...fields referenced by action / conditional-formatting predicates]; grouping is not in that union.

Upstream: objectstack-ai/objectui#7179 — the projection should union the grouping fields rather than making authors mirror them in columns. Not waiting on it, and this is not a wart: on a by-X view the X column is worth showing anyway.

1. The views

• task.view.ts › by_unit — the shared six plusbusiness_unit ([...columns, …], the same idiom stalled already uses). The other five task lenses keep the shared const untouched.
• duty.view.ts › catalog_tree — its own list gains business_unit and owner, listed in the grouping's own order so the row reads the way the hierarchy nests.

2. The guard — the actual deliverable

test/metadata-bindings.test.ts gains a second, independent stopgap, deleted when objectui#7179 lands and not with the reference walk above it (that one goes with objectstack#14105 / #14107 / #14108).

Why the existing guard could not catch this: it resolves business_unit against duly_task's schema and it resolves — a real, populated, correctly-typed lookup. Every binding was valid. The defect is a relationship between two config keys, not a dangling reference.

Proven red first. On 19a0306 with the views unfixed, npx vitest run test/metadata-bindings.test.ts exited 1:

AssertionError: a grouped grid buckets rows by a field its `columns` do not carry …
+ "view duly_task › listViews.by_unit · grouping.fields[0].field groups by \"business_unit\",
columns: subject, status, due_date, period_key, owner, source"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[0].field groups by \"business_unit\", …"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[1].field groups by \"owner\", …"

The transcript is recorded in the test's own comment, and synthetic fixtures pin both directions permanently (fires / does not fire, multi-level, bare-string column shorthand).

One measured deviation from the card's scope

The card asks the guard to cover kanban-grouping too, on the reading that the kanban board is "fine by luck" because its group field happens to be displayed. It is not luck, and status is not one of the board's columns. Ablated against a booted app one leg at a time, each mutation confirmed on disk and reverted through a restore trap:

leg	mutation	resulting select
A	board kanban.groupByField → business_unit	…,source,business_unit,status
B	A + business_unit added to kanban.columns	unchanged from A
C	schedule gantt.groupByField → business_unit	…,due_date,business_unit
D	recent gains timeline.groupByField: business_unit	…,business_unit,due_date

So kanban / gantt / timelinegroupByField are each unioned into the projection by their own adapter — the grid's grouping block is the one that is not, which is exactly the gap objectui#7179 names. The guard therefore covers grouping.fields[] only; widening it to three keys that measurably work would be the same mistake the card warns against for sort. The other group keys are still inventoried by the walk, so adding one fails a tripwire and lands in front of a human. Legs A/B also pin where a field must go: kanban.columns is the card face (cardFields), never the projection.

3. sort — left alone, as instructed

No measurement showed a sort failing, and sorting is applied server-side ($orderby in the same request), so a sort field outside columns is a different mechanism. Not touched, not guarded.

Browser verification

objectstack dev on port 3100 from this worktree, #75 seed (186 tasks, 31 duties, 5 business units), logged in as admin.

Before — one (empty) bucket holding every row:

After — by_unit, one group per unit, counts 33 + 3 + 46 + 18 = 100 = the visible row total (the seed's fifth unit has no rows on page 1 of 100):

After — duty's lens grouping on both levels (Ardenline Group → Nadia Ilves, Northgate Operations → Marek Dvorak 2 / Sami Okonkwo 3):

Post-fix requests: select=id,subject,status,due_date,period_key,owner,source,business_unit and select=id,name,form,frequency,business_unit,owner,source,status. Zero (empty) labels on either lens, no console errors, no 4xx.

The screenshots live on the throwaway branch claude/issue-76-evidence so no binaries enter this diff or main — delete it whenever.

Gates

All four green at df6b114 (this PR's head):

pnpm validate exit 0 ⚠ one expected warning: hierarchy-security is enterprise-edition (AGENTS.md rule 7)
pnpm typecheck exit 0
pnpm test exit 0 20 files, 545 tests
pnpm build exit 0 dist/objectstack.json 276.2 KB

No changeset: this repo has no .changeset/ directory in git log --all, no @changesets/* dependency and no changeset script — creating one would mint a mechanism nothing here reads.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The deviation from my scope is a correction to my card, and it is right.

Gates, re-run by me on df6b114 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 20 passed, Tests 545 passed), build 0.

I wrote in scope item 2 that "the kanban groupByFields are fine by luck: status (board) and owner (assignments) both happen to be displayed columns." That was wrong on both halves — status is not one of the board's columns, and they are not fine by luck. Four browser ablation legs with the captured select= string in each show kanban, gantt and timeline each union their groupByField into the projection through their own adapter, needing no column at all; leg B further shows kanban.columns is the card face and has nothing to do with the fetch.

So the grid's grouping block is the only projection-blind path. Scoping the guard to grouping.fields[] and inventorying the other three behind a tripwire is exactly right: widening it would have made it fire on views that measurably work, which is the mistake item 3 warns about one paragraph earlier. Good catch that my own card contained the error item 3 was written to prevent.

Two more things worth recording:

• Red-first was proven on 19a0306, not asserted — expected [ …(3) ] to deeply equal [] naming by_unit grouping.fields[0] and catalog_tree grouping.fields[0] and [1], with the other 42 tests in the file still passing so only the new assertion moved. And the guard is filed for deletion against objectui#7179, not against the #14105/#14107/#14108 walk — two stopgaps with different expiry dates, correctly kept apart.
• The browser acceptance is the real proof. Before: by_unit one (empty) group holding all 186 rows, catalog_tree(empty) nested inside (empty). After: Northgate Operations 33 / Northgate Plant 3 / Northgate Quality 46 / Riverside Plant 18, each labelled with the unit's name, and catalog_tree grouping on both levels. Screenshots kept on a throwaway branch so no binaries enter the diff — the right call.

I have posted your kanban/gantt/timeline measurement to objectui#7179, since I had told the platform team those were worth checking and you have now checked them.

#86 (page-scoped group counts) is a real finding and correctly out of scope here — this card's own acceptance treated the counts as page-scoped, so fixing it would have been scope creep. Triaging it separately.

---

Generated by Claude Code

[os-warren]

Fixes#76

Both grouped grids bucketed by a field they never fetched. by_unit rendered one(empty) group holding all 186 rows; duty's grouped lens collapsed on both levels. The rows were right, nothing errored, and all four gates were green.

Cause, re-measured on this branch's own boot

The grid builds its query projection from columnsalone. Captured off the page load at 19a0306:

GET /api/v1/data/duly_task?select=id,subject,status,due_date,period_key,owner,source
→ business_unit: undefined (on all 186 rows)

business_unit was the grouping field and not a column, so it was never requested, so buildSegmentLabel took its first line — if (value === undefined || …) return '(empty)' — for every row. Read off the shipped console bundle, $select is [id, ...columns, ...fields referenced by action / conditional-formatting predicates]; grouping is not in that union.

Upstream: objectstack-ai/objectui#7179 — the projection should union the grouping fields rather than making authors mirror them in columns. Not waiting on it, and this is not a wart: on a by-X view the X column is worth showing anyway.

1. The views

• task.view.ts › by_unit — the shared six plusbusiness_unit ([...columns, …], the same idiom stalled already uses). The other five task lenses keep the shared const untouched.
• duty.view.ts › catalog_tree — its own list gains business_unit and owner, listed in the grouping's own order so the row reads the way the hierarchy nests.

2. The guard — the actual deliverable

test/metadata-bindings.test.ts gains a second, independent stopgap, deleted when objectui#7179 lands and not with the reference walk above it (that one goes with objectstack#14105 / #14107 / #14108).

Why the existing guard could not catch this: it resolves business_unit against duly_task's schema and it resolves — a real, populated, correctly-typed lookup. Every binding was valid. The defect is a relationship between two config keys, not a dangling reference.

Proven red first. On 19a0306 with the views unfixed, npx vitest run test/metadata-bindings.test.ts exited 1:

AssertionError: a grouped grid buckets rows by a field its `columns` do not carry …
+ "view duly_task › listViews.by_unit · grouping.fields[0].field groups by \"business_unit\",
columns: subject, status, due_date, period_key, owner, source"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[0].field groups by \"business_unit\", …"
+ "view duly_duty › listViews.catalog_tree · grouping.fields[1].field groups by \"owner\", …"

The transcript is recorded in the test's own comment, and synthetic fixtures pin both directions permanently (fires / does not fire, multi-level, bare-string column shorthand).

One measured deviation from the card's scope

The card asks the guard to cover kanban-grouping too, on the reading that the kanban board is "fine by luck" because its group field happens to be displayed. It is not luck, and status is not one of the board's columns. Ablated against a booted app one leg at a time, each mutation confirmed on disk and reverted through a restore trap:

leg	mutation	resulting select
A	board kanban.groupByField → business_unit	…,source,business_unit,status
B	A + business_unit added to kanban.columns	unchanged from A
C	schedule gantt.groupByField → business_unit	…,due_date,business_unit
D	recent gains timeline.groupByField: business_unit	…,business_unit,due_date

So kanban / gantt / timelinegroupByField are each unioned into the projection by their own adapter — the grid's grouping block is the one that is not, which is exactly the gap objectui#7179 names. The guard therefore covers grouping.fields[] only; widening it to three keys that measurably work would be the same mistake the card warns against for sort. The other group keys are still inventoried by the walk, so adding one fails a tripwire and lands in front of a human. Legs A/B also pin where a field must go: kanban.columns is the card face (cardFields), never the projection.

3. sort — left alone, as instructed

No measurement showed a sort failing, and sorting is applied server-side ($orderby in the same request), so a sort field outside columns is a different mechanism. Not touched, not guarded.

Browser verification

objectstack dev on port 3100 from this worktree, #75 seed (186 tasks, 31 duties, 5 business units), logged in as admin.

Before — one (empty) bucket holding every row:

After — by_unit, one group per unit, counts 33 + 3 + 46 + 18 = 100 = the visible row total (the seed's fifth unit has no rows on page 1 of 100):

After — duty's lens grouping on both levels (Ardenline Group → Nadia Ilves, Northgate Operations → Marek Dvorak 2 / Sami Okonkwo 3):

Post-fix requests: select=id,subject,status,due_date,period_key,owner,source,business_unit and select=id,name,form,frequency,business_unit,owner,source,status. Zero (empty) labels on either lens, no console errors, no 4xx.

The screenshots live on the throwaway branch claude/issue-76-evidence so no binaries enter this diff or main — delete it whenever.

Gates

All four green at df6b114 (this PR's head):

pnpm validate exit 0 ⚠ one expected warning: hierarchy-security is enterprise-edition (AGENTS.md rule 7)
pnpm typecheck exit 0
pnpm test exit 0 20 files, 545 tests
pnpm build exit 0 dist/objectstack.json 276.2 KB

No changeset: this repo has no .changeset/ directory in git log --all, no @changesets/* dependency and no changeset script — creating one would mint a mechanism nothing here reads.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The deviation from my scope is a correction to my card, and it is right.

Gates, re-run by me on df6b114 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 20 passed, Tests 545 passed), build 0.

I wrote in scope item 2 that "the kanban groupByFields are fine by luck: status (board) and owner (assignments) both happen to be displayed columns." That was wrong on both halves — status is not one of the board's columns, and they are not fine by luck. Four browser ablation legs with the captured select= string in each show kanban, gantt and timeline each union their groupByField into the projection through their own adapter, needing no column at all; leg B further shows kanban.columns is the card face and has nothing to do with the fetch.

So the grid's grouping block is the only projection-blind path. Scoping the guard to grouping.fields[] and inventorying the other three behind a tripwire is exactly right: widening it would have made it fire on views that measurably work, which is the mistake item 3 warns about one paragraph earlier. Good catch that my own card contained the error item 3 was written to prevent.

Two more things worth recording:

• Red-first was proven on 19a0306, not asserted — expected [ …(3) ] to deeply equal [] naming by_unit grouping.fields[0] and catalog_tree grouping.fields[0] and [1], with the other 42 tests in the file still passing so only the new assertion moved. And the guard is filed for deletion against objectui#7179, not against the #14105/#14107/#14108 walk — two stopgaps with different expiry dates, correctly kept apart.
• The browser acceptance is the real proof. Before: by_unit one (empty) group holding all 186 rows, catalog_tree(empty) nested inside (empty). After: Northgate Operations 33 / Northgate Plant 3 / Northgate Quality 46 / Riverside Plant 18, each labelled with the unit's name, and catalog_tree grouping on both levels. Screenshots kept on a throwaway branch so no binaries enter the diff — the right call.

I have posted your kanban/gantt/timeline measurement to objectui#7179, since I had told the platform team those were worth checking and you have now checked them.

#86 (page-scoped group counts) is a real finding and correctly out of scope here — this card's own acceptance treated the counts as page-scoped, so fixing it would have been scope creep. Triaging it separately.

---

Generated by Claude Code