Record who can customize a view: no Duly permission set can

[os-warren]

Fixes#84

#84 was blocked on one question: the org-wide view overlay was measured as the dev admin, and the severity turned entirely on whether an ordinary member could do the same thing. #73 (pnpm demo) unblocked it. It is measured now, and the answer is no — so this is the card's "note, not p0" branch, and there is no security change.

What was measured

Against a live pnpm demo on @objectstack/rest 17.2.0. Three accounts were created by self-registration (POST /api/v1/auth/sign-up/email, which yields positions: ["user","org_member"], isPlatformAdmin: false) and each bound to exactly one Duly permission set through sys_user_permission_set — nothing beyond what src/security/permission-sets.ts grants.

The binding was verified live rather than assumed: a bound duly_member reads duly_task200, an unbound self-registered account reads it 403. So the sets really do resolve for these callers.

Each then issued the request the grid issues — the declared duly_task.default config with sort swapped to status asc:

Caller	PUT /api/v1/meta/view/duly_task.default
anonymous	401 UNAUTHENTICATED
duly_member	403 FORBIDDEN — Saving a metadata item requires the `manage_metadata` capability.
duly_manager	403 FORBIDDEN — same
duly_admin	403 FORBIDDEN — same
platform admin	200 — Saved customization overlay (org=org_mtik8rkleytx3x6b, state=active)

sys_metadata read total: 0 after every refused attempt.

Three things make the negative result trustworthy rather than a mis-shaped request:

• The control fires. The identical body from the platform-admin session returns 200 and lands the row finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 describes — type: view, name: duly_task.default, scope: platform, owner: null, organization_id: org_…, state: active. The 403s are a capability refusal, not a malformed payload.
• The 401/403 split. An anonymous caller gets a different code from the anonymous-deny gate, so the member's 403 proves its session resolved and was then denied on capability.
• Both doors and the reset door. The compound twin (PUT /api/v1/meta/duly_task/views/default) and DELETE /api/v1/meta/view/duly_task.default carry the identical gate — checked, because gating one door and not its twin is the usual bypass.

Also swept for a second persistence route a member might reach instead: the org-wide sys_view_definition answers 403, and the one member-writable store, sys_user_preference, requires user_id and is per-person by construction — which is the right affordance, not an org-wide overlay.

Cleanup: the control overlay was reset with DELETE, and the end state was verified — sys_metadatatotal: 0, and duly_task.default back to the shipped sort: [{"field":"due_date","order":"asc"}] with _provenance: package. The dev database lives in the task worktree and goes with it.

What this PR changes

One section in AGENTS.md. No code. It records the verdict, the table above, and how it was measured, so nobody re-derives it — plus two things a future reader would otherwise get wrong:

• Do not "harden" this by denying manage_metadata in src/security/permission-sets.ts.systemPermissions is an additive list with no deny form. The entry would not be enforcement; it would be a declared-and-unenforced key of exactly the kind ADR-0049 exists to remove, sitting in the one file whose credibility depends on every line in it being live. The card's contingent fix is not just unnecessary — it is not expressible.
• The admin-facing surprise is still real. For a caller who does hold the capability, an ordinary sort click persists an org-wide overlay carrying the entire view definition, with no save gesture and no UI indication. finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 proposed filing that at objectstack-ai/objectuiconditional on members being able to do it, so it is deliberately left unfiled here and flagged for the maintainer instead — see the report on finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84.

Gates

All four green on 67c670e, the head of this branch, with a clean tree:

