flanders 0.8.0 → 0.10.0

package/lib/commands/skillArtifacts.js

@@ -15,10 +15,10 @@ exports.SKILLS = [
 const CLAUDE_SKILLS_SUBDIR = ".claude/skills";
 const CODEX_PROMPTS_SUBDIR = ".codex/prompts";
 function skillArtifactPath(scopeRoot, tool, skillName) {
-    if (tool === "claude") {
-        return (0, fsUtils_1.joinPath)(scopeRoot, CLAUDE_SKILLS_SUBDIR, skillName, "SKILL.md");
+    if (tool === "codex") {
+        return (0, fsUtils_1.joinPath)(scopeRoot, CODEX_PROMPTS_SUBDIR, `${skillName}.md`);
     }
-    return (0, fsUtils_1.joinPath)(scopeRoot, CODEX_PROMPTS_SUBDIR, `${skillName}.md`);
+    return (0, fsUtils_1.joinPath)(scopeRoot, CLAUDE_SKILLS_SUBDIR, skillName, "SKILL.md");
 }
 function skillArtifactPaths(scopeRoot, tool) {
     return exports.SKILLS.map(skill => skillArtifactPath(scopeRoot, tool, skill.name));
@@ -38,29 +38,53 @@ function stripYamlFrontmatter(body) {
     }
     return body.slice(closerIndex + "\n---\n".length);
 }
+async function writeDirectorySkillTrio(fs, scopeRoot, tool, isDisposed) {
+    const skillsRoot = (0, fsUtils_1.joinPath)(scopeRoot, CLAUDE_SKILLS_SUBDIR);
+    const writtenPaths = [];
+    for (const skill of exports.SKILLS) {
+        if (isDisposed()) {
+            return { ok: false, diagnostic: null };
+        }
+        const skillFolder = (0, fsUtils_1.joinPath)(skillsRoot, skill.name);
+        try {
+            await fs.mkdir(skillFolder, { recursive: true });
+        }
+        catch {
+            return { ok: false, diagnostic: `Cannot create destination: ${skillFolder}\n` };
+        }
+        const filePath = skillArtifactPath(scopeRoot, tool, skill.name);
+        try {
+            await fs.writeFile(filePath, skill.body);
+            writtenPaths.push(filePath);
+        }
+        catch {
+            return { ok: false, diagnostic: `Cannot write file: ${filePath}\n` };
+        }
+    }
+    return { ok: true, writtenPaths };
+}
 async function writeSkillArtifacts(fs, scopeRoot, tool, isDisposed) {
     for (const skill of exports.SKILLS) {
         if (!skill.body) {
             return { ok: false, diagnostic: `Skill "${skill.name}" has no content.\n` };
         }
     }
-    const writtenPaths = [];
-    if (tool === "claude") {
-        const claudeSkillsRoot = (0, fsUtils_1.joinPath)(scopeRoot, CLAUDE_SKILLS_SUBDIR);
+    if (tool === "codex") {
+        const codexPromptsRoot = (0, fsUtils_1.joinPath)(scopeRoot, CODEX_PROMPTS_SUBDIR);
+        try {
+            await fs.mkdir(codexPromptsRoot, { recursive: true });
+        }
+        catch {
+            return { ok: false, diagnostic: `Cannot create destination: ${codexPromptsRoot}\n` };
+        }
+        const writtenPaths = [];
         for (const skill of exports.SKILLS) {
             if (isDisposed()) {
                 return { ok: false, diagnostic: null };
             }
-            const skillFolder = (0, fsUtils_1.joinPath)(claudeSkillsRoot, skill.name);
-            try {
-                await fs.mkdir(skillFolder, { recursive: true });
-            }
-            catch {
-                return { ok: false, diagnostic: `Cannot create destination: ${skillFolder}\n` };
-            }
-            const filePath = skillArtifactPath(scopeRoot, "claude", skill.name);
+            const filePath = skillArtifactPath(scopeRoot, "codex", skill.name);
             try {
-                await fs.writeFile(filePath, skill.body);
+                await fs.writeFile(filePath, stripYamlFrontmatter(skill.body));
                 writtenPaths.push(filePath);
             }
             catch {
@@ -69,25 +93,5 @@ async function writeSkillArtifacts(fs, scopeRoot, tool, isDisposed) {
         }
         return { ok: true, writtenPaths };
     }
-    const codexPromptsRoot = (0, fsUtils_1.joinPath)(scopeRoot, CODEX_PROMPTS_SUBDIR);
-    try {
-        await fs.mkdir(codexPromptsRoot, { recursive: true });
-    }
-    catch {
-        return { ok: false, diagnostic: `Cannot create destination: ${codexPromptsRoot}\n` };
-    }
-    for (const skill of exports.SKILLS) {
-        if (isDisposed()) {
-            return { ok: false, diagnostic: null };
-        }
-        const filePath = skillArtifactPath(scopeRoot, "codex", skill.name);
-        try {
-            await fs.writeFile(filePath, stripYamlFrontmatter(skill.body));
-            writtenPaths.push(filePath);
-        }
-        catch {
-            return { ok: false, diagnostic: `Cannot write file: ${filePath}\n` };
-        }
-    }
-    return { ok: true, writtenPaths };
+    return writeDirectorySkillTrio(fs, scopeRoot, tool, isDisposed);
 }

package/lib/contexts.d.ts

@@ -61,6 +61,7 @@ export type AskChoiceOptions = Readonly<{
     options: readonly ChoiceOption[];
     multiSelect: boolean;
     defaultIndex?: number;
+    defaultIndexes?: readonly number[];
 }>;
 export type AskAnswer = Readonly<{
     picked: readonly ChoiceOption[];

package/lib/fastMode.d.ts

@@ -0,0 +1,2 @@
+export declare const FAST_CAPABLE_MODELS: readonly string[];
+export declare function modelSupportsFastMode(model: string): boolean;

package/lib/fastMode.js

@@ -0,0 +1,15 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.FAST_CAPABLE_MODELS = void 0;
+exports.modelSupportsFastMode = modelSupportsFastMode;
+exports.FAST_CAPABLE_MODELS = [
+    "opus",
+    "opus[1m]",
+    "claude-opus-4-8",
+    "claude-opus-4-8[1m]",
+    "claude-opus-4-7",
+    "claude-opus-4-7[1m]"
+];
+function modelSupportsFastMode(model) {
+    return exports.FAST_CAPABLE_MODELS.includes(model);
+}

package/lib/plan/PlanFile.d.ts

@@ -33,11 +33,13 @@ export declare function headingAnchor(headingText: string): string;
 export declare function extractHeadingSection(content: string, anchor: string): string | null;
 export declare function buildSpecFileContent(references: readonly LinkedReference[], fileContents: ReadonlyMap<string, string>): string;
 export declare class PlanFile {
-    readonly path: string;
     private _content;
     private _fs;
+    private _path;
     private constructor();
+    get path(): string;
     static load(path: string, fs: FsContext): Promise<PlanFile>;
+    rename(newPath: string): Promise<void>;
     parse(): PlanParseResult;
     nextOpenTask(): PlanTask | null;
     updateMetrics(lineNumber: number, metrics: TaskMetrics): Promise<void>;

package/lib/plan/PlanFile.js

@@ -206,14 +206,21 @@ function buildSpecFileContent(references, fileContents) {
 }
 class PlanFile {
     constructor(path, _content, _fs) {
-        this.path = path;
         this._content = _content;
         this._fs = _fs;
+        this._path = path;
+    }
+    get path() {
+        return this._path;
     }
     static async load(path, fs) {
         const content = await fs.readFile(path);
         return new PlanFile(path, content, fs);
     }
+    async rename(newPath) {
+        await this._fs.rename(this._path, newPath);
+        this._path = newPath;
+    }
     parse() {
         return parsePlan(this._content);
     }

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

@@ -23,7 +23,7 @@ const workerToolchainRerunStep = `When a test-guarded regression argument cannot
 const claimClassification = `${claimClassificationCore}
 
 ${workerToolchainRerunStep}`;
-const foregroundBoundary = `Foreground execution boundary: you run every command you execute in the foreground and keep your turn active until that command finishes and its result is in hand. You must not start any command in the background and must not end your turn while a command you spawned is still running. This binds every command without exception — build scripts, test scripts, linters, and any other shell command; give a long-running command a tool timeout large enough to finish in the foreground rather than detaching it. Forbidden mechanisms include a tool call made with a background flag (for example \`run_in_background: true\`), shell-level detachment (a trailing \`&\`, \`nohup\`, \`setsid\`, \`disown\`, \`start\`, \`Start-Process\`, \`Start-Job\`), converting a timed-out foreground command into a background task, and ending your turn with a message that a spawned command is still running. The full obligation lives in rules/ai/agents/no-background-commands.md.`;
+const foregroundBoundary = `Foreground execution boundary: you run every command you execute in the foreground and keep your turn active until that command finishes and its result is in hand. This binds every command without exception — build scripts, test scripts, linters, and any other shell command; give a long-running command a tool timeout large enough to finish in the foreground rather than detaching it. Forbidden mechanisms include a tool call made with a background flag (for example \`run_in_background: true\`), shell-level detachment (a trailing \`&\`, \`nohup\`, \`setsid\`, \`disown\`, \`start\`, \`Start-Process\`, \`Start-Job\`), converting a timed-out foreground command into a background task, and ending your turn with a message that a spawned command is still running. The full obligation lives in rules/ai/agents/no-background-commands.md.`;
 const specFolderWriteBoundary = `Spec-folder write boundary: you must not create, modify, delete, or rename any file inside any \`.spec/contracts\` folder, any \`.spec/rules\` folder, any \`.spec/flanders\` folder, or the \`plans/\` folder. These folders are governed by dedicated skills and the implement command's bounded checkpoint updates; no other agent may write to them. See shared/spec-folder-write-authority.md for the full obligation.`;
 const claimClassificationCitationFree = claimClassificationCore.replace(" per `rules/testing/assert-via-public-surface.md`", "");
 function buildReviewerMethodology(s) {
@@ -144,23 +144,18 @@ const citationFreeReviewerMethodology = buildReviewerMethodology(citationFreeRev
 exports.reviewerMethodologyCore = `${citationFreeReviewerMethodology.changeSet}
 
 ${citationFreeReviewerMethodology.audit}`;
-const voiceLocalization = "using that language and region's genuine established localization of the character rather than a word-for-word translation of his original-language manner. Because an established localization is regional, detect and match the regional idiom the user's own writing exhibits, and fall back to the most widely recognized localization of that language when the user's region cannot be determined. When you are addressing the user in a language other than English, the flavor never appears as the character's English-language manner; and when the language has no established localization of the character, or you cannot otherwise render it in that localization, the message is delivered plainly, with no flavor.";
-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 whose language has no established localization of the character, or that you cannot render in that localization, 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. Render the flavor ${parts.languageFraming}, ${voiceLocalization} ${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: "in the same language you are already narrating in",
+        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"
             : ""
     });
 }
@@ -207,7 +202,7 @@ Your output will be inspected by an adversarial reviewer immediately after you f
 4. A contract or rule from the global lists below that the reviewer determines should have been applied but was not — even if the task did not reference it.
 5. A behavior rule from the behavior-rule list below whose \`.spec/flanders\` scope encloses the files your changes touch is not honored by the changes — in-scope behavior rules are mandatory whether or not the task links them.
 
-Condition 4 causes most rejections in practice. Rules whose scope matches your changes (testing rules when you touch tests, disposable rules when you touch async resources, UI rules when you change terminal output, etc.) are mandatory whether the task links them or not. Treat the global contract and rule lists below as part of your specification, not as optional reading. The reviewer will also enumerate every occurrence of a pattern violation, not just the first one, so partial compliance within a file is itself a FAIL.
+Condition 4 causes most rejections in practice. The reviewer will also enumerate every occurrence of a pattern violation, not just the first one, so partial compliance within a file is itself a FAIL.
 
 Procedure:
 1. Read the task shown above and respect the obligations of every contract and rule it references exactly. You may consult those files, or the plan file for broader context, at your discretion.
@@ -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.
@@ -272,7 +267,7 @@ The plan file is at ${"<PLAN_PATH>"}; you may open it for broader context, but y
 
 ${"<TASK_TEXT>"}
 
-The task's full description and its acceptance criteria are provided to you directly, and the full content of every contract and rule it references has been consolidated into a spec.md that you must read in full — see "Linked reference content" below. Inspect the working-tree changes that the worker just produced.
+Inspect the working-tree changes that the worker just produced.
 
 ${linkedReferenceDirective("<SPEC_PATH>")}
 

package/lib/prompts/skills.js

@@ -5,10 +5,9 @@ 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",
-        languageFraming: "in the resolved interaction language you are already addressing the user in",
-        finalExclusion: `, or ${authoredArtifactExclusion}`,
-        trailer: ""
+        subject: "the messages you address to the user",
+        languageFraming: "the resolved interaction language you are addressing the user in",
+        finalExclusion: `, and ${authoredArtifactExclusion}`
     });
 }
 exports.planSkillBody = `---
@@ -31,7 +30,7 @@ The user invokes you as: /flanders-plan [<data>]
 2. Discover every directory named \`.spec\` across the whole project tree at every depth, excluding every path the project's git ignore rules exclude (for example by enumerating with \`git ls-files --cached --others --exclude-standard\` — which lists tracked files plus untracked-but-not-ignored files — and dropping any candidate that sits under a git-ignored path, for example via \`git check-ignore\`); the files under each \`.spec/contracts\` subfolder form the canonical contracts listing and the files under each \`.spec/rules\` subfolder form the canonical rules listing; the files under each \`.spec/flanders\` subfolder form the behavior-rule listing, treating every file inside a \`.spec/flanders\` folder at any depth as a behavior rule; each file is identified by its namespace — its path relative to the project root, which for nested \`.spec\` folders includes the directories above the \`.spec\` folder, so files sharing a leaf filename in different \`.spec\` folders stay distinct.
 
    **Behavior rules.** Before persisting the plan file, read every behavior rule whose \`.spec/flanders\` scope encloses the plan file you are about to write — the project-root \`.spec\` folder and any other \`.spec\` folder whose scope encloses the \`plans/\` target — and honor all of them. Behavior rules govern how you name and organize the plan file you author; an in-scope behavior rule is binding on that work, not advisory, and applies whether or not the request mentions it. This adds no new task-line link obligation: the plan-file format and its contract and rule links are unchanged.
-3. **Clarification phase.** Ask the user clarifying questions only when the question targets one of three things: an implementation choice that shapes a task's observable outcome and that the request does not specify, or a task-scope ambiguity you cannot reasonably infer from the request or from the canonical contracts and rules, or a load-bearing runtime-behavior premise the plan would otherwise have to assert without backing (see the plan content rules below). A choice that affects only how a task's work is carried out internally, with no effect on any observable outcome its acceptance criteria pin, is not asked about: it is left for the implementer to resolve against the real code. Any other doubt is resolved silently: pick the most reasonable default and proceed, documenting the choice in the relevant task's description when it is plan-local and load-bearing. Permitted questions are asked sequentially — one question per turn, multiple-choice preferred when the answer space is bounded.
+3. **Clarification phase.** Ask the user clarifying questions only when the question targets one of three things: an implementation choice that shapes a task's observable outcome and that the request does not specify, or a task-scope ambiguity you cannot reasonably infer from the request or from the canonical contracts and rules, or a load-bearing runtime-behavior premise the plan would otherwise have to assert without backing (see the plan content rules below). A choice that affects only how a task's work is carried out internally, with no effect on any observable outcome its acceptance criteria pin, is not asked about: it is left for the implementer to resolve against the real code. Any other doubt is resolved silently: pick the most reasonable default and proceed, documenting the choice in the relevant task's description when it is plan-local and load-bearing. Before you start asking, accumulate every permitted question whose content does not depend on another question's answer and ask that whole set together in a single interaction rather than one question at a time; a question is held back only when it genuinely depends on an earlier answer, and is then asked in a later round that again batches the questions that have become independent. When your AI tool provides a facility for asking several questions at once, present the accumulated batch through that facility in a single interaction; when it provides no such facility, ask one question per turn. Multiple-choice questions are preferred when the answer space is bounded.
 
    When the doubt is about how the code should be implemented, resolve it through one of two outcomes:
    - **Cross-cutting convention** — the answer would apply to all future code of the same kind in the project and belongs in a \`.spec/rules\` folder. Surface the gap to the user and recommend creating the rule via /flanders-spec before the plan is drafted, instead of silently baking the decision into the plan. The user may explicitly elect to treat the decision as plan-local for this run; in that case it follows the plan-local outcome below.
@@ -94,13 +93,13 @@ Tasks are written in the order they must be implemented, accounting for dependen
 
 - The persisted plan is free of placeholders, contradictions with existing contracts or rules, acceptance criteria that leave a leaf task's observable outcome ambiguous, missing acceptance criteria on leaf tasks, and missing contract or rule links on leaf tasks.
 - The persisted plan is internally self-consistent: its narrative — context, rationale, and any explanatory prose — does not contradict the obligations, verification approach, or any other statement made in its task bodies, and no task contradicts that narrative. Where the prose describes how something is tested or built, it matches what the tasks prescribe.
-- Each leaf task's acceptance criteria pin the task's observable outcome — the behavior the result must exhibit through the surface a reader or a test can inspect — so that any two implementations satisfying them are observably equivalent. The plan does not dictate a task's internal mechanism beyond what an observable acceptance criterion or an explicitly required architectural property demands: a choice that affects only how the work is carried out internally, changing no observable outcome the acceptance criteria pin, is left for the implementer to resolve against the real code rather than fixed by the planner. When the planner needs a structural property for an architectural reason — a single source for some logic, the absence of duplication, a module boundary — it states that property as a required outcome the acceptance criteria assert rather than freezing a specific code element to reuse or to leave untouched.
+- Each leaf task's acceptance criteria pin the task's observable outcome — the behavior the result must exhibit through the surface a reader or a test can inspect — so that any two implementations satisfying them are observably equivalent. The plan does not dictate a task's internal mechanism beyond what an observable acceptance criterion or an explicitly required architectural property demands: a choice that affects only how the work is carried out internally — which mechanism a task uses, and how its code and tests are organized across files and modules — changing no observable outcome the acceptance criteria pin, is left for the implementer to resolve against the real code rather than fixed by the planner. When the planner needs a structural property for an architectural reason — a single source for some logic, the absence of duplication, a module boundary — it states that property as a required outcome the acceptance criteria assert rather than fixing a specific internal mechanism, whether a code element to reuse or leave untouched or the files and modules its code and tests are placed in.
 - Write each paragraph of prose in the plan as a single continuous line, however long; insert a line break only where markdown structure requires it — a blank line between paragraphs, a list item, a heading, a table row, or inside a fenced code block (whose contents you reproduce verbatim). Never break a paragraph across multiple lines to keep it within a maximum column width; the reader's editor wraps long lines for display.
+- Use the fewest words that state each task, obligation, and explanation unambiguously, and write content — a sentence, a section, a cross-reference — only when it carries something not already carried by another task, an earlier sentence, or the reader's ordinary competence. Reach for more words only when fewer would leave an observable outcome ambiguous; task granularity itself follows the granularity rule below.
 - Every task that creates, modifies, or removes code is grounded in the real state of the code it builds on — the current source, plus the changes any earlier task it depends on prescribes. Before writing the task, establish that state: read the current source for code that already exists, and consult the producing earlier task for code an earlier task in the plan creates or changes. Changing what the code does is the task's purpose and is allowed; what a task may not do is misstate the code it builds on — naming structure or behavior that code does not and will not have, or removing or rewriting code on a mistaken account of what it is for.
 - 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.
@@ -162,7 +161,7 @@ Five categories, all mandatory; failure in any one is a FAIL. Each category is a
    - Free of placeholders. No \`<TBD>\` or analogous task markers, no template-style blanks, no parenthetical "(to be decided)" deferrals.
    - Free of contradictions with existing contracts or rules. No task pins behavior the canonical listings forbid.
    - Internally self-consistent — no contradiction between the plan's narrative and its tasks. The plan's context, rationale, and explanatory prose do not contradict the obligations, verification approach, or any other statement in its task bodies, and no task contradicts that narrative. Where the prose describes how something is tested or built, it matches what the tasks prescribe.
-   - Acceptance criteria pin the observable outcome; the internal mechanism may be left to the implementer. Each leaf task's acceptance criteria pin the task's observable outcome precisely, such that two implementations satisfying them are observably equivalent. Acceptance criteria that leave the observable outcome open — satisfiable by implementations that differ in observable behavior — or hedge wording that defers the outcome are FAIL. This includes, non-exhaustively, hedge phrases such as: \`(or class)\`, \`(or function)\`, \`(or refactor in place if preferred)\`, \`pick the lower-friction option\`, \`pick the X that minimizes Y\`, \`suggested location\`, \`or — alternatively —\`, \`or — equivalently —\`, \`or equivalent\`, \`at the time of implementation\`, \`if the X exists, do Y; otherwise Z\`, \`either A or B — pick one\`, \`A or B (or some hybrid)\`, \`or, more strongly\`, \`or X if Y\`. An outcome-affecting choice that the request did not specify must be either closed to a single observable commitment in the task's acceptance criteria, or escalated by the skill to the user before the plan was drafted. A choice that affects only the task's internal mechanism — which helper to reuse, which internal structure, which implementation approach — and that changes no observable outcome the acceptance criteria pin is NOT a violation when left for the implementer to resolve; conversely, a task that freezes an internal mechanism that no observable acceptance criterion and no explicitly required architectural property needs is FAIL.
+   - Acceptance criteria pin the observable outcome; the internal mechanism may be left to the implementer. Each leaf task's acceptance criteria pin the task's observable outcome precisely, such that two implementations satisfying them are observably equivalent. Acceptance criteria that leave the observable outcome open — satisfiable by implementations that differ in observable behavior — or hedge wording that defers the outcome are FAIL. This includes, non-exhaustively, hedge phrases such as: \`(or class)\`, \`(or function)\`, \`(or refactor in place if preferred)\`, \`pick the lower-friction option\`, \`pick the X that minimizes Y\`, \`suggested location\`, \`or — alternatively —\`, \`or — equivalently —\`, \`or equivalent\`, \`at the time of implementation\`, \`if the X exists, do Y; otherwise Z\`, \`either A or B — pick one\`, \`A or B (or some hybrid)\`, \`or, more strongly\`, \`or X if Y\`. An outcome-affecting choice that the request did not specify must be either closed to a single observable commitment in the task's acceptance criteria, or escalated by the skill to the user before the plan was drafted. A choice that affects only the task's internal mechanism — which helper to reuse, which internal structure, how its code and tests are organized across files and modules, which implementation approach — and that changes no observable outcome the acceptance criteria pin is NOT a violation when left for the implementer to resolve; conversely, a task that freezes an internal mechanism that no observable acceptance criterion and no explicitly required architectural property needs is FAIL.
    - Every leaf task carries an explicit acceptance-criteria section.
    - Every leaf task carries the relevant contract link(s) as markdown links in project-root-relative namespace form — the link text is the file's listed namespace with no leading slash, and the target is that same namespace prefixed with a single leading slash.
    - Every leaf task carries the relevant rule link(s) as markdown links in project-root-relative namespace form — the link text is the file's listed namespace with no leading slash, and the target is that same namespace prefixed with a single leading slash. When a rule's enforcement is bound to a specific scope, that scope is referenced alongside the file path.
@@ -190,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 mechanics — one question per turn, multiple-choice preferred when bounded, no bundling. 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.
@@ -208,6 +207,10 @@ After the final validator returns PASS, print a summary in chat containing:
 - The plan file's total line count.
 - The total number of detected tasks.
 
+## After completion: implementing the plan
+
+After the final validator returns PASS and you print the summary above, tell the user in chat that the plan you produced is implemented from the command line by running \`flanders implement\` against it. This message is informational and final: you state that implementation path and end the run. You do not ask the user whether to proceed, and you do not offer to launch, nor launch, any AI-tool skill — including /flanders-work — to implement the plan; carrying out a plan is the job of the \`flanders implement\` command, not of an in-session skill.
+
 ## Output language
 
 Write the plan file in the same natural language as the input request, unless the user says otherwise.
@@ -239,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
 
@@ -249,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
 
@@ -270,11 +271,12 @@ For every obligation in the request, the skill decides whether it is a contract,
    **Behavior rules.** Before persisting any file, read every behavior rule whose \`.spec/flanders\` scope encloses each file you are about to write — the \`.spec\` folder you write the file into and every parent \`.spec\` folder up to the project root — and honor all of them. Behavior rules govern how you name, place, and organize the files you author; an in-scope behavior rule is binding on that work, not advisory, and applies whether or not the request mentions it.
 
    **Rename sweep.** When the run renames, relocates, or removes a term that can recur across the corpus beyond the files it is editing — a folder name, a path segment, a flag, an identifier, a fixed string, or a namespace convention — establish the full set of files to touch by searching the whole corpus (every contract and every rule) for the old term and inspecting every occurrence the search returns. The search is exhaustive over the corpus; it is not narrowed to the files you already planned to edit. Triage each occurrence individually into exactly one of two dispositions: an occurrence the rename must update, which the run edits; or an occurrence that is an intentional reference the rename leaves alone (for example a cross-reference to an unrelated file, or a deliberately unchanged example). An occurrence is never left unexamined on the grounds that its file looked irrelevant. Coverage is driven by the token, not by a judgment of which files are relevant: the set of files the run edits is the union of the occurrences the sweep shows must be updated, and a file the sweep surfaces that you had not planned to touch is added to the run.
-4. **Clarification phase.** Whenever the request leaves an obligation ambiguous, leaves a UI or logic decision unspecified, leaves a rule or its scope of enforcement unspecified, or admits multiple valid interpretations, ask the user clarifying questions sequentially — one question per turn. Prefer multiple-choice questions when the answer space is bounded. Use open-ended questions only when multiple-choice would force a false dichotomy. When two or three substantially different approaches would all satisfy the request, present those approaches with a short trade-off summary for each and ask the user to pick or redirect, instead of silently choosing one. The clarification phase ends only when you have enough information to draft files that contain no placeholders, no contradictions, and no scope ambiguity.
+4. **Clarification phase.** Whenever the request leaves an obligation ambiguous, leaves a UI or logic decision unspecified, leaves a rule or its scope of enforcement unspecified, or admits multiple valid interpretations, ask the user clarifying questions in batches: before you start asking, accumulate every question whose content does not depend on another question's answer and ask that whole set together in a single interaction rather than one question at a time, holding a question back only when it genuinely depends on an earlier answer and asking it in a later round that again batches the questions that have become independent. When your AI tool provides a facility for asking several questions at once, present the accumulated batch through that facility in a single interaction; when it provides no such facility, ask one question per turn. Prefer multiple-choice questions when the answer space is bounded. Use open-ended questions only when multiple-choice would force a false dichotomy. When two or three substantially different approaches would all satisfy the request, present those approaches with a short trade-off summary for each and ask the user to pick or redirect, instead of silently choosing one. The clarification phase ends only when you have enough information to draft files that contain no placeholders, no contradictions, and no scope ambiguity.
 5. **Drafting phase.** Before persisting any file:
    - Present the planned file layout — which files will exist, which \`.spec\` folder each falls in, which are contracts and which are rules (the classification and placement made visible), and the key obligations of each file — as a structured summary, and wait for user approval or redirection.
    - Once the layout is approved, persist every resulting file in a single batch without any further per-file or per-section confirmation step.
    - Update related existing files in place when the request affects obligations they already cover, and create new files only for obligations not already covered. Do not duplicate an obligation across files, whether within a folder or across the two folders.
+   - Use the fewest files and the fewest words that state each obligation unambiguously: write a file, a section, a sentence, or a cross-reference only when it carries something not already carried elsewhere — by another file, by a sentence already written, or by the reader's ordinary competence — and reach for more files or more words only when fewer would leave an obligation ambiguous or would fuse genuinely separable concerns into one place.
    - Do not write historical, transitional, or migration content into the contracts and rules you produce. A spec file states only the present spec — what the software does now and what the code must do now. Content recording what the spec used to be, what it replaces, what changed in this run, or any transitional framing (for example, "replaces the former X", "previously Y", a changelog of what this run changed) belongs in the commit message or pull-request description, not in a permanent spec file.
    - State each obligation as the behavior the code performs — what the software does and what the code must do. The set of things the code does not do is unbounded, so do not enumerate non-actions: satisfy a request to remove or stop a behavior by describing the resulting positive behavior, letting the removed behavior vanish by omission. Write an explicit prohibition — "does not…", "never…", "must not…" — only when it is load-bearing, namely when BOTH conditions hold: (1) its absence is not already entailed by a positive obligation (a positive obligation stated exclusively, such as "the only X is Y", already excludes every alternative, so a prohibition restating that exclusion adds nothing); and (2) it guards a behavior a competent implementer reading only the positive spec would plausibly introduce — an attractive default they would reach for, or a behavior that falls inside a responsibility the component otherwise has. A prohibition that fails either condition is redundant and is not written.
    - Write every cross-reference to another spec file as a markdown link in project-root-relative namespace form: the link text is the referenced file's namespace — its path relative to the project root, with no leading slash — and the target is that same namespace prefixed with a single leading slash, so the link resolves against the project root from a referencing file at any depth and never as a path computed relative to the referencing file's own location. When the relevant obligation lives in a specific section or line range, name that section or line range in the link text and point the target's fragment at it.
@@ -360,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 mechanics — one question per turn, multiple-choice preferred when bounded, no bundling. 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).

package/lib/toolNames.d.ts

@@ -0,0 +1 @@
+export declare const TOOL_NAMES: readonly ["claude", "codex"];

package/lib/toolNames.js

@@ -0,0 +1,4 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.TOOL_NAMES = void 0;
+exports.TOOL_NAMES = ["claude", "codex"];

package/lib/ui/BottomBlock.d.ts

@@ -9,20 +9,20 @@ export type BottomBlockIO = {
 export type Activity = "implementing" | "reviewing" | "building" | "testing";
 export type HeaderFields = {
     indexLabel?: string | null;
+    phaseMessage?: string | null;
     iteration?: number | null;
     activity?: Activity | null;
     taskNumber?: string | null;
     title?: string | null;
 };
+export type MetricsPairFields = {
+    tokens: number;
+    anchorMs?: number;
+    baseSeconds: number;
+};
 export type MetricsFields = {
-    task?: {
-        tokens: number;
-        seconds: number;
-    };
-    plan?: {
-        tokens: number;
-        seconds: number;
-    };
+    task?: MetricsPairFields;
+    plan?: MetricsPairFields;
 };
 export type WaitKind = "rate-limit";
 export type FooterState = {
@@ -58,6 +58,8 @@ export declare class BottomBlock {
     private _countdownTimer;
     private _unsubResize;
     private _prevLineWidths;
+    private _metricsPausedAtMs;
+    private _metricsPauseAccumMs;
     constructor(_io: BottomBlockIO, _time: TimeContext, _random: RandomContext);
     mount(): void;
     isFinalized(): boolean;
@@ -76,5 +78,6 @@ export declare class BottomBlock {
     private _drawBlock;
     private _renderHeader;
     private _renderMetrics;
+    private _resolvePair;
     private _renderFooter;
 }

package/lib/ui/BottomBlock.js

@@ -31,6 +31,8 @@ class BottomBlock {
         this._countdownTimer = null;
         this._unsubResize = null;
         this._prevLineWidths = null;
+        this._metricsPausedAtMs = null;
+        this._metricsPauseAccumMs = 0;
     }
     mount() {
         if (this._disposed)
@@ -64,6 +66,7 @@ class BottomBlock {
         if (this._disposed || this._finalized)
             return;
         this._metrics = fields;
+        this._metricsPauseAccumMs = 0;
         if (this._mounted) {
             this._clearBlock();
             this._drawBlock();
@@ -73,6 +76,13 @@ class BottomBlock {
         if (this._disposed || this._finalized)
             return;
         this._cancelTimers();
+        if (state.kind === "waiting") {
+            this._metricsPausedAtMs = this._time.now();
+        }
+        else if (this._metricsPausedAtMs !== null) {
+            this._metricsPauseAccumMs += this._time.now() - this._metricsPausedAtMs;
+            this._metricsPausedAtMs = null;
+        }
         this._footer = state;
         if (state.kind === "working") {
             this._animFrame = 0;
@@ -213,11 +223,22 @@ class BottomBlock {
         this._prevLineWidths = [cols, (0, formatters_1.stripAnsi)(header).length, (0, formatters_1.stripAnsi)(metrics).length, (0, formatters_1.stripAnsi)(footer).length];
     }
     _renderHeader(cols) {
-        var _a, _b, _c, _d, _e;
-        return (0, formatters_1.formatHeaderLine)((_a = this._header.indexLabel) !== null && _a !== void 0 ? _a : null, (_b = this._header.iteration) !== null && _b !== void 0 ? _b : null, (_c = this._header.activity) !== null && _c !== void 0 ? _c : null, (_d = this._header.taskNumber) !== null && _d !== void 0 ? _d : null, (_e = this._header.title) !== null && _e !== void 0 ? _e : null, cols);
+        var _a, _b, _c, _d, _e, _f;
+        return (0, formatters_1.formatHeaderLine)((_a = this._header.indexLabel) !== null && _a !== void 0 ? _a : null, (_b = this._header.phaseMessage) !== null && _b !== void 0 ? _b : null, (_c = this._header.iteration) !== null && _c !== void 0 ? _c : null, (_d = this._header.activity) !== null && _d !== void 0 ? _d : null, (_e = this._header.taskNumber) !== null && _e !== void 0 ? _e : null, (_f = this._header.title) !== null && _f !== void 0 ? _f : null, cols);
     }
     _renderMetrics(cols) {
-        return (0, formatters_1.formatMetricsLine)(this._metrics.task, this._metrics.plan, cols);
+        return (0, formatters_1.formatMetricsLine)(this._resolvePair(this._metrics.task), this._resolvePair(this._metrics.plan), cols);
+    }
+    _resolvePair(pair) {
+        var _a;
+        if (!pair)
+            return undefined;
+        if (pair.anchorMs === undefined) {
+            return { tokens: pair.tokens, seconds: pair.baseSeconds };
+        }
+        const evalNow = (_a = this._metricsPausedAtMs) !== null && _a !== void 0 ? _a : this._time.now();
+        const activeMs = Math.max(0, evalNow - pair.anchorMs - this._metricsPauseAccumMs);
+        return { tokens: pair.tokens, seconds: Math.floor(activeMs / 1000) + pair.baseSeconds };
     }
     _renderFooter(cols) {
         switch (this._footer.kind) {

package/lib/ui/PromptHelper.d.ts

@@ -10,5 +10,12 @@ export type AskTextArgs = Readonly<{
     placeholder?: string;
     default?: string;
 }>;
+export type AskMultiChoiceArgs = Readonly<{
+    header: string;
+    question: string;
+    options: readonly ChoiceOption[];
+    selected?: readonly ChoiceOption[];
+}>;
 export declare function askChoice(ask: AskContext, args: AskChoiceArgs, output?: OutputContext): Promise<ChoiceOption>;
+export declare function askMultiChoice(ask: AskContext, args: AskMultiChoiceArgs, output?: OutputContext): Promise<readonly ChoiceOption[]>;
 export declare function askText(ask: AskContext, args: AskTextArgs): Promise<string>;

package/lib/ui/PromptHelper.js

@@ -1,6 +1,7 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.askChoice = askChoice;
+exports.askMultiChoice = askMultiChoice;
 exports.askText = askText;
 function abortError() {
     const e = new Error("Aborted");
@@ -23,6 +24,27 @@ async function askChoice(ask, args, output) {
     }
     return answer.picked[0];
 }
+async function askMultiChoice(ask, args, output) {
+    var _a;
+    const selectedLabels = new Set(((_a = args.selected) !== null && _a !== void 0 ? _a : []).map(o => o.label));
+    const defaultIndexes = [];
+    for (let i = 0; i < args.options.length; i++) {
+        if (selectedLabels.has(args.options[i].label)) {
+            defaultIndexes.push(i);
+        }
+    }
+    const [answer] = await ask.askChoices([{
+            header: args.header,
+            question: args.question,
+            options: args.options,
+            multiSelect: true,
+            defaultIndexes: defaultIndexes.length > 0 ? defaultIndexes : undefined
+        }], output);
+    if (!answer || answer.picked.length === 0) {
+        throw abortError();
+    }
+    return answer.picked;
+}
 async function askText(ask, args) {
     const prompt = args.placeholder
         ? `${args.question} (${args.placeholder}): `

package/lib/ui/formatters.d.ts

@@ -1,3 +1,4 @@
+import type { ToolName } from "../ai/ToolAdapter";
 export declare const CYAN = "\u001B[36m";
 export declare const YELLOW = "\u001B[33m";
 export declare const MAGENTA = "\u001B[35m";
@@ -23,7 +24,7 @@ export declare function formatDateTime(date: Date): string;
 export declare function truncateToWidth(text: string, cols: number): string;
 export declare function formatTokens(n: number): string;
 export declare function formatActiveTime(seconds: number): string;
-export declare function formatHeaderLine(indexLabel: string | null, iteration: number | null, activity: string | null, taskNumber: string | null | undefined, title: string | null, cols: number): string;
+export declare function formatHeaderLine(indexLabel: string | null, phaseMessage: string | null, iteration: number | null, activity: string | null, taskNumber: string | null | undefined, title: string | null, cols: number): string;
 export type MetricsPair = {
     tokens: number;
     seconds: number;
@@ -32,7 +33,7 @@ export declare function formatMetricsLine(task: MetricsPair | undefined, plan: M
 export declare function formatSnapshotHeader(indexLabel: string, iteration: number, taskNumber: string | undefined, title: string): string;
 export declare function formatSnapshotMetrics(taskTokens: number, taskSeconds: number, planTokens: number, planSeconds: number): string;
 export declare function formatSnapshotBlock(indexLabel: string, iteration: number, taskNumber: string | undefined, title: string, taskTokens: number, taskSeconds: number, planTokens: number, planSeconds: number, cols: number): string;
-export type ReviewerTool = "claude" | "codex";
+export type ReviewerTool = ToolName;
 export type ReviewerState = "running" | "waiting" | "pass" | "fail";
 export type ReviewerEntry = {
     tool: ReviewerTool;