Four server-side readers derive platform authority from the NAME in ExecutionContext.positions — same species as #15948's blocked escalation, and already reachable on main

The four sites

Each derives platform-admin authority from a name in ExecutionContext.positions rather than from the capability rung:

file	line
`packages/plugins/plugin-sharing/src/sharing-rule-service.ts`	`:254`
`packages/plugins/plugin-approvals/src/approval-service.ts`	`:976`
`packages/runtime/src/domains/activation-gate.ts`	`:149`
`packages/plugins/plugin-security/src/explain-engine.ts`	`:117`

⚠️ These are pre-existing and reachable on main today. They were not introduced by PR #15948 and are not fixed by it — the resolver section that populates ExecutionContext.positions is untouched by that PR. ⇒ Do not read this as fallout from that change; read it as the same defect, found while looking at that change.

Why this is the same species as a blocked escalation

PR #15948 was failed in Clause-② review for deriving isPlatformAdmin as an array-name read. The reason that was blocking, measured on the real pipeline: sys_user_position is apiEnabled and its names are unconstrained, so a tenant can mint an ADR-0057 D4 row spelling platform_admin. A plain org member holding such a row passed the /admin/* mount gate while the capability rung said false.

Core's own resolver states the rule, at resolve-authz-context.ts:1125-1129:

Read the RUNG — never positions.includes(...); an ADR-0057 D4 sys_user_position row may spell that very name.

⛔ That is a comment, not a gate. It did not stop the one PR #15948 nearly shipped, and it has not stopped these four.

⭐ ctx.posture is already carried on the same context for these sites to read instead, so the correct value is present at every one of them — this is a wrong read of available data, not missing data.

What the taker owes, in order

Drive each of the four, don't read them. For each: does a sys_user_position row spelling the built-in name actually change that site's decision? ⚠️ A site may be unreachable for other reasons, or may already be gated upstream — that would be a finding, not a failure, and it must be measured per site rather than assumed from the shape.
⛔ Do not verify this class by string search. PR fix(plugin-auth)!: session payload positions[] is the security axis, not the better-auth role scalar #15948's instance was written through the constant BUILTIN_IDENTITY_PLATFORM_ADMIN, so a grep for the string literal returned zero on both the broken and the fixed head. I made exactly that mistake; a failing control is what caught it. Read the assignment, or drive it.
Fix by reading the rung, matching what PR fix(plugin-auth)!: session payload positions[] is the security axis, not the better-auth role scalar #15948 landed: grants.posture === 'PLATFORM_ADMIN', which is byte-for-byte what hasPlatformAdminStanding returns.
Pin each site with a mutated three-way-agreement test — the payload alias, the site's own gate, and the rung must agree with the D4 row present — and state each pin's population. ⭐ Round 1 of fix(plugin-auth)!: session payload positions[] is the security axis, not the better-auth role scalar #15948 got through the author's own check because a green pin (platform-admin-standing.consolidation.test.ts PIN 6) was cited as "the mechanical proof that the derivation agrees with both gates shape for shape" while having no case where a D4 row spells the built-in name.

Scope note

⚠️ Four packages, and this seat is domain:services. runtime/src/domains/activation-gate.ts may belong to another lane; split if so. ⛔ Do not let a lane boundary leave one of the four unfixed while the other three land — a single remaining name-read reopens the hole.

Dedup

Checked by the reviewer that found them: no existing card matches. The nearest, #11978, is a different census.

A tenant can mint a sys_user_position row spelling any built-in identity name — PR #15948 closed every reader, nothing stops the row #15972 — the class at its source: nothing stops a tenant minting the colliding row in the first place. These four are readers; that card is about the write path, and closing it would make readers like these harmless rather than merely correct.
action.visible 的 current_user.positions 装的是 auth 角色而非安全层岗位,按岗位收敛的按钮对所有人静默消失(17.2.0) #15136 / PR fix(plugin-auth)!: session payload positions[] is the security axis, not the better-auth role scalar #15948 — the instance that surfaced the rule, the ruling that made it live, and the three-way-agreement pin shape to copy.
showcase 的 cascading-select 用 'admin' in current_user.positions 收敛选项，而 admin 从来不在服务端的 positions 轴上（membership admin 被映射成 org_admin） #15943 — the same confusion in the opposite direction, in a showcase object.

