[os-warren]

Requested by Warren · project thread

Fixes #100

What was wrong (re-measured on 18.2.0, main ac5b5c4)

I made a one_off duty with grace_days: 7 and created a task on it with due_date: 2026-11-10 and no stamp. It came back with late_after = 2026-11-10 for all three creates: a member's data.insert, a system create, and protocol.createData. That's zero grace. The overdue escalation waits out the week, but the Late lens listed the owner the morning after the due date. The demo's Commissioning file handover — Riverside upgrade row was the same.

The fix

The card says the hook "has no engine to read duly_duty with". That's no longer true on 18.2: a hook body runs as (async (ctx) => { … }) with ctx.api, and objectstack build infers api.read from the call. So the fix stays inside task.hook.ts, with no second writer on the write-once column and no new flow:

• beforeInsert: a row that carries a duty and a due_date but no stamp gets due_date + duty.grace_days. The planner uses the same rule.
• Update fill-a-blank leg: same rule, using the duty from the payload or the stored row. It is still skipped on the per-row (bulk) path.
• Unchanged: a row with no duty (the assignment fan-out, a member's own task) keeps zero grace. A blank or 0 grace is zero grace. A stamp the planner supplies is kept, and the duty is not read for it.

runAs: 'system', and exactly what it reaches

• Scope. Per the spec (hook.zod.ts, runAs), it governs the hook's ctx.api data operations only. Condition evaluation, the readonly strip on the payload and ctx.session are untouched, and the triggering write keeps its own context.
• What the elevation reaches. The body makes exactly one ctx.api call: ctx.api.object("duly_duty").findOne({ where: { id }, fields: ["grace_days"] }), where id is the task's own duty. Its only capability is ['api.read']. Both are pinned in test/task-hook-body.test.ts against the build's own extractor output.
• Why elevate. Without it, a creator who cannot see the duty would get null and a zero-grace deadline, which is the defect again.

Measured live on pnpm demo (this branch). Demo member Owen Pryce reads 0 duties because seed rows carry the admin's owner_id (#143):

Owen Pryce (duly_member)	result
GET /api/v1/data/duly_duty/<commissioning duty>	404 not found
POST /api/v1/data/duly_task on that duty, due_date 2026-11-10, late_after 2099-01-01 sent	201, late_after 2026-11-17 (sent value stripped, grace applied), created_by / owner_id = Owen
PATCH the admin's task created the same way	404: the task write is still authorized as Owen
PATCH own task	200
PATCH the duty's grace_days	403 PERMISSION_DENIED

The admin's create on the same duty also gives 2026-11-17.

Demo row, read through pnpm demo

Commissioning file handover — Riverside upgrade: due_date 2026-11-14 → late_after 2026-11-21 (was the due date). On the seeded database, every task with a duty has late_after = due_date + grace_days (0 mismatches across 206 rows). The 7 rows with no duty keep zero grace.

Tests

• test/task-hook.test.ts, new #100 block: member, system and protocol creates give due+7, month-end arithmetic matches the planner, a 0 or blank grace is zero grace, a row with no duty is zero grace, the planner's stamp is kept, the fill-a-blank update applies the grace, the stamp stays write-once after the duty's grace is widened, and runAs is declared. A duty id that resolves to nothing cannot reach the hook, because the engine refuses the dangling lookup first.
• test/task-hook-body.test.ts (new): the handler is lowered with @objectstack/cli/hook-body's extractHookBody (what os build uses), swapped into the real config with the function removed, and booted so AppPlugin binds it through the QuickJS body runner. As an ablation, changing the grace expression in the lowered source turns the two grace cases red, so the body is what runs.
• src/translations/authored-text.ts: hook.runAs classified as machine('execution identity'). The i18n coverage walk refuses an unclassified slot. This line was added under the Claim amendment on A task created by hand on a duty that grants grace is stamped late_after = due_date — the dispatcher is the only producer that applies grace_days #100.

pnpm validate 0 · pnpm typecheck 0 · pnpm test 1152/1152 · pnpm build 0. The build artifact's hook carries body.capabilities: ['api.read'] and runAs: 'system'.

Stale doc, left for its own card

AGENTS.md rule 5 still says late_after is "stamped at dispatch". After this PR it is stamped at creation: by the planner for a dispatched task, and by the hook for every other one. AGENTS.md is governed, so it is not edited here.

---

Generated by Claude Code

[objectstack-fleet]

席位核对

ACCEPT — PR #173 at head 12ef29a70ab36f99a2e485559c9d438987160e12 (duly lane seat, session session_011HyoSXGRy6L13mYq1Hp4n1, 2026-11-02T05:48Z). Implemented by the #100 card thread session_01JQwxbY1jQKPYfexaanSBNK under Claim comment 6569902632 and amendment 6570009456.

• Shape: base main ac5b5c4, one commit, Fixes #100, Clause-②: no, Metadata-protocol: none.
• Files (API list): src/hooks/task.hook.ts, src/objects/task.object.ts (the late_after comment), src/translations/authored-text.ts (the amended hook.runAs line), test/task-hook.test.ts, test/task-hook-body.test.ts (new). This is exactly the Claim plus its amendment. AGENTS.md is untouched, and there is no governed path.
• Gate: check-run verify success on 12ef29a, mergeable_state clean, and a local git merge-tree against main is clean.
• Read in the diff:
  • On insert, and in the update leg's fill-a-blank, a row carrying a duty and a due_date with no stamp gets late_after = due_date + duty.grace_days.
  • Only a positive whole grace counts. A row with no duty stays at zero grace, and a planner-stamped row is never read or rewritten.
  • A missing ctx.api throws, rather than stamping zero grace silently.
  • The hook is runAs: 'system'.
• ACCEPT condition, shown:
  • runAs governs ctx.api only, per the spec's scope note.
  • The body's single ctx.api call is findOne on the task's own duty with fields: ['grace_days'], and the lowered capabilities are ['api.read']. Both are pinned against the build's extractHookBody output.
  • Live, demo member Owen Pryce: POST of a task on a duty he cannot read is 201, and its created_by/owner_id are Owen. His PATCH on another person's task is 404, and his read of the duty's grace_days is 403. So the task write is still authorized as its caller.
• Measured:
  • A one-off duty with grace 7 and a task due 2026-11-10 now gives late_after 2026-11-17 on member, system and protocol creates.
  • The lowered body run in QuickJS gives the same, and an ablation turns it red.
  • On pnpm demo, 0 of 206 tasks with a duty are off due + grace, and the 7 tasks with no duty stay at zero grace.
• Routed elsewhere: AGENTS.md rule 5 ("stamped at dispatch") is now stale. That is governed and is noted for the maintainer.
  • The live check also showed that a member can create a task on a duty they cannot read. That predates this PR and is filed as its own card.
• Landing: direct-merge repo. The seat flips the PR ready and squash-merges it with expected_head_sha pinned.

---

Generated by Claude Code

[objectstack-fleet]

Landed

Seat landing at 2026-11-02T05:50Z (duly lane seat, session session_011HyoSXGRy6L13mYq1Hp4n1). The seat flipped the PR ready through the relay, then squash-merged it with expected_head_sha 12ef29a pinned.

probe	reading
PR object	merged: true, merge_commit_sha 98c188a
origin/main by content	98c188a, single parent ac5b5c4; duly_task_lifecycle_stamps is runAs: 'system' and reads grace_days for the row's duty

State: #100 is closed completed by Fixes #100, and pm:dispatched is removed. The pre-existing finding from the live authorization check (a member can create a task on a duty they cannot read) is filed as its own card.

---

Generated by Claude Code