[os-warren]

Requested by Warren · project thread

Fixes #176

Step 0, measured

On main 94419c6, @objectstack 18.2.0, live pnpm demo. The callers were member Owen and manager Marek, whose report is Sami. All 24 writes were accepted. The doors were data POST and PATCH and MCP create and update. The writes were source: catalog, owner: Sami, and a foreign business_unit. Sami reads 0 of the tasks naming him (#143). A hand-made task got no business unit at all. No conflict with #143: after this change, every caller-written task has owner = owner_id = the writer. Full report: project file duly-176-task-provenance/step0.md.

Change

• TASK_PROVENANCE_LOCK (src/security/permission-sets.ts) sits on duly_member, duly_manager and duly_admin. It sets duly_task.source, owner and business_unit to readable: true, editable: false. The platform's field-level write gate then refuses any payload that names one of them, on every door, with 403 Field write denied: not permitted to edit [<field>].
  • owner defaults to the writer, so a caller creates tasks only for themselves. Per the seat's ruling, a manager follows the same rule. Their door for a report's work is duly_assignment.
  • source defaults to self.
  • The same map is on all three sets. Only declaring sets vote, and no Duly role hand-writes another person's task.
• business_unit stamp (duly_task_lifecycle_stamps, already runAs: 'system'). On a non-system insert with no unit, it reads the owner's primary_business_unit_id. That is the same rung the fan-out reads. The FLS gate judges only the caller's payload, so the hook's write lands.
• Why not readonly. A readonly field is validated shape-only, so required stops being checked. Measured: a system insert with owner: null then commits an ownerless task, which breaks the Assignment fan-out to a removed account creates a task silently: the system write skips the reference check #148 fan-out refusal. The first commit on this branch used readonly plus an owner guard hook. The second commit replaces both with the lock, after A member can create a duty with source catalog, another person as owner and a foreign business unit #178 showed that the console honours FLS on the form. Seat amendment comment 6571067672.
• Tests. Three A member can create a task on a duty they cannot read, and it counts in that duty's health readings #174 tests in test/task-duty-access.test.ts sent source or owner, so the lock now refuses them first. They now leave those keys out, or expect the lock's refusal. test/task-hook-body.test.ts pins the second elevated read.

Verify

• pnpm validate, typecheck, test (44 files, 1238 tests) and build are all green.
• The new test/task-provenance.test.ts (61 tests) runs as a real member, a real manager and a member + duly_admin co-holder, through SecurityPlugin, SharingServicePlugin and buildContextForUser:
  • For each of the three fields, these are refused: data POST, data PATCH (nothing of the write lands), MCP create and update, updateMany, and a predicate multi update.
  • A task that names none of the three is the writer's, self, and in the owner's unit. An edit that names none of them saves.
  • Still written as before: runDispatch (catalog, the duty's owner and unit); the fan-out run with { isSystem, userId: manager } (assigned, the assignee's unit); and the seed context.
  • owner: null from the system is still refused with "Owner is required".
  • Mutation checks: with the lock removed from the sets, 49 of 61 go red; with the BU stamp removed, 6 go red.
• Live pnpm demo on this branch:

as Owen (member) and as Marek (manager)	answer
POST / PATCH / MCP create / MCP update naming source, owner or business_unit	403 / isError PERMISSION_DENIED, "Field write denied", 24 of 24
POST naming none	201: owner = writer, self, the writer's unit
fan-out from Marek's assignment to Sami	Sami's task: assigned, Sami's unit
seed	150 catalog and 8 assigned tasks, all with a unit

• Browser, member, en-US and zh-CN: on the create and edit forms, Source (来源) and Business unit (部门) render disabled. Clicking BU opens nothing. The form's POST is {status, subject} → 201, and its PATCH sends only the changed field → 200.

Not in this PR

• The same shape on duly_duty is A member can create a duty with source catalog, another person as owner and a foreign business unit #178.
• Members and managers get 403 reading sys_business_unit, so a task's unit shows as a raw id on the record page and blank on the edit form. That predates this PR and is tracked in A member's task and duty pages show the business unit as a raw id, because Duly members and managers cannot read sys_business_unit #180.
• AGENTS.md is governed and was not touched. Its "which layer refuses" caveat is noted on Correct the AGENTS.md claims the @objectstack 18 upgrade made false #157.

---

Generated by Claude Code

[objectstack-fleet]

席位核对

ACCEPT — PR #182 at head 5c46eb19368b9fd244736542df6d888ae8598df3 (duly lane seat, session session_011HyoSXGRy6L13mYq1Hp4n1, 2026-11-02T07:07Z). Implemented by the #176 card thread session_01JQwxbaGDrSsQpv7GZxtDyZ under Claim comment 6570818262 and amendment 6571067672.

• Shape: base main 94419c6, Fixes #176, Clause-②: no, Metadata-protocol: none.
• Files (API list): src/security/permission-sets.ts, src/hooks/task.hook.ts, src/objects/task.object.ts (comments only), test/task-duty-access.test.ts, test/task-hook-body.test.ts, test/task-provenance.test.ts (new, 61 tests). This is inside the Claim as amended. There is no readonly change and no owner guard, and no governed path.
• Gate: check-run verify success on 5c46eb1, mergeable_state clean, and a local git merge-tree against main is clean.
• Mechanism (amended from readonly): TASK_PROVENANCE_LOCK sets duly_task.source, owner and business_unit to editable: false on all three Duly sets.
  • It is on all three because the field gate is a most-permissive merge among the sets that declare: a set that says nothing lifts nothing.
  • A platform administrator is not bound.
  • duly_task_lifecycle_stamps stamps the unit from the owner's primary unit on a non-system insert. The gate judges the caller's payload, not a hook's write.
• Measured (live demo):
  • Member Owen and manager Marek, through data POST, data PATCH, MCP create and MCP update, naming any of the three: refused, 403 Field write denied (MCP PERMISSION_DENIED). That is 24 of 24.
  • A plain POST gets 201 with owner = writer, source self and the writer's unit.
  • System writers still write all three. The fan-out gives Sami's task source assigned with Sami's unit. A live dispatch gave 2 tasks with source catalog and a unit. The seed wrote 158 tasks, all with a unit.
  • A system owner: null is still refused (required), which keeps the Assignment fan-out to a removed account creates a task silently: the system write skips the reference check #148 refusal.
• Browser (project files duly-176-task-provenance/browser-fls/, en-US and zh-CN, as member 周文博 / Owen):
  • Source and Business unit render disabled on create and edit.
  • Create saves 201 and edit saves 200.
• Accepted:
  • Naming your own current value is refused too. The console never sends it.
  • duly_admin is locked on task provenance, because no Duly role hand-writes another person's task.
  • The raw-id business unit a member sees is A member's task and duty pages show the business unit as a raw id, because Duly members and managers cannot read sys_business_unit #180, and no read was granted here.
• Serial: A member can create a duty with source catalog, another person as owner and a foreign business unit #178 adds a duly_duty field map to the same sets and lands after this, merging main.
• 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-02T07:08Z (duly lane seat, session session_011HyoSXGRy6L13mYq1Hp4n1). The seat flipped the PR ready through the relay, then squash-merged it with expected_head_sha 5c46eb1 pinned.

probe	reading
PR object	merged: true, merge_commit_sha 3395a9a
origin/main by content	3395a9a, single parent 94419c6; the three Duly sets carry TASK_PROVENANCE_LOCK

State: #176 is closed completed by Fixes #176, and pm:dispatched is removed. #178 (PR #181) merges main before it lands.

---

Generated by Claude Code