pi-plans 0.1.0 → 0.1.1

package/README.md

@@ -1,7 +1,7 @@
-<h1 align="center">pi-plans</h1>
+<h1 align="center">π-plans</h1>
 
 <p align="center">
-  <img src="docs/assets/pi-plans-logo.svg?v=3" alt="pi-plans: Plan. Review. Execute." width="640" />
+  <img src="docs/assets/pi-plans-logo.svg?v=4" alt="pi-plans: Plan. Review. Execute." width="640" />
 </p>
 
 <h2 align="center"><b>Plan. Review. Execute.</b></h2>
@@ -58,8 +58,9 @@ A rough change request becomes a versioned Markdown plan instead of a surprise d
    =============================================== write guard OFF
                  |
         tracked execution loop
+   fused AGENTS.md × Ponytail executor rules
    checklist injected each turn, [DONE:VC-xxx]
-   markers tracked with a footer widget
+   markers tracked via bottom status bar + detail panel
                  |
                  v
            run status: done
@@ -93,17 +94,13 @@ Pi:  Wrote ./docs/pi-plans/2026-08-26-split-execution-loop/PLAN_v1.md
      - [ ] `VC-001` covers `I-001`; pass condition: `npm test` passes;
        evidence: test output; metric: zero failing tests.
 
-Pi:  Next step for refining the plan?
-     1. Reviewer round (recommended)
-     2. Criticizer round
-     3. Accept plan for tracked execution
+Pi:  Accept the plan and execute it now?
+     1. ✓ Accept plan and execute now (recommended)
+     2. Accept plan, don't execute yet
+     3. Run another round: Reviewer
      ...
 
