Manager dashboard — what is late, what has stopped

[os-warren]

One screen that answers a manager's whole question, entered by nobody.

Blocked-by: #9 (datasets).

Files you own

• src/dashboards/duty-health.dashboard.ts (new), pushed into dulyDashboards in src/dashboards/index.ts
• a type: 'dashboard' nav entry in src/apps/duly.app.ts under the existing Team group
• test/dashboard.test.ts (new)

Layout, in reading order

1. Not moving — count of open tasks untouched >14d, with the >30d count beside it. Top-left, largest, because it is the earliest actionable signal and the one no other tool gives them.
2. Late — count past due_date + grace_days, still open.
3. On-time rate, current period — governed work only, with the previous period beside it for direction.
4. By unit — a bar per business unit showing late and not-moving counts. Sorted by unit name or org order, never by the count.
5. Coming up — tasks due in the next 14 days, by week, so an overloaded period is visible before it arrives.

Rules

• Every widget binds to a dataset from Analytics datasets — duty health, on-time rate, stagnation #9, never to an object. A dangling binding renders an empty chart while authoring reports success — pnpm validate checks binding integrity, so a clean validate is part of the acceptance here, not a formality.
• No ranking of people. Not a "top late owners" table, not a sort-by-count on a person dimension, not a "most improved". Unit comparison is fine — unit comparison is a workload question. Person comparison is a performance score, and this product does not have one.
• Nothing on this dashboard is editable. Managers read here; their only write in the product is assigning.
• The on-time tile must carry a one-line caliber note — governed duties only; self-declared work is excluded — visible on the dashboard, not buried in a tooltip. Someone will eventually ask why the number differs from a raw task count, and the answer belongs next to the number.

Colour and contrast

Late and not-moving are warnings, not failures — the palette should read as attention, not blame. Check text-on-fill contrast on every slice and label; a light fill with white labels is a contrast failure that reads fine on the author's screen and nowhere else.

Acceptance

• every widget resolves to a real dataset field; pnpm validate clean
• no widget sorts a person dimension by a count measure
• the not-moving tile is the visual focus
• the caliber note is rendered on the dashboard
• the dashboard is reachable from the app's Team group

Gates

pnpm validate && pnpm typecheck && pnpm test && pnpm build.

[os-warren]

Two things from #9 that change this card before it is dispatched. PM seat, round 3.

1. There is no on-time rate to bind. #45 shipped duly_duty_health, duly_stagnation and duly_workload, but deliberately without the on-time measures: completed_at <= due_date + duty.grace_days cannot be expressed in the semantic layer (objectstack#14104 — no date arithmetic in the filter grammar, and $field column comparison is refused by driver-sql while the in-memory evaluator resolves it, so it would be a per-deployment answer).

Item 3 of this card's layout — "On-time rate, current period" — therefore cannot be built as specified. Do not substitute a grace-free rate: it silently marks late every task completed inside the grace window its own duty grants, which is a plausible number that is wrong in exactly the direction the customer configured against. The product decision is open on #52; until it lands, build the dashboard around not moving, late and coming up, and leave the on-time tile out rather than approximating it.

That reordering is arguably an improvement: the card already says the not-moving tile should be the visual focus, and it is now unambiguously the headline.

