Declare hierarchy-security and restore the manager depth grants

[os-warren]

Fixes#46

Four places in this repo said declaring requires: ['hierarchy-security'] would fail an open-edition boot. It does not. That belief is what forced the three manager depth grants down to own, so removing it and restoring the grants are one change.

Verified on 5dd788b (final commit) with @objectstack/security-enterprisenot installed and nothing added to package.json.

What changed

objectstack.config.ts — requires: ['automation', 'hierarchy-security'], and the comment beside it rewritten. It now quotes the platform's own reason for the check, records the measurement, and says plainly that the warning is the expected state. The "Security posture" comment further down said the scopes "fail closed to owner-only, silently"; that was the same claim in its second half, and it is now the warning-announced behaviour it actually is.

src/security/permission-sets.ts — duly_manager reads unit_and_below on duly_task and duly_duty. duly_admin gets the task depth by inheritance, not restatement, so the third grant costs no third edit. Both overrides spread the member entry, leaving writeScope: 'own' inherited rather than retyped. HIERARCHY_SCOPES_DEFERRED and its docblock are gone.

Write scopes did not move. A manager reads down and writes nothing but their own — that was never the deferred half.

AGENTS.md rule 7 — rewritten end to end: a hierarchy scope requires the declaration; omitting it is an author-time hard error that takes validate, build and every test importing the config; declaring it warns and installs nothing; open-edition resolution is owner-only and a local manager view showing only your own rows is the edition, not a bug. It also names the trapdoor next door — org is not a hierarchy scope, loads with no declaration, and discloses the whole tenant.

docs/product/data-model.md and docs/deployment/security.md — same claim, same correction. The deployment page's "Two manager grants are currently narrower than this table implies" section is replaced by one describing the declaration and the warning; the model table now shows the manager depth instead of "inherited".

Tests

test/security.test.ts. The old stopgap block pinned the compromise in both directions; the new one pins the dependency in both directions:

• each of the three grants is unit_and_below;
• those three are the only hierarchy scopes authored anywhere (which is also what keeps the next assertion from going vacuous);
• if any hierarchy scope is authored, stack.requires must contain hierarchy-security — a named failure here instead of an opaque config-load failure across every suite;
• no set reads duly_task at org;
• the manager depth overrides keep every member key they do not change (the failure mode this change could most easily have caused: retyping the entry and dropping writeScope: 'own').

One deviation, stated

The card asks for a test that no grant anywhere has a write scope wider than own. Taken literally that is false today: duly_admin.duly_catalog_item is writeScope: 'org', deliberately — public_read is read-open but write-owned, so without it an administrator could only edit catalog items they personally created. So it is written as two assertions instead of one:

• every write scope is ownbar one allowlisted exception, asserted by equality against that allowlist, so adding a second exception is a deliberate act rather than a silent pass;
• no write scope anywhere is a hierarchy scope, unconditional and exception-included. This is the acceptance line's real content — depth never reaches the write axis — and it is the invariant this PR could have broken.

The second one earns its place: with the capability declared, the platform check accepts a hierarchy scope on either axis. It does not distinguish read from write. Nothing but this test stops a write depth from loading now.

Ablations

Four legs, each mutation confirmed on disk before measuring, each restored by an EXIT/INT/TERM trap. Tests resolve app code by relative path through vitest's transform — no package exports → dist boundary and no vitest alias (there is no vitest config file) — so no rebuild leg applies here.

leg	mutation	predicted	observed
1	drop hierarchy-security from requires	validate red	exit 1, defineStack hierarchy-scope capability validation failed (3 issues), naming all three grants — duly_admin.duly_task among them, which also proves the inherited grant is real
2	duly_manager.duly_task.writeScope: 'org'	write-scope tests red, validategreen	6 failed / 54 passed; expected { …(3) } to deeply equal { Object (duly_admin.duly_catalog_item) }. Config loaded — org needs no declaration, which is the point
3	duly_manager.duly_task.writeScope: 'unit_and_below'	leg 2's failures plus the hierarchy-write assertion	8 failed / 52 passed; duly_manager.duly_task writes by hierarchy depth: expected [ 'own_and_reports', 'unit', …(1) ] to not include 'unit_and_below'. Config still loaded
4	duly_manager.duly_task.readScope back to 'own'	depth assertions red, write assertions green	6 failed / 54 passed; write-scope block stayed green, as predicted

One honesty note on the on-disk confirmation: the injected-marker count (MUTANT, want 1) was correct on every leg and is what proves each mutation landed. The paired removed-anchor count was mis-anchored — its pattern also matched the untouched duly_duty override — so it read 2/1/1 instead of 0. The marker count and the assertion output naming the mutated value are the evidence; that counter is not.

Gates

All four green on 5dd788b, run under the container's shared verify lock:

✓ Validation passed (397ms)
⚠ Capability "hierarchy-security" is provided by @objectstack/security-enterprise …
Test Files 12 passed (12)
Tests 374 passed (374)
✓ Build complete (635ms)

The warning is the acceptance criterion, not a leftover.

File-surface note

One file beyond the declared surface: src/security/index.ts, which re-exported HIERARCHY_SCOPES_DEFERRED. Deleting the constant without it is a compile error, so it is the mechanical completion of the card's own step 2 rather than new scope — a four-line export list losing one line. No sibling card in this round touches it (#51 datasets, #50duty.object.ts, #27 global actions). src/objects/duty.object.ts was not touched.

Found outside the file surface — reported, not edited

docs/roadmap.md (M2 bullet) says an open-edition checkout "correctly shows owner-only rows". That half is true and stays true. It does not repeat the falsified claim, so it is left alone.