-You: Accept plan for tracked execution.
-
-Pi:  Execute this plan now?
-     1. Execute this plan now (recommended)
-     2. Stop after planning
+You: 1 — accept and execute.
 ```
 
 Planning artifacts live under `./docs/pi-plans/YYYY-MM-DD-<topic>/` by default (public, committed). Prefer `.git/pi_plans/plans` if you want them private to the repository.
@@ -116,7 +113,8 @@ Planning artifacts live under `./docs/pi-plans/YYYY-MM-DD-<topic>/` by default (
 | Choice prompts | `ask_choice`: recommended option first, answers auto-recorded per run |
 | Refinement rounds | Read-only reviewer/criticizer Pi subagents consolidate findings into the next plan version |
 | Workspace state | Config, runs, decisions, refs, and subagent ledgers in `.git/pi_plans/` (git common dir) |
-| Tracked execution | Checklist injected each turn; `[DONE:VC-xxx]` markers drive progress |
+| Tracked execution | Checklist injected each turn; `[DONE:VC-xxx]` markers drive progress; live `x/y · spent · in/out-toks` in the bottom status bar |
+| Efficient executor prompt | Each turn, the executor is steered by a fused rule set — Marcos Hernanz's AGENTS.md principles × Ponytail minimalism: layered growth, simplest implementation, long-term architecture (no stopgaps), library discipline — so plans finish in fewer tokens and fewer detours |
 | Write guard | `edit`/`write` blocked outside planning artifacts while a run is active |
 
 ## Interface overview
@@ -124,7 +122,7 @@ Planning artifacts live under `./docs/pi-plans/YYYY-MM-DD-<topic>/` by default (
 | Tool / Command | Purpose |
 |---|---|
 | `plans` | State CLI: `init`, `show`, `set-language`, `set-artifact-root`, `set-role`, `start-run`, `set-status`, `record-decision`, `record-ref`, `record-subagent` |
-| `ask_choice` | Numbered choice prompt; `autoComplete: false` for execution handoff / external-state questions |
+| `ask_choice` | Numbered choice prompt; `autoComplete: false` for the merged accept/execute question and external-state questions |
 | `refine` | Reviewer/criticizer round via read-only subagents (`--tools read,grep,find,ls`); `reviewers: 3` for big plans; enforces role/model confirmation gates |
 | `execute_plan` | Execution handoff: re-confirms with the user, enters extension-managed execution mode |
 | `/plans` | Show config, active run, execution progress |
@@ -132,6 +130,23 @@ Planning artifacts live under `./docs/pi-plans/YYYY-MM-DD-<topic>/` by default (
 | `/update-plan [plan.md] [reason…]` | Interrupt-and-refine: stops execution (if any), returns the run to planning, and directs the agent to revise the plan into `PLAN_vN+1.md` while preserving verified work |
 | `/plans-stop` | Stop execution mode |
 | `/plans-abandon` | Abandon the active run (lifts the write guard; artifacts stay) |
+| Status bar (lifecycle) | 💬 Q&A → 📝 draft written (planning sub-phases) → ⌛ executing `x/y · spent · in/out-toks` → ⛔ stopped / 🎯 done / 🚫 abandoned |
+
+## The execution rules
+
+Once you approve the handoff, every turn injects a compact rule set that fuses Marcos Hernanz's AGENTS.md seven principles with Ponytail minimalism — so the executor finishes plans in fewer tokens and fewer detours:
+
+<details>
+<summary>The four fused rules (click to expand)</summary>
+
+1. **Grow in layers** — smallest end-to-end slice first, then stack each new capability on top of what already works.
+2. **Simplest implementation** — no speculative abstractions, configuration, or indirection; modular components with clearly separated concerns.
+3. **Long-term architecture, no stopgaps** — no backward-compatibility layers, fallbacks, or migrations; remove the obsolete paths a change obsoletes.
+4. **Library discipline** — prefer established, well-maintained libraries; check the project's existing dependencies (docs and types) before writing your own or adding a package.
+
+</details>
+
+The rules cost four lines per turn and buy back far more: fewer wrong turns, shorter implementation paths, plans that finish in fewer tokens.
 
 ## Skills
 
@@ -198,7 +213,7 @@ Both run on Node ≥ 22.6 via `--experimental-strip-types`; no npm dependencies.
 
 **Why do I have to approve before any code changes?**
 
-The plan is the contract. Refinement converges on scope while nothing is writable yet; the execution handoff is a separate explicit approval that also lifts the write guard. You always see — and can veto — what will happen before it happens.
+The plan is the contract. Refinement converges on scope while nothing is writable yet; the merged accept/execute question is an explicit, never-auto-completed approval that also lifts the write guard. You always see — and can veto — what will happen before it happens.
 
 **What can Auto-complete decide on my behalf?**
 
@@ -212,6 +227,10 @@ Preferences and run ledgers in `.git/pi_plans/` inside your workspace's git dire
 
 Prompts produce one-shot diffs with no recorded reasoning. pi-plans produces versioned artifacts — decisions, references, reviewer findings, dispositions, a verifier checklist — that are auditable, resumable across sessions, and enforced by tooling rather than goodwill.
 
+**Doesn't injecting execution rules every turn cost extra tokens?**
+
+The injected rule set is four compressed lines. It buys back more than it costs: the executor stops re-deriving discipline (no speculative abstractions, no compatibility detours, no reinvented helpers), so finished items converge in fewer turns and fewer tokens overall.
+
 ## License
 
 MIT.

package/docs/assets/pi-plans-logo.svg

@@ -32,8 +32,8 @@
   </g>
 
   <!-- wordmark -->
-  <text x="150" y="96" font-family="-apple-system,'Segoe UI',Helvetica,Arial,sans-serif" font-size="60" font-weight="700" fill="#ffffff">pi-plans</text>
-  <rect x="153" y="110" width="236" height="6" rx="3" fill="url(#bar)"/>
+  <text x="150" y="96" font-family="-apple-system,'Segoe UI',Helvetica,Arial,sans-serif" font-size="60" font-weight="700" fill="#ffffff">π-plans</text>
+  <rect x="153" y="110" width="210" height="6" rx="3" fill="url(#bar)"/>
   <text x="151" y="147" font-family="'SF Mono',Menlo,Consolas,monospace" font-size="16" letter-spacing="4" fill="#ddd6fe">PLAN·REVIEW·EXECUTE</text>
 
   <!-- pipeline: plan -> review -> execute -->

package/index.ts

@@ -139,6 +139,16 @@ export default function piPlansExtension(pi: ExtensionAPI): void {
 		};
 	});
 
+	// The turn_end projection does not carry usage; message_end delivers the
+	// full assistant message, so we cache it there and consume it per turn.
+	let lastAssistantUsage: { input: number; output: number } | null = null;
+	pi.on("message_end", async (event) => {
+		const message = event.message as { role?: string; usage?: { input?: number; output?: number } };
+		if (message?.role === "assistant" && message.usage) {
+			lastAssistantUsage = { input: message.usage.input ?? 0, output: message.usage.output ?? 0 };
+		}
+	});
+
 	pi.on("turn_end", async (event, ctx) => {
 		const message = event.message as { role?: string; content?: Array<{ type: string; text?: string }> };
 		if (!message || message.role !== "assistant") {
@@ -151,7 +161,12 @@ export default function piPlansExtension(pi: ExtensionAPI): void {
 			.join("\n");
 		const changedIds = applyDoneMarkers(text);
 		if (changedIds.length > 0) {
-			recordExecutionCompletion(pi, ctx, changedIds);
+			// Attribute this turn's token usage to the finished items.
+			const projection = (event.message as { usage?: { input?: number; output?: number } }).usage;
+			const raw = projection ?? lastAssistantUsage;
+			lastAssistantUsage = null; // consumed: never re-attribute a stale turn
+			const usage = raw ? { input: raw.input ?? 0, output: raw.output ?? 0 } : undefined;
+			recordExecutionCompletion(pi, ctx, changedIds, usage);
 		}
 		if (getExecution() && isExecutionComplete()) {
 			completeExecution(pi, ctx);
@@ -322,7 +337,7 @@ export default function piPlansExtension(pi: ExtensionAPI): void {
 			if (focus) lines.push(`User-reported problems / refocus: ${focus}`);
 			lines.push(
 				"",
-				"Follow the original planning-skill contract for revisions: collect needed clarifications via ask_choice (one question at a time, recorded), apply evidence-based revisions only, then ask the next refinement-mode question, and finish with the execution handoff (ask_choice with autoComplete: false → execute_plan pointing at the new version).",
+				"Follow the original planning-skill contract for revisions: collect needed clarifications via ask_choice (one question at a time, recorded), apply evidence-based revisions only, then ask the next merged accept/execute question (autoComplete: false — ✓ Accept & execute now / Accept, don't execute yet / another round) and call execute_plan pointing at the new version on accept.",
 			);
 
 			await pi.sendUserMessage(lines.join("\n"));

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-plans",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Human-in-the-loop planning extension for the Pi coding agent: researched, refined Markdown plans before any code changes.",
   "license": "MIT",
   "type": "module",

package/references/pi-planning-workflow.md

@@ -59,7 +59,7 @@ Every user-facing planning or refinement question goes through the `ask_choice`
 
 - `options`: ordered options, recommended option first with `recommended: true` (exactly one), each with the tradeoff that matters in `description`;
 - do not add `Other` or `Auto-complete` yourself — the tool appends `Other…` second-last and `Auto-complete` last;
-- pass `autoComplete: false` for the execution handoff and for any install waiver, publishing, deployment, merge, push, credential, or external-state question. Auto-complete may choose the recommended planning or refinement option only.
+- pass `autoComplete: false` for the merged accept/execute question — it contains the execution approval, so Auto-complete never appears there — and for any install waiver, publishing, deployment, merge, push, credential, or external-state question. Auto-complete may choose the recommended planning or refinement option only.
 
 Answers are recorded automatically in the active run's `decisions.jsonl`. You must still maintain `DECISIONS.md` in the artifact directory (summary table of questions, options, answers, answer sources, open assumptions).
 
@@ -100,13 +100,13 @@ The execution loop parses `- [ ] \`VC-###\`` items and tracks `[DONE:VC-###]` ma
 
 ## Refinement
 
