Filed unassigned by the #9671 dev seat, as the docs half of #9730's ruled removal. No verdict of my own is asserted here — #9730's maintainer ruling (2026-08-18) already settled REMOVE; this card only records the doc surface that ruling lands on, so it is not discovered after the fact.
What couples
#9671 (PR pending) rewrites content/docs/permissions/authorization.mdx, section "Grant lifecycle: validity windows (ADR-0091 L1)", so the four ADR-0091 lifecycle columns are stated per column and per grant table instead of as one set. Two places in that section now assert the measured state of delegated_from on sys_user_permission_set:
- The per-object table row for
delegated_from, whose sys_user_permission_set cell reads "Authoring lint only — no runtime reader" and explains that a value there is provenance you record rather than provenance the platform checks. - The seed-lint paragraph below it, which now says the D3 seed rule runs on both grant tables and that on
sys_user_permission_set it is the only enforcement delegated_from has.
Both are accurate against main today. Both become false the moment #9730's removal lands: the column will not exist on that table, so a row describing its enforcement is worse than the conflation #9671 removed — it documents a column an author can no longer declare.
What the removal PR needs to do
In the same PR that retires the column:
- Drop the
sys_user_permission_set cell content from the delegated_from row (or drop the column from the table's object axis) in content/docs/permissions/authorization.mdx. - Correct the seed-lint paragraph: once the lint scope set at
packages/lint/src/validate-security-posture.ts:586 stops covering this object for the D3 rule, "runs on both grant tables" is wrong too. - The D5 pair rows and the
reason row are unaffected — reason stays declared on both tables.
Why a card rather than trusting the audit
content/docs/permissions/authorization.mdx is in docs-accuracy-audit scope, so the drift would be findable later. It should not need finding: the removal PR already has the page in its blast radius, and a docs edit riding along with the retirement costs one hunk. This card exists so that hunk is on the checklist rather than in a future audit round.
Note the description text on the declaration itself needs no separate card: sys_user_permission_set.delegated_from's description currently claims "A row with delegated_from set is not itself delegatable and not self-renewable" — an enforcement claim no runtime code makes on this object — and the #9046 comment block on the same file says "reason/delegated_from are read by the delegated-admin gate and the security-posture lint" without an object qualifier. The removal deletes both, so they dissolve into #9730 rather than needing their own fix.
Refs: #9730 (parent, ruled REMOVE) · #9671 (the docs card whose wording this updates) · ADR-0091 D1/D3 · ADR-0049.
Generated by Claude Code
Filed unassigned by the
#9671dev seat, as the docs half of #9730's ruled removal. No verdict of my own is asserted here — #9730's maintainer ruling (2026-08-18) already settled REMOVE; this card only records the doc surface that ruling lands on, so it is not discovered after the fact.What couples
#9671 (PR pending) rewrites
content/docs/permissions/authorization.mdx, section "Grant lifecycle: validity windows (ADR-0091 L1)", so the four ADR-0091 lifecycle columns are stated per column and per grant table instead of as one set. Two places in that section now assert the measured state ofdelegated_fromonsys_user_permission_set:delegated_from, whosesys_user_permission_setcell reads "Authoring lint only — no runtime reader" and explains that a value there is provenance you record rather than provenance the platform checks.sys_user_permission_setit is the only enforcementdelegated_fromhas.Both are accurate against
maintoday. Both become false the moment #9730's removal lands: the column will not exist on that table, so a row describing its enforcement is worse than the conflation #9671 removed — it documents a column an author can no longer declare.What the removal PR needs to do
In the same PR that retires the column:
sys_user_permission_setcell content from thedelegated_fromrow (or drop the column from the table's object axis) incontent/docs/permissions/authorization.mdx.packages/lint/src/validate-security-posture.ts:586stops covering this object for the D3 rule, "runs on both grant tables" is wrong too.reasonrow are unaffected —reasonstays declared on both tables.Why a card rather than trusting the audit
content/docs/permissions/authorization.mdxis indocs-accuracy-auditscope, so the drift would be findable later. It should not need finding: the removal PR already has the page in its blast radius, and a docs edit riding along with the retirement costs one hunk. This card exists so that hunk is on the checklist rather than in a future audit round.Note the description text on the declaration itself needs no separate card:
sys_user_permission_set.delegated_from's description currently claims "A row with delegated_from set is not itself delegatable and not self-renewable" — an enforcement claim no runtime code makes on this object — and the#9046comment block on the same file says "reason/delegated_from are read by the delegated-admin gate and the security-posture lint" without an object qualifier. The removal deletes both, so they dissolve into #9730 rather than needing their own fix.Refs: #9730 (parent, ruled REMOVE) · #9671 (the docs card whose wording this updates) · ADR-0091 D1/D3 · ADR-0049.
Generated by Claude Code