diff --git a/CLAUDE.md b/CLAUDE.md index df82e5e..26e1d2a 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -6,7 +6,7 @@ User-facing usage guide: [`USING_CLAUDE_CODE.md`](USING_CLAUDE_CODE.md). ## What this repo is -Hands-on simulations of the Forward Deployed Engineer role. Two fictional 4-week customer engagements (Calder insurance + Helix hedge fund) with working Python agent prototypes, weighted eval suites, reference solutions per phase, and stakeholder role-play prompts. Plus 4 simulation types (full engagement, 5h take-home + Review, 60-min recommendation, client simulation), 16 portable frameworks, a case-aware HTML whiteboard, and engagement-cycle artifacts (retro, portfolio, skip-ahead). +Hands-on simulations of the Forward Deployed Engineer role. Two fictional 4-week customer engagements (Calder insurance + Helix hedge fund) with working Python agent prototypes, weighted eval suites, reference solutions per phase, and stakeholder role-play prompts. Plus 4 simulation types (full engagement, 5h take-home + Review, 60-min recommendation, client simulation), 17 portable frameworks, a case-aware HTML whiteboard, and engagement-cycle artifacts (retro, portfolio, skip-ahead). Doubles as interview prep for FDE-style roles at frontier AI labs. @@ -82,7 +82,7 @@ The simulations are designed for the user to do the work. Reference solutions ex │ ├── 3-recommendation-60min/ # 1-hour live conversation │ └── 4-client-simulation/ # Hostile-customer role-play │ -├── frameworks/ # 16 portable frameworks +├── frameworks/ # 17 portable frameworks │ ├── 4-source-convergence.md │ ├── 3-lens-scaffold.md │ ├── outcome-risk-matrix.md @@ -98,6 +98,7 @@ The simulations are designed for the user to do the work. Reference solutions ex │ ├── agent-exploitation-taxonomy.md # operate-time security: 8 attack classes + gate per class │ ├── production-debugging.md # CS-agent components + latency root-cause + log-triage drill │ ├── system-design-round.md # design-round method + RAG/tools/MCP/trajectory-eval/cost depth + drills +│ ├── orchestration-topology.md # boundary test, 6 patterns, MCP vs A2A, delegation contracts, governance │ └── trust-surface-design.md # adoption layer: attribution, transparency, publish gate, permissions, stakes routing, autonomy ladder │ └── tools/ @@ -175,6 +176,7 @@ Personas' kill-criteria, what they would and wouldn't say, and tone are in `STAK - **System design round** — the design-round method (requirements first → walking-skeleton MVP → name tradeoffs and pick → identity/observability/rollback/eval-as-release) plus the AI-architecture depth it probes: RAG failure modes, agent tool design + MCP, trajectory evaluation, cost levers. Spine it on DASME or C.A.S.E. Includes a 6-prompt drill set. - **Trust surface design** — the adoption layer, for when the eval passes but nobody delegates to the agent. Five decisions: attribution (agent vs. human, reversible per-step), transparency depth (process for the accountable user, outcome for the served user), publish gate (producing is free; reaching another human needs approval), permission inheritance (never invent a second access model), stakes routing ("can AI do it?" vs "should AI do it?"). Approvals render next to the object in the customer's system of record; chat is a session log, not the front door. Plus the onboarding-style autonomy ladder (launch deliberately over-gated, widen on override rate) and the refinement loop the field memo has to name an owner for. +- **Orchestration topology** — the composition layer. When to add a reasoning boundary vs. a tool (boundary test: need >=2 of different failure mode / permissions / eval criteria / model tier / lifecycle / domain). Six patterns: router, supervisor, sequential, fan-out, generator-verifier, hierarchical. MCP = "I need a capability"; A2A = "I need another agent to own this task." Delegation contract: Objective -> Context -> Permissions -> Expected Output -> Completion Criteria -> Failure Behavior. Governance = model proposes, policy layer disposes. Multi-agent moves complexity into orchestration rather than removing it — sometimes one agent with good tools is right. When suggesting or critiquing, name the framework. Don't re-derive. diff --git a/COVERAGE_MAP.md b/COVERAGE_MAP.md index 9daf7c1..35ce2c8 100644 --- a/COVERAGE_MAP.md +++ b/COVERAGE_MAP.md @@ -4,7 +4,7 @@ ## Why this exists -The repo has 4 simulation formats and 16 frameworks. Candidates ask: "I have an OpenAI Deployed PM final round in 2 weeks — which simulation should I actually run?" This map answers that. +The repo has 4 simulation formats and 17 frameworks. Candidates ask: "I have an OpenAI Deployed PM final round in 2 weeks — which simulation should I actually run?" This map answers that. Two axes: 1. **Which simulation format covers which interview signal** (the matrix below) @@ -25,6 +25,7 @@ Legend: `█` = primary coverage (deliverable proves it), `▒` = secondary cove | Wedge selection on Outcome Risk Matrix | █ | █ | █ | | | 3-lens scaffold application | █ | █ | █ | | | Agent workforce decomposition (5-8 agents with shapes) | █ | █ | █ | | +| Orchestration topology + delegation contracts (why N agents, which pattern) | █ | █ | █ | | | Model-vs-application-layer tagging | █ | █ | █ | | | Hybrid deterministic + LLM discipline | █ | █ | | | | Working prototype that runs end-to-end | █ | █ | | | diff --git a/README.md b/README.md index 293c932..e8598db 100644 --- a/README.md +++ b/README.md @@ -103,7 +103,7 @@ Each agent run produces an examiner-readable audit trace. ### Frameworks (used across all simulations) -16 portable frameworks that show up in every FDE engagement: +17 portable frameworks that show up in every FDE engagement: 1. [4-source convergence](frameworks/4-source-convergence.md) — Buyer / Brief / Industry / Operator triangulation for discovery 2. [3-lens scaffold](frameworks/3-lens-scaffold.md) — Customer / Product / Technical for any agent design; AI-capability-relationship segmentation @@ -121,6 +121,7 @@ Each agent run produces an examiner-readable audit trace. 14. [Production debugging](frameworks/production-debugging.md) — customer-support agent reference architecture + a latency root-cause decomposition tree + a worked log-triage drill 15. [System design round](frameworks/system-design-round.md) — the design-round method + AI-architecture depth (RAG failure modes, agent tool design + MCP, trajectory eval, cost levers) + a 6-prompt drill set 16. [Trust surface design](frameworks/trust-surface-design.md) — the adoption layer: attribution, transparency depth, publish gate (and where the approval renders), permission inheritance, stakes routing, an onboarding-style autonomy ladder, and the post-handoff refinement loop +17. [Orchestration topology](frameworks/orchestration-topology.md) — when a reasoning boundary beats a tool, the 6 orchestration patterns, MCP vs. A2A, delegation contracts, and the governance/observability layers ### Tools @@ -163,7 +164,7 @@ fde-simulation/ │ ├── 3-recommendation-60min/ # 1 hour live conversation │ └── 4-client-simulation/ # Live customer-handling role-play │ -├── frameworks/ # 16 portable FDE frameworks +├── frameworks/ # 17 portable FDE frameworks └── tools/ # Interactive 3-lens whiteboard ``` diff --git a/USING_CLAUDE_CODE.md b/USING_CLAUDE_CODE.md index 0c33676..04fd979 100644 --- a/USING_CLAUDE_CODE.md +++ b/USING_CLAUDE_CODE.md @@ -112,7 +112,7 @@ Claude reads your work, compares to the week-2 deliverables, names what's missin After an engagement (or mid-engagement), ask Claude to grade which frameworks you actually deployed: -> "Read my discovery memo and wedge proposal. Which of the 16 frameworks in `frameworks/` did I actually use? Which did I name? Which did I skip? Score each as 'deployed / named / skipped'." +> "Read my discovery memo and wedge proposal. Which of the 17 frameworks in `frameworks/` did I actually use? Which did I name? Which did I skip? Score each as 'deployed / named / skipped'." Useful before writing the `PORTFOLIO_TEMPLATE.md` `frameworks-applied.md` doc — Claude tells you what you actually did vs what you said you did. diff --git a/frameworks/README.md b/frameworks/README.md index 74d9a83..0af7e53 100644 --- a/frameworks/README.md +++ b/frameworks/README.md @@ -1,6 +1,6 @@ # Frameworks -> Sixteen portable frameworks that show up in every FDE engagement. Internalize these and they generalize to any case. +> Seventeen portable frameworks that show up in every FDE engagement. Internalize these and they generalize to any case. | Framework | One-line definition | Deploy in... | |---|---|---| @@ -20,12 +20,13 @@ | [Production debugging](production-debugging.md) | Customer-support agent reference architecture + latency root-cause decomposition tree + worked log-triage drill | Live-debugging case + operate-time | | [System design round](system-design-round.md) | Design-round method + AI-architecture depth (RAG failure modes, tool design + MCP, trajectory eval, cost levers) + 6-prompt drill set | System-design round | | [Trust surface design](trust-surface-design.md) | The 5 decisions that make a working agent get *used*: attribution, transparency depth, publish gate (and where it renders), permission inheritance, stakes routing — plus the onboarding-style autonomy ladder and the post-launch refinement loop | Solution Strategy + Risk & Validation + handoff | +| [Orchestration topology](orchestration-topology.md) | When to add a reasoning boundary vs. a tool (6-signal boundary test), the 6 orchestration patterns, MCP vs. A2A, the 6-field delegation contract, and the governance/observability layers | Solution Strategy + System-design round | ## How to deploy them In a 60-min interview, you deploy them in order: - Discovery: framework 1 -- Solution Strategy: frameworks 2, 3, 4, 5 (in that order) +- Solution Strategy: frameworks 2, 3, 4, 5, then 17 (topology) if the system needs more than one agent - Risk & Validation: frameworks 6 and 16 In a 5-hour take-home, you deploy them across hours 1-2 (discovery + architecture) and reference them in your deck. diff --git a/frameworks/agent-shapes-catalog.md b/frameworks/agent-shapes-catalog.md index c944009..ca342db 100644 --- a/frameworks/agent-shapes-catalog.md +++ b/frameworks/agent-shapes-catalog.md @@ -109,4 +109,5 @@ Senior move: name the shape before the agent. ## See also +- [`orchestration-topology.md`](orchestration-topology.md) — the shapes say what each agent *is*; this says how they compose (patterns), when a shape should be a tool instead, and what a delegated task must specify - [`production-debugging.md`](production-debugging.md) — a worked customer-support agent reference architecture: how these shapes compose into an 11-component request path you can debug against. diff --git a/frameworks/orchestration-topology.md b/frameworks/orchestration-topology.md new file mode 100644 index 0000000..d230b97 --- /dev/null +++ b/frameworks/orchestration-topology.md @@ -0,0 +1,166 @@ +# Framework 17: Orchestration Topology + +> [Workflow decomposition](workflow-decomposition.md) tells you where the boundaries go. [Agent shapes](agent-shapes-catalog.md) tells you what each agent is. This tells you how they compose — and, more often than candidates expect, why the answer is one agent with good tools. + +## The failure this framework prevents + +Two opposite failures, and interviewers probe for both. + +**The agentic monolith.** One agent accumulates dozens of tools, an ever-growing instruction block, several permission levels, a large context, and responsibilities spanning multiple business domains. Like a software monolith, it becomes hard to maintain, test, secure, evaluate, and evolve. Nobody can say which instruction is load-bearing, and every eval regression is a bisect across one enormous prompt. + +**Multi-agent theater.** The candidate draws seven agents because seven agents look sophisticated. This is the [Unforgivable](essentials-unforgivables.md) of chasing trendy solutions, and it fails on the trade-off below. + +**Multi-agent architecture does not eliminate complexity. It moves complexity from inside the agent into the orchestration layer.** With one agent you manage prompts, tools, context, and permissions. With several you manage all of that *plus* delegation, coordination, context sharing, state, failure handling, governance, and observability. That's a real bill, and it comes due in week 3 when something breaks and nobody can tell which agent decided what. + +So the question is never *"how do we use more agents?"* It's: + +> **Where does creating an independent reasoning boundary make the system easier to build, govern, evaluate, and operate?** + +## The boundary test + +Add a reasoning boundary when at least two of these are true. One alone is usually not enough. + +| Signal | Why it justifies a boundary | +|---|---| +| **Different failure mode** | The existing [decomposition principle](workflow-decomposition.md) — regulatory leak and bad synthesis fail differently and need different gates | +| **Different permissions** | The retriever doesn't need write access; the policy reasoner doesn't need every customer record; the proposer doesn't need execute authority | +| **Different evaluation criteria** | If you'd score this capability on a different rubric, it wants its own eval suite and its own release gate | +| **Different model tier** | Extraction on Haiku, synthesis on Sonnet — a boundary makes the tier decision explicit and defensible | +| **Different lifecycle / owner** | A capability that changes weekly shouldn't be coupled to one that changes quarterly, especially across team boundaries | +| **Different business domain** | Billing policy and returns policy have different owners, different rules, and different rates of change | + +If none of these hold, you have a tool, not an agent. Add it to the existing agent and move on. + +## The six patterns + +| Pattern | Shape | Use when | Cost | +|---|---|---|---| +| **Router / triage** | Classify, then hand to one specialist | Requests fall into clean, disjoint categories | Mis-routes are silent; needs a fallback class | +| **Supervisor / manager** | One orchestrator owns the interaction, delegates tasks, assembles the answer | Enterprise workflows where control must stay centralized and one voice reaches the user | Supervisor becomes the new monolith if it also does the work | +| **Sequential** | Fixed order; each stage feeds the next | Regulated or predictable processes where order is the control | Latency is the sum; one slow stage blocks all | +| **Parallel / fan-out** | Independent tasks run concurrently, results joined | Tasks share no dependency and latency matters | Partial-failure semantics: what does the join do when one branch fails? | +| **Generator–verifier** | One agent produces, another evaluates against explicit criteria | Irreversible or reputation-bearing output with a checkable bar | Doubles cost per item; the verifier needs its own calibration | +| **Hierarchical** | Orchestrators coordinating orchestrators | Large orgs where domains own their own agents, policies, and systems | Debugging, governance, and ownership get materially harder | + +Patterns compose. Most real systems are a supervisor with a sequential spine and a couple of generator–verifier pairs hanging off the irreversible steps. + +## What the reference prototypes actually use + +Worth being concrete, because "which pattern did you use" is a live probe and the honest answer here is instructive. + +Both prototypes are a **sequential pipeline with a deterministic gate in front and generator–verifier pairs at the irreversible steps**. Helix runs MNPI Scrubber → Intake → KPI Extractor → Note Drafter → Tone Supervisor → Citation Verifier → Compliance Critic. The Scrubber fires *before any LLM call*, so a watch-list hit halts the run at zero token spend. Drafter→Tone Supervisor and Drafter→Citation Verifier are generator–verifier pairs. + +There is deliberately **no router, no fan-out, and no A2A** in v1. That is a defensible choice, not an omission: + +- The workflow has one entry point and a fixed regulatory order, so a router would add a mis-route failure mode and buy nothing. +- Fan-out would cut latency on a workflow whose SLA is "before market open," not milliseconds — the wrong thing to optimize. +- Every stage is owned by the same team on the same release cadence, so the lifecycle signal in the boundary test doesn't fire. + +**Where an interviewer will push:** at 10x volume with several note types, the intake step earns a router; if consensus and filings lookups are independent, they earn a fan-out. Say what would *change your mind*, and the answer reads as judgment rather than defensiveness. + +## MCP vs. A2A — capability or reasoning boundary? + +The question underneath every orchestration decision: + +> **Does this task need a capability, or another reasoning boundary?** + +- **MCP (Model Context Protocol)** — *"I need access to this capability."* Standardized access to tools, data, and systems. If the task is deterministic (retrieve a record, call an API, execute an operation), it's a tool. You don't need another agent. Tool-design discipline and the injection surface MCP widens are in [`system-design-round.md`](system-design-round.md). +- **A2A (agent-to-agent)** — *"I need another agent to own this task."* Delegating an *objective* to an autonomous agent that reasons, holds its own context, chooses its own capabilities, and reports completion. + +They're complementary, not competing: an agent that receives work over A2A still uses MCP to reach the systems it needs. The FDE-relevant point is that they're different boundaries with different blast radii. A tool call is bounded by its signature; a delegated objective is bounded only by the contract you wrote for it. + +## Delegation contracts + +Once agents delegate to agents, *"figure this out"* is not an interface. Every delegated task needs six fields: + +| Field | The question | Failure if you skip it | +|---|---|---| +| **Objective** | What outcome, stated so completion is checkable | The sub-agent optimizes something adjacent | +| **Context** | The minimum needed — nothing more | Context bloat, cost, and leaked data across boundaries | +| **Permissions** | What it may read, write, and execute | The sub-agent inherits the caller's full authority | +| **Expected output** | Shape and schema of the result | The caller parses prose and guesses | +| **Completion criteria** | How both sides know it's done | Silent partial completion, reported as success | +| **Failure behavior** | Retries, timeout, escalation target | Infinite loops, or a failure that vanishes | + +Four rules that go with it: + +1. **Pass only the context required.** Context is a permission — this is least privilege from [`agent-exploitation-taxonomy.md`](agent-exploitation-taxonomy.md) applied to data rather than tools. +2. **Give every task a single owner.** Shared ownership across agents means no ownership at failure time. +3. **Bound recursive delegation.** A depth limit, or the graph is unbounded and so is the bill. +4. **Separate instructions from untrusted data.** A delegated payload carrying retrieved content is an injection vector; the delegation contract is where you fence it. + +**More autonomy requires stronger contracts.** Autonomy and contract strength move together, or the system is under-specified exactly where it's most dangerous. + +## Governance and observability + +Two layers that become mandatory the moment agents take actions rather than answer questions. + +**Governance — what agents are *allowed* to do.** Permissions, tool access, approval gates, delegation limits, auditability. The load-bearing separation: + +> The model proposes what should happen. The policy layer determines what is allowed to happen. + +An agent that decides its own authority has no governance, however well it reasons. This is the deterministic-gate discipline from [`agent-exploitation-taxonomy.md`](agent-exploitation-taxonomy.md) and the publish gate from [`trust-surface-design.md`](trust-surface-design.md), stated as an architectural layer rather than a per-action rule. + +**Observability — what actually happened.** Multi-agent changes the debugging question: + +> From *"what did the model say?"* to *"what happened across the execution graph?"* + +That is a different instrumentation requirement, and it's why the repo's audit-trace standard is per-agent rather than per-run: you need the decision, the inputs, the delegation edges, and the policy verdicts, or a post-incident review can't answer which boundary failed. [`production-debugging.md`](production-debugging.md) has the latency decomposition; the same span discipline carries the causal one. + +## The decision ladder + +``` +Need a deterministic capability? -> Tool / MCP +Need specialized reasoning? -> Agent (run the boundary test) +Need autonomous delegation? -> A2A + a delegation contract +Need multiple agents coordinated? -> Orchestration (pick a pattern) +Can agents take consequential actions? -> Governance (policy layer) +Need to know what happened? -> Observability (execution graph) +``` + +Walk it top-down and stop at the first rung that answers the problem. Most enterprise problems stop at rung one or two. + +## The probe this defends against + +When the interviewer asks *"why not one agent?"* — or the inverse, *"why not split this up?"* — the weak answer treats agent count as a design goal. The strong answer: + +> "I don't optimize for agent count. I add a reasoning boundary only where at least two things differ — failure mode, permissions, eval criteria, model tier, lifecycle, or domain. On Helix, MNPI and drafting differ on all six, so they're separate; extraction and drafting differ on tier and eval, so they're separate. Everything else is a tool, not an agent. The topology is a sequential pipeline with a deterministic gate in front and generator–verifier pairs at the irreversible steps — no router, because there's one entry point and a fixed regulatory order, so a router would add a mis-route failure mode and buy nothing. What would change that: several note types at 10x volume earns a router at intake. And I'd say plainly that multi-agent doesn't remove complexity, it moves it into orchestration — which is why the audit trace is per-agent and every delegated task has an owner, a permission scope, and a failure behavior." + +## Quick reference + +``` +FIRST QUESTION: capability or reasoning boundary? + Deterministic (retrieve / call / execute) -> TOOL (MCP) + Needs to reason, hold context, choose -> AGENT (A2A) + +BOUNDARY TEST (need >=2 to justify a new agent): + different failure mode | permissions | eval criteria + model tier | lifecycle-owner | business domain + ...none? It's a tool. Add it to the existing agent. + +PATTERNS: + Router simple, disjoint categories + Supervisor centralized control, one voice to the user + Sequential order IS the control (regulated) + Fan-out independent tasks, latency-bound + Gen-verify irreversible output with a checkable bar + Hierarchical domains own their own agents (governance cost is real) + +DELEGATION CONTRACT (all six, every time): + Objective -> Context -> Permissions -> Expected Output + -> Completion Criteria -> Failure Behavior + +GOVERNANCE: model PROPOSES, policy layer DISPOSES +OBSERVABILITY: "what did the model say?" -> "what happened across the graph?" + +Senior move: multi-agent doesn't remove complexity, it MOVES it into orchestration. +Sometimes the right answer is still one agent with good tools. +``` + +## See also + +- [`workflow-decomposition.md`](workflow-decomposition.md) — where the boundaries go (bottom-up, from the manual workflow); this framework is the composition layer above it +- [`agent-shapes-catalog.md`](agent-shapes-catalog.md) — what each agent *is*; the Router shape is the deterministic implementation of the router pattern +- [`trust-surface-design.md`](trust-surface-design.md) — the publish gate and permission inheritance are the governance layer at the user boundary +- [`agent-exploitation-taxonomy.md`](agent-exploitation-taxonomy.md) — least privilege and the untrusted-input rule, which delegation contracts enforce across boundaries +- [`system-design-round.md`](system-design-round.md) — tool-design discipline, MCP's injection surface, and trajectory evaluation (which is how you eval a graph, not a call) diff --git a/frameworks/system-design-round.md b/frameworks/system-design-round.md index 5cbee11..27b03ab 100644 --- a/frameworks/system-design-round.md +++ b/frameworks/system-design-round.md @@ -34,6 +34,8 @@ Fixes: reranking, better chunking, lower top-k, dedup/recency filters, and a ret **MCP (Model Context Protocol)** is the emerging standard for exposing tools, resources, and prompts to a model across clients. Why it matters for an FDE: it standardizes plugging an agent into a customer's systems without bespoke glue per integration — and it widens the indirect-injection surface, because every tool result is untrusted input. +MCP answers *"I need access to this capability"*; **A2A** answers *"I need another agent to own this task."* Knowing which boundary a requirement calls for — and defending why most of them are tools — is [`orchestration-topology.md`](orchestration-topology.md). + ### Trajectory evaluation Pass^k on the *final output* (see [`4-dimensional-testing.md`](4-dimensional-testing.md)) is necessary but not sufficient for agents. **Trajectory evaluation** scores the *steps*: did the agent call the right tools in the right order, recover from a tool error, and avoid unnecessary or unsafe actions? A correct answer reached through a wrong path (it exfiltrated data, then summarized correctly) is still a failure. Evaluate both the destination and the route. diff --git a/frameworks/workflow-decomposition.md b/frameworks/workflow-decomposition.md index ed4c282..0c473d1 100644 --- a/frameworks/workflow-decomposition.md +++ b/frameworks/workflow-decomposition.md @@ -61,6 +61,10 @@ When the interviewer asks "how did you decide on these agents", you say: > "I decomposed by failure mode, not by feature. Step 1: mapped Rachel's manual workflow. Step 2: identified 2 decisions and 6 executions. Step 3: grouped executions by data + tier. Step 4: added a critic at every irreversible step. Step 5: added routing for confidence-low cases. That's how we got to 7 agents — mechanically, not by guessing." +## What this framework does not answer + +Decomposition is bottom-up: it derives boundaries from the manual workflow. It does not ask whether a boundary is *worth* creating, and it produces a flat set of agents with no named topology. Both are [`orchestration-topology.md`](orchestration-topology.md): the boundary test (a capability that differs on fewer than two of failure mode / permissions / eval criteria / tier / lifecycle / domain is a tool, not an agent) and the six composition patterns. + ## Quick reference ``` diff --git a/simulations/1-full-engagement/calder-insurance/START_HERE.md b/simulations/1-full-engagement/calder-insurance/START_HERE.md index bd00682..6abefba 100644 --- a/simulations/1-full-engagement/calder-insurance/START_HERE.md +++ b/simulations/1-full-engagement/calder-insurance/START_HERE.md @@ -119,7 +119,7 @@ Per the cadence in `STAKEHOLDER_INTERVIEWS.md`: ## When you're stuck -- Need the framework? See [`../../../frameworks/`](../../../frameworks/) — 16 portable frameworks. 4-source convergence first. +- Need the framework? See [`../../../frameworks/`](../../../frameworks/) — 17 portable frameworks. 4-source convergence first. - Need to know what good looks like? See [`GRADE_YOUR_WORK.md`](../GRADE_YOUR_WORK.md) — Claude grading prompt per phase. - Want a senior shortcut? See [`../SKIP_AHEAD.md`](../SKIP_AHEAD.md) — if you've done this before, do weeks 3-4 cold. - Done? See [`../RETRO_TEMPLATE.md`](../RETRO_TEMPLATE.md) at end of week 4. diff --git a/simulations/1-full-engagement/helix-finance/START_HERE.md b/simulations/1-full-engagement/helix-finance/START_HERE.md index 119f606..fa63f63 100644 --- a/simulations/1-full-engagement/helix-finance/START_HERE.md +++ b/simulations/1-full-engagement/helix-finance/START_HERE.md @@ -134,7 +134,7 @@ Per the cadence in `STAKEHOLDER_INTERVIEWS.md`: ## When you're stuck -- Need the framework? See [`../../../frameworks/`](../../../frameworks/) — 16 portable frameworks. 4-source convergence first. +- Need the framework? See [`../../../frameworks/`](../../../frameworks/) — 17 portable frameworks. 4-source convergence first. - Need to know what good looks like? See [`GRADE_YOUR_WORK.md`](../GRADE_YOUR_WORK.md) — Claude grading prompt per phase. - Want a senior shortcut? See [`../SKIP_AHEAD.md`](../SKIP_AHEAD.md) — if you've done this before, do weeks 3-4 cold. - Done? See [`../RETRO_TEMPLATE.md`](../RETRO_TEMPLATE.md) at end of week 4.