hostile-content-quarantine: neutralize is step 1, not approval-gated

Context

On 2026-06-15 the operator flagged an astroturf comment on #13352 (an external NONE-association account's credibility-then-backlink Trojan — a plausible gh-auth answer terminating in a vendor backlink + a risky --show-token "fix") and asked me to run /hostile-content-quarantine. I followed the playbook's order: §3 "warn the swarm immediately" then §6 "moderation is operator-owned (Tier-4), present the matrix, never execute unilaterally." The result was a process-safety failure: I (a) broadcast a swarm warning that referenced the live issue — pointing peers AT the un-neutralized hostile comment — and (b) presented a moderation matrix and asked the operator for approval, leaving the hostile content live for 5+ minutes.

Operator correction (verbatim intent): "FIRST STEP is to quarantine or delete. you do NOT need my approval for that. if there is anything value inside, keep only those parts, otherwise full delete." The agent has maintainer perm and deleted the comment immediately once corrected.

The Problem

The playbook's step order inverts the safety priority. Two coupled defects:

1. §6 "moderation operator-owned (Tier-4), present-don't-execute" treats the neutralize ACTION as operator-gated. For clear-hostile content (marker set fired, operator-flagged, or high-confidence) with maintainer perm, the neutralize is within agent agency — gating it behind operator approval leaves dangerous content live (the 5+ min window) and contradicts the operator's "you do NOT need my approval."
2. §3 "warn the swarm immediately" ordered BEFORE neutralization means the warning carries a live pointer to the un-neutralized hostile content — "spreading the link is like spreading a virus" (operator). The warning must come AFTER neutralization.

The §6 Tier-4-operator-ownership framing is over-broad: it should own the JUDGMENT calls (good-faith-vs-hostile classification when uncertain; keep-redacted-vs-full-delete value), NOT the neutralize ACTION on clear-hostile content.

The Architectural Reality

• .agents/skills/hostile-content-quarantine/references/hostile-content-quarantine-workflow.md §3 (Don't engage / warn the swarm) and §6 (Moderation matrix — operator-owned, present-don't-execute) are the two sections to reorder.
• The agent has maintain: true (verified via gh api repos/neomjs/neo --jq .permissions) — sufficient to delete/redact a third-party comment via gh api. The current §6 wording discourages using it.
• The §1 calibration (good-faith-vs-hostile is Tier-4) is correct and stays — it's the CLASSIFICATION that's operator-owned-when-uncertain, distinct from the neutralize action once classified hostile.

The Fix

Reorder the playbook to a neutralize-first sequence:

1. STEP 1 — Neutralize. For content classified hostile (marker set + §1 calibration, or operator-flagged), the agent (with maintainer perm) immediately deletes — or redacts to keep only genuinely-valuable parts (operator's "keep only those parts; otherwise full delete"). No approval gate. If the agent lacks perm, escalate to the operator as a blocker (the only branch where neutralize waits).
2. STEP 2 — Warn the swarm AFTER neutralization. The don't-engage broadcast must reference the now-neutralized artifact, never a live pointer/link to un-neutralized hostile content.
3. STEP 3 — Ingestion clock + record (current §5/§7/§8, unchanged).

Narrow the operator-Tier-4 ownership (revise §6) to ONLY: (a) the good-faith-vs-hostile classification when genuinely uncertain (§1), and (b) the keep-redacted-vs-full-delete VALUE judgment for ambiguous cases. The neutralize ACTION on clear-hostile content is agent-agency.

Decision Record impact

none (no ADR; a skill-playbook process-safety fix under Epic #10291).

Acceptance Criteria

• The workflow's step order makes neutralize (delete/redact) STEP 1, within agent agency for clear-hostile content with maintainer perm — no operator-approval gate.
• The swarm-warning (§3) is explicitly sequenced AFTER neutralization and forbidden from carrying a live pointer to un-neutralized hostile content.
• §6 is revised so operator-Tier-4 ownership covers classification-uncertainty + the keep-vs-delete value judgment, NOT the neutralize action.
• The #13352 incident is added as an empirical anchor (the 5+ min live-content + link-spread failure).
• Net loaded-bytes: the change is a reorder + a narrowed §6, roughly byte-neutral (substrate-accretion symmetry).

Out of Scope

• The link-defang machinery (#10476 P8) — this is the human-playbook ordering, not the mechanical quarantine.
• The KB tier-taint / sync-denylist (#12995) — orthogonal.
• The good-faith calibration (§1) — stays as-is (classification-when-uncertain is correctly Tier-4).

Related

• Parent: Epic #10291 (organism self-defense substrate).
• Empirical anchor: #13352's astroturf comment (2026-06-15) — the live-content + link-spread incident.
• Machinery: #10476 (link quarantine), #12995 (KB taint + denylist).
• Skill file: .agents/skills/hostile-content-quarantine/.

Handoff Retrieval Hints

• Retrieval Hint: "hostile-content-quarantine neutralize-first delete-before-warn operator-approval-gate #13352 astroturf"
• The eventual skill edit must consult create-skill (Progressive Disclosure) + turn-memory-pre-flight (it is .agents/skills/ substrate).

Live latest-open sweep: checked open issues at 2026-06-15 (~15:41Z); only #10476 (machinery) + #10291 (parent epic) are adjacent — no equivalent playbook-ordering ticket. KB semantic sweep skipped (KB collections were down earlier this session); live + grep sweeps sufficient.

Release classification: boardless (skill process-safety fix; not release-gating; v13 shipped).