---

Generated by Claude Code

[os-warren]

Fixes#46

Four places in this repo said declaring requires: ['hierarchy-security'] would fail an open-edition boot. It does not. That belief is what forced the three manager depth grants down to own, so removing it and restoring the grants are one change.

Verified on 5dd788b (final commit) with @objectstack/security-enterprisenot installed and nothing added to package.json.

What changed

objectstack.config.ts — requires: ['automation', 'hierarchy-security'], and the comment beside it rewritten. It now quotes the platform's own reason for the check, records the measurement, and says plainly that the warning is the expected state. The "Security posture" comment further down said the scopes "fail closed to owner-only, silently"; that was the same claim in its second half, and it is now the warning-announced behaviour it actually is.

src/security/permission-sets.ts — duly_manager reads unit_and_below on duly_task and duly_duty. duly_admin gets the task depth by inheritance, not restatement, so the third grant costs no third edit. Both overrides spread the member entry, leaving writeScope: 'own' inherited rather than retyped. HIERARCHY_SCOPES_DEFERRED and its docblock are gone.

Write scopes did not move. A manager reads down and writes nothing but their own — that was never the deferred half.

AGENTS.md rule 7 — rewritten end to end: a hierarchy scope requires the declaration; omitting it is an author-time hard error that takes validate, build and every test importing the config; declaring it warns and installs nothing; open-edition resolution is owner-only and a local manager view showing only your own rows is the edition, not a bug. It also names the trapdoor next door — org is not a hierarchy scope, loads with no declaration, and discloses the whole tenant.

docs/product/data-model.md and docs/deployment/security.md — same claim, same correction. The deployment page's "Two manager grants are currently narrower than this table implies" section is replaced by one describing the declaration and the warning; the model table now shows the manager depth instead of "inherited".

Tests

test/security.test.ts. The old stopgap block pinned the compromise in both directions; the new one pins the dependency in both directions:

• each of the three grants is unit_and_below;
• those three are the only hierarchy scopes authored anywhere (which is also what keeps the next assertion from going vacuous);
• if any hierarchy scope is authored, stack.requires must contain hierarchy-security — a named failure here instead of an opaque config-load failure across every suite;
• no set reads duly_task at org;
• the manager depth overrides keep every member key they do not change (the failure mode this change could most easily have caused: retyping the entry and dropping writeScope: 'own').

One deviation, stated

The card asks for a test that no grant anywhere has a write scope wider than own. Taken literally that is false today: duly_admin.duly_catalog_item is writeScope: 'org', deliberately — public_read is read-open but write-owned, so without it an administrator could only edit catalog items they personally created. So it is written as two assertions instead of one:

• every write scope is ownbar one allowlisted exception, asserted by equality against that allowlist, so adding a second exception is a deliberate act rather than a silent pass;
• no write scope anywhere is a hierarchy scope, unconditional and exception-included. This is the acceptance line's real content — depth never reaches the write axis — and it is the invariant this PR could have broken.

The second one earns its place: with the capability declared, the platform check accepts a hierarchy scope on either axis. It does not distinguish read from write. Nothing but this test stops a write depth from loading now.

Ablations

Four legs, each mutation confirmed on disk before measuring, each restored by an EXIT/INT/TERM trap. Tests resolve app code by relative path through vitest's transform — no package exports → dist boundary and no vitest alias (there is no vitest config file) — so no rebuild leg applies here.

leg	mutation	predicted	observed
1	drop hierarchy-security from requires	validate red	exit 1, defineStack hierarchy-scope capability validation failed (3 issues), naming all three grants — duly_admin.duly_task among them, which also proves the inherited grant is real
2	duly_manager.duly_task.writeScope: 'org'	write-scope tests red, validategreen	6 failed / 54 passed; expected { …(3) } to deeply equal { Object (duly_admin.duly_catalog_item) }. Config loaded — org needs no declaration, which is the point
3	duly_manager.duly_task.writeScope: 'unit_and_below'	leg 2's failures plus the hierarchy-write assertion	8 failed / 52 passed; duly_manager.duly_task writes by hierarchy depth: expected [ 'own_and_reports', 'unit', …(1) ] to not include 'unit_and_below'. Config still loaded
4	duly_manager.duly_task.readScope back to 'own'	depth assertions red, write assertions green	6 failed / 54 passed; write-scope block stayed green, as predicted

One honesty note on the on-disk confirmation: the injected-marker count (MUTANT, want 1) was correct on every leg and is what proves each mutation landed. The paired removed-anchor count was mis-anchored — its pattern also matched the untouched duly_duty override — so it read 2/1/1 instead of 0. The marker count and the assertion output naming the mutated value are the evidence; that counter is not.

Gates

All four green on 5dd788b, run under the container's shared verify lock:

✓ Validation passed (397ms)
⚠ Capability "hierarchy-security" is provided by @objectstack/security-enterprise …
Test Files 12 passed (12)
Tests 374 passed (374)
✓ Build complete (635ms)

The warning is the acceptance criterion, not a leftover.

File-surface note

One file beyond the declared surface: src/security/index.ts, which re-exported HIERARCHY_SCOPES_DEFERRED. Deleting the constant without it is a compile error, so it is the mechanical completion of the card's own step 2 rather than new scope — a four-line export list losing one line. No sibling card in this round touches it (#51 datasets, #50duty.object.ts, #27 global actions). src/objects/duty.object.ts was not touched.

Found outside the file surface — reported, not edited

docs/roadmap.md (M2 bullet) says an open-edition checkout "correctly shows owner-only rows". That half is true and stays true. It does not repeat the falsified claim, so it is left alone.

