flanders 0.9.0 → 0.11.0

package/README.md

@@ -68,7 +68,7 @@ Flanders installs at one of two scopes, chosen with a pair of mutually exclusive
 
 ### What it writes
 
-For each AI tool you select for skills, `install` writes one skill artifact per Flanders skill (`/flanders-spec`, `/flanders-plan`, and `/flanders-work`) into that tool's skill folder for the chosen scope:
+For each AI tool you select for skills, `install` writes one skill artifact per Flanders skill (`/flanders-spec`, `/flanders-plan`, `/flanders-work`, and `/flanders-hard-stop-review`) into that tool's skill folder for the chosen scope:
 
 | Tool | Project scope | Global scope |
 | --- | --- | --- |
@@ -137,7 +137,7 @@ Updated the lib and itching for the freshest skills, neighbor? Just run:
 flanders update
 ```
 
-`update` takes no flags. It scans the four skill destinations `install` writes to — Claude Code's `.claude/skills/` and `~/.claude/skills/`, and Codex CLI's `.codex/prompts/` and `~/.codex/prompts/` — and wherever it finds at least one Flanders skill artifact already in place, it rewrites the full `/flanders-spec`, `/flanders-plan`, and `/flanders-work` trio there with the current version. A destination where no Flanders skill artifact is present is left untouched, so `update` refreshes the installations you already have and never creates one where you had none.
+`update` takes no flags. It scans the four skill destinations `install` writes to — Claude Code's `.claude/skills/` and `~/.claude/skills/`, and Codex CLI's `.codex/prompts/` and `~/.codex/prompts/` — and wherever it finds at least one Flanders skill artifact already in place, it rewrites the full `/flanders-spec`, `/flanders-plan`, `/flanders-work`, and `/flanders-hard-stop-review` set there with the current version. A destination where no Flanders skill artifact is present is left untouched, so `update` refreshes the installations you already have and never creates one where you had none.
 
 ## Configuration
 
@@ -152,26 +152,32 @@ When a command reads the configuration, a project-scope `.flanders/` always take
 
 ## Usage
 
-With Flanders installed, here's how to put it to work — running plans from the CLI and shaping them with the three skills.
+With Flanders installed, here's how to put it to work — running plans from the CLI and shaping them with the four skills.
 
-### The three skills
+### The four skills
 
 - **`/flanders-spec`** — turns a free-form request into your contracts, rules, and behavior rules, written into the `.spec/contracts`, `.spec/rules`, and `.spec/flanders` folders.
 - **`/flanders-plan`** — derives a single, ordered, specification-aware work plan from your request.
 - **`/flanders-work`** — implements a small, self-contained request directly and gates it through build, test, and a single adversarial review, all in one invocation — no plan file and no commit.
+- **`/flanders-hard-stop-review`** — diagnoses an `implement` hard stop from its preserved temporary folder and recommends how to relaunch `implement` so the stuck task finishes instead of stopping again.
 
-Each skill takes the same optional `<data>` argument:
+The first three skills take the same optional `<data>` argument, and `/flanders-hard-stop-review` takes one too:
 
 ```
 /flanders-spec [<data>]
 /flanders-plan [<data>]
 /flanders-work [<data>]
+/flanders-hard-stop-review [<data>]
 ```
 
+For `/flanders-spec`, `/flanders-plan`, and `/flanders-work`, `<data>` is your request:
+
 - Omit it, and the skill takes your request straight from the conversation.
 - Give it a path to an existing file, and the skill reads that file as the input.
 - Give it any other text, and the skill uses that text verbatim.
 
+For `/flanders-hard-stop-review`, `<data>` is the path of the preserved hard-stop temporary folder to diagnose — omit it, and the skill takes that path from the conversation.
+
 ### Implementing a plan
 
 ```sh
@@ -254,4 +260,4 @@ It won't leave you guessing, though. Flanders prints an error that names the tas
 
 Inside you'll find the sessions from every attempt on the task: the worker's output, the build and test output, each reviewer's output, and the `error.log` that briefed the final iteration. It's the whole story of what was tried and where each go-round fell short.
 
-And here's the neighborly part — you don't have to untangle it all yourself. Hand that folder to your AI coding tool and just ask it to review the folder and tell you why the run failed. It'll read back through the sessions and walk you through what went wrong, so you can mend the spec, the plan, or the task and send Flanders off to try again.
+And here's the neighborly part — you don't have to untangle it all yourself. Invoke **`/flanders-hard-stop-review`** in your AI coding tool and hand it that folder's path, and it reads back through the sessions, tells you why the run failed, and recommends how to relaunch `implement` so the stuck task finishes this time — mending the spec or the plan, or simply running it again.

package/lib/ai/ClaudeAdapter.js

