Declare the security model, and gate all five actions

[os-warren]

Part of #8
Fixes#30
Fixes#40

Three flat positions, three composed permission sets, capability gates on all five actions, and a deployment page that says what a rollout still has to do by hand.

The first line is Part of, not a closing keyword, and that is deliberate: two things the card specifies are not shippable on protocol 17.2.0 (below), and one of them needs a maintainer ruling recorded on #8 before that card is closed. #30 and #40 are complete and do close here.

Gates, all four green at 8d5cc29 — the tip of this branch, re-run on the restored tree after the ablations below:

gate	verdict line
pnpm validate	✓ Validation passed (330ms) · Security: 3 Positions 3 Permissions
pnpm typecheck	tsc --noEmit, exit 0, no output
pnpm test	Test Files 9 passed (9) · Tests 334 passed (334)
pnpm build	✓ Build complete (603ms)

---

The model

	duly_member	duly_manager	duly_admin
duly_task	create/read/edit · read own · write own	inherited	inherited
duly_duty	create/read · read own · write own	inherited	+edit · read org · write own
duly_log_entry	full control · read own · write own	inherited	inherited
duly_catalog_item	read	inherited	+create/edit/delete · write org
duly_assignment	read · read own	+create/edit · write own	inherited
Capabilities	duly.task.update_status	inherited	+duly.catalog.apply, duly.catalog.sync

"Inherited" is literal, not descriptive: MANAGER_OBJECTS spreads MEMBER_OBJECTS, ADMIN_OBJECTS spreads MANAGER_OBJECTS, and the test asserts every non-overridden entry is the same object. A grant is written once, so nobody can widen the work log for managers by editing a copy — there is no copy.

Each set is self-contained, so binding one set to one position is a correct deployment.

The two invariants, enforced rather than intended

The work log is closed to everyone but its owner, administrators included. No depth scope, no viewAllRecords, no sharing rule, walked across all three sets. No set carries a write scope wider than own on duly_task / duly_duty — every widening in this PR is on the read axis, and the test also proves that the only write bit the manager set adds anywhere is duly_assignment.

duly_admin.duly_duty is the one entry worth reading twice: it gets allowEditand keeps writeScope: 'own'. That is the card's acceptance line beating its permission-set line, and the bit is not inert — an administrator can correct their own duties, which a member cannot. The org-wide correction path is deliberately elsewhere: duly_catalog_sync, which is bounded to cadence fields, capability-gated, and reportable. A correction typed into someone else's duty record is none of those.

Deliberate non-obvious calls

• duly_catalog_item gets writeScope: 'org' on the admin set, and no readScope anywhere.public_read is read-open but write-owned — buildWriteFilter applies to private and public_read alike — so without the write depth an administrator could only edit catalog items they personally created. Conversely buildReadFilter returns null before depth is consulted for any non-private object, so a readScope there would be inert and is not authored.
• duly.catalog.apply and duly.catalog.sync are two capabilities, both granted to duly_admin, answering the question Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 raises. Nothing is harder to deploy, but a customer who wants an onboarding administrator who cannot rewrite the org's cadence can now express it.
• No isDefault, no fields block, no adminScope, no '*' wildcard.isDefault is not available: the ADR-0090 D5/D9 anchor tier refuses any set carrying systemPermissions or a delete bit, and duly_member carries both. FLS would only restate readonly flags the objects already enforce.
• The action files hard-code their capability strings rather than importing the constants, to keep to the requiredPermissions-only file surface. The link is held by two independent checks instead: the capability-reference-unknown author-time rule, and a test asserting every required capability is granted by a set in this package.

---

⛔ Two things the card asks for that this platform version cannot express

Both fail closed. Neither is approximated.

1. No sharing rule can name the record owner's manager — objectstack#14103

ShareRecipientType is five static principals, and plugin-sharing's expandRecipient resolves rule.recipient_id once per rule, never per matched record. The predicate half (record.visibility == "manager") lowers fine; the recipient half has nothing to resolve through.

The nearest expressible recipient, position: 'duly_manager', would hand every marked entry to every manager in the tenant — the disclosure the invariant exists to prevent — so it is not authored as a stopgap.

RLS is not a way round it either, despite sharing-rule-runtime-variable-condition's hint recommending exactly that. On a private object the layers are AND-composed, not OR-composed:

// plugin-security getReadFilterreturnandComposeLayers(andComposeLayers(filter,cbpFilter),sharingFilter)??void0;

and buildReadFilter returns ownerMatch (OR'd only with the caller's own sys_record_share grants). An RLS policy can therefore only narrow a private object's readable set. Widening has two doors — the ADR-0057 depth scopes and a sys_record_share row — and both are shut for a record-relative recipient.

duly_assignment hits the same wall: "readable by the people it is addressed to" is the same shape. Assignees still see their own fanned-out duly_task, which is the row they work.

src/security/sharing-rules.ts is an empty array with the whole measurement on it. The file exists precisely so the next author does not rediscover the wall and author their way past it with the recipient that lints clean.

2. A hierarchy read depth cannot be authored here — tracked as #46

duly_manager on duly_task / duly_duty and duly_admin on duly_task should read unit_and_below. They ship at own.

defineStack's validateHierarchyScopeCapability is a hard error on unit / unit_and_below / own_and_reports unless the stack declares requires: ['hierarchy-security']. It runs inside defineStack(), so it takes validate, build and the three tests that import the config. This is not the "silent fallback to owner-only" AGENTS.md rule 7 describes — nothing silent happens; the config will not load.

The premise blocking the prescribed fix is measurably false. Rule 7, objectstack.config.ts, the card and its PM comment all state that declaring hierarchy-security "would fail an open-edition boot". Measured on this checkout with the capability declared, unit_and_below restored, and @objectstack/security-enterprise not installed:

gate	exit	result
pnpm validate	0	✓ Validation passed + one provider warning
pnpm test	0	Tests 278 passed (278), kernel logged ✅ Bootstrap complete
pnpm build	0	✓ Build complete

So the one-line fix appears to work. It is not taken here: objectstack.config.ts is outside this card's file surface, it is the collision file AGENTS.md rule 2 reserves, and overturning a rule written in four places belongs on its own change. #46 carries the full measurement and its bounds.

own is also exactly what an open-edition runtime would have resolvedunit_and_below to, so nothing about today's behaviour differs — only the honesty of the declaration. The three grants are recorded in HIERARCHY_SCOPES_DEFERRED and pinned in both directions: widen a grant without deleting its row and the test fails; delete a row without widening the grant and the test fails.

---

Ablations — the new tests do fail when they should

Both run on the committed tree with a restoring trap, mutation confirmed on disk before the run and absence confirmed after. Predicted direction for both was red, and both went red in exactly the named places.

Widen duly_log_entry to readScope: 'org' on the manager set (org chosen over unit_and_below on purpose — it is authorable, so the only red can come from the guard rather than from defineStack refusing to load):

injected marker count: 1 → Tests 4 failed | 330 passed
FAIL duly_log_entry must not leak > every set — admin included — reads own and only own
FAIL manager and admin inherit rather than restate > every non-overridden manager entry …
FAIL permission sets … > duly_manager · duly_log_entry declares readScope=own writeScope=own
FAIL permission sets … > duly_admin · duly_log_entry declares readScope=own writeScope=own
restored marker count: 0

Delete requiredPermissions from duly_catalog_apply:

Tests 2 failed | 332 passed
FAIL action capability gates > duly_catalog_apply requires duly.catalog.apply
FAIL action capability gates > every action this app ships declares a gate — none left open

One honest note on the second: the shell marker I printed for it was mis-anchored — it grepped the bare capability string, which also appears three times in prose, so it read 3 where I had written "want 0". The disk-landing proof there is the Python assert count == 1 on the exact requiredPermissions: line before the replace, plus the targeted red. The first ablation's markers were clean (1 → 0).

The own_and_reports / unit_and_below half of the hierarchy finding was measured the same way, against objectstack.config.ts under a trap; that file is untouched in this diff (git status clean, verified after each leg).

---

Also filed

