Assignment fan-out — one piece of work becomes N independent tasks

[os-warren]

Fixes#6

A record_change flow on duly_assignment that turns a dispatched assignment into N duly_task rows — one owner each — plus, only when needs_collection is ticked, one follow-up task for the assigner.

Verified on e3cbb28. All four gates green on that commit (see Gates below).

The three PM assumptions, all verified against engine source

Assumption	Verdict
A record_change flow can detect a transition into status = 'dispatched', not merely observe the state	True — but deliberately not used. See below.
A loop node with config: { collection, iteratorVariable, body: { nodes, edges } } can create a record per iteration	True.LoopConfigSchema carries exactly those keys; loop-node.ts runs the body via runRegion per item in the shared variable scope, and the body is an arbitrary sub-graph, so create_record inside it is supported.
Field.user({ multiple: true }) on assignees gives the loop an iterable array	True. It authors { type: 'user', reference: 'sys_user', multiple: true } and stores an array of sys_user ids. interpolate() returns the raw value when the whole string is a single token, so '{record.assignees}' resolves to the array itself, not its toString.

Two premises that did not survive contact — please read

1. The trigger does not bind where the issue implies

FlowSchema is .strict() and carries neitherobjectnortrigger. Writing either is a parse error, and the schema says where to go instead:

object is not a Flow field — a record-change flow binds its object on the START node's config ({ objectName, triggerType, condition }), not at the flow top level.

The engine's resolveTriggerBinding reads exactly those three keys off the start node, and reads objectName only (object is a load-time alias for the CRUD nodes, not for the trigger). Confirmed independently by the validator resolving record.needs_collection against duly_assignment — it could only know the bound object from that start-node config.

Worth knowing: the CLI's own objectstack generate scaffold still emits the rejected shape — top-level trigger: { type, object, events: ['after_insert', …] } and nodes with name/next instead of the required label. That scaffold cannot pass validate against 17.2.0. Reported separately for routing; nothing to do in this repo.

2. The gate is the dispatched STATE, not the transition into it

The dispatch note asked me to test this rather than paper over it, so, in full.

The platform can see a transition. AutomationContext.previous is documented for exactly this (status == "done" && previous.status != "done") and seedRunVariables binds it on every run. The design still must not depend on it, for two independent reasons:

It breaks the sixth assignee. Adding a name to an already-dispatched assignment moves no status. A transition gate fires zero times and creates zero tasks, where the acceptance criteria say exactly one. Criterion 3 ("re-saving creates 0 more") would also pass vacuously — for the wrong reason.

It faults the flow on insert.variables.set('previous', context?.previous ?? null) — previous is bound to null on an insert, and CEL field access through a null root aborts the predicate. evaluateCondition never swallows that to false; it throws (ADR-0032 §1c). So previous.status != "dispatched" would fail every assignment born directly as dispatched — an import, a REST create, a seed.

record.status cannot fail the same way: the record-change trigger runs materializeDeclaredFields over both CEL roots, so every declared field of duly_assignment is present, at worst as null.

So: triggerType: 'record-after-write' (the afterInsert + afterUpdate union) with condition: record.status == "dispatched". Idempotency is carried entirely by the guard below, which had to exist anyway.

Idempotency — explicit, and per OWNER

The (duty, owner, period_key) unique index does not constrain these rows: a fan-out task sets neither duty nor period_key. As the issue says, it will not protect us, so the guard is explicit. Each loop iteration reads duly_task where { assignment, owner } and creates only on a miss.

Per owner, not per assignment — a per-assignment guard finds the first of the five tasks and creates nothing for a sixth assignee. That exact bug is ablated in the test below.

The guard keys on (assignment, owner) and deliberately not on subject. A subject-aware guard would mint a duplicate task for every owner the moment somebody edits the assignment's subject and re-saves — a worse failure than the one it would prevent.

One consequence, stated so it is a decision and not an accident: an assigner who is also one of the assignees already owns a task on this assignment, so needs_collection adds no second one for them. That reads as correct to me — one task per owner per assignment is the invariant, and a manager does not need two rows for one piece of work — but it is a product call, so flagging it.

existing_task / existing_assigner_task are declared variables with defaultValue: null. get_record returns early without setting its outputVariable when no data engine is registered, and an unbound name aborts a strict-CEL predicate rather than yielding false; a declared default removes the unbound state, which is the platform's own stated remedy.

What this deliberately does not do

• No status or progress field is written. task_count is a Field.summary computed on read; nothing here writes back to duly_assignment at all. A test asserts every write node targets duly_task.
• period_key is not set — the key is absent from both create_record nodes, not set to ''.
• The assigner gets nothing unless needs_collection is true; the default out-edge routes straight past that branch.
• No display text is hard-coded. The follow-up task reuses {record.subject} rather than an inlined literal, since English is the source language and authored labels belong in a bundle.

Gates

Run under the shared verify lock on e3cbb28, worktree clean:

VALIDATE_EXIT=0 ✓ Validation passed (299ms) · Logic: 1 Flows
TYPECHECK_EXIT=0 tsc --noEmit, no output
TEST_EXIT=0 Test Files 2 passed (2) · Tests 36 passed (36)
BUILD_EXIT=0 ✓ Build complete (291ms) · Logic: 1 Flows

Reverse verification — three ablations, each confirmed on disk before measuring

1. record. → bare status. Mutation on disk (injected 1, removed 0) → validateexit 0, still passed. validate deliberately does not flag bare identifiers inside a flow (collectBoundRecordReads: "Deliberately NEVER a bare identifier"). So a clean validate is not evidence on this point — the dispatch note's expectation here was inverted. Filed as No gate catches a bare field reference in a flow predicate — and AGENTS.md claims there is one #29 with the measurement.
2. record.needs_collection → record.needs_colection. Mutation on disk → validateexit 1, located: unknown field `needs_colection` on `duly_assignment` — did you mean `needs_collection`? This is the gate that is real, and it proves the green run above is a measurement rather than a vacuous pass.
3. Guard filter { assignment, owner } → { assignment } (the per-assignment bug). Mutation on disk → pnpm testexit 1, one failure, the guard filters per OWNER, not per assignment; validate stayed exit 0. The test is the only thing standing between this repo and that bug.

Each ablation script carried a trap … EXIT INT TERM restore; the tree was verified clean after each.

Files

• src/flows/assignment.flow.ts (new)
• src/flows/index.ts — added to dulyFlows
• test/assignment-fanout.test.ts (new, 28 tests)

objectstack.config.ts untouched — the barrel was already wired on main. No changeset: this repo has no .changeset/.

