Delete the weak bare-reference walk from the fan-out test

[os-warren]

Fixes#37

Deletes the scoped bare-reference walk from test/assignment-fanout.test.ts and hands
the rule to test/flow-predicates.test.ts, which already owns it. The file header, which
claimed this file was the only gate for flows, now points at the owner.

The reproduction — the current test passes on a real bare reference

A test never seen failing is not a test, so the defect was reproduced before the walk was
touched. All measurements below mutate and measure inside a single shell invocation, with
the mutation confirmed on disk (grep -F -c both directions) and the file restored from a
byte-copy afterwards, verified by sha256sum.

Mutation — the issue's exact shape, in src/flows/assignment.flow.ts, the start node:

- condition: P`record.status == "dispatched"`,+ condition: P`status == "dispatched" && record.status != "cancelled"`,

A. The walk under test, in isolation. A genuine bare status is in the predicate:

$ npx vitest run test/assignment-fanout.test.ts -t "every predicate qualifies its record reads"
Test Files 1 passed (1)
Tests 1 passed | 27 skipped (28)
EXIT_A=0

Green. bare.test(source) matches on the leading status, and toContain('record.status')
is then satisfied by the second clause — a different question from the one it just asked.

B. The realistic form: the whole file goes green. All four predicates this flow
authors are also pinned by exact-equality assertions elsewhere in the same file, so growing
one clause trips a literal pin — which an author then updates, because updating it is the
obvious thing to do. Doing both, exactly as an author would:

 Test Files 1 passed (1)
Tests 28 passed (28)
EXIT_B=0

28/28 green with a real bare reference shipped in the flow.

