You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The fixed miner lifecycle is discover → analyze → plan → prepare → create → manage → repeat. Rather than every miner inventing its own step graph from scratch, provide a library of reusable plan TEMPLATES in the exact stateless DAG shape the existing MCP tools already speak: gittensory_build_plan / gittensory_plan_status / gittensory_record_step_result (src/mcp/server.ts:1421-1434), whose steps carry id/title/actionClass/dependsOn/maxAttempts (see rawPlanStepSchema at src/mcp/server.ts:324). This is pure data + a small builder function — no new state machine, since gittensory_build_plan already normalizes raw steps into the validated DAG.
Deliverables
packages/gittensory-engine/src/plan-templates.ts exporting one template function per lifecycle stage transition, e.g. analyzeToplanTemplate(issueContext) returning RawPlanStep[] in EXACTLY the shape gittensory_build_plan's buildPlanShape expects ({ id, title, actionClass?, dependsOn?, maxAttempts? })
At minimum: an "analyze" template (feasibility check → RAG retrieval → prompt-packet build) and a "prepare" template (branch creation → coding-agent invocation placeholder step → local test run)
Each template's steps use dependsOn to encode the real ordering (e.g. prompt-packet build depends on both feasibility-check and RAG-retrieval steps completing)
Unit tests asserting each template's output round-trips cleanly through the ACTUAL rawPlanStepSchema zod shape (import it, don't hand-roll a copy) so the templates never drift from what gittensory_build_plan accepts
No actuation anywhere — templates only describe steps; they don't run anything
The fixed miner lifecycle is discover → analyze → plan → prepare → create → manage → repeat. Rather than every miner inventing its own step graph from scratch, provide a library of reusable plan TEMPLATES in the exact stateless DAG shape the existing MCP tools already speak:
gittensory_build_plan/gittensory_plan_status/gittensory_record_step_result(src/mcp/server.ts:1421-1434), whose steps carryid/title/actionClass/dependsOn/maxAttempts(seerawPlanStepSchemaatsrc/mcp/server.ts:324). This is pure data + a small builder function — no new state machine, sincegittensory_build_planalready normalizes raw steps into the validated DAG.Deliverables
packages/gittensory-engine/src/plan-templates.tsexporting one template function per lifecycle stage transition, e.g.analyzeToplanTemplate(issueContext)returningRawPlanStep[]in EXACTLY the shapegittensory_build_plan'sbuildPlanShapeexpects ({ id, title, actionClass?, dependsOn?, maxAttempts? })dependsOnto encode the real ordering (e.g. prompt-packet build depends on both feasibility-check and RAG-retrieval steps completing)rawPlanStepSchemazod shape (import it, don't hand-roll a copy) so the templates never drift from whatgittensory_build_planacceptsReferences
src/mcp/server.ts:1421(gittensory_build_plantool registration + description)src/mcp/server.ts:324(rawPlanStepSchema— the EXACT step shape templates must produce)src/mcp/server.ts:333(planStepSchema— the normalized shapebuild_planreturns, showingstatus/attemptsget added)src/mcp/server.ts:321(module comment: "feat(agent): multi-step action DAG executor #783 multi-step plan DAG — stateless: pass the plan back each call")