---

Generated by Claude Code

[os-warren]

Fixes#6

A record_change flow on duly_assignment that turns a dispatched assignment into N duly_task rows — one owner each — plus, only when needs_collection is ticked, one follow-up task for the assigner.

Verified on e3cbb28. All four gates green on that commit (see Gates below).

The three PM assumptions, all verified against engine source

Assumption	Verdict
A record_change flow can detect a transition into status = 'dispatched', not merely observe the state	True — but deliberately not used. See below.
A loop node with config: { collection, iteratorVariable, body: { nodes, edges } } can create a record per iteration	True.LoopConfigSchema carries exactly those keys; loop-node.ts runs the body via runRegion per item in the shared variable scope, and the body is an arbitrary sub-graph, so create_record inside it is supported.
Field.user({ multiple: true }) on assignees gives the loop an iterable array	True. It authors { type: 'user', reference: 'sys_user', multiple: true } and stores an array of sys_user ids. interpolate() returns the raw value when the whole string is a single token, so '{record.assignees}' resolves to the array itself, not its toString.

Two premises that did not survive contact — please read

1. The trigger does not bind where the issue implies

FlowSchema is .strict() and carries neitherobjectnortrigger. Writing either is a parse error, and the schema says where to go instead:

object is not a Flow field — a record-change flow binds its object on the START node's config ({ objectName, triggerType, condition }), not at the flow top level.

The engine's resolveTriggerBinding reads exactly those three keys off the start node, and reads objectName only (object is a load-time alias for the CRUD nodes, not for the trigger). Confirmed independently by the validator resolving record.needs_collection against duly_assignment — it could only know the bound object from that start-node config.

Worth knowing: the CLI's own objectstack generate scaffold still emits the rejected shape — top-level trigger: { type, object, events: ['after_insert', …] } and nodes with name/next instead of the required label. That scaffold cannot pass validate against 17.2.0. Reported separately for routing; nothing to do in this repo.

2. The gate is the dispatched STATE, not the transition into it

The dispatch note asked me to test this rather than paper over it, so, in full.

The platform can see a transition. AutomationContext.previous is documented for exactly this (status == "done" && previous.status != "done") and seedRunVariables binds it on every run. The design still must not depend on it, for two independent reasons:

It breaks the sixth assignee. Adding a name to an already-dispatched assignment moves no status. A transition gate fires zero times and creates zero tasks, where the acceptance criteria say exactly one. Criterion 3 ("re-saving creates 0 more") would also pass vacuously — for the wrong reason.

It faults the flow on insert.variables.set('previous', context?.previous ?? null) — previous is bound to null on an insert, and CEL field access through a null root aborts the predicate. evaluateCondition never swallows that to false; it throws (ADR-0032 §1c). So previous.status != "dispatched" would fail every assignment born directly as dispatched — an import, a REST create, a seed.

record.status cannot fail the same way: the record-change trigger runs materializeDeclaredFields over both CEL roots, so every declared field of duly_assignment is present, at worst as null.

So: triggerType: 'record-after-write' (the afterInsert + afterUpdate union) with condition: record.status == "dispatched". Idempotency is carried entirely by the guard below, which had to exist anyway.

Idempotency — explicit, and per OWNER

The (duty, owner, period_key) unique index does not constrain these rows: a fan-out task sets neither duty nor period_key. As the issue says, it will not protect us, so the guard is explicit. Each loop iteration reads duly_task where { assignment, owner } and creates only on a miss.

Per owner, not per assignment — a per-assignment guard finds the first of the five tasks and creates nothing for a sixth assignee. That exact bug is ablated in the test below.

The guard keys on (assignment, owner) and deliberately not on subject. A subject-aware guard would mint a duplicate task for every owner the moment somebody edits the assignment's subject and re-saves — a worse failure than the one it would prevent.

One consequence, stated so it is a decision and not an accident: an assigner who is also one of the assignees already owns a task on this assignment, so needs_collection adds no second one for them. That reads as correct to me — one task per owner per assignment is the invariant, and a manager does not need two rows for one piece of work — but it is a product call, so flagging it.

existing_task / existing_assigner_task are declared variables with defaultValue: null. get_record returns early without setting its outputVariable when no data engine is registered, and an unbound name aborts a strict-CEL predicate rather than yielding false; a declared default removes the unbound state, which is the platform's own stated remedy.

What this deliberately does not do

• No status or progress field is written. task_count is a Field.summary computed on read; nothing here writes back to duly_assignment at all. A test asserts every write node targets duly_task.
• period_key is not set — the key is absent from both create_record nodes, not set to ''.
• The assigner gets nothing unless needs_collection is true; the default out-edge routes straight past that branch.
• No display text is hard-coded. The follow-up task reuses {record.subject} rather than an inlined literal, since English is the source language and authored labels belong in a bundle.

Gates

Run under the shared verify lock on e3cbb28, worktree clean:

VALIDATE_EXIT=0 ✓ Validation passed (299ms) · Logic: 1 Flows
TYPECHECK_EXIT=0 tsc --noEmit, no output
TEST_EXIT=0 Test Files 2 passed (2) · Tests 36 passed (36)
BUILD_EXIT=0 ✓ Build complete (291ms) · Logic: 1 Flows

Reverse verification — three ablations, each confirmed on disk before measuring

1. record. → bare status. Mutation on disk (injected 1, removed 0) → validateexit 0, still passed. validate deliberately does not flag bare identifiers inside a flow (collectBoundRecordReads: "Deliberately NEVER a bare identifier"). So a clean validate is not evidence on this point — the dispatch note's expectation here was inverted. Filed as No gate catches a bare field reference in a flow predicate — and AGENTS.md claims there is one #29 with the measurement.
2. record.needs_collection → record.needs_colection. Mutation on disk → validateexit 1, located: unknown field `needs_colection` on `duly_assignment` — did you mean `needs_collection`? This is the gate that is real, and it proves the green run above is a measurement rather than a vacuous pass.
3. Guard filter { assignment, owner } → { assignment } (the per-assignment bug). Mutation on disk → pnpm testexit 1, one failure, the guard filters per OWNER, not per assignment; validate stayed exit 0. The test is the only thing standing between this repo and that bug.

Each ablation script carried a trap … EXIT INT TERM restore; the tree was verified clean after each.

Files

• src/flows/assignment.flow.ts (new)
• src/flows/index.ts — added to dulyFlows
• test/assignment-fanout.test.ts (new, 28 tests)

objectstack.config.ts untouched — the barrel was already wired on main. No changeset: this repo has no .changeset/.