---

Generated by Claude Code

[os-warren]

Fixes#46

Four places in this repo said declaring requires: ['hierarchy-security'] would fail an open-edition boot. It does not. That belief is what forced the three manager depth grants down to own, so removing it and restoring the grants are one change.

Verified on 5dd788b (final commit) with @objectstack/security-enterprisenot installed and nothing added to package.json.

What changed

objectstack.config.ts — requires: ['automation', 'hierarchy-security'], and the comment beside it rewritten. It now quotes the platform's own reason for the check, records the measurement, and says plainly that the warning is the expected state. The "Security posture" comment further down said the scopes "fail closed to owner-only, silently"; that was the same claim in its second half, and it is now the warning-announced behaviour it actually is.

src/security/permission-sets.ts — duly_manager reads unit_and_below on duly_task and duly_duty. duly_admin gets the task depth by inheritance, not restatement, so the third grant costs no third edit. Both overrides spread the member entry, leaving writeScope: 'own' inherited rather than retyped. HIERARCHY_SCOPES_DEFERRED and its docblock are gone.

Write scopes did not move. A manager reads down and writes nothing but their own — that was never the deferred half.

AGENTS.md rule 7 — rewritten end to end: a hierarchy scope requires the declaration; omitting it is an author-time hard error that takes validate, build and every test importing the config; declaring it warns and installs nothing; open-edition resolution is owner-only and a local manager view showing only your own rows is the edition, not a bug. It also names the trapdoor next door — org is not a hierarchy scope, loads with no declaration, and discloses the whole tenant.

docs/product/data-model.md and docs/deployment/security.md — same claim, same correction. The deployment page's "Two manager grants are currently narrower than this table implies" section is replaced by one describing the declaration and the warning; the model table now shows the manager depth instead of "inherited".

Tests

test/security.test.ts. The old stopgap block pinned the compromise in both directions; the new one pins the dependency in both directions:

• each of the three grants is unit_and_below;
• those three are the only hierarchy scopes authored anywhere (which is also what keeps the next assertion from going vacuous);
• if any hierarchy scope is authored, stack.requires must contain hierarchy-security — a named failure here instead of an opaque config-load failure across every suite;
• no set reads duly_task at org;
• the manager depth overrides keep every member key they do not change (the failure mode this change could most easily have caused: retyping the entry and dropping writeScope: 'own').

One deviation, stated

The card asks for a test that no grant anywhere has a write scope wider than own. Taken literally that is false today: duly_admin.duly_catalog_item is writeScope: 'org', deliberately — public_read is read-open but write-owned, so without it an administrator could only edit catalog items they personally created. So it is written as two assertions instead of one:

• every write scope is ownbar one allowlisted exception, asserted by equality against that allowlist, so adding a second exception is a deliberate act rather than a silent pass;
• no write scope anywhere is a hierarchy scope, unconditional and exception-included. This is the acceptance line's real content — depth never reaches the write axis — and it is the invariant this PR could have broken.

The second one earns its place: with the capability declared, the platform check accepts a hierarchy scope on either axis. It does not distinguish read from write. Nothing but this test stops a write depth from loading now.

Ablations

Four legs, each mutation confirmed on disk before measuring, each restored by an EXIT/INT/TERM trap. Tests resolve app code by relative path through vitest's transform — no package exports → dist boundary and no vitest alias (there is no vitest config file) — so no rebuild leg applies here.

leg	mutation	predicted	observed
1	drop hierarchy-security from requires	validate red	exit 1, defineStack hierarchy-scope capability validation failed (3 issues), naming all three grants — duly_admin.duly_task among them, which also proves the inherited grant is real
2	duly_manager.duly_task.writeScope: 'org'	write-scope tests red, validategreen	6 failed / 54 passed; expected { …(3) } to deeply equal { Object (duly_admin.duly_catalog_item) }. Config loaded — org needs no declaration, which is the point
3	duly_manager.duly_task.writeScope: 'unit_and_below'	leg 2's failures plus the hierarchy-write assertion	8 failed / 52 passed; duly_manager.duly_task writes by hierarchy depth: expected [ 'own_and_reports', 'unit', …(1) ] to not include 'unit_and_below'. Config still loaded
4	duly_manager.duly_task.readScope back to 'own'	depth assertions red, write assertions green	6 failed / 54 passed; write-scope block stayed green, as predicted

One honesty note on the on-disk confirmation: the injected-marker count (MUTANT, want 1) was correct on every leg and is what proves each mutation landed. The paired removed-anchor count was mis-anchored — its pattern also matched the untouched duly_duty override — so it read 2/1/1 instead of 0. The marker count and the assertion output naming the mutated value are the evidence; that counter is not.

Gates

All four green on 5dd788b, run under the container's shared verify lock:

✓ Validation passed (397ms)
⚠ Capability "hierarchy-security" is provided by @objectstack/security-enterprise …
Test Files 12 passed (12)
Tests 374 passed (374)
✓ Build complete (635ms)

The warning is the acceptance criterion, not a leftover.

File-surface note

One file beyond the declared surface: src/security/index.ts, which re-exported HIERARCHY_SCOPES_DEFERRED. Deleting the constant without it is a compile error, so it is the mechanical completion of the card's own step 2 rather than new scope — a four-line export list losing one line. No sibling card in this round touches it (#51 datasets, #50duty.object.ts, #27 global actions). src/objects/duty.object.ts was not touched.

Found outside the file surface — reported, not edited

docs/roadmap.md (M2 bullet) says an open-edition checkout "correctly shows owner-only rows". That half is true and stays true. It does not repeat the falsified claim, so it is left alone.