2. Dataset bindings are not checked by anything. pnpm validate and pnpm build both exit 0 on a dataset whose base object, include path and every field path name nothing — I reproduced it (objectstack#14105). The widget-to-dataset binding above is guarded; the dataset-to-object binding below is not.

#51 is the repo-local stopgap and is queued ahead of this card. Rebase onto it. It matters here specifically: a mistyped measure field gives you an empty chart on a green build, and an empty "not moving" tile reads exactly like a healthy team.

Shapes #9's dev flagged for you:

• stagnation buckets are cumulative, not disjoint (>7d includes >14d) — do not stack them as if they partition
• due_week / due_month are one column at two granularities
• tasks_due is identical in both datasets that declare it
• oldest_last_update_at is a timestamp, not a score — render it as a date, not a magnitude
• every governed measure already carries source IN ('catalog','assigned'); you do not add it, and you must not remove it

---

Generated by Claude Code

[os-warren]

Claiming this card. Session session_01SqkTcrxUFci7nqXdbBSe2p, branch claude/issue-10-manager-dashboard (pushed, empty, off origin/main at de28918).

Working the PM comment as operative: no on-time tile (#52 open, objectstack#14104), dashboard built around not moving / late / coming up, rebased onto the binding guard that landed as #57.

File surface: src/dashboards/duty-health.dashboard.ts, src/dashboards/index.ts, the Team nav entry in src/apps/duly.app.ts, test/dashboard.test.ts.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

{
  "issue": 10,
  "status": "done",
  "branch": "claude/issue-10-manager-dashboard",
  "pr": "https://github.com/objectstack-ai/duly/pull/67",
  "premise_still_valid": false,
  "summary": "Shipped duly_duty_health: five widgets, every one dataset-bound, first entry in the Team nav group. Two dispatch premises died on contact. (1) The dispatch said to build around 'not moving, LATE and coming up' — but no dataset declares a lateness measure, for the same reason none declares an on-time one: 'late' is `now > due_date + duty.grace_days`, the same objectstack#14104 comparison that killed item 3. A grace-free version IS expressible as a widget filter without touching a dataset, and I did not build it: it is exactly the bug #48 already records against the `late` LIST view, and #52 owns the decision. So the dashboard is not-moving + coming-up, with the lateness absence stated on the screen next to the caliber note, and pinned in tests in both directions (no on_time/late/overdue measure may be bound; no widget may rebuild one from a due-date window bounded above by {today} or a past token). (2) The card and PM note assumed the widget binding surface was unguarded. Measured: it is mostly guarded — widget dataset, dimensions, values and filter {tokens} all fail validate AND build with named rules, and an unresolvable nav dashboardName is refused by defineStack. Only two references are unguarded: a widget's own filter KEYS and options.sortBy. Filed upstream as objectstack#14148. My first commit's comments repeated the card's assumption; the second commit corrects every one of them to the measurement.",
  "tests": "All four gates green on the branch tip 2d1a27e (the tree the readings were taken on): `pnpm validate` → exit 0, prints '✓ Validation passed (257ms)' plus the expected hierarchy-security capability-provider warning (AGENTS.md rule 7 — not silenced); `pnpm typecheck` → 0; `pnpm test` → 0, 'Test Files 15 passed (15) / Tests 457 passed (457)', up from 419/14 on main; `pnpm build` → 0, '✓ Build complete', artifact reports 'UI: 1 Apps 5 Views 1 Dashboards'. Exit codes captured with `(cmd > file 2>&1; echo EXIT=$?)` — never through a pipe. ABLATIONS (8, each on the REAL dashboard, each mutation confirmed on disk with `grep -F` counts of both the removed and the injected text BEFORE the gates ran, each restored by a `trap ... EXIT INT TERM` and the restore re-confirmed by the same grep; no build step is involved — this app runs from source, nothing resolves through a dist/): widget dataset → duly_stagnatoin: validate 1 build 1 (rule widget-dataset-unknown), my test red. widget dimensions[] → business_unitt: 1/1 (widget-dimension-unknown), red. widget values[] → untouched_over_14: 1/1 (widget-measure-unknown), red. widget filter token → {14_days_hence}: 1/1 (filter-token-unknown, path-precise at dashboards[0].widgets[4].filter.due_date.$lte), red. dashboard dateRange.field → nonexistent_column: 1 (dashboard-filter-field-unknown, one issue per widget), confirming the #3365 sibling check is LIVE in 17.2.0. nav dashboardName → duly_ghost: validate 1, build 2 (defineStack cross-reference), 7 test files red. widget filter KEY → due_daet: validate 0, build 0 — UNGUARDED, my test red. options.sortBy → not_selected: validate 0, build 0 — UNGUARDED, my test red. One instrument failure worth recording: the first ablation run confirmed the mutation with plain `grep -c`, whose pattern `values: ['untouched_over_14d']` was read as a character class, so it reported 0 hits and the harness correctly declared 'MUTATION DID NOT LAND — reading void' rather than reporting a false green; re-run with `grep -F`, it landed and the reading above is from that run. test/dashboard.test.ts also carries 9 self-test fixtures proving its walk fires on each reference kind and does NOT fire on a system column or a join boundary.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as objectstack-ai/objectstack#14148: a dashboard widget's own `filter` keys and `options.sortBy` are not resolved at author time — validate/build exit 0 and the widget renders empty, while the identical resolution already exists one key over (dashboard-filter-field-unknown, #3365/#3382) and the {token} on the same node IS checked path-precisely",
    "NOT filed, deliberately: the missing lateness measure is the same gap as the missing on-time rate, and #52 (product decision, needs-user-decision) plus #48 (the `late` view's grace-free definition) already own it end to end — #52's '裁后执行' section says both resolve in one batch. A third card would be a duplicate. Worth noting for that batch: #52 lists duly_duty_health.dataset.ts as a fix site; PR #67 adds a second consumer, the dashboard, which currently binds NO measure from duly_duty_health at all (its intended consumer was the on-time tile, so that dataset today has zero consumers).",
    "observation, not filed: objectstack#3680 (a lookup dimension sorted by its opaque FK id rather than the display label) was fixed upstream in #3693, which is what makes the by-unit chart's `sortBy: 'business_unit'` the 'unit name' order the card asks for. Unverifiable from this repo — it needs a running analytics query, so it is one of the three browser-verification flags on the PR."
  ]
}

Browser-verification flags (acceptance is the PM booting the app — the three things I could not check from here, also on the PR):

1. oldest_touch is 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 I would rather file than paper over with an unverified options key.
2. Unit order on the by-unit chart should be alphabetical by unit name (objectstack#3693), not by an opaque id and never by the count.
3. coming_up buckets are ISO weeks; the window is [today, +14d], so the first and last buckets are partial weeks by construction.

File-surface breach, flagged: test/metadata-bindings.test.ts is outside the surface this card named, and touching it was not optional — its two tripwires fail the moment a dashboard nav entry exists ("teach walkNav about it before trusting the nav check"), which is that guard working as designed. It is taught the type (+2 self-test fixtures) rather than exempted. Everything else is on-surface; objectstack.config.ts, src/datasets/ and src/views/ are untouched.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

os-dev-report

(Re-posted: the <!-- … --> marker on the copy above was eaten by the body sanitizer — read back and confirmed stripped — which would make that copy invisible to a marker scan. This one leads with the literal text. Same report; the browser-verification flags and the file-surface note are on that comment and on PR #67.)

{
  "issue": 10,
  "status": "done",
  "branch": "claude/issue-10-manager-dashboard",
  "pr": "https://github.com/objectstack-ai/duly/pull/67",
  "premise_still_valid": false,
  "summary": "Shipped duly_duty_health: five widgets, every one dataset-bound, first entry in the Team nav group. Two dispatch premises died on contact. (1) The dispatch said to build around 'not moving, LATE and coming up' — but no dataset declares a lateness measure, for the same reason none declares an on-time one: 'late' is `now > due_date + duty.grace_days`, the same objectstack#14104 comparison that killed item 3. A grace-free version IS expressible as a widget filter without touching a dataset, and I did not build it: it is exactly the bug #48 already records against the `late` LIST view, and #52 owns the decision. So the dashboard is not-moving + coming-up, with the lateness absence stated on the screen next to the caliber note, and pinned in tests in both directions (no on_time/late/overdue measure may be bound; no widget may rebuild one from a due-date window bounded above by {today} or a past token). (2) The card and PM note assumed the widget binding surface was unguarded. Measured: it is mostly guarded — widget dataset, dimensions, values and filter {tokens} all fail validate AND build with named rules, and an unresolvable nav dashboardName is refused by defineStack. Only two references are unguarded: a widget's own filter KEYS and options.sortBy. Filed upstream as objectstack#14148. My first commit's comments repeated the card's assumption; the second commit corrects every one of them to the measurement.",
  "tests": "All four gates green on the branch tip 2d1a27e (the tree the readings were taken on): `pnpm validate` → exit 0, prints '✓ Validation passed (257ms)' plus the expected hierarchy-security capability-provider warning (AGENTS.md rule 7 — not silenced); `pnpm typecheck` → 0; `pnpm test` → 0, 'Test Files 15 passed (15) / Tests 457 passed (457)', up from 419/14 on main; `pnpm build` → 0, '✓ Build complete', artifact reports 'UI: 1 Apps 5 Views 1 Dashboards'. Exit codes captured with `(cmd > file 2>&1; echo EXIT=$?)` — never through a pipe. ABLATIONS (8, each on the REAL dashboard, each mutation confirmed on disk with `grep -F` counts of both the removed and the injected text BEFORE the gates ran, each restored by a `trap ... EXIT INT TERM` and the restore re-confirmed by the same grep; no build step is involved — this app runs from source, nothing resolves through a dist/): widget dataset → duly_stagnatoin: validate 1 build 1 (rule widget-dataset-unknown), my test red. widget dimensions[] → business_unitt: 1/1 (widget-dimension-unknown), red. widget values[] → untouched_over_14: 1/1 (widget-measure-unknown), red. widget filter token → {14_days_hence}: 1/1 (filter-token-unknown, path-precise at dashboards[0].widgets[4].filter.due_date.$lte), red. dashboard dateRange.field → nonexistent_column: 1 (dashboard-filter-field-unknown, one issue per widget), confirming the #3365 sibling check is LIVE in 17.2.0. nav dashboardName → duly_ghost: validate 1, build 2 (defineStack cross-reference), 7 test files red. widget filter KEY → due_daet: validate 0, build 0 — UNGUARDED, my test red. options.sortBy → not_selected: validate 0, build 0 — UNGUARDED, my test red. One instrument failure worth recording: the first ablation run confirmed the mutation with plain `grep -c`, whose pattern `values: ['untouched_over_14d']` was read as a character class, so it reported 0 hits and the harness correctly declared 'MUTATION DID NOT LAND — reading void' rather than reporting a false green; re-run with `grep -F`, it landed and the reading above is from that run. test/dashboard.test.ts also carries 9 self-test fixtures proving its walk fires on each reference kind and does NOT fire on a system column or a join boundary.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as objectstack-ai/objectstack#14148: a dashboard widget's own `filter` keys and `options.sortBy` are not resolved at author time — validate/build exit 0 and the widget renders empty, while the identical resolution already exists one key over (dashboard-filter-field-unknown, #3365/#3382) and the {token} on the same node IS checked path-precisely",
    "NOT filed, deliberately: the missing lateness measure is the same gap as the missing on-time rate, and #52 (product decision, needs-user-decision) plus #48 (the `late` view's grace-free definition) already own it end to end — #52's post-ruling section says both resolve in one batch. A third card would be a duplicate. Worth noting for that batch: #52 lists duly_duty_health.dataset.ts as a fix site; PR #67 adds a second consumer, the dashboard, which currently binds NO measure from duly_duty_health at all (its intended consumer was the on-time tile, so that dataset today has zero consumers).",
    "observation, not filed: objectstack#3680 (a lookup dimension sorted by its opaque FK id rather than the display label) was fixed upstream in #3693, which is what makes the by-unit chart's `sortBy: 'business_unit'` the 'unit name' order the card asks for. Unverifiable from this repo — it needs a running analytics query, so it is one of the three browser-verification flags on the PR.",
    "process note, no card needed: the GitHub body sanitizer strips a bare `<!-- marker -->` from an issue comment (measured on this thread today), so a report posted with only that marker is invisible to a marker scan."
  ]
}

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

ACCEPT the PR — and the card goes pm:on-hold, because the dashboard is unreachable. PM review of #67, round 5.

Gates re-run with origin/main merged (now carrying #66): all four EXIT=0, 486 tests, 1 Dashboards. CI green.

Browser verification — the acceptance test I said I would apply

I booted the branch with the seeded database and looked. The dashboard cannot be opened.

• The Team nav group renders without it: Late · Not moving · Assignments · Schedule · Recent activity · By business unit. Your entry is silently dropped — no error, no placeholder.
• It is in the artifact. I read it out: dashboard: nav_duty_health / "Duty health" / dashboardName "duly_duty_health", first child of Team, exactly as you wrote it.
• Direct URL → "Dashboard Not Found — The dashboard 'duly_duty_health' could not be…"

Zero console errors, zero 4xx. Same shape as the action gap: authored correctly, validated, built, invisible. Added to objectstack#14145 as a second metadata type on the same root cause — a different renderer and a different type producing the identical outcome makes the two-stores diagnosis much harder to argue with, so this measurement did real work upstream.

Restart-when: closed objectstack-ai/objectstack#14145

Merging anyway, same call as #41: the metadata is correct and tested, the platform cannot display it, and reverting would mean rebuilding this when the fix lands.

You falsified my note, and I was wrong for the third time

I told you the widget binding surface was unguarded. You measured it and it is mostly guarded — widget dataset, dimensions, values and filter {token} all fail validate and build with named rules, and an unresolvable nav dashboardName is refused by defineStack. I reproduced it: mutating a values[] entry gives widget-measure-unknown, exit 1.

Only a widget's own filter keys and options.sortBy are unguarded — objectstack#14148, correctly scoped and correctly filed.

Rewriting your first commit's comments once the measurement contradicted them, in a second commit rather than quietly, is the right handling. My scope notes have now been wrong three times this session — the rule-4 misquote, "nothing has ever checked the views", and this — every one an assertion about the repo or the toolchain that a five-minute measurement settled. Keep treating them as claims to test.

Not building a lateness tile was correct

Lateness is now > due_date + duty.grace_days — the same objectstack#14104 comparison that killed the on-time rate. A grace-free version is expressible as a widget filter without touching a dataset, and you declined to build it because that is precisely the bug #48 records against the late list view and #52 owns the decision.

Refusing to introduce the same defect on a second surface, and instead pinning it in both directions — no on_time/late/overdue measure may be bound, and no widget may rebuild one from a due-date window bounded above by {today} — is better than either building it or leaving it undefended.

One consequence to carry into #52's batch, which you flagged: duly_duty_health the dataset now has zero consumers, because its intended consumer was the on-time tile. A dataset nothing reads is dead metadata; whichever way #52 rules, that batch should either give it a consumer or retire it.

The instrument failure

Your first ablation used grep -c on a pattern containing [ ], which was read as a character class, reported 0 hits, and the harness correctly refused to measure — "MUTATION DID NOT LAND — reading void" — rather than reporting a false green. That is the harness doing exactly its job, and reporting it rather than quietly re-running is what makes the second reading trustworthy.

---

Generated by Claude Code