---

Generated by Claude Code

[os-warren]

Fixes#6

A record_change flow on duly_assignment that turns a dispatched assignment into N duly_task rows — one owner each — plus, only when needs_collection is ticked, one follow-up task for the assigner.

Verified on e3cbb28. All four gates green on that commit (see Gates below).

The three PM assumptions, all verified against engine source

Assumption	Verdict
A record_change flow can detect a transition into status = 'dispatched', not merely observe the state	True — but deliberately not used. See below.
A loop node with config: { collection, iteratorVariable, body: { nodes, edges } } can create a record per iteration	True.LoopConfigSchema carries exactly those keys; loop-node.ts runs the body via runRegion per item in the shared variable scope, and the body is an arbitrary sub-graph, so create_record inside it is supported.
Field.user({ multiple: true }) on assignees gives the loop an iterable array	True. It authors { type: 'user', reference: 'sys_user', multiple: true } and stores an array of sys_user ids. interpolate() returns the raw value when the whole string is a single token, so '{record.assignees}' resolves to the array itself, not its toString.

Two premises that did not survive contact — please read

1. The trigger does not bind where the issue implies

FlowSchema is .strict() and carries neitherobjectnortrigger. Writing either is a parse error, and the schema says where to go instead:

object is not a Flow field — a record-change flow binds its object on the START node's config ({ objectName, triggerType, condition }), not at the flow top level.

The engine's resolveTriggerBinding reads exactly those three keys off the start node, and reads objectName only (object is a load-time alias for the CRUD nodes, not for the trigger). Confirmed independently by the validator resolving record.needs_collection against duly_assignment — it could only know the bound object from that start-node config.

Worth knowing: the CLI's own objectstack generate scaffold still emits the rejected shape — top-level trigger: { type, object, events: ['after_insert', …] } and nodes with name/next instead of the required label. That scaffold cannot pass validate against 17.2.0. Reported separately for routing; nothing to do in this repo.

2. The gate is the dispatched STATE, not the transition into it

The dispatch note asked me to test this rather than paper over it, so, in full.

The platform can see a transition. AutomationContext.previous is documented for exactly this (status == "done" && previous.status != "done") and seedRunVariables binds it on every run. The design still must not depend on it, for two independent reasons:

It breaks the sixth assignee. Adding a name to an already-dispatched assignment moves no status. A transition gate fires zero times and creates zero tasks, where the acceptance criteria say exactly one. Criterion 3 ("re-saving creates 0 more") would also pass vacuously — for the wrong reason.

It faults the flow on insert.variables.set('previous', context?.previous ?? null) — previous is bound to null on an insert, and CEL field access through a null root aborts the predicate. evaluateCondition never swallows that to false; it throws (ADR-0032 §1c). So previous.status != "dispatched" would fail every assignment born directly as dispatched — an import, a REST create, a seed.

record.status cannot fail the same way: the record-change trigger runs materializeDeclaredFields over both CEL roots, so every declared field of duly_assignment is present, at worst as null.

So: triggerType: 'record-after-write' (the afterInsert + afterUpdate union) with condition: record.status == "dispatched". Idempotency is carried entirely by the guard below, which had to exist anyway.

Idempotency — explicit, and per OWNER

The (duty, owner, period_key) unique index does not constrain these rows: a fan-out task sets neither duty nor period_key. As the issue says, it will not protect us, so the guard is explicit. Each loop iteration reads duly_task where { assignment, owner } and creates only on a miss.

Per owner, not per assignment — a per-assignment guard finds the first of the five tasks and creates nothing for a sixth assignee. That exact bug is ablated in the test below.

The guard keys on (assignment, owner) and deliberately not on subject. A subject-aware guard would mint a duplicate task for every owner the moment somebody edits the assignment's subject and re-saves — a worse failure than the one it would prevent.

One consequence, stated so it is a decision and not an accident: an assigner who is also one of the assignees already owns a task on this assignment, so needs_collection adds no second one for them. That reads as correct to me — one task per owner per assignment is the invariant, and a manager does not need two rows for one piece of work — but it is a product call, so flagging it.

existing_task / existing_assigner_task are declared variables with defaultValue: null. get_record returns early without setting its outputVariable when no data engine is registered, and an unbound name aborts a strict-CEL predicate rather than yielding false; a declared default removes the unbound state, which is the platform's own stated remedy.

What this deliberately does not do

• No status or progress field is written. task_count is a Field.summary computed on read; nothing here writes back to duly_assignment at all. A test asserts every write node targets duly_task.
• period_key is not set — the key is absent from both create_record nodes, not set to ''.
• The assigner gets nothing unless needs_collection is true; the default out-edge routes straight past that branch.
• No display text is hard-coded. The follow-up task reuses {record.subject} rather than an inlined literal, since English is the source language and authored labels belong in a bundle.

Gates

Run under the shared verify lock on e3cbb28, worktree clean:

VALIDATE_EXIT=0 ✓ Validation passed (299ms) · Logic: 1 Flows
TYPECHECK_EXIT=0 tsc --noEmit, no output
TEST_EXIT=0 Test Files 2 passed (2) · Tests 36 passed (36)
BUILD_EXIT=0 ✓ Build complete (291ms) · Logic: 1 Flows

Reverse verification — three ablations, each confirmed on disk before measuring

1. record. → bare status. Mutation on disk (injected 1, removed 0) → validateexit 0, still passed. validate deliberately does not flag bare identifiers inside a flow (collectBoundRecordReads: "Deliberately NEVER a bare identifier"). So a clean validate is not evidence on this point — the dispatch note's expectation here was inverted. Filed as No gate catches a bare field reference in a flow predicate — and AGENTS.md claims there is one #29 with the measurement.
2. record.needs_collection → record.needs_colection. Mutation on disk → validateexit 1, located: unknown field `needs_colection` on `duly_assignment` — did you mean `needs_collection`? This is the gate that is real, and it proves the green run above is a measurement rather than a vacuous pass.
3. Guard filter { assignment, owner } → { assignment } (the per-assignment bug). Mutation on disk → pnpm testexit 1, one failure, the guard filters per OWNER, not per assignment; validate stayed exit 0. The test is the only thing standing between this repo and that bug.

Each ablation script carried a trap … EXIT INT TERM restore; the tree was verified clean after each.

Files

• src/flows/assignment.flow.ts (new)
• src/flows/index.ts — added to dulyFlows
• test/assignment-fanout.test.ts (new, 28 tests)

objectstack.config.ts untouched — the barrel was already wired on main. No changeset: this repo has no .changeset/.