---

Generated by Claude Code

[os-warren]

Fixes#46

Four places in this repo said declaring requires: ['hierarchy-security'] would fail an open-edition boot. It does not. That belief is what forced the three manager depth grants down to own, so removing it and restoring the grants are one change.

Verified on 5dd788b (final commit) with @objectstack/security-enterprisenot installed and nothing added to package.json.

What changed

objectstack.config.ts — requires: ['automation', 'hierarchy-security'], and the comment beside it rewritten. It now quotes the platform's own reason for the check, records the measurement, and says plainly that the warning is the expected state. The "Security posture" comment further down said the scopes "fail closed to owner-only, silently"; that was the same claim in its second half, and it is now the warning-announced behaviour it actually is.

src/security/permission-sets.ts — duly_manager reads unit_and_below on duly_task and duly_duty. duly_admin gets the task depth by inheritance, not restatement, so the third grant costs no third edit. Both overrides spread the member entry, leaving writeScope: 'own' inherited rather than retyped. HIERARCHY_SCOPES_DEFERRED and its docblock are gone.

Write scopes did not move. A manager reads down and writes nothing but their own — that was never the deferred half.

AGENTS.md rule 7 — rewritten end to end: a hierarchy scope requires the declaration; omitting it is an author-time hard error that takes validate, build and every test importing the config; declaring it warns and installs nothing; open-edition resolution is owner-only and a local manager view showing only your own rows is the edition, not a bug. It also names the trapdoor next door — org is not a hierarchy scope, loads with no declaration, and discloses the whole tenant.

docs/product/data-model.md and docs/deployment/security.md — same claim, same correction. The deployment page's "Two manager grants are currently narrower than this table implies" section is replaced by one describing the declaration and the warning; the model table now shows the manager depth instead of "inherited".

Tests

test/security.test.ts. The old stopgap block pinned the compromise in both directions; the new one pins the dependency in both directions:

• each of the three grants is unit_and_below;
• those three are the only hierarchy scopes authored anywhere (which is also what keeps the next assertion from going vacuous);
• if any hierarchy scope is authored, stack.requires must contain hierarchy-security — a named failure here instead of an opaque config-load failure across every suite;
• no set reads duly_task at org;
• the manager depth overrides keep every member key they do not change (the failure mode this change could most easily have caused: retyping the entry and dropping writeScope: 'own').

One deviation, stated

The card asks for a test that no grant anywhere has a write scope wider than own. Taken literally that is false today: duly_admin.duly_catalog_item is writeScope: 'org', deliberately — public_read is read-open but write-owned, so without it an administrator could only edit catalog items they personally created. So it is written as two assertions instead of one:

• every write scope is ownbar one allowlisted exception, asserted by equality against that allowlist, so adding a second exception is a deliberate act rather than a silent pass;
• no write scope anywhere is a hierarchy scope, unconditional and exception-included. This is the acceptance line's real content — depth never reaches the write axis — and it is the invariant this PR could have broken.

The second one earns its place: with the capability declared, the platform check accepts a hierarchy scope on either axis. It does not distinguish read from write. Nothing but this test stops a write depth from loading now.

Ablations

Four legs, each mutation confirmed on disk before measuring, each restored by an EXIT/INT/TERM trap. Tests resolve app code by relative path through vitest's transform — no package exports → dist boundary and no vitest alias (there is no vitest config file) — so no rebuild leg applies here.

leg	mutation	predicted	observed
1	drop hierarchy-security from requires	validate red	exit 1, defineStack hierarchy-scope capability validation failed (3 issues), naming all three grants — duly_admin.duly_task among them, which also proves the inherited grant is real
2	duly_manager.duly_task.writeScope: 'org'	write-scope tests red, validategreen	6 failed / 54 passed; expected { …(3) } to deeply equal { Object (duly_admin.duly_catalog_item) }. Config loaded — org needs no declaration, which is the point
3	duly_manager.duly_task.writeScope: 'unit_and_below'	leg 2's failures plus the hierarchy-write assertion	8 failed / 52 passed; duly_manager.duly_task writes by hierarchy depth: expected [ 'own_and_reports', 'unit', …(1) ] to not include 'unit_and_below'. Config still loaded
4	duly_manager.duly_task.readScope back to 'own'	depth assertions red, write assertions green	6 failed / 54 passed; write-scope block stayed green, as predicted

One honesty note on the on-disk confirmation: the injected-marker count (MUTANT, want 1) was correct on every leg and is what proves each mutation landed. The paired removed-anchor count was mis-anchored — its pattern also matched the untouched duly_duty override — so it read 2/1/1 instead of 0. The marker count and the assertion output naming the mutated value are the evidence; that counter is not.

Gates

All four green on 5dd788b, run under the container's shared verify lock:

✓ Validation passed (397ms)
⚠ Capability "hierarchy-security" is provided by @objectstack/security-enterprise …
Test Files 12 passed (12)
Tests 374 passed (374)
✓ Build complete (635ms)

The warning is the acceptance criterion, not a leftover.

File-surface note

One file beyond the declared surface: src/security/index.ts, which re-exported HIERARCHY_SCOPES_DEFERRED. Deleting the constant without it is a compile error, so it is the mechanical completion of the card's own step 2 rather than new scope — a four-line export list losing one line. No sibling card in this round touches it (#51 datasets, #50duty.object.ts, #27 global actions). src/objects/duty.object.ts was not touched.

Found outside the file surface — reported, not edited

docs/roadmap.md (M2 bullet) says an open-edition checkout "correctly shows owner-only rows". That half is true and stays true. It does not repeat the falsified claim, so it is left alone.

