[PM seat] security — 🟢 os-sales #29740

security#1 · os-sales · session_01L6bhgVfjk2i8T2D4RmxsKg

⚠️ Seat stub. Job description: .claude/skills/pm-dispatch/references/lanes/security.md (⛔ not copied here). Never-public rules: .claude/skills/pm-dispatch/references/security-findings.md. This is security seat 1. This post carries no finding, path, object name or mechanism, by rule.

Current PM — 🟢 os-sales

• Holder: os-sales · session_01L6bhgVfjk2i8T2D4RmxsKg · seated 2026-11-05T10:45Z, on the maintainer's summons in the project (「接手 security 车道」), after the previous holder's clock-out brief (the latest event, so no takeover race). Run by the os-sales account's project.
• Advisory access: the relay advisory_read opened a sealed answer in this session (run 42013075070, state and counts only, nothing printed).
• Session effort: below high as set by the project; noted per seat-lifecycle.md.
• Patrol: trig_01YS6drHYT3ZaoxSo6Zp9tJF · 42 * * * *
• Mailbox: PR pm:mailbox — security#1 · os-sales #30424
• Previous holder: os-justin · session_01QSeKYn5CmmdShCJifm6WYj · clocked out 2026-11-05T07:48Z; the previous body revision (edited 2026-11-05T07:48:58Z) is the archive.
• Posture and round reports live in the project. Ledger rule: one row per advisory, opaque id · session · state, ⛔ no detail. Claims on advisory fixes live here, never in session memory.

Ledger

Standing orders (inherited: the maintainer's, given in the previous holder's session session_01QSeKYn5CmmdShCJifm6WYj, verbatim):

• 「目前的修复都关闭」 and 「你处理完的可以都先关闭」: once an advisory's fix merges, the seat closes it through the relay advisory_state and records it here.
• 「哪些高危要发布应该在我版本发布前决策吧」: before each version release, the seat puts a publish-or-not list to the maintainer, covering the closed advisories since the last release (high and moderate first), reviewed at CONTRACT_REVIEW_TIER first. Publishing is the maintainer's: they reopen and publish in the advisory UI, since the relay cannot move a closed advisory.
• 「同意,batch 调到 5」: the previous holder ran at most 5 slots. This holder's account runs at most 4 per seat (its maintainer's word in the project at 2026-11-05T21:32Z, latest wins).
• 「只记录,暂停派发」 (2026-11-04), lifted by 「可以继续派发」: the fourth and fifth decision batches are ruled and recorded in the seat's private notes, and dispatch has resumed.
• 「changeset 改写确认都同意」 (2026-11-05): a pending-changeset DELIBERATE CORRECTION lands on the seat's own record, as landing-operations.md already says (the ACCEPT quoting before and after, or the same-head at-tier PASS). The seat does not wait on the maintainer for it. Skills card: pm-dispatch skills: say who confirms a pending-changeset correction (the seat's record, never a maintainer wait) everywhere a dev or the gate is told to "get it confirmed", and keep PR bodies from narrating pre-fix behaviour on security fixes #30271.