---

Generated by Claude Code

[os-warren]

Fixes#6

A record_change flow on duly_assignment that turns a dispatched assignment into N duly_task rows — one owner each — plus, only when needs_collection is ticked, one follow-up task for the assigner.

Verified on e3cbb28. All four gates green on that commit (see Gates below).

The three PM assumptions, all verified against engine source

Assumption	Verdict
A record_change flow can detect a transition into status = 'dispatched', not merely observe the state	True — but deliberately not used. See below.
A loop node with config: { collection, iteratorVariable, body: { nodes, edges } } can create a record per iteration	True.LoopConfigSchema carries exactly those keys; loop-node.ts runs the body via runRegion per item in the shared variable scope, and the body is an arbitrary sub-graph, so create_record inside it is supported.
Field.user({ multiple: true }) on assignees gives the loop an iterable array	True. It authors { type: 'user', reference: 'sys_user', multiple: true } and stores an array of sys_user ids. interpolate() returns the raw value when the whole string is a single token, so '{record.assignees}' resolves to the array itself, not its toString.

Two premises that did not survive contact — please read

1. The trigger does not bind where the issue implies

FlowSchema is .strict() and carries neitherobjectnortrigger. Writing either is a parse error, and the schema says where to go instead:

object is not a Flow field — a record-change flow binds its object on the START node's config ({ objectName, triggerType, condition }), not at the flow top level.

The engine's resolveTriggerBinding reads exactly those three keys off the start node, and reads objectName only (object is a load-time alias for the CRUD nodes, not for the trigger). Confirmed independently by the validator resolving record.needs_collection against duly_assignment — it could only know the bound object from that start-node config.

Worth knowing: the CLI's own objectstack generate scaffold still emits the rejected shape — top-level trigger: { type, object, events: ['after_insert', …] } and nodes with name/next instead of the required label. That scaffold cannot pass validate against 17.2.0. Reported separately for routing; nothing to do in this repo.

2. The gate is the dispatched STATE, not the transition into it

The dispatch note asked me to test this rather than paper over it, so, in full.

The platform can see a transition. AutomationContext.previous is documented for exactly this (status == "done" && previous.status != "done") and seedRunVariables binds it on every run. The design still must not depend on it, for two independent reasons:

It breaks the sixth assignee. Adding a name to an already-dispatched assignment moves no status. A transition gate fires zero times and creates zero tasks, where the acceptance criteria say exactly one. Criterion 3 ("re-saving creates 0 more") would also pass vacuously — for the wrong reason.

It faults the flow on insert.variables.set('previous', context?.previous ?? null) — previous is bound to null on an insert, and CEL field access through a null root aborts the predicate. evaluateCondition never swallows that to false; it throws (ADR-0032 §1c). So previous.status != "dispatched" would fail every assignment born directly as dispatched — an import, a REST create, a seed.

record.status cannot fail the same way: the record-change trigger runs materializeDeclaredFields over both CEL roots, so every declared field of duly_assignment is present, at worst as null.

So: triggerType: 'record-after-write' (the afterInsert + afterUpdate union) with condition: record.status == "dispatched". Idempotency is carried entirely by the guard below, which had to exist anyway.

Idempotency — explicit, and per OWNER

The (duty, owner, period_key) unique index does not constrain these rows: a fan-out task sets neither duty nor period_key. As the issue says, it will not protect us, so the guard is explicit. Each loop iteration reads duly_task where { assignment, owner } and creates only on a miss.

Per owner, not per assignment — a per-assignment guard finds the first of the five tasks and creates nothing for a sixth assignee. That exact bug is ablated in the test below.

The guard keys on (assignment, owner) and deliberately not on subject. A subject-aware guard would mint a duplicate task for every owner the moment somebody edits the assignment's subject and re-saves — a worse failure than the one it would prevent.

One consequence, stated so it is a decision and not an accident: an assigner who is also one of the assignees already owns a task on this assignment, so needs_collection adds no second one for them. That reads as correct to me — one task per owner per assignment is the invariant, and a manager does not need two rows for one piece of work — but it is a product call, so flagging it.

existing_task / existing_assigner_task are declared variables with defaultValue: null. get_record returns early without setting its outputVariable when no data engine is registered, and an unbound name aborts a strict-CEL predicate rather than yielding false; a declared default removes the unbound state, which is the platform's own stated remedy.

What this deliberately does not do

• No status or progress field is written. task_count is a Field.summary computed on read; nothing here writes back to duly_assignment at all. A test asserts every write node targets duly_task.
• period_key is not set — the key is absent from both create_record nodes, not set to ''.
• The assigner gets nothing unless needs_collection is true; the default out-edge routes straight past that branch.
• No display text is hard-coded. The follow-up task reuses {record.subject} rather than an inlined literal, since English is the source language and authored labels belong in a bundle.

Gates

Run under the shared verify lock on e3cbb28, worktree clean:

VALIDATE_EXIT=0 ✓ Validation passed (299ms) · Logic: 1 Flows
TYPECHECK_EXIT=0 tsc --noEmit, no output
TEST_EXIT=0 Test Files 2 passed (2) · Tests 36 passed (36)
BUILD_EXIT=0 ✓ Build complete (291ms) · Logic: 1 Flows

Reverse verification — three ablations, each confirmed on disk before measuring

1. record. → bare status. Mutation on disk (injected 1, removed 0) → validateexit 0, still passed. validate deliberately does not flag bare identifiers inside a flow (collectBoundRecordReads: "Deliberately NEVER a bare identifier"). So a clean validate is not evidence on this point — the dispatch note's expectation here was inverted. Filed as No gate catches a bare field reference in a flow predicate — and AGENTS.md claims there is one #29 with the measurement.
2. record.needs_collection → record.needs_colection. Mutation on disk → validateexit 1, located: unknown field `needs_colection` on `duly_assignment` — did you mean `needs_collection`? This is the gate that is real, and it proves the green run above is a measurement rather than a vacuous pass.
3. Guard filter { assignment, owner } → { assignment } (the per-assignment bug). Mutation on disk → pnpm testexit 1, one failure, the guard filters per OWNER, not per assignment; validate stayed exit 0. The test is the only thing standing between this repo and that bug.

Each ablation script carried a trap … EXIT INT TERM restore; the tree was verified clean after each.

Files

• src/flows/assignment.flow.ts (new)
• src/flows/index.ts — added to dulyFlows
• test/assignment-fanout.test.ts (new, 28 tests)

objectstack.config.ts untouched — the barrel was already wired on main. No changeset: this repo has no .changeset/.