---

Generated by Claude Code

[os-warren]

Fixes#46

Four places in this repo said declaring requires: ['hierarchy-security'] would fail an open-edition boot. It does not. That belief is what forced the three manager depth grants down to own, so removing it and restoring the grants are one change.

Verified on 5dd788b (final commit) with @objectstack/security-enterprisenot installed and nothing added to package.json.

What changed

objectstack.config.ts — requires: ['automation', 'hierarchy-security'], and the comment beside it rewritten. It now quotes the platform's own reason for the check, records the measurement, and says plainly that the warning is the expected state. The "Security posture" comment further down said the scopes "fail closed to owner-only, silently"; that was the same claim in its second half, and it is now the warning-announced behaviour it actually is.

src/security/permission-sets.ts — duly_manager reads unit_and_below on duly_task and duly_duty. duly_admin gets the task depth by inheritance, not restatement, so the third grant costs no third edit. Both overrides spread the member entry, leaving writeScope: 'own' inherited rather than retyped. HIERARCHY_SCOPES_DEFERRED and its docblock are gone.

Write scopes did not move. A manager reads down and writes nothing but their own — that was never the deferred half.

AGENTS.md rule 7 — rewritten end to end: a hierarchy scope requires the declaration; omitting it is an author-time hard error that takes validate, build and every test importing the config; declaring it warns and installs nothing; open-edition resolution is owner-only and a local manager view showing only your own rows is the edition, not a bug. It also names the trapdoor next door — org is not a hierarchy scope, loads with no declaration, and discloses the whole tenant.

docs/product/data-model.md and docs/deployment/security.md — same claim, same correction. The deployment page's "Two manager grants are currently narrower than this table implies" section is replaced by one describing the declaration and the warning; the model table now shows the manager depth instead of "inherited".

Tests

test/security.test.ts. The old stopgap block pinned the compromise in both directions; the new one pins the dependency in both directions:

• each of the three grants is unit_and_below;
• those three are the only hierarchy scopes authored anywhere (which is also what keeps the next assertion from going vacuous);
• if any hierarchy scope is authored, stack.requires must contain hierarchy-security — a named failure here instead of an opaque config-load failure across every suite;
• no set reads duly_task at org;
• the manager depth overrides keep every member key they do not change (the failure mode this change could most easily have caused: retyping the entry and dropping writeScope: 'own').

One deviation, stated

The card asks for a test that no grant anywhere has a write scope wider than own. Taken literally that is false today: duly_admin.duly_catalog_item is writeScope: 'org', deliberately — public_read is read-open but write-owned, so without it an administrator could only edit catalog items they personally created. So it is written as two assertions instead of one:

• every write scope is ownbar one allowlisted exception, asserted by equality against that allowlist, so adding a second exception is a deliberate act rather than a silent pass;
• no write scope anywhere is a hierarchy scope, unconditional and exception-included. This is the acceptance line's real content — depth never reaches the write axis — and it is the invariant this PR could have broken.

The second one earns its place: with the capability declared, the platform check accepts a hierarchy scope on either axis. It does not distinguish read from write. Nothing but this test stops a write depth from loading now.

Ablations

Four legs, each mutation confirmed on disk before measuring, each restored by an EXIT/INT/TERM trap. Tests resolve app code by relative path through vitest's transform — no package exports → dist boundary and no vitest alias (there is no vitest config file) — so no rebuild leg applies here.

leg	mutation	predicted	observed
1	drop hierarchy-security from requires	validate red	exit 1, defineStack hierarchy-scope capability validation failed (3 issues), naming all three grants — duly_admin.duly_task among them, which also proves the inherited grant is real
2	duly_manager.duly_task.writeScope: 'org'	write-scope tests red, validategreen	6 failed / 54 passed; expected { …(3) } to deeply equal { Object (duly_admin.duly_catalog_item) }. Config loaded — org needs no declaration, which is the point
3	duly_manager.duly_task.writeScope: 'unit_and_below'	leg 2's failures plus the hierarchy-write assertion	8 failed / 52 passed; duly_manager.duly_task writes by hierarchy depth: expected [ 'own_and_reports', 'unit', …(1) ] to not include 'unit_and_below'. Config still loaded
4	duly_manager.duly_task.readScope back to 'own'	depth assertions red, write assertions green	6 failed / 54 passed; write-scope block stayed green, as predicted

One honesty note on the on-disk confirmation: the injected-marker count (MUTANT, want 1) was correct on every leg and is what proves each mutation landed. The paired removed-anchor count was mis-anchored — its pattern also matched the untouched duly_duty override — so it read 2/1/1 instead of 0. The marker count and the assertion output naming the mutated value are the evidence; that counter is not.

Gates

All four green on 5dd788b, run under the container's shared verify lock:

✓ Validation passed (397ms)
⚠ Capability "hierarchy-security" is provided by @objectstack/security-enterprise …
Test Files 12 passed (12)
Tests 374 passed (374)
✓ Build complete (635ms)

The warning is the acceptance criterion, not a leftover.

File-surface note

One file beyond the declared surface: src/security/index.ts, which re-exported HIERARCHY_SCOPES_DEFERRED. Deleting the constant without it is a compile error, so it is the mechanical completion of the card's own step 2 rather than new scope — a four-line export list losing one line. No sibling card in this round touches it (#51 datasets, #50duty.object.ts, #27 global actions). src/objects/duty.object.ts was not touched.

Found outside the file surface — reported, not edited

docs/roadmap.md (M2 bullet) says an open-edition checkout "correctly shows owner-only rows". That half is true and stays true. It does not repeat the falsified claim, so it is left alone.

---