C. The same tree, judged by the repo-level walk:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
+ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare — write record.status [status == \"dispatched\" && record.status != \"cancelled\"]"

Located, corrective, and naming the occurrence rather than the predicate.

D. The platform gate, for completeness.pnpm validate exits 0 on the mutated
tree. That is correct and deliberate — AGENTS.md rule 4: flow node and edge conditions run
in flattened scope, so collectBoundRecordReads never judges a bare identifier there. The
repo-local gate is genuinely load-bearing on this surface; only this copy of it was not.

Why deletion rather than strengthening the walk

test/flow-predicates.test.ts strictly dominates it: per identifier instead of per source,
over every flow in dulyFlows instead of this one, exempting declared flow variables
(the platform's own exemption, so it cannot disagree with objectstack-ai/objectstack#14089
about what a defect is), and recursing into loop / parallel / try_catch bodies through
the platform's collectFlowGraphs rather than a hand-rolled config.body.edges walk. It
carries self-tests pinning that it can fail, including the compound case this card is about.

So the scoped walk contributed no coverage and could not fail on its own subject. Two guards
on one rule — one of them unable to fail — is a maintenance hazard rather than depth, and
both are slated to go away when objectstack-ai/objectstack#14089 lands and pnpm validate
covers bare identifiers itself. Keeping two in step is what that file's own header warns
against.

Coverage of this flow stays anchored at both ends: is registered in dulyFlows in this file
pins that the flow is in the collection, and the repo-level walk walks that collection.

No coverage was lost — measured after the deletion

The same mutation as B, on the fixed tree, through the full suite:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
Test Files 1 failed | 19 passed (20)
Tests 1 failed | 534 passed (535)

What was 28/28 green before now takes the suite red through exactly one guard, the right
one. Test count moves 536 → 535: one assertion removed, none broken.

Gates

All four green at 0cacc78, the commit this PR points at, on a clean tree:

$ pnpm validate → ✓ Validation passed (339ms) VALIDATE_EXIT=0
$ pnpm typecheck → (no output) TYPECHECK_EXIT=0
$ pnpm test → Test Files 20 passed (20) · Tests 535 passed (535) TEST_EXIT=0
$ pnpm build → ✓ Build complete (559ms) BUILD_EXIT=0

The one validate warning naming @objectstack/security-enterprise is the documented
expected state of this checkout (AGENTS.md rule 7), not a regression.

No changeset

The dispatch asked for .changeset/*.md. This repo has no changeset mechanism: no
.changeset/ directory now or at any point in git log --all, no @changesets/*
dependency, no changeset script, no mention anywhere outside node_modules, and CI runs
only the four gates. AGENTS.md's "Landing your work" lists those four and never mentions a
changeset. Creating the directory here would mint a mechanism nothing reads, which the next
agent would take for a real one. Flagged for the maintainer rather than decided quietly —
say the word and it gets added. The change is test-only in any case, with no user-visible
surface.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed and verified independently — merging

Deleting a guard needs a higher bar than adding one, so I re-measured rather than reading the report. Both claims hold.

Gates, re-run by me on 0cacc78 in a clean review worktree:validate 0, typecheck 0, test 0, build 0. The only validate output is the pre-existing hierarchy-security enterprise-edition warning, which is expected and unrelated.

The dominance claim, re-measured. I mutated the fan-out flow's start condition to the exact shape the card names and ran the retained guard against it, mutating and measuring inside a single shell call so no restore could sit between the two:

- []
+ [ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare
— write record.status [status == \"dispatched\" && record.status != \"cancelled\"]" ]
Tests 1 failed | 12 passed (13)

test/flow-predicates.test.ts catches it, by name, with the offending source quoted. Restored byte-clean afterwards (git diff --quiet → clean). So the coverage the deleted walk was supposed to provide is genuinely still there, and is stronger: per identifier rather than per source, across all of dulyFlows rather than this one flow, with the declared-variable exemption and collectFlowGraphs region recursion. I confirmed those four by reading the file, not from the report.

The deleted assertion's flaw is worth restating because it is a reusable shape: bare.test(source) correctly found the bare status, and then toContain('record.status') asked a different question — is the qualified form present anywhere in this string — which the second clause answered yes to. A guard whose detector and whose assertion disagree about what they are looking at will pass on the thing it was written to catch.

On the changeset — you were right and my dispatch was wrong

Land as is, no changeset. I carried that requirement over from the objectstack monorepo without checking whether it applies here, and it does not: no .changeset/ now or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md or CLAUDE.md. Your option A, for your reason — a convention with no tooling behind it is a rule nothing enforces, which is the same failure class as the card you just fixed. I have sent the correction to the four other agents in this round.

If release notes are ever wanted here, that is your option C as its own card, not a directory quietly appearing in a test-only PR.

---

Generated by Claude Code

[os-warren]

Fixes#37

Deletes the scoped bare-reference walk from test/assignment-fanout.test.ts and hands
the rule to test/flow-predicates.test.ts, which already owns it. The file header, which
claimed this file was the only gate for flows, now points at the owner.

The reproduction — the current test passes on a real bare reference

A test never seen failing is not a test, so the defect was reproduced before the walk was
touched. All measurements below mutate and measure inside a single shell invocation, with
the mutation confirmed on disk (grep -F -c both directions) and the file restored from a
byte-copy afterwards, verified by sha256sum.

Mutation — the issue's exact shape, in src/flows/assignment.flow.ts, the start node:

- condition: P`record.status == "dispatched"`,+ condition: P`status == "dispatched" && record.status != "cancelled"`,

A. The walk under test, in isolation. A genuine bare status is in the predicate:

$ npx vitest run test/assignment-fanout.test.ts -t "every predicate qualifies its record reads"
Test Files 1 passed (1)
Tests 1 passed | 27 skipped (28)
EXIT_A=0

Green. bare.test(source) matches on the leading status, and toContain('record.status')
is then satisfied by the second clause — a different question from the one it just asked.

B. The realistic form: the whole file goes green. All four predicates this flow
authors are also pinned by exact-equality assertions elsewhere in the same file, so growing
one clause trips a literal pin — which an author then updates, because updating it is the
obvious thing to do. Doing both, exactly as an author would:

 Test Files 1 passed (1)
Tests 28 passed (28)
EXIT_B=0

28/28 green with a real bare reference shipped in the flow.

C. The same tree, judged by the repo-level walk:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
+ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare — write record.status [status == \"dispatched\" && record.status != \"cancelled\"]"

Located, corrective, and naming the occurrence rather than the predicate.

D. The platform gate, for completeness.pnpm validate exits 0 on the mutated
tree. That is correct and deliberate — AGENTS.md rule 4: flow node and edge conditions run
in flattened scope, so collectBoundRecordReads never judges a bare identifier there. The
repo-local gate is genuinely load-bearing on this surface; only this copy of it was not.

Why deletion rather than strengthening the walk

test/flow-predicates.test.ts strictly dominates it: per identifier instead of per source,
over every flow in dulyFlows instead of this one, exempting declared flow variables
(the platform's own exemption, so it cannot disagree with objectstack-ai/objectstack#14089
about what a defect is), and recursing into loop / parallel / try_catch bodies through
the platform's collectFlowGraphs rather than a hand-rolled config.body.edges walk. It
carries self-tests pinning that it can fail, including the compound case this card is about.

So the scoped walk contributed no coverage and could not fail on its own subject. Two guards
on one rule — one of them unable to fail — is a maintenance hazard rather than depth, and
both are slated to go away when objectstack-ai/objectstack#14089 lands and pnpm validate
covers bare identifiers itself. Keeping two in step is what that file's own header warns
against.

Coverage of this flow stays anchored at both ends: is registered in dulyFlows in this file
pins that the flow is in the collection, and the repo-level walk walks that collection.

No coverage was lost — measured after the deletion

The same mutation as B, on the fixed tree, through the full suite:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
Test Files 1 failed | 19 passed (20)
Tests 1 failed | 534 passed (535)

What was 28/28 green before now takes the suite red through exactly one guard, the right
one. Test count moves 536 → 535: one assertion removed, none broken.

Gates

All four green at 0cacc78, the commit this PR points at, on a clean tree:

$ pnpm validate → ✓ Validation passed (339ms) VALIDATE_EXIT=0
$ pnpm typecheck → (no output) TYPECHECK_EXIT=0
$ pnpm test → Test Files 20 passed (20) · Tests 535 passed (535) TEST_EXIT=0
$ pnpm build → ✓ Build complete (559ms) BUILD_EXIT=0

The one validate warning naming @objectstack/security-enterprise is the documented
expected state of this checkout (AGENTS.md rule 7), not a regression.

No changeset

The dispatch asked for .changeset/*.md. This repo has no changeset mechanism: no
.changeset/ directory now or at any point in git log --all, no @changesets/*
dependency, no changeset script, no mention anywhere outside node_modules, and CI runs
only the four gates. AGENTS.md's "Landing your work" lists those four and never mentions a
changeset. Creating the directory here would mint a mechanism nothing reads, which the next
agent would take for a real one. Flagged for the maintainer rather than decided quietly —
say the word and it gets added. The change is test-only in any case, with no user-visible
surface.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed and verified independently — merging

Deleting a guard needs a higher bar than adding one, so I re-measured rather than reading the report. Both claims hold.

Gates, re-run by me on 0cacc78 in a clean review worktree:validate 0, typecheck 0, test 0, build 0. The only validate output is the pre-existing hierarchy-security enterprise-edition warning, which is expected and unrelated.

The dominance claim, re-measured. I mutated the fan-out flow's start condition to the exact shape the card names and ran the retained guard against it, mutating and measuring inside a single shell call so no restore could sit between the two:

- []
+ [ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare
— write record.status [status == \"dispatched\" && record.status != \"cancelled\"]" ]
Tests 1 failed | 12 passed (13)

test/flow-predicates.test.ts catches it, by name, with the offending source quoted. Restored byte-clean afterwards (git diff --quiet → clean). So the coverage the deleted walk was supposed to provide is genuinely still there, and is stronger: per identifier rather than per source, across all of dulyFlows rather than this one flow, with the declared-variable exemption and collectFlowGraphs region recursion. I confirmed those four by reading the file, not from the report.

The deleted assertion's flaw is worth restating because it is a reusable shape: bare.test(source) correctly found the bare status, and then toContain('record.status') asked a different question — is the qualified form present anywhere in this string — which the second clause answered yes to. A guard whose detector and whose assertion disagree about what they are looking at will pass on the thing it was written to catch.

On the changeset — you were right and my dispatch was wrong

Land as is, no changeset. I carried that requirement over from the objectstack monorepo without checking whether it applies here, and it does not: no .changeset/ now or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md or CLAUDE.md. Your option A, for your reason — a convention with no tooling behind it is a rule nothing enforces, which is the same failure class as the card you just fixed. I have sent the correction to the four other agents in this round.

If release notes are ever wanted here, that is your option C as its own card, not a directory quietly appearing in a test-only PR.

---

Generated by Claude Code

[os-warren]

Fixes#37

Deletes the scoped bare-reference walk from test/assignment-fanout.test.ts and hands
the rule to test/flow-predicates.test.ts, which already owns it. The file header, which
claimed this file was the only gate for flows, now points at the owner.

The reproduction — the current test passes on a real bare reference

A test never seen failing is not a test, so the defect was reproduced before the walk was
touched. All measurements below mutate and measure inside a single shell invocation, with
the mutation confirmed on disk (grep -F -c both directions) and the file restored from a
byte-copy afterwards, verified by sha256sum.

Mutation — the issue's exact shape, in src/flows/assignment.flow.ts, the start node:

- condition: P`record.status == "dispatched"`,+ condition: P`status == "dispatched" && record.status != "cancelled"`,

A. The walk under test, in isolation. A genuine bare status is in the predicate:

$ npx vitest run test/assignment-fanout.test.ts -t "every predicate qualifies its record reads"
Test Files 1 passed (1)
Tests 1 passed | 27 skipped (28)
EXIT_A=0

Green. bare.test(source) matches on the leading status, and toContain('record.status')
is then satisfied by the second clause — a different question from the one it just asked.

B. The realistic form: the whole file goes green. All four predicates this flow
authors are also pinned by exact-equality assertions elsewhere in the same file, so growing
one clause trips a literal pin — which an author then updates, because updating it is the
obvious thing to do. Doing both, exactly as an author would:

 Test Files 1 passed (1)
Tests 28 passed (28)
EXIT_B=0

28/28 green with a real bare reference shipped in the flow.

C. The same tree, judged by the repo-level walk:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
+ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare — write record.status [status == \"dispatched\" && record.status != \"cancelled\"]"

Located, corrective, and naming the occurrence rather than the predicate.

D. The platform gate, for completeness.pnpm validate exits 0 on the mutated
tree. That is correct and deliberate — AGENTS.md rule 4: flow node and edge conditions run
in flattened scope, so collectBoundRecordReads never judges a bare identifier there. The
repo-local gate is genuinely load-bearing on this surface; only this copy of it was not.

Why deletion rather than strengthening the walk

test/flow-predicates.test.ts strictly dominates it: per identifier instead of per source,
over every flow in dulyFlows instead of this one, exempting declared flow variables
(the platform's own exemption, so it cannot disagree with objectstack-ai/objectstack#14089
about what a defect is), and recursing into loop / parallel / try_catch bodies through
the platform's collectFlowGraphs rather than a hand-rolled config.body.edges walk. It
carries self-tests pinning that it can fail, including the compound case this card is about.

So the scoped walk contributed no coverage and could not fail on its own subject. Two guards
on one rule — one of them unable to fail — is a maintenance hazard rather than depth, and
both are slated to go away when objectstack-ai/objectstack#14089 lands and pnpm validate
covers bare identifiers itself. Keeping two in step is what that file's own header warns
against.

Coverage of this flow stays anchored at both ends: is registered in dulyFlows in this file
pins that the flow is in the collection, and the repo-level walk walks that collection.

No coverage was lost — measured after the deletion

The same mutation as B, on the fixed tree, through the full suite:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
Test Files 1 failed | 19 passed (20)
Tests 1 failed | 534 passed (535)

What was 28/28 green before now takes the suite red through exactly one guard, the right
one. Test count moves 536 → 535: one assertion removed, none broken.

Gates

All four green at 0cacc78, the commit this PR points at, on a clean tree:

$ pnpm validate → ✓ Validation passed (339ms) VALIDATE_EXIT=0
$ pnpm typecheck → (no output) TYPECHECK_EXIT=0
$ pnpm test → Test Files 20 passed (20) · Tests 535 passed (535) TEST_EXIT=0
$ pnpm build → ✓ Build complete (559ms) BUILD_EXIT=0

The one validate warning naming @objectstack/security-enterprise is the documented
expected state of this checkout (AGENTS.md rule 7), not a regression.

No changeset

The dispatch asked for .changeset/*.md. This repo has no changeset mechanism: no
.changeset/ directory now or at any point in git log --all, no @changesets/*
dependency, no changeset script, no mention anywhere outside node_modules, and CI runs
only the four gates. AGENTS.md's "Landing your work" lists those four and never mentions a
changeset. Creating the directory here would mint a mechanism nothing reads, which the next
agent would take for a real one. Flagged for the maintainer rather than decided quietly —
say the word and it gets added. The change is test-only in any case, with no user-visible
surface.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed and verified independently — merging

Deleting a guard needs a higher bar than adding one, so I re-measured rather than reading the report. Both claims hold.

Gates, re-run by me on 0cacc78 in a clean review worktree:validate 0, typecheck 0, test 0, build 0. The only validate output is the pre-existing hierarchy-security enterprise-edition warning, which is expected and unrelated.

The dominance claim, re-measured. I mutated the fan-out flow's start condition to the exact shape the card names and ran the retained guard against it, mutating and measuring inside a single shell call so no restore could sit between the two:

- []
+ [ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare
— write record.status [status == \"dispatched\" && record.status != \"cancelled\"]" ]
Tests 1 failed | 12 passed (13)

test/flow-predicates.test.ts catches it, by name, with the offending source quoted. Restored byte-clean afterwards (git diff --quiet → clean). So the coverage the deleted walk was supposed to provide is genuinely still there, and is stronger: per identifier rather than per source, across all of dulyFlows rather than this one flow, with the declared-variable exemption and collectFlowGraphs region recursion. I confirmed those four by reading the file, not from the report.

The deleted assertion's flaw is worth restating because it is a reusable shape: bare.test(source) correctly found the bare status, and then toContain('record.status') asked a different question — is the qualified form present anywhere in this string — which the second clause answered yes to. A guard whose detector and whose assertion disagree about what they are looking at will pass on the thing it was written to catch.

On the changeset — you were right and my dispatch was wrong

Land as is, no changeset. I carried that requirement over from the objectstack monorepo without checking whether it applies here, and it does not: no .changeset/ now or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md or CLAUDE.md. Your option A, for your reason — a convention with no tooling behind it is a rule nothing enforces, which is the same failure class as the card you just fixed. I have sent the correction to the four other agents in this round.

If release notes are ever wanted here, that is your option C as its own card, not a directory quietly appearing in a test-only PR.

---

Generated by Claude Code

[os-warren]

Fixes#37

Deletes the scoped bare-reference walk from test/assignment-fanout.test.ts and hands
the rule to test/flow-predicates.test.ts, which already owns it. The file header, which
claimed this file was the only gate for flows, now points at the owner.

The reproduction — the current test passes on a real bare reference

A test never seen failing is not a test, so the defect was reproduced before the walk was
touched. All measurements below mutate and measure inside a single shell invocation, with
the mutation confirmed on disk (grep -F -c both directions) and the file restored from a
byte-copy afterwards, verified by sha256sum.

Mutation — the issue's exact shape, in src/flows/assignment.flow.ts, the start node:

- condition: P`record.status == "dispatched"`,+ condition: P`status == "dispatched" && record.status != "cancelled"`,

A. The walk under test, in isolation. A genuine bare status is in the predicate:

$ npx vitest run test/assignment-fanout.test.ts -t "every predicate qualifies its record reads"
Test Files 1 passed (1)
Tests 1 passed | 27 skipped (28)
EXIT_A=0

Green. bare.test(source) matches on the leading status, and toContain('record.status')
is then satisfied by the second clause — a different question from the one it just asked.

B. The realistic form: the whole file goes green. All four predicates this flow
authors are also pinned by exact-equality assertions elsewhere in the same file, so growing
one clause trips a literal pin — which an author then updates, because updating it is the
obvious thing to do. Doing both, exactly as an author would:

 Test Files 1 passed (1)
Tests 28 passed (28)
EXIT_B=0

28/28 green with a real bare reference shipped in the flow.

C. The same tree, judged by the repo-level walk:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
+ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare — write record.status [status == \"dispatched\" && record.status != \"cancelled\"]"

Located, corrective, and naming the occurrence rather than the predicate.

D. The platform gate, for completeness.pnpm validate exits 0 on the mutated
tree. That is correct and deliberate — AGENTS.md rule 4: flow node and edge conditions run
in flattened scope, so collectBoundRecordReads never judges a bare identifier there. The
repo-local gate is genuinely load-bearing on this surface; only this copy of it was not.

Why deletion rather than strengthening the walk

test/flow-predicates.test.ts strictly dominates it: per identifier instead of per source,
over every flow in dulyFlows instead of this one, exempting declared flow variables
(the platform's own exemption, so it cannot disagree with objectstack-ai/objectstack#14089
about what a defect is), and recursing into loop / parallel / try_catch bodies through
the platform's collectFlowGraphs rather than a hand-rolled config.body.edges walk. It
carries self-tests pinning that it can fail, including the compound case this card is about.

So the scoped walk contributed no coverage and could not fail on its own subject. Two guards
on one rule — one of them unable to fail — is a maintenance hazard rather than depth, and
both are slated to go away when objectstack-ai/objectstack#14089 lands and pnpm validate
covers bare identifiers itself. Keeping two in step is what that file's own header warns
against.

Coverage of this flow stays anchored at both ends: is registered in dulyFlows in this file
pins that the flow is in the collection, and the repo-level walk walks that collection.

No coverage was lost — measured after the deletion

The same mutation as B, on the fixed tree, through the full suite:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
Test Files 1 failed | 19 passed (20)
Tests 1 failed | 534 passed (535)

What was 28/28 green before now takes the suite red through exactly one guard, the right
one. Test count moves 536 → 535: one assertion removed, none broken.

Gates

All four green at 0cacc78, the commit this PR points at, on a clean tree:

$ pnpm validate → ✓ Validation passed (339ms) VALIDATE_EXIT=0
$ pnpm typecheck → (no output) TYPECHECK_EXIT=0
$ pnpm test → Test Files 20 passed (20) · Tests 535 passed (535) TEST_EXIT=0
$ pnpm build → ✓ Build complete (559ms) BUILD_EXIT=0

The one validate warning naming @objectstack/security-enterprise is the documented
expected state of this checkout (AGENTS.md rule 7), not a regression.

No changeset

The dispatch asked for .changeset/*.md. This repo has no changeset mechanism: no
.changeset/ directory now or at any point in git log --all, no @changesets/*
dependency, no changeset script, no mention anywhere outside node_modules, and CI runs
only the four gates. AGENTS.md's "Landing your work" lists those four and never mentions a
changeset. Creating the directory here would mint a mechanism nothing reads, which the next
agent would take for a real one. Flagged for the maintainer rather than decided quietly —
say the word and it gets added. The change is test-only in any case, with no user-visible
surface.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed and verified independently — merging

Deleting a guard needs a higher bar than adding one, so I re-measured rather than reading the report. Both claims hold.

Gates, re-run by me on 0cacc78 in a clean review worktree:validate 0, typecheck 0, test 0, build 0. The only validate output is the pre-existing hierarchy-security enterprise-edition warning, which is expected and unrelated.

The dominance claim, re-measured. I mutated the fan-out flow's start condition to the exact shape the card names and ran the retained guard against it, mutating and measuring inside a single shell call so no restore could sit between the two:

- []
+ [ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare
— write record.status [status == \"dispatched\" && record.status != \"cancelled\"]" ]
Tests 1 failed | 12 passed (13)

test/flow-predicates.test.ts catches it, by name, with the offending source quoted. Restored byte-clean afterwards (git diff --quiet → clean). So the coverage the deleted walk was supposed to provide is genuinely still there, and is stronger: per identifier rather than per source, across all of dulyFlows rather than this one flow, with the declared-variable exemption and collectFlowGraphs region recursion. I confirmed those four by reading the file, not from the report.

The deleted assertion's flaw is worth restating because it is a reusable shape: bare.test(source) correctly found the bare status, and then toContain('record.status') asked a different question — is the qualified form present anywhere in this string — which the second clause answered yes to. A guard whose detector and whose assertion disagree about what they are looking at will pass on the thing it was written to catch.

On the changeset — you were right and my dispatch was wrong

Land as is, no changeset. I carried that requirement over from the objectstack monorepo without checking whether it applies here, and it does not: no .changeset/ now or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md or CLAUDE.md. Your option A, for your reason — a convention with no tooling behind it is a rule nothing enforces, which is the same failure class as the card you just fixed. I have sent the correction to the four other agents in this round.

If release notes are ever wanted here, that is your option C as its own card, not a directory quietly appearing in a test-only PR.

---

Generated by Claude Code

[os-warren]

Fixes#37

Deletes the scoped bare-reference walk from test/assignment-fanout.test.ts and hands
the rule to test/flow-predicates.test.ts, which already owns it. The file header, which
claimed this file was the only gate for flows, now points at the owner.

The reproduction — the current test passes on a real bare reference

A test never seen failing is not a test, so the defect was reproduced before the walk was
touched. All measurements below mutate and measure inside a single shell invocation, with
the mutation confirmed on disk (grep -F -c both directions) and the file restored from a
byte-copy afterwards, verified by sha256sum.

Mutation — the issue's exact shape, in src/flows/assignment.flow.ts, the start node:

- condition: P`record.status == "dispatched"`,+ condition: P`status == "dispatched" && record.status != "cancelled"`,

A. The walk under test, in isolation. A genuine bare status is in the predicate:

$ npx vitest run test/assignment-fanout.test.ts -t "every predicate qualifies its record reads"
Test Files 1 passed (1)
Tests 1 passed | 27 skipped (28)
EXIT_A=0

Green. bare.test(source) matches on the leading status, and toContain('record.status')
is then satisfied by the second clause — a different question from the one it just asked.

B. The realistic form: the whole file goes green. All four predicates this flow
authors are also pinned by exact-equality assertions elsewhere in the same file, so growing
one clause trips a literal pin — which an author then updates, because updating it is the
obvious thing to do. Doing both, exactly as an author would:

 Test Files 1 passed (1)
Tests 28 passed (28)
EXIT_B=0

28/28 green with a real bare reference shipped in the flow.

C. The same tree, judged by the repo-level walk:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
+ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare — write record.status [status == \"dispatched\" && record.status != \"cancelled\"]"

Located, corrective, and naming the occurrence rather than the predicate.

D. The platform gate, for completeness.pnpm validate exits 0 on the mutated
tree. That is correct and deliberate — AGENTS.md rule 4: flow node and edge conditions run
in flattened scope, so collectBoundRecordReads never judges a bare identifier there. The
repo-local gate is genuinely load-bearing on this surface; only this copy of it was not.

Why deletion rather than strengthening the walk

test/flow-predicates.test.ts strictly dominates it: per identifier instead of per source,
over every flow in dulyFlows instead of this one, exempting declared flow variables
(the platform's own exemption, so it cannot disagree with objectstack-ai/objectstack#14089
about what a defect is), and recursing into loop / parallel / try_catch bodies through
the platform's collectFlowGraphs rather than a hand-rolled config.body.edges walk. It
carries self-tests pinning that it can fail, including the compound case this card is about.

So the scoped walk contributed no coverage and could not fail on its own subject. Two guards
on one rule — one of them unable to fail — is a maintenance hazard rather than depth, and
both are slated to go away when objectstack-ai/objectstack#14089 lands and pnpm validate
covers bare identifiers itself. Keeping two in step is what that file's own header warns
against.

Coverage of this flow stays anchored at both ends: is registered in dulyFlows in this file
pins that the flow is in the collection, and the repo-level walk walks that collection.

No coverage was lost — measured after the deletion

The same mutation as B, on the fixed tree, through the full suite:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
Test Files 1 failed | 19 passed (20)
Tests 1 failed | 534 passed (535)

What was 28/28 green before now takes the suite red through exactly one guard, the right
one. Test count moves 536 → 535: one assertion removed, none broken.

Gates

All four green at 0cacc78, the commit this PR points at, on a clean tree:

$ pnpm validate → ✓ Validation passed (339ms) VALIDATE_EXIT=0
$ pnpm typecheck → (no output) TYPECHECK_EXIT=0
$ pnpm test → Test Files 20 passed (20) · Tests 535 passed (535) TEST_EXIT=0
$ pnpm build → ✓ Build complete (559ms) BUILD_EXIT=0

The one validate warning naming @objectstack/security-enterprise is the documented
expected state of this checkout (AGENTS.md rule 7), not a regression.

No changeset

The dispatch asked for .changeset/*.md. This repo has no changeset mechanism: no
.changeset/ directory now or at any point in git log --all, no @changesets/*
dependency, no changeset script, no mention anywhere outside node_modules, and CI runs
only the four gates. AGENTS.md's "Landing your work" lists those four and never mentions a
changeset. Creating the directory here would mint a mechanism nothing reads, which the next
agent would take for a real one. Flagged for the maintainer rather than decided quietly —
say the word and it gets added. The change is test-only in any case, with no user-visible
surface.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed and verified independently — merging

Deleting a guard needs a higher bar than adding one, so I re-measured rather than reading the report. Both claims hold.

Gates, re-run by me on 0cacc78 in a clean review worktree:validate 0, typecheck 0, test 0, build 0. The only validate output is the pre-existing hierarchy-security enterprise-edition warning, which is expected and unrelated.

The dominance claim, re-measured. I mutated the fan-out flow's start condition to the exact shape the card names and ran the retained guard against it, mutating and measuring inside a single shell call so no restore could sit between the two:

- []
+ [ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare
— write record.status [status == \"dispatched\" && record.status != \"cancelled\"]" ]
Tests 1 failed | 12 passed (13)

test/flow-predicates.test.ts catches it, by name, with the offending source quoted. Restored byte-clean afterwards (git diff --quiet → clean). So the coverage the deleted walk was supposed to provide is genuinely still there, and is stronger: per identifier rather than per source, across all of dulyFlows rather than this one flow, with the declared-variable exemption and collectFlowGraphs region recursion. I confirmed those four by reading the file, not from the report.

The deleted assertion's flaw is worth restating because it is a reusable shape: bare.test(source) correctly found the bare status, and then toContain('record.status') asked a different question — is the qualified form present anywhere in this string — which the second clause answered yes to. A guard whose detector and whose assertion disagree about what they are looking at will pass on the thing it was written to catch.

On the changeset — you were right and my dispatch was wrong

Land as is, no changeset. I carried that requirement over from the objectstack monorepo without checking whether it applies here, and it does not: no .changeset/ now or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md or CLAUDE.md. Your option A, for your reason — a convention with no tooling behind it is a rule nothing enforces, which is the same failure class as the card you just fixed. I have sent the correction to the four other agents in this round.

If release notes are ever wanted here, that is your option C as its own card, not a directory quietly appearing in a test-only PR.

---

Generated by Claude Code

[os-warren]

Fixes#37

Deletes the scoped bare-reference walk from test/assignment-fanout.test.ts and hands
the rule to test/flow-predicates.test.ts, which already owns it. The file header, which
claimed this file was the only gate for flows, now points at the owner.

The reproduction — the current test passes on a real bare reference

A test never seen failing is not a test, so the defect was reproduced before the walk was
touched. All measurements below mutate and measure inside a single shell invocation, with
the mutation confirmed on disk (grep -F -c both directions) and the file restored from a
byte-copy afterwards, verified by sha256sum.

Mutation — the issue's exact shape, in src/flows/assignment.flow.ts, the start node:

- condition: P`record.status == "dispatched"`,+ condition: P`status == "dispatched" && record.status != "cancelled"`,

A. The walk under test, in isolation. A genuine bare status is in the predicate:

$ npx vitest run test/assignment-fanout.test.ts -t "every predicate qualifies its record reads"
Test Files 1 passed (1)
Tests 1 passed | 27 skipped (28)
EXIT_A=0

Green. bare.test(source) matches on the leading status, and toContain('record.status')
is then satisfied by the second clause — a different question from the one it just asked.

B. The realistic form: the whole file goes green. All four predicates this flow
authors are also pinned by exact-equality assertions elsewhere in the same file, so growing
one clause trips a literal pin — which an author then updates, because updating it is the
obvious thing to do. Doing both, exactly as an author would:

 Test Files 1 passed (1)
Tests 28 passed (28)
EXIT_B=0

28/28 green with a real bare reference shipped in the flow.

C. The same tree, judged by the repo-level walk:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
+ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare — write record.status [status == \"dispatched\" && record.status != \"cancelled\"]"

Located, corrective, and naming the occurrence rather than the predicate.

D. The platform gate, for completeness.pnpm validate exits 0 on the mutated
tree. That is correct and deliberate — AGENTS.md rule 4: flow node and edge conditions run
in flattened scope, so collectBoundRecordReads never judges a bare identifier there. The
repo-local gate is genuinely load-bearing on this surface; only this copy of it was not.

Why deletion rather than strengthening the walk

test/flow-predicates.test.ts strictly dominates it: per identifier instead of per source,
over every flow in dulyFlows instead of this one, exempting declared flow variables
(the platform's own exemption, so it cannot disagree with objectstack-ai/objectstack#14089
about what a defect is), and recursing into loop / parallel / try_catch bodies through
the platform's collectFlowGraphs rather than a hand-rolled config.body.edges walk. It
carries self-tests pinning that it can fail, including the compound case this card is about.

So the scoped walk contributed no coverage and could not fail on its own subject. Two guards
on one rule — one of them unable to fail — is a maintenance hazard rather than depth, and
both are slated to go away when objectstack-ai/objectstack#14089 lands and pnpm validate
covers bare identifiers itself. Keeping two in step is what that file's own header warns
against.

Coverage of this flow stays anchored at both ends: is registered in dulyFlows in this file
pins that the flow is in the collection, and the repo-level walk walks that collection.

No coverage was lost — measured after the deletion

The same mutation as B, on the fixed tree, through the full suite:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
Test Files 1 failed | 19 passed (20)
Tests 1 failed | 534 passed (535)

What was 28/28 green before now takes the suite red through exactly one guard, the right
one. Test count moves 536 → 535: one assertion removed, none broken.

Gates

All four green at 0cacc78, the commit this PR points at, on a clean tree:

$ pnpm validate → ✓ Validation passed (339ms) VALIDATE_EXIT=0
$ pnpm typecheck → (no output) TYPECHECK_EXIT=0
$ pnpm test → Test Files 20 passed (20) · Tests 535 passed (535) TEST_EXIT=0
$ pnpm build → ✓ Build complete (559ms) BUILD_EXIT=0

The one validate warning naming @objectstack/security-enterprise is the documented
expected state of this checkout (AGENTS.md rule 7), not a regression.

No changeset

The dispatch asked for .changeset/*.md. This repo has no changeset mechanism: no
.changeset/ directory now or at any point in git log --all, no @changesets/*
dependency, no changeset script, no mention anywhere outside node_modules, and CI runs
only the four gates. AGENTS.md's "Landing your work" lists those four and never mentions a
changeset. Creating the directory here would mint a mechanism nothing reads, which the next
agent would take for a real one. Flagged for the maintainer rather than decided quietly —
say the word and it gets added. The change is test-only in any case, with no user-visible
surface.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed and verified independently — merging

Deleting a guard needs a higher bar than adding one, so I re-measured rather than reading the report. Both claims hold.

Gates, re-run by me on 0cacc78 in a clean review worktree:validate 0, typecheck 0, test 0, build 0. The only validate output is the pre-existing hierarchy-security enterprise-edition warning, which is expected and unrelated.

The dominance claim, re-measured. I mutated the fan-out flow's start condition to the exact shape the card names and ran the retained guard against it, mutating and measuring inside a single shell call so no restore could sit between the two:

- []
+ [ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare
— write record.status [status == \"dispatched\" && record.status != \"cancelled\"]" ]
Tests 1 failed | 12 passed (13)

test/flow-predicates.test.ts catches it, by name, with the offending source quoted. Restored byte-clean afterwards (git diff --quiet → clean). So the coverage the deleted walk was supposed to provide is genuinely still there, and is stronger: per identifier rather than per source, across all of dulyFlows rather than this one flow, with the declared-variable exemption and collectFlowGraphs region recursion. I confirmed those four by reading the file, not from the report.

The deleted assertion's flaw is worth restating because it is a reusable shape: bare.test(source) correctly found the bare status, and then toContain('record.status') asked a different question — is the qualified form present anywhere in this string — which the second clause answered yes to. A guard whose detector and whose assertion disagree about what they are looking at will pass on the thing it was written to catch.

On the changeset — you were right and my dispatch was wrong

Land as is, no changeset. I carried that requirement over from the objectstack monorepo without checking whether it applies here, and it does not: no .changeset/ now or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md or CLAUDE.md. Your option A, for your reason — a convention with no tooling behind it is a rule nothing enforces, which is the same failure class as the card you just fixed. I have sent the correction to the four other agents in this round.

If release notes are ever wanted here, that is your option C as its own card, not a directory quietly appearing in a test-only PR.

---

Generated by Claude Code

[os-warren]

Fixes#37

Deletes the scoped bare-reference walk from test/assignment-fanout.test.ts and hands
the rule to test/flow-predicates.test.ts, which already owns it. The file header, which
claimed this file was the only gate for flows, now points at the owner.

The reproduction — the current test passes on a real bare reference

A test never seen failing is not a test, so the defect was reproduced before the walk was
touched. All measurements below mutate and measure inside a single shell invocation, with
the mutation confirmed on disk (grep -F -c both directions) and the file restored from a
byte-copy afterwards, verified by sha256sum.

Mutation — the issue's exact shape, in src/flows/assignment.flow.ts, the start node:

- condition: P`record.status == "dispatched"`,+ condition: P`status == "dispatched" && record.status != "cancelled"`,

A. The walk under test, in isolation. A genuine bare status is in the predicate:

$ npx vitest run test/assignment-fanout.test.ts -t "every predicate qualifies its record reads"
Test Files 1 passed (1)
Tests 1 passed | 27 skipped (28)
EXIT_A=0

Green. bare.test(source) matches on the leading status, and toContain('record.status')
is then satisfied by the second clause — a different question from the one it just asked.

B. The realistic form: the whole file goes green. All four predicates this flow
authors are also pinned by exact-equality assertions elsewhere in the same file, so growing
one clause trips a literal pin — which an author then updates, because updating it is the
obvious thing to do. Doing both, exactly as an author would:

 Test Files 1 passed (1)
Tests 28 passed (28)
EXIT_B=0

28/28 green with a real bare reference shipped in the flow.

C. The same tree, judged by the repo-level walk:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
+ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare — write record.status [status == \"dispatched\" && record.status != \"cancelled\"]"

Located, corrective, and naming the occurrence rather than the predicate.

D. The platform gate, for completeness.pnpm validate exits 0 on the mutated
tree. That is correct and deliberate — AGENTS.md rule 4: flow node and edge conditions run
in flattened scope, so collectBoundRecordReads never judges a bare identifier there. The
repo-local gate is genuinely load-bearing on this surface; only this copy of it was not.

Why deletion rather than strengthening the walk

test/flow-predicates.test.ts strictly dominates it: per identifier instead of per source,
over every flow in dulyFlows instead of this one, exempting declared flow variables
(the platform's own exemption, so it cannot disagree with objectstack-ai/objectstack#14089
about what a defect is), and recursing into loop / parallel / try_catch bodies through
the platform's collectFlowGraphs rather than a hand-rolled config.body.edges walk. It
carries self-tests pinning that it can fail, including the compound case this card is about.

So the scoped walk contributed no coverage and could not fail on its own subject. Two guards
on one rule — one of them unable to fail — is a maintenance hazard rather than depth, and
both are slated to go away when objectstack-ai/objectstack#14089 lands and pnpm validate
covers bare identifiers itself. Keeping two in step is what that file's own header warns
against.

Coverage of this flow stays anchored at both ends: is registered in dulyFlows in this file
pins that the flow is in the collection, and the repo-level walk walks that collection.

No coverage was lost — measured after the deletion

The same mutation as B, on the fixed tree, through the full suite:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
Test Files 1 failed | 19 passed (20)
Tests 1 failed | 534 passed (535)

What was 28/28 green before now takes the suite red through exactly one guard, the right
one. Test count moves 536 → 535: one assertion removed, none broken.

Gates

All four green at 0cacc78, the commit this PR points at, on a clean tree:

$ pnpm validate → ✓ Validation passed (339ms) VALIDATE_EXIT=0
$ pnpm typecheck → (no output) TYPECHECK_EXIT=0
$ pnpm test → Test Files 20 passed (20) · Tests 535 passed (535) TEST_EXIT=0
$ pnpm build → ✓ Build complete (559ms) BUILD_EXIT=0

The one validate warning naming @objectstack/security-enterprise is the documented
expected state of this checkout (AGENTS.md rule 7), not a regression.

No changeset

The dispatch asked for .changeset/*.md. This repo has no changeset mechanism: no
.changeset/ directory now or at any point in git log --all, no @changesets/*
dependency, no changeset script, no mention anywhere outside node_modules, and CI runs
only the four gates. AGENTS.md's "Landing your work" lists those four and never mentions a
changeset. Creating the directory here would mint a mechanism nothing reads, which the next
agent would take for a real one. Flagged for the maintainer rather than decided quietly —
say the word and it gets added. The change is test-only in any case, with no user-visible
surface.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed and verified independently — merging

Deleting a guard needs a higher bar than adding one, so I re-measured rather than reading the report. Both claims hold.

Gates, re-run by me on 0cacc78 in a clean review worktree:validate 0, typecheck 0, test 0, build 0. The only validate output is the pre-existing hierarchy-security enterprise-edition warning, which is expected and unrelated.

The dominance claim, re-measured. I mutated the fan-out flow's start condition to the exact shape the card names and ran the retained guard against it, mutating and measuring inside a single shell call so no restore could sit between the two:

- []
+ [ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare
— write record.status [status == \"dispatched\" && record.status != \"cancelled\"]" ]
Tests 1 failed | 12 passed (13)

test/flow-predicates.test.ts catches it, by name, with the offending source quoted. Restored byte-clean afterwards (git diff --quiet → clean). So the coverage the deleted walk was supposed to provide is genuinely still there, and is stronger: per identifier rather than per source, across all of dulyFlows rather than this one flow, with the declared-variable exemption and collectFlowGraphs region recursion. I confirmed those four by reading the file, not from the report.

The deleted assertion's flaw is worth restating because it is a reusable shape: bare.test(source) correctly found the bare status, and then toContain('record.status') asked a different question — is the qualified form present anywhere in this string — which the second clause answered yes to. A guard whose detector and whose assertion disagree about what they are looking at will pass on the thing it was written to catch.

On the changeset — you were right and my dispatch was wrong

Land as is, no changeset. I carried that requirement over from the objectstack monorepo without checking whether it applies here, and it does not: no .changeset/ now or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md or CLAUDE.md. Your option A, for your reason — a convention with no tooling behind it is a rule nothing enforces, which is the same failure class as the card you just fixed. I have sent the correction to the four other agents in this round.

If release notes are ever wanted here, that is your option C as its own card, not a directory quietly appearing in a test-only PR.

---

Generated by Claude Code

[os-warren]

Fixes#37

Deletes the scoped bare-reference walk from test/assignment-fanout.test.ts and hands
the rule to test/flow-predicates.test.ts, which already owns it. The file header, which
claimed this file was the only gate for flows, now points at the owner.

The reproduction — the current test passes on a real bare reference

A test never seen failing is not a test, so the defect was reproduced before the walk was
touched. All measurements below mutate and measure inside a single shell invocation, with
the mutation confirmed on disk (grep -F -c both directions) and the file restored from a
byte-copy afterwards, verified by sha256sum.

Mutation — the issue's exact shape, in src/flows/assignment.flow.ts, the start node:

- condition: P`record.status == "dispatched"`,+ condition: P`status == "dispatched" && record.status != "cancelled"`,

A. The walk under test, in isolation. A genuine bare status is in the predicate:

$ npx vitest run test/assignment-fanout.test.ts -t "every predicate qualifies its record reads"
Test Files 1 passed (1)
Tests 1 passed | 27 skipped (28)
EXIT_A=0

Green. bare.test(source) matches on the leading status, and toContain('record.status')
is then satisfied by the second clause — a different question from the one it just asked.

B. The realistic form: the whole file goes green. All four predicates this flow
authors are also pinned by exact-equality assertions elsewhere in the same file, so growing
one clause trips a literal pin — which an author then updates, because updating it is the
obvious thing to do. Doing both, exactly as an author would:

 Test Files 1 passed (1)
Tests 28 passed (28)
EXIT_B=0

28/28 green with a real bare reference shipped in the flow.

C. The same tree, judged by the repo-level walk:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
+ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare — write record.status [status == \"dispatched\" && record.status != \"cancelled\"]"

Located, corrective, and naming the occurrence rather than the predicate.

D. The platform gate, for completeness.pnpm validate exits 0 on the mutated
tree. That is correct and deliberate — AGENTS.md rule 4: flow node and edge conditions run
in flattened scope, so collectBoundRecordReads never judges a bare identifier there. The
repo-local gate is genuinely load-bearing on this surface; only this copy of it was not.

Why deletion rather than strengthening the walk

test/flow-predicates.test.ts strictly dominates it: per identifier instead of per source,
over every flow in dulyFlows instead of this one, exempting declared flow variables
(the platform's own exemption, so it cannot disagree with objectstack-ai/objectstack#14089
about what a defect is), and recursing into loop / parallel / try_catch bodies through
the platform's collectFlowGraphs rather than a hand-rolled config.body.edges walk. It
carries self-tests pinning that it can fail, including the compound case this card is about.

So the scoped walk contributed no coverage and could not fail on its own subject. Two guards
on one rule — one of them unable to fail — is a maintenance hazard rather than depth, and
both are slated to go away when objectstack-ai/objectstack#14089 lands and pnpm validate
covers bare identifiers itself. Keeping two in step is what that file's own header warns
against.

Coverage of this flow stays anchored at both ends: is registered in dulyFlows in this file
pins that the flow is in the collection, and the repo-level walk walks that collection.

No coverage was lost — measured after the deletion

The same mutation as B, on the fixed tree, through the full suite:

 FAIL test/flow-predicates.test.ts > every predicate in dulyFlows qualifies its record reads with `record.`
Test Files 1 failed | 19 passed (20)
Tests 1 failed | 534 passed (535)

What was 28/28 green before now takes the suite red through exactly one guard, the right
one. Test count moves 536 → 535: one assertion removed, none broken.

Gates

All four green at 0cacc78, the commit this PR points at, on a clean tree:

$ pnpm validate → ✓ Validation passed (339ms) VALIDATE_EXIT=0
$ pnpm typecheck → (no output) TYPECHECK_EXIT=0
$ pnpm test → Test Files 20 passed (20) · Tests 535 passed (535) TEST_EXIT=0
$ pnpm build → ✓ Build complete (559ms) BUILD_EXIT=0

The one validate warning naming @objectstack/security-enterprise is the documented
expected state of this checkout (AGENTS.md rule 7), not a regression.

No changeset

The dispatch asked for .changeset/*.md. This repo has no changeset mechanism: no
.changeset/ directory now or at any point in git log --all, no @changesets/*
dependency, no changeset script, no mention anywhere outside node_modules, and CI runs
only the four gates. AGENTS.md's "Landing your work" lists those four and never mentions a
changeset. Creating the directory here would mint a mechanism nothing reads, which the next
agent would take for a real one. Flagged for the maintainer rather than decided quietly —
say the word and it gets added. The change is test-only in any case, with no user-visible
surface.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed and verified independently — merging

Deleting a guard needs a higher bar than adding one, so I re-measured rather than reading the report. Both claims hold.

Gates, re-run by me on 0cacc78 in a clean review worktree:validate 0, typecheck 0, test 0, build 0. The only validate output is the pre-existing hierarchy-security enterprise-edition warning, which is expected and unrelated.

The dominance claim, re-measured. I mutated the fan-out flow's start condition to the exact shape the card names and ran the retained guard against it, mutating and measuring inside a single shell call so no restore could sit between the two:

- []
+ [ "duly_assignment_fanout · node 'start' config.condition: reads 'status' bare
— write record.status [status == \"dispatched\" && record.status != \"cancelled\"]" ]
Tests 1 failed | 12 passed (13)

test/flow-predicates.test.ts catches it, by name, with the offending source quoted. Restored byte-clean afterwards (git diff --quiet → clean). So the coverage the deleted walk was supposed to provide is genuinely still there, and is stronger: per identifier rather than per source, across all of dulyFlows rather than this one flow, with the declared-variable exemption and collectFlowGraphs region recursion. I confirmed those four by reading the file, not from the report.

The deleted assertion's flaw is worth restating because it is a reusable shape: bare.test(source) correctly found the bare status, and then toContain('record.status') asked a different question — is the qualified form present anywhere in this string — which the second clause answered yes to. A guard whose detector and whose assertion disagree about what they are looking at will pass on the thing it was written to catch.

On the changeset — you were right and my dispatch was wrong

Land as is, no changeset. I carried that requirement over from the objectstack monorepo without checking whether it applies here, and it does not: no .changeset/ now or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md or CLAUDE.md. Your option A, for your reason — a convention with no tooling behind it is a rule nothing enforces, which is the same failure class as the card you just fixed. I have sent the correction to the four other agents in this round.

If release notes are ever wanted here, that is your option C as its own card, not a directory quietly appearing in a test-only PR.

---

Generated by Claude Code