---

Generated by Claude Code

[os-warren]

Fixes#6

A record_change flow on duly_assignment that turns a dispatched assignment into N duly_task rows — one owner each — plus, only when needs_collection is ticked, one follow-up task for the assigner.

Verified on e3cbb28. All four gates green on that commit (see Gates below).

The three PM assumptions, all verified against engine source

Assumption	Verdict
A record_change flow can detect a transition into status = 'dispatched', not merely observe the state	True — but deliberately not used. See below.
A loop node with config: { collection, iteratorVariable, body: { nodes, edges } } can create a record per iteration	True.LoopConfigSchema carries exactly those keys; loop-node.ts runs the body via runRegion per item in the shared variable scope, and the body is an arbitrary sub-graph, so create_record inside it is supported.
Field.user({ multiple: true }) on assignees gives the loop an iterable array	True. It authors { type: 'user', reference: 'sys_user', multiple: true } and stores an array of sys_user ids. interpolate() returns the raw value when the whole string is a single token, so '{record.assignees}' resolves to the array itself, not its toString.

Two premises that did not survive contact — please read

1. The trigger does not bind where the issue implies

FlowSchema is .strict() and carries neitherobjectnortrigger. Writing either is a parse error, and the schema says where to go instead:

object is not a Flow field — a record-change flow binds its object on the START node's config ({ objectName, triggerType, condition }), not at the flow top level.

The engine's resolveTriggerBinding reads exactly those three keys off the start node, and reads objectName only (object is a load-time alias for the CRUD nodes, not for the trigger). Confirmed independently by the validator resolving record.needs_collection against duly_assignment — it could only know the bound object from that start-node config.

Worth knowing: the CLI's own objectstack generate scaffold still emits the rejected shape — top-level trigger: { type, object, events: ['after_insert', …] } and nodes with name/next instead of the required label. That scaffold cannot pass validate against 17.2.0. Reported separately for routing; nothing to do in this repo.

2. The gate is the dispatched STATE, not the transition into it

The dispatch note asked me to test this rather than paper over it, so, in full.

The platform can see a transition. AutomationContext.previous is documented for exactly this (status == "done" && previous.status != "done") and seedRunVariables binds it on every run. The design still must not depend on it, for two independent reasons:

It breaks the sixth assignee. Adding a name to an already-dispatched assignment moves no status. A transition gate fires zero times and creates zero tasks, where the acceptance criteria say exactly one. Criterion 3 ("re-saving creates 0 more") would also pass vacuously — for the wrong reason.

It faults the flow on insert.variables.set('previous', context?.previous ?? null) — previous is bound to null on an insert, and CEL field access through a null root aborts the predicate. evaluateCondition never swallows that to false; it throws (ADR-0032 §1c). So previous.status != "dispatched" would fail every assignment born directly as dispatched — an import, a REST create, a seed.

record.status cannot fail the same way: the record-change trigger runs materializeDeclaredFields over both CEL roots, so every declared field of duly_assignment is present, at worst as null.

So: triggerType: 'record-after-write' (the afterInsert + afterUpdate union) with condition: record.status == "dispatched". Idempotency is carried entirely by the guard below, which had to exist anyway.

Idempotency — explicit, and per OWNER

The (duty, owner, period_key) unique index does not constrain these rows: a fan-out task sets neither duty nor period_key. As the issue says, it will not protect us, so the guard is explicit. Each loop iteration reads duly_task where { assignment, owner } and creates only on a miss.

Per owner, not per assignment — a per-assignment guard finds the first of the five tasks and creates nothing for a sixth assignee. That exact bug is ablated in the test below.

The guard keys on (assignment, owner) and deliberately not on subject. A subject-aware guard would mint a duplicate task for every owner the moment somebody edits the assignment's subject and re-saves — a worse failure than the one it would prevent.

One consequence, stated so it is a decision and not an accident: an assigner who is also one of the assignees already owns a task on this assignment, so needs_collection adds no second one for them. That reads as correct to me — one task per owner per assignment is the invariant, and a manager does not need two rows for one piece of work — but it is a product call, so flagging it.

existing_task / existing_assigner_task are declared variables with defaultValue: null. get_record returns early without setting its outputVariable when no data engine is registered, and an unbound name aborts a strict-CEL predicate rather than yielding false; a declared default removes the unbound state, which is the platform's own stated remedy.

What this deliberately does not do

• No status or progress field is written. task_count is a Field.summary computed on read; nothing here writes back to duly_assignment at all. A test asserts every write node targets duly_task.
• period_key is not set — the key is absent from both create_record nodes, not set to ''.
• The assigner gets nothing unless needs_collection is true; the default out-edge routes straight past that branch.
• No display text is hard-coded. The follow-up task reuses {record.subject} rather than an inlined literal, since English is the source language and authored labels belong in a bundle.

Gates

Run under the shared verify lock on e3cbb28, worktree clean:

VALIDATE_EXIT=0 ✓ Validation passed (299ms) · Logic: 1 Flows
TYPECHECK_EXIT=0 tsc --noEmit, no output
TEST_EXIT=0 Test Files 2 passed (2) · Tests 36 passed (36)
BUILD_EXIT=0 ✓ Build complete (291ms) · Logic: 1 Flows

Reverse verification — three ablations, each confirmed on disk before measuring

1. record. → bare status. Mutation on disk (injected 1, removed 0) → validateexit 0, still passed. validate deliberately does not flag bare identifiers inside a flow (collectBoundRecordReads: "Deliberately NEVER a bare identifier"). So a clean validate is not evidence on this point — the dispatch note's expectation here was inverted. Filed as No gate catches a bare field reference in a flow predicate — and AGENTS.md claims there is one #29 with the measurement.
2. record.needs_collection → record.needs_colection. Mutation on disk → validateexit 1, located: unknown field `needs_colection` on `duly_assignment` — did you mean `needs_collection`? This is the gate that is real, and it proves the green run above is a measurement rather than a vacuous pass.
3. Guard filter { assignment, owner } → { assignment } (the per-assignment bug). Mutation on disk → pnpm testexit 1, one failure, the guard filters per OWNER, not per assignment; validate stayed exit 0. The test is the only thing standing between this repo and that bug.

Each ablation script carried a trap … EXIT INT TERM restore; the tree was verified clean after each.

Files

• src/flows/assignment.flow.ts (new)
• src/flows/index.ts — added to dulyFlows
• test/assignment-fanout.test.ts (new, 28 tests)

objectstack.config.ts untouched — the barrel was already wired on main. No changeset: this repo has no .changeset/.

---