Generated by Claude Code

[os-warren]

Fixes#46

Four places in this repo said declaring requires: ['hierarchy-security'] would fail an open-edition boot. It does not. That belief is what forced the three manager depth grants down to own, so removing it and restoring the grants are one change.

Verified on 5dd788b (final commit) with @objectstack/security-enterprisenot installed and nothing added to package.json.

What changed

objectstack.config.ts — requires: ['automation', 'hierarchy-security'], and the comment beside it rewritten. It now quotes the platform's own reason for the check, records the measurement, and says plainly that the warning is the expected state. The "Security posture" comment further down said the scopes "fail closed to owner-only, silently"; that was the same claim in its second half, and it is now the warning-announced behaviour it actually is.

src/security/permission-sets.ts — duly_manager reads unit_and_below on duly_task and duly_duty. duly_admin gets the task depth by inheritance, not restatement, so the third grant costs no third edit. Both overrides spread the member entry, leaving writeScope: 'own' inherited rather than retyped. HIERARCHY_SCOPES_DEFERRED and its docblock are gone.

Write scopes did not move. A manager reads down and writes nothing but their own — that was never the deferred half.

AGENTS.md rule 7 — rewritten end to end: a hierarchy scope requires the declaration; omitting it is an author-time hard error that takes validate, build and every test importing the config; declaring it warns and installs nothing; open-edition resolution is owner-only and a local manager view showing only your own rows is the edition, not a bug. It also names the trapdoor next door — org is not a hierarchy scope, loads with no declaration, and discloses the whole tenant.

docs/product/data-model.md and docs/deployment/security.md — same claim, same correction. The deployment page's "Two manager grants are currently narrower than this table implies" section is replaced by one describing the declaration and the warning; the model table now shows the manager depth instead of "inherited".

Tests

test/security.test.ts. The old stopgap block pinned the compromise in both directions; the new one pins the dependency in both directions:

• each of the three grants is unit_and_below;
• those three are the only hierarchy scopes authored anywhere (which is also what keeps the next assertion from going vacuous);
• if any hierarchy scope is authored, stack.requires must contain hierarchy-security — a named failure here instead of an opaque config-load failure across every suite;
• no set reads duly_task at org;
• the manager depth overrides keep every member key they do not change (the failure mode this change could most easily have caused: retyping the entry and dropping writeScope: 'own').

One deviation, stated

The card asks for a test that no grant anywhere has a write scope wider than own. Taken literally that is false today: duly_admin.duly_catalog_item is writeScope: 'org', deliberately — public_read is read-open but write-owned, so without it an administrator could only edit catalog items they personally created. So it is written as two assertions instead of one:

• every write scope is ownbar one allowlisted exception, asserted by equality against that allowlist, so adding a second exception is a deliberate act rather than a silent pass;
• no write scope anywhere is a hierarchy scope, unconditional and exception-included. This is the acceptance line's real content — depth never reaches the write axis — and it is the invariant this PR could have broken.

The second one earns its place: with the capability declared, the platform check accepts a hierarchy scope on either axis. It does not distinguish read from write. Nothing but this test stops a write depth from loading now.

Ablations

Four legs, each mutation confirmed on disk before measuring, each restored by an EXIT/INT/TERM trap. Tests resolve app code by relative path through vitest's transform — no package exports → dist boundary and no vitest alias (there is no vitest config file) — so no rebuild leg applies here.

leg	mutation	predicted	observed
1	drop hierarchy-security from requires	validate red	exit 1, defineStack hierarchy-scope capability validation failed (3 issues), naming all three grants — duly_admin.duly_task among them, which also proves the inherited grant is real
2	duly_manager.duly_task.writeScope: 'org'	write-scope tests red, validategreen	6 failed / 54 passed; expected { …(3) } to deeply equal { Object (duly_admin.duly_catalog_item) }. Config loaded — org needs no declaration, which is the point
3	duly_manager.duly_task.writeScope: 'unit_and_below'	leg 2's failures plus the hierarchy-write assertion	8 failed / 52 passed; duly_manager.duly_task writes by hierarchy depth: expected [ 'own_and_reports', 'unit', …(1) ] to not include 'unit_and_below'. Config still loaded
4	duly_manager.duly_task.readScope back to 'own'	depth assertions red, write assertions green	6 failed / 54 passed; write-scope block stayed green, as predicted

One honesty note on the on-disk confirmation: the injected-marker count (MUTANT, want 1) was correct on every leg and is what proves each mutation landed. The paired removed-anchor count was mis-anchored — its pattern also matched the untouched duly_duty override — so it read 2/1/1 instead of 0. The marker count and the assertion output naming the mutated value are the evidence; that counter is not.

Gates

All four green on 5dd788b, run under the container's shared verify lock:

✓ Validation passed (397ms)
⚠ Capability "hierarchy-security" is provided by @objectstack/security-enterprise …
Test Files 12 passed (12)
Tests 374 passed (374)
✓ Build complete (635ms)

The warning is the acceptance criterion, not a leftover.

File-surface note

One file beyond the declared surface: src/security/index.ts, which re-exported HIERARCHY_SCOPES_DEFERRED. Deleting the constant without it is a compile error, so it is the mechanical completion of the card's own step 2 rather than new scope — a four-line export list losing one line. No sibling card in this round touches it (#51 datasets, #50duty.object.ts, #27 global actions). src/objects/duty.object.ts was not touched.

Found outside the file surface — reported, not edited

docs/roadmap.md (M2 bullet) says an open-edition checkout "correctly shows owner-only rows". That half is true and stays true. It does not repeat the falsified claim, so it is left alone.

---

