Steve Cunningham's workshops show what Level 2–3 business owners actually look like up close. They have documentation. They have SOPs. They have intention. What they don't have is a system that learns, adapts, and runs without them in the room.
Jason is building at Level 5–6 — a factory that runs while he sleeps. The gap between where most businesses are and where Forge operates is exactly the market. The factory IS the proof. Every session Forge runs autonomously overnight is the live demo for every JV conversation.
The build pipeline exists but has two holes. Every task that goes through the factory currently skips scope confirmation on the way in and skips quality validation on the way out.
■ exists ■ not built — these are the two gates
Five questions, asked before the first line of code is written. This isn't a process tax — it's the difference between building the right thing and building a thing. The entire class of "spent 3 hours on the wrong interpretation" failures comes from skipping this gate.
/align already fires on "starting a new project." Add a pre-build mode: when called with a task/code context (vs a project idea), run the 5-question interview instead of first-principles scoring. Same skill, two modes detected by context.
Before ralph picks up any task tagged code or build, fire a lightweight pre-flight prompt that confirms the 5 questions are answerable from the task description. If not → task goes back to queue with a clarification request.
Every /start asks: "What's the primary build for today?" and runs the 5 questions before anything else. Sets the frame for the whole session instead of discovering gaps mid-build.
When Ralph picks up a task, send a Telegram card with the 5 questions pre-filled from the task description. One-tap confirm or one-tap clarify. Keeps Jason in loop without requiring full session attention.
Automated pass before any deploy. This is the single biggest gap in the current system — every overnight build is unvalidated code going straight to production. The QA gate doesn't need to be perfect. It needs to catch the obvious failures: wrong function signature, missing env var, broken health check, test file that panics.
Three layers, in order of build priority:
/health return 200? Does the primary function run without throwing? (1 min)Called by Ralph after build, before deploy. Reads the task spec + the code diff + the CLAUDE.md. Returns PASS / FAIL with specific reasons. PASS → deploy proceeds. FAIL → task flagged, Jason gets Telegram.
deploy.sh already runs smoke tests. Extend it: after smoke test passes, run a lightweight spec-match check. Non-blocking warning now, blocking gate when confidence is higher.
ralph.sh has pre/post-task hooks (KFS wired). Add QA as a post-task hook for code tasks. QA result gets written to KFS brain event — the factory learns what kinds of tasks tend to fail QA.
Every service already has a CLAUDE.md. The QA gate treats CLAUDE.md as the implicit spec — does the new code violate any of the service's stated contracts? Simple but powerful.
These two gates look like process overhead. They're not. They're the difference between a factory that produces volume and one that produces compounding value.
| Step | What | Effort | Unlocks |
|---|---|---|---|
| 1 | Extend /align with pre-build mode (5 questions on code context) | Small | Gate 1 in every Claude Code session immediately |
| 2 | Add smoke test + spec-match to deploy.sh | Small | Gate 2 on every manual deploy immediately |
| 3 | Wire Gate 1 into ralph.sh (pre-flight before code task pickup) | Medium | Gate 1 for ALL Ralph overnight builds |
| 4 | New /qa skill — reads task spec + diff + CLAUDE.md → PASS/FAIL | Medium | Automated Gate 2 for Ralph, with Telegram notification on FAIL |
| 5 | Wire /qa as ralph.sh post-task hook + KFS brain event | Medium | Factory learns from gate outcomes — self-optimizing QA over time |