[{"data":1,"prerenderedAt":213},["ShallowReactive",2],{"docs-\u002Fdocs\u002Fforge":3},{"id":4,"title":5,"body":6,"description":205,"extension":206,"meta":207,"navigation":208,"path":209,"seo":210,"stem":211,"__hash__":212},"docs\u002Fdocs\u002Fforge.md","Phase B - Forge (The Autonomous Loop)",{"type":7,"value":8,"toc":191},"minimark",[9,14,18,21,25,36,39,43,48,56,78,85,89,92,95,99,102,116,119,123,126,130,133,144,147,151,154,157,180,183],[10,11,13],"h2",{"id":12},"overview","Overview",[15,16,17],"p",{},"From your perspective, the Forge phase is a black box. You triggered a ticket; it is now \"In Progress\". You can go do other things. The agents will reach out only if they hit a genuine blocker that requires human judgment.",[15,19,20],{},"Inside the box, a structured loop is running.",[10,22,24],{"id":23},"the-internal-loop","The internal loop",[26,27,32],"pre",{"className":28,"code":30,"language":31},[29],"language-text","Triggered\n   │\n   ▼\nAnalytic writes affected use-case specs\n(API contracts, data model, components,\n test scenarios, flow diagrams)\n   │\n   ▼\nDev builds (FE + BE)\n   │\n   ▼\nReviewer audits code ──── FAIL ───► Dev revises\n   │\n PASS\n   │\n   ▼\nDevOps spins ephemeral env\n   │\n   ▼\nTester runs suite ──── FAIL ───► Dev fixes + Reviewer re-audits\n   │\n PASS\n   │\n   ▼\nValidation Package assembled\n   │\n   ▼\nYou are notified\n","text",[33,34,30],"code",{"__ignoreMap":35},"",[15,37,38],{},"Each transition in the loop is gated. An agent cannot skip a gate. A Dev cannot start coding before the Analytic's use-case specs exist. A Dev cannot push code that has not passed Review. A Tester cannot sign off on a suite that has not run against the ephemeral environment. The loop enforces quality at every step without requiring your attention.",[10,40,42],{"id":41},"what-each-agent-does","What each agent does",[44,45,47],"h3",{"id":46},"analytic-agent","Analytic agent",[15,49,50,51,55],{},"The Analytic agent runs ",[52,53,54],"strong",{},"first"," in the Forge loop. It reads the staged ticket and produces full use-case specifications for every part of the product the change affects. A use-case spec typically contains:",[57,58,59,63,66,69,72,75],"ul",{},[60,61,62],"li",{},"A short narrative of the use case and its actor",[60,64,65],{},"A Mermaid sequence diagram covering the happy path and the alternative branches",[60,67,68],{},"The API contract (endpoint, request body, response shape, status codes)",[60,70,71],{},"Frontend and backend validation tables (field, constraints, size, pattern, notes)",[60,73,74],{},"Data-model changes (new entities, columns, migrations)",[60,76,77],{},"A test-case matrix (positive, negative, edge cases)",[15,79,80,81,84],{},"In short, the Analytic turns \"we want feature X\" into a deterministic blueprint that Dev, Reviewer, and Tester can all execute against without further input from you. Real examples of this format live under ",[33,82,83],{},"documentation\u002Fusecases\u002F"," - one file per use case, indexed in a per-domain README.",[44,86,88],{"id":87},"dev-agents-fe-be","Dev agents (FE + BE)",[15,90,91],{},"Dev agents pick up the Analytic's use-case specs and implement them. They produce code, migrations, configuration changes, and documentation updates exactly as the spec describes.",[15,93,94],{},"FE and BE Devs work in parallel where possible. Shared contracts (API schemas, TypeScript interfaces) are established first to allow concurrent work.",[44,96,98],{"id":97},"reviewer-agent","Reviewer agent",[15,100,101],{},"The Reviewer reads every diff before it is promoted. It checks for:",[57,103,104,107,110,113],{},[60,105,106],{},"Adherence to the accepted technical specification",[60,108,109],{},"Security issues (injection risks, auth gaps, secrets in code)",[60,111,112],{},"Performance regressions",[60,114,115],{},"Code style and maintainability",[15,117,118],{},"If the Reviewer fails a diff, it returns a structured list of issues to the Dev. The Dev revises and resubmits. This inner loop runs silently.",[44,120,122],{"id":121},"devops-agent","DevOps agent",[15,124,125],{},"Once code passes Review, DevOps spins up an ephemeral environment - a clean, isolated deployment that mirrors production configuration. This environment is used exclusively by the Tester for this ticket and is torn down after the Validation Package is assembled.",[44,127,129],{"id":128},"tester-agent","Tester agent",[15,131,132],{},"The Tester executes the test suite against the ephemeral environment. The suite includes:",[57,134,135,138,141],{},[60,136,137],{},"Unit tests generated during Dev",[60,139,140],{},"Integration tests against the API contract",[60,142,143],{},"End-to-end tests covering the acceptance criteria defined in the Feed phase",[15,145,146],{},"A failure returns a structured report to the Dev, and the inner loop restarts.",[10,148,150],{"id":149},"the-interruption-protocol","The interruption protocol",[15,152,153],{},"Agents interrupt you only when they encounter a decision that genuinely requires human judgment and cannot be resolved by re-reading the spec or making a reasonable inference.",[15,155,156],{},"An interruption looks like this:",[158,159,160,166,177],"blockquote",{},[15,161,162,165],{},[52,163,164],{},"Ticket #142 - Interruption required","\nThe payment webhook spec requires idempotency handling, but it does not specify the idempotency window. Options:",[57,167,168,171,174],{},[60,169,170],{},"24 hours (Stripe default)",[60,172,173],{},"7 days (conservative)",[60,175,176],{},"Configurable via environment variable",[15,178,179],{},"Which should we implement?",[15,181,182],{},"Interruptions are specific, offer concrete options, and require a one-word or one-sentence answer. They are never vague and never ask you to re-explain the requirement.",[158,184,185],{},[15,186,187,190],{},[52,188,189],{},"Note:"," A well-written ticket spec should result in zero interruptions. If a ticket type consistently generates interruptions, the Analytic agent's instructions for that ticket type need refinement.",{"title":35,"searchDepth":192,"depth":192,"links":193},2,[194,195,196,204],{"id":12,"depth":192,"text":13},{"id":23,"depth":192,"text":24},{"id":41,"depth":192,"text":42,"children":197},[198,200,201,202,203],{"id":46,"depth":199,"text":47},3,{"id":87,"depth":199,"text":88},{"id":97,"depth":199,"text":98},{"id":121,"depth":199,"text":122},{"id":128,"depth":199,"text":129},{"id":149,"depth":192,"text":150},"The internal build-review-test cycle that runs silently after you trigger a ticket.","md",{},true,"\u002Fdocs\u002Fforge",{"title":5,"description":205},"docs\u002Fforge","dus5gf9khudzBcgskmQBAt4hy3X-NY6CyKLThAuPkeM",1778559261707]