Generated by Claude Code

[os-warren]

Fixes#46

Four places in this repo said declaring requires: ['hierarchy-security'] would fail an open-edition boot. It does not. That belief is what forced the three manager depth grants down to own, so removing it and restoring the grants are one change.

Verified on 5dd788b (final commit) with @objectstack/security-enterprisenot installed and nothing added to package.json.

What changed

objectstack.config.ts — requires: ['automation', 'hierarchy-security'], and the comment beside it rewritten. It now quotes the platform's own reason for the check, records the measurement, and says plainly that the warning is the expected state. The "Security posture" comment further down said the scopes "fail closed to owner-only, silently"; that was the same claim in its second half, and it is now the warning-announced behaviour it actually is.

src/security/permission-sets.ts — duly_manager reads unit_and_below on duly_task and duly_duty. duly_admin gets the task depth by inheritance, not restatement, so the third grant costs no third edit. Both overrides spread the member entry, leaving writeScope: 'own' inherited rather than retyped. HIERARCHY_SCOPES_DEFERRED and its docblock are gone.

Write scopes did not move. A manager reads down and writes nothing but their own — that was never the deferred half.

AGENTS.md rule 7 — rewritten end to end: a hierarchy scope requires the declaration; omitting it is an author-time hard error that takes validate, build and every test importing the config; declaring it warns and installs nothing; open-edition resolution is owner-only and a local manager view showing only your own rows is the edition, not a bug. It also names the trapdoor next door — org is not a hierarchy scope, loads with no declaration, and discloses the whole tenant.

docs/product/data-model.md and docs/deployment/security.md — same claim, same correction. The deployment page's "Two manager grants are currently narrower than this table implies" section is replaced by one describing the declaration and the warning; the model table now shows the manager depth instead of "inherited".

Tests

test/security.test.ts. The old stopgap block pinned the compromise in both directions; the new one pins the dependency in both directions:

• each of the three grants is unit_and_below;
• those three are the only hierarchy scopes authored anywhere (which is also what keeps the next assertion from going vacuous);
• if any hierarchy scope is authored, stack.requires must contain hierarchy-security — a named failure here instead of an opaque config-load failure across every suite;
• no set reads duly_task at org;
• the manager depth overrides keep every member key they do not change (the failure mode this change could most easily have caused: retyping the entry and dropping writeScope: 'own').

One deviation, stated

The card asks for a test that no grant anywhere has a write scope wider than own. Taken literally that is false today: duly_admin.duly_catalog_item is writeScope: 'org', deliberately — public_read is read-open but write-owned, so without it an administrator could only edit catalog items they personally created. So it is written as two assertions instead of one:

• every write scope is ownbar one allowlisted exception, asserted by equality against that allowlist, so adding a second exception is a deliberate act rather than a silent pass;
• no write scope anywhere is a hierarchy scope, unconditional and exception-included. This is the acceptance line's real content — depth never reaches the write axis — and it is the invariant this PR could have broken.

The second one earns its place: with the capability declared, the platform check accepts a hierarchy scope on either axis. It does not distinguish read from write. Nothing but this test stops a write depth from loading now.

Ablations

Four legs, each mutation confirmed on disk before measuring, each restored by an EXIT/INT/TERM trap. Tests resolve app code by relative path through vitest's transform — no package exports → dist boundary and no vitest alias (there is no vitest config file) — so no rebuild leg applies here.

leg	mutation	predicted	observed
1	drop hierarchy-security from requires	validate red	exit 1, defineStack hierarchy-scope capability validation failed (3 issues), naming all three grants — duly_admin.duly_task among them, which also proves the inherited grant is real
2	duly_manager.duly_task.writeScope: 'org'	write-scope tests red, validategreen	6 failed / 54 passed; expected { …(3) } to deeply equal { Object (duly_admin.duly_catalog_item) }. Config loaded — org needs no declaration, which is the point
3	duly_manager.duly_task.writeScope: 'unit_and_below'	leg 2's failures plus the hierarchy-write assertion	8 failed / 52 passed; duly_manager.duly_task writes by hierarchy depth: expected [ 'own_and_reports', 'unit', …(1) ] to not include 'unit_and_below'. Config still loaded
4	duly_manager.duly_task.readScope back to 'own'	depth assertions red, write assertions green	6 failed / 54 passed; write-scope block stayed green, as predicted

One honesty note on the on-disk confirmation: the injected-marker count (MUTANT, want 1) was correct on every leg and is what proves each mutation landed. The paired removed-anchor count was mis-anchored — its pattern also matched the untouched duly_duty override — so it read 2/1/1 instead of 0. The marker count and the assertion output naming the mutated value are the evidence; that counter is not.

Gates

All four green on 5dd788b, run under the container's shared verify lock:

✓ Validation passed (397ms)
⚠ Capability "hierarchy-security" is provided by @objectstack/security-enterprise …
Test Files 12 passed (12)
Tests 374 passed (374)
✓ Build complete (635ms)

The warning is the acceptance criterion, not a leftover.

File-surface note

One file beyond the declared surface: src/security/index.ts, which re-exported HIERARCHY_SCOPES_DEFERRED. Deleting the constant without it is a compile error, so it is the mechanical completion of the card's own step 2 rather than new scope — a four-line export list losing one line. No sibling card in this round touches it (#51 datasets, #50duty.object.ts, #27 global actions). src/objects/duty.object.ts was not touched.

Found outside the file surface — reported, not edited

docs/roadmap.md (M2 bullet) says an open-edition checkout "correctly shows owner-only rows". That half is true and stays true. It does not repeat the falsified claim, so it is left alone.

---

Generated by Claude Code

