@exaudeus/workrail 3.33.0 → 3.34.0

package/docs/discovery/design-candidates.md

@@ -0,0 +1,180 @@
+# Design Candidates: wr.discovery Goal Reframing
+
+**Status:** Candidate generation complete -- for main agent review  
+**Date:** 2026-04-18  
+**Session:** wr.discovery (improving goal reframing)
+
+---
+
+## Problem Understanding
+
+### Core tensions
+
+**T1: Early interrogation vs late-discovered context**  
+Goal interrogation in Phase 0 happens before any landscape work. Some hidden assumptions only become visible after reading the codebase. An early interrogation catches structural goal-type issues (solution-framed vs problem-framed) but misses context-dependent assumptions. Phase 1g retriage catches these later -- but only if the agent explicitly sets `retriageNeeded = true`.
+
+**T2: Non-interactive constraint vs interrogation quality**  
+The best reframing comes from dialogue. Daemon sessions have no human. Non-interactive interrogation means the agent interrogates itself, which risks circular reasoning (surfacing expected assumptions rather than genuinely hidden ones).
+
+**T3: Overhead for well-framed goals**  
+Any mandatory goal-challenge step adds overhead to every session, including correctly-framed ones. The mechanism must be lightweight for good goals, substantial for misframed ones.
+
+**T4: Workflow enforcement vs agent judgment**  
+The workflow can instruct the agent to classify a goal, but the classification itself is still LLM output. A `runCondition` on `goalType = solution_framed` is structural, but the `goalType` value is agent judgment. There is no escape from this.
+
+### Likely seam
+
+Phase 0's `procedure` block -- specifically the `Capture` step that lists context variables and the path selection logic. This is where goal misframing has the highest downstream impact (wrong `pathRecommendation` propagates through all subsequent steps).
+
+### What makes this hard
+
+1. The agent interrogates itself -- self-adversarial reasoning is weaker than adversarial reasoning against a well-defined artifact
+2. Solution-framed goals can look like problem-framed goals ('improve discovery' looks like a problem frame but contains hidden assumptions)
+3. Adding required output fields to Phase 0 means sessions starting mid-workflow (without Phase 0 context) need graceful fallback
+
+---
+
+## Philosophy Constraints
+
+| Principle | Constraint |
+|---|---|
+| Validate at boundaries, trust inside | Phase 0 is the input boundary; it must validate goal framing |
+| Make illegal states unrepresentable | Solution-framed goal processed without interrogation should not be a valid state |
+| YAGNI with discipline | The mechanism must add near-zero cost for well-framed goals |
+| Architectural fixes over patches | The fix should change structural invariants, not add 'be careful' reminders |
+| Determinism over cleverness | Same goalType -> same downstream path bias |
+
+**Philosophy conflict:** 'Make illegal states unrepresentable' conflicts with 'YAGNI with discipline' when it comes to adding a mandatory interrogation step. A mandatory step is more enforceable but adds overhead for every session.
+
+---
+
+## Impact Surface
+
+| Surface | Must stay consistent |
+|---|---|
+| `pathRecommendation` context variable | Set by Phase 0; used by all phase-1 `runCondition` gates |
+| `problemStatement` context variable | Should reflect the actual problem, not the stated solution |
+| `designDocPath` content | Problem framing section becomes misleading if it reflects a solution-framed goal verbatim |
+| Phase 1g `retriageNeeded` trigger | If retriage condition changes, existing sessions may behave differently |
+| Daemon sessions | Cannot be blocked on interactive responses |
+
+---
+
+## Candidates
+
+### Candidate 1: Minimal -- Extend Phase 0 `Capture` with `goalType` and `impliedProblem`
+
+**Summary:** Add `goalType` (4-value closed enum: `solution_framed | problem_framed | opportunity_framed | decision_framed`) and `impliedProblem` to the Phase 0 `Capture` step. Add a procedure instruction: classify first, derive `impliedProblem` when `solution_framed`, then select path with `goalType` awareness.
+
+**Tensions resolved:** T3 (near-zero overhead for well-framed goals -- classification is lightweight), T4 partially (structural variable exists)  
+**Tensions accepted:** T1 (pre-context), T2 (self-interrogation), T4 fully (goalType is still agent judgment)
+
+**Boundary:** Phase 0 `Capture` list and `procedure` text
+
+**Why best fit:** Phase 0 already captures 12+ context variables. Adding `goalType` and `impliedProblem` follows the established pattern. No new step IDs, no new `runCondition` chains, fully backward compatible.
+
+**Failure mode:** Agent classifies a solution-framed goal as `opportunity_framed`, skipping `impliedProblem` derivation. No structural enforcement prevents this.
+
+**Repo pattern:** Follows the existing 'Phase 0 captures context variables for downstream use' pattern.
+
+**Gains:** Zero new steps. Backward compatible. `goalType` available for all downstream phases.  
+**Gives up:** No enforcement that classification happens before path selection. Still relies on procedure text instructions, not structural ordering.
+
+**Scope judgment: best-fit as a minimal change.** Not too narrow (introduces the structural signal). Not too broad (no new steps).
+
+**Philosophy:** Honors 'YAGNI', 'Determinism'. Conflicts with 'Make illegal states unrepresentable' (misframings are still structurally possible).
+
+---
+
+### Candidate 2: Structural -- New mandatory Phase 0a before current Phase 0
+
+**Summary:** Add a new step `phase-0a-goal-interrogation` that runs before the current Phase 0. Always runs. Required outputs: `goalType` (4-value enum), `impliedProblem` (string, required when `solution_framed`), `hiddenAssumptions` (array, min 1 when `goalType != problem_framed`), `alternativeFraming` (string, optional). Phase 0 then reads `goalType` from context rather than deriving it.
+
+**Tensions resolved:** T3 partially (well-framed goals produce trivial Phase 0a output fast), T4 (structural enforcement -- path selection cannot happen without Phase 0a having run)  
+**Tensions accepted:** T1 (still pre-landscape), T2 (self-interrogation)
+
+**Boundary:** A new step with ID `phase-0a-goal-interrogation`, inserted as the first step of the workflow. Phase 0 becomes a consumer of `goalType` rather than its producer.
+
+**Why best fit:** True structural enforcement. Phase 0a is a required step. The interrogation runs before path selection by design, not by instruction. Mirrors the existing `phase-0b-capability-setup` pattern (a pre-phase setup step before the main classification phase).
+
+**Failure mode:** For well-framed goals, Phase 0a adds overhead. More importantly: Phase 0a and Phase 0 can produce contradictory conclusions if the agent reconsiders its interpretation between steps.
+
+**Repo pattern:** Adapts the `phase-0b-capability-setup` pattern. Departs in that Phase 0a runs before Phase 0 (changes existing step order).
+
+**Gains:** True enforcement. `hiddenAssumptions` and `alternativeFraming` become required outputs with engine validation. Sets a seam for a future reusable `routine-goal-interrogation`.  
+**Gives up:** Adds a step to every session (overhead for well-framed goals). Changes step order (Phase 0 is no longer the first step).
+
+**Scope judgment: best-fit for structural correctness, slightly overbroad for immediate need.** The structural separation is the correct long-term architecture.
+
+**Philosophy:** Honors 'Architectural fixes over patches', 'Make illegal states unrepresentable', 'Validate at boundaries'. Conflicts with 'YAGNI with discipline'.
+
+---
+
+### Candidate 3: Distributed -- Three targeted strengthening changes to existing steps
+
+**Summary:** No new steps. Three changes: (1) add `goalType` classification + `impliedProblem` to Phase 0 procedure (same as C1). (2) Make `problemFrameTemplate`'s 'What would make this framing wrong' field a required non-empty output contract in Phase 1e/1f steps. (3) Change Phase 1g `runCondition` from `retriageNeeded = true` to `pathRecommendation == design_first || pathRecommendation == full_spectrum` (retriage always runs for these paths).
+
+**Tensions resolved:** T1 (distributed checkpoints catch both pre-context issues at Phase 0 and post-landscape issues at Phase 1g), T3 (no new steps)  
+**Tensions accepted:** T2 (self-interrogation at all checkpoints), T4 partially
+
+**Boundary:** Three existing steps: Phase 0 (procedure text), Phase 1e/1f (output contract), Phase 1g (runCondition).
+
+**Why best fit:** Fixes the three specific weak points in the existing design without adding new steps. Distributed checkpoints catch more than a single-point interrogation.
+
+**Failure mode:** An agent anchored to the original framing can produce weak 'what would make this wrong' answers -- required non-empty output enforces form but not quality. Phase 1g always-on for `design_first` runs a (potentially unnecessary) retriage step for sessions where the path was correct from the start.
+
+**Repo pattern:** Adapts existing `outputRequired` contract pattern. Adapts `runCondition` pattern. Follows (not departs from) established mechanisms.
+
+**Gains:** No new steps. Reinforces three existing weak mechanisms. Catches both early and late misframings.  
+**Gives up:** No single strong enforcement point. Effect is diffuse. Does not fix path-selection bias (wrong path can still be chosen in Phase 0 before Phase 1g runs).
+
+**Scope judgment: too narrow as standalone, best-fit as complement to C1 or C2.**
+
+**Philosophy:** Honors 'YAGNI with discipline', 'Architectural fixes over patches'. Conflicts with 'Make illegal states unrepresentable' (path selection still uses raw stated goal).
+
+---
+
+## Comparison and Recommendation
+
+### Tension resolution matrix
+
+| Tension | C1 (Phase 0 extension) | C2 (new Phase 0a) | C3 (distributed) |
+|---|---|---|---|
+| T1: pre-context interrogation | Accepts | Accepts | Resolves (Phase 1g post-landscape) |
+| T2: self-interrogation quality | Accepts (same for all) | Accepts | Accepts |
+| T3: overhead for well-framed goals | **Resolves** (lightweight) | Accepts (adds step) | **Resolves** (absorbed) |
+| T4: structural enforcement | Partial | **Resolves** (mandatory step) | Partial |
+
+### Recommendation: C1 + C3 hybrid, with C2 as future evolution
+
+**Primary (immediate):** C1 extended with procedural strength: add `goalType`, `impliedProblem`, `hiddenAssumptions` to Phase 0 Capture as required context variables. Add explicit procedure: classify goal type first, derive implied problem before path selection, let goalType influence path bias toward `design_first` for `solution_framed` goals.
+
+**Secondary (no new steps):** Three C3 changes: (a) `goalType` in Phase 0 (same as C1), (b) make 'What would make this framing wrong' a required non-empty output in Phase 1e/1f, (c) change Phase 1g `runCondition` to always run for `design_first` and `full_spectrum` paths.
+
+**Future evolution:** If the C1+C3 hybrid proves insufficient for daemon sessions, extract Phase 0a as a mandatory pre-step (C2).
+
+---
+
+## Self-Critique
+
+**Strongest argument against this recommendation:** C1's enforcement is procedural (instructions), not structural (step ordering). A capable LLM running in QUICK mode or under context pressure can skip the classification step and proceed to path selection. C2's mandatory separate step is the only way to structurally guarantee the interrogation happened.
+
+**Counter:** Both approaches ultimately rely on the LLM following instructions. The difference is in how much structural scaffolding supports following those instructions. C2 enforces 'the step ran' not 'the step ran well.'
+
+**Narrower option:** Just add `goalType` to the Capture list with no procedure change. Too narrow -- introduces the variable without the interrogation mechanism.
+
+**Broader option:** Extract a reusable `routine-goal-interrogation` callable from any workflow. Justified if pattern proves valuable in other workflows. Not warranted now.
+
+**Assumption that would invalidate this:** Claude Sonnet already implicitly reframes solution-framed goals. Counter-evidence: two real examples (MCP simplification, structured output session) show this is not reliably true.
+
+---
+
+## Open Questions for the Main Agent
+
+1. **Should `goalType` influence path selection automatically** (e.g., `solution_framed` -> force `design_first`) or **only as a soft bias**? Automatic enforcement is stronger but may override user intent for cases where the solution IS the right framing.
+
+2. **How should `impliedProblem` flow to the design doc?** Should Phase 0 write it as the `problemStatement` in the design doc (replacing the stated goal), or record it as a separate field ('stated goal' vs 'implied problem')?
+
+3. **Phase 1g runCondition change:** Making Phase 1g always run for `design_first` and `full_spectrum` is a behavior change for existing sessions. Is this backward compatible enough?
+
+4. **`hiddenAssumptions` format:** Should this be a free-text field or a structured array? Free-text is easier to author; structured allows downstream steps to reference specific assumptions.

