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

security#1 · os-justin · session_01QSeKYn5CmmdShCJifm6WYj

Why

references/landing-operations.md already states the rule (#19970, #23257): a check-empty-changeset DELIBERATE CORRECTION red does not wait for the maintainer. The confirmation is the dispatching seat's own record:

• For a text-only diff: the ACCEPT, quoting each note before and after.
• Otherwise: the same-head at-tier contract-review PASS, which judges each corrected sentence.

The texts a dev and a seat actually meet do not say this.

• The gate's remedy line. FOREIGN_CORRECTION_REMEDY in scripts/check-empty-changeset.mjs reads "get it confirmed on the PR". It does not say by whom.
• The os-dev side. .claude/agents/os-dev.md and references/execution-duties.md do not say who confirms. On 2026-11-05 three security PRs carried "please confirm" asks addressed to the maintainer in their bodies (fix(plugin-auth): a verification-email resend from a visitor who is not signed in answers the same whatever the send does #30144, fix(plugin-security): an assignment write the administrator cannot address answers not-found, as a read does; a refusal names only values the caller can read #30165, fix(plugin-security): an organization administrator's assignment removal is judged on the stored row, and its refusal names only values the caller can read #30248). The security seat waited on the maintainer for each one and held the landings until the maintainer answered.

The maintainer has now said, in the security seat's session, verbatim: 「changeset 改写确认都同意」 (2026-11-05). This restates the existing rule. It does not create a new one.

Changes

1. Gate remedy text. FOREIGN_CORRECTION_REMEDY (scripts/check-empty-changeset.mjs) names the confirmer by pointing at landing-operations.md (the seat's ACCEPT or its same-head at-tier PASS record). Keep the one-source / two-renderings construction and its self-test assertions in step. Keep the verdict unchanged: the class stays refused, and only the remedy wording moves.
2. The dev's side. references/execution-duties.md, or os-dev.md if that is where PR-body duties live, says:
   • A dev who corrects a pending note declares it on the PR as a DELIBERATE CORRECTION, naming each note and quoting the corrected sentences.
   • ⛔ The dev does not ask the maintainer to confirm it. The dispatching seat's record confirms it.
3. Security PR bodies state the rule, never the pre-fix path. This goes in references/security-findings.md §6, or in the os-dev pointer to it. Twice this week a security fix's PR body narrated what the code did before the fix (fix(spec)!: an object permission that edits or deletes a record also reads it #30180, fix(plugin-security)!: a write from a caller the read door refuses is refused, whatever rows it addresses #30219), and the contract review failed it on §6. The rule to add: on a security fix, the PR body, its Verification section and its ablation notes describe the rule and the counts ("red, then restored"). ⛔ They never describe what the unguarded code does. That detail goes in the dev's private security_findings only.

Acceptance

• Each rule lives in the one reference that owns it, with no restatement. The hot files' line ratchets are respected.
• check-empty-changeset's self-test is green, and its verdicts are unchanged.
• The skills gates the diff derives are green.
• lanes/security.md and security-findings.md still carry no finding, id, path, object or mechanism.