[os-warren]

Fixes#46

Four places in this repo said declaring requires: ['hierarchy-security'] would fail an open-edition boot. It does not. That belief is what forced the three manager depth grants down to own, so removing it and restoring the grants are one change.

Verified on 5dd788b (final commit) with @objectstack/security-enterprisenot installed and nothing added to package.json.

What changed

objectstack.config.ts — requires: ['automation', 'hierarchy-security'], and the comment beside it rewritten. It now quotes the platform's own reason for the check, records the measurement, and says plainly that the warning is the expected state. The "Security posture" comment further down said the scopes "fail closed to owner-only, silently"; that was the same claim in its second half, and it is now the warning-announced behaviour it actually is.

src/security/permission-sets.ts — duly_manager reads unit_and_below on duly_task and duly_duty. duly_admin gets the task depth by inheritance, not restatement, so the third grant costs no third edit. Both overrides spread the member entry, leaving writeScope: 'own' inherited rather than retyped. HIERARCHY_SCOPES_DEFERRED and its docblock are gone.

Write scopes did not move. A manager reads down and writes nothing but their own — that was never the deferred half.

AGENTS.md rule 7 — rewritten end to end: a hierarchy scope requires the declaration; omitting it is an author-time hard error that takes validate, build and every test importing the config; declaring it warns and installs nothing; open-edition resolution is owner-only and a local manager view showing only your own rows is the edition, not a bug. It also names the trapdoor next door — org is not a hierarchy scope, loads with no declaration, and discloses the whole tenant.

docs/product/data-model.md and docs/deployment/security.md — same claim, same correction. The deployment page's "Two manager grants are currently narrower than this table implies" section is replaced by one describing the declaration and the warning; the model table now shows the manager depth instead of "inherited".

Tests

test/security.test.ts. The old stopgap block pinned the compromise in both directions; the new one pins the dependency in both directions:

• each of the three grants is unit_and_below;
• those three are the only hierarchy scopes authored anywhere (which is also what keeps the next assertion from going vacuous);
• if any hierarchy scope is authored, stack.requires must contain hierarchy-security — a named failure here instead of an opaque config-load failure across every suite;
• no set reads duly_task at org;
• the manager depth overrides keep every member key they do not change (the failure mode this change could most easily have caused: retyping the entry and dropping writeScope: 'own').

One deviation, stated

The card asks for a test that no grant anywhere has a write scope wider than own. Taken literally that is false today: duly_admin.duly_catalog_item is writeScope: 'org', deliberately — public_read is read-open but write-owned, so without it an administrator could only edit catalog items they personally created. So it is written as two assertions instead of one:

• every write scope is ownbar one allowlisted exception, asserted by equality against that allowlist, so adding a second exception is a deliberate act rather than a silent pass;
• no write scope anywhere is a hierarchy scope, unconditional and exception-included. This is the acceptance line's real content — depth never reaches the write axis — and it is the invariant this PR could have broken.

The second one earns its place: with the capability declared, the platform check accepts a hierarchy scope on either axis. It does not distinguish read from write. Nothing but this test stops a write depth from loading now.

Ablations

Four legs, each mutation confirmed on disk before measuring, each restored by an EXIT/INT/TERM trap. Tests resolve app code by relative path through vitest's transform — no package exports → dist boundary and no vitest alias (there is no vitest config file) — so no rebuild leg applies here.

leg	mutation	predicted	observed
1	drop hierarchy-security from requires	validate red	exit 1, defineStack hierarchy-scope capability validation failed (3 issues), naming all three grants — duly_admin.duly_task among them, which also proves the inherited grant is real
2	duly_manager.duly_task.writeScope: 'org'	write-scope tests red, validategreen	6 failed / 54 passed; expected { …(3) } to deeply equal { Object (duly_admin.duly_catalog_item) }. Config loaded — org needs no declaration, which is the point
3	duly_manager.duly_task.writeScope: 'unit_and_below'	leg 2's failures plus the hierarchy-write assertion	8 failed / 52 passed; duly_manager.duly_task writes by hierarchy depth: expected [ 'own_and_reports', 'unit', …(1) ] to not include 'unit_and_below'. Config still loaded
4	duly_manager.duly_task.readScope back to 'own'	depth assertions red, write assertions green	6 failed / 54 passed; write-scope block stayed green, as predicted

One honesty note on the on-disk confirmation: the injected-marker count (MUTANT, want 1) was correct on every leg and is what proves each mutation landed. The paired removed-anchor count was mis-anchored — its pattern also matched the untouched duly_duty override — so it read 2/1/1 instead of 0. The marker count and the assertion output naming the mutated value are the evidence; that counter is not.

Gates

All four green on 5dd788b, run under the container's shared verify lock:

✓ Validation passed (397ms)
⚠ Capability "hierarchy-security" is provided by @objectstack/security-enterprise …
Test Files 12 passed (12)
Tests 374 passed (374)
✓ Build complete (635ms)

The warning is the acceptance criterion, not a leftover.

File-surface note

One file beyond the declared surface: src/security/index.ts, which re-exported HIERARCHY_SCOPES_DEFERRED. Deleting the constant without it is a compile error, so it is the mechanical completion of the card's own step 2 rather than new scope — a four-line export list losing one line. No sibling card in this round touches it (#51 datasets, #50duty.object.ts, #27 global actions). src/objects/duty.object.ts was not touched.

Found outside the file surface — reported, not edited

docs/roadmap.md (M2 bullet) says an open-edition checkout "correctly shows owner-only rows". That half is true and stays true. It does not repeat the falsified claim, so it is left alone.

---

Generated by Claude Code