pnpm validate exit 0 ✓ Validation passed (368ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 25 passed (25) · Tests 641 passed (641)
pnpm build exit 0 ✓ Build complete (746ms)

validate's one warning is the hierarchy-security capability-provider notice that AGENTS.md documents as this repo's expected state.

No changeset — this repo has no changeset mechanism.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The answer is "note branch", and the reason not to write the fix is better than the fix.

Gates on the head merged with current main:validate 0, typecheck 0, test 0 (Test Files 26, Tests 662), build 0.

The question this card was blocked on is answered, with controls rather than a single reading:

control	result	what it rules out
same body, platform-admin session	200, overlay lands exactly as the card described	the 403s are not a malformed payload
anonymous	401 from a different gate	the member's 403 came after its session resolved
compound twin door + DELETE reset door	same 403	a gate on one door and not its twin — the usual bypass
sys_view_definition / sys_user_preference sweep	org-wide refused; the writable one is per-person by construction	an alternate persistence route

And the permission-set binding was verified by A/B rather than assumed — a bound duly_member reads duly_task 200, an unbound self-registered account 403 — which is the step that makes the three 403s mean "this role cannot" rather than "this account has nothing".

Declining to write the contingent fix is the right call

My card said: if members can do it, deny the capability to duly_member and duly_manager. You established they cannot, and then went one better — the fix is not expressible. systemPermissions is an additive list with no deny form, so the entry would not be enforcement, it would be a declared-and-unenforced key sitting in the one file whose entire credibility rests on every line in it being live. Writing it would have looked like hardening and been the exact defect ADR-0049 exists to remove. Putting a stop sign in AGENTS.md so the next person does not "helpfully" add it is worth more than the line itself would have been.

The section is well-judged generally: verdict, result table, method, and the boundary of what remains true. Recording how it was measured is what stops this being re-derived in three months by someone who finds the same PUT in a network log.

On your open question — file it, and I will

Your recommendation B is right and your reason for not doing it yourself is also right: I conditioned the upstream filing on the member branch, and that branch did not happen, so writing into another repository's tracker was outside what you were authorized to do. Declining on scope while saying plainly that the merit is unchanged is the correct shape for that. Consider it authorized retroactively in spirit — but it is mine to file, and I am filing it now with your result table.

The claim is smaller than the p0 this card was written against, and still real: an administrator demoing the app can freeze duly_task.default at the shipped definition by clicking a column header, and nothing tells them. A later release adding a column to that view would then be silently ignored in their org.

Cleanup verified — overlay deleted, sys_metadata back to 0, the view restored to its shipped due_date asc with its _provenance package, server killed by recorded PID, worktree removed without --force.

---

Generated by Claude Code

[os-warren]

Fixes#84

#84 was blocked on one question: the org-wide view overlay was measured as the dev admin, and the severity turned entirely on whether an ordinary member could do the same thing. #73 (pnpm demo) unblocked it. It is measured now, and the answer is no — so this is the card's "note, not p0" branch, and there is no security change.

What was measured

Against a live pnpm demo on @objectstack/rest 17.2.0. Three accounts were created by self-registration (POST /api/v1/auth/sign-up/email, which yields positions: ["user","org_member"], isPlatformAdmin: false) and each bound to exactly one Duly permission set through sys_user_permission_set — nothing beyond what src/security/permission-sets.ts grants.

The binding was verified live rather than assumed: a bound duly_member reads duly_task200, an unbound self-registered account reads it 403. So the sets really do resolve for these callers.

Each then issued the request the grid issues — the declared duly_task.default config with sort swapped to status asc:

Caller	PUT /api/v1/meta/view/duly_task.default
anonymous	401 UNAUTHENTICATED
duly_member	403 FORBIDDEN — Saving a metadata item requires the `manage_metadata` capability.
duly_manager	403 FORBIDDEN — same
duly_admin	403 FORBIDDEN — same
platform admin	200 — Saved customization overlay (org=org_mtik8rkleytx3x6b, state=active)

sys_metadata read total: 0 after every refused attempt.

Three things make the negative result trustworthy rather than a mis-shaped request:

• The control fires. The identical body from the platform-admin session returns 200 and lands the row finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 describes — type: view, name: duly_task.default, scope: platform, owner: null, organization_id: org_…, state: active. The 403s are a capability refusal, not a malformed payload.
• The 401/403 split. An anonymous caller gets a different code from the anonymous-deny gate, so the member's 403 proves its session resolved and was then denied on capability.
• Both doors and the reset door. The compound twin (PUT /api/v1/meta/duly_task/views/default) and DELETE /api/v1/meta/view/duly_task.default carry the identical gate — checked, because gating one door and not its twin is the usual bypass.

Also swept for a second persistence route a member might reach instead: the org-wide sys_view_definition answers 403, and the one member-writable store, sys_user_preference, requires user_id and is per-person by construction — which is the right affordance, not an org-wide overlay.

Cleanup: the control overlay was reset with DELETE, and the end state was verified — sys_metadatatotal: 0, and duly_task.default back to the shipped sort: [{"field":"due_date","order":"asc"}] with _provenance: package. The dev database lives in the task worktree and goes with it.

What this PR changes

One section in AGENTS.md. No code. It records the verdict, the table above, and how it was measured, so nobody re-derives it — plus two things a future reader would otherwise get wrong:

• Do not "harden" this by denying manage_metadata in src/security/permission-sets.ts.systemPermissions is an additive list with no deny form. The entry would not be enforcement; it would be a declared-and-unenforced key of exactly the kind ADR-0049 exists to remove, sitting in the one file whose credibility depends on every line in it being live. The card's contingent fix is not just unnecessary — it is not expressible.
• The admin-facing surprise is still real. For a caller who does hold the capability, an ordinary sort click persists an org-wide overlay carrying the entire view definition, with no save gesture and no UI indication. finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 proposed filing that at objectstack-ai/objectuiconditional on members being able to do it, so it is deliberately left unfiled here and flagged for the maintainer instead — see the report on finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84.

Gates

All four green on 67c670e, the head of this branch, with a clean tree:

pnpm validate exit 0 ✓ Validation passed (368ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 25 passed (25) · Tests 641 passed (641)
pnpm build exit 0 ✓ Build complete (746ms)

validate's one warning is the hierarchy-security capability-provider notice that AGENTS.md documents as this repo's expected state.

No changeset — this repo has no changeset mechanism.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The answer is "note branch", and the reason not to write the fix is better than the fix.

Gates on the head merged with current main:validate 0, typecheck 0, test 0 (Test Files 26, Tests 662), build 0.

The question this card was blocked on is answered, with controls rather than a single reading:

control	result	what it rules out
same body, platform-admin session	200, overlay lands exactly as the card described	the 403s are not a malformed payload
anonymous	401 from a different gate	the member's 403 came after its session resolved
compound twin door + DELETE reset door	same 403	a gate on one door and not its twin — the usual bypass
sys_view_definition / sys_user_preference sweep	org-wide refused; the writable one is per-person by construction	an alternate persistence route

And the permission-set binding was verified by A/B rather than assumed — a bound duly_member reads duly_task 200, an unbound self-registered account 403 — which is the step that makes the three 403s mean "this role cannot" rather than "this account has nothing".

Declining to write the contingent fix is the right call

My card said: if members can do it, deny the capability to duly_member and duly_manager. You established they cannot, and then went one better — the fix is not expressible. systemPermissions is an additive list with no deny form, so the entry would not be enforcement, it would be a declared-and-unenforced key sitting in the one file whose entire credibility rests on every line in it being live. Writing it would have looked like hardening and been the exact defect ADR-0049 exists to remove. Putting a stop sign in AGENTS.md so the next person does not "helpfully" add it is worth more than the line itself would have been.

The section is well-judged generally: verdict, result table, method, and the boundary of what remains true. Recording how it was measured is what stops this being re-derived in three months by someone who finds the same PUT in a network log.

On your open question — file it, and I will

Your recommendation B is right and your reason for not doing it yourself is also right: I conditioned the upstream filing on the member branch, and that branch did not happen, so writing into another repository's tracker was outside what you were authorized to do. Declining on scope while saying plainly that the merit is unchanged is the correct shape for that. Consider it authorized retroactively in spirit — but it is mine to file, and I am filing it now with your result table.

The claim is smaller than the p0 this card was written against, and still real: an administrator demoing the app can freeze duly_task.default at the shipped definition by clicking a column header, and nothing tells them. A later release adding a column to that view would then be silently ignored in their org.

Cleanup verified — overlay deleted, sys_metadata back to 0, the view restored to its shipped due_date asc with its _provenance package, server killed by recorded PID, worktree removed without --force.

---

Generated by Claude Code

[os-warren]

Fixes#84

#84 was blocked on one question: the org-wide view overlay was measured as the dev admin, and the severity turned entirely on whether an ordinary member could do the same thing. #73 (pnpm demo) unblocked it. It is measured now, and the answer is no — so this is the card's "note, not p0" branch, and there is no security change.

What was measured

Against a live pnpm demo on @objectstack/rest 17.2.0. Three accounts were created by self-registration (POST /api/v1/auth/sign-up/email, which yields positions: ["user","org_member"], isPlatformAdmin: false) and each bound to exactly one Duly permission set through sys_user_permission_set — nothing beyond what src/security/permission-sets.ts grants.

The binding was verified live rather than assumed: a bound duly_member reads duly_task200, an unbound self-registered account reads it 403. So the sets really do resolve for these callers.

Each then issued the request the grid issues — the declared duly_task.default config with sort swapped to status asc:

Caller	PUT /api/v1/meta/view/duly_task.default
anonymous	401 UNAUTHENTICATED
duly_member	403 FORBIDDEN — Saving a metadata item requires the `manage_metadata` capability.
duly_manager	403 FORBIDDEN — same
duly_admin	403 FORBIDDEN — same
platform admin	200 — Saved customization overlay (org=org_mtik8rkleytx3x6b, state=active)

sys_metadata read total: 0 after every refused attempt.

Three things make the negative result trustworthy rather than a mis-shaped request:

• The control fires. The identical body from the platform-admin session returns 200 and lands the row finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 describes — type: view, name: duly_task.default, scope: platform, owner: null, organization_id: org_…, state: active. The 403s are a capability refusal, not a malformed payload.
• The 401/403 split. An anonymous caller gets a different code from the anonymous-deny gate, so the member's 403 proves its session resolved and was then denied on capability.
• Both doors and the reset door. The compound twin (PUT /api/v1/meta/duly_task/views/default) and DELETE /api/v1/meta/view/duly_task.default carry the identical gate — checked, because gating one door and not its twin is the usual bypass.

Also swept for a second persistence route a member might reach instead: the org-wide sys_view_definition answers 403, and the one member-writable store, sys_user_preference, requires user_id and is per-person by construction — which is the right affordance, not an org-wide overlay.

Cleanup: the control overlay was reset with DELETE, and the end state was verified — sys_metadatatotal: 0, and duly_task.default back to the shipped sort: [{"field":"due_date","order":"asc"}] with _provenance: package. The dev database lives in the task worktree and goes with it.

What this PR changes

One section in AGENTS.md. No code. It records the verdict, the table above, and how it was measured, so nobody re-derives it — plus two things a future reader would otherwise get wrong:

• Do not "harden" this by denying manage_metadata in src/security/permission-sets.ts.systemPermissions is an additive list with no deny form. The entry would not be enforcement; it would be a declared-and-unenforced key of exactly the kind ADR-0049 exists to remove, sitting in the one file whose credibility depends on every line in it being live. The card's contingent fix is not just unnecessary — it is not expressible.
• The admin-facing surprise is still real. For a caller who does hold the capability, an ordinary sort click persists an org-wide overlay carrying the entire view definition, with no save gesture and no UI indication. finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 proposed filing that at objectstack-ai/objectuiconditional on members being able to do it, so it is deliberately left unfiled here and flagged for the maintainer instead — see the report on finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84.

Gates

All four green on 67c670e, the head of this branch, with a clean tree:

pnpm validate exit 0 ✓ Validation passed (368ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 25 passed (25) · Tests 641 passed (641)
pnpm build exit 0 ✓ Build complete (746ms)

validate's one warning is the hierarchy-security capability-provider notice that AGENTS.md documents as this repo's expected state.

No changeset — this repo has no changeset mechanism.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The answer is "note branch", and the reason not to write the fix is better than the fix.

Gates on the head merged with current main:validate 0, typecheck 0, test 0 (Test Files 26, Tests 662), build 0.

The question this card was blocked on is answered, with controls rather than a single reading:

control	result	what it rules out
same body, platform-admin session	200, overlay lands exactly as the card described	the 403s are not a malformed payload
anonymous	401 from a different gate	the member's 403 came after its session resolved
compound twin door + DELETE reset door	same 403	a gate on one door and not its twin — the usual bypass
sys_view_definition / sys_user_preference sweep	org-wide refused; the writable one is per-person by construction	an alternate persistence route

And the permission-set binding was verified by A/B rather than assumed — a bound duly_member reads duly_task 200, an unbound self-registered account 403 — which is the step that makes the three 403s mean "this role cannot" rather than "this account has nothing".

Declining to write the contingent fix is the right call

My card said: if members can do it, deny the capability to duly_member and duly_manager. You established they cannot, and then went one better — the fix is not expressible. systemPermissions is an additive list with no deny form, so the entry would not be enforcement, it would be a declared-and-unenforced key sitting in the one file whose entire credibility rests on every line in it being live. Writing it would have looked like hardening and been the exact defect ADR-0049 exists to remove. Putting a stop sign in AGENTS.md so the next person does not "helpfully" add it is worth more than the line itself would have been.

The section is well-judged generally: verdict, result table, method, and the boundary of what remains true. Recording how it was measured is what stops this being re-derived in three months by someone who finds the same PUT in a network log.

On your open question — file it, and I will

Your recommendation B is right and your reason for not doing it yourself is also right: I conditioned the upstream filing on the member branch, and that branch did not happen, so writing into another repository's tracker was outside what you were authorized to do. Declining on scope while saying plainly that the merit is unchanged is the correct shape for that. Consider it authorized retroactively in spirit — but it is mine to file, and I am filing it now with your result table.

The claim is smaller than the p0 this card was written against, and still real: an administrator demoing the app can freeze duly_task.default at the shipped definition by clicking a column header, and nothing tells them. A later release adding a column to that view would then be silently ignored in their org.

Cleanup verified — overlay deleted, sys_metadata back to 0, the view restored to its shipped due_date asc with its _provenance package, server killed by recorded PID, worktree removed without --force.

---

Generated by Claude Code

[os-warren]

Fixes#84

#84 was blocked on one question: the org-wide view overlay was measured as the dev admin, and the severity turned entirely on whether an ordinary member could do the same thing. #73 (pnpm demo) unblocked it. It is measured now, and the answer is no — so this is the card's "note, not p0" branch, and there is no security change.

What was measured

Against a live pnpm demo on @objectstack/rest 17.2.0. Three accounts were created by self-registration (POST /api/v1/auth/sign-up/email, which yields positions: ["user","org_member"], isPlatformAdmin: false) and each bound to exactly one Duly permission set through sys_user_permission_set — nothing beyond what src/security/permission-sets.ts grants.

The binding was verified live rather than assumed: a bound duly_member reads duly_task200, an unbound self-registered account reads it 403. So the sets really do resolve for these callers.

Each then issued the request the grid issues — the declared duly_task.default config with sort swapped to status asc:

Caller	PUT /api/v1/meta/view/duly_task.default
anonymous	401 UNAUTHENTICATED
duly_member	403 FORBIDDEN — Saving a metadata item requires the `manage_metadata` capability.
duly_manager	403 FORBIDDEN — same
duly_admin	403 FORBIDDEN — same
platform admin	200 — Saved customization overlay (org=org_mtik8rkleytx3x6b, state=active)

sys_metadata read total: 0 after every refused attempt.

Three things make the negative result trustworthy rather than a mis-shaped request:

• The control fires. The identical body from the platform-admin session returns 200 and lands the row finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 describes — type: view, name: duly_task.default, scope: platform, owner: null, organization_id: org_…, state: active. The 403s are a capability refusal, not a malformed payload.
• The 401/403 split. An anonymous caller gets a different code from the anonymous-deny gate, so the member's 403 proves its session resolved and was then denied on capability.
• Both doors and the reset door. The compound twin (PUT /api/v1/meta/duly_task/views/default) and DELETE /api/v1/meta/view/duly_task.default carry the identical gate — checked, because gating one door and not its twin is the usual bypass.

Also swept for a second persistence route a member might reach instead: the org-wide sys_view_definition answers 403, and the one member-writable store, sys_user_preference, requires user_id and is per-person by construction — which is the right affordance, not an org-wide overlay.

Cleanup: the control overlay was reset with DELETE, and the end state was verified — sys_metadatatotal: 0, and duly_task.default back to the shipped sort: [{"field":"due_date","order":"asc"}] with _provenance: package. The dev database lives in the task worktree and goes with it.

What this PR changes

One section in AGENTS.md. No code. It records the verdict, the table above, and how it was measured, so nobody re-derives it — plus two things a future reader would otherwise get wrong:

• Do not "harden" this by denying manage_metadata in src/security/permission-sets.ts.systemPermissions is an additive list with no deny form. The entry would not be enforcement; it would be a declared-and-unenforced key of exactly the kind ADR-0049 exists to remove, sitting in the one file whose credibility depends on every line in it being live. The card's contingent fix is not just unnecessary — it is not expressible.
• The admin-facing surprise is still real. For a caller who does hold the capability, an ordinary sort click persists an org-wide overlay carrying the entire view definition, with no save gesture and no UI indication. finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 proposed filing that at objectstack-ai/objectuiconditional on members being able to do it, so it is deliberately left unfiled here and flagged for the maintainer instead — see the report on finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84.

Gates

All four green on 67c670e, the head of this branch, with a clean tree:

pnpm validate exit 0 ✓ Validation passed (368ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 25 passed (25) · Tests 641 passed (641)
pnpm build exit 0 ✓ Build complete (746ms)

validate's one warning is the hierarchy-security capability-provider notice that AGENTS.md documents as this repo's expected state.

No changeset — this repo has no changeset mechanism.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The answer is "note branch", and the reason not to write the fix is better than the fix.

Gates on the head merged with current main:validate 0, typecheck 0, test 0 (Test Files 26, Tests 662), build 0.

The question this card was blocked on is answered, with controls rather than a single reading:

control	result	what it rules out
same body, platform-admin session	200, overlay lands exactly as the card described	the 403s are not a malformed payload
anonymous	401 from a different gate	the member's 403 came after its session resolved
compound twin door + DELETE reset door	same 403	a gate on one door and not its twin — the usual bypass
sys_view_definition / sys_user_preference sweep	org-wide refused; the writable one is per-person by construction	an alternate persistence route

And the permission-set binding was verified by A/B rather than assumed — a bound duly_member reads duly_task 200, an unbound self-registered account 403 — which is the step that makes the three 403s mean "this role cannot" rather than "this account has nothing".

Declining to write the contingent fix is the right call

My card said: if members can do it, deny the capability to duly_member and duly_manager. You established they cannot, and then went one better — the fix is not expressible. systemPermissions is an additive list with no deny form, so the entry would not be enforcement, it would be a declared-and-unenforced key sitting in the one file whose entire credibility rests on every line in it being live. Writing it would have looked like hardening and been the exact defect ADR-0049 exists to remove. Putting a stop sign in AGENTS.md so the next person does not "helpfully" add it is worth more than the line itself would have been.

The section is well-judged generally: verdict, result table, method, and the boundary of what remains true. Recording how it was measured is what stops this being re-derived in three months by someone who finds the same PUT in a network log.

On your open question — file it, and I will

Your recommendation B is right and your reason for not doing it yourself is also right: I conditioned the upstream filing on the member branch, and that branch did not happen, so writing into another repository's tracker was outside what you were authorized to do. Declining on scope while saying plainly that the merit is unchanged is the correct shape for that. Consider it authorized retroactively in spirit — but it is mine to file, and I am filing it now with your result table.

The claim is smaller than the p0 this card was written against, and still real: an administrator demoing the app can freeze duly_task.default at the shipped definition by clicking a column header, and nothing tells them. A later release adding a column to that view would then be silently ignored in their org.

Cleanup verified — overlay deleted, sys_metadata back to 0, the view restored to its shipped due_date asc with its _provenance package, server killed by recorded PID, worktree removed without --force.

---

Generated by Claude Code

[os-warren]

Fixes#84

#84 was blocked on one question: the org-wide view overlay was measured as the dev admin, and the severity turned entirely on whether an ordinary member could do the same thing. #73 (pnpm demo) unblocked it. It is measured now, and the answer is no — so this is the card's "note, not p0" branch, and there is no security change.

What was measured

Against a live pnpm demo on @objectstack/rest 17.2.0. Three accounts were created by self-registration (POST /api/v1/auth/sign-up/email, which yields positions: ["user","org_member"], isPlatformAdmin: false) and each bound to exactly one Duly permission set through sys_user_permission_set — nothing beyond what src/security/permission-sets.ts grants.

The binding was verified live rather than assumed: a bound duly_member reads duly_task200, an unbound self-registered account reads it 403. So the sets really do resolve for these callers.

Each then issued the request the grid issues — the declared duly_task.default config with sort swapped to status asc:

Caller	PUT /api/v1/meta/view/duly_task.default
anonymous	401 UNAUTHENTICATED
duly_member	403 FORBIDDEN — Saving a metadata item requires the `manage_metadata` capability.
duly_manager	403 FORBIDDEN — same
duly_admin	403 FORBIDDEN — same
platform admin	200 — Saved customization overlay (org=org_mtik8rkleytx3x6b, state=active)

sys_metadata read total: 0 after every refused attempt.

Three things make the negative result trustworthy rather than a mis-shaped request:

• The control fires. The identical body from the platform-admin session returns 200 and lands the row finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 describes — type: view, name: duly_task.default, scope: platform, owner: null, organization_id: org_…, state: active. The 403s are a capability refusal, not a malformed payload.
• The 401/403 split. An anonymous caller gets a different code from the anonymous-deny gate, so the member's 403 proves its session resolved and was then denied on capability.
• Both doors and the reset door. The compound twin (PUT /api/v1/meta/duly_task/views/default) and DELETE /api/v1/meta/view/duly_task.default carry the identical gate — checked, because gating one door and not its twin is the usual bypass.

Also swept for a second persistence route a member might reach instead: the org-wide sys_view_definition answers 403, and the one member-writable store, sys_user_preference, requires user_id and is per-person by construction — which is the right affordance, not an org-wide overlay.

Cleanup: the control overlay was reset with DELETE, and the end state was verified — sys_metadatatotal: 0, and duly_task.default back to the shipped sort: [{"field":"due_date","order":"asc"}] with _provenance: package. The dev database lives in the task worktree and goes with it.

What this PR changes

One section in AGENTS.md. No code. It records the verdict, the table above, and how it was measured, so nobody re-derives it — plus two things a future reader would otherwise get wrong:

• Do not "harden" this by denying manage_metadata in src/security/permission-sets.ts.systemPermissions is an additive list with no deny form. The entry would not be enforcement; it would be a declared-and-unenforced key of exactly the kind ADR-0049 exists to remove, sitting in the one file whose credibility depends on every line in it being live. The card's contingent fix is not just unnecessary — it is not expressible.
• The admin-facing surprise is still real. For a caller who does hold the capability, an ordinary sort click persists an org-wide overlay carrying the entire view definition, with no save gesture and no UI indication. finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 proposed filing that at objectstack-ai/objectuiconditional on members being able to do it, so it is deliberately left unfiled here and flagged for the maintainer instead — see the report on finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84.

Gates

All four green on 67c670e, the head of this branch, with a clean tree:

pnpm validate exit 0 ✓ Validation passed (368ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 25 passed (25) · Tests 641 passed (641)
pnpm build exit 0 ✓ Build complete (746ms)

validate's one warning is the hierarchy-security capability-provider notice that AGENTS.md documents as this repo's expected state.

No changeset — this repo has no changeset mechanism.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The answer is "note branch", and the reason not to write the fix is better than the fix.

Gates on the head merged with current main:validate 0, typecheck 0, test 0 (Test Files 26, Tests 662), build 0.

The question this card was blocked on is answered, with controls rather than a single reading:

control	result	what it rules out
same body, platform-admin session	200, overlay lands exactly as the card described	the 403s are not a malformed payload
anonymous	401 from a different gate	the member's 403 came after its session resolved
compound twin door + DELETE reset door	same 403	a gate on one door and not its twin — the usual bypass
sys_view_definition / sys_user_preference sweep	org-wide refused; the writable one is per-person by construction	an alternate persistence route

And the permission-set binding was verified by A/B rather than assumed — a bound duly_member reads duly_task 200, an unbound self-registered account 403 — which is the step that makes the three 403s mean "this role cannot" rather than "this account has nothing".

Declining to write the contingent fix is the right call

My card said: if members can do it, deny the capability to duly_member and duly_manager. You established they cannot, and then went one better — the fix is not expressible. systemPermissions is an additive list with no deny form, so the entry would not be enforcement, it would be a declared-and-unenforced key sitting in the one file whose entire credibility rests on every line in it being live. Writing it would have looked like hardening and been the exact defect ADR-0049 exists to remove. Putting a stop sign in AGENTS.md so the next person does not "helpfully" add it is worth more than the line itself would have been.

The section is well-judged generally: verdict, result table, method, and the boundary of what remains true. Recording how it was measured is what stops this being re-derived in three months by someone who finds the same PUT in a network log.

On your open question — file it, and I will

Your recommendation B is right and your reason for not doing it yourself is also right: I conditioned the upstream filing on the member branch, and that branch did not happen, so writing into another repository's tracker was outside what you were authorized to do. Declining on scope while saying plainly that the merit is unchanged is the correct shape for that. Consider it authorized retroactively in spirit — but it is mine to file, and I am filing it now with your result table.

The claim is smaller than the p0 this card was written against, and still real: an administrator demoing the app can freeze duly_task.default at the shipped definition by clicking a column header, and nothing tells them. A later release adding a column to that view would then be silently ignored in their org.

Cleanup verified — overlay deleted, sys_metadata back to 0, the view restored to its shipped due_date asc with its _provenance package, server killed by recorded PID, worktree removed without --force.

---

Generated by Claude Code

[os-warren]

Fixes#84

#84 was blocked on one question: the org-wide view overlay was measured as the dev admin, and the severity turned entirely on whether an ordinary member could do the same thing. #73 (pnpm demo) unblocked it. It is measured now, and the answer is no — so this is the card's "note, not p0" branch, and there is no security change.

What was measured

Against a live pnpm demo on @objectstack/rest 17.2.0. Three accounts were created by self-registration (POST /api/v1/auth/sign-up/email, which yields positions: ["user","org_member"], isPlatformAdmin: false) and each bound to exactly one Duly permission set through sys_user_permission_set — nothing beyond what src/security/permission-sets.ts grants.

The binding was verified live rather than assumed: a bound duly_member reads duly_task200, an unbound self-registered account reads it 403. So the sets really do resolve for these callers.

Each then issued the request the grid issues — the declared duly_task.default config with sort swapped to status asc:

Caller	PUT /api/v1/meta/view/duly_task.default
anonymous	401 UNAUTHENTICATED
duly_member	403 FORBIDDEN — Saving a metadata item requires the `manage_metadata` capability.
duly_manager	403 FORBIDDEN — same
duly_admin	403 FORBIDDEN — same
platform admin	200 — Saved customization overlay (org=org_mtik8rkleytx3x6b, state=active)

sys_metadata read total: 0 after every refused attempt.

Three things make the negative result trustworthy rather than a mis-shaped request:

• The control fires. The identical body from the platform-admin session returns 200 and lands the row finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 describes — type: view, name: duly_task.default, scope: platform, owner: null, organization_id: org_…, state: active. The 403s are a capability refusal, not a malformed payload.
• The 401/403 split. An anonymous caller gets a different code from the anonymous-deny gate, so the member's 403 proves its session resolved and was then denied on capability.
• Both doors and the reset door. The compound twin (PUT /api/v1/meta/duly_task/views/default) and DELETE /api/v1/meta/view/duly_task.default carry the identical gate — checked, because gating one door and not its twin is the usual bypass.

Also swept for a second persistence route a member might reach instead: the org-wide sys_view_definition answers 403, and the one member-writable store, sys_user_preference, requires user_id and is per-person by construction — which is the right affordance, not an org-wide overlay.

Cleanup: the control overlay was reset with DELETE, and the end state was verified — sys_metadatatotal: 0, and duly_task.default back to the shipped sort: [{"field":"due_date","order":"asc"}] with _provenance: package. The dev database lives in the task worktree and goes with it.

What this PR changes

One section in AGENTS.md. No code. It records the verdict, the table above, and how it was measured, so nobody re-derives it — plus two things a future reader would otherwise get wrong:

• Do not "harden" this by denying manage_metadata in src/security/permission-sets.ts.systemPermissions is an additive list with no deny form. The entry would not be enforcement; it would be a declared-and-unenforced key of exactly the kind ADR-0049 exists to remove, sitting in the one file whose credibility depends on every line in it being live. The card's contingent fix is not just unnecessary — it is not expressible.
• The admin-facing surprise is still real. For a caller who does hold the capability, an ordinary sort click persists an org-wide overlay carrying the entire view definition, with no save gesture and no UI indication. finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 proposed filing that at objectstack-ai/objectuiconditional on members being able to do it, so it is deliberately left unfiled here and flagged for the maintainer instead — see the report on finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84.

Gates

All four green on 67c670e, the head of this branch, with a clean tree:

pnpm validate exit 0 ✓ Validation passed (368ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 25 passed (25) · Tests 641 passed (641)
pnpm build exit 0 ✓ Build complete (746ms)

validate's one warning is the hierarchy-security capability-provider notice that AGENTS.md documents as this repo's expected state.

No changeset — this repo has no changeset mechanism.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The answer is "note branch", and the reason not to write the fix is better than the fix.

Gates on the head merged with current main:validate 0, typecheck 0, test 0 (Test Files 26, Tests 662), build 0.

The question this card was blocked on is answered, with controls rather than a single reading:

control	result	what it rules out
same body, platform-admin session	200, overlay lands exactly as the card described	the 403s are not a malformed payload
anonymous	401 from a different gate	the member's 403 came after its session resolved
compound twin door + DELETE reset door	same 403	a gate on one door and not its twin — the usual bypass
sys_view_definition / sys_user_preference sweep	org-wide refused; the writable one is per-person by construction	an alternate persistence route

And the permission-set binding was verified by A/B rather than assumed — a bound duly_member reads duly_task 200, an unbound self-registered account 403 — which is the step that makes the three 403s mean "this role cannot" rather than "this account has nothing".

Declining to write the contingent fix is the right call

My card said: if members can do it, deny the capability to duly_member and duly_manager. You established they cannot, and then went one better — the fix is not expressible. systemPermissions is an additive list with no deny form, so the entry would not be enforcement, it would be a declared-and-unenforced key sitting in the one file whose entire credibility rests on every line in it being live. Writing it would have looked like hardening and been the exact defect ADR-0049 exists to remove. Putting a stop sign in AGENTS.md so the next person does not "helpfully" add it is worth more than the line itself would have been.

The section is well-judged generally: verdict, result table, method, and the boundary of what remains true. Recording how it was measured is what stops this being re-derived in three months by someone who finds the same PUT in a network log.

On your open question — file it, and I will

Your recommendation B is right and your reason for not doing it yourself is also right: I conditioned the upstream filing on the member branch, and that branch did not happen, so writing into another repository's tracker was outside what you were authorized to do. Declining on scope while saying plainly that the merit is unchanged is the correct shape for that. Consider it authorized retroactively in spirit — but it is mine to file, and I am filing it now with your result table.

The claim is smaller than the p0 this card was written against, and still real: an administrator demoing the app can freeze duly_task.default at the shipped definition by clicking a column header, and nothing tells them. A later release adding a column to that view would then be silently ignored in their org.

Cleanup verified — overlay deleted, sys_metadata back to 0, the view restored to its shipped due_date asc with its _provenance package, server killed by recorded PID, worktree removed without --force.

---

Generated by Claude Code

[os-warren]

Fixes#84

#84 was blocked on one question: the org-wide view overlay was measured as the dev admin, and the severity turned entirely on whether an ordinary member could do the same thing. #73 (pnpm demo) unblocked it. It is measured now, and the answer is no — so this is the card's "note, not p0" branch, and there is no security change.

What was measured

Against a live pnpm demo on @objectstack/rest 17.2.0. Three accounts were created by self-registration (POST /api/v1/auth/sign-up/email, which yields positions: ["user","org_member"], isPlatformAdmin: false) and each bound to exactly one Duly permission set through sys_user_permission_set — nothing beyond what src/security/permission-sets.ts grants.

The binding was verified live rather than assumed: a bound duly_member reads duly_task200, an unbound self-registered account reads it 403. So the sets really do resolve for these callers.

Each then issued the request the grid issues — the declared duly_task.default config with sort swapped to status asc:

Caller	PUT /api/v1/meta/view/duly_task.default
anonymous	401 UNAUTHENTICATED
duly_member	403 FORBIDDEN — Saving a metadata item requires the `manage_metadata` capability.
duly_manager	403 FORBIDDEN — same
duly_admin	403 FORBIDDEN — same
platform admin	200 — Saved customization overlay (org=org_mtik8rkleytx3x6b, state=active)

sys_metadata read total: 0 after every refused attempt.

Three things make the negative result trustworthy rather than a mis-shaped request:

• The control fires. The identical body from the platform-admin session returns 200 and lands the row finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 describes — type: view, name: duly_task.default, scope: platform, owner: null, organization_id: org_…, state: active. The 403s are a capability refusal, not a malformed payload.
• The 401/403 split. An anonymous caller gets a different code from the anonymous-deny gate, so the member's 403 proves its session resolved and was then denied on capability.
• Both doors and the reset door. The compound twin (PUT /api/v1/meta/duly_task/views/default) and DELETE /api/v1/meta/view/duly_task.default carry the identical gate — checked, because gating one door and not its twin is the usual bypass.

Also swept for a second persistence route a member might reach instead: the org-wide sys_view_definition answers 403, and the one member-writable store, sys_user_preference, requires user_id and is per-person by construction — which is the right affordance, not an org-wide overlay.

Cleanup: the control overlay was reset with DELETE, and the end state was verified — sys_metadatatotal: 0, and duly_task.default back to the shipped sort: [{"field":"due_date","order":"asc"}] with _provenance: package. The dev database lives in the task worktree and goes with it.

What this PR changes

One section in AGENTS.md. No code. It records the verdict, the table above, and how it was measured, so nobody re-derives it — plus two things a future reader would otherwise get wrong:

• Do not "harden" this by denying manage_metadata in src/security/permission-sets.ts.systemPermissions is an additive list with no deny form. The entry would not be enforcement; it would be a declared-and-unenforced key of exactly the kind ADR-0049 exists to remove, sitting in the one file whose credibility depends on every line in it being live. The card's contingent fix is not just unnecessary — it is not expressible.
• The admin-facing surprise is still real. For a caller who does hold the capability, an ordinary sort click persists an org-wide overlay carrying the entire view definition, with no save gesture and no UI indication. finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 proposed filing that at objectstack-ai/objectuiconditional on members being able to do it, so it is deliberately left unfiled here and flagged for the maintainer instead — see the report on finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84.

Gates

All four green on 67c670e, the head of this branch, with a clean tree:

pnpm validate exit 0 ✓ Validation passed (368ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 25 passed (25) · Tests 641 passed (641)
pnpm build exit 0 ✓ Build complete (746ms)

validate's one warning is the hierarchy-security capability-provider notice that AGENTS.md documents as this repo's expected state.

No changeset — this repo has no changeset mechanism.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The answer is "note branch", and the reason not to write the fix is better than the fix.

Gates on the head merged with current main:validate 0, typecheck 0, test 0 (Test Files 26, Tests 662), build 0.

The question this card was blocked on is answered, with controls rather than a single reading:

control	result	what it rules out
same body, platform-admin session	200, overlay lands exactly as the card described	the 403s are not a malformed payload
anonymous	401 from a different gate	the member's 403 came after its session resolved
compound twin door + DELETE reset door	same 403	a gate on one door and not its twin — the usual bypass
sys_view_definition / sys_user_preference sweep	org-wide refused; the writable one is per-person by construction	an alternate persistence route

And the permission-set binding was verified by A/B rather than assumed — a bound duly_member reads duly_task 200, an unbound self-registered account 403 — which is the step that makes the three 403s mean "this role cannot" rather than "this account has nothing".

Declining to write the contingent fix is the right call

My card said: if members can do it, deny the capability to duly_member and duly_manager. You established they cannot, and then went one better — the fix is not expressible. systemPermissions is an additive list with no deny form, so the entry would not be enforcement, it would be a declared-and-unenforced key sitting in the one file whose entire credibility rests on every line in it being live. Writing it would have looked like hardening and been the exact defect ADR-0049 exists to remove. Putting a stop sign in AGENTS.md so the next person does not "helpfully" add it is worth more than the line itself would have been.

The section is well-judged generally: verdict, result table, method, and the boundary of what remains true. Recording how it was measured is what stops this being re-derived in three months by someone who finds the same PUT in a network log.

On your open question — file it, and I will

Your recommendation B is right and your reason for not doing it yourself is also right: I conditioned the upstream filing on the member branch, and that branch did not happen, so writing into another repository's tracker was outside what you were authorized to do. Declining on scope while saying plainly that the merit is unchanged is the correct shape for that. Consider it authorized retroactively in spirit — but it is mine to file, and I am filing it now with your result table.

The claim is smaller than the p0 this card was written against, and still real: an administrator demoing the app can freeze duly_task.default at the shipped definition by clicking a column header, and nothing tells them. A later release adding a column to that view would then be silently ignored in their org.

Cleanup verified — overlay deleted, sys_metadata back to 0, the view restored to its shipped due_date asc with its _provenance package, server killed by recorded PID, worktree removed without --force.

---

Generated by Claude Code

[os-warren]

Fixes#84

#84 was blocked on one question: the org-wide view overlay was measured as the dev admin, and the severity turned entirely on whether an ordinary member could do the same thing. #73 (pnpm demo) unblocked it. It is measured now, and the answer is no — so this is the card's "note, not p0" branch, and there is no security change.

What was measured

Against a live pnpm demo on @objectstack/rest 17.2.0. Three accounts were created by self-registration (POST /api/v1/auth/sign-up/email, which yields positions: ["user","org_member"], isPlatformAdmin: false) and each bound to exactly one Duly permission set through sys_user_permission_set — nothing beyond what src/security/permission-sets.ts grants.

The binding was verified live rather than assumed: a bound duly_member reads duly_task200, an unbound self-registered account reads it 403. So the sets really do resolve for these callers.

Each then issued the request the grid issues — the declared duly_task.default config with sort swapped to status asc:

Caller	PUT /api/v1/meta/view/duly_task.default
anonymous	401 UNAUTHENTICATED
duly_member	403 FORBIDDEN — Saving a metadata item requires the `manage_metadata` capability.
duly_manager	403 FORBIDDEN — same
duly_admin	403 FORBIDDEN — same
platform admin	200 — Saved customization overlay (org=org_mtik8rkleytx3x6b, state=active)

sys_metadata read total: 0 after every refused attempt.

Three things make the negative result trustworthy rather than a mis-shaped request:

• The control fires. The identical body from the platform-admin session returns 200 and lands the row finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 describes — type: view, name: duly_task.default, scope: platform, owner: null, organization_id: org_…, state: active. The 403s are a capability refusal, not a malformed payload.
• The 401/403 split. An anonymous caller gets a different code from the anonymous-deny gate, so the member's 403 proves its session resolved and was then denied on capability.
• Both doors and the reset door. The compound twin (PUT /api/v1/meta/duly_task/views/default) and DELETE /api/v1/meta/view/duly_task.default carry the identical gate — checked, because gating one door and not its twin is the usual bypass.

Also swept for a second persistence route a member might reach instead: the org-wide sys_view_definition answers 403, and the one member-writable store, sys_user_preference, requires user_id and is per-person by construction — which is the right affordance, not an org-wide overlay.

Cleanup: the control overlay was reset with DELETE, and the end state was verified — sys_metadatatotal: 0, and duly_task.default back to the shipped sort: [{"field":"due_date","order":"asc"}] with _provenance: package. The dev database lives in the task worktree and goes with it.

What this PR changes

One section in AGENTS.md. No code. It records the verdict, the table above, and how it was measured, so nobody re-derives it — plus two things a future reader would otherwise get wrong:

• Do not "harden" this by denying manage_metadata in src/security/permission-sets.ts.systemPermissions is an additive list with no deny form. The entry would not be enforcement; it would be a declared-and-unenforced key of exactly the kind ADR-0049 exists to remove, sitting in the one file whose credibility depends on every line in it being live. The card's contingent fix is not just unnecessary — it is not expressible.
• The admin-facing surprise is still real. For a caller who does hold the capability, an ordinary sort click persists an org-wide overlay carrying the entire view definition, with no save gesture and no UI indication. finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84 proposed filing that at objectstack-ai/objectuiconditional on members being able to do it, so it is deliberately left unfiled here and flagged for the maintainer instead — see the report on finding: clicking a column header persists an org-wide view overlay — one person's sort silently rewrites the view for everyone #84.

Gates

All four green on 67c670e, the head of this branch, with a clean tree:

pnpm validate exit 0 ✓ Validation passed (368ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 25 passed (25) · Tests 641 passed (641)
pnpm build exit 0 ✓ Build complete (746ms)

validate's one warning is the hierarchy-security capability-provider notice that AGENTS.md documents as this repo's expected state.

No changeset — this repo has no changeset mechanism.

Generated by Claude Code

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The answer is "note branch", and the reason not to write the fix is better than the fix.

Gates on the head merged with current main:validate 0, typecheck 0, test 0 (Test Files 26, Tests 662), build 0.

The question this card was blocked on is answered, with controls rather than a single reading:

control	result	what it rules out
same body, platform-admin session	200, overlay lands exactly as the card described	the 403s are not a malformed payload
anonymous	401 from a different gate	the member's 403 came after its session resolved
compound twin door + DELETE reset door	same 403	a gate on one door and not its twin — the usual bypass
sys_view_definition / sys_user_preference sweep	org-wide refused; the writable one is per-person by construction	an alternate persistence route

And the permission-set binding was verified by A/B rather than assumed — a bound duly_member reads duly_task 200, an unbound self-registered account 403 — which is the step that makes the three 403s mean "this role cannot" rather than "this account has nothing".

Declining to write the contingent fix is the right call

My card said: if members can do it, deny the capability to duly_member and duly_manager. You established they cannot, and then went one better — the fix is not expressible. systemPermissions is an additive list with no deny form, so the entry would not be enforcement, it would be a declared-and-unenforced key sitting in the one file whose entire credibility rests on every line in it being live. Writing it would have looked like hardening and been the exact defect ADR-0049 exists to remove. Putting a stop sign in AGENTS.md so the next person does not "helpfully" add it is worth more than the line itself would have been.

The section is well-judged generally: verdict, result table, method, and the boundary of what remains true. Recording how it was measured is what stops this being re-derived in three months by someone who finds the same PUT in a network log.

On your open question — file it, and I will

Your recommendation B is right and your reason for not doing it yourself is also right: I conditioned the upstream filing on the member branch, and that branch did not happen, so writing into another repository's tracker was outside what you were authorized to do. Declining on scope while saying plainly that the merit is unchanged is the correct shape for that. Consider it authorized retroactively in spirit — but it is mine to file, and I am filing it now with your result table.

The claim is smaller than the p0 this card was written against, and still real: an administrator demoing the app can freeze duly_task.default at the shipped definition by clicking a column header, and nothing tells them. A later release adding a column to that view would then be silently ignored in their org.

Cleanup verified — overlay deleted, sys_metadata back to 0, the view restored to its shipped due_date asc with its _provenance package, server killed by recorded PID, worktree removed without --force.

---

Generated by Claude Code