Hand every child Run one set of child asks, built once after the Harness check

[JacobStephens2]

Summary

A Run builds one ChildAsks value after its Harness check: the Command's checked Harness, Model and Effort, its Security fix ask and its Security review ask. Every child Run is handed that same value unchanged.

flowchart LR
  Asks --> Run
  Run -->|after Harness check| ChildAsks
  ChildAsks --> Delivery
  Delivery --> BaseFix[Base fix]
  Delivery --> SpecRun[Spec run]
  BaseFix --> Start[child_run::start]
  SpecRun --> Runs[child Runs] --> Start
  Start --> Given

Loading

 run(issue, asks, started_by, base_fix)
   if started by its command: asks.harness.check()
-    base_fix.runs_on(asks.harness.clone())        # re-sync of the early copy
+  child_asks = ChildAsks::of(asks)                # built once, after the check
-  security_review = asks.security_review && !Ticket
+  security_review = child_asks.runs_security_review(started_by.child())
   Delivery { security_review, child_asks, .. }    # was security_fix + harness
-    BaseFix::new(child, ask, harness, security)   # kept its own Harness and Security options
+    BaseFix::new(child, ask)                      # child asks arrive per call
+    base_fix.fix(LaunchAndGitHub { launch, issue, asks: child_asks }, ..)
-    Spec run: security_fix, security_review, harness → Options { .. } per Ticket
+    Spec run: children.start(ticket, kind, base_fix_ask, child_asks)

security::Options is deleted. Given carries asks: ChildAsks, and its hidden arguments are the same as before. The Security review entry in GLOSSARY.md now says a Base fix gets one when its Command asked for one, whichever Run started it. docs/code-navigation.md points to ChildAsks.

Seams under test

• ChildAsks::runs_security_review: whether a Run runs its own Security review, for each child kind.
• Given::to_args / Reader: the round trip of what a child Run is given.
• The CLI end to end, through the fake gh and Harness: a Run's Base fix, and a Spec run whose Ticket starts a Base fix.

Evidence

• Unit: only_a_ticket_s_run_skips_the_security_review_the_command_asked_for checks none, Ticket and Base fix, with the Command's Security review ask on and off.
• Unit: what_a_child_run_is_given_reads_back_as_written_around_its_issue_url_and_a_flag now crosses all four Security fix and Security review pairs with every Base fix ask, on both child kinds.
• Integration: base_fixes_inherit_the_security_review_choice (tests/security_review.rs) now asserts that Base fix Keeping the PR mergeable: merge the Base branch and conflict Repair #8's fourth session is a guidance Security review of issue-8 against main.
• Integration (new): a_base_fix_a_tickets_run_starts_runs_the_security_review_its_ticket_skips (tests/spec_run.rs) runs with base-fix security-review. Sessions by issue are 21, 22, 22, 20, 20: the Ticket has no review, its Base fix has one on issue-22 against issue-20, and the Spec PR has one.
• Integration (unchanged, green): security_review_runs_once_after_spec_review_over_the_whole_spec_branch still sees exactly one review, on the Spec PR.
• cargo fmt --check, cargo clippy --all-targets -- -D warnings and cargo test: all pass (cargo test: 0 failed across every target; the unit suite is 1115 passed, 2 ignored).

Merge Danger

Door: two-way

An in-process re-plumbing that keeps behaviour. A parent and child Run are always the same binary, so the unchanged hidden arguments carry no cross-version risk.

Blast Radius: child-Runs

A mistake would show up as a child Run on the wrong Harness, or a Security review run or skipped wrongly. The tests above pin each of those rules.

Review

Both axes read every changed file. No changed file was left unread, and no generated output was excluded.

Fixed from the review:

• Standards: the StartedFrom copy of the Base fix's LaunchAndGitHub fields is deleted. BaseFix::fix takes its LaunchAndGitHub directly.
• Standards: ChildAsks derives Default for test fixtures.
• Spec: the StartedFrom scope note is resolved by the same deletion.

Unaddressed findings

Standards

• Asks still holds harness, security_fix and security_review as loose fields, a half-bundled clump. Refuted by the issue's plan decision "Asks keeps its flat fields… The child asks are derived from Asks once, and a child's Asks are rebuilt from them in the one existing place" (src/asks.rs Asks::of_child_run; src/child_run/asks.rs ChildAsks::of).
• security_review: bool sits beside child_asks.security_review in the Delivery and the Run's LaunchAndGitHub. Refuted by the acceptance criterion "Its own Security review ask stays a separate fact". Each field's doc names it as the Run's own: src/delivery.rs Delivery::security_review ("Whether the opening session is followed by a guidance Security review") and src/run.rs LaunchAndGitHub::security_review ("Whether the Run runs its own Security review").
• child_asks.harness is also the Run's own Harness (naming). Refuted by the plan decision "The Delivery's own sessions run on the child asks' Harness. One Harness per Command is already a glossary rule, so a separate Harness field on the Delivery would only duplicate it."
• runs_security_review might belong on Kind (Feature Envy). Refuted by the acceptance criterion "The child asks module answers whether a Run started as a given child kind (none, Ticket or Base fix) runs its own Security review."

Spec

• docs/code-navigation.md gained a ChildAsks row (minor scope note). Kept. AGENTS.md has issue terms located through the domain-to-code index, and that row is where "which Runs run a Security review" is now found.

Closes #876

🤖 Generated with Claude Code

Built with claude · claude-opus-5-5 · medium

Security review outcome

No unaddressed introduced findings.