Generated by Claude Code

[os-warren]

Fixes#6

A record_change flow on duly_assignment that turns a dispatched assignment into N duly_task rows — one owner each — plus, only when needs_collection is ticked, one follow-up task for the assigner.

Verified on e3cbb28. All four gates green on that commit (see Gates below).

The three PM assumptions, all verified against engine source

Assumption	Verdict
A record_change flow can detect a transition into status = 'dispatched', not merely observe the state	True — but deliberately not used. See below.
A loop node with config: { collection, iteratorVariable, body: { nodes, edges } } can create a record per iteration	True.LoopConfigSchema carries exactly those keys; loop-node.ts runs the body via runRegion per item in the shared variable scope, and the body is an arbitrary sub-graph, so create_record inside it is supported.
Field.user({ multiple: true }) on assignees gives the loop an iterable array	True. It authors { type: 'user', reference: 'sys_user', multiple: true } and stores an array of sys_user ids. interpolate() returns the raw value when the whole string is a single token, so '{record.assignees}' resolves to the array itself, not its toString.

Two premises that did not survive contact — please read

1. The trigger does not bind where the issue implies

FlowSchema is .strict() and carries neitherobjectnortrigger. Writing either is a parse error, and the schema says where to go instead:

object is not a Flow field — a record-change flow binds its object on the START node's config ({ objectName, triggerType, condition }), not at the flow top level.

The engine's resolveTriggerBinding reads exactly those three keys off the start node, and reads objectName only (object is a load-time alias for the CRUD nodes, not for the trigger). Confirmed independently by the validator resolving record.needs_collection against duly_assignment — it could only know the bound object from that start-node config.

Worth knowing: the CLI's own objectstack generate scaffold still emits the rejected shape — top-level trigger: { type, object, events: ['after_insert', …] } and nodes with name/next instead of the required label. That scaffold cannot pass validate against 17.2.0. Reported separately for routing; nothing to do in this repo.

2. The gate is the dispatched STATE, not the transition into it

The dispatch note asked me to test this rather than paper over it, so, in full.

The platform can see a transition. AutomationContext.previous is documented for exactly this (status == "done" && previous.status != "done") and seedRunVariables binds it on every run. The design still must not depend on it, for two independent reasons:

It breaks the sixth assignee. Adding a name to an already-dispatched assignment moves no status. A transition gate fires zero times and creates zero tasks, where the acceptance criteria say exactly one. Criterion 3 ("re-saving creates 0 more") would also pass vacuously — for the wrong reason.

It faults the flow on insert.variables.set('previous', context?.previous ?? null) — previous is bound to null on an insert, and CEL field access through a null root aborts the predicate. evaluateCondition never swallows that to false; it throws (ADR-0032 §1c). So previous.status != "dispatched" would fail every assignment born directly as dispatched — an import, a REST create, a seed.

record.status cannot fail the same way: the record-change trigger runs materializeDeclaredFields over both CEL roots, so every declared field of duly_assignment is present, at worst as null.

So: triggerType: 'record-after-write' (the afterInsert + afterUpdate union) with condition: record.status == "dispatched". Idempotency is carried entirely by the guard below, which had to exist anyway.

Idempotency — explicit, and per OWNER

The (duty, owner, period_key) unique index does not constrain these rows: a fan-out task sets neither duty nor period_key. As the issue says, it will not protect us, so the guard is explicit. Each loop iteration reads duly_task where { assignment, owner } and creates only on a miss.

Per owner, not per assignment — a per-assignment guard finds the first of the five tasks and creates nothing for a sixth assignee. That exact bug is ablated in the test below.

The guard keys on (assignment, owner) and deliberately not on subject. A subject-aware guard would mint a duplicate task for every owner the moment somebody edits the assignment's subject and re-saves — a worse failure than the one it would prevent.

One consequence, stated so it is a decision and not an accident: an assigner who is also one of the assignees already owns a task on this assignment, so needs_collection adds no second one for them. That reads as correct to me — one task per owner per assignment is the invariant, and a manager does not need two rows for one piece of work — but it is a product call, so flagging it.

existing_task / existing_assigner_task are declared variables with defaultValue: null. get_record returns early without setting its outputVariable when no data engine is registered, and an unbound name aborts a strict-CEL predicate rather than yielding false; a declared default removes the unbound state, which is the platform's own stated remedy.

What this deliberately does not do

• No status or progress field is written. task_count is a Field.summary computed on read; nothing here writes back to duly_assignment at all. A test asserts every write node targets duly_task.
• period_key is not set — the key is absent from both create_record nodes, not set to ''.
• The assigner gets nothing unless needs_collection is true; the default out-edge routes straight past that branch.
• No display text is hard-coded. The follow-up task reuses {record.subject} rather than an inlined literal, since English is the source language and authored labels belong in a bundle.

Gates

Run under the shared verify lock on e3cbb28, worktree clean:

VALIDATE_EXIT=0 ✓ Validation passed (299ms) · Logic: 1 Flows
TYPECHECK_EXIT=0 tsc --noEmit, no output
TEST_EXIT=0 Test Files 2 passed (2) · Tests 36 passed (36)
BUILD_EXIT=0 ✓ Build complete (291ms) · Logic: 1 Flows

Reverse verification — three ablations, each confirmed on disk before measuring

1. record. → bare status. Mutation on disk (injected 1, removed 0) → validateexit 0, still passed. validate deliberately does not flag bare identifiers inside a flow (collectBoundRecordReads: "Deliberately NEVER a bare identifier"). So a clean validate is not evidence on this point — the dispatch note's expectation here was inverted. Filed as No gate catches a bare field reference in a flow predicate — and AGENTS.md claims there is one #29 with the measurement.
2. record.needs_collection → record.needs_colection. Mutation on disk → validateexit 1, located: unknown field `needs_colection` on `duly_assignment` — did you mean `needs_collection`? This is the gate that is real, and it proves the green run above is a measurement rather than a vacuous pass.
3. Guard filter { assignment, owner } → { assignment } (the per-assignment bug). Mutation on disk → pnpm testexit 1, one failure, the guard filters per OWNER, not per assignment; validate stayed exit 0. The test is the only thing standing between this repo and that bug.

Each ablation script carried a trap … EXIT INT TERM restore; the tree was verified clean after each.

Files

• src/flows/assignment.flow.ts (new)
• src/flows/index.ts — added to dulyFlows
• test/assignment-fanout.test.ts (new, 28 tests)

objectstack.config.ts untouched — the barrel was already wired on main. No changeset: this repo has no .changeset/.

---

