phase4-ablation

name

phase4-ablation

description

Main Agent orchestration skill for Phase 4 — taking the Phase-3-validated framework_v{m}.md and latest story_check and producing per-variant ablation evidence that sharpens contribution attribution. Load when phase3-exit-check PASSed with dominant rollback depth None and a handoff-compatible story check, and Phase 4 has not yet produced a fully analyzed set of variants; also load on re-entry after Loop 4 supplementary ablation additions (Case B) or after a phase4-exit-check NEEDS-REWORK (Case C). Drives: (i) plan design via ablation-designer, (ii) per-variant spec delta via method-architect ↔ spec-confirmer, (iii) per-variant code upgrade via the per-module Coder ↔ Fidelity loop with carry-forward from Phase 3, (iv) per-variant run-experiment + experiment-analyst + story-coherence-advisor Context C checkpoints. Hands off to phase4-exit-check. Does NOT rerun Phase 3 main-results cells.

Phase 4 — Ablation Pipeline

You are the Main Agent running Phase 4. Your role is to take Phase 3's validated framework_v{m}.md and the latest story_check_{k}.md and drive a per-variant ablation sweep that sharpens (or refutes, or redirects) each contribution bullet's attribution claim. You orchestrate four sub-processes in order: plan design, per-variant spec delta, per-variant code upgrade, per-variant execution with narrative checkpoints. You do not design ablation variants yourself, do not write spec deltas, do not interpret results, and do not decide whether Phase 4 is done — those are agent / skill responsibilities downstream.

Scope boundary. Phase 4 produces attribution evidence: which components actually drive the effects Phase 3's Main Results measured. It does NOT rerun the Phase 3 main-results matrix, does NOT add new datasets or baselines (that is an Experimental-Setup-revisit or a Phase 3 Case B), and does NOT write the paper (that is Phase 6). If a variant surfaces a finding that implies the Phase 3 framework is wrong rather than an ablation-attribution question, surface to the user — do not silently escalate here.

Transparent-relay rule. Between agents (Ablation Designer / Architect / Confirmer / Coder / Fidelity Checker / Analyst / Story Advisor) you are a pipe, not a participant. You do not rewrite their outputs, do not add your own assessments between rounds, do not pre-filter findings. Your active decisions are: case entry, precondition checks, loop convergence detection, per-variant iteration, and deadlock escalation.

---

Entry — Identify the case

Before starting, determine which entry case applies:

Case A — Fresh entry from Phase 3 exit phase3-exit-check returned PASS, latest story_check is COHERENT or FRACTURED-scoped-to-Phase-4, no Phase 4 artifacts yet exist (phase_4_ablation/plans/ is empty). This is the normal path.