-After each plan version, ask one refinement-mode question via `ask_choice`. The recommended (first) option follows the skill level's default sequence; the user may always pick a different mode or keep refining:
+After each plan version, ask one merged accept/execute question via `ask_choice` with `autoComplete: false` — it contains the execution approval, so Auto-complete never appears. Options:
 
-- `plan-small`: recommend `Criticizer` for the first (and only default) round; afterwards recommend `Accept plan for tracked execution`.
-- `plan-normal`: recommend `Reviewer` first, then `Criticizer`; afterwards recommend `Accept plan for tracked execution`.
-- `plan-big`: recommend `Reviewer` first as three concurrent independent reviewers (`refine` with `reviewers: 3`), then `Criticizer`; afterwards recommend `Accept plan for tracked execution`.
+1. `✓ Accept PLAN_vN and execute it now` — mark the plan accepted (`plans set-status accepted`), then call the `execute_plan` tool.
+2. `Accept PLAN_vN, don't execute yet` — mark accepted; resume later via `/plans-execute`.
+3. `Run another round: <the level's default next refine mode>` — only while the level's default sequence is unfinished.
 
-Option list for the question: the recommended next step; the other refinement modes with their tradeoffs; `Accept plan for tracked execution`; `Other`; `Auto-complete`.
+The recommended option follows the skill level's default sequence: while the default rounds are unfinished it is option 3's default next mode (`plan-small`: `Criticizer`; `plan-normal`: `Reviewer` then `Criticizer`; `plan-big`: three concurrent reviewers (`refine` with `reviewers: 3`) then `Criticizer`); once the default sequence is complete it is option 1.
 
 If the user selects `Reviewer` or `Criticizer`, run the `refine` tool with the plan path and any focus. Reviewer output consolidates into `PLAN_vN_reviewer_comments.md` with findings IDs, severity, affected plan IDs, evidence, impact, recommended fix, and disposition. Revise the next plan only for findings accepted on evidence.
 
