Stage spec proposal text and validate before creating public issues

[JacobStephens2]

Summary

Spec-sized public Security fixes now stage their proposal text and get it validated before any public issue exists. Thirdshift creates the issues and their native links from the staged text.

security-fix publishing (public spec)
  sweep session-created issues -> close leak + fail
  parse staged spec (top issue + Tickets + blocked-by edges)
  validate every staged text vs the private record
  create top issue (needs-triage)
  create Tickets (ready-for-agent)
  link native sub-issues + blocked-by edges
  mark ready + security-fix, dispatch Spec run

Seams exercised: secure security-fix end to end for a public spec; the staged-spec protocol parse; the existing check_public_fix_text validation.

Evidence

• Before: a spec-sized public fix was published by the session itself (gh issue create), and thirdshift validated only after creation — write-up text copied into an issue was already public before any rejection.
  After: cargo test green on the final tree — all 41 targets ok (956 bin unittests; security_run 92 passed, including the new staged-spec tests; spec_run 68 passed), 0 failed. Focused runs: a_bigger_public_fix_publishes_tickets_and_ends_as_the_spec_run, invalid_security_fix_specs_are_not_marked_ready_or_dispatched (rejected staged specs create zero public issues), and a_spec_session_side_effect_public_issue_fails_the_fix_and_is_closed (side-effect leak closed, fix fails loudly) all pass.

Merge Danger

Door: two-way — reverting restores session-created spec publishing; no migrations, no data changes.

Blast Radius: security-fix publishing — changes secure security-fix for spec-sized findings on public repositories only; the private-repository path is unchanged.

Unaddressed findings

Standards

1. Duplicated Code — parse_staged_proposal (src/security/fixing.rs:340) vs parse_staged_spec_proposal (src/security/fixing.rs:219) share the marker / Title: / Body: shape. Declined as a non-blocking judgement call (the reviewer itself would not block): the single-issue and spec-with-tickets protocols evolve separately, and a shared splitter would couple them. Refuting runs: staged_proposal_parses_title_and_body and staged_spec_parses_top_issue_and_tickets_with_blocking both pass; full suite green. This is my technical call, not a Spec or Day-shift decision, so no needs-triage issue was filed.
2. Repeated Switches on FixSize (src/security/fixing.rs:102, :126, :159). Declined: polymorphism would be heavier than three small branches at this size and matches the file's existing style. Refuting runs: the single and spec end-to-end paths (staged and private) are all green in security_run (92 passed). My technical call, so no needs-triage issue was filed.

Addressed rather than listed: the third Standards smell (add_sub_issue / add_blocked_by duplication) was fixed — both delegate to the private GitHub::post_by_id (src/github.rs:218), covered by the staged-spec happy-path test.

Spec

None. The review filed no Spec findings; its one robustness observation (a Ticket body containing the literal substrings Ticket: or Blocked by: fails closed, rejecting the proposal without leaking anything) is safe by construction and needs no Day-shift decision, so no issue was filed for it.

Review coverage: both axes read all 7 changed files. No changed file was left unread by the review.

Closes #647

Built with muse · default model · default effort