Manager dashboard: what has stopped, and what is coming up

[os-warren]

Fixes#10

duly_duty_health, bound entirely to the semantic layer, reachable from the Team nav group as its first entry.

Gates green on 2d1a27e (the tip of this branch): pnpm validate 0 · pnpm typecheck 0 · pnpm test 0 (457 passed / 15 files, up from 419 / 14) · pnpm build 0. The one validate warning is the expected hierarchy-security capability-provider line, which AGENTS.md rule 7 says not to silence.

The layout, and the item that is not in it

#	card	shipped
1	Not moving, >14d with >30d beside it	not_moving_14d (top-left, largest tile) + not_moving_30d, plus oldest_touch as a date
2	Late	not built — see below
3	On-time rate	not built — per the PM note (#52)
4	By unit	not_moving_by_unit, ordered by the unit dimension
5	Coming up	coming_up, due next 14 days by week

Items 2 and 3 are the same missing comparison, not two omissions. Both need due_date + duty.grace_days: there is no date arithmetic in the filter grammar, the {N_days_ago} vocabulary is relative to NOW rather than to another column, and here the offset is itself a column (objectstack#14104). No dataset declares an on-time or a lateness measure for a widget to bind, and src/datasets/ is not mine to change on this card.

A grace-free lateness is expressible without touching a dataset — a widget filter of due_date < {today} over tasks_due is two lines — and is deliberately not built. It marks late every task still inside the grace its own duty grants, so a customer who configured 7 days gets its people listed late the morning after the due date. That is the bug #48 already records against the late LIST view, and the product decision is open on #52. Deciding it in a widget would settle it by accident.

test/dashboard.test.ts pins the absence in both directions: no widget may bind an on_time / late / overdue measure, and no widget may rebuild one out of a due-date window bounded above by {today} or a past token (the forward window this dashboard does use is bounded above by a future token, which is a different question). When the tile arrives, both pins come off with it.

The absence is also stated on the screen, in the dashboard description, next to the caliber note — a manager reading "not moving: 3" on a screen silent about lateness concludes there are three problems. An unexplained absence is a wrong number with no digits.

What the platform actually guards — the card's second assumption was wrong too

The PM note said dataset bindings are guarded "above" and asked whether test/metadata-bindings.test.ts reaches dashboard widgets. It does not — its dulyDashboards import (added here) resolves the nav entry only. But the more useful answer came from measuring rather than assuming. Each mutation below was applied to the real dashboard, confirmed on disk with grep -F before the gates ran, and restored by a trap:

mutated reference	validate	build	rule
widget dataset → duly_stagnatoin	1	1	widget-dataset-unknown (+ did-you-mean)
widget dimensions[] → business_unitt	1	1	widget-dimension-unknown
widget values[] → untouched_over_14	1	1	widget-measure-unknown
{token} in widget filter → {14_days_hence}	1	1	filter-token-unknown, path-precise
dashboard dateRange.field → nonexistent_column	1	1	dashboard-filter-field-unknown
nav dashboardName → duly_ghost	1	2	defineStack cross-reference
widget filter KEY → due_daet	0	0	—
options.sortBy → not_selected	0	0	—

The last two are the real holes, and the first of them is sharp: on the same filter node, a bad {token} is caught with the exact path widgets[4].filter.due_date.$lte while a misspelt column is not — and dashboard-filter-field-unknown already resolves dataset → base object → field set per widget for the dashboard-level filter one key over. Filed upstream as objectstack-ai/objectstack#14148 with both halves and the repro. test/dashboard.test.ts's binding walk is the repo-local stopgap and is written to be deleted when that lands.

Every claim in the checked-in comments is one of these measurements; the first commit's comments asserted the opposite (inherited from the card) and the second commit corrects them.

Shapes the PM flagged, and where each one landed

• Cumulative buckets — >14d and >30d are separate tiles, never two series in one chart. Pinned: no widget may select two nested thresholds together, none may draw one as a pie/donut/funnel, and none may stack one.
• due_week / due_month — coming_up groups by due_week only.
• tasks_due identical in both datasets — so the forward look is scoped by a date window and not narrowed by status: adding status IN (open,in_progress) would put a different number behind a name the semantic layer defines once.
• oldest_last_update_at is a timestamp — a metric tile labelled as a date, never a bar length.
• The governed filter — neither added nor removed; it rides on the measures.

No ranking of people

No widget selects owner. The rule is pinned as a property rather than a spot-check: a person dimension is detected by resolving the dataset dimension's field to a sys_user lookup, so a second one added later is covered without editing the test. Two further pins hold even if a per-person workload widget is ever added deliberately (duly_workload keeps owner for exactly that): it may not be ordered by a measure, and it may not be truncated to a top N.

sortBy on the unit chart names the dimension. Ordering a lookup used to sort by the opaque FK id — "sorted by unit" that reads as random (objectstack#3680) — which was fixed upstream in #3693 to sort by the resolved display label. That is what makes this the unit name order the card asked for, not merely a count-free one.

Contrast, both themes

No text is drawn on a fill anywhere: showDataLabels: false is stated explicitly on both charts, so every label renders as axis or legend text on the card background. That is not tidiness — it is forced. Both fills are mid-tones chosen to clear 3:1 as graphical objects (WCAG 1.4.11) against a white and a near-black card, since metadata carries no per-theme colour: #B07C17 (L≈0.237 → 3.7:1 light, 5.3:1 dark) and #2E7C8E (L≈0.169 → 4.8:1 light, 4.0:1 dark). At that lightness white label text on the amber fill is 3.7:1, a failure for text — the two constraints have no common solution in one hex, so the labels come off the fill. The app's darker palette entries were measured and rejected for fills on the same test (#16515F 2.2:1, #5A3F0C 2.0:1 on a dark card). Tiles use warning / orange and never danger: attention, not blame — asserted.

File surface — one breach, flagged

test/metadata-bindings.test.ts is outside the surface the card named, and the change is not optional: that file's two tripwires fail the moment a dashboard nav entry exists ("teach walkNav about it before trusting the nav check"), which is the guard working as designed. It is taught the type — dashboardName resolved against the dashboards barrel, with self-test fixtures in both directions — and its nav-type tripwire now excludes the type it reads. Its comment records that this one, unlike viewName (#14108), is not an unguarded reference: defineStack refuses it. Everything else is on-surface: src/dashboards/*, the Team nav entry in src/apps/duly.app.ts, test/dashboard.test.ts. objectstack.config.ts, src/datasets/ and src/views/ are untouched.

What to look at in the browser

Acceptance is a running app, so the three things I could not verify from here:

1. oldest_touch — a min over a datetime. It should read as a date; if the KPI card renders a raw ISO string or an epoch number, that is a renderer formatting gap and I would rather file it than paper over it with an unverified options key.
2. Unit order on the by-unit chart — should be alphabetical by unit name per #3693.
3. coming_up bucket boundaries — ISO weeks (Monday start) wherever the driver does not truncate server-side; the window is [today, +14d], so the first and last buckets are partial weeks by construction.

In this open-edition checkout the hierarchy scopes resolve to owner-only (AGENTS.md rule 7), so every number will be scoped to the signed-in user rather than to their unit — that is the edition, not this dashboard.

---

Generated by Claude Code

[os-warren]

Fixes#10

duly_duty_health, bound entirely to the semantic layer, reachable from the Team nav group as its first entry.

Gates green on 2d1a27e (the tip of this branch): pnpm validate 0 · pnpm typecheck 0 · pnpm test 0 (457 passed / 15 files, up from 419 / 14) · pnpm build 0. The one validate warning is the expected hierarchy-security capability-provider line, which AGENTS.md rule 7 says not to silence.

The layout, and the item that is not in it

#	card	shipped
1	Not moving, >14d with >30d beside it	not_moving_14d (top-left, largest tile) + not_moving_30d, plus oldest_touch as a date
2	Late	not built — see below
3	On-time rate	not built — per the PM note (#52)
4	By unit	not_moving_by_unit, ordered by the unit dimension
5	Coming up	coming_up, due next 14 days by week

Items 2 and 3 are the same missing comparison, not two omissions. Both need due_date + duty.grace_days: there is no date arithmetic in the filter grammar, the {N_days_ago} vocabulary is relative to NOW rather than to another column, and here the offset is itself a column (objectstack#14104). No dataset declares an on-time or a lateness measure for a widget to bind, and src/datasets/ is not mine to change on this card.

A grace-free lateness is expressible without touching a dataset — a widget filter of due_date < {today} over tasks_due is two lines — and is deliberately not built. It marks late every task still inside the grace its own duty grants, so a customer who configured 7 days gets its people listed late the morning after the due date. That is the bug #48 already records against the late LIST view, and the product decision is open on #52. Deciding it in a widget would settle it by accident.

test/dashboard.test.ts pins the absence in both directions: no widget may bind an on_time / late / overdue measure, and no widget may rebuild one out of a due-date window bounded above by {today} or a past token (the forward window this dashboard does use is bounded above by a future token, which is a different question). When the tile arrives, both pins come off with it.

The absence is also stated on the screen, in the dashboard description, next to the caliber note — a manager reading "not moving: 3" on a screen silent about lateness concludes there are three problems. An unexplained absence is a wrong number with no digits.

What the platform actually guards — the card's second assumption was wrong too

The PM note said dataset bindings are guarded "above" and asked whether test/metadata-bindings.test.ts reaches dashboard widgets. It does not — its dulyDashboards import (added here) resolves the nav entry only. But the more useful answer came from measuring rather than assuming. Each mutation below was applied to the real dashboard, confirmed on disk with grep -F before the gates ran, and restored by a trap:

mutated reference	validate	build	rule
widget dataset → duly_stagnatoin	1	1	widget-dataset-unknown (+ did-you-mean)
widget dimensions[] → business_unitt	1	1	widget-dimension-unknown
widget values[] → untouched_over_14	1	1	widget-measure-unknown
{token} in widget filter → {14_days_hence}	1	1	filter-token-unknown, path-precise
dashboard dateRange.field → nonexistent_column	1	1	dashboard-filter-field-unknown
nav dashboardName → duly_ghost	1	2	defineStack cross-reference
widget filter KEY → due_daet	0	0	—
options.sortBy → not_selected	0	0	—

The last two are the real holes, and the first of them is sharp: on the same filter node, a bad {token} is caught with the exact path widgets[4].filter.due_date.$lte while a misspelt column is not — and dashboard-filter-field-unknown already resolves dataset → base object → field set per widget for the dashboard-level filter one key over. Filed upstream as objectstack-ai/objectstack#14148 with both halves and the repro. test/dashboard.test.ts's binding walk is the repo-local stopgap and is written to be deleted when that lands.

Every claim in the checked-in comments is one of these measurements; the first commit's comments asserted the opposite (inherited from the card) and the second commit corrects them.

Shapes the PM flagged, and where each one landed

• Cumulative buckets — >14d and >30d are separate tiles, never two series in one chart. Pinned: no widget may select two nested thresholds together, none may draw one as a pie/donut/funnel, and none may stack one.
• due_week / due_month — coming_up groups by due_week only.
• tasks_due identical in both datasets — so the forward look is scoped by a date window and not narrowed by status: adding status IN (open,in_progress) would put a different number behind a name the semantic layer defines once.
• oldest_last_update_at is a timestamp — a metric tile labelled as a date, never a bar length.
• The governed filter — neither added nor removed; it rides on the measures.

No ranking of people

No widget selects owner. The rule is pinned as a property rather than a spot-check: a person dimension is detected by resolving the dataset dimension's field to a sys_user lookup, so a second one added later is covered without editing the test. Two further pins hold even if a per-person workload widget is ever added deliberately (duly_workload keeps owner for exactly that): it may not be ordered by a measure, and it may not be truncated to a top N.

sortBy on the unit chart names the dimension. Ordering a lookup used to sort by the opaque FK id — "sorted by unit" that reads as random (objectstack#3680) — which was fixed upstream in #3693 to sort by the resolved display label. That is what makes this the unit name order the card asked for, not merely a count-free one.

Contrast, both themes

No text is drawn on a fill anywhere: showDataLabels: false is stated explicitly on both charts, so every label renders as axis or legend text on the card background. That is not tidiness — it is forced. Both fills are mid-tones chosen to clear 3:1 as graphical objects (WCAG 1.4.11) against a white and a near-black card, since metadata carries no per-theme colour: #B07C17 (L≈0.237 → 3.7:1 light, 5.3:1 dark) and #2E7C8E (L≈0.169 → 4.8:1 light, 4.0:1 dark). At that lightness white label text on the amber fill is 3.7:1, a failure for text — the two constraints have no common solution in one hex, so the labels come off the fill. The app's darker palette entries were measured and rejected for fills on the same test (#16515F 2.2:1, #5A3F0C 2.0:1 on a dark card). Tiles use warning / orange and never danger: attention, not blame — asserted.

File surface — one breach, flagged

test/metadata-bindings.test.ts is outside the surface the card named, and the change is not optional: that file's two tripwires fail the moment a dashboard nav entry exists ("teach walkNav about it before trusting the nav check"), which is the guard working as designed. It is taught the type — dashboardName resolved against the dashboards barrel, with self-test fixtures in both directions — and its nav-type tripwire now excludes the type it reads. Its comment records that this one, unlike viewName (#14108), is not an unguarded reference: defineStack refuses it. Everything else is on-surface: src/dashboards/*, the Team nav entry in src/apps/duly.app.ts, test/dashboard.test.ts. objectstack.config.ts, src/datasets/ and src/views/ are untouched.

What to look at in the browser

Acceptance is a running app, so the three things I could not verify from here:

1. oldest_touch — a min over a datetime. It should read as a date; if the KPI card renders a raw ISO string or an epoch number, that is a renderer formatting gap and I would rather file it than paper over it with an unverified options key.
2. Unit order on the by-unit chart — should be alphabetical by unit name per #3693.
3. coming_up bucket boundaries — ISO weeks (Monday start) wherever the driver does not truncate server-side; the window is [today, +14d], so the first and last buckets are partial weeks by construction.

In this open-edition checkout the hierarchy scopes resolve to owner-only (AGENTS.md rule 7), so every number will be scoped to the signed-in user rather than to their unit — that is the edition, not this dashboard.

---

Generated by Claude Code

[os-warren]

Fixes#10

duly_duty_health, bound entirely to the semantic layer, reachable from the Team nav group as its first entry.

Gates green on 2d1a27e (the tip of this branch): pnpm validate 0 · pnpm typecheck 0 · pnpm test 0 (457 passed / 15 files, up from 419 / 14) · pnpm build 0. The one validate warning is the expected hierarchy-security capability-provider line, which AGENTS.md rule 7 says not to silence.

The layout, and the item that is not in it

#	card	shipped
1	Not moving, >14d with >30d beside it	not_moving_14d (top-left, largest tile) + not_moving_30d, plus oldest_touch as a date
2	Late	not built — see below
3	On-time rate	not built — per the PM note (#52)
4	By unit	not_moving_by_unit, ordered by the unit dimension
5	Coming up	coming_up, due next 14 days by week

Items 2 and 3 are the same missing comparison, not two omissions. Both need due_date + duty.grace_days: there is no date arithmetic in the filter grammar, the {N_days_ago} vocabulary is relative to NOW rather than to another column, and here the offset is itself a column (objectstack#14104). No dataset declares an on-time or a lateness measure for a widget to bind, and src/datasets/ is not mine to change on this card.

A grace-free lateness is expressible without touching a dataset — a widget filter of due_date < {today} over tasks_due is two lines — and is deliberately not built. It marks late every task still inside the grace its own duty grants, so a customer who configured 7 days gets its people listed late the morning after the due date. That is the bug #48 already records against the late LIST view, and the product decision is open on #52. Deciding it in a widget would settle it by accident.

test/dashboard.test.ts pins the absence in both directions: no widget may bind an on_time / late / overdue measure, and no widget may rebuild one out of a due-date window bounded above by {today} or a past token (the forward window this dashboard does use is bounded above by a future token, which is a different question). When the tile arrives, both pins come off with it.

The absence is also stated on the screen, in the dashboard description, next to the caliber note — a manager reading "not moving: 3" on a screen silent about lateness concludes there are three problems. An unexplained absence is a wrong number with no digits.

What the platform actually guards — the card's second assumption was wrong too

The PM note said dataset bindings are guarded "above" and asked whether test/metadata-bindings.test.ts reaches dashboard widgets. It does not — its dulyDashboards import (added here) resolves the nav entry only. But the more useful answer came from measuring rather than assuming. Each mutation below was applied to the real dashboard, confirmed on disk with grep -F before the gates ran, and restored by a trap:

mutated reference	validate	build	rule
widget dataset → duly_stagnatoin	1	1	widget-dataset-unknown (+ did-you-mean)
widget dimensions[] → business_unitt	1	1	widget-dimension-unknown
widget values[] → untouched_over_14	1	1	widget-measure-unknown
{token} in widget filter → {14_days_hence}	1	1	filter-token-unknown, path-precise
dashboard dateRange.field → nonexistent_column	1	1	dashboard-filter-field-unknown
nav dashboardName → duly_ghost	1	2	defineStack cross-reference
widget filter KEY → due_daet	0	0	—
options.sortBy → not_selected	0	0	—

The last two are the real holes, and the first of them is sharp: on the same filter node, a bad {token} is caught with the exact path widgets[4].filter.due_date.$lte while a misspelt column is not — and dashboard-filter-field-unknown already resolves dataset → base object → field set per widget for the dashboard-level filter one key over. Filed upstream as objectstack-ai/objectstack#14148 with both halves and the repro. test/dashboard.test.ts's binding walk is the repo-local stopgap and is written to be deleted when that lands.

Every claim in the checked-in comments is one of these measurements; the first commit's comments asserted the opposite (inherited from the card) and the second commit corrects them.

Shapes the PM flagged, and where each one landed

• Cumulative buckets — >14d and >30d are separate tiles, never two series in one chart. Pinned: no widget may select two nested thresholds together, none may draw one as a pie/donut/funnel, and none may stack one.
• due_week / due_month — coming_up groups by due_week only.
• tasks_due identical in both datasets — so the forward look is scoped by a date window and not narrowed by status: adding status IN (open,in_progress) would put a different number behind a name the semantic layer defines once.
• oldest_last_update_at is a timestamp — a metric tile labelled as a date, never a bar length.
• The governed filter — neither added nor removed; it rides on the measures.

No ranking of people

No widget selects owner. The rule is pinned as a property rather than a spot-check: a person dimension is detected by resolving the dataset dimension's field to a sys_user lookup, so a second one added later is covered without editing the test. Two further pins hold even if a per-person workload widget is ever added deliberately (duly_workload keeps owner for exactly that): it may not be ordered by a measure, and it may not be truncated to a top N.

sortBy on the unit chart names the dimension. Ordering a lookup used to sort by the opaque FK id — "sorted by unit" that reads as random (objectstack#3680) — which was fixed upstream in #3693 to sort by the resolved display label. That is what makes this the unit name order the card asked for, not merely a count-free one.

Contrast, both themes

No text is drawn on a fill anywhere: showDataLabels: false is stated explicitly on both charts, so every label renders as axis or legend text on the card background. That is not tidiness — it is forced. Both fills are mid-tones chosen to clear 3:1 as graphical objects (WCAG 1.4.11) against a white and a near-black card, since metadata carries no per-theme colour: #B07C17 (L≈0.237 → 3.7:1 light, 5.3:1 dark) and #2E7C8E (L≈0.169 → 4.8:1 light, 4.0:1 dark). At that lightness white label text on the amber fill is 3.7:1, a failure for text — the two constraints have no common solution in one hex, so the labels come off the fill. The app's darker palette entries were measured and rejected for fills on the same test (#16515F 2.2:1, #5A3F0C 2.0:1 on a dark card). Tiles use warning / orange and never danger: attention, not blame — asserted.

File surface — one breach, flagged

test/metadata-bindings.test.ts is outside the surface the card named, and the change is not optional: that file's two tripwires fail the moment a dashboard nav entry exists ("teach walkNav about it before trusting the nav check"), which is the guard working as designed. It is taught the type — dashboardName resolved against the dashboards barrel, with self-test fixtures in both directions — and its nav-type tripwire now excludes the type it reads. Its comment records that this one, unlike viewName (#14108), is not an unguarded reference: defineStack refuses it. Everything else is on-surface: src/dashboards/*, the Team nav entry in src/apps/duly.app.ts, test/dashboard.test.ts. objectstack.config.ts, src/datasets/ and src/views/ are untouched.

What to look at in the browser

Acceptance is a running app, so the three things I could not verify from here:

1. oldest_touch — a min over a datetime. It should read as a date; if the KPI card renders a raw ISO string or an epoch number, that is a renderer formatting gap and I would rather file it than paper over it with an unverified options key.
2. Unit order on the by-unit chart — should be alphabetical by unit name per #3693.
3. coming_up bucket boundaries — ISO weeks (Monday start) wherever the driver does not truncate server-side; the window is [today, +14d], so the first and last buckets are partial weeks by construction.

In this open-edition checkout the hierarchy scopes resolve to owner-only (AGENTS.md rule 7), so every number will be scoped to the signed-in user rather than to their unit — that is the edition, not this dashboard.

---

Generated by Claude Code

[os-warren]

Fixes#10

duly_duty_health, bound entirely to the semantic layer, reachable from the Team nav group as its first entry.

Gates green on 2d1a27e (the tip of this branch): pnpm validate 0 · pnpm typecheck 0 · pnpm test 0 (457 passed / 15 files, up from 419 / 14) · pnpm build 0. The one validate warning is the expected hierarchy-security capability-provider line, which AGENTS.md rule 7 says not to silence.

The layout, and the item that is not in it

#	card	shipped
1	Not moving, >14d with >30d beside it	not_moving_14d (top-left, largest tile) + not_moving_30d, plus oldest_touch as a date
2	Late	not built — see below
3	On-time rate	not built — per the PM note (#52)
4	By unit	not_moving_by_unit, ordered by the unit dimension
5	Coming up	coming_up, due next 14 days by week

Items 2 and 3 are the same missing comparison, not two omissions. Both need due_date + duty.grace_days: there is no date arithmetic in the filter grammar, the {N_days_ago} vocabulary is relative to NOW rather than to another column, and here the offset is itself a column (objectstack#14104). No dataset declares an on-time or a lateness measure for a widget to bind, and src/datasets/ is not mine to change on this card.

A grace-free lateness is expressible without touching a dataset — a widget filter of due_date < {today} over tasks_due is two lines — and is deliberately not built. It marks late every task still inside the grace its own duty grants, so a customer who configured 7 days gets its people listed late the morning after the due date. That is the bug #48 already records against the late LIST view, and the product decision is open on #52. Deciding it in a widget would settle it by accident.

test/dashboard.test.ts pins the absence in both directions: no widget may bind an on_time / late / overdue measure, and no widget may rebuild one out of a due-date window bounded above by {today} or a past token (the forward window this dashboard does use is bounded above by a future token, which is a different question). When the tile arrives, both pins come off with it.

The absence is also stated on the screen, in the dashboard description, next to the caliber note — a manager reading "not moving: 3" on a screen silent about lateness concludes there are three problems. An unexplained absence is a wrong number with no digits.

What the platform actually guards — the card's second assumption was wrong too

The PM note said dataset bindings are guarded "above" and asked whether test/metadata-bindings.test.ts reaches dashboard widgets. It does not — its dulyDashboards import (added here) resolves the nav entry only. But the more useful answer came from measuring rather than assuming. Each mutation below was applied to the real dashboard, confirmed on disk with grep -F before the gates ran, and restored by a trap:

mutated reference	validate	build	rule
widget dataset → duly_stagnatoin	1	1	widget-dataset-unknown (+ did-you-mean)
widget dimensions[] → business_unitt	1	1	widget-dimension-unknown
widget values[] → untouched_over_14	1	1	widget-measure-unknown
{token} in widget filter → {14_days_hence}	1	1	filter-token-unknown, path-precise
dashboard dateRange.field → nonexistent_column	1	1	dashboard-filter-field-unknown
nav dashboardName → duly_ghost	1	2	defineStack cross-reference
widget filter KEY → due_daet	0	0	—
options.sortBy → not_selected	0	0	—

The last two are the real holes, and the first of them is sharp: on the same filter node, a bad {token} is caught with the exact path widgets[4].filter.due_date.$lte while a misspelt column is not — and dashboard-filter-field-unknown already resolves dataset → base object → field set per widget for the dashboard-level filter one key over. Filed upstream as objectstack-ai/objectstack#14148 with both halves and the repro. test/dashboard.test.ts's binding walk is the repo-local stopgap and is written to be deleted when that lands.

Every claim in the checked-in comments is one of these measurements; the first commit's comments asserted the opposite (inherited from the card) and the second commit corrects them.

Shapes the PM flagged, and where each one landed

• Cumulative buckets — >14d and >30d are separate tiles, never two series in one chart. Pinned: no widget may select two nested thresholds together, none may draw one as a pie/donut/funnel, and none may stack one.
• due_week / due_month — coming_up groups by due_week only.
• tasks_due identical in both datasets — so the forward look is scoped by a date window and not narrowed by status: adding status IN (open,in_progress) would put a different number behind a name the semantic layer defines once.
• oldest_last_update_at is a timestamp — a metric tile labelled as a date, never a bar length.
• The governed filter — neither added nor removed; it rides on the measures.

No ranking of people

No widget selects owner. The rule is pinned as a property rather than a spot-check: a person dimension is detected by resolving the dataset dimension's field to a sys_user lookup, so a second one added later is covered without editing the test. Two further pins hold even if a per-person workload widget is ever added deliberately (duly_workload keeps owner for exactly that): it may not be ordered by a measure, and it may not be truncated to a top N.

sortBy on the unit chart names the dimension. Ordering a lookup used to sort by the opaque FK id — "sorted by unit" that reads as random (objectstack#3680) — which was fixed upstream in #3693 to sort by the resolved display label. That is what makes this the unit name order the card asked for, not merely a count-free one.

Contrast, both themes

No text is drawn on a fill anywhere: showDataLabels: false is stated explicitly on both charts, so every label renders as axis or legend text on the card background. That is not tidiness — it is forced. Both fills are mid-tones chosen to clear 3:1 as graphical objects (WCAG 1.4.11) against a white and a near-black card, since metadata carries no per-theme colour: #B07C17 (L≈0.237 → 3.7:1 light, 5.3:1 dark) and #2E7C8E (L≈0.169 → 4.8:1 light, 4.0:1 dark). At that lightness white label text on the amber fill is 3.7:1, a failure for text — the two constraints have no common solution in one hex, so the labels come off the fill. The app's darker palette entries were measured and rejected for fills on the same test (#16515F 2.2:1, #5A3F0C 2.0:1 on a dark card). Tiles use warning / orange and never danger: attention, not blame — asserted.

File surface — one breach, flagged

test/metadata-bindings.test.ts is outside the surface the card named, and the change is not optional: that file's two tripwires fail the moment a dashboard nav entry exists ("teach walkNav about it before trusting the nav check"), which is the guard working as designed. It is taught the type — dashboardName resolved against the dashboards barrel, with self-test fixtures in both directions — and its nav-type tripwire now excludes the type it reads. Its comment records that this one, unlike viewName (#14108), is not an unguarded reference: defineStack refuses it. Everything else is on-surface: src/dashboards/*, the Team nav entry in src/apps/duly.app.ts, test/dashboard.test.ts. objectstack.config.ts, src/datasets/ and src/views/ are untouched.

What to look at in the browser

Acceptance is a running app, so the three things I could not verify from here:

1. oldest_touch — a min over a datetime. It should read as a date; if the KPI card renders a raw ISO string or an epoch number, that is a renderer formatting gap and I would rather file it than paper over it with an unverified options key.
2. Unit order on the by-unit chart — should be alphabetical by unit name per #3693.
3. coming_up bucket boundaries — ISO weeks (Monday start) wherever the driver does not truncate server-side; the window is [today, +14d], so the first and last buckets are partial weeks by construction.

In this open-edition checkout the hierarchy scopes resolve to owner-only (AGENTS.md rule 7), so every number will be scoped to the signed-in user rather than to their unit — that is the edition, not this dashboard.

---

Generated by Claude Code

[os-warren]

Fixes#10

duly_duty_health, bound entirely to the semantic layer, reachable from the Team nav group as its first entry.

Gates green on 2d1a27e (the tip of this branch): pnpm validate 0 · pnpm typecheck 0 · pnpm test 0 (457 passed / 15 files, up from 419 / 14) · pnpm build 0. The one validate warning is the expected hierarchy-security capability-provider line, which AGENTS.md rule 7 says not to silence.

The layout, and the item that is not in it

#	card	shipped
1	Not moving, >14d with >30d beside it	not_moving_14d (top-left, largest tile) + not_moving_30d, plus oldest_touch as a date
2	Late	not built — see below
3	On-time rate	not built — per the PM note (#52)
4	By unit	not_moving_by_unit, ordered by the unit dimension
5	Coming up	coming_up, due next 14 days by week

Items 2 and 3 are the same missing comparison, not two omissions. Both need due_date + duty.grace_days: there is no date arithmetic in the filter grammar, the {N_days_ago} vocabulary is relative to NOW rather than to another column, and here the offset is itself a column (objectstack#14104). No dataset declares an on-time or a lateness measure for a widget to bind, and src/datasets/ is not mine to change on this card.

A grace-free lateness is expressible without touching a dataset — a widget filter of due_date < {today} over tasks_due is two lines — and is deliberately not built. It marks late every task still inside the grace its own duty grants, so a customer who configured 7 days gets its people listed late the morning after the due date. That is the bug #48 already records against the late LIST view, and the product decision is open on #52. Deciding it in a widget would settle it by accident.

test/dashboard.test.ts pins the absence in both directions: no widget may bind an on_time / late / overdue measure, and no widget may rebuild one out of a due-date window bounded above by {today} or a past token (the forward window this dashboard does use is bounded above by a future token, which is a different question). When the tile arrives, both pins come off with it.

The absence is also stated on the screen, in the dashboard description, next to the caliber note — a manager reading "not moving: 3" on a screen silent about lateness concludes there are three problems. An unexplained absence is a wrong number with no digits.

What the platform actually guards — the card's second assumption was wrong too

The PM note said dataset bindings are guarded "above" and asked whether test/metadata-bindings.test.ts reaches dashboard widgets. It does not — its dulyDashboards import (added here) resolves the nav entry only. But the more useful answer came from measuring rather than assuming. Each mutation below was applied to the real dashboard, confirmed on disk with grep -F before the gates ran, and restored by a trap:

mutated reference	validate	build	rule
widget dataset → duly_stagnatoin	1	1	widget-dataset-unknown (+ did-you-mean)
widget dimensions[] → business_unitt	1	1	widget-dimension-unknown
widget values[] → untouched_over_14	1	1	widget-measure-unknown
{token} in widget filter → {14_days_hence}	1	1	filter-token-unknown, path-precise
dashboard dateRange.field → nonexistent_column	1	1	dashboard-filter-field-unknown
nav dashboardName → duly_ghost	1	2	defineStack cross-reference
widget filter KEY → due_daet	0	0	—
options.sortBy → not_selected	0	0	—

The last two are the real holes, and the first of them is sharp: on the same filter node, a bad {token} is caught with the exact path widgets[4].filter.due_date.$lte while a misspelt column is not — and dashboard-filter-field-unknown already resolves dataset → base object → field set per widget for the dashboard-level filter one key over. Filed upstream as objectstack-ai/objectstack#14148 with both halves and the repro. test/dashboard.test.ts's binding walk is the repo-local stopgap and is written to be deleted when that lands.

Every claim in the checked-in comments is one of these measurements; the first commit's comments asserted the opposite (inherited from the card) and the second commit corrects them.

Shapes the PM flagged, and where each one landed

• Cumulative buckets — >14d and >30d are separate tiles, never two series in one chart. Pinned: no widget may select two nested thresholds together, none may draw one as a pie/donut/funnel, and none may stack one.
• due_week / due_month — coming_up groups by due_week only.
• tasks_due identical in both datasets — so the forward look is scoped by a date window and not narrowed by status: adding status IN (open,in_progress) would put a different number behind a name the semantic layer defines once.
• oldest_last_update_at is a timestamp — a metric tile labelled as a date, never a bar length.
• The governed filter — neither added nor removed; it rides on the measures.

No ranking of people

No widget selects owner. The rule is pinned as a property rather than a spot-check: a person dimension is detected by resolving the dataset dimension's field to a sys_user lookup, so a second one added later is covered without editing the test. Two further pins hold even if a per-person workload widget is ever added deliberately (duly_workload keeps owner for exactly that): it may not be ordered by a measure, and it may not be truncated to a top N.

sortBy on the unit chart names the dimension. Ordering a lookup used to sort by the opaque FK id — "sorted by unit" that reads as random (objectstack#3680) — which was fixed upstream in #3693 to sort by the resolved display label. That is what makes this the unit name order the card asked for, not merely a count-free one.

Contrast, both themes

No text is drawn on a fill anywhere: showDataLabels: false is stated explicitly on both charts, so every label renders as axis or legend text on the card background. That is not tidiness — it is forced. Both fills are mid-tones chosen to clear 3:1 as graphical objects (WCAG 1.4.11) against a white and a near-black card, since metadata carries no per-theme colour: #B07C17 (L≈0.237 → 3.7:1 light, 5.3:1 dark) and #2E7C8E (L≈0.169 → 4.8:1 light, 4.0:1 dark). At that lightness white label text on the amber fill is 3.7:1, a failure for text — the two constraints have no common solution in one hex, so the labels come off the fill. The app's darker palette entries were measured and rejected for fills on the same test (#16515F 2.2:1, #5A3F0C 2.0:1 on a dark card). Tiles use warning / orange and never danger: attention, not blame — asserted.

File surface — one breach, flagged

test/metadata-bindings.test.ts is outside the surface the card named, and the change is not optional: that file's two tripwires fail the moment a dashboard nav entry exists ("teach walkNav about it before trusting the nav check"), which is the guard working as designed. It is taught the type — dashboardName resolved against the dashboards barrel, with self-test fixtures in both directions — and its nav-type tripwire now excludes the type it reads. Its comment records that this one, unlike viewName (#14108), is not an unguarded reference: defineStack refuses it. Everything else is on-surface: src/dashboards/*, the Team nav entry in src/apps/duly.app.ts, test/dashboard.test.ts. objectstack.config.ts, src/datasets/ and src/views/ are untouched.

What to look at in the browser

Acceptance is a running app, so the three things I could not verify from here:

1. oldest_touch — a min over a datetime. It should read as a date; if the KPI card renders a raw ISO string or an epoch number, that is a renderer formatting gap and I would rather file it than paper over it with an unverified options key.
2. Unit order on the by-unit chart — should be alphabetical by unit name per #3693.
3. coming_up bucket boundaries — ISO weeks (Monday start) wherever the driver does not truncate server-side; the window is [today, +14d], so the first and last buckets are partial weeks by construction.

In this open-edition checkout the hierarchy scopes resolve to owner-only (AGENTS.md rule 7), so every number will be scoped to the signed-in user rather than to their unit — that is the edition, not this dashboard.

---

Generated by Claude Code

[os-warren]

Fixes#10

duly_duty_health, bound entirely to the semantic layer, reachable from the Team nav group as its first entry.

Gates green on 2d1a27e (the tip of this branch): pnpm validate 0 · pnpm typecheck 0 · pnpm test 0 (457 passed / 15 files, up from 419 / 14) · pnpm build 0. The one validate warning is the expected hierarchy-security capability-provider line, which AGENTS.md rule 7 says not to silence.

The layout, and the item that is not in it

#	card	shipped
1	Not moving, >14d with >30d beside it	not_moving_14d (top-left, largest tile) + not_moving_30d, plus oldest_touch as a date
2	Late	not built — see below
3	On-time rate	not built — per the PM note (#52)
4	By unit	not_moving_by_unit, ordered by the unit dimension
5	Coming up	coming_up, due next 14 days by week

Items 2 and 3 are the same missing comparison, not two omissions. Both need due_date + duty.grace_days: there is no date arithmetic in the filter grammar, the {N_days_ago} vocabulary is relative to NOW rather than to another column, and here the offset is itself a column (objectstack#14104). No dataset declares an on-time or a lateness measure for a widget to bind, and src/datasets/ is not mine to change on this card.

A grace-free lateness is expressible without touching a dataset — a widget filter of due_date < {today} over tasks_due is two lines — and is deliberately not built. It marks late every task still inside the grace its own duty grants, so a customer who configured 7 days gets its people listed late the morning after the due date. That is the bug #48 already records against the late LIST view, and the product decision is open on #52. Deciding it in a widget would settle it by accident.

test/dashboard.test.ts pins the absence in both directions: no widget may bind an on_time / late / overdue measure, and no widget may rebuild one out of a due-date window bounded above by {today} or a past token (the forward window this dashboard does use is bounded above by a future token, which is a different question). When the tile arrives, both pins come off with it.

The absence is also stated on the screen, in the dashboard description, next to the caliber note — a manager reading "not moving: 3" on a screen silent about lateness concludes there are three problems. An unexplained absence is a wrong number with no digits.

What the platform actually guards — the card's second assumption was wrong too

The PM note said dataset bindings are guarded "above" and asked whether test/metadata-bindings.test.ts reaches dashboard widgets. It does not — its dulyDashboards import (added here) resolves the nav entry only. But the more useful answer came from measuring rather than assuming. Each mutation below was applied to the real dashboard, confirmed on disk with grep -F before the gates ran, and restored by a trap:

mutated reference	validate	build	rule
widget dataset → duly_stagnatoin	1	1	widget-dataset-unknown (+ did-you-mean)
widget dimensions[] → business_unitt	1	1	widget-dimension-unknown
widget values[] → untouched_over_14	1	1	widget-measure-unknown
{token} in widget filter → {14_days_hence}	1	1	filter-token-unknown, path-precise
dashboard dateRange.field → nonexistent_column	1	1	dashboard-filter-field-unknown
nav dashboardName → duly_ghost	1	2	defineStack cross-reference
widget filter KEY → due_daet	0	0	—
options.sortBy → not_selected	0	0	—

The last two are the real holes, and the first of them is sharp: on the same filter node, a bad {token} is caught with the exact path widgets[4].filter.due_date.$lte while a misspelt column is not — and dashboard-filter-field-unknown already resolves dataset → base object → field set per widget for the dashboard-level filter one key over. Filed upstream as objectstack-ai/objectstack#14148 with both halves and the repro. test/dashboard.test.ts's binding walk is the repo-local stopgap and is written to be deleted when that lands.

Every claim in the checked-in comments is one of these measurements; the first commit's comments asserted the opposite (inherited from the card) and the second commit corrects them.

Shapes the PM flagged, and where each one landed

• Cumulative buckets — >14d and >30d are separate tiles, never two series in one chart. Pinned: no widget may select two nested thresholds together, none may draw one as a pie/donut/funnel, and none may stack one.
• due_week / due_month — coming_up groups by due_week only.
• tasks_due identical in both datasets — so the forward look is scoped by a date window and not narrowed by status: adding status IN (open,in_progress) would put a different number behind a name the semantic layer defines once.
• oldest_last_update_at is a timestamp — a metric tile labelled as a date, never a bar length.
• The governed filter — neither added nor removed; it rides on the measures.

No ranking of people

No widget selects owner. The rule is pinned as a property rather than a spot-check: a person dimension is detected by resolving the dataset dimension's field to a sys_user lookup, so a second one added later is covered without editing the test. Two further pins hold even if a per-person workload widget is ever added deliberately (duly_workload keeps owner for exactly that): it may not be ordered by a measure, and it may not be truncated to a top N.

sortBy on the unit chart names the dimension. Ordering a lookup used to sort by the opaque FK id — "sorted by unit" that reads as random (objectstack#3680) — which was fixed upstream in #3693 to sort by the resolved display label. That is what makes this the unit name order the card asked for, not merely a count-free one.

Contrast, both themes

No text is drawn on a fill anywhere: showDataLabels: false is stated explicitly on both charts, so every label renders as axis or legend text on the card background. That is not tidiness — it is forced. Both fills are mid-tones chosen to clear 3:1 as graphical objects (WCAG 1.4.11) against a white and a near-black card, since metadata carries no per-theme colour: #B07C17 (L≈0.237 → 3.7:1 light, 5.3:1 dark) and #2E7C8E (L≈0.169 → 4.8:1 light, 4.0:1 dark). At that lightness white label text on the amber fill is 3.7:1, a failure for text — the two constraints have no common solution in one hex, so the labels come off the fill. The app's darker palette entries were measured and rejected for fills on the same test (#16515F 2.2:1, #5A3F0C 2.0:1 on a dark card). Tiles use warning / orange and never danger: attention, not blame — asserted.

File surface — one breach, flagged

test/metadata-bindings.test.ts is outside the surface the card named, and the change is not optional: that file's two tripwires fail the moment a dashboard nav entry exists ("teach walkNav about it before trusting the nav check"), which is the guard working as designed. It is taught the type — dashboardName resolved against the dashboards barrel, with self-test fixtures in both directions — and its nav-type tripwire now excludes the type it reads. Its comment records that this one, unlike viewName (#14108), is not an unguarded reference: defineStack refuses it. Everything else is on-surface: src/dashboards/*, the Team nav entry in src/apps/duly.app.ts, test/dashboard.test.ts. objectstack.config.ts, src/datasets/ and src/views/ are untouched.

What to look at in the browser

Acceptance is a running app, so the three things I could not verify from here:

1. oldest_touch — a min over a datetime. It should read as a date; if the KPI card renders a raw ISO string or an epoch number, that is a renderer formatting gap and I would rather file it than paper over it with an unverified options key.
2. Unit order on the by-unit chart — should be alphabetical by unit name per #3693.
3. coming_up bucket boundaries — ISO weeks (Monday start) wherever the driver does not truncate server-side; the window is [today, +14d], so the first and last buckets are partial weeks by construction.

In this open-edition checkout the hierarchy scopes resolve to owner-only (AGENTS.md rule 7), so every number will be scoped to the signed-in user rather than to their unit — that is the edition, not this dashboard.

---

Generated by Claude Code

[os-warren]

Fixes#10

duly_duty_health, bound entirely to the semantic layer, reachable from the Team nav group as its first entry.

Gates green on 2d1a27e (the tip of this branch): pnpm validate 0 · pnpm typecheck 0 · pnpm test 0 (457 passed / 15 files, up from 419 / 14) · pnpm build 0. The one validate warning is the expected hierarchy-security capability-provider line, which AGENTS.md rule 7 says not to silence.

The layout, and the item that is not in it

#	card	shipped
1	Not moving, >14d with >30d beside it	not_moving_14d (top-left, largest tile) + not_moving_30d, plus oldest_touch as a date
2	Late	not built — see below
3	On-time rate	not built — per the PM note (#52)
4	By unit	not_moving_by_unit, ordered by the unit dimension
5	Coming up	coming_up, due next 14 days by week

Items 2 and 3 are the same missing comparison, not two omissions. Both need due_date + duty.grace_days: there is no date arithmetic in the filter grammar, the {N_days_ago} vocabulary is relative to NOW rather than to another column, and here the offset is itself a column (objectstack#14104). No dataset declares an on-time or a lateness measure for a widget to bind, and src/datasets/ is not mine to change on this card.

A grace-free lateness is expressible without touching a dataset — a widget filter of due_date < {today} over tasks_due is two lines — and is deliberately not built. It marks late every task still inside the grace its own duty grants, so a customer who configured 7 days gets its people listed late the morning after the due date. That is the bug #48 already records against the late LIST view, and the product decision is open on #52. Deciding it in a widget would settle it by accident.

test/dashboard.test.ts pins the absence in both directions: no widget may bind an on_time / late / overdue measure, and no widget may rebuild one out of a due-date window bounded above by {today} or a past token (the forward window this dashboard does use is bounded above by a future token, which is a different question). When the tile arrives, both pins come off with it.

The absence is also stated on the screen, in the dashboard description, next to the caliber note — a manager reading "not moving: 3" on a screen silent about lateness concludes there are three problems. An unexplained absence is a wrong number with no digits.

What the platform actually guards — the card's second assumption was wrong too

The PM note said dataset bindings are guarded "above" and asked whether test/metadata-bindings.test.ts reaches dashboard widgets. It does not — its dulyDashboards import (added here) resolves the nav entry only. But the more useful answer came from measuring rather than assuming. Each mutation below was applied to the real dashboard, confirmed on disk with grep -F before the gates ran, and restored by a trap:

mutated reference	validate	build	rule
widget dataset → duly_stagnatoin	1	1	widget-dataset-unknown (+ did-you-mean)
widget dimensions[] → business_unitt	1	1	widget-dimension-unknown
widget values[] → untouched_over_14	1	1	widget-measure-unknown
{token} in widget filter → {14_days_hence}	1	1	filter-token-unknown, path-precise
dashboard dateRange.field → nonexistent_column	1	1	dashboard-filter-field-unknown
nav dashboardName → duly_ghost	1	2	defineStack cross-reference
widget filter KEY → due_daet	0	0	—
options.sortBy → not_selected	0	0	—

The last two are the real holes, and the first of them is sharp: on the same filter node, a bad {token} is caught with the exact path widgets[4].filter.due_date.$lte while a misspelt column is not — and dashboard-filter-field-unknown already resolves dataset → base object → field set per widget for the dashboard-level filter one key over. Filed upstream as objectstack-ai/objectstack#14148 with both halves and the repro. test/dashboard.test.ts's binding walk is the repo-local stopgap and is written to be deleted when that lands.

Every claim in the checked-in comments is one of these measurements; the first commit's comments asserted the opposite (inherited from the card) and the second commit corrects them.

Shapes the PM flagged, and where each one landed

• Cumulative buckets — >14d and >30d are separate tiles, never two series in one chart. Pinned: no widget may select two nested thresholds together, none may draw one as a pie/donut/funnel, and none may stack one.
• due_week / due_month — coming_up groups by due_week only.
• tasks_due identical in both datasets — so the forward look is scoped by a date window and not narrowed by status: adding status IN (open,in_progress) would put a different number behind a name the semantic layer defines once.
• oldest_last_update_at is a timestamp — a metric tile labelled as a date, never a bar length.
• The governed filter — neither added nor removed; it rides on the measures.

No ranking of people

No widget selects owner. The rule is pinned as a property rather than a spot-check: a person dimension is detected by resolving the dataset dimension's field to a sys_user lookup, so a second one added later is covered without editing the test. Two further pins hold even if a per-person workload widget is ever added deliberately (duly_workload keeps owner for exactly that): it may not be ordered by a measure, and it may not be truncated to a top N.

sortBy on the unit chart names the dimension. Ordering a lookup used to sort by the opaque FK id — "sorted by unit" that reads as random (objectstack#3680) — which was fixed upstream in #3693 to sort by the resolved display label. That is what makes this the unit name order the card asked for, not merely a count-free one.

Contrast, both themes

No text is drawn on a fill anywhere: showDataLabels: false is stated explicitly on both charts, so every label renders as axis or legend text on the card background. That is not tidiness — it is forced. Both fills are mid-tones chosen to clear 3:1 as graphical objects (WCAG 1.4.11) against a white and a near-black card, since metadata carries no per-theme colour: #B07C17 (L≈0.237 → 3.7:1 light, 5.3:1 dark) and #2E7C8E (L≈0.169 → 4.8:1 light, 4.0:1 dark). At that lightness white label text on the amber fill is 3.7:1, a failure for text — the two constraints have no common solution in one hex, so the labels come off the fill. The app's darker palette entries were measured and rejected for fills on the same test (#16515F 2.2:1, #5A3F0C 2.0:1 on a dark card). Tiles use warning / orange and never danger: attention, not blame — asserted.

File surface — one breach, flagged

test/metadata-bindings.test.ts is outside the surface the card named, and the change is not optional: that file's two tripwires fail the moment a dashboard nav entry exists ("teach walkNav about it before trusting the nav check"), which is the guard working as designed. It is taught the type — dashboardName resolved against the dashboards barrel, with self-test fixtures in both directions — and its nav-type tripwire now excludes the type it reads. Its comment records that this one, unlike viewName (#14108), is not an unguarded reference: defineStack refuses it. Everything else is on-surface: src/dashboards/*, the Team nav entry in src/apps/duly.app.ts, test/dashboard.test.ts. objectstack.config.ts, src/datasets/ and src/views/ are untouched.

What to look at in the browser

Acceptance is a running app, so the three things I could not verify from here:

1. oldest_touch — a min over a datetime. It should read as a date; if the KPI card renders a raw ISO string or an epoch number, that is a renderer formatting gap and I would rather file it than paper over it with an unverified options key.
2. Unit order on the by-unit chart — should be alphabetical by unit name per #3693.
3. coming_up bucket boundaries — ISO weeks (Monday start) wherever the driver does not truncate server-side; the window is [today, +14d], so the first and last buckets are partial weeks by construction.

In this open-edition checkout the hierarchy scopes resolve to owner-only (AGENTS.md rule 7), so every number will be scoped to the signed-in user rather than to their unit — that is the edition, not this dashboard.

---

Generated by Claude Code

[os-warren]

Fixes#10

duly_duty_health, bound entirely to the semantic layer, reachable from the Team nav group as its first entry.

Gates green on 2d1a27e (the tip of this branch): pnpm validate 0 · pnpm typecheck 0 · pnpm test 0 (457 passed / 15 files, up from 419 / 14) · pnpm build 0. The one validate warning is the expected hierarchy-security capability-provider line, which AGENTS.md rule 7 says not to silence.

The layout, and the item that is not in it

#	card	shipped
1	Not moving, >14d with >30d beside it	not_moving_14d (top-left, largest tile) + not_moving_30d, plus oldest_touch as a date
2	Late	not built — see below
3	On-time rate	not built — per the PM note (#52)
4	By unit	not_moving_by_unit, ordered by the unit dimension
5	Coming up	coming_up, due next 14 days by week

Items 2 and 3 are the same missing comparison, not two omissions. Both need due_date + duty.grace_days: there is no date arithmetic in the filter grammar, the {N_days_ago} vocabulary is relative to NOW rather than to another column, and here the offset is itself a column (objectstack#14104). No dataset declares an on-time or a lateness measure for a widget to bind, and src/datasets/ is not mine to change on this card.

A grace-free lateness is expressible without touching a dataset — a widget filter of due_date < {today} over tasks_due is two lines — and is deliberately not built. It marks late every task still inside the grace its own duty grants, so a customer who configured 7 days gets its people listed late the morning after the due date. That is the bug #48 already records against the late LIST view, and the product decision is open on #52. Deciding it in a widget would settle it by accident.

test/dashboard.test.ts pins the absence in both directions: no widget may bind an on_time / late / overdue measure, and no widget may rebuild one out of a due-date window bounded above by {today} or a past token (the forward window this dashboard does use is bounded above by a future token, which is a different question). When the tile arrives, both pins come off with it.

The absence is also stated on the screen, in the dashboard description, next to the caliber note — a manager reading "not moving: 3" on a screen silent about lateness concludes there are three problems. An unexplained absence is a wrong number with no digits.

What the platform actually guards — the card's second assumption was wrong too

The PM note said dataset bindings are guarded "above" and asked whether test/metadata-bindings.test.ts reaches dashboard widgets. It does not — its dulyDashboards import (added here) resolves the nav entry only. But the more useful answer came from measuring rather than assuming. Each mutation below was applied to the real dashboard, confirmed on disk with grep -F before the gates ran, and restored by a trap:

mutated reference	validate	build	rule
widget dataset → duly_stagnatoin	1	1	widget-dataset-unknown (+ did-you-mean)
widget dimensions[] → business_unitt	1	1	widget-dimension-unknown
widget values[] → untouched_over_14	1	1	widget-measure-unknown
{token} in widget filter → {14_days_hence}	1	1	filter-token-unknown, path-precise
dashboard dateRange.field → nonexistent_column	1	1	dashboard-filter-field-unknown
nav dashboardName → duly_ghost	1	2	defineStack cross-reference
widget filter KEY → due_daet	0	0	—
options.sortBy → not_selected	0	0	—

The last two are the real holes, and the first of them is sharp: on the same filter node, a bad {token} is caught with the exact path widgets[4].filter.due_date.$lte while a misspelt column is not — and dashboard-filter-field-unknown already resolves dataset → base object → field set per widget for the dashboard-level filter one key over. Filed upstream as objectstack-ai/objectstack#14148 with both halves and the repro. test/dashboard.test.ts's binding walk is the repo-local stopgap and is written to be deleted when that lands.

Every claim in the checked-in comments is one of these measurements; the first commit's comments asserted the opposite (inherited from the card) and the second commit corrects them.

Shapes the PM flagged, and where each one landed

• Cumulative buckets — >14d and >30d are separate tiles, never two series in one chart. Pinned: no widget may select two nested thresholds together, none may draw one as a pie/donut/funnel, and none may stack one.
• due_week / due_month — coming_up groups by due_week only.
• tasks_due identical in both datasets — so the forward look is scoped by a date window and not narrowed by status: adding status IN (open,in_progress) would put a different number behind a name the semantic layer defines once.
• oldest_last_update_at is a timestamp — a metric tile labelled as a date, never a bar length.
• The governed filter — neither added nor removed; it rides on the measures.

No ranking of people

No widget selects owner. The rule is pinned as a property rather than a spot-check: a person dimension is detected by resolving the dataset dimension's field to a sys_user lookup, so a second one added later is covered without editing the test. Two further pins hold even if a per-person workload widget is ever added deliberately (duly_workload keeps owner for exactly that): it may not be ordered by a measure, and it may not be truncated to a top N.

sortBy on the unit chart names the dimension. Ordering a lookup used to sort by the opaque FK id — "sorted by unit" that reads as random (objectstack#3680) — which was fixed upstream in #3693 to sort by the resolved display label. That is what makes this the unit name order the card asked for, not merely a count-free one.

Contrast, both themes

No text is drawn on a fill anywhere: showDataLabels: false is stated explicitly on both charts, so every label renders as axis or legend text on the card background. That is not tidiness — it is forced. Both fills are mid-tones chosen to clear 3:1 as graphical objects (WCAG 1.4.11) against a white and a near-black card, since metadata carries no per-theme colour: #B07C17 (L≈0.237 → 3.7:1 light, 5.3:1 dark) and #2E7C8E (L≈0.169 → 4.8:1 light, 4.0:1 dark). At that lightness white label text on the amber fill is 3.7:1, a failure for text — the two constraints have no common solution in one hex, so the labels come off the fill. The app's darker palette entries were measured and rejected for fills on the same test (#16515F 2.2:1, #5A3F0C 2.0:1 on a dark card). Tiles use warning / orange and never danger: attention, not blame — asserted.

File surface — one breach, flagged

test/metadata-bindings.test.ts is outside the surface the card named, and the change is not optional: that file's two tripwires fail the moment a dashboard nav entry exists ("teach walkNav about it before trusting the nav check"), which is the guard working as designed. It is taught the type — dashboardName resolved against the dashboards barrel, with self-test fixtures in both directions — and its nav-type tripwire now excludes the type it reads. Its comment records that this one, unlike viewName (#14108), is not an unguarded reference: defineStack refuses it. Everything else is on-surface: src/dashboards/*, the Team nav entry in src/apps/duly.app.ts, test/dashboard.test.ts. objectstack.config.ts, src/datasets/ and src/views/ are untouched.

What to look at in the browser

Acceptance is a running app, so the three things I could not verify from here:

1. oldest_touch — a min over a datetime. It should read as a date; if the KPI card renders a raw ISO string or an epoch number, that is a renderer formatting gap and I would rather file it than paper over it with an unverified options key.
2. Unit order on the by-unit chart — should be alphabetical by unit name per #3693.
3. coming_up bucket boundaries — ISO weeks (Monday start) wherever the driver does not truncate server-side; the window is [today, +14d], so the first and last buckets are partial weeks by construction.

In this open-edition checkout the hierarchy scopes resolve to owner-only (AGENTS.md rule 7), so every number will be scoped to the signed-in user rather than to their unit — that is the edition, not this dashboard.

---

Generated by Claude Code