package/docs/discovery/design-review-findings.md

@@ -0,0 +1,110 @@
+# Design Review Findings: wr.discovery Goal Reframing
+
+*Concise, actionable findings for main-agent synthesis. Not a final decision.*
+**Date:** 2026-04-18
+
+---
+
+## Tradeoff Review
+
+**Tradeoff 1: goalType classification remains agent judgment**
+
+- Acceptable: this pattern is established in the workflow (rigorMode, pathRecommendation are all agent-derived)
+- Classification examples in the procedure reduce misclassification probability
+- **Finding: YELLOW.** Add goalType classification examples to procedure text to reduce ambiguity at the problem_framed / opportunity_framed boundary.
+
+**Tradeoff 2: overhead for well-framed goals is nonzero**
+
+- A few additional context variable captures and procedure lines in Phase 0
+- Well-framed goals produce minimal output ('goalType = problem_framed, no impliedProblem needed')
+- **Finding: NON-ISSUE.** Overhead is trivial.
+
+**Tradeoff 3: Phase 1g always-on for design_first/full_spectrum**
+
+- One additional advance per session for these paths
+- Produces trivially short output for well-framed sessions ('pathChangedAfterContext = false')
+- **CRITICAL CORRECTION NEEDED:** Phase 1g runCondition must be an OR (`retriageNeeded = true OR pathRecommendation in [design_first, full_spectrum]`) not a replacement. Otherwise landscape_first sessions that explicitly need retriage will not trigger it.
+- **Finding: YELLOW.** Runnable as-designed if the OR condition is used correctly.
+
+---
+
+## Failure Mode Review
+
+**Failure mode 1: Agent misclassifies solution-framed goal as opportunity_framed**
+- Status: **Partially mitigated.** C3's Phase 1e/1f required 'what would make this framing wrong' output provides a downstream catch. Classification examples in Phase 0 reduce probability.
+- Missing mitigation: examples in procedure (address in revisions)
+- **Finding: MEDIUM risk, mitigated.**
+
+**Failure mode 2: 'What would make this framing wrong' output is formulaic**
+- Status: **Partially mitigated.** Making it required non-empty enforces form but not quality.
+- Missing mitigation: specificity instruction ('name ONE concrete condition, not a general caveat')
+- **Finding: LOW-MEDIUM risk.**
+
+**Failure mode 3: Phase 1g doesn't surface new insights for well-framed sessions**
+- Status: **Non-issue by design.** For well-framed sessions, Phase 1g is a graceful no-op that confirms the path is still correct. One advance wasted, nothing more.
+- **Finding: LOW risk, acceptable.**
+
+---
+
+## Runner-Up / Simpler Alternative Review
+
+**C2 (mandatory Phase 0a):** The structural enforcement advantage is real but comes at the cost of a mandatory overhead step for all sessions. The C1+C3 hybrid achieves most of C2's value via procedure-level enforcement plus structural runCondition changes. C2 is the right escalation if the hybrid proves insufficient.
+
+**Simpler variant:** Just one sentence added to Phase 0: 'If the goal is solution-framed, derive the underlying problem.' Too narrow -- no context variables means no downstream reference to the reframing.
+
+**`alternativeFraming` addition from C2:** Borrowing C2's `alternativeFraming` requirement (one reframe even when the original goal seems correct) is high-value, low-cost. Add to Phase 0 design doc entry, not as a context variable.
+
+**Finding: C1+C3 hybrid with two refinements (examples, alternativeFraming) stands. No direction change needed.**
+
+---
+
+## Philosophy Alignment
+
+| Principle | Status |
+|---|---|
+| Validate at boundaries, trust inside | SATISFIED -- Phase 0 becomes an active validator |
+| Make illegal states unrepresentable | PARTIALLY SATISFIED -- C3 structural changes help; C2 would fully satisfy |
+| YAGNI with discipline | SATISFIED -- no new steps, minimal additions |
+| Architectural fixes over patches | SATISFIED -- runCondition changes and required output contracts are structural |
+| Determinism over cleverness | SATISFIED -- same goalType input produces same path behavior |
+
+**One explicit philosophy tension:** 'Make illegal states unrepresentable' vs 'YAGNI with discipline' -- deliberately accepted, C2 is escalation path.
+
+---
+
+## Findings
+
+### Yellow findings
+
+**Y1: goalType classification boundary ambiguity**
+The boundary between `problem_framed` and `opportunity_framed` is unclear without examples. Add classification examples to Phase 0 procedure to reduce misclassification at this boundary.
+
+**Y2: Phase 1g runCondition must be OR, not replacement**
+The retriage step runCondition must be: `retriageNeeded = true OR pathRecommendation == design_first OR pathRecommendation == full_spectrum`. A straight replacement would break landscape_first sessions that legitimately need retriage.
+
+**Y3: 'What would make this framing wrong' needs specificity instruction**
+The required output field should specify 'name ONE concrete falsification condition, not a general caveat.' Without this, the field can be satisfied by formulaic responses.
+
+### No Red or Orange findings
+
+The selected C1+C3 direction has no material structural weaknesses.
+
+---
+
+## Recommended Revisions
+
+1. **Add goalType classification examples** to Phase 0 procedure (solution_framed: 'add X', 'implement Y', 'build X'; problem_framed: 'reduce X', 'fix Y'; opportunity_framed: 'explore X', 'decide whether Y'; decision_framed: 'choose between A and B')
+
+2. **Add `alternativeFraming`** as a required design doc entry in Phase 0: 'Before selecting a path, generate one alternative framing -- if the stated goal is wrong, what would a better goal be?'
+
+3. **Use OR condition for Phase 1g runCondition:** `retriageNeeded = true OR pathRecommendation in [design_first, full_spectrum]`
+
+4. **Add specificity instruction** to Phase 1e/1f 'what would make this framing wrong' field: require naming one concrete falsification condition.
+
+---
+
+## Residual Concerns
+
+1. The goalType classification is LLM-dependent. Without empirical testing on real sessions, we cannot confirm the classification is reliable. This is an inherent limitation of the approach.
+
+2. The C1+C3 hybrid does not prevent path-selection bias for the window between Phase 0 path selection and Phase 1g retriage. A session that selects the wrong path in Phase 0 runs several steps in the wrong direction before Phase 1g can correct it. Acceptable for STANDARD rigor; C2 is the correct escalation if this proves problematic.

