obra/superpowers
Refactor the L3 planner prompt to treat the L2 assess artifact as its sole context input, eliminating implicit reliance on enrichment_snapshot and establishing explicit stage contracts between pipeline stages.
No operator comment -- selected 'Stateless stage handoff refactor' as the lowest-risk option that delivers meaningful value; skim-and-shelve was excluded because the assessor's own analysis noted that notes without code changes tend to get lost and the inefficiency persists.
In scripts/run-pipeline-planner.ps1, inside the '## Step 2 -- Get item details' section, after the bullet '- comments -- array of objects; find the one with stage="assess" and decision="approved" to get the operator's L2 steering comment', insert a new bullet on its own line: '- item.enrichment_snapshot -- present in the response but DO NOT use it. The assess artifact is the complete authoritative context for this item.' This makes the stateless input contract explicit at the point where the model reads the API response.
scripts/run-pipeline-planner.ps1In scripts/run-pipeline-planner.ps1, replace the existing 'The assessment artifact (artifacts[stage="assess"].artifact) contains:' bullet list (currently 4 bullets) with an expanded version listing all 9 actual artifact fields: '- value: one sentence on what the repo brings to the stack'; '- confidence: low | medium | high'; '- fit_to_stack: {score: string, reasoning: string} -- how well it fits the current tech stack'; '- fit_to_vision: {score: string, reasoning: string} -- how well it fits the product vision'; '- options: array of {name, description, risk, effort, tradeoffs: {pros: string[], cons: string[]}, target_project} -- each implementation approach'; '- recommendation: proceed | defer | skip'; '- recommendation_rationale: one sentence justifying the recommendation'; '- why_it_matters: prose context on the item significance'; '- what_implementation_looks_like: prose description of the minimal implementation path'. Documenting every field prevents the model from going to enrichment_snapshot when a field is not listed.
scripts/run-pipeline-planner.ps1In scripts/run-pipeline-planner.ps1, add a new '## Stage contract' section between the end of the '## What the pipeline is' block and the start of the '## Pipeline API' block. Content (verbatim): 'The planner has exactly two inputs: (1) the L2 assess artifact - the structured JSON artifact written by the assessor, and (2) the operator approval comment (may be null). It must not read or use item.enrichment_snapshot. Output is the L3 plan artifact whose JSON schema is defined in Step 3 below.'
scripts/run-pipeline-planner.ps1Create a new file context/pipeline-stage-contracts.md. Start with a one-line intro: 'Each pipeline stage reads ONLY the prior stage artifact -- not raw enrichment data or item.enrichment_snapshot.' Then add two sections. '## L2 Assess artifact (input to L3 Plan)' listing all assess fields with types: value (string), confidence (string: low|medium|high), fit_to_stack (object: {score: string, reasoning: string}), fit_to_vision (object: {score: string, reasoning: string}), options (array of {name: string, description: string, risk: string, effort: string, tradeoffs: {pros: string[], cons: string[]}, target_project: string}), recommendation (string: proceed|defer|skip), recommendation_rationale (string), why_it_matters (string), what_implementation_looks_like (string). Then '## L3 Plan artifact (input to L4 Execute)' listing all plan fields with types: objective (string), target_project (string), target_files (string[]), steps (array of {order: number, action: string, detail: string, file: string}), acceptance_criteria (string[]), estimated_effort (string), risks (string[]), operator_note_addressed (string). Keep it under 60 lines -- schema only, no prose beyond the intro.
context/pipeline-stage-contracts.mdscripts/run-pipeline-planner.ps1 Step 2 section contains a bullet explicitly stating item.enrichment_snapshot must not be used
The assess artifact schema in the prompt lists all 9 fields: value, confidence, fit_to_stack, fit_to_vision, options (with tradeoffs sub-schema), recommendation, recommendation_rationale, why_it_matters, what_implementation_looks_like
A '## Stage contract' section appears in the prompt between 'What the pipeline is' and 'Pipeline API', stating the planner's two allowed inputs
context/pipeline-stage-contracts.md exists and documents both the L2->L3 and L3->L4 field contracts with types, and includes the 'reads ONLY prior stage artifact' rule
After the PR is merged, the operator manually updates the live routine (trig_012P6FPmidMStmrsueSVW1dp at https://claude.ai/code/scheduled) to match the updated script content
The live routine update (trig_012P6FPmidMStmrsueSVW1dp) requires manual operator action in the claude.ai/code/scheduled UI -- the executor can update files and open a PR but cannot update cloud routines
If the assessor artifact schema adds fields in future, both context/pipeline-stage-contracts.md and the planner prompt will need to be updated in sync