Inherited handover (previous holder's clock-out 2026-11-05T07:48Z, taken on as written)

In flight: dev done, contract review owed. Each PR carries its at-tier records so far; each needs a review on its current head and then landing.

• ✅ merged by this holder: fix(core)!: a banned user's credentials are refused while the ban holds, at every door #30287 f4cd4ec879, fix(plugin-security): a by-id write's row re-read propagates a store fault, and judges the platform's own predicates without the caller-predicate guard #30307 70981e63ed, fix(runtime,plugin-auth)!: a banned user's OAuth access tokens and refresh grants are refused while the ban holds #30360 b3d2f4bdb7 and fix(plugin-security, plugin-auth)!: a person-to-permission-set assignment refuses an agent ceiling set at every write door, and so does the self-registration permission set #30578 6dd2ca5788 (at-tier FAIL → findings commit → delta PASS → ACCEPT → queue). Original handover entries follow.
• fix(core)!: a banned user's credentials are refused while the ban holds, at every door #30287 (the API-key half of the high advisory above). PASS at 15b303e0bf (comment 6650521523). Two findings commits since; head f064a0e418. Owes a delta review by an at-tier reviewer, then ACCEPT and landing.
• fix(runtime,plugin-auth)!: a banned user's OAuth access tokens and refresh grants are refused while the ban holds #30360 (the OAuth half of the same advisory). Stacked on fix(core)!: a banned user's credentials are refused while the ban holds, at every door #30287, with its base the R4 branch. Once fix(core)!: a banned user's credentials are refused while the ban holds, at every door #30287 merges: rebase onto origin/main per the note in its body, retarget to main, run the gates, then a full at-tier review. Not reviewed yet.
• fix(plugin-security): a by-id write's row re-read propagates a store fault, and judges the platform's own predicates without the caller-predicate guard #30307 (the by-id write row re-read: store faults propagate, and platform predicates skip the caller-predicate guard). FAIL at b6b340a3db (comment 6650951607), on public text only. The findings commit cc1fbac302 and the replacement body address it; owes a delta review.

Waiting on the maintainer (analyses are in the previous holder's session notes, which this holder cannot read; each item stays open for the maintainer; each item was fable-reviewed before it was put):

• Batch 7: three items (transfer requires read; explain answers existence-blind; capability-layer write-implies-read).
• The fix shape for the high advisory received earlier (see its ledger row).
• The high advisory above: three items (a revoke switch on the ban act; refusing a credential whose owner row is gone; the answer shape for a banned owner's credential).
• Whether the controlled-by-parent master read should also propagate a store fault (fix(plugin-security): a by-id write's row re-read propagates a store fault, and judges the platform's own predicates without the caller-predicate guard #30307 open question; an older ruling note keeps its catch-all).
• Deleting the old PR-body revisions on fix(spec)!: an object permission that edits or deletes a record also reads it #30180 and fix(plugin-security)!: a write from a caller the read door refuses is refused, whatever rows it addresses #30219 (GitHub UI).
• The id of the draft change-email notice, and pasting its corrected description.

Next orders, not yet dispatched:

• The medium advisory above: covered by the server lane's PR fix(plugin-auth)!: clearing an authentication setting, or resetting the namespace, takes effect at once (#30312) #30447; no order of this seat.
• plugin-auth: an MCP JWT access token cannot be revoked — /oauth2/revoke answers 400 and delete-consent ends nothing, against IAuthService.verifyMcpAccessToken's 'falsy when revoked' (objectstack-ai/cloud#3606 ruling A) #30345 (p1; MCP access tokens cannot be revoked; the platform half of a cloud ruling). It touches the same verification point as fix(runtime,plugin-auth)!: a banned user's OAuth access tokens and refresh grants are refused while the ban holds #30360. Dispatch after fix(runtime,plugin-auth)!: a banned user's OAuth access tokens and refresh grants are refused while the ban holds #30360 lands, or fold it in.
• From the fix(runtime,plugin-auth)!: a banned user's OAuth access tokens and refresh grants are refused while the ban holds #30360 dev's census: the OAuth userinfo and introspection endpoints for a banned subject (one security order, after fix(runtime,plugin-auth)!: a banned user's OAuth access tokens and refresh grants are refused while the ban holds #30360). The ban docs and the Ban User copy gain OAuth credentials once fix(runtime,plugin-auth)!: a banned user's OAuth access tokens and refresh grants are refused while the ban holds #30360 lands.
• Skills cards pm-dispatch skills: say who confirms a pending-changeset correction (the seat's record, never a maintainer wait) everywhere a dev or the gate is told to "get it confirmed", and keep PR bodies from narrating pre-fix behaviour on security fixes #30271 and pm-dispatch SKILL.md: the seat invariant still names MCP rerun_failed_jobs as the one allowed MCP write, while a re-run leaves only through the relay #30159, filed and not yet dispatched.

Hot-file serial queue

⛔ Re-derive from live claims and each open PR's file list before every dispatch.

• None held as a lane: fixes land in their owning packages through no-card orders.
• The skills-lane cards on lanes/security.md and security-findings.md that the previous holder queued (pm/fleet-write: the relay publishes a security advisory on the maintainer's list: reopen, set the affected and patched versions, publish #30110, pm-dispatch skills: the security seat's triage of a non-finding, its ledger states after the close-on-merge order, a release's contents read by ancestry, and the CI recoveries the relay leaves #30111) are both closed; nothing is held on those files.

Notes

• Write path: the relay (post-stamped.mjs, label-write.mjs, issue-create.mjs, fleet-write/dispatch.mjs). ⛔ No GitHub MCP writes. Advisory text is read only through the relay advisory_read.
• domain:skills#2 ([PM seat] domain:skills · seat 2 — ⏳ vacant #19287), held by the previous holder's session for the security work's skills-lane cards, was handed back once they landed (clock-out brief 6598110373).