• Sharing rules cannot name a RECORD-RELATIVE recipient (the owner's manager; the value of a user field on the matched record), and no other declarative surface can widen a private object either objectstack#14103 — record-relative sharing recipients. Unassigned.
• AGENTS.md rule 7 and objectstack.config.ts claim declaring hierarchy-security fails an open-edition boot — measured false, and the claim is what blocks the manager read scopes #46 — the falsified hierarchy-security premise in AGENTS.md rule 7 and objectstack.config.ts. Unassigned. Note docs/product/data-model.md's "Security posture" section carries the same claim and is outside this card's file surface, so it is left for that issue.
• A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50 — duly_duty.source defaults to catalog, so a hand-created self-declared duty is born scoreable. Found because the member set grants "create own duty, source: 'self'". Unassigned.

Files

src/security/positions.ts, src/security/permission-sets.ts, src/security/sharing-rules.ts (new) · src/security/index.ts (barrel) · src/actions/catalog.actions.ts, src/actions/task.actions.ts (requiredPermissions keys only — no imports added, no handler bodies, no register-handlers.ts) · docs/deployment/security.md (new) · test/security.test.ts (new). objectstack.config.ts untouched.

---

Generated by Claude Code

[os-warren]

Part of #8
Fixes#30
Fixes#40

Three flat positions, three composed permission sets, capability gates on all five actions, and a deployment page that says what a rollout still has to do by hand.

The first line is Part of, not a closing keyword, and that is deliberate: two things the card specifies are not shippable on protocol 17.2.0 (below), and one of them needs a maintainer ruling recorded on #8 before that card is closed. #30 and #40 are complete and do close here.

Gates, all four green at 8d5cc29 — the tip of this branch, re-run on the restored tree after the ablations below:

gate	verdict line
pnpm validate	✓ Validation passed (330ms) · Security: 3 Positions 3 Permissions
pnpm typecheck	tsc --noEmit, exit 0, no output
pnpm test	Test Files 9 passed (9) · Tests 334 passed (334)
pnpm build	✓ Build complete (603ms)

---

The model

	duly_member	duly_manager	duly_admin
duly_task	create/read/edit · read own · write own	inherited	inherited
duly_duty	create/read · read own · write own	inherited	+edit · read org · write own
duly_log_entry	full control · read own · write own	inherited	inherited
duly_catalog_item	read	inherited	+create/edit/delete · write org
duly_assignment	read · read own	+create/edit · write own	inherited
Capabilities	duly.task.update_status	inherited	+duly.catalog.apply, duly.catalog.sync

"Inherited" is literal, not descriptive: MANAGER_OBJECTS spreads MEMBER_OBJECTS, ADMIN_OBJECTS spreads MANAGER_OBJECTS, and the test asserts every non-overridden entry is the same object. A grant is written once, so nobody can widen the work log for managers by editing a copy — there is no copy.

Each set is self-contained, so binding one set to one position is a correct deployment.

The two invariants, enforced rather than intended

The work log is closed to everyone but its owner, administrators included. No depth scope, no viewAllRecords, no sharing rule, walked across all three sets. No set carries a write scope wider than own on duly_task / duly_duty — every widening in this PR is on the read axis, and the test also proves that the only write bit the manager set adds anywhere is duly_assignment.

duly_admin.duly_duty is the one entry worth reading twice: it gets allowEditand keeps writeScope: 'own'. That is the card's acceptance line beating its permission-set line, and the bit is not inert — an administrator can correct their own duties, which a member cannot. The org-wide correction path is deliberately elsewhere: duly_catalog_sync, which is bounded to cadence fields, capability-gated, and reportable. A correction typed into someone else's duty record is none of those.

Deliberate non-obvious calls

• duly_catalog_item gets writeScope: 'org' on the admin set, and no readScope anywhere.public_read is read-open but write-owned — buildWriteFilter applies to private and public_read alike — so without the write depth an administrator could only edit catalog items they personally created. Conversely buildReadFilter returns null before depth is consulted for any non-private object, so a readScope there would be inert and is not authored.
• duly.catalog.apply and duly.catalog.sync are two capabilities, both granted to duly_admin, answering the question Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 raises. Nothing is harder to deploy, but a customer who wants an onboarding administrator who cannot rewrite the org's cadence can now express it.
• No isDefault, no fields block, no adminScope, no '*' wildcard.isDefault is not available: the ADR-0090 D5/D9 anchor tier refuses any set carrying systemPermissions or a delete bit, and duly_member carries both. FLS would only restate readonly flags the objects already enforce.
• The action files hard-code their capability strings rather than importing the constants, to keep to the requiredPermissions-only file surface. The link is held by two independent checks instead: the capability-reference-unknown author-time rule, and a test asserting every required capability is granted by a set in this package.

---

⛔ Two things the card asks for that this platform version cannot express

Both fail closed. Neither is approximated.

1. No sharing rule can name the record owner's manager — objectstack#14103

ShareRecipientType is five static principals, and plugin-sharing's expandRecipient resolves rule.recipient_id once per rule, never per matched record. The predicate half (record.visibility == "manager") lowers fine; the recipient half has nothing to resolve through.

The nearest expressible recipient, position: 'duly_manager', would hand every marked entry to every manager in the tenant — the disclosure the invariant exists to prevent — so it is not authored as a stopgap.

RLS is not a way round it either, despite sharing-rule-runtime-variable-condition's hint recommending exactly that. On a private object the layers are AND-composed, not OR-composed:

// plugin-security getReadFilterreturnandComposeLayers(andComposeLayers(filter,cbpFilter),sharingFilter)??void0;

and buildReadFilter returns ownerMatch (OR'd only with the caller's own sys_record_share grants). An RLS policy can therefore only narrow a private object's readable set. Widening has two doors — the ADR-0057 depth scopes and a sys_record_share row — and both are shut for a record-relative recipient.

duly_assignment hits the same wall: "readable by the people it is addressed to" is the same shape. Assignees still see their own fanned-out duly_task, which is the row they work.

src/security/sharing-rules.ts is an empty array with the whole measurement on it. The file exists precisely so the next author does not rediscover the wall and author their way past it with the recipient that lints clean.

2. A hierarchy read depth cannot be authored here — tracked as #46

duly_manager on duly_task / duly_duty and duly_admin on duly_task should read unit_and_below. They ship at own.

defineStack's validateHierarchyScopeCapability is a hard error on unit / unit_and_below / own_and_reports unless the stack declares requires: ['hierarchy-security']. It runs inside defineStack(), so it takes validate, build and the three tests that import the config. This is not the "silent fallback to owner-only" AGENTS.md rule 7 describes — nothing silent happens; the config will not load.

The premise blocking the prescribed fix is measurably false. Rule 7, objectstack.config.ts, the card and its PM comment all state that declaring hierarchy-security "would fail an open-edition boot". Measured on this checkout with the capability declared, unit_and_below restored, and @objectstack/security-enterprise not installed:

gate	exit	result
pnpm validate	0	✓ Validation passed + one provider warning
pnpm test	0	Tests 278 passed (278), kernel logged ✅ Bootstrap complete
pnpm build	0	✓ Build complete

So the one-line fix appears to work. It is not taken here: objectstack.config.ts is outside this card's file surface, it is the collision file AGENTS.md rule 2 reserves, and overturning a rule written in four places belongs on its own change. #46 carries the full measurement and its bounds.

own is also exactly what an open-edition runtime would have resolvedunit_and_below to, so nothing about today's behaviour differs — only the honesty of the declaration. The three grants are recorded in HIERARCHY_SCOPES_DEFERRED and pinned in both directions: widen a grant without deleting its row and the test fails; delete a row without widening the grant and the test fails.

---

Ablations — the new tests do fail when they should

Both run on the committed tree with a restoring trap, mutation confirmed on disk before the run and absence confirmed after. Predicted direction for both was red, and both went red in exactly the named places.

Widen duly_log_entry to readScope: 'org' on the manager set (org chosen over unit_and_below on purpose — it is authorable, so the only red can come from the guard rather than from defineStack refusing to load):

injected marker count: 1 → Tests 4 failed | 330 passed
FAIL duly_log_entry must not leak > every set — admin included — reads own and only own
FAIL manager and admin inherit rather than restate > every non-overridden manager entry …
FAIL permission sets … > duly_manager · duly_log_entry declares readScope=own writeScope=own
FAIL permission sets … > duly_admin · duly_log_entry declares readScope=own writeScope=own
restored marker count: 0

Delete requiredPermissions from duly_catalog_apply:

Tests 2 failed | 332 passed
FAIL action capability gates > duly_catalog_apply requires duly.catalog.apply
FAIL action capability gates > every action this app ships declares a gate — none left open

One honest note on the second: the shell marker I printed for it was mis-anchored — it grepped the bare capability string, which also appears three times in prose, so it read 3 where I had written "want 0". The disk-landing proof there is the Python assert count == 1 on the exact requiredPermissions: line before the replace, plus the targeted red. The first ablation's markers were clean (1 → 0).

The own_and_reports / unit_and_below half of the hierarchy finding was measured the same way, against objectstack.config.ts under a trap; that file is untouched in this diff (git status clean, verified after each leg).

---

Also filed

• Sharing rules cannot name a RECORD-RELATIVE recipient (the owner's manager; the value of a user field on the matched record), and no other declarative surface can widen a private object either objectstack#14103 — record-relative sharing recipients. Unassigned.
• AGENTS.md rule 7 and objectstack.config.ts claim declaring hierarchy-security fails an open-edition boot — measured false, and the claim is what blocks the manager read scopes #46 — the falsified hierarchy-security premise in AGENTS.md rule 7 and objectstack.config.ts. Unassigned. Note docs/product/data-model.md's "Security posture" section carries the same claim and is outside this card's file surface, so it is left for that issue.
• A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50 — duly_duty.source defaults to catalog, so a hand-created self-declared duty is born scoreable. Found because the member set grants "create own duty, source: 'self'". Unassigned.

Files

src/security/positions.ts, src/security/permission-sets.ts, src/security/sharing-rules.ts (new) · src/security/index.ts (barrel) · src/actions/catalog.actions.ts, src/actions/task.actions.ts (requiredPermissions keys only — no imports added, no handler bodies, no register-handlers.ts) · docs/deployment/security.md (new) · test/security.test.ts (new). objectstack.config.ts untouched.

---

Generated by Claude Code

[os-warren]

Part of #8
Fixes#30
Fixes#40

Three flat positions, three composed permission sets, capability gates on all five actions, and a deployment page that says what a rollout still has to do by hand.

The first line is Part of, not a closing keyword, and that is deliberate: two things the card specifies are not shippable on protocol 17.2.0 (below), and one of them needs a maintainer ruling recorded on #8 before that card is closed. #30 and #40 are complete and do close here.

Gates, all four green at 8d5cc29 — the tip of this branch, re-run on the restored tree after the ablations below:

gate	verdict line
pnpm validate	✓ Validation passed (330ms) · Security: 3 Positions 3 Permissions
pnpm typecheck	tsc --noEmit, exit 0, no output
pnpm test	Test Files 9 passed (9) · Tests 334 passed (334)
pnpm build	✓ Build complete (603ms)

---

The model

	duly_member	duly_manager	duly_admin
duly_task	create/read/edit · read own · write own	inherited	inherited
duly_duty	create/read · read own · write own	inherited	+edit · read org · write own
duly_log_entry	full control · read own · write own	inherited	inherited
duly_catalog_item	read	inherited	+create/edit/delete · write org
duly_assignment	read · read own	+create/edit · write own	inherited
Capabilities	duly.task.update_status	inherited	+duly.catalog.apply, duly.catalog.sync

"Inherited" is literal, not descriptive: MANAGER_OBJECTS spreads MEMBER_OBJECTS, ADMIN_OBJECTS spreads MANAGER_OBJECTS, and the test asserts every non-overridden entry is the same object. A grant is written once, so nobody can widen the work log for managers by editing a copy — there is no copy.

Each set is self-contained, so binding one set to one position is a correct deployment.

The two invariants, enforced rather than intended

The work log is closed to everyone but its owner, administrators included. No depth scope, no viewAllRecords, no sharing rule, walked across all three sets. No set carries a write scope wider than own on duly_task / duly_duty — every widening in this PR is on the read axis, and the test also proves that the only write bit the manager set adds anywhere is duly_assignment.

duly_admin.duly_duty is the one entry worth reading twice: it gets allowEditand keeps writeScope: 'own'. That is the card's acceptance line beating its permission-set line, and the bit is not inert — an administrator can correct their own duties, which a member cannot. The org-wide correction path is deliberately elsewhere: duly_catalog_sync, which is bounded to cadence fields, capability-gated, and reportable. A correction typed into someone else's duty record is none of those.

Deliberate non-obvious calls

• duly_catalog_item gets writeScope: 'org' on the admin set, and no readScope anywhere.public_read is read-open but write-owned — buildWriteFilter applies to private and public_read alike — so without the write depth an administrator could only edit catalog items they personally created. Conversely buildReadFilter returns null before depth is consulted for any non-private object, so a readScope there would be inert and is not authored.
• duly.catalog.apply and duly.catalog.sync are two capabilities, both granted to duly_admin, answering the question Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 raises. Nothing is harder to deploy, but a customer who wants an onboarding administrator who cannot rewrite the org's cadence can now express it.
• No isDefault, no fields block, no adminScope, no '*' wildcard.isDefault is not available: the ADR-0090 D5/D9 anchor tier refuses any set carrying systemPermissions or a delete bit, and duly_member carries both. FLS would only restate readonly flags the objects already enforce.
• The action files hard-code their capability strings rather than importing the constants, to keep to the requiredPermissions-only file surface. The link is held by two independent checks instead: the capability-reference-unknown author-time rule, and a test asserting every required capability is granted by a set in this package.

---

⛔ Two things the card asks for that this platform version cannot express

Both fail closed. Neither is approximated.

1. No sharing rule can name the record owner's manager — objectstack#14103

ShareRecipientType is five static principals, and plugin-sharing's expandRecipient resolves rule.recipient_id once per rule, never per matched record. The predicate half (record.visibility == "manager") lowers fine; the recipient half has nothing to resolve through.

The nearest expressible recipient, position: 'duly_manager', would hand every marked entry to every manager in the tenant — the disclosure the invariant exists to prevent — so it is not authored as a stopgap.

RLS is not a way round it either, despite sharing-rule-runtime-variable-condition's hint recommending exactly that. On a private object the layers are AND-composed, not OR-composed:

// plugin-security getReadFilterreturnandComposeLayers(andComposeLayers(filter,cbpFilter),sharingFilter)??void0;

and buildReadFilter returns ownerMatch (OR'd only with the caller's own sys_record_share grants). An RLS policy can therefore only narrow a private object's readable set. Widening has two doors — the ADR-0057 depth scopes and a sys_record_share row — and both are shut for a record-relative recipient.

duly_assignment hits the same wall: "readable by the people it is addressed to" is the same shape. Assignees still see their own fanned-out duly_task, which is the row they work.

src/security/sharing-rules.ts is an empty array with the whole measurement on it. The file exists precisely so the next author does not rediscover the wall and author their way past it with the recipient that lints clean.

2. A hierarchy read depth cannot be authored here — tracked as #46

duly_manager on duly_task / duly_duty and duly_admin on duly_task should read unit_and_below. They ship at own.

defineStack's validateHierarchyScopeCapability is a hard error on unit / unit_and_below / own_and_reports unless the stack declares requires: ['hierarchy-security']. It runs inside defineStack(), so it takes validate, build and the three tests that import the config. This is not the "silent fallback to owner-only" AGENTS.md rule 7 describes — nothing silent happens; the config will not load.

The premise blocking the prescribed fix is measurably false. Rule 7, objectstack.config.ts, the card and its PM comment all state that declaring hierarchy-security "would fail an open-edition boot". Measured on this checkout with the capability declared, unit_and_below restored, and @objectstack/security-enterprise not installed:

gate	exit	result
pnpm validate	0	✓ Validation passed + one provider warning
pnpm test	0	Tests 278 passed (278), kernel logged ✅ Bootstrap complete
pnpm build	0	✓ Build complete

So the one-line fix appears to work. It is not taken here: objectstack.config.ts is outside this card's file surface, it is the collision file AGENTS.md rule 2 reserves, and overturning a rule written in four places belongs on its own change. #46 carries the full measurement and its bounds.

own is also exactly what an open-edition runtime would have resolvedunit_and_below to, so nothing about today's behaviour differs — only the honesty of the declaration. The three grants are recorded in HIERARCHY_SCOPES_DEFERRED and pinned in both directions: widen a grant without deleting its row and the test fails; delete a row without widening the grant and the test fails.

---

Ablations — the new tests do fail when they should

Both run on the committed tree with a restoring trap, mutation confirmed on disk before the run and absence confirmed after. Predicted direction for both was red, and both went red in exactly the named places.

Widen duly_log_entry to readScope: 'org' on the manager set (org chosen over unit_and_below on purpose — it is authorable, so the only red can come from the guard rather than from defineStack refusing to load):

injected marker count: 1 → Tests 4 failed | 330 passed
FAIL duly_log_entry must not leak > every set — admin included — reads own and only own
FAIL manager and admin inherit rather than restate > every non-overridden manager entry …
FAIL permission sets … > duly_manager · duly_log_entry declares readScope=own writeScope=own
FAIL permission sets … > duly_admin · duly_log_entry declares readScope=own writeScope=own
restored marker count: 0

Delete requiredPermissions from duly_catalog_apply:

Tests 2 failed | 332 passed
FAIL action capability gates > duly_catalog_apply requires duly.catalog.apply
FAIL action capability gates > every action this app ships declares a gate — none left open

One honest note on the second: the shell marker I printed for it was mis-anchored — it grepped the bare capability string, which also appears three times in prose, so it read 3 where I had written "want 0". The disk-landing proof there is the Python assert count == 1 on the exact requiredPermissions: line before the replace, plus the targeted red. The first ablation's markers were clean (1 → 0).

The own_and_reports / unit_and_below half of the hierarchy finding was measured the same way, against objectstack.config.ts under a trap; that file is untouched in this diff (git status clean, verified after each leg).

---

Also filed

• Sharing rules cannot name a RECORD-RELATIVE recipient (the owner's manager; the value of a user field on the matched record), and no other declarative surface can widen a private object either objectstack#14103 — record-relative sharing recipients. Unassigned.
• AGENTS.md rule 7 and objectstack.config.ts claim declaring hierarchy-security fails an open-edition boot — measured false, and the claim is what blocks the manager read scopes #46 — the falsified hierarchy-security premise in AGENTS.md rule 7 and objectstack.config.ts. Unassigned. Note docs/product/data-model.md's "Security posture" section carries the same claim and is outside this card's file surface, so it is left for that issue.
• A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50 — duly_duty.source defaults to catalog, so a hand-created self-declared duty is born scoreable. Found because the member set grants "create own duty, source: 'self'". Unassigned.

Files

src/security/positions.ts, src/security/permission-sets.ts, src/security/sharing-rules.ts (new) · src/security/index.ts (barrel) · src/actions/catalog.actions.ts, src/actions/task.actions.ts (requiredPermissions keys only — no imports added, no handler bodies, no register-handlers.ts) · docs/deployment/security.md (new) · test/security.test.ts (new). objectstack.config.ts untouched.

---

Generated by Claude Code

[os-warren]

Part of #8
Fixes#30
Fixes#40

Three flat positions, three composed permission sets, capability gates on all five actions, and a deployment page that says what a rollout still has to do by hand.

The first line is Part of, not a closing keyword, and that is deliberate: two things the card specifies are not shippable on protocol 17.2.0 (below), and one of them needs a maintainer ruling recorded on #8 before that card is closed. #30 and #40 are complete and do close here.

Gates, all four green at 8d5cc29 — the tip of this branch, re-run on the restored tree after the ablations below:

gate	verdict line
pnpm validate	✓ Validation passed (330ms) · Security: 3 Positions 3 Permissions
pnpm typecheck	tsc --noEmit, exit 0, no output
pnpm test	Test Files 9 passed (9) · Tests 334 passed (334)
pnpm build	✓ Build complete (603ms)

---

The model

	duly_member	duly_manager	duly_admin
duly_task	create/read/edit · read own · write own	inherited	inherited
duly_duty	create/read · read own · write own	inherited	+edit · read org · write own
duly_log_entry	full control · read own · write own	inherited	inherited
duly_catalog_item	read	inherited	+create/edit/delete · write org
duly_assignment	read · read own	+create/edit · write own	inherited
Capabilities	duly.task.update_status	inherited	+duly.catalog.apply, duly.catalog.sync

"Inherited" is literal, not descriptive: MANAGER_OBJECTS spreads MEMBER_OBJECTS, ADMIN_OBJECTS spreads MANAGER_OBJECTS, and the test asserts every non-overridden entry is the same object. A grant is written once, so nobody can widen the work log for managers by editing a copy — there is no copy.

Each set is self-contained, so binding one set to one position is a correct deployment.

The two invariants, enforced rather than intended

The work log is closed to everyone but its owner, administrators included. No depth scope, no viewAllRecords, no sharing rule, walked across all three sets. No set carries a write scope wider than own on duly_task / duly_duty — every widening in this PR is on the read axis, and the test also proves that the only write bit the manager set adds anywhere is duly_assignment.

duly_admin.duly_duty is the one entry worth reading twice: it gets allowEditand keeps writeScope: 'own'. That is the card's acceptance line beating its permission-set line, and the bit is not inert — an administrator can correct their own duties, which a member cannot. The org-wide correction path is deliberately elsewhere: duly_catalog_sync, which is bounded to cadence fields, capability-gated, and reportable. A correction typed into someone else's duty record is none of those.

Deliberate non-obvious calls

• duly_catalog_item gets writeScope: 'org' on the admin set, and no readScope anywhere.public_read is read-open but write-owned — buildWriteFilter applies to private and public_read alike — so without the write depth an administrator could only edit catalog items they personally created. Conversely buildReadFilter returns null before depth is consulted for any non-private object, so a readScope there would be inert and is not authored.
• duly.catalog.apply and duly.catalog.sync are two capabilities, both granted to duly_admin, answering the question Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 raises. Nothing is harder to deploy, but a customer who wants an onboarding administrator who cannot rewrite the org's cadence can now express it.
• No isDefault, no fields block, no adminScope, no '*' wildcard.isDefault is not available: the ADR-0090 D5/D9 anchor tier refuses any set carrying systemPermissions or a delete bit, and duly_member carries both. FLS would only restate readonly flags the objects already enforce.
• The action files hard-code their capability strings rather than importing the constants, to keep to the requiredPermissions-only file surface. The link is held by two independent checks instead: the capability-reference-unknown author-time rule, and a test asserting every required capability is granted by a set in this package.

---

⛔ Two things the card asks for that this platform version cannot express

Both fail closed. Neither is approximated.

1. No sharing rule can name the record owner's manager — objectstack#14103

ShareRecipientType is five static principals, and plugin-sharing's expandRecipient resolves rule.recipient_id once per rule, never per matched record. The predicate half (record.visibility == "manager") lowers fine; the recipient half has nothing to resolve through.

The nearest expressible recipient, position: 'duly_manager', would hand every marked entry to every manager in the tenant — the disclosure the invariant exists to prevent — so it is not authored as a stopgap.

RLS is not a way round it either, despite sharing-rule-runtime-variable-condition's hint recommending exactly that. On a private object the layers are AND-composed, not OR-composed:

// plugin-security getReadFilterreturnandComposeLayers(andComposeLayers(filter,cbpFilter),sharingFilter)??void0;

and buildReadFilter returns ownerMatch (OR'd only with the caller's own sys_record_share grants). An RLS policy can therefore only narrow a private object's readable set. Widening has two doors — the ADR-0057 depth scopes and a sys_record_share row — and both are shut for a record-relative recipient.

duly_assignment hits the same wall: "readable by the people it is addressed to" is the same shape. Assignees still see their own fanned-out duly_task, which is the row they work.

src/security/sharing-rules.ts is an empty array with the whole measurement on it. The file exists precisely so the next author does not rediscover the wall and author their way past it with the recipient that lints clean.

2. A hierarchy read depth cannot be authored here — tracked as #46

duly_manager on duly_task / duly_duty and duly_admin on duly_task should read unit_and_below. They ship at own.

defineStack's validateHierarchyScopeCapability is a hard error on unit / unit_and_below / own_and_reports unless the stack declares requires: ['hierarchy-security']. It runs inside defineStack(), so it takes validate, build and the three tests that import the config. This is not the "silent fallback to owner-only" AGENTS.md rule 7 describes — nothing silent happens; the config will not load.

The premise blocking the prescribed fix is measurably false. Rule 7, objectstack.config.ts, the card and its PM comment all state that declaring hierarchy-security "would fail an open-edition boot". Measured on this checkout with the capability declared, unit_and_below restored, and @objectstack/security-enterprise not installed:

gate	exit	result
pnpm validate	0	✓ Validation passed + one provider warning
pnpm test	0	Tests 278 passed (278), kernel logged ✅ Bootstrap complete
pnpm build	0	✓ Build complete

So the one-line fix appears to work. It is not taken here: objectstack.config.ts is outside this card's file surface, it is the collision file AGENTS.md rule 2 reserves, and overturning a rule written in four places belongs on its own change. #46 carries the full measurement and its bounds.

own is also exactly what an open-edition runtime would have resolvedunit_and_below to, so nothing about today's behaviour differs — only the honesty of the declaration. The three grants are recorded in HIERARCHY_SCOPES_DEFERRED and pinned in both directions: widen a grant without deleting its row and the test fails; delete a row without widening the grant and the test fails.

---

Ablations — the new tests do fail when they should

Both run on the committed tree with a restoring trap, mutation confirmed on disk before the run and absence confirmed after. Predicted direction for both was red, and both went red in exactly the named places.

Widen duly_log_entry to readScope: 'org' on the manager set (org chosen over unit_and_below on purpose — it is authorable, so the only red can come from the guard rather than from defineStack refusing to load):

injected marker count: 1 → Tests 4 failed | 330 passed
FAIL duly_log_entry must not leak > every set — admin included — reads own and only own
FAIL manager and admin inherit rather than restate > every non-overridden manager entry …
FAIL permission sets … > duly_manager · duly_log_entry declares readScope=own writeScope=own
FAIL permission sets … > duly_admin · duly_log_entry declares readScope=own writeScope=own
restored marker count: 0

Delete requiredPermissions from duly_catalog_apply:

Tests 2 failed | 332 passed
FAIL action capability gates > duly_catalog_apply requires duly.catalog.apply
FAIL action capability gates > every action this app ships declares a gate — none left open

One honest note on the second: the shell marker I printed for it was mis-anchored — it grepped the bare capability string, which also appears three times in prose, so it read 3 where I had written "want 0". The disk-landing proof there is the Python assert count == 1 on the exact requiredPermissions: line before the replace, plus the targeted red. The first ablation's markers were clean (1 → 0).

The own_and_reports / unit_and_below half of the hierarchy finding was measured the same way, against objectstack.config.ts under a trap; that file is untouched in this diff (git status clean, verified after each leg).

---

Also filed

• Sharing rules cannot name a RECORD-RELATIVE recipient (the owner's manager; the value of a user field on the matched record), and no other declarative surface can widen a private object either objectstack#14103 — record-relative sharing recipients. Unassigned.
• AGENTS.md rule 7 and objectstack.config.ts claim declaring hierarchy-security fails an open-edition boot — measured false, and the claim is what blocks the manager read scopes #46 — the falsified hierarchy-security premise in AGENTS.md rule 7 and objectstack.config.ts. Unassigned. Note docs/product/data-model.md's "Security posture" section carries the same claim and is outside this card's file surface, so it is left for that issue.
• A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50 — duly_duty.source defaults to catalog, so a hand-created self-declared duty is born scoreable. Found because the member set grants "create own duty, source: 'self'". Unassigned.

Files

src/security/positions.ts, src/security/permission-sets.ts, src/security/sharing-rules.ts (new) · src/security/index.ts (barrel) · src/actions/catalog.actions.ts, src/actions/task.actions.ts (requiredPermissions keys only — no imports added, no handler bodies, no register-handlers.ts) · docs/deployment/security.md (new) · test/security.test.ts (new). objectstack.config.ts untouched.

---

Generated by Claude Code

[os-warren]

Part of #8
Fixes#30
Fixes#40

Three flat positions, three composed permission sets, capability gates on all five actions, and a deployment page that says what a rollout still has to do by hand.

The first line is Part of, not a closing keyword, and that is deliberate: two things the card specifies are not shippable on protocol 17.2.0 (below), and one of them needs a maintainer ruling recorded on #8 before that card is closed. #30 and #40 are complete and do close here.

Gates, all four green at 8d5cc29 — the tip of this branch, re-run on the restored tree after the ablations below:

gate	verdict line
pnpm validate	✓ Validation passed (330ms) · Security: 3 Positions 3 Permissions
pnpm typecheck	tsc --noEmit, exit 0, no output
pnpm test	Test Files 9 passed (9) · Tests 334 passed (334)
pnpm build	✓ Build complete (603ms)

---

The model

	duly_member	duly_manager	duly_admin
duly_task	create/read/edit · read own · write own	inherited	inherited
duly_duty	create/read · read own · write own	inherited	+edit · read org · write own
duly_log_entry	full control · read own · write own	inherited	inherited
duly_catalog_item	read	inherited	+create/edit/delete · write org
duly_assignment	read · read own	+create/edit · write own	inherited
Capabilities	duly.task.update_status	inherited	+duly.catalog.apply, duly.catalog.sync

"Inherited" is literal, not descriptive: MANAGER_OBJECTS spreads MEMBER_OBJECTS, ADMIN_OBJECTS spreads MANAGER_OBJECTS, and the test asserts every non-overridden entry is the same object. A grant is written once, so nobody can widen the work log for managers by editing a copy — there is no copy.

Each set is self-contained, so binding one set to one position is a correct deployment.

The two invariants, enforced rather than intended

The work log is closed to everyone but its owner, administrators included. No depth scope, no viewAllRecords, no sharing rule, walked across all three sets. No set carries a write scope wider than own on duly_task / duly_duty — every widening in this PR is on the read axis, and the test also proves that the only write bit the manager set adds anywhere is duly_assignment.

duly_admin.duly_duty is the one entry worth reading twice: it gets allowEditand keeps writeScope: 'own'. That is the card's acceptance line beating its permission-set line, and the bit is not inert — an administrator can correct their own duties, which a member cannot. The org-wide correction path is deliberately elsewhere: duly_catalog_sync, which is bounded to cadence fields, capability-gated, and reportable. A correction typed into someone else's duty record is none of those.

Deliberate non-obvious calls

• duly_catalog_item gets writeScope: 'org' on the admin set, and no readScope anywhere.public_read is read-open but write-owned — buildWriteFilter applies to private and public_read alike — so without the write depth an administrator could only edit catalog items they personally created. Conversely buildReadFilter returns null before depth is consulted for any non-private object, so a readScope there would be inert and is not authored.
• duly.catalog.apply and duly.catalog.sync are two capabilities, both granted to duly_admin, answering the question Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 raises. Nothing is harder to deploy, but a customer who wants an onboarding administrator who cannot rewrite the org's cadence can now express it.
• No isDefault, no fields block, no adminScope, no '*' wildcard.isDefault is not available: the ADR-0090 D5/D9 anchor tier refuses any set carrying systemPermissions or a delete bit, and duly_member carries both. FLS would only restate readonly flags the objects already enforce.
• The action files hard-code their capability strings rather than importing the constants, to keep to the requiredPermissions-only file surface. The link is held by two independent checks instead: the capability-reference-unknown author-time rule, and a test asserting every required capability is granted by a set in this package.

---

⛔ Two things the card asks for that this platform version cannot express

Both fail closed. Neither is approximated.

1. No sharing rule can name the record owner's manager — objectstack#14103

ShareRecipientType is five static principals, and plugin-sharing's expandRecipient resolves rule.recipient_id once per rule, never per matched record. The predicate half (record.visibility == "manager") lowers fine; the recipient half has nothing to resolve through.

The nearest expressible recipient, position: 'duly_manager', would hand every marked entry to every manager in the tenant — the disclosure the invariant exists to prevent — so it is not authored as a stopgap.

RLS is not a way round it either, despite sharing-rule-runtime-variable-condition's hint recommending exactly that. On a private object the layers are AND-composed, not OR-composed:

// plugin-security getReadFilterreturnandComposeLayers(andComposeLayers(filter,cbpFilter),sharingFilter)??void0;

and buildReadFilter returns ownerMatch (OR'd only with the caller's own sys_record_share grants). An RLS policy can therefore only narrow a private object's readable set. Widening has two doors — the ADR-0057 depth scopes and a sys_record_share row — and both are shut for a record-relative recipient.

duly_assignment hits the same wall: "readable by the people it is addressed to" is the same shape. Assignees still see their own fanned-out duly_task, which is the row they work.

src/security/sharing-rules.ts is an empty array with the whole measurement on it. The file exists precisely so the next author does not rediscover the wall and author their way past it with the recipient that lints clean.

2. A hierarchy read depth cannot be authored here — tracked as #46

duly_manager on duly_task / duly_duty and duly_admin on duly_task should read unit_and_below. They ship at own.

defineStack's validateHierarchyScopeCapability is a hard error on unit / unit_and_below / own_and_reports unless the stack declares requires: ['hierarchy-security']. It runs inside defineStack(), so it takes validate, build and the three tests that import the config. This is not the "silent fallback to owner-only" AGENTS.md rule 7 describes — nothing silent happens; the config will not load.

The premise blocking the prescribed fix is measurably false. Rule 7, objectstack.config.ts, the card and its PM comment all state that declaring hierarchy-security "would fail an open-edition boot". Measured on this checkout with the capability declared, unit_and_below restored, and @objectstack/security-enterprise not installed:

gate	exit	result
pnpm validate	0	✓ Validation passed + one provider warning
pnpm test	0	Tests 278 passed (278), kernel logged ✅ Bootstrap complete
pnpm build	0	✓ Build complete

So the one-line fix appears to work. It is not taken here: objectstack.config.ts is outside this card's file surface, it is the collision file AGENTS.md rule 2 reserves, and overturning a rule written in four places belongs on its own change. #46 carries the full measurement and its bounds.

own is also exactly what an open-edition runtime would have resolvedunit_and_below to, so nothing about today's behaviour differs — only the honesty of the declaration. The three grants are recorded in HIERARCHY_SCOPES_DEFERRED and pinned in both directions: widen a grant without deleting its row and the test fails; delete a row without widening the grant and the test fails.

---

Ablations — the new tests do fail when they should

Both run on the committed tree with a restoring trap, mutation confirmed on disk before the run and absence confirmed after. Predicted direction for both was red, and both went red in exactly the named places.

Widen duly_log_entry to readScope: 'org' on the manager set (org chosen over unit_and_below on purpose — it is authorable, so the only red can come from the guard rather than from defineStack refusing to load):

injected marker count: 1 → Tests 4 failed | 330 passed
FAIL duly_log_entry must not leak > every set — admin included — reads own and only own
FAIL manager and admin inherit rather than restate > every non-overridden manager entry …
FAIL permission sets … > duly_manager · duly_log_entry declares readScope=own writeScope=own
FAIL permission sets … > duly_admin · duly_log_entry declares readScope=own writeScope=own
restored marker count: 0

Delete requiredPermissions from duly_catalog_apply:

Tests 2 failed | 332 passed
FAIL action capability gates > duly_catalog_apply requires duly.catalog.apply
FAIL action capability gates > every action this app ships declares a gate — none left open

One honest note on the second: the shell marker I printed for it was mis-anchored — it grepped the bare capability string, which also appears three times in prose, so it read 3 where I had written "want 0". The disk-landing proof there is the Python assert count == 1 on the exact requiredPermissions: line before the replace, plus the targeted red. The first ablation's markers were clean (1 → 0).

The own_and_reports / unit_and_below half of the hierarchy finding was measured the same way, against objectstack.config.ts under a trap; that file is untouched in this diff (git status clean, verified after each leg).

---

Also filed

• Sharing rules cannot name a RECORD-RELATIVE recipient (the owner's manager; the value of a user field on the matched record), and no other declarative surface can widen a private object either objectstack#14103 — record-relative sharing recipients. Unassigned.
• AGENTS.md rule 7 and objectstack.config.ts claim declaring hierarchy-security fails an open-edition boot — measured false, and the claim is what blocks the manager read scopes #46 — the falsified hierarchy-security premise in AGENTS.md rule 7 and objectstack.config.ts. Unassigned. Note docs/product/data-model.md's "Security posture" section carries the same claim and is outside this card's file surface, so it is left for that issue.
• A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50 — duly_duty.source defaults to catalog, so a hand-created self-declared duty is born scoreable. Found because the member set grants "create own duty, source: 'self'". Unassigned.

Files

src/security/positions.ts, src/security/permission-sets.ts, src/security/sharing-rules.ts (new) · src/security/index.ts (barrel) · src/actions/catalog.actions.ts, src/actions/task.actions.ts (requiredPermissions keys only — no imports added, no handler bodies, no register-handlers.ts) · docs/deployment/security.md (new) · test/security.test.ts (new). objectstack.config.ts untouched.

---

Generated by Claude Code

[os-warren]

Part of #8
Fixes#30
Fixes#40

Three flat positions, three composed permission sets, capability gates on all five actions, and a deployment page that says what a rollout still has to do by hand.

The first line is Part of, not a closing keyword, and that is deliberate: two things the card specifies are not shippable on protocol 17.2.0 (below), and one of them needs a maintainer ruling recorded on #8 before that card is closed. #30 and #40 are complete and do close here.

Gates, all four green at 8d5cc29 — the tip of this branch, re-run on the restored tree after the ablations below:

gate	verdict line
pnpm validate	✓ Validation passed (330ms) · Security: 3 Positions 3 Permissions
pnpm typecheck	tsc --noEmit, exit 0, no output
pnpm test	Test Files 9 passed (9) · Tests 334 passed (334)
pnpm build	✓ Build complete (603ms)

---

The model

	duly_member	duly_manager	duly_admin
duly_task	create/read/edit · read own · write own	inherited	inherited
duly_duty	create/read · read own · write own	inherited	+edit · read org · write own
duly_log_entry	full control · read own · write own	inherited	inherited
duly_catalog_item	read	inherited	+create/edit/delete · write org
duly_assignment	read · read own	+create/edit · write own	inherited
Capabilities	duly.task.update_status	inherited	+duly.catalog.apply, duly.catalog.sync

"Inherited" is literal, not descriptive: MANAGER_OBJECTS spreads MEMBER_OBJECTS, ADMIN_OBJECTS spreads MANAGER_OBJECTS, and the test asserts every non-overridden entry is the same object. A grant is written once, so nobody can widen the work log for managers by editing a copy — there is no copy.

Each set is self-contained, so binding one set to one position is a correct deployment.

The two invariants, enforced rather than intended

The work log is closed to everyone but its owner, administrators included. No depth scope, no viewAllRecords, no sharing rule, walked across all three sets. No set carries a write scope wider than own on duly_task / duly_duty — every widening in this PR is on the read axis, and the test also proves that the only write bit the manager set adds anywhere is duly_assignment.

duly_admin.duly_duty is the one entry worth reading twice: it gets allowEditand keeps writeScope: 'own'. That is the card's acceptance line beating its permission-set line, and the bit is not inert — an administrator can correct their own duties, which a member cannot. The org-wide correction path is deliberately elsewhere: duly_catalog_sync, which is bounded to cadence fields, capability-gated, and reportable. A correction typed into someone else's duty record is none of those.

Deliberate non-obvious calls

• duly_catalog_item gets writeScope: 'org' on the admin set, and no readScope anywhere.public_read is read-open but write-owned — buildWriteFilter applies to private and public_read alike — so without the write depth an administrator could only edit catalog items they personally created. Conversely buildReadFilter returns null before depth is consulted for any non-private object, so a readScope there would be inert and is not authored.
• duly.catalog.apply and duly.catalog.sync are two capabilities, both granted to duly_admin, answering the question Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 raises. Nothing is harder to deploy, but a customer who wants an onboarding administrator who cannot rewrite the org's cadence can now express it.
• No isDefault, no fields block, no adminScope, no '*' wildcard.isDefault is not available: the ADR-0090 D5/D9 anchor tier refuses any set carrying systemPermissions or a delete bit, and duly_member carries both. FLS would only restate readonly flags the objects already enforce.
• The action files hard-code their capability strings rather than importing the constants, to keep to the requiredPermissions-only file surface. The link is held by two independent checks instead: the capability-reference-unknown author-time rule, and a test asserting every required capability is granted by a set in this package.

---

⛔ Two things the card asks for that this platform version cannot express

Both fail closed. Neither is approximated.

1. No sharing rule can name the record owner's manager — objectstack#14103

ShareRecipientType is five static principals, and plugin-sharing's expandRecipient resolves rule.recipient_id once per rule, never per matched record. The predicate half (record.visibility == "manager") lowers fine; the recipient half has nothing to resolve through.

The nearest expressible recipient, position: 'duly_manager', would hand every marked entry to every manager in the tenant — the disclosure the invariant exists to prevent — so it is not authored as a stopgap.

RLS is not a way round it either, despite sharing-rule-runtime-variable-condition's hint recommending exactly that. On a private object the layers are AND-composed, not OR-composed:

// plugin-security getReadFilterreturnandComposeLayers(andComposeLayers(filter,cbpFilter),sharingFilter)??void0;

and buildReadFilter returns ownerMatch (OR'd only with the caller's own sys_record_share grants). An RLS policy can therefore only narrow a private object's readable set. Widening has two doors — the ADR-0057 depth scopes and a sys_record_share row — and both are shut for a record-relative recipient.

duly_assignment hits the same wall: "readable by the people it is addressed to" is the same shape. Assignees still see their own fanned-out duly_task, which is the row they work.

src/security/sharing-rules.ts is an empty array with the whole measurement on it. The file exists precisely so the next author does not rediscover the wall and author their way past it with the recipient that lints clean.

2. A hierarchy read depth cannot be authored here — tracked as #46

duly_manager on duly_task / duly_duty and duly_admin on duly_task should read unit_and_below. They ship at own.

defineStack's validateHierarchyScopeCapability is a hard error on unit / unit_and_below / own_and_reports unless the stack declares requires: ['hierarchy-security']. It runs inside defineStack(), so it takes validate, build and the three tests that import the config. This is not the "silent fallback to owner-only" AGENTS.md rule 7 describes — nothing silent happens; the config will not load.

The premise blocking the prescribed fix is measurably false. Rule 7, objectstack.config.ts, the card and its PM comment all state that declaring hierarchy-security "would fail an open-edition boot". Measured on this checkout with the capability declared, unit_and_below restored, and @objectstack/security-enterprise not installed:

gate	exit	result
pnpm validate	0	✓ Validation passed + one provider warning
pnpm test	0	Tests 278 passed (278), kernel logged ✅ Bootstrap complete
pnpm build	0	✓ Build complete

So the one-line fix appears to work. It is not taken here: objectstack.config.ts is outside this card's file surface, it is the collision file AGENTS.md rule 2 reserves, and overturning a rule written in four places belongs on its own change. #46 carries the full measurement and its bounds.

own is also exactly what an open-edition runtime would have resolvedunit_and_below to, so nothing about today's behaviour differs — only the honesty of the declaration. The three grants are recorded in HIERARCHY_SCOPES_DEFERRED and pinned in both directions: widen a grant without deleting its row and the test fails; delete a row without widening the grant and the test fails.

---

Ablations — the new tests do fail when they should

Both run on the committed tree with a restoring trap, mutation confirmed on disk before the run and absence confirmed after. Predicted direction for both was red, and both went red in exactly the named places.

Widen duly_log_entry to readScope: 'org' on the manager set (org chosen over unit_and_below on purpose — it is authorable, so the only red can come from the guard rather than from defineStack refusing to load):

injected marker count: 1 → Tests 4 failed | 330 passed
FAIL duly_log_entry must not leak > every set — admin included — reads own and only own
FAIL manager and admin inherit rather than restate > every non-overridden manager entry …
FAIL permission sets … > duly_manager · duly_log_entry declares readScope=own writeScope=own
FAIL permission sets … > duly_admin · duly_log_entry declares readScope=own writeScope=own
restored marker count: 0

Delete requiredPermissions from duly_catalog_apply:

Tests 2 failed | 332 passed
FAIL action capability gates > duly_catalog_apply requires duly.catalog.apply
FAIL action capability gates > every action this app ships declares a gate — none left open

One honest note on the second: the shell marker I printed for it was mis-anchored — it grepped the bare capability string, which also appears three times in prose, so it read 3 where I had written "want 0". The disk-landing proof there is the Python assert count == 1 on the exact requiredPermissions: line before the replace, plus the targeted red. The first ablation's markers were clean (1 → 0).

The own_and_reports / unit_and_below half of the hierarchy finding was measured the same way, against objectstack.config.ts under a trap; that file is untouched in this diff (git status clean, verified after each leg).

---

Also filed

• Sharing rules cannot name a RECORD-RELATIVE recipient (the owner's manager; the value of a user field on the matched record), and no other declarative surface can widen a private object either objectstack#14103 — record-relative sharing recipients. Unassigned.
• AGENTS.md rule 7 and objectstack.config.ts claim declaring hierarchy-security fails an open-edition boot — measured false, and the claim is what blocks the manager read scopes #46 — the falsified hierarchy-security premise in AGENTS.md rule 7 and objectstack.config.ts. Unassigned. Note docs/product/data-model.md's "Security posture" section carries the same claim and is outside this card's file surface, so it is left for that issue.
• A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50 — duly_duty.source defaults to catalog, so a hand-created self-declared duty is born scoreable. Found because the member set grants "create own duty, source: 'self'". Unassigned.

Files

src/security/positions.ts, src/security/permission-sets.ts, src/security/sharing-rules.ts (new) · src/security/index.ts (barrel) · src/actions/catalog.actions.ts, src/actions/task.actions.ts (requiredPermissions keys only — no imports added, no handler bodies, no register-handlers.ts) · docs/deployment/security.md (new) · test/security.test.ts (new). objectstack.config.ts untouched.

---

Generated by Claude Code

[os-warren]

Part of #8
Fixes#30
Fixes#40

Three flat positions, three composed permission sets, capability gates on all five actions, and a deployment page that says what a rollout still has to do by hand.

The first line is Part of, not a closing keyword, and that is deliberate: two things the card specifies are not shippable on protocol 17.2.0 (below), and one of them needs a maintainer ruling recorded on #8 before that card is closed. #30 and #40 are complete and do close here.

Gates, all four green at 8d5cc29 — the tip of this branch, re-run on the restored tree after the ablations below:

gate	verdict line
pnpm validate	✓ Validation passed (330ms) · Security: 3 Positions 3 Permissions
pnpm typecheck	tsc --noEmit, exit 0, no output
pnpm test	Test Files 9 passed (9) · Tests 334 passed (334)
pnpm build	✓ Build complete (603ms)

---

The model

	duly_member	duly_manager	duly_admin
duly_task	create/read/edit · read own · write own	inherited	inherited
duly_duty	create/read · read own · write own	inherited	+edit · read org · write own
duly_log_entry	full control · read own · write own	inherited	inherited
duly_catalog_item	read	inherited	+create/edit/delete · write org
duly_assignment	read · read own	+create/edit · write own	inherited
Capabilities	duly.task.update_status	inherited	+duly.catalog.apply, duly.catalog.sync

"Inherited" is literal, not descriptive: MANAGER_OBJECTS spreads MEMBER_OBJECTS, ADMIN_OBJECTS spreads MANAGER_OBJECTS, and the test asserts every non-overridden entry is the same object. A grant is written once, so nobody can widen the work log for managers by editing a copy — there is no copy.

Each set is self-contained, so binding one set to one position is a correct deployment.

The two invariants, enforced rather than intended

The work log is closed to everyone but its owner, administrators included. No depth scope, no viewAllRecords, no sharing rule, walked across all three sets. No set carries a write scope wider than own on duly_task / duly_duty — every widening in this PR is on the read axis, and the test also proves that the only write bit the manager set adds anywhere is duly_assignment.

duly_admin.duly_duty is the one entry worth reading twice: it gets allowEditand keeps writeScope: 'own'. That is the card's acceptance line beating its permission-set line, and the bit is not inert — an administrator can correct their own duties, which a member cannot. The org-wide correction path is deliberately elsewhere: duly_catalog_sync, which is bounded to cadence fields, capability-gated, and reportable. A correction typed into someone else's duty record is none of those.

Deliberate non-obvious calls

• duly_catalog_item gets writeScope: 'org' on the admin set, and no readScope anywhere.public_read is read-open but write-owned — buildWriteFilter applies to private and public_read alike — so without the write depth an administrator could only edit catalog items they personally created. Conversely buildReadFilter returns null before depth is consulted for any non-private object, so a readScope there would be inert and is not authored.
• duly.catalog.apply and duly.catalog.sync are two capabilities, both granted to duly_admin, answering the question Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 raises. Nothing is harder to deploy, but a customer who wants an onboarding administrator who cannot rewrite the org's cadence can now express it.
• No isDefault, no fields block, no adminScope, no '*' wildcard.isDefault is not available: the ADR-0090 D5/D9 anchor tier refuses any set carrying systemPermissions or a delete bit, and duly_member carries both. FLS would only restate readonly flags the objects already enforce.
• The action files hard-code their capability strings rather than importing the constants, to keep to the requiredPermissions-only file surface. The link is held by two independent checks instead: the capability-reference-unknown author-time rule, and a test asserting every required capability is granted by a set in this package.

---

⛔ Two things the card asks for that this platform version cannot express

Both fail closed. Neither is approximated.

1. No sharing rule can name the record owner's manager — objectstack#14103

ShareRecipientType is five static principals, and plugin-sharing's expandRecipient resolves rule.recipient_id once per rule, never per matched record. The predicate half (record.visibility == "manager") lowers fine; the recipient half has nothing to resolve through.

The nearest expressible recipient, position: 'duly_manager', would hand every marked entry to every manager in the tenant — the disclosure the invariant exists to prevent — so it is not authored as a stopgap.

RLS is not a way round it either, despite sharing-rule-runtime-variable-condition's hint recommending exactly that. On a private object the layers are AND-composed, not OR-composed:

// plugin-security getReadFilterreturnandComposeLayers(andComposeLayers(filter,cbpFilter),sharingFilter)??void0;

and buildReadFilter returns ownerMatch (OR'd only with the caller's own sys_record_share grants). An RLS policy can therefore only narrow a private object's readable set. Widening has two doors — the ADR-0057 depth scopes and a sys_record_share row — and both are shut for a record-relative recipient.

duly_assignment hits the same wall: "readable by the people it is addressed to" is the same shape. Assignees still see their own fanned-out duly_task, which is the row they work.

src/security/sharing-rules.ts is an empty array with the whole measurement on it. The file exists precisely so the next author does not rediscover the wall and author their way past it with the recipient that lints clean.

2. A hierarchy read depth cannot be authored here — tracked as #46

duly_manager on duly_task / duly_duty and duly_admin on duly_task should read unit_and_below. They ship at own.

defineStack's validateHierarchyScopeCapability is a hard error on unit / unit_and_below / own_and_reports unless the stack declares requires: ['hierarchy-security']. It runs inside defineStack(), so it takes validate, build and the three tests that import the config. This is not the "silent fallback to owner-only" AGENTS.md rule 7 describes — nothing silent happens; the config will not load.

The premise blocking the prescribed fix is measurably false. Rule 7, objectstack.config.ts, the card and its PM comment all state that declaring hierarchy-security "would fail an open-edition boot". Measured on this checkout with the capability declared, unit_and_below restored, and @objectstack/security-enterprise not installed:

gate	exit	result
pnpm validate	0	✓ Validation passed + one provider warning
pnpm test	0	Tests 278 passed (278), kernel logged ✅ Bootstrap complete
pnpm build	0	✓ Build complete

So the one-line fix appears to work. It is not taken here: objectstack.config.ts is outside this card's file surface, it is the collision file AGENTS.md rule 2 reserves, and overturning a rule written in four places belongs on its own change. #46 carries the full measurement and its bounds.

own is also exactly what an open-edition runtime would have resolvedunit_and_below to, so nothing about today's behaviour differs — only the honesty of the declaration. The three grants are recorded in HIERARCHY_SCOPES_DEFERRED and pinned in both directions: widen a grant without deleting its row and the test fails; delete a row without widening the grant and the test fails.

---

Ablations — the new tests do fail when they should

Both run on the committed tree with a restoring trap, mutation confirmed on disk before the run and absence confirmed after. Predicted direction for both was red, and both went red in exactly the named places.

Widen duly_log_entry to readScope: 'org' on the manager set (org chosen over unit_and_below on purpose — it is authorable, so the only red can come from the guard rather than from defineStack refusing to load):

injected marker count: 1 → Tests 4 failed | 330 passed
FAIL duly_log_entry must not leak > every set — admin included — reads own and only own
FAIL manager and admin inherit rather than restate > every non-overridden manager entry …
FAIL permission sets … > duly_manager · duly_log_entry declares readScope=own writeScope=own
FAIL permission sets … > duly_admin · duly_log_entry declares readScope=own writeScope=own
restored marker count: 0

Delete requiredPermissions from duly_catalog_apply:

Tests 2 failed | 332 passed
FAIL action capability gates > duly_catalog_apply requires duly.catalog.apply
FAIL action capability gates > every action this app ships declares a gate — none left open

One honest note on the second: the shell marker I printed for it was mis-anchored — it grepped the bare capability string, which also appears three times in prose, so it read 3 where I had written "want 0". The disk-landing proof there is the Python assert count == 1 on the exact requiredPermissions: line before the replace, plus the targeted red. The first ablation's markers were clean (1 → 0).

The own_and_reports / unit_and_below half of the hierarchy finding was measured the same way, against objectstack.config.ts under a trap; that file is untouched in this diff (git status clean, verified after each leg).

---

Also filed

• Sharing rules cannot name a RECORD-RELATIVE recipient (the owner's manager; the value of a user field on the matched record), and no other declarative surface can widen a private object either objectstack#14103 — record-relative sharing recipients. Unassigned.
• AGENTS.md rule 7 and objectstack.config.ts claim declaring hierarchy-security fails an open-edition boot — measured false, and the claim is what blocks the manager read scopes #46 — the falsified hierarchy-security premise in AGENTS.md rule 7 and objectstack.config.ts. Unassigned. Note docs/product/data-model.md's "Security posture" section carries the same claim and is outside this card's file surface, so it is left for that issue.
• A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50 — duly_duty.source defaults to catalog, so a hand-created self-declared duty is born scoreable. Found because the member set grants "create own duty, source: 'self'". Unassigned.

Files

src/security/positions.ts, src/security/permission-sets.ts, src/security/sharing-rules.ts (new) · src/security/index.ts (barrel) · src/actions/catalog.actions.ts, src/actions/task.actions.ts (requiredPermissions keys only — no imports added, no handler bodies, no register-handlers.ts) · docs/deployment/security.md (new) · test/security.test.ts (new). objectstack.config.ts untouched.

---

Generated by Claude Code

[os-warren]

Part of #8
Fixes#30
Fixes#40

Three flat positions, three composed permission sets, capability gates on all five actions, and a deployment page that says what a rollout still has to do by hand.

The first line is Part of, not a closing keyword, and that is deliberate: two things the card specifies are not shippable on protocol 17.2.0 (below), and one of them needs a maintainer ruling recorded on #8 before that card is closed. #30 and #40 are complete and do close here.

Gates, all four green at 8d5cc29 — the tip of this branch, re-run on the restored tree after the ablations below:

gate	verdict line
pnpm validate	✓ Validation passed (330ms) · Security: 3 Positions 3 Permissions
pnpm typecheck	tsc --noEmit, exit 0, no output
pnpm test	Test Files 9 passed (9) · Tests 334 passed (334)
pnpm build	✓ Build complete (603ms)

---

The model

	duly_member	duly_manager	duly_admin
duly_task	create/read/edit · read own · write own	inherited	inherited
duly_duty	create/read · read own · write own	inherited	+edit · read org · write own
duly_log_entry	full control · read own · write own	inherited	inherited
duly_catalog_item	read	inherited	+create/edit/delete · write org
duly_assignment	read · read own	+create/edit · write own	inherited
Capabilities	duly.task.update_status	inherited	+duly.catalog.apply, duly.catalog.sync

"Inherited" is literal, not descriptive: MANAGER_OBJECTS spreads MEMBER_OBJECTS, ADMIN_OBJECTS spreads MANAGER_OBJECTS, and the test asserts every non-overridden entry is the same object. A grant is written once, so nobody can widen the work log for managers by editing a copy — there is no copy.

Each set is self-contained, so binding one set to one position is a correct deployment.

The two invariants, enforced rather than intended

The work log is closed to everyone but its owner, administrators included. No depth scope, no viewAllRecords, no sharing rule, walked across all three sets. No set carries a write scope wider than own on duly_task / duly_duty — every widening in this PR is on the read axis, and the test also proves that the only write bit the manager set adds anywhere is duly_assignment.

duly_admin.duly_duty is the one entry worth reading twice: it gets allowEditand keeps writeScope: 'own'. That is the card's acceptance line beating its permission-set line, and the bit is not inert — an administrator can correct their own duties, which a member cannot. The org-wide correction path is deliberately elsewhere: duly_catalog_sync, which is bounded to cadence fields, capability-gated, and reportable. A correction typed into someone else's duty record is none of those.

Deliberate non-obvious calls

• duly_catalog_item gets writeScope: 'org' on the admin set, and no readScope anywhere.public_read is read-open but write-owned — buildWriteFilter applies to private and public_read alike — so without the write depth an administrator could only edit catalog items they personally created. Conversely buildReadFilter returns null before depth is consulted for any non-private object, so a readScope there would be inert and is not authored.
• duly.catalog.apply and duly.catalog.sync are two capabilities, both granted to duly_admin, answering the question Gate the catalog actions with requiredPermissions — duly_catalog_apply is currently ungated #30 raises. Nothing is harder to deploy, but a customer who wants an onboarding administrator who cannot rewrite the org's cadence can now express it.
• No isDefault, no fields block, no adminScope, no '*' wildcard.isDefault is not available: the ADR-0090 D5/D9 anchor tier refuses any set carrying systemPermissions or a delete bit, and duly_member carries both. FLS would only restate readonly flags the objects already enforce.
• The action files hard-code their capability strings rather than importing the constants, to keep to the requiredPermissions-only file surface. The link is held by two independent checks instead: the capability-reference-unknown author-time rule, and a test asserting every required capability is granted by a set in this package.

---

⛔ Two things the card asks for that this platform version cannot express

Both fail closed. Neither is approximated.

1. No sharing rule can name the record owner's manager — objectstack#14103

ShareRecipientType is five static principals, and plugin-sharing's expandRecipient resolves rule.recipient_id once per rule, never per matched record. The predicate half (record.visibility == "manager") lowers fine; the recipient half has nothing to resolve through.

The nearest expressible recipient, position: 'duly_manager', would hand every marked entry to every manager in the tenant — the disclosure the invariant exists to prevent — so it is not authored as a stopgap.

RLS is not a way round it either, despite sharing-rule-runtime-variable-condition's hint recommending exactly that. On a private object the layers are AND-composed, not OR-composed:

// plugin-security getReadFilterreturnandComposeLayers(andComposeLayers(filter,cbpFilter),sharingFilter)??void0;

and buildReadFilter returns ownerMatch (OR'd only with the caller's own sys_record_share grants). An RLS policy can therefore only narrow a private object's readable set. Widening has two doors — the ADR-0057 depth scopes and a sys_record_share row — and both are shut for a record-relative recipient.

duly_assignment hits the same wall: "readable by the people it is addressed to" is the same shape. Assignees still see their own fanned-out duly_task, which is the row they work.

src/security/sharing-rules.ts is an empty array with the whole measurement on it. The file exists precisely so the next author does not rediscover the wall and author their way past it with the recipient that lints clean.

2. A hierarchy read depth cannot be authored here — tracked as #46

duly_manager on duly_task / duly_duty and duly_admin on duly_task should read unit_and_below. They ship at own.

defineStack's validateHierarchyScopeCapability is a hard error on unit / unit_and_below / own_and_reports unless the stack declares requires: ['hierarchy-security']. It runs inside defineStack(), so it takes validate, build and the three tests that import the config. This is not the "silent fallback to owner-only" AGENTS.md rule 7 describes — nothing silent happens; the config will not load.

The premise blocking the prescribed fix is measurably false. Rule 7, objectstack.config.ts, the card and its PM comment all state that declaring hierarchy-security "would fail an open-edition boot". Measured on this checkout with the capability declared, unit_and_below restored, and @objectstack/security-enterprise not installed:

gate	exit	result
pnpm validate	0	✓ Validation passed + one provider warning
pnpm test	0	Tests 278 passed (278), kernel logged ✅ Bootstrap complete
pnpm build	0	✓ Build complete

So the one-line fix appears to work. It is not taken here: objectstack.config.ts is outside this card's file surface, it is the collision file AGENTS.md rule 2 reserves, and overturning a rule written in four places belongs on its own change. #46 carries the full measurement and its bounds.

own is also exactly what an open-edition runtime would have resolvedunit_and_below to, so nothing about today's behaviour differs — only the honesty of the declaration. The three grants are recorded in HIERARCHY_SCOPES_DEFERRED and pinned in both directions: widen a grant without deleting its row and the test fails; delete a row without widening the grant and the test fails.

---

Ablations — the new tests do fail when they should

Both run on the committed tree with a restoring trap, mutation confirmed on disk before the run and absence confirmed after. Predicted direction for both was red, and both went red in exactly the named places.

Widen duly_log_entry to readScope: 'org' on the manager set (org chosen over unit_and_below on purpose — it is authorable, so the only red can come from the guard rather than from defineStack refusing to load):

injected marker count: 1 → Tests 4 failed | 330 passed
FAIL duly_log_entry must not leak > every set — admin included — reads own and only own
FAIL manager and admin inherit rather than restate > every non-overridden manager entry …
FAIL permission sets … > duly_manager · duly_log_entry declares readScope=own writeScope=own
FAIL permission sets … > duly_admin · duly_log_entry declares readScope=own writeScope=own
restored marker count: 0

Delete requiredPermissions from duly_catalog_apply:

Tests 2 failed | 332 passed
FAIL action capability gates > duly_catalog_apply requires duly.catalog.apply
FAIL action capability gates > every action this app ships declares a gate — none left open

One honest note on the second: the shell marker I printed for it was mis-anchored — it grepped the bare capability string, which also appears three times in prose, so it read 3 where I had written "want 0". The disk-landing proof there is the Python assert count == 1 on the exact requiredPermissions: line before the replace, plus the targeted red. The first ablation's markers were clean (1 → 0).

The own_and_reports / unit_and_below half of the hierarchy finding was measured the same way, against objectstack.config.ts under a trap; that file is untouched in this diff (git status clean, verified after each leg).

---

Also filed

• Sharing rules cannot name a RECORD-RELATIVE recipient (the owner's manager; the value of a user field on the matched record), and no other declarative surface can widen a private object either objectstack#14103 — record-relative sharing recipients. Unassigned.
• AGENTS.md rule 7 and objectstack.config.ts claim declaring hierarchy-security fails an open-edition boot — measured false, and the claim is what blocks the manager read scopes #46 — the falsified hierarchy-security premise in AGENTS.md rule 7 and objectstack.config.ts. Unassigned. Note docs/product/data-model.md's "Security posture" section carries the same claim and is outside this card's file surface, so it is left for that issue.
• A hand-created duty defaults to source: 'catalog', so a self-declared duty is born scoreable #50 — duly_duty.source defaults to catalog, so a hand-created self-declared duty is born scoreable. Found because the member set grants "create own duty, source: 'self'". Unassigned.

Files

src/security/positions.ts, src/security/permission-sets.ts, src/security/sharing-rules.ts (new) · src/security/index.ts (barrel) · src/actions/catalog.actions.ts, src/actions/task.actions.ts (requiredPermissions keys only — no imports added, no handler bodies, no register-handlers.ts) · docs/deployment/security.md (new) · test/security.test.ts (new). objectstack.config.ts untouched.

---

Generated by Claude Code