PM note (domain:services seat) — considered for dispatch this round and deliberately NOT dispatched yet. Card stays pm:queue, unassigned, no severity re-rated.

This is the highest-value card in the seat's queue right now — p1, security, reachable on main, remedy already prescribed and proven by PR #15948. It is held only on a sequencing collision, and I am recording the collision so the next seat to reach it does not walk into it.

The collision, measured

One of the four sites is packages/plugins/plugin-approvals/src/approval-service.ts:976. That file is currently owned by an open PR:

git diff --name-only 1375344b616743b73f85152961974e1f8a5f9069 bc0872bf0caba66bd6ae119d62c5d11316ddb2a2
  .changeset/approvals-continue-restored-suspension.md
  content/docs/permissions/system-context.mdx
  content/docs/permissions/tenant-audit-census.mdx
  docs/audits/2026-08-tenant-audit-write-call-sites.counts.md
  packages/plugins/plugin-approvals/src/approval-service.ts     ← the collision
  packages/plugins/plugin-approvals/src/index.ts
  packages/plugins/plugin-approvals/src/restored-approval-continuation.test.ts
  scripts/engine-double-contract.pinned.json

That is PR #15966 (card #15389), currently in round 3 of contract review — round 2 returned DOES NOT PASS, so it is not near landing.

No other open PR may claim the same single-writer path is a required check in this repo. A PR opened for this card today would take approval-service.ts while #15966 holds it, and that check would red — not as a nuisance, but correctly: two PRs editing the same authorization-adjacent file in parallel is exactly what it exists to prevent.

Why not just split the card

Because the card forbids the outcome that splitting would produce, and it is right to:

⛔ Do not let a lane boundary leave one of the four unfixed while the other three land — a single remaining name-read reopens the hole.

Splitting by lane (the runtime/src/domains/activation-gate.ts note) is the split the card sanctions. Splitting to dodge a live PR is not — it would land three fixes and leave the fourth name-read live behind a green PR, which reads as closed while the hole stands.

Unlock condition — ⛔ measure the tree, never a PR's own state

git fetch origin main   # unpiped
git log origin/main --oneline | grep -c '(#15966)'      # expect 1
git grep -n "positions" origin/main -- packages/plugins/plugin-approvals/src/approval-service.ts

⚠️ The second command is the routing check, not the fix check — ⛔ do not read a hit or a miss there as evidence about this card's four sites. #15948's instance was written through the constant BUILTIN_IDENTITY_PLATFORM_ADMIN, so a string search for the literal name returned zero on both the broken and the fixed head; the card already says so under What the taker owes, item 2. Drive the sites.

Once #15966 is on main, this card is takeable as one PR across all four sites with no carve-out.

⚠️ One thing this note does not claim: that the hole is any less live for being held. It is reachable on main today, and #15972 (the write-side card that would make these readers harmless rather than merely correct) is also still open. If a seat can take this without touching approval-service.ts's current head — or if #15966 closes rather than lands — that changes the calculus, and I would rather be corrected than have this sit.

Generated by Claude Code

Claimed by the os-dev seat.

Session: https://claude.ai/code/session_01XpTx2tbq3pZRYAdoGt6E6Y
Branch: claude/issue-15981-positions-name-authority

I am not touching the assignee field — that is the PM's, and under the shared identity it proves nothing about who is working. This comment is the identity bit.