@@ -82,11 +82,11 @@ class ClaudeAdapterIterator {
         this._capturedSessionId = null;
         this._queue = [];
         this._done = false;
-        this._error = null;
         this._waitResolve = null;
         this._abortListener = null;
         this._pendingTerminal = null;
         this._exitPromise = null;
+        this._retainedRateLimitInfo = null;
         this._start();
     }
     _start() {
@@ -123,13 +123,24 @@ class ClaudeAdapterIterator {
         });
         proc.on("error", (e) => {
             if (!this._done) {
+                const err = e instanceof Error ? e : new Error(String(e));
                 this._done = true;
-                this._error = e instanceof Error ? e : new Error(String(e));
+                this._queue.push({
+                    type: "error",
+                    retryable: false,
+                    message: err.code === "ENOENT"
+                        ? "claude binary not found"
+                        : err.message
+                });
                 this._wake();
             }
             exitResolve === null || exitResolve === void 0 ? void 0 : exitResolve();
         });
-        proc.on("exit", () => {
+        proc.on("exit", (code, signal) => {
+            if (this._done) {
+                exitResolve === null || exitResolve === void 0 ? void 0 : exitResolve();
+                return;
+            }
             if (stderrBuf) {
                 this._queue.push({
                     type: "output",
@@ -143,6 +154,20 @@ class ClaudeAdapterIterator {
                 this._queue.push(this._pendingTerminal);
                 this._pendingTerminal = null;
             }
+            else if (signal) {
+                this._queue.push({
+                    type: "error",
+                    retryable: true,
+                    message: `claude terminated by signal ${signal}`
+                });
+            }
+            else {
+                this._queue.push({
+                    type: "error",
+                    retryable: true,
+                    message: `claude exited unexpectedly (code ${code} signal ${signal})`
+                });
+            }
             if (!this._done) {
                 this._done = true;
             }
@@ -150,10 +175,10 @@ class ClaudeAdapterIterator {
             exitResolve === null || exitResolve === void 0 ? void 0 : exitResolve();
         });
         this._abortListener = () => {
+            this._done = true;
             if (this._proc) {
                 this._proc.kill("SIGINT");
             }
-            this._done = true;
             this._wake();
         };
         if (this._args.abortSignal.aborted) {
@@ -182,6 +207,8 @@ class ClaudeAdapterIterator {
     }
     _handleLine(line) {
         var _a, _b, _c, _d, _e, _f;
+        if (this._done)
+            return;
         let parsed = null;
         try {
             parsed = JSON.parse(line);
@@ -201,6 +228,9 @@ class ClaudeAdapterIterator {
                 this._queue.push({ type: "session", id: parsed.session_id });
             }
         }
+        if (parsed.type === "rate_limit_event" && parsed.rate_limit_info) {
+            this._retainedRateLimitInfo = parsed.rate_limit_info;
+        }
         if (parsed.type === "assistant" && ((_a = parsed.message) === null || _a === void 0 ? void 0 : _a.content)) {
             for (const block of parsed.message.content) {
                 if (block.type === "tool_use" && typeof block.name === "string") {
@@ -263,11 +293,11 @@ class ClaudeAdapterIterator {
         this._wake();
     }
     _classifyError(parsed) {
-        var _a, _b;
+        var _a, _b, _c;
         const status = parsed.api_error_status;
         const subtype = parsed.subtype;
         const message = (_b = (_a = parsed.error) === null || _a === void 0 ? void 0 : _a.message) !== null && _b !== void 0 ? _b : "unknown error";
-        const info = parsed.rate_limit_info;
+        const info = (_c = this._retainedRateLimitInfo) !== null && _c !== void 0 ? _c : parsed.rate_limit_info;
         if (info || status === 429) {
             if (info) {
                 const target = info.isUsingOverage && typeof info.overageResetsAt === "number"
@@ -313,9 +343,6 @@ class ClaudeAdapterIterator {
             if (this._queue.length > 0) {
                 return { value: this._queue.shift(), done: false };
             }
-            if (this._error) {
-                throw this._error;
-            }
             if (this._done && this._queue.length === 0) {
                 this._cleanup();
                 if (this._exitPromise) {

package/lib/ai/CodexAdapter.js

@@ -40,13 +40,12 @@ class CodexAdapterIterator {
         this._exitPromise = null;
         this._sawTurnCompleted = false;
         this._receivedAnyEvent = false;
-        this._fallbackAttempted = false;
         this._usedResume = false;
-        this._start(false);
+        this._start();
     }
-    _start(useExecFallback) {
+    _start() {
         var _a, _b, _c;
-        const isResume = !useExecFallback && !!this._args.resumeSessionId;
+        const isResume = !!this._args.resumeSessionId;
         this._usedResume = isResume;
         const argv = this._buildArgv(isResume);
         const spawnOptions = { stdio: "pipe" };
@@ -91,23 +90,6 @@ class CodexAdapterIterator {
                 exitResolve === null || exitResolve === void 0 ? void 0 : exitResolve();
                 return;
             }
-            if (this._usedResume && !this._receivedAnyEvent && !this._fallbackAttempted) {
-                this._fallbackAttempted = true;
-                this._queue.push({
-                    type: "output",
-                    title: "Continuity lost",
-                    subtitle: "",
-                    details: "codex exec resume unavailable in installed CLI"
-                });
-                this._cleanup();
-                this._sawTurnCompleted = false;
-                this._receivedAnyEvent = false;
-                this._usedResume = false;
-                exitResolve === null || exitResolve === void 0 ? void 0 : exitResolve();
-                this._start(true);
-                this._wake();
-                return;
-            }
             if (this._sawTurnCompleted) {
                 this._queue.push({ type: "done" });
             }
@@ -118,6 +100,13 @@ class CodexAdapterIterator {
                     message: `codex terminated by signal ${signal}`
                 });
             }
+            else if (this._usedResume && !this._receivedAnyEvent) {
+                this._queue.push({
+                    type: "error",
+                    retryable: false,
+                    message: "codex exec resume unavailable in installed CLI"
+                });
+            }
             else {
                 this._queue.push({
                     type: "error",
@@ -130,10 +119,10 @@ class CodexAdapterIterator {
             exitResolve === null || exitResolve === void 0 ? void 0 : exitResolve();
         });
         this._abortListener = () => {
+            this._done = true;
             if (this._proc) {
                 this._proc.kill("SIGINT");
             }
-            this._done = true;
             this._wake();
         };
         if (this._args.abortSignal.aborted) {

package/lib/commands/Implement.d.ts

@@ -40,8 +40,9 @@ export declare class Implement {
     private _currentIteration;
     private _currentTask;
     private _taskStartedAt;
-    private _taskRateLimitMs;
+    private _taskExcludedMs;
     private _taskRateLimitStartedAt;
+    private _reviewPauseStartedAt;
     private _taskTokens;
     private _otherTasksSeconds;
     private _runPromise;
@@ -64,6 +65,8 @@ export declare class Implement {
     private _setReviewerState;
     private _setReviewerWaiting;
     private _writeReviewerEntry;
+    private _syncReviewPause;
+    private _endReviewPause;
     private _renderReviewingFooter;
     private _setReviewerLogicalStatus;
     private _evaluateReviewRoundCompletion;

package/lib/commands/Implement.js

@@ -85,8 +85,9 @@ class Implement {
         this._currentIteration = 0;
         this._currentTask = null;
         this._taskStartedAt = 0;
-        this._taskRateLimitMs = 0;
+        this._taskExcludedMs = 0;
         this._taskRateLimitStartedAt = null;
+        this._reviewPauseStartedAt = null;
         this._taskTokens = { it: 0, ot: 0 };
         this._otherTasksSeconds = 0;
         this._runPromise = this._run(rawArgs);
@@ -271,7 +272,7 @@ class Implement {
         });
     }
     _activeSeconds() {
-        return Math.max(0, Math.floor((this._contexts.time.now() - this._taskStartedAt - this._taskRateLimitMs) / 1000));
+        return Math.max(0, Math.floor((this._contexts.time.now() - this._taskStartedAt - this._taskExcludedMs) / 1000));
     }
     async _persistMetrics(plan, line) {
         try {
@@ -285,7 +286,7 @@ class Implement {
         if (!this._currentTask || this._taskRateLimitStartedAt !== null)
             return;
         const planTotals = plan.planTotals();
-        const anchorMs = this._taskStartedAt + this._taskRateLimitMs;
+        const anchorMs = this._taskStartedAt + this._taskExcludedMs;
         this._block.setMetrics({
             task: { tokens: this._taskTokens.it + this._taskTokens.ot, anchorMs, baseSeconds: 0 },
             plan: { tokens: planTotals.it + planTotals.ot, anchorMs, baseSeconds: this._otherTasksSeconds }
@@ -306,8 +307,9 @@ class Implement {
         this._currentWorkerSessionId = null;
         this._workerSessionTokens = { inputTokens: 0, outputTokens: 0 };
         this._taskStartedAt = this._contexts.time.now();
-        this._taskRateLimitMs = 0;
+        this._taskExcludedMs = 0;
         this._taskRateLimitStartedAt = null;
+        this._reviewPauseStartedAt = null;
         this._taskTokens = { it: 0, ot: 0 };
         this._otherTasksSeconds = plan.planTotals().t - task.metrics.t;
         this._updateMetrics(plan);
@@ -515,8 +517,23 @@ class Implement {
             next.endTime = endTime;
         }
         this._reviewerStates[reviewerIdx] = next;
+        this._syncReviewPause();
         this._renderReviewingFooter();
     }
+    _syncReviewPause() {
+        if (this._reviewerStates.some(r => r.state === "running")) {
+            this._endReviewPause();
+        }
+        else {
+            this._reviewPauseStartedAt = this._contexts.time.now();
+        }
+    }
+    _endReviewPause() {
+        if (this._reviewPauseStartedAt !== null) {
+            this._taskExcludedMs += this._contexts.time.now() - this._reviewPauseStartedAt;
+            this._reviewPauseStartedAt = null;
+        }
+    }
     _renderReviewingFooter() {
         if (!this._block || this._block.isFinalized() || !this._reviewerStates)
             return;
@@ -570,6 +587,7 @@ class Implement {
             }
         }));
         await Promise.all(launches);
+        this._endReviewPause();
         if (this._disposed) {
             return false;
         }
@@ -709,7 +727,7 @@ class Implement {
             },
             onLongWaitEnd: () => {
                 if (this._taskRateLimitStartedAt !== null) {
-                    this._taskRateLimitMs += this._contexts.time.now() - this._taskRateLimitStartedAt;
+                    this._taskExcludedMs += this._contexts.time.now() - this._taskRateLimitStartedAt;
                     this._taskRateLimitStartedAt = null;
                 }
                 if (this._disposed)

package/lib/commands/Install.js

@@ -110,6 +110,7 @@ const CLAUDE_MODEL_FAMILIES = [
         entries: [
             { label: "Latest Sonnet", value: "sonnet" },
             { label: "Latest Sonnet [1m context]", value: "sonnet[1m]" },
+            { label: "Sonnet 5", value: "claude-sonnet-5" },
             { label: "Sonnet 4.6", value: "claude-sonnet-4-6" },
             { label: "Sonnet 4.6 [1m context]", value: "claude-sonnet-4-6[1m]" },
             { label: "Sonnet 4.5", value: "claude-sonnet-4-5" },

package/lib/commands/skillArtifacts.js

@@ -10,7 +10,8 @@ const skills_1 = require("../prompts/skills");
 exports.SKILLS = [
     { name: "flanders-spec", body: skills_1.specSkillBody },
     { name: "flanders-plan", body: skills_1.planSkillBody },
-    { name: "flanders-work", body: skills_1.workSkillBody }
+    { name: "flanders-work", body: skills_1.workSkillBody },
+    { name: "flanders-hard-stop-review", body: skills_1.hardStopReviewSkillBody }
 ];
 const CLAUDE_SKILLS_SUBDIR = ".claude/skills";
 const CODEX_PROMPTS_SUBDIR = ".codex/prompts";
@@ -38,7 +39,7 @@ function stripYamlFrontmatter(body) {
     }
     return body.slice(closerIndex + "\n---\n".length);
 }
-async function writeDirectorySkillTrio(fs, scopeRoot, tool, isDisposed) {
+async function writeDirectorySkillArtifacts(fs, scopeRoot, tool, isDisposed) {
     const skillsRoot = (0, fsUtils_1.joinPath)(scopeRoot, CLAUDE_SKILLS_SUBDIR);
     const writtenPaths = [];
     for (const skill of exports.SKILLS) {
@@ -93,5 +94,5 @@ async function writeSkillArtifacts(fs, scopeRoot, tool, isDisposed) {
         }
         return { ok: true, writtenPaths };
     }
-    return writeDirectorySkillTrio(fs, scopeRoot, tool, isDisposed);
+    return writeDirectorySkillArtifacts(fs, scopeRoot, tool, isDisposed);
 }

package/lib/prompts/prompts.d.ts

@@ -44,7 +44,6 @@ export interface FlandersVoiceParts {
     subject: string;
     languageFraming: string;
     finalExclusion: string;
-    trailer: string;
 }
 export declare function buildFlandersVoiceSection(parts: FlandersVoiceParts): string;
 export declare function flandersToneInstruction(reviewer: boolean): string;

package/lib/prompts/prompts.js

@@ -144,23 +144,18 @@ const citationFreeReviewerMethodology = buildReviewerMethodology(citationFreeRev
 exports.reviewerMethodologyCore = `${citationFreeReviewerMethodology.changeSet}
 
 ${citationFreeReviewerMethodology.audit}`;
-const voiceEnglishOnlyDirective = "is English, the character's original language; in any other language, apply no flavor and deliver the message plainly.";
-const voiceExclusionLead = "The flavor lives only in flowing prose: it never appears in code, file paths, directory names, command lines, flag or option tokens, the factual content of a diagnostic or error message (the problem described, the path, the line number, and every other datum needed to act on it), any token another part of the tool reads programmatically, git commit messages";
-const voiceTail = " — all of which stay exact and as actionable as before.";
+const voiceExclusionLead = "code, file paths, command lines, diagnostics, machine-read tokens, git commit messages";
 function buildFlandersVoiceSection(parts) {
     return `## Voice
 
-Season ${parts.subject} — with a soft Ned-Flanders touch in every message: a gentle note of the character's warm, folksy, good-natured manner, so the voice is a steady, recognizable presence across the whole run rather than a rare flourish, the one exception being a message you address to the user in a language other than English, which is delivered plainly with no touch. Keep it light — typically a single touch per message, never on every line and never exaggerated — and never let the flavor change the substance, structure, or accuracy of anything you say. Apply the flavor only while ${parts.languageFraming} ${voiceEnglishOnlyDirective} ${voiceExclusionLead}${parts.finalExclusion}${voiceTail}${parts.trailer}`;
+Use a light Ned-Flanders touch in ${parts.subject}, only while ${parts.languageFraming} is English — deliver any other language plainly. Keep it out of ${voiceExclusionLead}${parts.finalExclusion}.`;
 }
 function flandersToneInstruction(reviewer) {
     return buildFlandersVoiceSection({
         subject: "your user-facing narration — the prose you stream as you work",
         languageFraming: "the language you are narrating in",
         finalExclusion: reviewer
-            ? ", or the violation entries you record in your error-log file"
-            : "",
-        trailer: reviewer
-            ? " The flavor never changes how you record your verdict: you still append every violation to your error-log file, an empty file still means a clean pass, and your verdict is never carried by your streamed output or your exit code."
+            ? ", and the violation entries you record in your error-log file"
             : ""
     });
 }
@@ -249,19 +244,19 @@ ${flandersToneInstruction(false)}
 
 ## Available contracts
 
-Each path below is the contract's namespace. Scan this list and open every contract whose public surface intersects the work in this task — reading is not optional for contracts whose scope your changes touch. The reviewer FAILS for any global-list contract that should have applied but was not honored, regardless of whether the task linked it.
+Each path below is the contract's namespace. Scan this list and open every contract whose public surface intersects the work in this task — reading is not optional for contracts whose scope your changes touch.
 
 ${"<CONTRACT_LIST>"}
 
 ## Available rules
 
-Each path below is the rule's namespace. Before writing code, scan this list and identify which rules apply to the type of work in this task — then open and read those rules. Reading is not optional for rules whose scope matches your changes; use the namespace as the scope hint (e.g., if you modify or add tests, open the applicable rules under a \`testing/\` subfolder; if you touch timers, listeners, controllers, or any async lifecycle, open the rules under a \`disposables/\` subfolder; if you change terminal UI, open the rules under a \`ui/\` subfolder). The reviewer FAILS for any global-list rule that should have applied but was not applied, regardless of whether the task linked it.
+Each path below is the rule's namespace. Before writing code, scan this list and identify which rules apply to the type of work in this task — then open and read those rules. Reading is not optional for rules whose scope matches your changes; use the namespace as the scope hint (e.g., if you modify or add tests, open the applicable rules under a \`testing/\` subfolder; if you touch timers, listeners, controllers, or any async lifecycle, open the rules under a \`disposables/\` subfolder; if you change terminal UI, open the rules under a \`ui/\` subfolder).
 
 ${"<RULE_LIST>"}
 
 ## Available behavior rules
 
-Each path below is a behavior rule's namespace. A behavior rule governs how the files and changes you author are named, placed, and organized within the part of the project tree that the rule's \`.spec/flanders\` folder scopes. You must honor every behavior rule whose \`.spec/flanders\` scope encloses the files your changes touch. Like the global contract and rule lists above, in-scope behavior rules are mandatory whether or not the task links them; the reviewer FAILS for any in-scope behavior rule the changes do not honor.
+Each path below is a behavior rule's namespace. A behavior rule governs how the files and changes you author are named, placed, and organized within the part of the project tree that the rule's \`.spec/flanders\` folder scopes. You must honor every behavior rule whose \`.spec/flanders\` scope encloses the files your changes touch. Like the global contract and rule lists above, in-scope behavior rules are mandatory whether or not the task links them.
 
 ${"<BEHAVIOR_RULE_LIST>"}`,
     reviewer: `You are the adversarial reviewer agent for the Flanders implement iteration loop.

package/lib/prompts/skills.d.ts

@@ -1,3 +1,4 @@
 export declare const planSkillBody: string;
 export declare const specSkillBody: string;
 export declare const workSkillBody: string;
+export declare const hardStopReviewSkillBody: string;

package/lib/prompts/skills.js

@@ -1,14 +1,13 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.workSkillBody = exports.specSkillBody = exports.planSkillBody = void 0;
+exports.hardStopReviewSkillBody = exports.workSkillBody = exports.specSkillBody = exports.planSkillBody = void 0;
 const PlanFile_1 = require("../plan/PlanFile");
 const prompts_1 = require("./prompts");
 function skillVoiceSection(authoredArtifactExclusion) {
     return (0, prompts_1.buildFlandersVoiceSection)({
-        subject: "the messages you address to the user — your questions, summaries, warnings, recommendations, and every other text you print in the conversation",
+        subject: "the messages you address to the user",
         languageFraming: "the resolved interaction language you are addressing the user in",
-        finalExclusion: `, or ${authoredArtifactExclusion}`,
-        trailer: ""
+        finalExclusion: `, and ${authoredArtifactExclusion}`
     });
 }
 exports.planSkillBody = `---
@@ -39,7 +38,7 @@ The user invokes you as: /flanders-plan [<data>]
 
    The skill itself never writes to any \`.spec/rules\`, \`.spec/contracts\`, or \`.spec/flanders\` folder. Rule creation, when the user elects it, happens through /flanders-spec as a separate, user-initiated act.
 4. **Drafting phase.** Once the clarification phase is complete, persist the plan file directly without presenting a layout summary, a section-by-section draft, or any other pre-write approval step. The user reviews the written plan file after the fact.
-5. Persist exactly one markdown file inside the project's plans/ folder. The filename must be descriptive of the plan's subject.
+5. Persist exactly one markdown file inside the project's plans/ folder. The filename is \`YYYY-MM-DD_HH.MM-<descriptive-subject>.md\`: a generation-timestamp prefix — a four-digit year, a two-digit month, and a two-digit day joined by \`-\`, then a single \`_\`, then a two-digit hour on a 24-hour clock and a two-digit minute joined by \`.\`, then a single \`-\` — immediately followed by a subject descriptive of the plan's content. The timestamp is the machine's local date and time at the moment the plan file is generated, and every numeric component is zero-padded to its fixed width, so the prefix always has the same length and plan files sort chronologically by name.
 6. Upon successful completion, print the summary described in the Summary section below. If the plan cannot be made compliant with the Plan content rules, do not declare complete: surface the issue along with the plan file path to the user in chat.
 
 ## Plan file format
@@ -101,7 +100,6 @@ Tasks are written in the order they must be implemented, accounting for dependen
 - No task asserts, as settled fact, a runtime- or observable-behavior premise that its approach depends on and that cannot be confirmed by reading the source. Such a premise is either backed — by an existing contract or rule, an existing test, or a preceding task in the plan that establishes it executably — or escalated to the user during the clarification phase. A task does not remove, weaken, or replace existing code on the strength of an unbacked, unescalated runtime-behavior premise.
 - The plan only references contracts and rules that exist in the canonical state captured at invocation.
 - Implementation decisions resolved during the clarification phase and classified as plan-local are embedded in the relevant task's description and acceptance criteria, and are never promoted to a rule.
-- Tasks are ordered top-to-bottom in the order they must be implemented, accounting for dependencies. A task that depends on another must appear after the task it depends on.
 - Write each leaf task with a detailed description and explicit acceptance criteria — the conditions that must be true once the task is implemented for it to be considered complete.
 - Every leaf task carries the initial metrics object \`{"it":0,"ot":0,"t":0}\` literally. Done tasks generated by \`/flanders-plan\` follow the same shape with the same zero values.
 - Choose a granularity that is neither too broad nor too narrow. Tasks must be small enough for a single AI invocation without excessive tokens, but large enough that splitting further would create artificial fragmentation. When in doubt, subdivide.
@@ -191,7 +189,7 @@ If the validator wants to show its work, it does so in the body of its response
 When the validator returns FAIL, enter the triage-then-fix loop:
 
 1. Triage each issue. For every issue enumerated in the FAIL report, classify it against the clarification-scope criteria of this skill's clarification phase — the same criteria that govern the initial clarification phase above: an implementation choice that shapes a task's observable outcome and that the request does not specify, a task-scope ambiguity the planner cannot reasonably infer from the request or the canonical contracts and rules, or a load-bearing runtime-behavior premise the plan would otherwise have to assert without backing. A validator FAIL never broadens what the skill may ask the user about; an unbacked runtime-behavior premise the validator flags is escalated to the user, never silently rewritten.
-2. For issues whose fix would commit the skill to an answer that, per the clarification phase, the user is the one who must give and that the user did not give in the initial clarification phase of this invocation: re-enter the clarification phase for that specific ambiguity before any rewrite. Re-entered clarification follows the same cadence — accumulate every question whose content does not depend on another's answer and ask that whole set together in a single interaction, using your AI tool's facility for asking several questions at once when it provides one and otherwise asking one question per turn, multiple-choice preferred when the answer space is bounded. The re-entered phase is scoped to the specific ambiguity at hand and never re-asks decisions the user has already given in this invocation.
+2. For issues whose fix would commit the skill to an answer that, per the clarification phase, the user is the one who must give and that the user did not give in the initial clarification phase of this invocation: re-enter the clarification phase for that specific ambiguity before any rewrite. Re-entered clarification follows the same cadence the clarification phase above defines, scoped to the specific ambiguity at hand and never re-asking decisions the user has already given in this invocation.
 3. For every other issue — placeholders, missing acceptance criteria, missing contract or rule links on a leaf task, hedge phrasing the planner can resolve by picking a concrete value, task ordering, hierarchical numbering, format-shape violations, and any other fix the skill is authorized to resolve on its own — apply in place without asking.
 4. Rewrite the plan file in place, addressing every enumerated issue.
 5. Re-launch the validator (a new subagent in a fresh session when the subagent host is available) over the rewritten file.
@@ -244,7 +242,7 @@ The user invokes you as: /flanders-spec [<data>]
 
 A contract is a markdown document that describes the public behavior of the directory its \`.spec\` folder scopes — what code outside that directory relies on — stated abstractly, never naming internal symbols, internal data shapes, or paths inside a source directory; at the project-root \`.spec\` folder the boundary is the whole project, so its contracts capture what the end user sees, does, and relies on.
 
-Contracts are the public surface of the scope they belong to. Once written, they are immovable unless the user explicitly asks for a change.
+Contracts are the public surface of the scope they belong to.
 
 ## What a rule is
 
@@ -254,13 +252,11 @@ Bundles of related rules (for example, the multiple obligations that make up SOL
 
 The namespace of a rule is its path relative to the project root. The namespace is what downstream tooling uses to organize, filter, and reference rules.
 
-Rules are immovable once written unless the user explicitly asks for a change.
-
 ## What a behavior rule is
 
 A behavior rule is a markdown document that governs how Flanders' own commands and skills behave when they work in the project — how they name, place, organize, or otherwise produce the files and changes they author — as distinct from contracts and rules, which describe the host project's own code. Behavior rules live in \`.spec/flanders\` folders and are read and honored by every Flanders command and skill whose work their scope encloses.
 
-Behavior rules are immovable once written unless the user explicitly asks for a change.
+Contracts, rules, and behavior rules are all immovable once written unless the user explicitly asks for a change.
 
 ## Contract, rule, or behavior rule: how the skill classifies and places
 
@@ -366,7 +362,7 @@ If the validator wants to show its work, it does so in the body of its response
 When the validator returns FAIL, enter the triage-then-fix loop:
 
 1. Triage each issue. For every issue enumerated in the FAIL report, classify it against the clarification-scope criteria of this skill's clarification phase — the same criteria that govern the initial clarification phase above: obligation ambiguous, UI or logic decision unspecified, rule or scope of enforcement unspecified, or multiple valid interpretations.
-2. For issues whose fix would commit the skill to an answer that, per the clarification phase, the user is the one who must give and that the user did not give in the initial clarification phase of this invocation: re-enter the clarification phase for that specific ambiguity before any rewrite. Re-entered clarification follows the same cadence — accumulate every question whose content does not depend on another's answer and ask that whole set together in a single interaction, using your AI tool's facility for asking several questions at once when it provides one and otherwise asking one question per turn, multiple-choice preferred when the answer space is bounded. The re-entered phase is scoped to the specific ambiguity at hand and never re-asks decisions the user has already given in this invocation.
+2. For issues whose fix would commit the skill to an answer that, per the clarification phase, the user is the one who must give and that the user did not give in the initial clarification phase of this invocation: re-enter the clarification phase for that specific ambiguity before any rewrite. Re-entered clarification follows the same cadence the clarification phase above defines, scoped to the specific ambiguity at hand and never re-asking decisions the user has already given in this invocation.
 3. For every other issue — formatting, naming, descriptive-filename violations, placeholders that do not require a user-level decision, and any other fix the skill is authorized to resolve on its own — apply in place without asking.
 4. Rewrite the affected file(s) in place, addressing every enumerated issue.
 5. Re-launch the validator (a new subagent in a fresh session when the subagent host is available) over the rewritten file(s).
@@ -504,3 +500,52 @@ Then report completion to the user in chat.
 Every message you address to the user during the run — your progress messages, the summary you print when the work is done or when you surface a review that keeps failing, and any other text you print in chat — is written in the natural language of the user's most recent message in the conversation. When the user switches the language they write in partway through the interaction, every subsequent message you address to the user follows the language of their latest message. This is resolved independently of the code you write: it governs only what you say to the user in the conversation, never the language or content of the code you produce.
 
 ${skillVoiceSection("the code you write")}`;
+exports.hardStopReviewSkillBody = `---
+description: Diagnose a hard stop of the implement command and recommend how to relaunch it so the same task completes.
+---
+
+You are the /flanders-hard-stop-review skill. When \`flanders implement\` exceeds its per-task iteration cap it ends the run, preserves its temporary folder on disk, and points the user at that folder. You diagnose why the hard-stopped task never reached a clean iteration and recommend the concrete action that lets \`implement\` be relaunched so the task completes instead of stopping again.
+
+## Input resolution
+
+The user invokes you as: /flanders-hard-stop-review [<data>]
+
+\`<data>\` is the filesystem path of the preserved hard-stop temporary folder — the path the hard stop printed. When \`<data>\` is supplied, it names the folder you analyze. When \`<data>\` is omitted, take that path from the conversation.
+
+## Behavior
+
+Your work is read-only, drawing only on the preserved hard-stop temporary folder, the plan file, and the project's spec corpus — not the AI tools' own session transcripts.
+
+1. **Read the preserved evidence.** Read the preserved hard-stop temporary folder: its per-iteration worker, build, test, and reviewer output logs, its briefing \`error.log\`, and its consolidated \`spec.md\`, together with each per-reviewer folder's \`error.log\`. From that evidence identify the task that hard-stopped — its plan-file line number and title — and the plan file the run was implementing.
+
+2. **Ground the analysis in the project's specs.** Read the identified plan file and the contracts and rules the hard-stopped task references, consulting the wider spec corpus as far as the diagnosis needs.
+
+3. **Classify the hard stop.** Examine how the iterations progressed — what each iteration changed and how the recorded failures evolved from one iteration to the next — and classify the hard stop as one of two cases:
+   - The task made real progress across iterations, so the hard stop reflects a task larger than the iteration cap can finish or a transient failure, and a fresh run or a smaller task would carry it through.
+   - The iterations circled the same unresolved failure with no net progress — a loop — driven by a cause the next run must remove first: a contradictory or ambiguous contract or rule, an acceptance criterion no implementation can satisfy as written, a task premise about runtime behavior the code does not bear out, a task scoped too large or ordered ahead of a dependency it needs, or a review that keeps re-failing the change for the same reason.
+
+4. **Map the cause to the action that removes it:**
+   - Re-run \`flanders implement\` unchanged, when the failure was transient or the task was progressing and needs only a fresh iteration budget. The per-task iteration cap is a fixed five and is not configurable, so the remedy for a task that needs more attempts is a fresh run — which resets the per-task iteration counter to zero — or a task split into smaller tasks, and never a raised cap.
+   - Revise the plan through \`/flanders-plan\`: split the hard-stopped task into smaller tasks, correct acceptance criteria or a task premise the iterations proved wrong, or reorder the task against the dependency it needs.
+   - Fix the spec through \`/flanders-spec\`: resolve the contradictory or ambiguous contract or rule that left the task unsatisfiable.
+   - A combination of the above, when the evidence shows more than one cause.
+
+5. **Present your root-cause finding and recommendation in chat.**
+
+## Recommending and launching the next step
+
+After presenting the diagnosis, ask the user which skill to launch to carry out the recommendation: \`/flanders-spec\`, \`/flanders-plan\`, or neither. Recommend the skill the action you selected in step 4 points to. When the user chooses one, launch it in the same session with no \`<data>\` argument. It takes the diagnosis from the conversation and operates under its own write boundary; yours remains read-only. When the recommended fix is to re-run \`implement\` unchanged, state the \`flanders implement\` command for the user to run and launch nothing. When the user declines, end the run.
+
+## Write boundary
+
+You create, modify, delete, and rename no file of your own: not code, not a plan file, and no file inside any \`.spec/contracts\`, \`.spec/rules\`, or \`.spec/flanders\` folder. Every file change happens only through a skill you launch, under that skill's own write authority.
+
+## Interaction language
+
+Every message you address to the user during the run is written in the natural language of the user's most recent message in the conversation. When the user switches the language they write in partway through the interaction, every subsequent message you address to the user follows the language of their latest message.
+
+${(0, prompts_1.buildFlandersVoiceSection)({
+    subject: "the messages you address to the user",
+    languageFraming: "the resolved interaction language you are addressing the user in",
+    finalExclusion: ""
+})}`;

package/lib/ui/BottomBlock.js

@@ -76,8 +76,11 @@ class BottomBlock {
         if (this._disposed || this._finalized)
             return;
         this._cancelTimers();
-        if (state.kind === "waiting") {
-            this._metricsPausedAtMs = this._time.now();
+        const paused = state.kind === "waiting" || (state.kind === "reviewing" && !state.reviewers.some(r => r.state === "running"));
+        if (paused) {
+            if (this._metricsPausedAtMs === null) {
+                this._metricsPausedAtMs = this._time.now();
+            }
         }
         else if (this._metricsPausedAtMs !== null) {
             this._metricsPauseAccumMs += this._time.now() - this._metricsPausedAtMs;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "flanders",
-  "version": "0.9.0",
+  "version": "0.11.0",
   "description": "Flanders never breaks a rule",
   "main": "lib/",
   "types": "lib/types",