Pass the engine facade a bare filter, not a query envelope

[os-warren]

Fixes#79

ctx.engine.find(object, query) takes a bare filter. The runtime's buildActionEngineFacade (@objectstack/runtime 17.2.0) adds the ObjectQL envelope itself:

asyncfind(object,query){constwhere=query&&Object.keys(query).length ? {where: query} : {};constrows=awaitql.find(object,{ ...where, context });

Every filtered read in src/actions/catalog.handlers.ts passed an envelope, so through the real dispatcher the query arrived as { where: { where: { … } } }. No row has a field called where, so each read came back empty with no error: duly_catalog_apply reported a successful run of zero, duly_catalog_sync scanned nothing and called every duty unchanged, and resolveBusinessUnit created unanchored duties. Only the one unfiltered read survived, because Object.keys({}).length === 0 skips the wrapping entirely — which is what made the handler look partially alive.

What changed

• All five engine.find calls pass the filter flat — the apply catalog read and its duly_duty idempotency probe, the sync catalog read (both the narrowed and the unnarrowed branch) and its { source: 'catalog' } duty read, and resolveBusinessUnit's sys_user_position read.
• FakeEngine.find in test/catalog-instantiate.test.ts reads the flat filter. It used to read query.where, honouring the handler's convention rather than the runtime's, which is exactly how 78 duty assertions stayed green against a shape production never produced. Left as-is, the fix would have been invisible to the suite.
• The #79 tripwire in test/catalog-apply-cadence.test.ts is deleted, not adjusted — it was written to go red when this landed. Its two facades collapse into one: handlerFacade now reproduces buildActionEngineFacade line for line, so there is a single convention in the file.
• New test/catalog-engine-facade.test.ts dispatches through the real action route (HttpDispatcher.handleActions — the function createActionsDomain's route delegates to) and lets the runtime build ctx.engine itself. No facade is written in that file; that is the point. It covers apply, the business-unit anchor, idempotency across two dispatched runs, the object-bound twin's own route, sync's scan/replay, the narrowed sweep, and the retired report, plus one control asserting the route really is the capability-gated platform route.

A tolerant query.where ?? query rung was deliberately not added anywhere — a consumer that accepts both shapes is what let the wrong one ship green. The contract half (ActionEngineFacade.find types query as a plain record and says nothing about which shape it is) is filed upstream as objectstack-ai/objectstack#14175 and referenced from a code comment; this PR does not wait on it.

Acceptance

From the issue	Where it is pinned
apply, dispatched with the facade the runtime builds, creates the duties for a matching position_code	catalog-engine-facade.test.ts — "creates the duties for a matching position_code"
duly_catalog_sync scans the catalog-sourced duties it is supposed to scan	same file — "scans the catalog-sourced duties and replays a cadence edit" (scanned: 2, updated: 2)
the tripwire is deleted, not adjusted	catalog-apply-cadence.test.ts — last describe and runtimeFacade removed

Verification

All four gates on 0c510fd, each read from its own verdict output (exit codes captured before any pipe):

GATE validate EXIT=0 # one expected warning: hierarchy-security provider absent (AGENTS.md)
GATE typecheck EXIT=0
GATE test EXIT=0 # Test Files 22 passed (22) · Tests 559 passed (559)
GATE build EXIT=0 # Build complete (597ms) · dist/objectstack.json

Reverse verification. The pre-fix src/actions/catalog.handlers.ts was restored from origin/main over the fixed tree, the mutation was confirmed on disk by grep before anything ran (1 envelope read present, 0 flat reads — an editor's exit code proves nothing), and the three catalog suites were re-run:

❯ test/catalog-apply-cadence.test.ts (3 tests | 2 failed)
❯ test/catalog-engine-facade.test.ts (8 tests | 7 failed)
❯ test/catalog-instantiate.test.ts (31 tests | 14 failed)
vitest exit: 1

23 failures, in the predicted direction and across all three suites — before this PR only the tripwire could see the defect. The one new test that stays green under the mutation is the capability control, which does not depend on the query shape. The mutation script carried a trap … EXIT INT TERM restore, and the tree was confirmed clean against HEAD afterwards. No rebuild leg was needed: these suites import ../src/… directly, so nothing resolves through dist/.

No changeset: this repo has no changeset mechanism (no .changeset/ in the tree or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates in .github/workflows/ci.yml are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. Two things I checked beyond the report.

1. Gates on the PR head, re-run by me on 0c510fd:validate 0, typecheck 0, test 0 (Test Files 22 passed, Tests 559 passed), build 0.

2. Gates on the head merged with current main, which is the state that actually lands. This branch was cut from dbe1537 and is two commits behind — it does not contain #83 (the duly_duty timezone write guard) or #85 (grouped-view projection). #83 matters here specifically: it puts a beforeInsert/beforeUpdate hook on duly_duty, and applyCatalogHandler writes duties. A fix that makes the catalog action start creating duties for the first time, landing next to a new guard that can refuse a duty write, is exactly the combination worth checking rather than assuming.

Merged origin/main into the branch locally and re-ran everything: Test Files 23 passed, Tests 589 passed, all four gates 0, no conflicts. The two changes are independent in practice. I have pushed that update to the branch so CI runs on the combination rather than on the older base.

On the work itself

• Five call sites, not four. My card said four; the fifth is resolveBusinessUnit's sys_user_position read, which my own blast-radius section named and my count missed. That one was the nastiest of the set — "no position row" is a legitimate day-one state the handler tolerates, so its failure produced unanchored duties with no error anywhere.
• The test dispatches through HttpDispatcher.handleActions, so the runtime builds ctx.engine. No double is written in that file. This is the whole point of the card: the previous suite was green because a hand-written FakeEngine encoded the author's belief about the contract, so the fake and the handler were wrong in the same direction by construction. A test that builds its own facade could not have caught this and cannot catch the next one.
• No tolerant query.where ?? query rung anywhere. Correct, and worth stating why: accepting both shapes would have made the app work while leaving objectstack#14175 invisible, and the next application to read that type would make the same choice with nothing to warn it.
• The ablation is the real evidence. Restoring the pre-fix handler over the fixed tree turns three suites red — 23 failures across catalog-apply-cadence (2), catalog-engine-facade (7) and catalog-instantiate (14) — where before the fix the tripwire was the only thing that could see the defect at all. That number is the answer to "did the tests actually gain coverage", and it is a much better answer than a passing run.
• The tripwire was deleted rather than adjusted, as the card asked.

---

Generated by Claude Code

[os-warren]

Fixes#79

ctx.engine.find(object, query) takes a bare filter. The runtime's buildActionEngineFacade (@objectstack/runtime 17.2.0) adds the ObjectQL envelope itself:

asyncfind(object,query){constwhere=query&&Object.keys(query).length ? {where: query} : {};constrows=awaitql.find(object,{ ...where, context });

Every filtered read in src/actions/catalog.handlers.ts passed an envelope, so through the real dispatcher the query arrived as { where: { where: { … } } }. No row has a field called where, so each read came back empty with no error: duly_catalog_apply reported a successful run of zero, duly_catalog_sync scanned nothing and called every duty unchanged, and resolveBusinessUnit created unanchored duties. Only the one unfiltered read survived, because Object.keys({}).length === 0 skips the wrapping entirely — which is what made the handler look partially alive.

What changed

• All five engine.find calls pass the filter flat — the apply catalog read and its duly_duty idempotency probe, the sync catalog read (both the narrowed and the unnarrowed branch) and its { source: 'catalog' } duty read, and resolveBusinessUnit's sys_user_position read.
• FakeEngine.find in test/catalog-instantiate.test.ts reads the flat filter. It used to read query.where, honouring the handler's convention rather than the runtime's, which is exactly how 78 duty assertions stayed green against a shape production never produced. Left as-is, the fix would have been invisible to the suite.
• The #79 tripwire in test/catalog-apply-cadence.test.ts is deleted, not adjusted — it was written to go red when this landed. Its two facades collapse into one: handlerFacade now reproduces buildActionEngineFacade line for line, so there is a single convention in the file.
• New test/catalog-engine-facade.test.ts dispatches through the real action route (HttpDispatcher.handleActions — the function createActionsDomain's route delegates to) and lets the runtime build ctx.engine itself. No facade is written in that file; that is the point. It covers apply, the business-unit anchor, idempotency across two dispatched runs, the object-bound twin's own route, sync's scan/replay, the narrowed sweep, and the retired report, plus one control asserting the route really is the capability-gated platform route.

A tolerant query.where ?? query rung was deliberately not added anywhere — a consumer that accepts both shapes is what let the wrong one ship green. The contract half (ActionEngineFacade.find types query as a plain record and says nothing about which shape it is) is filed upstream as objectstack-ai/objectstack#14175 and referenced from a code comment; this PR does not wait on it.

Acceptance

From the issue	Where it is pinned
apply, dispatched with the facade the runtime builds, creates the duties for a matching position_code	catalog-engine-facade.test.ts — "creates the duties for a matching position_code"
duly_catalog_sync scans the catalog-sourced duties it is supposed to scan	same file — "scans the catalog-sourced duties and replays a cadence edit" (scanned: 2, updated: 2)
the tripwire is deleted, not adjusted	catalog-apply-cadence.test.ts — last describe and runtimeFacade removed

Verification

All four gates on 0c510fd, each read from its own verdict output (exit codes captured before any pipe):

GATE validate EXIT=0 # one expected warning: hierarchy-security provider absent (AGENTS.md)
GATE typecheck EXIT=0
GATE test EXIT=0 # Test Files 22 passed (22) · Tests 559 passed (559)
GATE build EXIT=0 # Build complete (597ms) · dist/objectstack.json

Reverse verification. The pre-fix src/actions/catalog.handlers.ts was restored from origin/main over the fixed tree, the mutation was confirmed on disk by grep before anything ran (1 envelope read present, 0 flat reads — an editor's exit code proves nothing), and the three catalog suites were re-run:

❯ test/catalog-apply-cadence.test.ts (3 tests | 2 failed)
❯ test/catalog-engine-facade.test.ts (8 tests | 7 failed)
❯ test/catalog-instantiate.test.ts (31 tests | 14 failed)
vitest exit: 1

23 failures, in the predicted direction and across all three suites — before this PR only the tripwire could see the defect. The one new test that stays green under the mutation is the capability control, which does not depend on the query shape. The mutation script carried a trap … EXIT INT TERM restore, and the tree was confirmed clean against HEAD afterwards. No rebuild leg was needed: these suites import ../src/… directly, so nothing resolves through dist/.

No changeset: this repo has no changeset mechanism (no .changeset/ in the tree or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates in .github/workflows/ci.yml are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. Two things I checked beyond the report.

1. Gates on the PR head, re-run by me on 0c510fd:validate 0, typecheck 0, test 0 (Test Files 22 passed, Tests 559 passed), build 0.

2. Gates on the head merged with current main, which is the state that actually lands. This branch was cut from dbe1537 and is two commits behind — it does not contain #83 (the duly_duty timezone write guard) or #85 (grouped-view projection). #83 matters here specifically: it puts a beforeInsert/beforeUpdate hook on duly_duty, and applyCatalogHandler writes duties. A fix that makes the catalog action start creating duties for the first time, landing next to a new guard that can refuse a duty write, is exactly the combination worth checking rather than assuming.

Merged origin/main into the branch locally and re-ran everything: Test Files 23 passed, Tests 589 passed, all four gates 0, no conflicts. The two changes are independent in practice. I have pushed that update to the branch so CI runs on the combination rather than on the older base.

On the work itself

• Five call sites, not four. My card said four; the fifth is resolveBusinessUnit's sys_user_position read, which my own blast-radius section named and my count missed. That one was the nastiest of the set — "no position row" is a legitimate day-one state the handler tolerates, so its failure produced unanchored duties with no error anywhere.
• The test dispatches through HttpDispatcher.handleActions, so the runtime builds ctx.engine. No double is written in that file. This is the whole point of the card: the previous suite was green because a hand-written FakeEngine encoded the author's belief about the contract, so the fake and the handler were wrong in the same direction by construction. A test that builds its own facade could not have caught this and cannot catch the next one.
• No tolerant query.where ?? query rung anywhere. Correct, and worth stating why: accepting both shapes would have made the app work while leaving objectstack#14175 invisible, and the next application to read that type would make the same choice with nothing to warn it.
• The ablation is the real evidence. Restoring the pre-fix handler over the fixed tree turns three suites red — 23 failures across catalog-apply-cadence (2), catalog-engine-facade (7) and catalog-instantiate (14) — where before the fix the tripwire was the only thing that could see the defect at all. That number is the answer to "did the tests actually gain coverage", and it is a much better answer than a passing run.
• The tripwire was deleted rather than adjusted, as the card asked.

---

Generated by Claude Code

[os-warren]

Fixes#79

ctx.engine.find(object, query) takes a bare filter. The runtime's buildActionEngineFacade (@objectstack/runtime 17.2.0) adds the ObjectQL envelope itself:

asyncfind(object,query){constwhere=query&&Object.keys(query).length ? {where: query} : {};constrows=awaitql.find(object,{ ...where, context });

Every filtered read in src/actions/catalog.handlers.ts passed an envelope, so through the real dispatcher the query arrived as { where: { where: { … } } }. No row has a field called where, so each read came back empty with no error: duly_catalog_apply reported a successful run of zero, duly_catalog_sync scanned nothing and called every duty unchanged, and resolveBusinessUnit created unanchored duties. Only the one unfiltered read survived, because Object.keys({}).length === 0 skips the wrapping entirely — which is what made the handler look partially alive.

What changed

• All five engine.find calls pass the filter flat — the apply catalog read and its duly_duty idempotency probe, the sync catalog read (both the narrowed and the unnarrowed branch) and its { source: 'catalog' } duty read, and resolveBusinessUnit's sys_user_position read.
• FakeEngine.find in test/catalog-instantiate.test.ts reads the flat filter. It used to read query.where, honouring the handler's convention rather than the runtime's, which is exactly how 78 duty assertions stayed green against a shape production never produced. Left as-is, the fix would have been invisible to the suite.
• The #79 tripwire in test/catalog-apply-cadence.test.ts is deleted, not adjusted — it was written to go red when this landed. Its two facades collapse into one: handlerFacade now reproduces buildActionEngineFacade line for line, so there is a single convention in the file.
• New test/catalog-engine-facade.test.ts dispatches through the real action route (HttpDispatcher.handleActions — the function createActionsDomain's route delegates to) and lets the runtime build ctx.engine itself. No facade is written in that file; that is the point. It covers apply, the business-unit anchor, idempotency across two dispatched runs, the object-bound twin's own route, sync's scan/replay, the narrowed sweep, and the retired report, plus one control asserting the route really is the capability-gated platform route.

A tolerant query.where ?? query rung was deliberately not added anywhere — a consumer that accepts both shapes is what let the wrong one ship green. The contract half (ActionEngineFacade.find types query as a plain record and says nothing about which shape it is) is filed upstream as objectstack-ai/objectstack#14175 and referenced from a code comment; this PR does not wait on it.

Acceptance

From the issue	Where it is pinned
apply, dispatched with the facade the runtime builds, creates the duties for a matching position_code	catalog-engine-facade.test.ts — "creates the duties for a matching position_code"
duly_catalog_sync scans the catalog-sourced duties it is supposed to scan	same file — "scans the catalog-sourced duties and replays a cadence edit" (scanned: 2, updated: 2)
the tripwire is deleted, not adjusted	catalog-apply-cadence.test.ts — last describe and runtimeFacade removed

Verification

All four gates on 0c510fd, each read from its own verdict output (exit codes captured before any pipe):

GATE validate EXIT=0 # one expected warning: hierarchy-security provider absent (AGENTS.md)
GATE typecheck EXIT=0
GATE test EXIT=0 # Test Files 22 passed (22) · Tests 559 passed (559)
GATE build EXIT=0 # Build complete (597ms) · dist/objectstack.json

Reverse verification. The pre-fix src/actions/catalog.handlers.ts was restored from origin/main over the fixed tree, the mutation was confirmed on disk by grep before anything ran (1 envelope read present, 0 flat reads — an editor's exit code proves nothing), and the three catalog suites were re-run:

❯ test/catalog-apply-cadence.test.ts (3 tests | 2 failed)
❯ test/catalog-engine-facade.test.ts (8 tests | 7 failed)
❯ test/catalog-instantiate.test.ts (31 tests | 14 failed)
vitest exit: 1

23 failures, in the predicted direction and across all three suites — before this PR only the tripwire could see the defect. The one new test that stays green under the mutation is the capability control, which does not depend on the query shape. The mutation script carried a trap … EXIT INT TERM restore, and the tree was confirmed clean against HEAD afterwards. No rebuild leg was needed: these suites import ../src/… directly, so nothing resolves through dist/.

No changeset: this repo has no changeset mechanism (no .changeset/ in the tree or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates in .github/workflows/ci.yml are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. Two things I checked beyond the report.

1. Gates on the PR head, re-run by me on 0c510fd:validate 0, typecheck 0, test 0 (Test Files 22 passed, Tests 559 passed), build 0.

2. Gates on the head merged with current main, which is the state that actually lands. This branch was cut from dbe1537 and is two commits behind — it does not contain #83 (the duly_duty timezone write guard) or #85 (grouped-view projection). #83 matters here specifically: it puts a beforeInsert/beforeUpdate hook on duly_duty, and applyCatalogHandler writes duties. A fix that makes the catalog action start creating duties for the first time, landing next to a new guard that can refuse a duty write, is exactly the combination worth checking rather than assuming.

Merged origin/main into the branch locally and re-ran everything: Test Files 23 passed, Tests 589 passed, all four gates 0, no conflicts. The two changes are independent in practice. I have pushed that update to the branch so CI runs on the combination rather than on the older base.

On the work itself

• Five call sites, not four. My card said four; the fifth is resolveBusinessUnit's sys_user_position read, which my own blast-radius section named and my count missed. That one was the nastiest of the set — "no position row" is a legitimate day-one state the handler tolerates, so its failure produced unanchored duties with no error anywhere.
• The test dispatches through HttpDispatcher.handleActions, so the runtime builds ctx.engine. No double is written in that file. This is the whole point of the card: the previous suite was green because a hand-written FakeEngine encoded the author's belief about the contract, so the fake and the handler were wrong in the same direction by construction. A test that builds its own facade could not have caught this and cannot catch the next one.
• No tolerant query.where ?? query rung anywhere. Correct, and worth stating why: accepting both shapes would have made the app work while leaving objectstack#14175 invisible, and the next application to read that type would make the same choice with nothing to warn it.
• The ablation is the real evidence. Restoring the pre-fix handler over the fixed tree turns three suites red — 23 failures across catalog-apply-cadence (2), catalog-engine-facade (7) and catalog-instantiate (14) — where before the fix the tripwire was the only thing that could see the defect at all. That number is the answer to "did the tests actually gain coverage", and it is a much better answer than a passing run.
• The tripwire was deleted rather than adjusted, as the card asked.

---

Generated by Claude Code

[os-warren]

Fixes#79

ctx.engine.find(object, query) takes a bare filter. The runtime's buildActionEngineFacade (@objectstack/runtime 17.2.0) adds the ObjectQL envelope itself:

asyncfind(object,query){constwhere=query&&Object.keys(query).length ? {where: query} : {};constrows=awaitql.find(object,{ ...where, context });

Every filtered read in src/actions/catalog.handlers.ts passed an envelope, so through the real dispatcher the query arrived as { where: { where: { … } } }. No row has a field called where, so each read came back empty with no error: duly_catalog_apply reported a successful run of zero, duly_catalog_sync scanned nothing and called every duty unchanged, and resolveBusinessUnit created unanchored duties. Only the one unfiltered read survived, because Object.keys({}).length === 0 skips the wrapping entirely — which is what made the handler look partially alive.

What changed

• All five engine.find calls pass the filter flat — the apply catalog read and its duly_duty idempotency probe, the sync catalog read (both the narrowed and the unnarrowed branch) and its { source: 'catalog' } duty read, and resolveBusinessUnit's sys_user_position read.
• FakeEngine.find in test/catalog-instantiate.test.ts reads the flat filter. It used to read query.where, honouring the handler's convention rather than the runtime's, which is exactly how 78 duty assertions stayed green against a shape production never produced. Left as-is, the fix would have been invisible to the suite.
• The #79 tripwire in test/catalog-apply-cadence.test.ts is deleted, not adjusted — it was written to go red when this landed. Its two facades collapse into one: handlerFacade now reproduces buildActionEngineFacade line for line, so there is a single convention in the file.
• New test/catalog-engine-facade.test.ts dispatches through the real action route (HttpDispatcher.handleActions — the function createActionsDomain's route delegates to) and lets the runtime build ctx.engine itself. No facade is written in that file; that is the point. It covers apply, the business-unit anchor, idempotency across two dispatched runs, the object-bound twin's own route, sync's scan/replay, the narrowed sweep, and the retired report, plus one control asserting the route really is the capability-gated platform route.

A tolerant query.where ?? query rung was deliberately not added anywhere — a consumer that accepts both shapes is what let the wrong one ship green. The contract half (ActionEngineFacade.find types query as a plain record and says nothing about which shape it is) is filed upstream as objectstack-ai/objectstack#14175 and referenced from a code comment; this PR does not wait on it.

Acceptance

From the issue	Where it is pinned
apply, dispatched with the facade the runtime builds, creates the duties for a matching position_code	catalog-engine-facade.test.ts — "creates the duties for a matching position_code"
duly_catalog_sync scans the catalog-sourced duties it is supposed to scan	same file — "scans the catalog-sourced duties and replays a cadence edit" (scanned: 2, updated: 2)
the tripwire is deleted, not adjusted	catalog-apply-cadence.test.ts — last describe and runtimeFacade removed

Verification

All four gates on 0c510fd, each read from its own verdict output (exit codes captured before any pipe):

GATE validate EXIT=0 # one expected warning: hierarchy-security provider absent (AGENTS.md)
GATE typecheck EXIT=0
GATE test EXIT=0 # Test Files 22 passed (22) · Tests 559 passed (559)
GATE build EXIT=0 # Build complete (597ms) · dist/objectstack.json

Reverse verification. The pre-fix src/actions/catalog.handlers.ts was restored from origin/main over the fixed tree, the mutation was confirmed on disk by grep before anything ran (1 envelope read present, 0 flat reads — an editor's exit code proves nothing), and the three catalog suites were re-run:

❯ test/catalog-apply-cadence.test.ts (3 tests | 2 failed)
❯ test/catalog-engine-facade.test.ts (8 tests | 7 failed)
❯ test/catalog-instantiate.test.ts (31 tests | 14 failed)
vitest exit: 1

23 failures, in the predicted direction and across all three suites — before this PR only the tripwire could see the defect. The one new test that stays green under the mutation is the capability control, which does not depend on the query shape. The mutation script carried a trap … EXIT INT TERM restore, and the tree was confirmed clean against HEAD afterwards. No rebuild leg was needed: these suites import ../src/… directly, so nothing resolves through dist/.

No changeset: this repo has no changeset mechanism (no .changeset/ in the tree or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates in .github/workflows/ci.yml are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. Two things I checked beyond the report.

1. Gates on the PR head, re-run by me on 0c510fd:validate 0, typecheck 0, test 0 (Test Files 22 passed, Tests 559 passed), build 0.

2. Gates on the head merged with current main, which is the state that actually lands. This branch was cut from dbe1537 and is two commits behind — it does not contain #83 (the duly_duty timezone write guard) or #85 (grouped-view projection). #83 matters here specifically: it puts a beforeInsert/beforeUpdate hook on duly_duty, and applyCatalogHandler writes duties. A fix that makes the catalog action start creating duties for the first time, landing next to a new guard that can refuse a duty write, is exactly the combination worth checking rather than assuming.

Merged origin/main into the branch locally and re-ran everything: Test Files 23 passed, Tests 589 passed, all four gates 0, no conflicts. The two changes are independent in practice. I have pushed that update to the branch so CI runs on the combination rather than on the older base.

On the work itself

• Five call sites, not four. My card said four; the fifth is resolveBusinessUnit's sys_user_position read, which my own blast-radius section named and my count missed. That one was the nastiest of the set — "no position row" is a legitimate day-one state the handler tolerates, so its failure produced unanchored duties with no error anywhere.
• The test dispatches through HttpDispatcher.handleActions, so the runtime builds ctx.engine. No double is written in that file. This is the whole point of the card: the previous suite was green because a hand-written FakeEngine encoded the author's belief about the contract, so the fake and the handler were wrong in the same direction by construction. A test that builds its own facade could not have caught this and cannot catch the next one.
• No tolerant query.where ?? query rung anywhere. Correct, and worth stating why: accepting both shapes would have made the app work while leaving objectstack#14175 invisible, and the next application to read that type would make the same choice with nothing to warn it.
• The ablation is the real evidence. Restoring the pre-fix handler over the fixed tree turns three suites red — 23 failures across catalog-apply-cadence (2), catalog-engine-facade (7) and catalog-instantiate (14) — where before the fix the tripwire was the only thing that could see the defect at all. That number is the answer to "did the tests actually gain coverage", and it is a much better answer than a passing run.
• The tripwire was deleted rather than adjusted, as the card asked.

---

Generated by Claude Code

[os-warren]

Fixes#79

ctx.engine.find(object, query) takes a bare filter. The runtime's buildActionEngineFacade (@objectstack/runtime 17.2.0) adds the ObjectQL envelope itself:

asyncfind(object,query){constwhere=query&&Object.keys(query).length ? {where: query} : {};constrows=awaitql.find(object,{ ...where, context });

Every filtered read in src/actions/catalog.handlers.ts passed an envelope, so through the real dispatcher the query arrived as { where: { where: { … } } }. No row has a field called where, so each read came back empty with no error: duly_catalog_apply reported a successful run of zero, duly_catalog_sync scanned nothing and called every duty unchanged, and resolveBusinessUnit created unanchored duties. Only the one unfiltered read survived, because Object.keys({}).length === 0 skips the wrapping entirely — which is what made the handler look partially alive.

What changed

• All five engine.find calls pass the filter flat — the apply catalog read and its duly_duty idempotency probe, the sync catalog read (both the narrowed and the unnarrowed branch) and its { source: 'catalog' } duty read, and resolveBusinessUnit's sys_user_position read.
• FakeEngine.find in test/catalog-instantiate.test.ts reads the flat filter. It used to read query.where, honouring the handler's convention rather than the runtime's, which is exactly how 78 duty assertions stayed green against a shape production never produced. Left as-is, the fix would have been invisible to the suite.
• The #79 tripwire in test/catalog-apply-cadence.test.ts is deleted, not adjusted — it was written to go red when this landed. Its two facades collapse into one: handlerFacade now reproduces buildActionEngineFacade line for line, so there is a single convention in the file.
• New test/catalog-engine-facade.test.ts dispatches through the real action route (HttpDispatcher.handleActions — the function createActionsDomain's route delegates to) and lets the runtime build ctx.engine itself. No facade is written in that file; that is the point. It covers apply, the business-unit anchor, idempotency across two dispatched runs, the object-bound twin's own route, sync's scan/replay, the narrowed sweep, and the retired report, plus one control asserting the route really is the capability-gated platform route.

A tolerant query.where ?? query rung was deliberately not added anywhere — a consumer that accepts both shapes is what let the wrong one ship green. The contract half (ActionEngineFacade.find types query as a plain record and says nothing about which shape it is) is filed upstream as objectstack-ai/objectstack#14175 and referenced from a code comment; this PR does not wait on it.

Acceptance

From the issue	Where it is pinned
apply, dispatched with the facade the runtime builds, creates the duties for a matching position_code	catalog-engine-facade.test.ts — "creates the duties for a matching position_code"
duly_catalog_sync scans the catalog-sourced duties it is supposed to scan	same file — "scans the catalog-sourced duties and replays a cadence edit" (scanned: 2, updated: 2)
the tripwire is deleted, not adjusted	catalog-apply-cadence.test.ts — last describe and runtimeFacade removed

Verification

All four gates on 0c510fd, each read from its own verdict output (exit codes captured before any pipe):

GATE validate EXIT=0 # one expected warning: hierarchy-security provider absent (AGENTS.md)
GATE typecheck EXIT=0
GATE test EXIT=0 # Test Files 22 passed (22) · Tests 559 passed (559)
GATE build EXIT=0 # Build complete (597ms) · dist/objectstack.json

Reverse verification. The pre-fix src/actions/catalog.handlers.ts was restored from origin/main over the fixed tree, the mutation was confirmed on disk by grep before anything ran (1 envelope read present, 0 flat reads — an editor's exit code proves nothing), and the three catalog suites were re-run:

❯ test/catalog-apply-cadence.test.ts (3 tests | 2 failed)
❯ test/catalog-engine-facade.test.ts (8 tests | 7 failed)
❯ test/catalog-instantiate.test.ts (31 tests | 14 failed)
vitest exit: 1

23 failures, in the predicted direction and across all three suites — before this PR only the tripwire could see the defect. The one new test that stays green under the mutation is the capability control, which does not depend on the query shape. The mutation script carried a trap … EXIT INT TERM restore, and the tree was confirmed clean against HEAD afterwards. No rebuild leg was needed: these suites import ../src/… directly, so nothing resolves through dist/.

No changeset: this repo has no changeset mechanism (no .changeset/ in the tree or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates in .github/workflows/ci.yml are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. Two things I checked beyond the report.

1. Gates on the PR head, re-run by me on 0c510fd:validate 0, typecheck 0, test 0 (Test Files 22 passed, Tests 559 passed), build 0.

2. Gates on the head merged with current main, which is the state that actually lands. This branch was cut from dbe1537 and is two commits behind — it does not contain #83 (the duly_duty timezone write guard) or #85 (grouped-view projection). #83 matters here specifically: it puts a beforeInsert/beforeUpdate hook on duly_duty, and applyCatalogHandler writes duties. A fix that makes the catalog action start creating duties for the first time, landing next to a new guard that can refuse a duty write, is exactly the combination worth checking rather than assuming.

Merged origin/main into the branch locally and re-ran everything: Test Files 23 passed, Tests 589 passed, all four gates 0, no conflicts. The two changes are independent in practice. I have pushed that update to the branch so CI runs on the combination rather than on the older base.

On the work itself

• Five call sites, not four. My card said four; the fifth is resolveBusinessUnit's sys_user_position read, which my own blast-radius section named and my count missed. That one was the nastiest of the set — "no position row" is a legitimate day-one state the handler tolerates, so its failure produced unanchored duties with no error anywhere.
• The test dispatches through HttpDispatcher.handleActions, so the runtime builds ctx.engine. No double is written in that file. This is the whole point of the card: the previous suite was green because a hand-written FakeEngine encoded the author's belief about the contract, so the fake and the handler were wrong in the same direction by construction. A test that builds its own facade could not have caught this and cannot catch the next one.
• No tolerant query.where ?? query rung anywhere. Correct, and worth stating why: accepting both shapes would have made the app work while leaving objectstack#14175 invisible, and the next application to read that type would make the same choice with nothing to warn it.
• The ablation is the real evidence. Restoring the pre-fix handler over the fixed tree turns three suites red — 23 failures across catalog-apply-cadence (2), catalog-engine-facade (7) and catalog-instantiate (14) — where before the fix the tripwire was the only thing that could see the defect at all. That number is the answer to "did the tests actually gain coverage", and it is a much better answer than a passing run.
• The tripwire was deleted rather than adjusted, as the card asked.

---

Generated by Claude Code

[os-warren]

Fixes#79

ctx.engine.find(object, query) takes a bare filter. The runtime's buildActionEngineFacade (@objectstack/runtime 17.2.0) adds the ObjectQL envelope itself:

asyncfind(object,query){constwhere=query&&Object.keys(query).length ? {where: query} : {};constrows=awaitql.find(object,{ ...where, context });

Every filtered read in src/actions/catalog.handlers.ts passed an envelope, so through the real dispatcher the query arrived as { where: { where: { … } } }. No row has a field called where, so each read came back empty with no error: duly_catalog_apply reported a successful run of zero, duly_catalog_sync scanned nothing and called every duty unchanged, and resolveBusinessUnit created unanchored duties. Only the one unfiltered read survived, because Object.keys({}).length === 0 skips the wrapping entirely — which is what made the handler look partially alive.

What changed

• All five engine.find calls pass the filter flat — the apply catalog read and its duly_duty idempotency probe, the sync catalog read (both the narrowed and the unnarrowed branch) and its { source: 'catalog' } duty read, and resolveBusinessUnit's sys_user_position read.
• FakeEngine.find in test/catalog-instantiate.test.ts reads the flat filter. It used to read query.where, honouring the handler's convention rather than the runtime's, which is exactly how 78 duty assertions stayed green against a shape production never produced. Left as-is, the fix would have been invisible to the suite.
• The #79 tripwire in test/catalog-apply-cadence.test.ts is deleted, not adjusted — it was written to go red when this landed. Its two facades collapse into one: handlerFacade now reproduces buildActionEngineFacade line for line, so there is a single convention in the file.
• New test/catalog-engine-facade.test.ts dispatches through the real action route (HttpDispatcher.handleActions — the function createActionsDomain's route delegates to) and lets the runtime build ctx.engine itself. No facade is written in that file; that is the point. It covers apply, the business-unit anchor, idempotency across two dispatched runs, the object-bound twin's own route, sync's scan/replay, the narrowed sweep, and the retired report, plus one control asserting the route really is the capability-gated platform route.

A tolerant query.where ?? query rung was deliberately not added anywhere — a consumer that accepts both shapes is what let the wrong one ship green. The contract half (ActionEngineFacade.find types query as a plain record and says nothing about which shape it is) is filed upstream as objectstack-ai/objectstack#14175 and referenced from a code comment; this PR does not wait on it.

Acceptance

From the issue	Where it is pinned
apply, dispatched with the facade the runtime builds, creates the duties for a matching position_code	catalog-engine-facade.test.ts — "creates the duties for a matching position_code"
duly_catalog_sync scans the catalog-sourced duties it is supposed to scan	same file — "scans the catalog-sourced duties and replays a cadence edit" (scanned: 2, updated: 2)
the tripwire is deleted, not adjusted	catalog-apply-cadence.test.ts — last describe and runtimeFacade removed

Verification

All four gates on 0c510fd, each read from its own verdict output (exit codes captured before any pipe):

GATE validate EXIT=0 # one expected warning: hierarchy-security provider absent (AGENTS.md)
GATE typecheck EXIT=0
GATE test EXIT=0 # Test Files 22 passed (22) · Tests 559 passed (559)
GATE build EXIT=0 # Build complete (597ms) · dist/objectstack.json

Reverse verification. The pre-fix src/actions/catalog.handlers.ts was restored from origin/main over the fixed tree, the mutation was confirmed on disk by grep before anything ran (1 envelope read present, 0 flat reads — an editor's exit code proves nothing), and the three catalog suites were re-run:

❯ test/catalog-apply-cadence.test.ts (3 tests | 2 failed)
❯ test/catalog-engine-facade.test.ts (8 tests | 7 failed)
❯ test/catalog-instantiate.test.ts (31 tests | 14 failed)
vitest exit: 1

23 failures, in the predicted direction and across all three suites — before this PR only the tripwire could see the defect. The one new test that stays green under the mutation is the capability control, which does not depend on the query shape. The mutation script carried a trap … EXIT INT TERM restore, and the tree was confirmed clean against HEAD afterwards. No rebuild leg was needed: these suites import ../src/… directly, so nothing resolves through dist/.

No changeset: this repo has no changeset mechanism (no .changeset/ in the tree or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates in .github/workflows/ci.yml are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. Two things I checked beyond the report.

1. Gates on the PR head, re-run by me on 0c510fd:validate 0, typecheck 0, test 0 (Test Files 22 passed, Tests 559 passed), build 0.

2. Gates on the head merged with current main, which is the state that actually lands. This branch was cut from dbe1537 and is two commits behind — it does not contain #83 (the duly_duty timezone write guard) or #85 (grouped-view projection). #83 matters here specifically: it puts a beforeInsert/beforeUpdate hook on duly_duty, and applyCatalogHandler writes duties. A fix that makes the catalog action start creating duties for the first time, landing next to a new guard that can refuse a duty write, is exactly the combination worth checking rather than assuming.

Merged origin/main into the branch locally and re-ran everything: Test Files 23 passed, Tests 589 passed, all four gates 0, no conflicts. The two changes are independent in practice. I have pushed that update to the branch so CI runs on the combination rather than on the older base.

On the work itself

• Five call sites, not four. My card said four; the fifth is resolveBusinessUnit's sys_user_position read, which my own blast-radius section named and my count missed. That one was the nastiest of the set — "no position row" is a legitimate day-one state the handler tolerates, so its failure produced unanchored duties with no error anywhere.
• The test dispatches through HttpDispatcher.handleActions, so the runtime builds ctx.engine. No double is written in that file. This is the whole point of the card: the previous suite was green because a hand-written FakeEngine encoded the author's belief about the contract, so the fake and the handler were wrong in the same direction by construction. A test that builds its own facade could not have caught this and cannot catch the next one.
• No tolerant query.where ?? query rung anywhere. Correct, and worth stating why: accepting both shapes would have made the app work while leaving objectstack#14175 invisible, and the next application to read that type would make the same choice with nothing to warn it.
• The ablation is the real evidence. Restoring the pre-fix handler over the fixed tree turns three suites red — 23 failures across catalog-apply-cadence (2), catalog-engine-facade (7) and catalog-instantiate (14) — where before the fix the tripwire was the only thing that could see the defect at all. That number is the answer to "did the tests actually gain coverage", and it is a much better answer than a passing run.
• The tripwire was deleted rather than adjusted, as the card asked.

---

Generated by Claude Code

[os-warren]

Fixes#79

ctx.engine.find(object, query) takes a bare filter. The runtime's buildActionEngineFacade (@objectstack/runtime 17.2.0) adds the ObjectQL envelope itself:

asyncfind(object,query){constwhere=query&&Object.keys(query).length ? {where: query} : {};constrows=awaitql.find(object,{ ...where, context });

Every filtered read in src/actions/catalog.handlers.ts passed an envelope, so through the real dispatcher the query arrived as { where: { where: { … } } }. No row has a field called where, so each read came back empty with no error: duly_catalog_apply reported a successful run of zero, duly_catalog_sync scanned nothing and called every duty unchanged, and resolveBusinessUnit created unanchored duties. Only the one unfiltered read survived, because Object.keys({}).length === 0 skips the wrapping entirely — which is what made the handler look partially alive.

What changed

• All five engine.find calls pass the filter flat — the apply catalog read and its duly_duty idempotency probe, the sync catalog read (both the narrowed and the unnarrowed branch) and its { source: 'catalog' } duty read, and resolveBusinessUnit's sys_user_position read.
• FakeEngine.find in test/catalog-instantiate.test.ts reads the flat filter. It used to read query.where, honouring the handler's convention rather than the runtime's, which is exactly how 78 duty assertions stayed green against a shape production never produced. Left as-is, the fix would have been invisible to the suite.
• The #79 tripwire in test/catalog-apply-cadence.test.ts is deleted, not adjusted — it was written to go red when this landed. Its two facades collapse into one: handlerFacade now reproduces buildActionEngineFacade line for line, so there is a single convention in the file.
• New test/catalog-engine-facade.test.ts dispatches through the real action route (HttpDispatcher.handleActions — the function createActionsDomain's route delegates to) and lets the runtime build ctx.engine itself. No facade is written in that file; that is the point. It covers apply, the business-unit anchor, idempotency across two dispatched runs, the object-bound twin's own route, sync's scan/replay, the narrowed sweep, and the retired report, plus one control asserting the route really is the capability-gated platform route.

A tolerant query.where ?? query rung was deliberately not added anywhere — a consumer that accepts both shapes is what let the wrong one ship green. The contract half (ActionEngineFacade.find types query as a plain record and says nothing about which shape it is) is filed upstream as objectstack-ai/objectstack#14175 and referenced from a code comment; this PR does not wait on it.

Acceptance

From the issue	Where it is pinned
apply, dispatched with the facade the runtime builds, creates the duties for a matching position_code	catalog-engine-facade.test.ts — "creates the duties for a matching position_code"
duly_catalog_sync scans the catalog-sourced duties it is supposed to scan	same file — "scans the catalog-sourced duties and replays a cadence edit" (scanned: 2, updated: 2)
the tripwire is deleted, not adjusted	catalog-apply-cadence.test.ts — last describe and runtimeFacade removed

Verification

All four gates on 0c510fd, each read from its own verdict output (exit codes captured before any pipe):

GATE validate EXIT=0 # one expected warning: hierarchy-security provider absent (AGENTS.md)
GATE typecheck EXIT=0
GATE test EXIT=0 # Test Files 22 passed (22) · Tests 559 passed (559)
GATE build EXIT=0 # Build complete (597ms) · dist/objectstack.json

Reverse verification. The pre-fix src/actions/catalog.handlers.ts was restored from origin/main over the fixed tree, the mutation was confirmed on disk by grep before anything ran (1 envelope read present, 0 flat reads — an editor's exit code proves nothing), and the three catalog suites were re-run:

❯ test/catalog-apply-cadence.test.ts (3 tests | 2 failed)
❯ test/catalog-engine-facade.test.ts (8 tests | 7 failed)
❯ test/catalog-instantiate.test.ts (31 tests | 14 failed)
vitest exit: 1

23 failures, in the predicted direction and across all three suites — before this PR only the tripwire could see the defect. The one new test that stays green under the mutation is the capability control, which does not depend on the query shape. The mutation script carried a trap … EXIT INT TERM restore, and the tree was confirmed clean against HEAD afterwards. No rebuild leg was needed: these suites import ../src/… directly, so nothing resolves through dist/.

No changeset: this repo has no changeset mechanism (no .changeset/ in the tree or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates in .github/workflows/ci.yml are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. Two things I checked beyond the report.

1. Gates on the PR head, re-run by me on 0c510fd:validate 0, typecheck 0, test 0 (Test Files 22 passed, Tests 559 passed), build 0.

2. Gates on the head merged with current main, which is the state that actually lands. This branch was cut from dbe1537 and is two commits behind — it does not contain #83 (the duly_duty timezone write guard) or #85 (grouped-view projection). #83 matters here specifically: it puts a beforeInsert/beforeUpdate hook on duly_duty, and applyCatalogHandler writes duties. A fix that makes the catalog action start creating duties for the first time, landing next to a new guard that can refuse a duty write, is exactly the combination worth checking rather than assuming.

Merged origin/main into the branch locally and re-ran everything: Test Files 23 passed, Tests 589 passed, all four gates 0, no conflicts. The two changes are independent in practice. I have pushed that update to the branch so CI runs on the combination rather than on the older base.

On the work itself

• Five call sites, not four. My card said four; the fifth is resolveBusinessUnit's sys_user_position read, which my own blast-radius section named and my count missed. That one was the nastiest of the set — "no position row" is a legitimate day-one state the handler tolerates, so its failure produced unanchored duties with no error anywhere.
• The test dispatches through HttpDispatcher.handleActions, so the runtime builds ctx.engine. No double is written in that file. This is the whole point of the card: the previous suite was green because a hand-written FakeEngine encoded the author's belief about the contract, so the fake and the handler were wrong in the same direction by construction. A test that builds its own facade could not have caught this and cannot catch the next one.
• No tolerant query.where ?? query rung anywhere. Correct, and worth stating why: accepting both shapes would have made the app work while leaving objectstack#14175 invisible, and the next application to read that type would make the same choice with nothing to warn it.
• The ablation is the real evidence. Restoring the pre-fix handler over the fixed tree turns three suites red — 23 failures across catalog-apply-cadence (2), catalog-engine-facade (7) and catalog-instantiate (14) — where before the fix the tripwire was the only thing that could see the defect at all. That number is the answer to "did the tests actually gain coverage", and it is a much better answer than a passing run.
• The tripwire was deleted rather than adjusted, as the card asked.

---

Generated by Claude Code

[os-warren]

Fixes#79

ctx.engine.find(object, query) takes a bare filter. The runtime's buildActionEngineFacade (@objectstack/runtime 17.2.0) adds the ObjectQL envelope itself:

asyncfind(object,query){constwhere=query&&Object.keys(query).length ? {where: query} : {};constrows=awaitql.find(object,{ ...where, context });

Every filtered read in src/actions/catalog.handlers.ts passed an envelope, so through the real dispatcher the query arrived as { where: { where: { … } } }. No row has a field called where, so each read came back empty with no error: duly_catalog_apply reported a successful run of zero, duly_catalog_sync scanned nothing and called every duty unchanged, and resolveBusinessUnit created unanchored duties. Only the one unfiltered read survived, because Object.keys({}).length === 0 skips the wrapping entirely — which is what made the handler look partially alive.

What changed

• All five engine.find calls pass the filter flat — the apply catalog read and its duly_duty idempotency probe, the sync catalog read (both the narrowed and the unnarrowed branch) and its { source: 'catalog' } duty read, and resolveBusinessUnit's sys_user_position read.
• FakeEngine.find in test/catalog-instantiate.test.ts reads the flat filter. It used to read query.where, honouring the handler's convention rather than the runtime's, which is exactly how 78 duty assertions stayed green against a shape production never produced. Left as-is, the fix would have been invisible to the suite.
• The #79 tripwire in test/catalog-apply-cadence.test.ts is deleted, not adjusted — it was written to go red when this landed. Its two facades collapse into one: handlerFacade now reproduces buildActionEngineFacade line for line, so there is a single convention in the file.
• New test/catalog-engine-facade.test.ts dispatches through the real action route (HttpDispatcher.handleActions — the function createActionsDomain's route delegates to) and lets the runtime build ctx.engine itself. No facade is written in that file; that is the point. It covers apply, the business-unit anchor, idempotency across two dispatched runs, the object-bound twin's own route, sync's scan/replay, the narrowed sweep, and the retired report, plus one control asserting the route really is the capability-gated platform route.

A tolerant query.where ?? query rung was deliberately not added anywhere — a consumer that accepts both shapes is what let the wrong one ship green. The contract half (ActionEngineFacade.find types query as a plain record and says nothing about which shape it is) is filed upstream as objectstack-ai/objectstack#14175 and referenced from a code comment; this PR does not wait on it.

Acceptance

From the issue	Where it is pinned
apply, dispatched with the facade the runtime builds, creates the duties for a matching position_code	catalog-engine-facade.test.ts — "creates the duties for a matching position_code"
duly_catalog_sync scans the catalog-sourced duties it is supposed to scan	same file — "scans the catalog-sourced duties and replays a cadence edit" (scanned: 2, updated: 2)
the tripwire is deleted, not adjusted	catalog-apply-cadence.test.ts — last describe and runtimeFacade removed

Verification

All four gates on 0c510fd, each read from its own verdict output (exit codes captured before any pipe):

GATE validate EXIT=0 # one expected warning: hierarchy-security provider absent (AGENTS.md)
GATE typecheck EXIT=0
GATE test EXIT=0 # Test Files 22 passed (22) · Tests 559 passed (559)
GATE build EXIT=0 # Build complete (597ms) · dist/objectstack.json

Reverse verification. The pre-fix src/actions/catalog.handlers.ts was restored from origin/main over the fixed tree, the mutation was confirmed on disk by grep before anything ran (1 envelope read present, 0 flat reads — an editor's exit code proves nothing), and the three catalog suites were re-run:

❯ test/catalog-apply-cadence.test.ts (3 tests | 2 failed)
❯ test/catalog-engine-facade.test.ts (8 tests | 7 failed)
❯ test/catalog-instantiate.test.ts (31 tests | 14 failed)
vitest exit: 1

23 failures, in the predicted direction and across all three suites — before this PR only the tripwire could see the defect. The one new test that stays green under the mutation is the capability control, which does not depend on the query shape. The mutation script carried a trap … EXIT INT TERM restore, and the tree was confirmed clean against HEAD afterwards. No rebuild leg was needed: these suites import ../src/… directly, so nothing resolves through dist/.

No changeset: this repo has no changeset mechanism (no .changeset/ in the tree or anywhere in git log --all, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates in .github/workflows/ci.yml are the whole contract.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. Two things I checked beyond the report.

1. Gates on the PR head, re-run by me on 0c510fd:validate 0, typecheck 0, test 0 (Test Files 22 passed, Tests 559 passed), build 0.

2. Gates on the head merged with current main, which is the state that actually lands. This branch was cut from dbe1537 and is two commits behind — it does not contain #83 (the duly_duty timezone write guard) or #85 (grouped-view projection). #83 matters here specifically: it puts a beforeInsert/beforeUpdate hook on duly_duty, and applyCatalogHandler writes duties. A fix that makes the catalog action start creating duties for the first time, landing next to a new guard that can refuse a duty write, is exactly the combination worth checking rather than assuming.

Merged origin/main into the branch locally and re-ran everything: Test Files 23 passed, Tests 589 passed, all four gates 0, no conflicts. The two changes are independent in practice. I have pushed that update to the branch so CI runs on the combination rather than on the older base.

On the work itself

• Five call sites, not four. My card said four; the fifth is resolveBusinessUnit's sys_user_position read, which my own blast-radius section named and my count missed. That one was the nastiest of the set — "no position row" is a legitimate day-one state the handler tolerates, so its failure produced unanchored duties with no error anywhere.
• The test dispatches through HttpDispatcher.handleActions, so the runtime builds ctx.engine. No double is written in that file. This is the whole point of the card: the previous suite was green because a hand-written FakeEngine encoded the author's belief about the contract, so the fake and the handler were wrong in the same direction by construction. A test that builds its own facade could not have caught this and cannot catch the next one.
• No tolerant query.where ?? query rung anywhere. Correct, and worth stating why: accepting both shapes would have made the app work while leaving objectstack#14175 invisible, and the next application to read that type would make the same choice with nothing to warn it.
• The ablation is the real evidence. Restoring the pre-fix handler over the fixed tree turns three suites red — 23 failures across catalog-apply-cadence (2), catalog-engine-facade (7) and catalog-instantiate (14) — where before the fix the tripwire was the only thing that could see the defect at all. That number is the answer to "did the tests actually gain coverage", and it is a much better answer than a passing run.
• The tripwire was deleted rather than adjusted, as the card asked.

---

Generated by Claude Code