Generated by Claude Code

[os-warren]

Fixes#6

A record_change flow on duly_assignment that turns a dispatched assignment into N duly_task rows — one owner each — plus, only when needs_collection is ticked, one follow-up task for the assigner.

Verified on e3cbb28. All four gates green on that commit (see Gates below).

The three PM assumptions, all verified against engine source

Assumption	Verdict
A record_change flow can detect a transition into status = 'dispatched', not merely observe the state	True — but deliberately not used. See below.
A loop node with config: { collection, iteratorVariable, body: { nodes, edges } } can create a record per iteration	True.LoopConfigSchema carries exactly those keys; loop-node.ts runs the body via runRegion per item in the shared variable scope, and the body is an arbitrary sub-graph, so create_record inside it is supported.
Field.user({ multiple: true }) on assignees gives the loop an iterable array	True. It authors { type: 'user', reference: 'sys_user', multiple: true } and stores an array of sys_user ids. interpolate() returns the raw value when the whole string is a single token, so '{record.assignees}' resolves to the array itself, not its toString.

Two premises that did not survive contact — please read

1. The trigger does not bind where the issue implies

FlowSchema is .strict() and carries neitherobjectnortrigger. Writing either is a parse error, and the schema says where to go instead:

object is not a Flow field — a record-change flow binds its object on the START node's config ({ objectName, triggerType, condition }), not at the flow top level.

The engine's resolveTriggerBinding reads exactly those three keys off the start node, and reads objectName only (object is a load-time alias for the CRUD nodes, not for the trigger). Confirmed independently by the validator resolving record.needs_collection against duly_assignment — it could only know the bound object from that start-node config.

Worth knowing: the CLI's own objectstack generate scaffold still emits the rejected shape — top-level trigger: { type, object, events: ['after_insert', …] } and nodes with name/next instead of the required label. That scaffold cannot pass validate against 17.2.0. Reported separately for routing; nothing to do in this repo.

2. The gate is the dispatched STATE, not the transition into it

The dispatch note asked me to test this rather than paper over it, so, in full.

The platform can see a transition. AutomationContext.previous is documented for exactly this (status == "done" && previous.status != "done") and seedRunVariables binds it on every run. The design still must not depend on it, for two independent reasons:

It breaks the sixth assignee. Adding a name to an already-dispatched assignment moves no status. A transition gate fires zero times and creates zero tasks, where the acceptance criteria say exactly one. Criterion 3 ("re-saving creates 0 more") would also pass vacuously — for the wrong reason.

It faults the flow on insert.variables.set('previous', context?.previous ?? null) — previous is bound to null on an insert, and CEL field access through a null root aborts the predicate. evaluateCondition never swallows that to false; it throws (ADR-0032 §1c). So previous.status != "dispatched" would fail every assignment born directly as dispatched — an import, a REST create, a seed.

record.status cannot fail the same way: the record-change trigger runs materializeDeclaredFields over both CEL roots, so every declared field of duly_assignment is present, at worst as null.

So: triggerType: 'record-after-write' (the afterInsert + afterUpdate union) with condition: record.status == "dispatched". Idempotency is carried entirely by the guard below, which had to exist anyway.

Idempotency — explicit, and per OWNER

The (duty, owner, period_key) unique index does not constrain these rows: a fan-out task sets neither duty nor period_key. As the issue says, it will not protect us, so the guard is explicit. Each loop iteration reads duly_task where { assignment, owner } and creates only on a miss.

Per owner, not per assignment — a per-assignment guard finds the first of the five tasks and creates nothing for a sixth assignee. That exact bug is ablated in the test below.

The guard keys on (assignment, owner) and deliberately not on subject. A subject-aware guard would mint a duplicate task for every owner the moment somebody edits the assignment's subject and re-saves — a worse failure than the one it would prevent.

One consequence, stated so it is a decision and not an accident: an assigner who is also one of the assignees already owns a task on this assignment, so needs_collection adds no second one for them. That reads as correct to me — one task per owner per assignment is the invariant, and a manager does not need two rows for one piece of work — but it is a product call, so flagging it.

existing_task / existing_assigner_task are declared variables with defaultValue: null. get_record returns early without setting its outputVariable when no data engine is registered, and an unbound name aborts a strict-CEL predicate rather than yielding false; a declared default removes the unbound state, which is the platform's own stated remedy.

What this deliberately does not do

• No status or progress field is written. task_count is a Field.summary computed on read; nothing here writes back to duly_assignment at all. A test asserts every write node targets duly_task.
• period_key is not set — the key is absent from both create_record nodes, not set to ''.
• The assigner gets nothing unless needs_collection is true; the default out-edge routes straight past that branch.
• No display text is hard-coded. The follow-up task reuses {record.subject} rather than an inlined literal, since English is the source language and authored labels belong in a bundle.

Gates

Run under the shared verify lock on e3cbb28, worktree clean:

VALIDATE_EXIT=0 ✓ Validation passed (299ms) · Logic: 1 Flows
TYPECHECK_EXIT=0 tsc --noEmit, no output
TEST_EXIT=0 Test Files 2 passed (2) · Tests 36 passed (36)
BUILD_EXIT=0 ✓ Build complete (291ms) · Logic: 1 Flows

Reverse verification — three ablations, each confirmed on disk before measuring

1. record. → bare status. Mutation on disk (injected 1, removed 0) → validateexit 0, still passed. validate deliberately does not flag bare identifiers inside a flow (collectBoundRecordReads: "Deliberately NEVER a bare identifier"). So a clean validate is not evidence on this point — the dispatch note's expectation here was inverted. Filed as No gate catches a bare field reference in a flow predicate — and AGENTS.md claims there is one #29 with the measurement.
2. record.needs_collection → record.needs_colection. Mutation on disk → validateexit 1, located: unknown field `needs_colection` on `duly_assignment` — did you mean `needs_collection`? This is the gate that is real, and it proves the green run above is a measurement rather than a vacuous pass.
3. Guard filter { assignment, owner } → { assignment } (the per-assignment bug). Mutation on disk → pnpm testexit 1, one failure, the guard filters per OWNER, not per assignment; validate stayed exit 0. The test is the only thing standing between this repo and that bug.

Each ablation script carried a trap … EXIT INT TERM restore; the tree was verified clean after each.

Files

• src/flows/assignment.flow.ts (new)
• src/flows/index.ts — added to dulyFlows
• test/assignment-fanout.test.ts (new, 28 tests)

objectstack.config.ts untouched — the barrel was already wired on main. No changeset: this repo has no .changeset/.

---

Generated by Claude Code