@@ -120,19 +120,13 @@ Present each criticizer question with `ask_choice` (one call per question, in th
 
 ### Round Lifecycle
 
-A refinement round is complete when all reviewer outputs have returned or all criticizer questions have answers. In the same turn: consolidate, accept or reject each finding on evidence (the user may override any disposition), revise to `PLAN_v(N+1).md` when accepted items require it (copy, edit only the new version, update the revision ledger and verifier checklist), then immediately ask the next refinement-mode question. Never end a turn merely because a round completed.
+A refinement round is complete when all reviewer outputs have returned or all criticizer questions have answers. In the same turn: consolidate, accept or reject each finding on evidence (the user may override any disposition), revise to `PLAN_v(N+1).md` when accepted items require it (copy, edit only the new version, update the revision ledger and verifier checklist), then immediately ask the next merged accept/execute question. Never end a turn merely because a round completed.
 
 ## Execution Handoff
 
-After the plan is accepted or refinement converges, ask the explicit execution-handoff question via `ask_choice` with `autoComplete: false`:
+When the user picks `✓ Accept PLAN_vN and execute it now` in the merged question, mark the plan accepted and call the `execute_plan` tool (or the user runs `/plans-execute`). It re-confirms with the user, then the extension enters execution mode:
 
-1. `Execute this plan now` — enter the tracked execution loop (recommended once refinement converged).
-2. `Stop after planning` — keep the plan artifact only.
-3. `Other`.
-
-On approval, call the `execute_plan` tool (or the user runs `/plans-execute`). It re-confirms with the user, then the extension enters execution mode:
-
-- every agent turn is injected with the remaining verifier checklist and execution rules (ponytail discipline, minimum tests);
+- every agent turn is injected with the remaining verifier checklist and execution rules (layered simplest implementation, no stopgaps, dependency and library discipline, minimum tests);
 - the read-only guard lifts: full write access returns;
 - the run status moves to `executing`, then `done` when the last `[DONE:VC-xxx]` marker lands;
 - `/plans-stop` stops execution; `/plans` shows progress.
@@ -144,8 +138,8 @@ If the user declines, stay in planning (or stop, per their choice). Never start
 Stop and return to the workflow if any of these happen:
 
 - implementing before the approved execution handoff;
-- running `refine` without first asking the refinement-mode question, or before the role gates pass;
-- ending a turn after a completed refinement round without asking the next refinement-mode question;
+- running `refine` without first asking the merged accept/execute question, or before the role gates pass;
+- ending a turn after a completed refinement round without asking the next merged accept/execute question;
 - storing planning settings outside the target workspace's `.git/pi_plans/` state directory;
 - asking multiple planning questions in one message, or asking them outside `ask_choice`;
 - writing `PLAN_v1.md` before final scope confirmation;

package/references/plan-artifact-template.md

@@ -70,7 +70,7 @@ Summarize the user's request in one paragraph.
 
 ## Execution Handoff Notes
 
-State anything the executor should know, including order of work, files to avoid, and verification commands. The execution handoff still requires explicit user approval (ask_choice with `autoComplete: false`, then the `execute_plan` tool) and must never be auto-completed. Once approved, the extension-managed execution loop injects the remaining checklist every turn and completes when every `[DONE:VC-xxx]` marker has landed — keep this section concise enough to serve as the executor's brief.
+State anything the executor should know, including order of work, files to avoid, and verification commands. The merged accept/execute question still requires explicit user approval (ask_choice with `autoComplete: false`, then the `execute_plan` tool) and must never be auto-completed. Once approved, the extension-managed execution loop injects the remaining checklist every turn and completes when every `[DONE:VC-xxx]` marker has landed — keep this section concise enough to serve as the executor's brief.
 
 ## Revision Ledger
 

package/references/state-and-config.md

@@ -126,7 +126,7 @@ When `mode` is `delegated-subagent`, the `refine` tool spawns a read-only `pi` s
 - receives the full plan text and a review/criticism brief;
 - returns its findings as the tool result (recorded in `subagents.jsonl` with name and model).
 
-The main agent consolidates the results, records dispositions, revises the plan, and asks the next refinement-mode question — all in the same turn.
+The main agent consolidates the results, records dispositions, revises the plan, and asks the next merged accept/execute question — all in the same turn.
 
 ## Run State
 

package/skills/debug-and-plan/SKILL.md

@@ -20,7 +20,7 @@ Read `../../references/pi-planning-workflow.md` and `../../references/state-and-
    2. `Stop after RCA` — keep the diagnosis only.
    3. `Other` / 4. `Auto-complete` are added by the tool.
 4. On opt-out, stop after the summary; do not write `PROBLEM_ANALYSIS.md`.
-5. On opt-in (or `Auto-complete` choosing the recommendation), select the smallest fitting planning skill and follow that skill exactly: first-turn planning question, final scope confirmation, `PLAN_v1.md`, refinement, and the execution handoff (ask_choice with `autoComplete: false`, then the `execute_plan` tool).
+5. On opt-in (or `Auto-complete` choosing the recommendation), select the smallest fitting planning skill and follow that skill exactly: first-turn planning question, final scope confirmation, `PLAN_v1.md`, refinement, and the merged accept/execute question (ask_choice with `autoComplete: false`) before calling the `execute_plan` tool.
 
 ## Level Selection
 

package/skills/plan-big/SKILL.md

@@ -17,7 +17,7 @@ Read `../../references/pi-planning-workflow.md` and `../../references/state-and-
 - Ask at least 10 planning questions, one at a time; no maximum — stop only when the decision tree is genuinely resolved. Each via `ask_choice` (recommended option first; the tool adds `Other` second-last and `Auto-complete` last).
 - Use web research during both brainstorming and refinement when outside facts, patterns, or ecosystem constraints matter, and cite sources in the plan.
 - Ask the final scope confirmation, then write `PLAN_v1.md` per `../../references/plan-artifact-template.md`.
-- After each plan version, ask the refinement-mode question via `ask_choice` — never run `refine` unless the user or `Auto-complete` selected it at that question. Default sequence: one `Reviewer` round as three concurrent independent reviewers (`refine` with `reviewers: 3`, consolidated by the main agent per the shared workflow), then one `Criticizer` round; afterwards the recommended option is `Accept plan for tracked execution`. Beyond the default sequence, refine until convergence on high-priority findings, unresolved questions, or evidence gaps; surface at most five per round. Then the execution handoff (ask_choice with `autoComplete: false`, then the `execute_plan` tool).
+- After each plan version, ask the merged accept/execute question via `ask_choice` with `autoComplete: false` — never run `refine` unless the user picked another round at that question. Default sequence: one `Reviewer` round as three concurrent independent reviewers (`refine` with `reviewers: 3`, consolidated by the main agent per the shared workflow), then one `Criticizer` round; afterwards the recommended option is `✓ Accept & execute now` in the merged accept/execute question. Beyond the default sequence, refine until convergence on high-priority findings, unresolved questions, or evidence gaps; surface at most five per round. Then the merged accept/execute question (ask_choice with `autoComplete: false`: ✓ Accept & execute now / Accept, don't execute yet / another round) and the `execute_plan` tool.
 
 ## Fit
 

package/skills/plan-normal/SKILL.md

@@ -17,7 +17,7 @@ Read `../../references/pi-planning-workflow.md` and `../../references/state-and-
 - Ask 5 to 10 planning questions, one at a time, each via `ask_choice` (recommended option first; the tool adds `Other` second-last and `Auto-complete` last).
 - Use web research whenever outside library behavior, ecosystem precedent, UX convention, protocol semantics, or compatibility affects the recommendation (websearch skill when installed; otherwise `curl`/`gh` via bash), and cite sources in the plan.
 - Ask the final scope confirmation, then write `PLAN_v1.md` per `../../references/plan-artifact-template.md`.
-- After each plan version, ask the refinement-mode question via `ask_choice` — never run `refine` unless the user or `Auto-complete` selected it at that question. Default sequence: one `Reviewer` round, then one `Criticizer` round; afterwards the recommended option is `Accept plan for tracked execution`. Up to five rounds total, continuing only for high-priority findings or unresolved criticizer questions; surface at most five per round. Then the execution handoff (ask_choice with `autoComplete: false`, then the `execute_plan` tool).
+- After each plan version, ask the merged accept/execute question via `ask_choice` with `autoComplete: false` — never run `refine` unless the user picked another round at that question. Default sequence: one `Reviewer` round, then one `Criticizer` round; afterwards the recommended option is `✓ Accept & execute now` in the merged accept/execute question. Up to five rounds total, continuing only for high-priority findings or unresolved criticizer questions; surface at most five per round. Then the merged accept/execute question (ask_choice with `autoComplete: false`: ✓ Accept & execute now / Accept, don't execute yet / another round) and the `execute_plan` tool.
 
 ## Fit
 

package/skills/plan-small/SKILL.md

@@ -16,7 +16,7 @@ Read `../../references/pi-planning-workflow.md` and `../../references/state-and-
 - Inspect the target Git repo read-only before the first product question.
 - Ask 1 to 3 planning questions, one at a time, each via `ask_choice` (recommended option first; the tool adds `Other` second-last and `Auto-complete` last).
 - Ask the final scope confirmation, then write `PLAN_v1.md` under the artifact root (normally the configured workspace root, default `./docs/pi-plans/YYYY-MM-DD-topic/`) per `../../references/plan-artifact-template.md`.
-- After each plan version, ask the refinement-mode question via `ask_choice` — never run `refine` unless the user or `Auto-complete` selected it at that question. Default: exactly one round, recommended mode `Criticizer`; afterwards the recommended option is `Accept plan for tracked execution`, then the execution handoff (ask_choice with `autoComplete: false`, then the `execute_plan` tool).
+- After each plan version, ask the merged accept/execute question via `ask_choice` with `autoComplete: false` — never run `refine` unless the user picked another round at that question. Default: exactly one round, recommended mode `Criticizer`; afterwards the recommended option is `✓ Accept & execute now` in the merged accept/execute question (ask_choice with `autoComplete: false`: ✓ Accept & execute now / Accept, don't execute yet / another round), then the `execute_plan` tool.
 
 ## Fit
 

package/skills/plan-with-refs/SKILL.md

@@ -21,7 +21,7 @@ Read `../../references/pi-planning-workflow.md` and `../../references/state-and-
 6. For every reference, produce a structured analysis artifact (manual structured read recorded in `REF_ANALYSIS.md`) before asking adoption questions.
 7. For every reference after analysis, ask at least 3 ref-specific adoption questions via `ask_choice` before using its ideas in `PLAN_v1.md`; each based on downloaded content, recommended option first, `Other` second-last, `Auto-complete` last (the tool appends both).
 8. Block rather than pad if fewer than 3 credible references exist, unless the user explicitly narrows the topic or waives the minimum. `Auto-complete` cannot grant this waiver.
-9. Continue with big-plan depth: at least 10 planning questions, required web research during brainstorming and refinement (`refine` `reviewers: 3` reviewer round, then a criticizer round), no refinement limit, at most five high-priority comments or questions per refinement round. Then the execution handoff (ask_choice with `autoComplete: false`, then the `execute_plan` tool).
+9. Continue with big-plan depth: at least 10 planning questions, required web research during brainstorming and refinement (`refine` `reviewers: 3` reviewer round, then a criticizer round), no refinement limit, at most five high-priority comments or questions per refinement round. Then the merged accept/execute question (ask_choice with `autoComplete: false`: ✓ Accept & execute now / Accept, don't execute yet / another round) and the `execute_plan` tool.
 
 ## REF_ANALYSIS.md
 

package/src/exec.ts

@@ -22,12 +22,13 @@ import {
 	type ExecutionPanelState,
 	type ItemDiffSummary,
 } from "./execution-panel.ts";
-import { readActive, setRunStatus, utcNow } from "./state.ts";
-import { scanDoneMarkers, type CheckItem } from "./plan.ts";
+import { getRun, readActive, setRunStatus, utcNow } from "./state.ts";
+import { latestPlanVersion, scanDoneMarkers, type CheckItem } from "./plan.ts";
 
 export interface ExecState extends ExecutionPanelExecutionLike {
 	startedAt: string;
 	panel?: ExecutionPanelState;
+	usage: { inToks: number; outToks: number };
 }
 
 let execution: ExecState | null = null;
@@ -54,18 +55,58 @@ export function executionProgress(): { done: number; total: number } | null {
 	};
 }
 
+function formatElapsed(startedAt: string): string {
+	const total = Math.max(0, Math.floor((Date.now() - Date.parse(startedAt)) / 1000));
+	const h = String(Math.floor(total / 3600)).padStart(2, "0");
+	const m = String(Math.floor((total % 3600) / 60)).padStart(2, "0");
+	const sec = String(total % 60).padStart(2, "0");
+	return `${h}:${m}:${sec}`;
+}
+
+function formatToks(tokens: number): string {
+	const n = Math.max(0, Math.round(tokens));
+	return n < 1000 ? String(n) : `${(n / 1000).toFixed(1)}k`;
+}
+
 export function updateStatusWidget(ctx: ExtensionContext): void {
 	const progress = executionProgress();
-	if (progress) {
-		// The below-editor panel owns the in-execution progress display; keep the
-		// status bar free of a duplicate count (and clear stale ones from before).
-		ctx.ui.setStatus("pi-plans", undefined);
+	if (progress && execution) {
+		// Progress lives in the bottom status bar — the same layer as the ⛔/⌛
+		// paused indicator — so both execution states read from one place.
+		const tail = execution.panel?.expanded ? "/plans-list hide" : "/plans-list details";
+		const line = `⌛ plans ${progress.done}/${progress.total}: spent ${formatElapsed(execution.startedAt)} · ${formatToks(execution.usage.inToks)} in-toks · ${formatToks(execution.usage.outToks)} out-toks · ${tail}`;
+		ctx.ui.setStatus("pi-plans", ctx.ui.theme.fg("accent", line));
 		return;
 	}
 	const active = readActive(ctx.cwd);
 	if (active) {
-		ctx.ui.setStatus("pi-plans", ctx.ui.theme.fg("warning", `⏸ plans: ${active.run_id}`));
-		return;
+		// Idle indicator depends on the run's lifecycle, not just its existence:
+		// done reads as finished, abandoned as closed, stopped/accepted as paused.
+		const status = getRun(ctx.cwd, active.run_id)?.status;
+		if (status === "done") {
+			ctx.ui.setStatus("pi-plans", ctx.ui.theme.fg("success", `🎯 plans: ${active.run_id} (done)`));
+			return;
+		}
+		if (status === "abandoned") {
+			ctx.ui.setStatus("pi-plans", ctx.ui.theme.fg("error", `🚫 plans: ${active.run_id}`));
+			return;
+		}
+		if (status === "stopped") {
+			ctx.ui.setStatus("pi-plans", ctx.ui.theme.fg("warning", `⛔ plans: ${active.run_id}`));
+			return;
+		}
+		if (status === "accepted") {
+			ctx.ui.setStatus("pi-plans", ctx.ui.theme.fg("warning", `⌛ plans: ${active.run_id}`));
+			return;
+		}
+		if (status === "planning") {
+			// Planning phase: 💬 while still in Q&A, 📝 once a PLAN draft exists
+			// — kept until execution starts (then ⌛ takes over).
+			const emoji = latestPlanVersion(active.artifact_dir) ? "📝" : "💬";
+			ctx.ui.setStatus("pi-plans", ctx.ui.theme.fg("muted", `${emoji} plans: ${active.run_id}`));
+			return;
+		}
+		// unknown status: no indicator.
 	}
 	ctx.ui.setStatus("pi-plans", undefined);
 }
@@ -76,6 +117,7 @@ function persist(pi: ExtensionAPI): void {
 		planPath: execution.planPath,
 		items: execution.items,
 		startedAt: execution.startedAt,
+		usage: execution.usage,
 		panel: snapshotPanelState(execution),
 	});
 }
@@ -94,7 +136,7 @@ export function startExecution(
 	planPath: string,
 	items: CheckItem[],
 ): void {
-	execution = { planPath, items, startedAt: utcNow(), panel: createExecutionPanelState() };
+	execution = { planPath, items, startedAt: utcNow(), panel: createExecutionPanelState(), usage: { inToks: 0, outToks: 0 } };
 	attachPanelBaseline(execution, ctx.cwd);
 	consumePendingPanelSync(); // fresh run: drop any stale deferral from a previous one
 	persist(pi);
@@ -109,7 +151,7 @@ export function startExecution(
 	pi.sendMessage(
 		{
 			customType: "pi-plans-exec-start",
-			content: `**pi-plans: executing** \`${planPath}\` — ${items.length} verifier item(s). Progress appears below the editor; mark verified items with \`[DONE:VC-xxx]\`.`,
+			content: `**pi-plans: executing** \`${planPath}\` — ${items.length} verifier item(s). Progress appears in the bottom status bar; mark verified items with \`[DONE:VC-xxx]\`.`,
 			display: true,
 		},
 		{ triggerTurn: false },
@@ -148,8 +190,17 @@ export function recordTouchedPaths(_workdir: string, paths: string[]): void {
 	panel.touchedPaths = [...merged];
 }
 
-export function recordExecutionCompletion(pi: ExtensionAPI, ctx: ExtensionContext, completedIds: string[]): ItemDiffSummary | null {
+export function recordExecutionCompletion(
+	pi: ExtensionAPI,
+	ctx: ExtensionContext,
+	completedIds: string[],
+	usage?: { input: number; output: number },
+): ItemDiffSummary | null {
 	if (!execution) return null;
+	if (usage) {
+		execution.usage.inToks += usage.input;
+		execution.usage.outToks += usage.output;
+	}
 	const summary = completeCompletedItems(execution, ctx.cwd, completedIds);
 	persist(pi);
 	syncExecutionPanel(ctx);
@@ -237,8 +288,10 @@ Remaining verifier items:
 ${list}
 
 Execution rules:
-- Implement implementation items in dependency order.
-- Ponytail discipline: for each item, take the laziest rung that holds (does it need to exist; already in this codebase; stdlib; native platform feature; already-installed dependency; one line). Mark deliberate simplifications with \`# ponytail: <ceiling>, <upgrade path>\`.
+- Implement implementation items in dependency order; grow the change in layers — smallest end-to-end slice first, then stack each new capability on top of what already works.
+- Simplest implementation that fully meets the item: no speculative abstractions, configuration, or indirection; keep components modular with clearly separated concerns.
+- Architectural decisions are for the long term: no stopgaps. Do not add backward-compatibility layers, fallbacks, or migrations — remove the obsolete paths this change obsoletes.
+- Prefer established, well-maintained libraries when they reduce complexity or improve reliability; before writing your own implementation or adding a package, check the project's existing dependencies (docs and types) — never reimplement common functionality without a clear reason.
 - MINIMUM tests: trivial one-liners get no test; non-trivial logic gets exactly one minimal check; reuse the repo's test runner when one exists; when unsure, skip and emit \`[test skipped: <name>, add when <trigger>]\`.
 - After verifying an item's pass condition with its stated evidence, include \`[DONE:VC-xxx]\` in your reply.
 - When every item is done, report a completion summary.`;
@@ -290,6 +343,7 @@ export function restoreFromSession(pi: ExtensionAPI, ctx: ExtensionContext, entr
 	execution = {
 		...snapshot,
 		items: snapshot.items.map((item) => ({ ...item })),
+		usage: snapshot.usage ?? { inToks: 0, outToks: 0 },
 		panel: executionPanelFromEntryData(snapshot.panel) ?? createExecutionPanelState(),
 	};
 	for (let i = snapshotIndex + 1; i < entries.length; i++) {

package/src/execution-panel.ts

@@ -396,19 +396,16 @@ function renderItemLines(item: CheckItem, summary: ItemDiffSummary | undefined,
 }
 
 function renderPanelLines(execution: ExecutionPanelExecutionLike, theme: ThemeLike, width: number): string[] {
+	// Expanded detail view only: the count/hint live in the bottom status bar,
+	// so the panel below the editor never repeats them.
 	const panel = ensurePanelState(execution);
-	const done = execution.items.filter((item) => item.done).length;
-	const hint = panel.expanded ? "alt+o /plans-list hide" : "alt+o /plans-list details";
-	const header = truncateAnsi(theme.fg("accent", `📋 plans ${done}/${execution.items.length} · ${hint}`), width);
-	if (!panel.expanded) {
-		return [header];
-	}
-	const lines = [header];
+	if (!panel.expanded) return [""];
+	const lines: string[] = [];
 	for (const item of execution.items) {
 		const summary = panel.itemSummaries[item.id]?.summary;
 		lines.push(...renderItemLines(item, summary, theme, width));
 	}
-	return lines;
+	return lines.length ? lines : [""];
 }
 
 interface WidgetThemeSource {
@@ -457,6 +454,11 @@ export function refreshExecutionPanel(ctx: ExtensionContext, execution: Executio
 		clearExecutionPanel(ctx);
 		return;
 	}
+	if (!execution.panel?.expanded) {
+		// Collapsed: the bottom status bar carries the count; no panel widget.
+		clearExecutionPanel(ctx);
+		return;
+	}
 	panelRef.current = execution;
 	invalidateRenderCache(); // next render always reflects the latest state
 	if (registeredUi === ctx.ui) {

package/tests/exec.test.ts

@@ -14,15 +14,19 @@ import {
 	isExecutionComplete,
 	restoreFromSession,
 	startExecution,
+	recordExecutionCompletion,
 	stopExecution,
 	toggleExecutionPanelView,
+	updateStatusWidget,
 } from "../src/exec.ts";
 import type { CheckItem } from "../src/plan.ts";
+import { initState, setRunStatus, startRun } from "../src/state.ts";
 
 interface Recorded {
 	entries: { type: string; customType?: string; data?: unknown }[];
 	messages: { customType: string; content: string }[];
 	status: string | undefined;
+	colors: string[];
 	widget?: { key: string; options?: unknown; factory: any };
 	widgetCalls: number;
 }
@@ -34,7 +38,7 @@ interface Harness {
 }
 
 function makeHarness(workdir: string): Harness {
-	const recorded: Recorded = { entries: [], messages: [], status: undefined, widgetCalls: 0 };
+	const recorded: Recorded = { entries: [], messages: [], status: undefined, colors: [], widgetCalls: 0 };
 	const pi = {
 		appendEntry: (customType: string, data: unknown) => {
 			recorded.entries.push({ type: "custom", customType, data });
@@ -56,7 +60,10 @@ function makeHarness(workdir: string): Harness {
 			recorded.widget = { key, options, factory };
 		},
 		theme: {
-			fg: (_color: string, text: string) => text,
+			fg: (color: string, text: string) => {
+				recorded.colors.push(color);
+				return text;
+			},
 			strikethrough: (text: string) => `~~${text}~~`,
 		},
 	};
@@ -95,20 +102,19 @@ describe("execution loop", () => {
 		const workdir = freshWorkdir();
 		const { pi, ctx, recorded } = makeHarness(workdir);
 		startExecution(pi, ctx, path.join(workdir, "PLAN_v1.md"), items("VC-001", "VC-002"));
-		assert.ok(recorded.widget);
-		assert.equal(recorded.widget?.key, "pi-plans-execution");
-		assert.deepEqual(recorded.widget?.options, { placement: "belowEditor" });
-		const widget = recorded.widget?.factory(
-			{} as any,
-			{ fg: (_color: string, text: string) => text, strikethrough: (text: string) => `~~${text}~~` },
-		);
-		assert.ok(widget);
-		const rendered = widget.render(80);
-		assert.match(rendered[0] ?? "", /alt\+o/);
-		assert.match(rendered[0] ?? "", /📋 plans 0\/2/);
+
+		// Collapsed by default: progress lives in the bottom status bar (same
+		// layer as the ⛔/⌛ indicators); no panel widget is registered yet.
+		assert.equal(recorded.widget, undefined);
+		assert.match(recorded.status ?? "", /⌛ plans 0\/2: spent \d{2}:\d{2}:\d{2}/);
+		assert.match(recorded.status ?? "", /in-toks/);
+		assert.match(recorded.status ?? "", /out-toks/);
+		assert.match(recorded.status ?? "", /\/plans-list details/);
 
 		toggleExecutionPanelView(pi, ctx);
 		assert.ok(recorded.widget);
+		assert.equal(recorded.widget?.key, "pi-plans-execution");
+		assert.deepEqual(recorded.widget?.options, { placement: "belowEditor" });
 		const expandedWidget = recorded.widget?.factory(
 			{} as any,
 			{ fg: (_color: string, text: string) => text, strikethrough: (text: string) => `~~${text}~~` },
@@ -116,10 +122,23 @@ describe("execution loop", () => {
 		assert.ok(expandedWidget);
 		const expandedLines = expandedWidget.render(80);
 		assert.match(expandedLines.join("\n"), /☐/);
+		// Detail view never repeats the count or the keyboard hint.
+		assert.doesNotMatch(expandedLines.join("\n"), /📋 plans/);
+		assert.doesNotMatch(expandedLines.join("\n"), /alt\+o/);
 
 		assert.ok(getExecution());
-		assert.match(executionContextMessage()!, /PI-PLANS EXECUTION/);
-		assert.match(executionContextMessage()!, /VC-001/);
+		const rules = executionContextMessage()!;
+		assert.match(rules, /PI-PLANS EXECUTION/);
+		assert.match(rules, /VC-001/);
+		// Seven-principle rule set: representative anchors (PLAN_v2 D-003/D-004).
+		assert.match(rules, /for the long term/);
+		assert.match(rules, /Simplest implementation/);
+		assert.match(rules, /grow the change in layers/);
+		assert.match(rules, /existing dependencies \(docs and types\)/);
+		assert.match(rules, /well-maintained libraries/);
+		assert.match(rules, /clearly separated concerns/);
+		assert.match(rules, /no stopgaps/);
+		assert.doesNotMatch(rules, /ponytail/i);
 
 		assert.deepEqual(applyDoneMarkers("progress… [DONE:VC-001] done"), ["VC-001"]);
 		assert.equal(isExecutionComplete(), false);
@@ -207,18 +226,77 @@ describe("execution loop", () => {
 		const { pi, ctx, recorded } = makeHarness(workdir);
 		startExecution(pi, ctx, path.join(workdir, "PLAN_v2.md"), items("VC-001", "VC-002"));
 
-		// The below-editor panel owns progress; the status item must be cleared,
-		// never carrying a duplicate “📋 plans x/y” count (regression: double display).
-		assert.equal(recorded.status, undefined);
+		// Bottom status bar carries the count — the same layer as ⛔/⌛ — so both
+		// execution states read from one consistent place.
+		assert.match(recorded.status ?? "", /⌛ plans 0\/2: spent \d{2}:\d{2}:\d{2}/);
+		assert.match(recorded.status ?? "", /in-toks/);
+		assert.match(recorded.status ?? "", /\/plans-list details/);
 
 		const start = recorded.messages.find((message) => message.customType === "pi-plans-exec-start");
 		assert.ok(start);
-		assert.match(start.content, /Progress appears below the editor/);
+		assert.match(start.content, /Progress appears in the bottom status bar/);
 		assert.doesNotMatch(start.content, /footer/);
 
 		applyDoneMarkers("[DONE:VC-001]");
 		completeExecution(pi, ctx);
 		assert.equal(getExecution(), null);
+
+	});
+
+	it("renders the idle indicator by run status", () => {
+		const workdir = freshWorkdir();
+		const { ctx, recorded } = makeHarness(workdir);
+		initState(workdir);
+		const { run } = startRun(workdir, { topic: "demo", skill: "plan-small", requestText: "x" });
+
+		// planning before any PLAN draft exists: 💬 (Q&A phase).
+		updateStatusWidget(ctx);
+		assert.match(recorded.status ?? "", /💬 plans: /);
+		assert.equal(recorded.colors.at(-1), "muted");
+
+		// Once a draft lands: 📝, kept until execution starts.
+		fs.writeFileSync(path.join(run.artifact_dir, "PLAN_v1.md"), "# plan");
+		updateStatusWidget(ctx);
+		assert.match(recorded.status ?? "", /📝 plans: /);
+		assert.equal(recorded.colors.at(-1), "muted");
+
+		setRunStatus(workdir, run.run_id, "accepted");
+		updateStatusWidget(ctx);
+		assert.match(recorded.status ?? "", /⌛ plans: /);
+		assert.equal(recorded.colors.at(-1), "warning");
+
+		setRunStatus(workdir, run.run_id, "stopped");
+		updateStatusWidget(ctx);
+		assert.match(recorded.status ?? "", /⛔ plans: /);
+		assert.equal(recorded.colors.at(-1), "warning");
+
+		setRunStatus(workdir, run.run_id, "done");
+		updateStatusWidget(ctx);
+		assert.match(recorded.status ?? "", /🎯 plans: .*\(done\)/);
+		assert.equal(recorded.colors.at(-1), "success");
+
+		setRunStatus(workdir, run.run_id, "abandoned");
+		updateStatusWidget(ctx);
+		assert.match(recorded.status ?? "", /🚫 plans: /);
+		assert.equal(recorded.colors.at(-1), "error");
+	});
+
+	it("accumulates token usage only for turns that finish items", () => {
+		const workdir = freshWorkdir();
+		const { pi, ctx, recorded } = makeHarness(workdir);
+		startExecution(pi, ctx, path.join(workdir, "PLAN_v5.md"), items("VC-001", "VC-002"));
+
+		recordExecutionCompletion(pi, ctx, ["VC-001"], { input: 100, output: 40 });
+		assert.equal(getExecution()?.usage.inToks, 100);
+		assert.equal(getExecution()?.usage.outToks, 40);
+
+		// A completion without usage data must keep prior totals intact.
+		recordExecutionCompletion(pi, ctx, ["VC-002"]);
+		assert.equal(getExecution()?.usage.inToks, 100);
+		assert.equal(getExecution()?.usage.outToks, 40);
+
+		stopExecution(pi, ctx, "test-done");
+		assert.equal(getExecution(), null);
 	});
 
 	it("defers persistence and widget churn when toggling mid-turn", () => {
@@ -237,12 +315,12 @@ describe("execution loop", () => {
 		assert.equal(consumePendingPanelSync(), true, "expected a pending panel sync marker");
 		assert.equal(consumePendingPanelSync(), false, "marker should be consumed exactly once");
 
-		// Back to idle: the next toggle persists and syncs, but still reuses the
-		// already-registered factory (cache-drop instead of teardown).
+		// Back to idle: the next toggle persists and syncs. It flips the panel to
+		// expanded, which registers the detail widget exactly once (no teardown).
 		ctx.isIdle = () => true;
 		assert.equal(toggleExecutionPanelView(pi, ctx), false);
 		assert.ok(recorded.entries.length > entriesBefore, "idle toggle did not persist");
-		assert.equal(recorded.widgetCalls, factoriesBefore, "idle toggle replaced the widget factory");
+		assert.equal(recorded.widgetCalls, factoriesBefore + 1, "idle toggle churned the widget registration");
 
 		stopExecution(pi, ctx, "test-done");
 	});

package/tests/execution-panel.test.ts

@@ -117,22 +117,29 @@ describe("execution panel helpers", () => {
 		const theme = { fg: (_color: string, text: string) => `\u001b[38;5;2m${text}\u001b[39m`, strikethrough: (text: string) => text };
 		const ctx = { ui: { setWidget: (_key: string, factory: any) => void factories.push(factory) } } as any;
 
+		// Collapsed execution renders no widget at all — the bottom status bar
+		// owns the count (each clear call pushes `undefined`).
 		refreshExecutionPanel(ctx, execution);
-		refreshExecutionPanel(ctx, execution); // second pass must only invalidate
-		assert.equal(factories.length, 1, "factory re-registered on refresh");
-
-		const widget = (factories[0] as any)({}, theme);
-		assert.equal(widget.render(80).length, 1, "collapsed render should be a single line");
+		refreshExecutionPanel(ctx, execution); // stays cleared while collapsed
+		assert.equal(factories.length, 2);
+		assert.equal(factories[0], undefined);
+		assert.equal(factories[1], undefined);
 
+		// Expanding registers the detail widget exactly once.
 		toggleExpanded(execution);
 		refreshExecutionPanel(ctx, execution);
-		assert.equal(factories.length, 1);
-		assert.ok(widget.render(80).length > 1, "invalidate did not pick up expanded state");
+		assert.equal(factories.length, 3);
+		const widget = (factories[2] as any)({}, theme);
+		assert.ok(widget.render(80).length >= 1, "expanded render should list items");
+
+		refreshExecutionPanel(ctx, execution); // same host: reuse, no re-register
+		assert.equal(factories.length, 3);
+		assert.ok(widget.render(80).length >= 1, "invalidate did not pick up latest state");
 
 		// Clearing releases the slot so a future run registers afresh.
 		refreshExecutionPanel(ctx, null);
 		refreshExecutionPanel(ctx, execution);
-		assert.equal(factories.length, 3); // #2 was the explicit clear (undefined)
+		assert.equal(factories.length, 5); // #4 was the explicit clear (undefined)
 	});
 });