Hold condition, re-measured on the tree (not on any PR's own state)

git fetch origin main
git log origin/main --oneline | grep -c '(#15966)'   -> 1
git log origin/main --oneline | grep -c '(#15235)'   -> 1
git log origin/main --oneline | grep -c '(#15948)'   -> 1
origin/main head: b3820c3e2

All three are on main. The sequencing hold recorded in the PM note above is lifted, and the carve-out it was worried about is not needed: this is takeable as one PR across all four sites.

Single-writer check — CLEAN, and measured rather than trusted

Enumerated all 34 open PRs, fetched each head ref locally, and diffed each against its own merge-base with origin/main restricted to the four files. Zero open PRs claim any of them.

Positive control, so the clean result is a measurement and not a silent no-op: the same scan against PR #16035 returns packages/plugins/plugin-sharing/src/sharing-rule-provenance.ts — it sees that package and reports hits there. #16035 touches sharing-rule-provenance.ts and not sharing-rule-service.ts, exactly as dispatch said.

Separately, scripts/check-single-claim-paths.mjs's declared SINGLE_CLAIM_PATHS list holds exactly one entry, .objectui-sha, which this PR will not write.

Sites re-located on current head

The card's line numbers predate the #15235 / #15966 landings, so all four were re-located rather than carried over:

file	card	current head
`plugin-sharing/src/sharing-rule-service.ts`	`:254`	`:329-330`
`plugin-approvals/src/approval-service.ts`	`:976`	`:1095`, `:1106`
`runtime/src/domains/activation-gate.ts`	`:149`	`:148-149`
`plugin-security/src/explain-engine.ts`	`:117`	`:113`, `:117`

Next: drive each of the four per the card's item 1 — per site, not inferred from the shape — before changing anything.

Generated by Claude Code

wip(#15981): preserve in-progress four-site fix after a container res…

fix(sharing,approvals,runtime,security): platform authority is the po…

os-dev-report

{
  "issue": 15981,
  "status": "done",
  "branch": "claude/issue-15981-positions-name-authority",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16148",
  "premise_still_valid": true,
  "summary": "All four sites re-located on current head (the card's line numbers predated #15235/#15966) and DRIVEN rather than read, with a real D4 sys_user_position row resolved through the actual resolveUserAuthzGrants. Three were live escalations: plugin-sharing answered an org-less manage_sharing holder with every tenant's rules and let it delete platform-global rows; plugin-approvals moved another tenant's PENDING request to approved for a non-slate actor (its rung-first read was no protection, because an OR is only as strong as its weakest arm); runtime's ADR-0126 gate returned 200 and entered toggleFlow for a tenant org admin writing the install-wide activation row under both walled postures. The fourth, plugin-security derivePosture, is a FINDING not a failure: the name-read sits behind an early ctx.posture return that buildContextForUser always populates, so the shipping path was already gated and the D4 row never moved it; what the read did reach is a posture-less hand-built context, where it made the explain panel REPORT PLATFORM_ADMIN for a MEMBER - a misreport, not an admission. All four now read posture === 'PLATFORM_ADMIN'. One PR across all four, no lane split needed. Six existing fixtures that pinned the removed branches were migrated (four gained the rung plus a new name-only refusal arm; two in explain-engine.test.ts were inverted with the reason recorded in place). Single-writer check was measured, not trusted: all 34 open PRs fetched and diffed against their own merge-bases, zero claimants, with a positive control against #16035 proving the scan sees that package. Two half-states to note for the PM: (1) the card carried NO Claim comment when I took it, only the PM hold note, so I posted the claim comment myself per CLAUDE.md's 'the comments decide, not the field' - I never touched the assignee; (2) main moved under the branch mid-round and the PR went 'dirty' on content/docs/permissions/system-context.mdx, the merge=os-regen artifact - resolved with scripts/pm/os-regen-merge.sh (merge, never rebase), regeneration committed separately as that sequence requires, and every reading then re-measured on the merged head.",
  "tests": "All figures at final head a8d29e2a3, each exit code captured immediately after a single redirected command, never through a pipe. TESTS exit 0: plugin-sharing 37 files/910 passed; plugin-approvals 41/690; plugin-security 101/1881; runtime 233/3321. DOWNSTREAM consumers (measured pre-merge at 55b1a28ce, NOT re-run on a8d29e2a3 - stated rather than implied) exit 0: rest 185/3161, verify 10/58, dogfood 132/1023 passed + 3 SKIPPED, and those 3 skips are UNMEASURED not green. TYPECHECK exit 0 for all four including each package's check:test-typecheck over tsconfig.test.json, so the new pins are inside the checked zone rather than merely compiling (two real type errors were found and fixed there, not silenced). DRIVE evidence, pre-fix: sharing pin 3 failed/4 passed with listRules returning srule_victim from a foreign org; approvals pin 3 failed/3 passed with the request at status 'approved', decided:true, while the plain-member floor arm correctly returned FORBIDDEN/pending/not-decided; runtime pin 8 failed/4 passed (200 instead of 403, toggleFlow entered) across both walled postures; security pin only 2 failed/5 passed, and the 3 green shipping-path arms are exactly the already-gated finding. Post-fix all four pins green. ABLATION on site 1, fix committed FIRST so a restore could not silently delete it: HEAD_BLOB=be016b7e73bf4bcd2f2187d88de7c6568cc59cda equals BEFORE_HASH (tree provably at HEAD before mutating); marker counts BEFORE rung=1 name=0 -> AFTER rung=0 name=1, proving the anchor hit rather than a zero-hit no-op; AFTER_HASH=32e67bb19c1e554c5d513c55525a185818a96538 (hash delta = mutation on disk); REBUILD_EXIT=0 so the mutation reached dist/; ABLATED_VITEST_EXIT=1 -> 3 failed/4 passed, the predicted plain-RED direction and the same three arms that were red pre-fix. RESTORE leg proven, not assumed: trap ... EXIT INT TERM with an absolute REPO_ROOT path, then blob equality back to be016b7e..., an EMPTY git diff HEAD, markers back to rung=1/name=0, the restore leg REBUILT, and ablation-dist-preflight confirming the mutation marker absent from dist/ and the fixed code present. Note: my first preflight marker matched my own doc-comment prose in the emitted .d.ts and gave a false hit - the code-shaped marker is the one reported. GATES: family derived mechanically via dispatch-gates.mjs --repo objectstack-ai/objectstack, Reconciliation line authoritative at 59 families; 21 run locally at a8d29e2a3, all exit 0 (nul-bytes, authz-resolver, system-context-census, tenant-audit-census, engine-double-contract, where-matcher, test-source-alias, cross-package-test-inputs, single-claim-paths, objectql-double-limit, tenant-chokepoint, error-code-casing, org-identifier, route-envelope, empty-changeset --base, changeset-no-major --base, changeset-fixed, undeclared-dep-imports, adr-0087-registration --base, error-status-conformance, partof-closing-keyword). NOT MEASURED and named rather than implied green: check-test-completeness.mjs exits 3, and its own text says a bare local invocation is the unreachable-in-CI branch to be recorded as NOT MEASURED, not a red; and the remaining families of the 59 were not invoked locally. Two gates were red and were REPAIRED rather than worked around: check:system-context-census (my added doc comments shifted isSystem read sites and rotted the page's anchors - repaired with the gate's OWN --fix, 12 anchors, never hand-edited, fixpoint proven by a second --fix rewriting 0), and check:engine-double-contract (the new approvals double declared delete/update without the engine's dispatch predicates - now routed through assertEngineDeleteDispatch/assertEngineUpdateDispatch, after which the gate reclassified it as new pinned coverage and --write recorded it; the maintainer-only baseline-exemption path was NOT taken). I assert nothing about CI state.",
  "mcp_calls": "9 - list_pull_requests, add_issue_comment (claim), issue_read get_comments (claim read-back), create_pull_request, pull_request_read x2 (body read-backs), update_pull_request, search_issues (RATE-LIMITED, returned no reading), add_issue_comment (this report)",
  "open_questions": [],
  "out_of_scope_findings": [
    "NOT FILED - handing back to the PM to file, because the mandatory dedup search could not complete: mcp search_issues returned 'API rate limit already exceeded for user ID 318460043', and per the dispatch discipline a dev who hits the limit must return the finding rather than open a card blind. THE FINDING: the same name-read species survives on the TENANT half of plugin-approvals isOverrideActor (packages/plugins/plugin-approvals/src/approval-service.ts, the arm reading positions.includes(BUILTIN_IDENTITY_ORG_OWNER) / BUILTIN_IDENTITY_ORG_ADMIN). It is NARROWER than the four this card fixed and I deliberately did not widen scope into it, but it is not obviously harmless: #15948's own pin header records that a delegate holding manageAssignments passes assertAssignmentWrite's boundSets.every(...) VACUOUSLY for a position carrying no position-bound set, so a delegate who is not a full tenant admin may be able to mint an org_owner-spelled sys_user_position row and thereby gain tenant-admin override authority over approvals in that org. Related to but not the same as #15972 (which is the write-side card). Suggested labels: security, domain:services. Dedup should check #15972 and #15943 first."
  ]
}

Generated by Claude Code

@os-zhuang

Claim: PM loop round R1 — the clause-② declaration re-filed in the documented shape
Session: session_01XpTx2tbq3pZRYAdoGt6E6Y
Branch: claude/issue-15981-positions-name-authority
Domain: domain:services
File surface: packages/plugins/plugin-sharing/, packages/plugins/plugin-approvals/, packages/plugins/plugin-security/, packages/runtime/
Container & model: L, mode:subagent
Clause-②: no — no exported symbol, signature or payload key moves on any of the four packages' published .d.ts; the accept set that narrows is an internal authority predicate, not a published contract's
Serial constraints cleared: none in flight on the four authority sites

Owed to @os-zhuang's landing hold (5556942832), which has been open since 04:39Z. The verdict above it (5556932887) is PASS and needs no re-read — head a8d29e2a has not moved.

The gap was mine. pm-dispatch/SKILL.md:525-536 makes the claim comment step 2 of the PM's atomic pair, first line the literal Claim:, carrying a mandatory Clause-②:. The existing claim (5555995683) opens **Claimed by the os-dev seat.**, which /^\s*>?\s*Claim(?:ed)?\s*:/mi cannot read — ** is not whitespace. I verified that reading against the shipped parser rather than by eye; the full root-cause note is on #16097 (5557652999).

The declaration is my own reading. ⛔ Not a transcription of the verdict — a declaration I merely copied would not be one. The four sites stop deriving platform-operator authority from a NAME in ExecutionContext.positions (which any tenant can mint) and read the ADR-0095 posture rung instead. Nothing is added to or removed from a published surface.

⚠️ Stating the one place a reader could reasonably push back, rather than leaving it implicit: this change does move an accept/reject boundary — that is the whole point of the fix. My reading is that clause ② asks about a contract's accept set (what the platform will parse, accept or expose), and what narrows here is an internal authorization predicate whose pre-fix breadth was itself the security defect. On ADR-0095's own terms the rung was always the authority; the name check was never a contract anyone was owed. So: conformance repair ⇒ no. The director measured the same answer independently across four .d.ts files, which is concurrence rather than my source — and if this reasoning is judged wrong, the correction is a yes plus needs:contract-review on both carriers, not a quiet re-file.

_{domain:services PM seat · claim carrier corrected at the documented spelling; p1 security}

Generated by Claude Code

os-dev-report

{
  "issue": 15981,
  "status": "done",
  "branch": "claude/issue-15981-positions-name-authority",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16148",
  "premise_still_valid": true,
  "summary": "Forward-merge round only -- no content change. The four fix sites are byte-identical to the pre-merge tip (blob hashes equal at a8d29e2a and at the merged head; main never touched any of the four since the merge base), and no pin was moved. Resolved with `bash scripts/pm/os-regen-merge.sh` in a dedicated worktree: merge, never rebase, no force-push. WITH the os-regen driver registered the merge did NOT conflict -- the driver deferred `content/docs/permissions/system-context.mdx` with exit 0 and no markers, which is why GitHub reported `dirty`: GitHub merges driver-less, and a driver-less text merge of that file does conflict. Step 2 took main's side of the census; step 3's ordinary commit was refused by the pre-commit hook, which is that sequence's designed collection point; regeneration followed as its own commit and the hook then printed `current -- marker cleared`. Branch now carries 5 commits: the fix, the first merge, the first census regen, merge commit 4a25f8e76, regen commit b8f8dd59e. Pushed to the same branch; no new PR, branch, card or claim comment. Auto-merge was not touched.",
  "conflict_resolution": "merge base 7beaaa32c. Step 3 was refused TWICE and the two refusals are different: the first was `PREREQUISITE NOT MET -- the dependency typescript is not installed` (a fresh worktree has no node_modules; exit-3 shape, NOT a finding), cleared by `pnpm install`; the second was the designed `content/docs/permissions/system-context.mdx - stale / Regenerate the 1 stale artifact(s) above`. Regeneration ran only AFTER the merge commit had landed (no MERGE_HEAD present), so no generated anchor could roll back to the old fork point. The staged diff was inspected before committing, not the working-tree diff: it is 18 insertions / 18 deletions, purely anchor line-number advances caused by main growing rest-server.ts, engine.ts and domains/packages.ts -- no prose change, no hand edit. The branch's own two entries in scripts/engine-double-contract.pinned.json survived the text merge alongside main's 45 added lines (verified by quoted-exact-name git grep at the merged head).",
  "fixpoint_proof": "pnpm gen:system-context-census run 1: `12 anchor(s) rewritten`, exit 0. Run 2 on the same tree: `0 anchor(s) rewritten`, exit 0. pnpm check:system-context-census (which chains --self-test): exit 0, verdict line `check-system-context-census: OK -- 105 elevation read sites in 19 packages across 44 files, all anchored; 140 anchors resolve, 27 declared non-read; 19 row reference(s) resolve to their keyed row, 2 declared unheld.`",
  "mergeability_measured": "Driver-less bare clone (`git clone --bare --shared`; `git config --get merge.os-regen.driver` exits 1 = undefined there), which is GitHub's own view. `git merge-tree --write-tree b8f8dd59e 1ca95df16` (1ca95df16 = origin/main AFTER it advanced twice more during this run) exits 0 and prints one tree oid 910ccdffb, no conflict lines. POSITIVE CONTROL so that clean result is a measurement, not an absence: the same probe on the OLD head a8d29e2a exits 1 with `CONFLICT (content): Merge conflict in content/docs/permissions/system-context.mdx` against both 7beaaa32c and current 1ca95df16. The branch is behind main again (main moved twice mid-run) -- that is not `dirty`; the merge queue rebuilds against current main.",
  "tests": "All figures re-measured on the FINAL head b8f8dd59e (`git rev-parse --short HEAD` taken from the same runs). Heavy work went through `bash scripts/pm/os-verify-lock.sh`; every exit code captured immediately after a single redirected command, never through a pipe; each lock run's own VERDICT line quoted. SHARED-BOX seconds, not idle-box. (1) Dependency closures for the four packages, `pnpm --filter PKG^... build`: VERDICT command-exit 0, held 337s. (2) Tests, exit 0, VERDICT command-exit 0: plugin-sharing 37 files / 910 passed; plugin-approvals 41 files / 690 passed; plugin-security 101 files / 1889 passed; runtime 236 files / 3344 passed. The last two GREW against the pre-merge body (1881 and 233/3321) -- main landed 8 new plugin-security tests and 3 new runtime files; nothing was lost. (3) Typecheck, all four, exit 0, VERDICT command-exit 0, with each package's script name echoed so no zero-match pnpm filter could green silently; each check:test-typecheck reports OK -- sharing 2 files / 3 errors / 3 pinned, approvals 8 / 324 / 27, security 0 / 0 / 0, runtime 27 / 191 / 69, all at their recorded numbers. (4) Gate family re-derived mechanically ON THE FINAL HEAD: `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands`, exit 0, first line confirms `derived from the tree of objectstack-ai/objectstack at commit b8f8dd59e` and the --repo assertion holds. It yields 97 commands -- far more than the 21 in the PR body, because this merge brought main's 369-line rewrite of dispatch-gates.mjs itself. All 97 were run and all 97 exit 0. Four were non-zero on first pass and every one was converted into a REAL measurement by satisfying the prerequisite it named, none waived: check:skill-examples exit 1 (packages/client-react had no dist -- the gate refuses rather than green falsely) then exit 0 after building it, verdict `257 prose examples type-check across 3 surface(s)`; check:i18n exit 3 (PREREQUISITE NOT MET, named its whole closure in one command) then exit 0, `check-i18n-bundles: OK (9 package(s) -- all bundles in sync)`; check:dual-build-cjs-loads exit 3 (35 packages had no dist) then exit 0 after a full build, `103 published require entry point(s) across 66 package(s) load`; check:type-check-debt exit 3 (--re-measure refuses without the built closure) then exit 0, `12 ledger entr(ies) re-measured in 99.7s, 140 raw tsc error(s) total, none above its recorded number`. Nothing is left as NOT MEASURED locally. No ablation was run or claimed this round -- this is a merge, no implementation byte moved, and the PR body's existing ablation record stands against source that is byte-identical here.",
  "not_re_run": "The downstream consumer suites the PR body lists (rest, verify, dogfood) were NOT re-run on the merged head -- they were outside the dispatch list and are named here rather than implied green. CI runs the farm exactly once regardless.",
  "mcp_calls": "3",
  "open_questions": [
    {
      "question": "The PR body still says its figures were re-measured on `current head a8d29e2a3` and that the branch carries three commits. Both are now stale, and with SQUASH auto-merge armed that body becomes main's commit message. Refresh it?",
      "options": [
        "A. PM (or a follow-up round) refreshes the Verification and Merge-with-main sections with the b8f8dd59e figures above.",
        "B. Leave the body as reviewed and let this comment carry the second round's record."
      ],
      "recommendation": "A, but NOT done here on purpose: the body is long, contract-reviewed and PASSED, a body edit is a full-text replace, and AGENTS.md warns that a rewrite destroys a correct card. Handing it back rather than risking it."
    }
  ],
  "out_of_scope_findings": []
}

Generated by Claude Code

os-closed-card-sweep — machine-findable marker for this generated comment.

Removed the pm-loop state label(s) this closed card no longer claims: pm:dispatched.

Closing pull request: fix(sharing,approvals,runtime,security): platform authority is the posture RUNG, never a name in positions[] #16148, merged.
Closing commit ac6213ee95, merged into main.
Left untouched: bug, priority:p1, security, domain:services, finding — ownership, priority and outcome are not state claims.
The label set was read back after the write and matched.

A state label claims work is in flight. This card is closed on a merged delivery, so the claim
is stale; every other label is left exactly as it was found. Nothing here is a judgement about
the card, and no verdict-bearing label is ever touched by this sweep.

posted by half-state-patrol run 34055667490 · trigger schedule

Generated by Claude Code

fix(sharing,approvals,runtime,security): platform authority is the po…

Navigation Menu

Repository navigation

Four server-side readers derive platform authority from the NAME in `ExecutionContext.positions` — same species as #15948's blocked escalation, and already reachable on `main` #15981

The four sites

Why this is the same species as a blocked escalation

What the taker owes, in order

Scope note

Dedup

Related

The collision, measured

Why not just split the card

Unlock condition — ⛔ measure the tree, never a PR's own state

Hold condition, re-measured on the tree (not on any PR's own state)

Single-writer check — CLEAN, and measured rather than trusted

Sites re-located on current head

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Four server-side readers derive platform authority from the NAME in ExecutionContext.positions — same species as #15948's blocked escalation, and already reachable on main #15981

Description

The four sites

Why this is the same species as a blocked escalation

What the taker owes, in order

Scope note

Dedup

Related

Activity

os-warren commented on Sep 5, 2026

The collision, measured

Why not just split the card

Unlock condition — ⛔ measure the tree, never a PR's own state

os-warren commented on Sep 6, 2026

Hold condition, re-measured on the tree (not on any PR's own state)

Single-writer check — CLEAN, and measured rather than trusted

Sites re-located on current head

os-warren commented on Sep 6, 2026

os-warren commented on Sep 6, 2026

os-warren commented on Sep 6, 2026

github-actions commented on Sep 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Four server-side readers derive platform authority from the NAME in `ExecutionContext.positions` — same species as #15948's blocked escalation, and already reachable on `main` #15981