package/docs/discovery/wr-discovery-goal-reframing.md

@@ -0,0 +1,303 @@
+# Discovery: Improving wr.discovery Goal Reframing
+
+**Status:** Discovery in progress
+**Session:** wr.discovery (Phase 1 -- diagnosis)
+**Date:** 2026-04-18
+
+**Artifact strategy:** This document is for human reading. Execution truth (context variables, step notes) lives in WorkRail session state. This doc is updated at each phase.
+
+---
+
+## Context / Ask
+
+The `wr.discovery` workflow (v3.1.0) takes the stated goal at face value. Users often state solutions instead of problems, carry faulty assumptions into the brief, or do not actually know what they want. The goal of this discovery is to diagnose what is specifically weak about the current workflow and identify improvement directions -- not to design the final solution.
+
+---
+
+## Path Recommendation
+
+**Path:** `design_first`
+
+**Rationale:** The dominant risk here is solving the wrong problem. "Make discovery better" is ambiguous. The brief itself suggests one diagnosis (takes requests at face value) but that framing may itself be incomplete -- the problem could be about *when* reframing happens, *how* it happens, *what triggers* it, or something else entirely (e.g., the problem is that the workflow is too sequential rather than too credulous). `design_first` is the right path because the framing is genuinely uncertain and jumping to "add a reframe step" risks solving a surface symptom. A `landscape_first` path would just survey other discovery frameworks -- interesting but not the center of gravity. `full_spectrum` would work but would diffuse effort equally on landscape and framing when framing is the real bottleneck.
+
+**Why not landscape_first:** The landscape (design thinking, Jobs-to-be-Done, 5 Whys, pre-mortem, etc.) is well-known and would mostly confirm what we already know. The interesting question is not "what frameworks exist" but "what structural change to this specific workflow would make it genuinely better."
+
+---
+
+## Constraints / Anti-goals
+
+**Constraints:**
+- The improved workflow must remain usable in automated (daemon) contexts where no human is present to answer follow-up questions
+- Changes to `wr.discovery.json` must follow the v2 workflow authoring format
+- The workflow already has a path-selection mechanism (phase-0); any improvement should integrate with or extend this, not duplicate it
+- Must not break existing sessions mid-flight
+
+**Anti-goals:**
+- Do not add interactive Q&A that assumes a human will respond (daemon contexts have no human)
+- Do not make the workflow so heavy that it becomes a therapy session before doing any actual work
+- Do not import external frameworks wholesale -- extract principles, do not copy playbooks
+- Do not redesign the full workflow structure -- focus on the goal-reframing problem specifically
+
+---
+
+## Landscape Packet
+
+### Current state summary
+
+`wr.discovery` v3.1.0 has a Phase 0 that:
+1. Captures `problemStatement`, `desiredOutcome`, `coreConstraints`, `antiGoals`, `primaryUncertainty`, `knownApproaches`
+2. Selects a path: `landscape_first`, `full_spectrum`, `design_first`
+3. Creates a design doc
+
+**What Phase 0 does NOT do:**
+- It does not challenge or probe the stated goal
+- It does not distinguish between "user stated a problem" vs "user stated a solution"
+- It does not surface faulty assumptions in the goal itself
+- It does not ask "is this the real problem or is it a symptom?"
+- The path selection criteria are about *emphasis* (landscape vs framing), not about *goal validity*
+
+The workflow does have a `design_first` path choice and a "what would make this framing wrong" element in the problemFrameTemplate -- but these apply after the goal is accepted, not before.
+
+### Existing approaches / precedents
+
+**1. Design Thinking (IDEO/Stanford d.school):** "Empathize" phase is explicitly about setting aside your solution hypothesis and observing real user behavior. Pre-work question: "Are we solving the right problem?" The structural insight: problem reframing is not a step *in* the process -- it is a prerequisite to starting the process.
+
+**2. Jobs-to-be-Done (Christensen):** When a user states "I want a faster horse," the JTBD practitioner asks "What job are you trying to get done?" The goal is to surface the functional, emotional, and social dimensions of the actual outcome -- not the solution form. Structured probe: "What were you doing before? What did you try? What would success look like even if our solution didn't exist?"
+
+**3. 5 Whys (Toyota):** Sequential causal probing. "Why do you want X?" -> "Because Y." "Why Y?" -> "Because Z." Three to five levels of probing reveals whether the stated goal is a root cause or a symptom. Works well for problem goals; less well for opportunity goals.
+
+**4. Pre-mortem (Gary Klein):** "Imagine we did exactly what you asked and it failed. What went wrong?" Forces the requester to articulate hidden assumptions. Particularly effective at surfacing: wrong success criteria, ignored stakeholders, underestimated constraints.
+
+**5. AI-specific: Prompt interrogation patterns:** The "goal elicitation" pattern in agentic AI systems (e.g., AutoGPT system prompts, OpenAI alignment research) distinguishes between *stated objectives* and *intended objectives*. The typical mechanism: present a synthetic interpretation back to the user and ask for confirmation or correction.
+
+**6. Consulting intake (McKinsey, IDEO, etc.):** A structured discovery brief usually has: "What decision do you need to make?" + "What would change if you had the answer?" + "Who else has thought about this?" + "What have you already tried?" The intake is not about validating the solution -- it is about understanding the decision context.
+
+### Option categories
+
+1. **Pre-step interrogation:** Add a Phase -1 (before path selection) that explicitly challenges the goal statement
+2. **Integrated reframing in Phase 0:** Extend Phase 0 to include goal challenge as part of classification
+3. **Adversarial dual-track:** Run two interpretations in parallel -- "take it literally" vs "reframe it" -- and let synthesis surface the gap
+4. **Progressive commitment:** Start with minimal goal acceptance, revisit the framing after each major phase, make reframing explicit at retriage points
+5. **Structural annotation:** Add a `goalType` classification (solution-framed, problem-framed, opportunity-framed, decision-framed) that changes how Phase 0 proceeds
+
+### Contradictions / disagreements
+
+- The workflow already has `design_first` as a path and says "Choose `design_first` when the dominant risk is solving the wrong problem" -- but the path selection itself uses the stated goal as input. If the goal is wrong, the path selection can still be wrong.
+- Phase 1g (re-triage) exists for course correction after landscape and framing work -- but it triggers on `retriageNeeded` being explicitly set, which assumes the agent identifies the need. A goal stated as a solution could pass through path selection and Phase 1 without triggering retriage.
+- The metaGuidance says "Anti-anchoring: do not let the first framing or favorite option dominate the work" -- but this applies to *candidate generation*, not to goal framing. The stated goal is not challenged by this guidance.
+
+### Evidence gaps
+
+- No direct data on how often real discovery sessions start with solution-framed goals vs problem-framed goals
+- No post-hoc analysis of sessions where the stated goal turned out to be wrong
+- The two specific examples from the brief (MCP simplification, structured output) are known anecdotally but not documented
+
+### Why this matters for path selection
+
+The current workflow's structure means the *path selection step* inherits any misframing in the goal. A solution-framed goal can be classified as `landscape_first` when it should be `design_first`. The goal challenge needs to happen *before* path selection, or path selection needs to be goal-type-aware.
+
+---
+
+## Problem Frame Packet
+
+### Users / stakeholders
+
+- **Primary:** User (human or daemon) submitting a goal to `wr.discovery`
+- **Secondary:** Etienne (workflow author) -- wants the workflow to produce genuinely surprising insights, not just organize what was already stated
+- **Tertiary:** Downstream consumers of the design document
+
+### Jobs / goals / outcomes
+
+- **Actual job:** "Help me think through this problem so I reach the best decision, even if I described the problem wrong"
+- **Stated job:** "Help me with [stated goal]"
+- **The gap:** These are often not the same. The user often does not know the gap exists.
+
+### Pains / tensions / constraints
+
+- **T1: Goal credulous processing:** Phase 0 processes the stated goal as if it is valid. A solution-framed goal ("build X") is treated as if "X is the right solution" is not an assumption.
+- **T2: Daemon context constraint:** A daemon session has no human to answer follow-up questions. Any interactive "is this really what you want?" loop requires a human. Daemon sessions must use a non-interactive reframing strategy.
+- **T3: Overhead vs signal ratio:** Heavy interrogation adds steps. If the goal is correctly framed (which it often is), the extra steps are pure overhead. The mechanism must be lightweight and skip gracefully when the goal is already well-framed.
+- **T4: Reframing is hard to automate:** The AI cannot know what the user "really" wants -- it can only identify structural signals of a poorly-framed goal (solution-framing, missing success criteria, absent alternatives, hidden assumptions).
+
+### Success criteria
+
+1. The workflow identifies solution-framed goals and surfaces the implicit problem before generating candidates
+2. The workflow works in daemon contexts (no interactive questioning required)
+3. The overhead for a well-framed goal is minimal (a few structural notes, not a full reframing ceremony)
+4. The output of a reframed session differs meaningfully from the output of a non-reframed session for the same goal
+
+### Assumptions
+
+- The goal text itself contains structural signals that distinguish "stated solution" from "stated problem" (e.g., "implement X" vs "improve Y" vs "decide between A and B")
+- Surfacing the implicit problem does not require user confirmation -- it can be done by the agent itself as a reasoning step
+- The most important case is solution-framed goals -- a user who says "add a reframe step to wr.discovery" is actually asking about "how to make discovery better" (this very brief is an example)
+
+### Reframes / HMW questions
+
+- HMW: How might we detect when a stated goal is a solution hypothesis rather than a problem statement -- without requiring human confirmation?
+- HMW: How might we ensure the workflow explores the problem space *before* accepting the stated goal's framing?
+- HMW: How might we make goal reframing something the agent does *for itself* rather than a ceremony it performs *for the user*?
+
+### What would make this framing wrong
+
+- If the agent model is already good enough at implicit reframing (without explicit prompting), the structural change adds ceremony without value
+- If daemon sessions are a small minority of `wr.discovery` uses, an interactive probe could work for the majority case
+- If the real problem is not "goal acceptance" but "insufficient candidate diversity" -- i.e., the workflow accepts the goal but generates too-narrow candidates -- then the fix belongs in Phase 3, not Phase 0
+
+---
+
+## Candidate Generation Expectations (design_first)
+
+Because this is a `design_first` pass:
+- At least one direction must meaningfully reframe the problem, not just add a "challenge" step
+- The candidate set must address the daemon constraint directly -- solutions that require human interaction are non-starters
+- Include the simplest change that could work alongside more structural alternatives
+
+---
+
+## Candidate Directions
+
+### Direction A: Goal-type classification in Phase 0 (minimal change)
+
+**Summary:** Extend Phase 0 to classify the stated goal into one of four structural types: `solution_framed` ("build/add/implement X"), `problem_framed` ("improve/fix/reduce Y"), `opportunity_framed` ("explore/understand Z"), `decision_framed` ("choose between A and B"). When the goal is `solution_framed`, Phase 0 must explicitly surface the implicit problem statement before proceeding.
+
+**Mechanism:** Add a `goalType` context variable and a procedure step: "Before selecting a path, classify the goal as `solution_framed`, `problem_framed`, `opportunity_framed`, or `decision_framed`. If `solution_framed`, produce an explicit `impliedProblem` statement: 'The stated goal implies this underlying problem: [X]. Confirm this is correct or surface a different problem frame before proceeding.'"
+
+**Why it fits:** Minimal change. Works in daemon context (no human confirmation needed -- the agent surfaces the implication and continues). Does not add steps; extends Phase 0. The goalType classification is cheap and structural.
+
+**Strongest evidence for it:** The brief itself is a perfect example: "improve wr.discovery goal reframing" is opportunity-framed, but the actual problem statement needs to be made explicit ("the workflow accepts stated goals uncritically"). Phase 0 in the current workflow would process this as landscape/full_spectrum without ever articulating the underlying mechanism.
+
+**Strongest risk against it:** The four-category taxonomy may be too rigid. Many goals are mixed (e.g., "decide whether to build X or Y" is both decision-framed and solution-framed). Also, the agent may classify incorrectly, and without human confirmation in daemon mode, the wrong classification goes uncorrected.
+
+**When it should win:** When the change must be minimal, backward-compatible, and immediately implementable without restructuring the workflow.
+
+---
+
+### Direction B: Adversarial goal interrogation as a distinct Phase 0b step
+
+**Summary:** Add a new Phase 0b (between goal capture and path selection) that runs a structured adversarial interrogation of the stated goal. The step always runs and produces: the `impliedProblem`, the `hiddenAssumptions`, and at least one `alternativeFraming`. Path selection happens *after* this step, using the enriched understanding rather than the raw goal.
+
+**Mechanism:** Phase 0b procedure: "(1) Restate the goal as a problem: what must be true for this goal to be the right thing to do? (2) List the 2-3 hidden assumptions the goal takes for granted. (3) Generate one alternative framing: if the stated goal is wrong, what would a better goal be? (4) Decide: is the original framing correct as-stated, or does the workflow proceed under the reframed problem? Set `goalValidated`, `impliedProblem`, `hiddenAssumptions`, `alternativeFraming` in context."
+
+**Why it fits:** Makes reframing structural and always-on rather than path-dependent. The adversarial lens is familiar in WorkRail (adversarial challenge is already used in Phase 3d). This is the same discipline applied earlier in the process. Works in daemon context -- no human response needed, the agent conducts the interrogation with itself.
+
+**Strongest evidence for it:** The two examples in the brief: (1) MCP simplification -- the discovery produced design candidates but missed that the immediate fix was just `artifacts` -- this is a case where the stated goal ("how do we simplify?") was accepted when the real problem was narrower ("what's the cheapest fix right now?"). (2) Structured output -- started with the wrong assumption about mixing `response_format + tools`, which Phase 0 would have surfaced if it asked "what assumptions does this goal take for granted?"
+
+**Strongest risk against it:** Adds a mandatory step. For well-framed goals, the step is overhead with no signal. Also, the agent interrogating its own goal with itself may produce circular reasoning -- it surfaces the assumptions it already expects, not genuinely hidden ones.
+
+**When it should win:** When the problem of goal acceptance is systematic and the overhead of an extra step is acceptable. This is the more thorough solution.
+
+---
+
+### Direction C: Progressive commitment -- reframing woven across phases
+
+**Summary:** Instead of a single upfront interrogation, weave explicit "is the framing still correct?" moments at multiple points in the workflow: after landscape (Phase 1b/1c), after problem framing (Phase 1e/1f), and explicitly in re-triage (Phase 1g). The mechanism: add a `framingChallenge` requirement at each of these steps -- a single structured question ("what would have to be true for the original goal to be wrong?") rather than a separate step.
+
+**Mechanism:** At Phase 1b (landscape), after summarizing the current state, add: "Before continuing, ask: does the landscape evidence support or challenge the original goal? If it challenges, update `retriageNeeded = true` and note the specific challenge." At Phase 1e/1f (problem framing), the existing `problemFrameTemplate` already has "What would make this framing wrong" -- make this a required non-empty output, not a soft guideline. In Phase 1g (re-triage), add explicit procedure: "Revisit the original goal statement. Is the goal still correct as-stated given what you now know?"
+
+**Why it fits:** Does not add steps. Upgrades existing checkpoints. The re-triage step already exists for this purpose but currently triggers on a set variable rather than mandating goal challenge. Most importantly: distributed reframing is more likely to catch late-arriving information than a single upfront interrogation.
+
+**Strongest evidence for it:** The workflow already has `anti-anchoring` guidance in metaGuidance -- "do not let the first framing or favorite option dominate." This direction makes the same principle apply to the *goal*, not just the *candidates*. It is consistent with the workflow's existing philosophy.
+
+**Strongest risk against it:** If the original goal is wrong in a way that affects path selection itself (e.g., choosing `landscape_first` when `design_first` was needed), distributed reframing happens too late. The path is already chosen; the work is already done in the wrong direction.
+
+**When it should win:** When the problem is primarily about insufficient rigor late in the workflow, not about path selection being skewed by a bad goal.
+
+---
+
+## Challenge Notes
+
+**Against Direction A (goal-type classification):**
+The four-category taxonomy solves the symptom (goal is solution-framed) but not the underlying mechanism. A goal classified as `problem_framed` ("improve Y") can still contain hidden assumptions. The classification alone is not sufficient -- it needs to be paired with explicit assumption surfacing.
+
+**Against Direction B (adversarial Phase 0b):**
+Phase 0b interrogates the goal before the agent has any landscape knowledge. This limits the quality of assumption surfacing -- the agent can only use its prior knowledge, not what it discovers in the codebase. The most surprising hidden assumptions are often ones that only become visible after seeing the actual state of the system.
+
+**Against Direction C (progressive commitment):**
+Distributed reframing is weaker than upfront reframing for the specific problem of path selection bias. If the original goal causes the wrong path to be selected, later reframing stages run within the wrong path's constraints. Retriage exists but only triggers when `retriageNeeded` is set -- and an agent anchored to the original framing may not set it.
+
+**Synthesis:** The strongest design would combine A and B: goal-type classification *plus* an adversarial interrogation step. Direction C should also be incorporated -- make the "what would make this framing wrong" field in problemFrameTemplate mandatory and non-empty. But a minimal viable change is Direction B alone.
+
+---
+
+## Resolution Notes
+
+**Primary diagnosis:**
+The core weakness is that Phase 0 has no mechanism to distinguish "user stated a real problem" from "user stated a solution hypothesis." The path selection, framing, and candidate generation all downstream from this -- if the goal is wrong, the entire workflow is scaffolded on the wrong foundation.
+
+**Secondary diagnosis:**
+Even when the path is correct, the workflow has weak *mandatory* goal challenge. The `anti-anchoring` guidance in metaGuidance is for candidates, not for the original goal. The `problemFrameTemplate`'s "what would make this framing wrong" section is a soft guideline, not a required output.
+
+**Tertiary diagnosis:**
+The re-triage step (Phase 1g) is underused. It only runs when `retriageNeeded = true`, and the agent sets this variable. An anchored agent will not set it.
+
+**Improvement directions (in priority order):**
+
+1. **Highest priority -- Phase 0 goal interrogation:** Add a structured adversarial examination of the stated goal to Phase 0 (or as a small new step before path selection). The key outputs: `goalType`, `impliedProblem`, `hiddenAssumptions`, `alternativeFraming`. This is the primary fix.
+
+2. **Medium priority -- Make "what would make this wrong" mandatory:** In the problemFrameTemplate, change the "What would make this framing wrong" from an optional field to a required output with at least one specific, concrete falsification condition.
+
+3. **Medium priority -- Make re-triage always run for full_spectrum and design_first paths:** Remove the `retriageNeeded = true` condition gate on Phase 1g for these paths. For `landscape_first`, keep the gate.
+
+4. **Lower priority -- Goal type affects path selection:** When `goalType = solution_framed`, bias toward `design_first` path selection rather than accepting the default, unless the user has explicitly confirmed that the stated solution is the correct framing.
+
+---
+
+## Decision Log
+
+| Decision | Rationale |
+|----------|-----------|
+| `design_first` path chosen | The framing of "what's wrong with wr.discovery" is itself uncertain; dominant risk is solving the wrong problem |
+| Diagnosis focused on Phase 0 | Phase 0 is where goal acceptance happens; this is the root cause |
+| Daemon context preserved as hard constraint | Daemon sessions are real use cases; interactive questioning is not viable |
+| C1+C3 hybrid selected (not C2) | C1 extends Phase 0 with goalType/impliedProblem/hiddenAssumptions; C3 strengthens existing checkpoints. C2 (mandatory Phase 0a) is structurally stronger but adds mandatory overhead for every session. YAGNI and graceful-no-op criteria favor C1+C3. |
+| 4 refinements added from review | (1) goalType examples in procedure, (2) alternativeFraming in design doc, (3) Phase 1g OR runCondition, (4) specificity instruction for framing-risk required output |
+| C2 named as escalation path | If C1+C3 hybrid proves insufficient for daemon sessions, extract Phase 0a as mandatory pre-step |
+| direct_recommendation resolution | Remaining gap (goalType classification reliability) is a runtime testability question, not a design gap |
+
+---
+
+## Final Summary
+
+### Selected direction: C1+C3 hybrid with 4 refinements
+
+**Confidence band: MEDIUM-HIGH**
+
+### What changes in the workflow
+
+**Phase 0 (phase-0-select-path):**
+1. Add to `Capture` list: `goalType` (4-value enum: `solution_framed | problem_framed | opportunity_framed | decision_framed`), `impliedProblem` (required when solution_framed), `hiddenAssumptions` (min 1 when goalType != problem_framed)
+2. Add to procedure: "Before selecting a path, classify the goal type using these examples: solution_framed ('add X', 'implement Y', 'build X'), problem_framed ('reduce X', 'fix Y', 'understand why Z'), opportunity_framed ('explore X', 'decide whether Y'), decision_framed ('choose between A and B'). If solution_framed, derive the implied problem and record at least 1 hidden assumption. Generate one alternative framing ('if this goal is wrong, what would a better goal be?') and record it in the design doc."
+3. Add to procedure: "Let goalType influence path selection: when goalType = solution_framed, bias toward design_first unless the stated solution is clearly the correct framing."
+
+**Phase 1e and 1f (problem framing steps):**
+4. Make 'What would make this framing wrong' a required non-empty output with specificity: "Name ONE concrete falsification condition -- a specific thing that, if discovered to be true, would change the path or direction."
+
+**Phase 1g (retriage):**
+5. Change `runCondition` from `{ var: "retriageNeeded", equals: true }` to an OR: `{ or: [{ var: "retriageNeeded", equals: true }, { var: "pathRecommendation", equals: "design_first" }, { var: "pathRecommendation", equals: "full_spectrum" }] }` so retriage always runs for design_first and full_spectrum paths.
+
+### Why this direction wins
+
+- Addresses path-selection bias (the root cause) by making goalType available before path selection
+- Works non-interactively (daemon compatible)
+- Adds near-zero overhead for correctly-framed goals
+- Strengthens three existing weak mechanisms rather than adding ceremony
+- Fully backward compatible (new context variables default to unset in existing sessions)
+
+### Strongest alternative: C2 (mandatory Phase 0a)
+
+C2 is more structurally correct -- a mandatory separate step enforces that goal interrogation happens before path selection at the step-execution level. If the C1+C3 hybrid proves insufficient (tested by running a session with a known solution-framed goal), the correct escalation is to extract `phase-0a-goal-interrogation` as a mandatory pre-step before Phase 0.
+
+### Residual risks
+
+1. **goalType misclassification** (MEDIUM): a solution-framed goal classified as opportunity_framed bypasses the impliedProblem derivation. Mitigated by examples in procedure and Phase 1e/1f backstop. C2 is the escalation.
+2. **Quality of 'what would make this framing wrong' output** (LOW-MEDIUM): required non-empty enforces form but not quality. Specificity instruction reduces formulaic responses.
+3. **Phase 1g produces trivial output for well-framed sessions** (LOW): acceptable graceful no-op.
+
+### Next actions
+
+These findings are the input to Phase 2: the `workflow-for-workflows` workflow will design the implementation based on this diagnosis.
+
+1. The wfw workflow should receive: the full diagnosis (Phase 0 is the root cause), the specific changes needed (5 changes listed above), the priority order (Phase 0 goalType classification is highest priority), and the decision to implement the C1+C3 hybrid, not C2.
+2. After wfw produces the improved workflow, write it to `workflows/wr.discovery.json`.
+3. Create PR on branch `feat/discovery-workflow-improve-goal-reframing`.