Found while measuring the isSystem guard surface for #12597 (not fixed there — out of scope for that card).
content/docs/permissions/system-context.mdx presents itself as the platform's authority on elevation:
This page is the authority for what that flag actually does. […] a single boolean read at 80 distinct sites across 18 packages
and
Built by census over the whole repo, not by recall.
Each row of its tables carries a file:line anchor. Every anchor I checked resolves to an unrelated line on origin/main (measured at bc5156fcb):
| Row |
Page claims |
Actually at |
What is at the claimed line |
| 18 — "Referential-integrity check skipped" |
engine.ts:3314 |
engine.ts:5525 (assertReferencesResolve's if (context?.isSystem) return;) |
a comment inside an unrelated filter block |
13 — "readonly strip bypassed — UPDATE, single row" |
engine.ts:6860 |
engine.ts:10434 (if (!opCtx.context?.isSystem) { wrapping stripReadonlyFields) |
a bare } catch (e) { |
14 — "readonly strip bypassed — UPDATE, bulk/predicate" |
engine.ts:7004 |
engine.ts:10596 |
— |
I checked three rows and all three had drifted, so this is systematic rather than one stale entry; I did not audit the remaining rows.
Why it is worth a card
The page's value is that it is checkable — the anchors are what let a reader re-run the census instead of trusting the prose. Anchors that point at unrelated lines make it unverifiable in exactly the situation it exists for: someone deciding whether to set isSystem on a write, who needs to know what elevation costs. It is also the page that would have to grow a row for any new elevated write site, so the drift compounds.
It degrades silently: nothing in CI holds the anchors to the code, and a line-number anchor rots on every unrelated edit to the same file.
Not prescribing a fix
Two shapes seem plausible and the choice is a real one — a gate that resolves each anchor and fails when it does not match an expected symbol, or dropping line numbers in favour of symbol-name anchors that survive edits. The second is cheaper to keep true; the first catches deletions the second would not. Deliberately left open.
Filed unassigned.
Generated by Claude Code
Found while measuring the
isSystemguard surface for #12597 (not fixed there — out of scope for that card).content/docs/permissions/system-context.mdxpresents itself as the platform's authority on elevation:and
Each row of its tables carries a
file:lineanchor. Every anchor I checked resolves to an unrelated line onorigin/main(measured atbc5156fcb):engine.ts:3314engine.ts:5525(assertReferencesResolve'sif (context?.isSystem) return;)readonlystrip bypassed — UPDATE, single row"engine.ts:6860engine.ts:10434(if (!opCtx.context?.isSystem) {wrappingstripReadonlyFields)} catch (e) {readonlystrip bypassed — UPDATE, bulk/predicate"engine.ts:7004engine.ts:10596I checked three rows and all three had drifted, so this is systematic rather than one stale entry; I did not audit the remaining rows.
Why it is worth a card
The page's value is that it is checkable — the anchors are what let a reader re-run the census instead of trusting the prose. Anchors that point at unrelated lines make it unverifiable in exactly the situation it exists for: someone deciding whether to set
isSystemon a write, who needs to know what elevation costs. It is also the page that would have to grow a row for any new elevated write site, so the drift compounds.It degrades silently: nothing in CI holds the anchors to the code, and a line-number anchor rots on every unrelated edit to the same file.
Not prescribing a fix
Two shapes seem plausible and the choice is a real one — a gate that resolves each anchor and fails when it does not match an expected symbol, or dropping line numbers in favour of symbol-name anchors that survive edits. The second is cheaper to keep true; the first catches deletions the second would not. Deliberately left open.
Filed unassigned.
Generated by Claude Code