flanders 0.9.0 → 0.10.0

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/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/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.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",
+        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 = `---
@@ -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).

package/package.json

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