feat(miner-plan): issue-to-plan decomposition heuristic

[JSONbored]

The stateless MCP plan-DAG surface already exists end to end except for the one piece that actually decomposes a target issue into steps. rawPlanStepSchema (src/mcp/server.ts:392-400) and planDagSchema (src/mcp/server.ts:413) define the wire shape; gittensory_build_plan / gittensory_plan_status / gittensory_record_step_result (same file, tool registrations beginning at lines 1623, 1628, and 1633) are the stateless tools that validate and advance a caller-supplied plan; packages/gittensory-miner/lib/plan-store.js is the already-done local SQLite persistence for it, with its own independent re-validation of the DAG shape on every save/load (isValidStep, lines 66-78; validatePlanDag, lines 82-118, including cycle detection). None of this builds a plan from an issue — every caller today has to hand it one already-built.

The closest existing prior art is packages/gittensory-engine/src/plan-templates.ts: PLAN_TEMPLATE_BUILDERS (line 111) gives fixed, 3-step templates per miner lifecycle stage (discover/analyze/plan/prepare/create/manage), each producing RawPlanStep[] (type at line 11) templated only by a generic subject string — these describe the miner's OWN fixed process, not the target issue's actual implementation work. Tellingly, planPlanTemplate's own step list (lines 69-78) includes a step this issue is the real implementation of: { id: "plan-dag-build", title: "Build execution plan DAG", actionClass: "compose", dependsOn: ["packet-validate"] } (line 73) — that step currently has no logic behind it anywhere in the repo.

The natural input is the already-done analyze-phase output: PromptPacket/PromptPacketInput (packages/gittensory-engine/src/prompt-packet.ts:25-26, built from the four scrubbed text fields defined at line 16 — taskBrief, feasibilityNotes, retrievalContext, constraints) is the metadata-only bundle #2321 built specifically to hand a coding agent everything it needs about a target issue without ever touching source content. A decomposition heuristic sitting between "prompt packet built" and "execution plan DAG" would consume that (or the raw issue title/body/labels directly) and emit a RawPlanStep[] compatible with rawPlanStepSchema and plan-store.js's validator.

Deliverables

• A pure function in packages/gittensory-engine/src/ (e.g. issue-plan-decomposition.ts) that takes issue-level input (at minimum title/body/labels, or a PromptPacket) and returns RawPlanStep[] in the same shape as plan-templates.ts's builders — mirror the RawPlanStep type there (line 11) rather than inventing a parallel one
• Output must pass plan-store.js's isValidStep/validatePlanDag (packages/gittensory-miner/lib/plan-store.js:66-118) unmodified — no unknown step keys, valid dependsOn graph, no cycles
• Deterministic: same issue input always yields the same plan (matches every other pure composer in this package)
• Export from the package's public entrypoint (packages/gittensory-engine/src/index.ts)
• Wire the result into planPlanTemplate's plan-dag-build step (plan-templates.ts:73) or document why it stays a standalone caller-invoked function instead
• Unit tests covering a range of issue shapes (minimal body, long body, many labels, no labels) and asserting the DAG is acyclic and schema-valid

References

• src/mcp/server.ts:392-400 (rawPlanStepSchema) and :413 (planDagSchema) — the target output contract
• src/mcp/server.ts:1623, :1628, :1633 (gittensory_build_plan / gittensory_plan_status / gittensory_record_step_result tool registrations)
• packages/gittensory-miner/lib/plan-store.js:66-118 (isValidStep / validatePlanDag, the shape this heuristic's output must satisfy)
• packages/gittensory-engine/src/plan-templates.ts:73 (plan-dag-build placeholder step this heuristic is the real implementation of)
• packages/gittensory-engine/src/plan-templates.ts:11, :69-78, :111 (RawPlanStep type, planPlanTemplate, PLAN_TEMPLATE_BUILDERS — closest existing prior art)
• packages/gittensory-engine/src/prompt-packet.ts:16, :25-26 (PromptPacketTextField, PromptPacket/PromptPacketInput — the likely analyze-phase input, test(miner-plan): adversarial redaction/allowlist test suite for the prompt-packet builder #2321, already done)
• Wave 2 tracker 🧩 Wave 2 — Analyze, Plan, Create & Deploy (HELD tracker) #2353, Phase 2

[linear-code]

JSO-3279