[os-warren]

Fixes#6

A record_change flow on duly_assignment that turns a dispatched assignment into N duly_task rows — one owner each — plus, only when needs_collection is ticked, one follow-up task for the assigner.

Verified on e3cbb28. All four gates green on that commit (see Gates below).

The three PM assumptions, all verified against engine source

Assumption	Verdict
A record_change flow can detect a transition into status = 'dispatched', not merely observe the state	True — but deliberately not used. See below.
A loop node with config: { collection, iteratorVariable, body: { nodes, edges } } can create a record per iteration	True.LoopConfigSchema carries exactly those keys; loop-node.ts runs the body via runRegion per item in the shared variable scope, and the body is an arbitrary sub-graph, so create_record inside it is supported.
Field.user({ multiple: true }) on assignees gives the loop an iterable array	True. It authors { type: 'user', reference: 'sys_user', multiple: true } and stores an array of sys_user ids. interpolate() returns the raw value when the whole string is a single token, so '{record.assignees}' resolves to the array itself, not its toString.

Two premises that did not survive contact — please read

1. The trigger does not bind where the issue implies

FlowSchema is .strict() and carries neitherobjectnortrigger. Writing either is a parse error, and the schema says where to go instead:

object is not a Flow field — a record-change flow binds its object on the START node's config ({ objectName, triggerType, condition }), not at the flow top level.

The engine's resolveTriggerBinding reads exactly those three keys off the start node, and reads objectName only (object is a load-time alias for the CRUD nodes, not for the trigger). Confirmed independently by the validator resolving record.needs_collection against duly_assignment — it could only know the bound object from that start-node config.

Worth knowing: the CLI's own objectstack generate scaffold still emits the rejected shape — top-level trigger: { type, object, events: ['after_insert', …] } and nodes with name/next instead of the required label. That scaffold cannot pass validate against 17.2.0. Reported separately for routing; nothing to do in this repo.

2. The gate is the dispatched STATE, not the transition into it

The dispatch note asked me to test this rather than paper over it, so, in full.

The platform can see a transition. AutomationContext.previous is documented for exactly this (status == "done" && previous.status != "done") and seedRunVariables binds it on every run. The design still must not depend on it, for two independent reasons:

It breaks the sixth assignee. Adding a name to an already-dispatched assignment moves no status. A transition gate fires zero times and creates zero tasks, where the acceptance criteria say exactly one. Criterion 3 ("re-saving creates 0 more") would also pass vacuously — for the wrong reason.

It faults the flow on insert.variables.set('previous', context?.previous ?? null) — previous is bound to null on an insert, and CEL field access through a null root aborts the predicate. evaluateCondition never swallows that to false; it throws (ADR-0032 §1c). So previous.status != "dispatched" would fail every assignment born directly as dispatched — an import, a REST create, a seed.

record.status cannot fail the same way: the record-change trigger runs materializeDeclaredFields over both CEL roots, so every declared field of duly_assignment is present, at worst as null.

So: triggerType: 'record-after-write' (the afterInsert + afterUpdate union) with condition: record.status == "dispatched". Idempotency is carried entirely by the guard below, which had to exist anyway.

Idempotency — explicit, and per OWNER

The (duty, owner, period_key) unique index does not constrain these rows: a fan-out task sets neither duty nor period_key. As the issue says, it will not protect us, so the guard is explicit. Each loop iteration reads duly_task where { assignment, owner } and creates only on a miss.

Per owner, not per assignment — a per-assignment guard finds the first of the five tasks and creates nothing for a sixth assignee. That exact bug is ablated in the test below.

The guard keys on (assignment, owner) and deliberately not on subject. A subject-aware guard would mint a duplicate task for every owner the moment somebody edits the assignment's subject and re-saves — a worse failure than the one it would prevent.

One consequence, stated so it is a decision and not an accident: an assigner who is also one of the assignees already owns a task on this assignment, so needs_collection adds no second one for them. That reads as correct to me — one task per owner per assignment is the invariant, and a manager does not need two rows for one piece of work — but it is a product call, so flagging it.

existing_task / existing_assigner_task are declared variables with defaultValue: null. get_record returns early without setting its outputVariable when no data engine is registered, and an unbound name aborts a strict-CEL predicate rather than yielding false; a declared default removes the unbound state, which is the platform's own stated remedy.

What this deliberately does not do

• No status or progress field is written. task_count is a Field.summary computed on read; nothing here writes back to duly_assignment at all. A test asserts every write node targets duly_task.
• period_key is not set — the key is absent from both create_record nodes, not set to ''.
• The assigner gets nothing unless needs_collection is true; the default out-edge routes straight past that branch.
• No display text is hard-coded. The follow-up task reuses {record.subject} rather than an inlined literal, since English is the source language and authored labels belong in a bundle.

Gates

Run under the shared verify lock on e3cbb28, worktree clean:

VALIDATE_EXIT=0 ✓ Validation passed (299ms) · Logic: 1 Flows
TYPECHECK_EXIT=0 tsc --noEmit, no output
TEST_EXIT=0 Test Files 2 passed (2) · Tests 36 passed (36)
BUILD_EXIT=0 ✓ Build complete (291ms) · Logic: 1 Flows

Reverse verification — three ablations, each confirmed on disk before measuring

1. record. → bare status. Mutation on disk (injected 1, removed 0) → validateexit 0, still passed. validate deliberately does not flag bare identifiers inside a flow (collectBoundRecordReads: "Deliberately NEVER a bare identifier"). So a clean validate is not evidence on this point — the dispatch note's expectation here was inverted. Filed as No gate catches a bare field reference in a flow predicate — and AGENTS.md claims there is one #29 with the measurement.
2. record.needs_collection → record.needs_colection. Mutation on disk → validateexit 1, located: unknown field `needs_colection` on `duly_assignment` — did you mean `needs_collection`? This is the gate that is real, and it proves the green run above is a measurement rather than a vacuous pass.
3. Guard filter { assignment, owner } → { assignment } (the per-assignment bug). Mutation on disk → pnpm testexit 1, one failure, the guard filters per OWNER, not per assignment; validate stayed exit 0. The test is the only thing standing between this repo and that bug.

Each ablation script carried a trap … EXIT INT TERM restore; the tree was verified clean after each.

Files

• src/flows/assignment.flow.ts (new)
• src/flows/index.ts — added to dulyFlows
• test/assignment-fanout.test.ts (new, 28 tests)

objectstack.config.ts untouched — the barrel was already wired on main. No changeset: this repo has no .changeset/.

---

Generated by Claude Code