maxsimcli 4.11.0 → 4.13.0

package/dist/assets/CHANGELOG.md

@@ -1,3 +1,17 @@
+# [4.12.0](https://github.com/maystudios/maxsimcli/compare/v4.11.0...v4.12.0) (2026-03-11)
+
+
+### Features
+
+* **workflows:** rewrite plan workflows for GitHub-first artifact storage and stage detection ([289fc7e](https://github.com/maystudios/maxsimcli/commit/289fc7e4fbc583e2b182d4a73ebdfc0d85123d2b))
+
+# [4.11.0](https://github.com/maystudios/maxsimcli/compare/v4.10.0...v4.11.0) (2026-03-11)
+
+
+### Features
+
+* **workflows:** wire mcp_github_setup and phase issue creation into init workflows ([fe30a97](https://github.com/maystudios/maxsimcli/commit/fe30a979957e9a480fc6e98bc9e60d51d2f428e2))
+
 # [4.10.0](https://github.com/maystudios/maxsimcli/compare/v4.9.0...v4.10.0) (2026-03-11)
 
 

package/dist/assets/templates/workflows/go.md

@@ -1,5 +1,5 @@
 <purpose>
-Auto-detect project state through deep context gathering, surface problems proactively, and dispatch to the appropriate MAXSIM command. Uses the Show + Act pattern: display detection reasoning first, then act immediately.
+Auto-detect project state through live GitHub queries, surface problems proactively, and dispatch to the appropriate MAXSIM command. Uses the Show + Act pattern: display detection reasoning first, then act immediately.
 </purpose>
 
 <required_reading>
@@ -30,19 +30,24 @@ PLANNING_EXISTS=$(test -d .planning && echo "true" || echo "false")
 
 If `.planning/` does not exist, skip all other checks and go directly to the decision tree (Rule 1: No project found).
 
-**2. Load project state (if .planning/ exists):**
+**2. Load local project context (always from local files per WIRE-02):**
 ```bash
-# State snapshot
+# State snapshot (local)
 STATE=$(node ~/.claude/maxsim/bin/maxsim-tools.cjs state-snapshot 2>/dev/null || echo "{}")
-
-# Roadmap analysis
-ROADMAP=$(node ~/.claude/maxsim/bin/maxsim-tools.cjs roadmap analyze 2>/dev/null || echo "{}")
 ```
 
-**3. Read key files (if they exist):**
-- `.planning/PROJECT.md` -- project name and vision
-- `.planning/STATE.md` -- blockers, decisions, session continuity
-- `.planning/ROADMAP.md` -- phase structure and progress
+Read local files for project context:
+- `.planning/STATE.md` — blockers, decisions, session continuity
+- `.planning/ROADMAP.md` — phase structure and phase ordering
+
+**3. Live GitHub state (primary source — always-live, no cached state):**
+
+Call `mcp_get_all_progress` to get current state of all phases from GitHub. Returns:
+- `phase_number`, `title`, `issue_number`
+- `total_tasks`, `completed_tasks`, `remaining_tasks`
+- `status` (GitHub board column: To Do / In Progress / In Review / Done)
+
+Call `mcp_detect_interrupted` to check for any phases that were interrupted mid-execution (e.g., agent was stopped while a task was marked in-flight).
 
 **4. Git context:**
 ```bash
@@ -52,20 +57,12 @@ GIT_STATUS=$(git status --porcelain 2>/dev/null | head -20)
 # Recent commits
 RECENT_COMMITS=$(git log --oneline -5 2>/dev/null)
 ```
-
-**5. Phase directory scan:**
-```bash
-# List phase directories and their contents
-ls -1 .planning/phases/ 2>/dev/null
-```
-
-For each phase directory, check for PLAN.md, SUMMARY.md, CONTEXT.md, RESEARCH.md files to determine phase state.
 </step>
 
 <step name="problem_detection">
 **Phase 2: Problem Detection**
 
-Check for problems BEFORE suggesting any action. All problems are blocking -- no severity tiers.
+Check for problems BEFORE suggesting any action. All problems are blocking — no severity tiers.
 
 **Check each of these in order:**
 
@@ -78,7 +75,7 @@ If uncommitted changes exist in `.planning/`:
 ## Problem Detected
 
 **Issue:** Uncommitted changes in .planning/ directory
-**Impact:** State drift -- local planning files may diverge from team or lose work
+**Impact:** State drift — local planning files may diverge from team or lose work
 **Resolution:** Commit planning changes to preserve state
 
 **Files with changes:**
@@ -110,22 +107,18 @@ Resolve this before continuing. Options:
 
 Block until user responds.
 
-**3. Failed verification**
-Check for VERIFICATION.md in the current/latest phase with FAIL status:
-```bash
-grep -l "FAIL\|status: failed" .planning/phases/*/VERIFICATION.md 2>/dev/null | tail -1
-```
-If found:
+**3. Failed verification on GitHub**
+Check if any phase issue has a verification comment with FAIL status (from live GitHub data via `mcp_get_all_progress` — look for phases stuck in "In Review" with a known failure, or check recent comments via `mcp_get_issue_detail` for the current phase issue):
 ```
 ## Problem Detected
 
 **Issue:** Phase verification failed
-**Phase:** {phase number and name}
-**Impact:** Phase is not verified as complete -- may have gaps
+**Phase:** {phase number and name} (GitHub Issue #{issue_number})
+**Impact:** Phase is not verified as complete — may have gaps
 **Resolution:** Re-run verification or fix identified issues
 
 Resolve this before continuing. Options:
-1. View verification results
+1. View verification results (check GitHub issue comments)
 2. Re-execute to fix issues
 3. Skip and continue anyway
 ```
@@ -142,6 +135,8 @@ Block until user responds.
 
 Apply rules in strict precedence order. The FIRST matching rule determines the action.
 
+Use live GitHub data from `mcp_get_all_progress` and `mcp_detect_interrupted` (gathered in Phase 1) as the primary source of truth for phase state. Use local ROADMAP.md for phase ordering only.
+
 ```
 Rule 1: No .planning/ directory?
   -> Action: /maxsim:init
@@ -151,31 +146,35 @@ Rule 2: Has blockers in STATE.md? (not cleared in problem detection)
   -> Action: Surface blocker, suggest resolution
   -> Reasoning: "BLOCKED: {blocker text}"
 
-Rule 3: Active phase has plans but not all executed?
-  -> Check: summaries < plans in current phase directory
+Rule 3: Interrupted phase detected (from mcp_detect_interrupted)?
+  -> Action: /maxsim:execute {N}
+  -> Reasoning: "Phase {N} ({name}) was interrupted. Resuming execution."
+
+Rule 4: Phase "In Progress" on GitHub board with incomplete tasks?
+  -> Check: mcp_get_all_progress returns a phase with status="In Progress" and remaining_tasks > 0
   -> Action: /maxsim:execute {N}
-  -> Reasoning: "Phase {N} ({name}) has {X} plans, {Y} executed. Ready to continue."
+  -> Reasoning: "Phase {N} ({name}) has {remaining} tasks remaining. Ready to continue."
 
-Rule 4: Active phase needs planning? (no PLAN.md files)
-  -> Check: no PLAN.md files in current phase directory
+Rule 5: Phase "To Do" on GitHub board (not yet started)?
+  -> Check: mcp_get_all_progress returns the next unstarted phase (status="To Do")
   -> Action: /maxsim:plan {N}
   -> Reasoning: "Phase {N} ({name}) needs planning."
 
-  Sub-check: Does CONTEXT.md exist?
+  Sub-check: Does local CONTEXT.md exist?
   -> If yes: "Discussion complete, ready for research + planning."
   -> If no: "Starting from discussion stage."
 
-Rule 5: Current phase complete, next phase exists?
-  -> Check: all plans have summaries AND next phase exists in roadmap
-  -> Action: /maxsim:plan {N+1}
-  -> Reasoning: "Phase {N} complete. Next: Phase {N+1} ({name})."
+Rule 6: Current phase "In Review" on GitHub board?
+  -> Check: mcp_get_all_progress returns a phase with status="In Review"
+  -> Action: /maxsim:verify {N}
+  -> Reasoning: "Phase {N} ({name}) is awaiting verification."
 
-Rule 6: All phases complete?
-  -> Check: all phases in roadmap have all plans executed
+Rule 7: All phases "Done" on GitHub board?
+  -> Check: mcp_get_all_progress — all phases have status="Done"
   -> Action: /maxsim:progress
   -> Reasoning: "All phases complete. Milestone ready for review."
 
-Rule 7: None of the above?
+Rule 8: None of the above?
   -> Action: Show interactive menu
   -> Reasoning: "Project state is ambiguous. Here are your options."
 ```
@@ -186,53 +185,55 @@ Rule 7: None of the above?
 
 Once a rule matches, display detection reasoning FIRST, then act immediately.
 
-**Format for auto-dispatch (Rules 1-6):**
+**Format for auto-dispatch (Rules 1-7):**
 
 ```
 ## Detected: {summary of what was found}
 
 **Project:** {project name from PROJECT.md, or "New project"}
 **Milestone:** {milestone from ROADMAP.md, or "Not started"}
-**Current phase:** {phase N - name, or "None"}
-**Status:** {description of current state}
+**Current phase:** {phase N - name, or "None"} (GitHub Issue #{issue_number})
+**GitHub Status:** {board column from live mcp_get_all_progress data}
+**Tasks:** {completed}/{total} complete
 
 **Action:** Running /maxsim:{command} {args}...
 ```
 
 Then immediately dispatch the command using the SlashCommand tool. The user can Ctrl+C if the detection is wrong.
 
-**Important:** Show the detection block, then dispatch. Do not ask for confirmation -- this is Show + Act, not Show + Ask.
+**Important:** Show the detection block, then dispatch. Do not ask for confirmation — this is Show + Act, not Show + Ask.
 </step>
 
 <step name="interactive_menu">
-**Phase 5: Interactive Menu (Rule 7 -- no obvious action)**
+**Phase 5: Interactive Menu (Rule 8 — no obvious action)**
 
-When no clear action is detected, show a contextual menu. The menu items are NOT static -- filter based on what makes sense for the current project state.
+When no clear action is detected, show a contextual menu. The menu items are NOT static — filter based on what makes sense for the current project state (use live GitHub data from mcp_get_all_progress).
 
 ```
 ## Project Status
 
 **Project:** {project name}
 **Milestone:** {milestone}
-**Progress:** {X}/{Y} phases complete
+**GitHub Progress:** {X}/{Y} phases Done on board
 
 What would you like to do?
 
-1. /maxsim:plan {next_phase} -- Plan next phase
-2. /maxsim:quick -- Quick ad-hoc task
-3. /maxsim:progress -- View detailed progress
-4. /maxsim:debug -- Debug an issue
+1. /maxsim:plan {next_phase} — Plan next phase
+2. /maxsim:quick — Quick ad-hoc task
+3. /maxsim:progress — View detailed progress
+4. /maxsim:debug — Debug an issue
 
 Or describe what you'd like to do:
 ```
 
 **Contextual filtering rules:**
-- If phases are planned but not executed: show execute options prominently
-- If all phases are done: show `/maxsim:progress` (offers milestone completion)
+- If phases are "In Progress" on GitHub: show execute options prominently
+- If all phases are "Done" on GitHub: show `/maxsim:progress` (offers milestone completion)
 - If recent git activity suggests debugging: show `/maxsim:debug` prominently
-- If no phases exist: show `/maxsim:plan` prominently
+- If no phases exist on board: show `/maxsim:plan` prominently
 - Always include `/maxsim:quick` as it is always relevant
 - Always include an open-ended fallback ("Or describe what you'd like to do")
+- If GitHub not available (mcp calls fail): fall back to local ROADMAP analysis and note degraded mode
 
 Wait for user selection, then dispatch the chosen command.
 </step>
@@ -242,9 +243,12 @@ Wait for user selection, then dispatch the chosen command.
 <constraints>
 - Never ask for confirmation before dispatching (Show + Act, not Show + Ask)
 - Always surface problems BEFORE suggesting actions
-- All problems block -- no severity tiers, no "warnings"
-- No arguments accepted -- this is pure auto-detection
+- All problems block — no severity tiers, no "warnings"
+- No arguments accepted — this is pure auto-detection
 - No mention of old commands (plan-phase, execute-phase, etc.)
-- Keep initial feedback fast -- show "Analyzing..." before heavy operations
+- Keep initial feedback fast — show "Analyzing..." before heavy operations
+- Primary source for phase state: live GitHub (mcp_get_all_progress, mcp_detect_interrupted)
+- Local reads: STATE.md for blockers/decisions, ROADMAP.md for phase ordering only
 - If context gathering fails (tools not available, etc.), fall back to the interactive menu
 </constraints>
+</output>

package/dist/assets/templates/workflows/plan-create.md

@@ -1,7 +1,7 @@
 <purpose>
-Planning stage sub-workflow for /maxsim:plan. Spawns the planner agent to create PLAN.md files, then optionally spawns the planner (in plan-checking mode) for verification with a revision loop.
+Planning stage sub-workflow for /maxsim:plan. Spawns the planner agent to create plan content, posts plans to GitHub as comments on the phase issue, creates task sub-issues, and moves the phase board card to "In Progress". Optionally spawns the planner (in plan-checking mode) for verification with a revision loop.
 
-This file is loaded by the plan.md orchestrator. It does NOT handle gate confirmations or stage routing -- the orchestrator handles that. This sub-workflow focuses ONLY on creating and verifying plans.
+This file is loaded by the plan.md orchestrator. It does NOT handle gate confirmations or stage routing -- the orchestrator handles that. This sub-workflow focuses ONLY on creating, verifying, and publishing plans to GitHub.
 </purpose>
 
 <process>
@@ -15,6 +15,7 @@ The orchestrator provides phase context. Verify we have what we need:
 - `commit_docs`
 - `state_path`, `roadmap_path`, `requirements_path`, `context_path`, `research_path`
 - `phase_req_ids` (requirement IDs that this phase must address)
+- `phase_issue_number` (GitHub Issue number for the phase)
 - `--skip-verify` flag presence
 
 ## Step 2: Resolve Models
@@ -26,38 +27,40 @@ CHECKER_MODEL=$(node .claude/maxsim/bin/maxsim-tools.cjs resolve-model planner -
 
 ## Step 3: Check Existing Plans
 
-```bash
-ls "${phase_dir}"/*-PLAN.md 2>/dev/null
+Query the phase GitHub Issue for existing plan comments:
+```
+mcp_get_issue_detail(issue_number={phase_issue_number})
 ```
 
-**If plans exist:** Offer options via natural conversation:
+Look for comments that contain `<!-- maxsim:type=plan -->`.
+
+**If plan comment(s) exist:** Offer options via natural conversation:
 ```
-Phase {phase_number} already has plan(s):
-{list of existing plan files}
+Phase {phase_number} already has plan(s) on GitHub Issue #{phase_issue_number}.
 
 1. Add more plans (keep existing)
 2. View existing plans
-3. Re-plan from scratch (deletes existing plans)
+3. Re-plan from scratch (deletes existing plan comments)
 ```
 
 - If "Add more": Continue to Step 4 with existing plans preserved.
-- If "View": Display plan files, then re-offer options.
-- If "Re-plan": Delete existing PLAN.md files, continue to Step 4.
+- If "View": Display plan comment contents, then re-offer options.
+- If "Re-plan": Delete existing plan comments from the issue, continue to Step 4.
 
-**If no plans exist:** Continue to Step 4.
+**If no plan comments exist:** Continue to Step 4.
 
 ## Step 4: Gather Context Paths
 
-Extract file paths from the orchestrator context (provided via init JSON):
+Extract file paths and GitHub context from the orchestrator context (provided via init JSON):
 
 ```bash
 STATE_PATH=$(echo "$INIT" | jq -r '.state_path // empty')
 ROADMAP_PATH=$(echo "$INIT" | jq -r '.roadmap_path // empty')
 REQUIREMENTS_PATH=$(echo "$INIT" | jq -r '.requirements_path // empty')
-RESEARCH_PATH=$(echo "$INIT" | jq -r '.research_path // empty')
-CONTEXT_PATH=$(echo "$INIT" | jq -r '.context_path // empty')
 ```
 
+Context and research content will be read from GitHub Issue #{phase_issue_number} comments (identified by `<!-- maxsim:type=context -->` and `<!-- maxsim:type=research -->` markers) rather than from local files.
+
 ## Step 5: Spawn Planner
 
 Display:
@@ -65,20 +68,20 @@ Display:
 Planning Phase {phase_number}: {phase_name}...
 ```
 
-Construct the planner prompt:
+Construct the planner prompt. The planner must return plan content as structured markdown in its response (not write local files):
 
 ```markdown
 <planning_context>
 **Phase:** {phase_number}
 **Mode:** standard
 
-<files_to_read>
+<context_sources>
+- GitHub Issue #{phase_issue_number} context comment (USER DECISIONS -- locked choices from discussion stage)
+- GitHub Issue #{phase_issue_number} research comment (Technical Research findings)
 - {state_path} (Project State)
 - {roadmap_path} (Roadmap)
 - {requirements_path} (Requirements)
-- {context_path} (USER DECISIONS from discussion stage)
-- {research_path} (Technical Research)
-</files_to_read>
+</context_sources>
 
 **Phase requirement IDs (every ID MUST appear in a plan's `requirements` field):** {phase_req_ids}
 
@@ -87,16 +90,31 @@ Construct the planner prompt:
 </planning_context>
 
 <downstream_consumer>
-Output consumed by /maxsim:execute. Plans need:
+Output consumed by /maxsim:execute via GitHub Issue comments. Plans need:
 - Frontmatter (wave, depends_on, files_modified, autonomous)
 - Tasks in XML format
 - Verification criteria
 - must_haves for goal-backward verification
 </downstream_consumer>
 
+<output_format>
+Return each plan as a separate fenced code block with a plan number header.
+Do NOT write local PLAN.md files -- plans will be posted to GitHub by the orchestrator.
+
+Example structure:
+## Plan 01
+
+```yaml
+# frontmatter here
+```
+
+<tasks>
+...
+</tasks>
+</output_format>
+
 <quality_gate>
-- [ ] PLAN.md files created in phase directory
-- [ ] Each plan has valid frontmatter
+- [ ] Each plan returned in response with valid frontmatter
 - [ ] Tasks are specific and actionable
 - [ ] Dependencies correctly identified
 - [ ] Waves assigned for parallel execution
@@ -120,18 +138,16 @@ Task(
 Parse the planner's return message:
 
 - **`## PLANNING COMPLETE`:**
-  Validate PLAN.md files were created:
-  ```bash
-  ls "${phase_dir}"/*-PLAN.md 2>/dev/null | wc -l
-  ```
+  Extract the plan content from the planner's response. Parse out individual plans (each is a separate fenced block with a plan number header).
 
-  If plans found:
-  - Display plan count and filenames.
+  If plans found in response:
+  - Display plan count.
+  - Store plans in memory as `plans_content` array.
   - If `--skip-verify` flag is set OR `plan_checker_enabled` is false: skip to Step 9.
   - Otherwise: continue to Step 7 (verification).
 
-  If no plans found:
-  - Error: "Planner reported complete but no PLAN.md files found."
+  If no plans in response:
+  - Error: "Planner reported complete but returned no plan content."
   - Offer: retry or abort.
 
 - **`## CHECKPOINT REACHED`:**
@@ -157,20 +173,23 @@ Display:
 Verifying plans...
 ```
 
-Construct the checker prompt:
+Construct the checker prompt. Pass the in-memory `plans_content` directly:
 
 ```markdown
 <verification_context>
 **Phase:** {phase_number}
 **Phase Goal:** {goal from ROADMAP}
 
-<files_to_read>
-- {phase_dir}/*-PLAN.md (Plans to verify)
+<plans_to_verify>
+{plans_content -- the plan(s) returned by the planner in step 5}
+</plans_to_verify>
+
+<context_sources>
+- GitHub Issue #{phase_issue_number} context comment (USER DECISIONS)
+- GitHub Issue #{phase_issue_number} research comment (Technical Research)
 - {roadmap_path} (Roadmap)
 - {requirements_path} (Requirements)
-- {context_path} (USER DECISIONS from discussion stage)
-- {research_path} (Technical Research)
-</files_to_read>
+</context_sources>
 
 **Phase requirement IDs (MUST ALL be covered):** {phase_req_ids}
 
@@ -214,17 +233,20 @@ Task(
   Sending plans back for revision... (iteration {iteration_count}/3)
   ```
 
-  Construct revision prompt:
+  Construct revision prompt. Pass the current in-memory `plans_content` directly:
 
   ```markdown
   <revision_context>
   **Phase:** {phase_number}
   **Mode:** revision
 
-  <files_to_read>
-  - {phase_dir}/*-PLAN.md (Existing plans)
-  - {context_path} (USER DECISIONS from discussion stage)
-  </files_to_read>
+  <existing_plans>
+  {plans_content -- current in-memory plan content}
+  </existing_plans>
+
+  <context_sources>
+  - GitHub Issue #{phase_issue_number} context comment (USER DECISIONS)
+  </context_sources>
 
   **Checker issues:** {structured_issues_from_checker}
   </revision_context>
@@ -232,7 +254,7 @@ Task(
   <instructions>
   Make targeted updates to address checker issues.
   Do NOT replan from scratch unless issues are fundamental.
-  Return what changed.
+  Return the full revised plan content (same format as original -- one fenced block per plan).
   </instructions>
   ```
 
@@ -267,32 +289,98 @@ Task(
   - If "Provide guidance": Get user input, re-spawn planner with user guidance, reset iteration_count, go to Step 7.
   - If "Abort": Exit workflow.
 
-## Step 9: Commit Plans
+## Step 9: Post Plans to GitHub
 
-If `commit_docs` is true:
+After verification passes (or is skipped), post each plan as a separate comment on the phase GitHub Issue.
 
-```bash
-node .claude/maxsim/bin/maxsim-tools.cjs commit "docs(${padded_phase}): create phase plan" --files "${phase_dir}"
+For each plan in `plans_content`:
+
+```
+mcp_post_plan_comment(
+  phase_issue_number={phase_issue_number},
+  plan_number={plan_number},  // e.g. "01", "02"
+  plan_content="<!-- maxsim:type=plan -->\n" + {plan_content}
+)
+```
+
+If posting any plan comment fails:
+- Report which plans failed to post.
+- Offer retry for failed plans.
+- Do not proceed to task creation until all plans are successfully posted.
+
+Display:
+```
+Plans posted to GitHub Issue #{phase_issue_number}: {plan_count} plan(s).
+```
+
+## Step 10: Create Task Sub-Issues
+
+Parse tasks from the posted plans. For each `<task>` element in the plan XML, extract:
+- `id` (e.g. "1.1", "1.2")
+- `title`
+- `description` / body content
+
+Call `mcp_batch_create_tasks` with the full tasks array and the phase issue number:
+
+```
+mcp_batch_create_tasks(
+  phase_issue_number={phase_issue_number},
+  tasks=[
+    { id: "1.1", title: "Task title", description: "Task body" },
+    ...
+  ]
+)
+```
+
+Each task becomes a GitHub sub-issue linked to the phase issue.
+
+**If batch creation fails (partial or total):**
+- Report which task IDs failed to create.
+- Offer: retry failed tasks, skip and continue, or abort.
+- Do not proceed to board transition until task creation succeeds or user accepts partial failure.
+
+Display:
+```
+Task sub-issues created: {task_count} tasks linked to Issue #{phase_issue_number}.
+```
+
+## Step 11: Move Phase to In Progress
+
+After all plans are posted and task sub-issues are created, move the phase issue to "In Progress" on the project board:
+
+```
+mcp_move_issue(
+  issue_number={phase_issue_number},
+  status="In Progress"
+)
+```
+
+Display:
+```
+Phase #{phase_issue_number} moved to "In Progress" on the board.
 ```
 
-## Step 10: Return to Orchestrator
+## Step 12: Return to Orchestrator
 
-After plans are created and optionally verified, return control to the plan.md orchestrator. Do NOT show gate confirmation or next steps -- the orchestrator handles the final gate.
+After plans are posted, task sub-issues created, and the phase moved to "In Progress", return control to the plan.md orchestrator. Do NOT show gate confirmation or next steps -- the orchestrator handles the final gate.
 
 Display a brief completion message:
 ```
-Planning complete. {plan_count} plan(s) created in {phase_dir}.
+Planning complete. {plan_count} plan(s) posted to GitHub Issue #{phase_issue_number}. {task_count} task sub-issues created.
 ```
 
 </process>
 
 <success_criteria>
 - Planner and checker models resolved from config
-- Existing plans detected and handled (add/view/replan options)
-- Planner agent spawned with full context (STATE.md, ROADMAP.md, REQUIREMENTS.md, CONTEXT.md, RESEARCH.md)
-- PLAN.md files created and validated
+- Existing plans detected from GitHub Issue comments and handled (add/view/replan options)
+- Planner agent spawned with context from GitHub Issue comments (context + research) and local files (state, roadmap, requirements)
+- Plan content returned from planner as in-memory document (no local PLAN.md files written)
 - Checker verification loop runs (max 3 iterations) unless --skip-verify
-- Revision loop sends issues back to planner for targeted fixes
-- Plan files committed if commit_docs is true
+- Revision loop passes in-memory plan content to planner for targeted fixes
+- Plans posted to GitHub Issue #{phase_issue_number} as comments with <!-- maxsim:type=plan --> markers
+- Task sub-issues created via mcp_batch_create_tasks linked to phase issue
+- Phase issue moved to "In Progress" via mcp_move_issue
+- Failed task creation surfaced with retry option (WIRE-07)
 - Control returned to orchestrator without showing gate or next steps
 </success_criteria>