Case B — Re-entry after Loop 4 supplementary ablation Phase 5/6 review raised attribution-style issues (reviewer asked for a specific ablation; Writer surfaced a contribution bullet that needs sharpening), the Main Agent chose to add variants rather than reframe. An ablation_plan_v{n}.md already exists; the invocation brief names the specific additions (new variants, or revisions to existing variants' cell scope).

Case C — Re-entry after a Phase 4 rollback (via phase4-exit-check) phase4-exit-check returned NEEDS-REWORK with a non-None rollback depth for some variant, or the latest Story Advisor Context C pass returned FRACTURED (non-scoped). The Main Agent chose to address a Phase 4-internal issue (code bug in one variant, a failed variant that needs rerun). The brief names what to redo.

If no case matches — e.g., Phase 3 never passed, or a framework_v{m}.md exists but no story_check is on disk — halt and ask the user which case applies. Do not guess.

---

Preconditions (all cases)

Verify before any sub-process invocation:

1. Phase 3 has passed. A phase3-exit-check PASS block is in the session log, and the latest phase_3_main_experiment/story_checks/story_check_{k}.md has Verdict COHERENT or FRACTURED-scoped-to-Phase-4.
2. Framework spec is locked. phase_3_main_experiment/specs/framework_v{m}.md exists with an ALL CLEAR confirmer report. This is the base that per-variant spec deltas modify.
3. Phase 3 code is on disk. phase_3_main_experiment/code/ contains the ALL-CLEAR-fidelity modules. Phase 4 variants carry forward most modules from here. If Phase 3 code is missing, halt — Phase 4 cannot proceed against phantom code.
4. Execution environment configured. Phase 4 invokes run-experiment once per variant launch; each call will re-verify the four-point execution contract, but check once upfront to halt early if the environment is unconfigured.
5. Working directories. Create if missing:
   • phase_4_ablation/plans/
   • phase_4_ablation/specs/
   • phase_4_ablation/code/
   • phase_4_ablation/fidelity/
   • phase_4_ablation/results/
   • phase_4_ablation/analysis/ (Story checks continue to land at phase_3_main_experiment/story_checks/ — unified across Contexts A/B/C per the Story Advisor's design. Do NOT create a separate phase_4_ablation/story_checks/ directory.)

On any precondition failure, halt and report the specific failing item.

---

Sub-process 1 — Plan design (Ablation Designer)

Case A: run in full. Case B: run scoped to the named additions. Case C: skip unless the brief names a plan issue.

Step 1 — Invoke the Ablation Designer

Compute {n} — the next plan index:

n = count(phase_4_ablation/plans/ablation_plan_v*.md) + 1

Invoke ablation-designer with the appropriate case brief:

Case: A (fresh Phase 4 entry) | B (revision — new story_check or Loop 4)
Source story check: phase_3_main_experiment/story_checks/story_check_{k}.md
  (latest; must be COHERENT or FRACTURED-scoped-to-Phase-4)
Framework spec: phase_3_main_experiment/specs/framework_v{m}.md
Phase 3 analyses: phase_3_main_experiment/analysis/analysis_*.md
IDEA: phase_0_ideation/ideas/IDEA.md
Output: phase_4_ablation/plans/ablation_plan_v{n}.md

[Case B only: previous plan at phase_4_ablation/plans/ablation_plan_v{n-1}.md
and any Phase 4 analyses at phase_4_ablation/analysis/analysis_*.md.
Revise; do not re-open already-finalized variants unless the new
story_check explicitly invalidates them.]

[Case B only: scope additions per this brief: {list from caller}.]

Wait for the Ablation Designer to finish. Confirm ablation_plan_v{n}.md exists.

Step 2 — Surface the plan for user confirmation

Read the plan's Summary, variant count by priority, and flagged items (Unusable bullets, Uncovered bullets). Announce to the user:

Phase 4 ablation plan — v{n}

Summary: {read the Summary paragraph}

Priority distribution: Critical {c} / High {h} / Standard {s} / Optional {o}

Flagged:
- Unusable bullets (blocked on Story Advisor): {count} — {handles}
- Uncovered bullets: {count} — {handles}

Variants to run (defaults to Critical + High):
{variant handles by priority}

Options:
(a) Proceed with defaults (Critical + High variants).
(b) Proceed with a different subset — name which variants.
(c) Pause — Main Agent should address Unusable bullets first (route
    back to Story Advisor Context B to revise bullets, then re-invoke
    this skill as Case B).
(d) Pause — Main Agent should resolve Uncovered bullets first
    (typically a Story Advisor Context B re-invocation to refine
    attribution claims).

Wait for user confirmation. The selected variants become the Phase 4 execution set. Record the set in the session log. Standard and Optional variants not selected are not deleted from the plan — they remain on-disk as future-work candidates.

If the user picks (c) or (d), halt Phase 4 and route per their direction. Do not proceed to Sub-process 2 until Unusable / Uncovered bullets are resolved upstream or explicitly waived.

---

Sub-process 2 — Per-variant spec delta (Architect ↔ Confirmer)

For each variant in the execution set, produce a spec delta that the Coder can implement against. Variants are processed in priority order (Critical first, then High, etc.). Per-variant processing is serial unless the user explicitly authorizes parallel variants.

Step 1 — Architect Case B invocation (per variant)

Compute {r} = 1 for the initial draft. Invoke method-architect with Case B (scope expansion) brief adapted for Phase 4:

Case: Phase 4 ablation spec delta.
Base spec: phase_3_main_experiment/specs/framework_v{m}.md
Ablation plan: phase_4_ablation/plans/ablation_plan_v{n}.md
Variant to spec: {variant handle}
Variant operation detail: {from plan}
Component to ablate: {from plan}
Carry-forward modules: {from plan}
Spec-delta modules: {from plan — usually one}
Cell scope: {from plan}
Output: phase_4_ablation/specs/ablation_spec_{handle}_v1.md
Round: 1 (initial delta draft)

Your task: produce a minimal spec delta that modifies exactly the
named spec-delta module(s) per the plan's Operation detail. All
other modules are carry-forward — reference them by naming
framework_v{m}.md §Modules §{module} rather than duplicating
their Operation text. The Runner module's §Operation should name
this variant's Cell scope explicitly. Preserve framework_v{m}.md's
Runner iteration strategy (single-process / per-cell / hybrid)
unless the Operation detail requires changing it (rare).

Wait for the Architect. Confirm ablation_spec_{handle}_v1.md exists.

Step 2 — Confirmer invocation (per variant)

Invoke spec-confirmer against the variant's spec delta:

Spec to audit: phase_4_ablation/specs/ablation_spec_{handle}_v{r}.md
Base spec: phase_3_main_experiment/specs/framework_v{m}.md
Ablation plan: phase_4_ablation/plans/ablation_plan_v{n}.md
IDEA: phase_0_ideation/ideas/IDEA.md
Round: {r}
Output: phase_4_ablation/specs/confirmer_report_{handle}_v{r}.md

Audit scope: focus on the spec delta, not the carry-forward
references. Confirm (1) the delta matches the plan's Operation
detail for this variant, (2) the Runner's Cell scope matches the
plan's Cell scope, (3) metric keys the variant will produce are
declared, (4) carry-forward module references are by name (not
duplicated text).

Wait for the Confirmer. Read the Verdict.

Step 3 — Per-variant Architect ↔ Confirmer loop (max 3 rounds)

If Verdict = ALL CLEAR: variant spec is confirmed. Proceed to Sub-process 3 for this variant.

If Verdict = REVISIONS NEEDED: invoke the Architect for revision round r ← r + 1 with the Confirmer's findings as the brief. Then re-invoke the Confirmer. Repeat until ALL CLEAR or r > 3.

If r > 3 with still-open findings: escalate with the same deadlock menu as phase3-main-experiment (continue with the next variant and return to this one later / accept-with-override / abandon this variant). Do not auto-route.

Step 4 — Variant iteration

When a variant's spec is ALL CLEAR (or accepted override), move immediately to Sub-process 3 for that variant — do NOT wait to queue up all variants' specs first. Phase 4 runs one variant's full pipeline (spec → code → run → analyze) before starting the next variant's spec, unless the user authorized per-variant parallel processing upfront.

---

Sub-process 3 — Per-variant code upgrade (Coder ↔ Fidelity)

Phase 3 code at phase_3_main_experiment/code/ implemented the full matrix. Phase 4 variants carry forward nearly all of it verbatim; only the spec-delta module changes. This is the carry-forward path the ablation-designer named in the plan's Carry-forward modules field.

Step 1 — Enumerate modules and classify (per variant)

Read ablation_spec_{handle}_v{r}.md §Modules. For each module:

• Unchanged: the spec references framework_v{m}.md §Modules §{module} and adds no changes. Copy the Phase 3 code directory to phase_4_ablation/code/{handle}/{module}/ verbatim (cp -r or equivalent); mark as carry-forward. No Coder invocation.
• Changed: the spec has a delta. Re-implement via Coder ↔ Fidelity. This is typically one module per variant (the ablated one) plus possibly the Runner (if Cell scope changed non-trivially).
• New: named in the variant's spec but not in framework_v{m}.md. Rare in Phase 4; if present, implement fresh via Coder ↔ Fidelity.

Announce the plan for this variant to the user:

Phase 4 code upgrade — variant {handle}

Carry-forward (no Coder work, copy from phase_3_main_experiment/code/):
  - {module_a}: unchanged
  - {module_b}: unchanged
  - ...
Re-implement (Coder ↔ Fidelity):
  - {module_c}: {one-line delta summary from spec}
  - ...
New:
  - {module_d}: {role} [rare at Phase 4]

Per-module cap: 3 Coder ↔ Fidelity rounds. Carry-forward modules are
not audited — they carry Phase 3's ALL-CLEAR fidelity by reference.
I will process Re-implement and New modules in spec-declared order.

Unless the user's upfront confirmation said "proceed without per- variant prompts", wait for go-ahead on the first variant. Subsequent variants can proceed under the same blanket go-ahead unless the user indicated otherwise.

Step 2 — Run the Coder ↔ Fidelity loop per non-carry-forward module

For each Re-implement or New module of this variant, run the same loop shape as phase2-implementation Steps 3–6, but with paths rooted at phase_4_ablation/code/{handle}/:

• Code directory: phase_4_ablation/code/{handle}/{module}/
• Fidelity reports: phase_4_ablation/fidelity/fidelity_{handle}_{module}_v{r}.md
• Spec reference: phase_4_ablation/specs/ablation_spec_{handle}_v{r}.md

The Coder's cross-module I/O references should point at phase_4_ablation/code/{handle}/{other_module}/ for this variant's carry-forward modules (not at phase_3_main_experiment/code/) — the copy in Step 1 exists so that each variant is a self-contained code tree for run-experiment.

Round cap, deadlock escalation menu, and cross-module I/O handling are identical to phase2-implementation's Steps 3–6 and its "On per-module deadlock" section. If a variant's code requirement diverges from the plan's Operation detail, halt and re-invoke the Architect ↔ Confirmer loop for that variant — do not silently adapt.

Step 3 — Per-variant code-upgrade exit condition

When every module in this variant's spec has either (i) carry-forward status or (ii) an ALL CLEAR Phase 4 Fidelity Report (or user-accepted override), proceed to Sub-process 4 for this variant. Announce:

Phase 4 code upgrade — variant {handle} — COMPLETE

Carry-forward modules: [list]
Re-implemented / new modules with Phase 4 fidelity ALL CLEAR:
  - {module_c}: Round {r_c}
  - ...

Accepted additions (if any): [list]

The Runner's README at
phase_4_ablation/code/{handle}/{runner}/README.md (if the Runner is
the delta module) or phase_3_main_experiment/code/{runner}/README.md
(carry-forward) now carries the variant's Invocation Command.
Proceeding to execution.

---

Sub-process 4 — Per-variant execution + Analyst + Story Advisor

Step 1 — Plan this variant's launches

Read ablation_spec_{handle}_v{r}.md §Modules §Runner. The variant's Cell scope names the cells to run — a subset (typically one to a few cells) of the Phase 3 matrix. The Runner's §Operation declares the iteration strategy for this variant's cells (single-process / per-cell / hybrid — same three options as Phase 3).

Produce a launch table for this variant:

Launch	Cell(s) covered	Expected runtime class	Metric keys to capture
1	...	...	[keys]
...	...	...	...

Announce before the first launch for this variant:

Phase 4 variant {handle} — execution plan

Iteration strategy: single-process / per-cell / hybrid
Total launches for this variant: {K_handle}
Expected runtime class: {range}

Launch table:
{table above}

Story Advisor (Context C) will be invoked after the variant's last
analysis finalizes. If this variant is marked Critical, an earlier
checkpoint may be added on user request.

Proceed?

Wait for user confirmation on the first variant; subsequent variants can proceed under a blanket go-ahead.

Step 2 — Execute one launch

Invoke run-experiment in Launch mode. Pass the brief pointing at Phase 4 paths:

Phase: 4 (ablation)
Spec: phase_4_ablation/specs/ablation_spec_{handle}_v{r}.md
Runner code: phase_4_ablation/code/{handle}/{runner}/   (or
  phase_3_main_experiment/code/{runner}/ if Runner is carry-forward;
  the spec's invocation command resolves this)
Results directory: phase_4_ablation/results/
Launch scope: {cell(s) per the launch-table row}
Variant handle: {handle}  (for result_{n}.md §Slice tagging)

run-experiment writes phase_4_ablation/results/result_{n}.md with status RUNNING, registers in PROJECT_STATE §2, and returns. The {n} index is global across Phase 4 (not per-variant) — the Slice field inside the result names the variant handle for disambiguation.

Do not wait synchronously. Return control to the user as run-experiment instructs. session-start will poll. When the sentinel drops, re-enter run-experiment in Finalize mode.

Step 3 — Per-run Analyst invocation (after Finalize)

Once run-experiment Finalize has written result_{n}.md with status COMPLETE or FAILED, invoke experiment-analyst:

Result to analyze: phase_4_ablation/results/result_{n}.md
Spec: phase_4_ablation/specs/ablation_spec_{handle}_v{r}.md
Base spec: phase_3_main_experiment/specs/framework_v{m}.md  (context for
  what "full method" means — the ablation is measured against this)
Ablation plan: phase_4_ablation/plans/ablation_plan_v{n}.md
IDEA: phase_0_ideation/ideas/IDEA.md
Output: phase_4_ablation/analysis/analysis_{n}.md

Context note: this is a Phase 4 ablation analysis. The variant's
Expected outcome (from the plan) is the prediction to validate —
include a Claim-Result row for "Ablation attribution prediction:
{variant handle}" with verdict SUPPORTED / NOT SUPPORTED /
UNMEASURABLE. Other Claim-Result rows may be UNMEASURABLE at this
scope (that is fine — the Core Claims are defended at Phase 3; this
variant tests attribution).

If a variant's dominant rollback depth is non-None, halt the variant loop and escalate per §Variant-level failure handling below — do not continue launching other variants against a broken spec or code.

Step 4 — Story Advisor Context C checkpoint (per variant)

After the variant's last analysis finalizes (when the Cell scope is fully covered and analyzed), invoke story-coherence-advisor:

Invocation context: C (Phase 4 ablation integration)
Inputs:
  - IDEA: phase_0_ideation/ideas/IDEA.md
  - Spec: phase_3_main_experiment/specs/framework_v{m}.md
  - Phase 2 analyses: phase_2_verification/analysis/analysis_*.md
  - Phase 3 analyses: phase_3_main_experiment/analysis/analysis_*.md
  - Phase 4 ablation analyses so far:
      phase_4_ablation/analysis/analysis_*.md
  - Ablation plan: phase_4_ablation/plans/ablation_plan_v{n}.md
  - Prior story_check:
      phase_3_main_experiment/story_checks/story_check_{k-1}.md
Output: phase_3_main_experiment/story_checks/story_check_{k}.md

Read the Verdict. Context-C-specific handling:

• COHERENT: the variant's attribution confirmed or sharpened a contribution bullet. Continue to the next variant.

• FRACTURED (new fracture introduced by this variant): do NOT auto-continue; the variant has redirected credit in a way the previous story did not account for. Surface the Story Advisor's Most-important-reconciliation and ask:

  Phase 4 variant {handle} — Story Check FRACTURED.
  
  Most important reconciliation: {one line from story_check_{k}.md}
  
  Reconciliation options the Story Advisor proposed:
  {list}
  
  Options for you:
  (a) Continue remaining variants — the fracture is attribution-
      level and later variants may resolve it (e.g., the credit
      redirected to another component will be tested next). Appropriate
      when the reconciliation is an update to contribution bullets
      that subsequent Context-C calls will absorb.
  (b) Pause and revise the plan — route to Ablation Designer Case B
      with the new story_check as input. Appropriate when new
      variants are needed (the redirected credit points at a
      component not currently in the plan's execution set).
  (c) Pause and retreat to Phase 3 — rare; only when the
      reconciliation implies the Main Results are misframed (not
      an ablation-attribution fix). Requires user confirmation.
  (d) Accept the fracture as a narrative update and continue —
      the bullet is retired / redirected per the story_check and
      no new variants are needed.
  

  Wait for user instruction.

Step 5 — Variant iteration exit

When every variant in the execution set has either (i) completed with every Cell-scope analysis finalized and a Context-C story_check recorded, or (ii) been explicitly paused per Step 4's options, the variant loop is done.

Confirm the latest story_check's Verdict before moving to Sub-process 5:

• COHERENT: proceed to Sub-process 5.
• FRACTURED: do not proceed — the Main Agent must reconcile per Step 4's options first.

---

Sub-process 5 — Exit

Invoke phase4-exit-check against the accumulated Phase 4 artifacts. It returns PASS or NEEDS-REWORK with a routing-advisory table.

On PASS: announce handoff:

Phase 4 — COMPLETE

Plan: phase_4_ablation/plans/ablation_plan_v{n}.md
Variants executed: {execution set handles}
Results: phase_4_ablation/results/result_1.md … _{N}.md
Analyses: phase_4_ablation/analysis/analysis_1.md … _{N}.md
Story check trail (chronological):
  {list of (k, Verdict) pairs across Phase 3 + Phase 4}
Latest story check: phase_3_main_experiment/story_checks/story_check_{K}.md
  (Verdict: COHERENT)

Contribution bullets (final, per latest story check):
{list from story_check_{K}.md Contribution Bullets section}

Hand-off: Phase 5 (Review) / Phase 6 (Writing) are the next phases.
Their skills are NOT YET BUILT.

Then stop.

On NEEDS-REWORK: Main Agent reads the advisory table and picks a case per §Variant-level failure handling below, or re-invokes this skill as Case C.

---

Variant-level failure handling

A variant's analysis may return a non-None rollback depth mid- sweep (Sub-process 4 Step 3). Handle per depth:

Depth	Action
Low (code bug in one module of this variant)	Halt the variant. Route to phase2-implementation Case B scoped to phase_4_ablation/code/{handle}/, fix the named module, then re-invoke this skill as Case C to rerun the affected launches. Other variants continue.
Medium (spec ambiguity or bad per-variant setup)	Halt the variant. Route to this skill's Sub-process 2 for that variant (Architect ↔ Confirmer revision round on ablation_spec_{handle}_v{r+1}.md). Resume as Case C for this variant.
High (method component's predicted effect didn't materialize — the bullet's attribution is wrong, the variant IS the signal)	Do NOT treat as rollback — this is expected Phase-4 evidence. The Story Advisor (Context C) will reframe the bullet. Continue to the next variant; the story_check at the end of this variant's Cell scope will surface the redirect as a fracture diagnosis with method-ahead-of-story or story-ahead-of-method direction.
Critical (variant's result implies the Phase 3 Main Results themselves are wrong)	Halt Phase 4 immediately. Surface to user. This is a Phase-3-re-entry signal, not a Phase-4 continuation. User-confirmed routing only — options include (i) reframing the IDEA's Core Claims (Refiner), (ii) re-running the affected Phase 3 cells with a corrected framework_v{m+1}.md (Phase 3 Case C), (iii) retreating to Phase 0 re-ideation.

The key distinction from Phase 3 matrix execution: in Phase 4, a High per-variant finding is usually the signal the ablation was designed to catch (a bullet's attribution was wrong). That is a Story Advisor Context C job, not a Main Agent routing call — let the Story Advisor reframe and continue. Critical is different: the variant's data contradicts the Phase 3 Main Results themselves, not just the bullet attribution.

---

Loop control

• Architect ↔ Confirmer cap per variant (Sub-process 2): 3 rounds.
• Coder ↔ Fidelity cap per module (Sub-process 3): 3 rounds.
• Variant sweep (Sub-process 4): no round cap — every variant in the execution set must be attempted. A variant's non-None analysis depth is handled per §Variant-level failure handling, not retried in-loop.

---

Files produced by this pipeline

File	Written by	Notes
phase_4_ablation/plans/ablation_plan_v{n}.md	Ablation Designer	Versioned.
phase_4_ablation/specs/ablation_spec_{handle}_v{r}.md	Architect	One per variant; versioned per Architect ↔ Confirmer round.
phase_4_ablation/specs/confirmer_report_{handle}_v{r}.md	Confirmer	One per round per variant.
phase_4_ablation/code/{handle}/{module}/	Coder (or carry-forward copy)	Per variant; carry-forward modules copied from phase_3_main_experiment/code/ verbatim.
phase_4_ablation/code/{handle}/{runner}/README.md	Coder (if Runner is delta) OR carry-forward	Invocation Command for this variant.
phase_4_ablation/fidelity/fidelity_{handle}_{module}_v{r}.md	Fidelity Checker	One per Coder ↔ Fidelity round per changed module per variant.
phase_4_ablation/results/result_{n}.md	run-experiment	One per launch. {n} is global within Phase 4. Slice field names the variant handle.
phase_4_ablation/results/log_{n}.txt	run-experiment (via execution environment)	Live log, locally readable per the execution contract.
phase_4_ablation/results/log_{n}.done	launched process on exit	Sentinel.
phase_4_ablation/analysis/analysis_{n}.md	experiment-analyst	One per finalized run.
phase_3_main_experiment/story_checks/story_check_{k}.md	story-coherence-advisor	Context C entries land here (shared directory across Phase 3 / Phase 4 per Story Advisor design).
phase_4_ablation/PHASE_4_SUMMARY.md	Main Agent	Written at handoff on PASS. One-page rollup: plan version, variants executed, per-bullet attribution verdict, latest story check verdict.

---

What this skill does NOT do

• Does not rerun Phase 3 main-results cells. Phase 4's role is attribution, not re-verification. If a Phase 4 result implies a Phase 3 cell was wrong, that is a Critical signal that routes back to Phase 3 Case C — not a silent rerun here.
• Does not add new datasets, baselines, LLMs, or metrics. Those are Experimental-Setup revisits. If a variant's Expected outcome clause names a baseline that was not in the Phase 3 matrix, that is a plan error — surface to Ablation Designer Case B.
• Does not write the paper. The Story Advisor's updated contribution bullets at the end of Phase 4 are the Writer's input; they are not draft sections.
• Does not second-guess the Analyst, the Ablation Designer, or the Story Advisor. Their outputs are authoritative. If you believe one is wrong, re-invoke with a specific gap named; do not override.
• Does not parallelize variants by default. Variants run serially unless the user authorized parallel variants upfront. GPU sharing is a user decision, not a skill default.
• Does not design ablations for uncovered bullets. If the plan flagged bullets as uncovered, the resolution is upstream (Story Advisor Context B to reshape the bullet, or IDEA reframe) — not a fresh Ablation Designer pass at the same bullets.

---

Interaction with other loops

• From Phase 3 (phase3-exit-check): enter as Case A when depth = None, story_check is COHERENT or FRACTURED-scoped-to-Phase-4, and user confirms Phase 4 start.
• To Phase 3 (phase3-main-experiment Case C): on variant-level Critical depth (Main Results themselves contradicted).
• To Phase 2 (phase2-implementation Case B): on variant-level Low depth, scoped to phase_4_ablation/code/{handle}/.
• To Phase 1 (phase1-method-design Case B): if a variant's Medium depth traces to a spec ambiguity that affects the base framework_v{m}.md (rare; usually Phase 4 Medium is variant-spec-local).
• To Phase 0 (loop1-ideation-pipeline Case C): on variant-level Critical, user-confirmed only.
• From Loop 4 (review supplementary): enter as Case B with variant additions or revisions named.
• To Phase 5 / 6 (Review / Writing): via the Sub-process 5 PASS handoff. Their skills are not yet built.