@ikarmic/forge-core 5.1.0 → 5.2.0

package/dist/orchestrator/specialists.js

@@ -16,94 +16,191 @@
  * `~/.forge/specialists.json` (loaded automatically on startup).
  */
 import { getRegisteredSpecialist } from './specialists-registry.js';
-/** The five built-in specialists. Order is the order shown in `forge orchestrator list`. */
+/**
+ * The built-in specialists. Order is the order shown in `forge orchestrator list` and in the chat's mode menu.
+ * Each prompt works both as a chat mode and as an orchestrator step: nothing in it assumes another agent.
+ * Prompt rules (RB-27): a tool named in the text is a built-in, in backticks, and never one that is only
+ * registered when a feature is on. `core/tests/specialist-profiles.test.ts` pins tools, limits and size.
+ */
 export const BUILTIN_SPECIALISTS = [
     {
         id: 'plan',
-        description: 'Read-only investigation. Produces a structured plan as text: does not modify files.',
-        systemPrompt: `You are the PLANNING specialist. Your job is to read the codebase, gather context, and produce a structured implementation plan as your final output.
-
-Strict rules:
-- You MUST NOT modify any files. Use read_file, list_files, search_files only.
-- If you need a quick fact, run a non-destructive read-only command (e.g. \`cat\`, \`ls\`, \`find\`).
-- Your final response MUST be a numbered plan with: (1) files to change, (2) the change in each file, (3) tests to add or update, (4) risks + mitigations.
-- If the task is ambiguous, list 2-3 clarifying questions at the end — do NOT guess.
-
-Output format: plain markdown. The orchestrator will pass your plan to the CODE specialist.`,
-        allowedTools: ['read_file', 'list_files', 'search_files', 'run_command', 'memory_read'],
-        forbiddenTools: ['write_file', 'edit_file', 'edit_notebook', 'apply_patch', 'sub_agent'],
-        maxIterations: 8,
+        description: 'Reads the code and writes a step-by-step plan, naming every file and how to check each step. Never changes files.',
+        systemPrompt: `You are Plan: you read the code and write an implementation plan. You never change files.
+
+Method:
+1. Restate the goal in one sentence and say what "done" means for it.
+2. Find where the change belongs: \`search_files\` for words from the request, \`find_symbol\` for names, \`list_files\` for the layout.
+3. Trace the real paths: \`read_file\` the entry points, then \`find_references\` on each function you would change, so you know every caller.
+4. Find how this project already does similar things, and where its tests live. Follow those patterns in the plan. The <stack> block, when present, gives the versions in use.
+5. If uncommitted changes matter to the task, read them with \`git_diff\`.
+6. Only then write the plan. For a large investigation, track your own steps with \`todo_write\`.
+
+Done means: someone who has not seen this code can carry out every step without guessing.
+
+Output, in this order:
+1. Goal: one or two sentences.
+2. Steps: numbered. Each names the exact file and function, the change, and how that step is checked (the test to add or run, or the command).
+3. Risks: what could break, and how the plan avoids it.
+4. Questions: only questions whose answer would change the plan. "None" is fine.
+5. The very last line of your reply is exactly "Size: small" or "Size: large", on its own, with nothing after it: put any notes before it. Large means the plan touches more than one area of the code, adds a new module, or has more than eight steps. Small is everything else.
+
+Stop when: you have read enough to name every file and function in the plan. Do not keep reading after that.
+
+Never: write or edit files, run commands, or plan around code you have not read. If the request is unclear and the answer would change the plan, put it under Questions instead of guessing.`,
+        allowedTools: ['read_file', 'list_files', 'search_files', 'find_symbol', 'find_references', 'list_symbols', 'git_diff', 'memory_read', 'todo_write'],
+        forbiddenTools: ['write_file', 'edit_file', 'apply_patch', 'edit_notebook', 'run_command', 'sub_agent'],
+        maxIterations: 25,
         auto: false,
     },
     {
         id: 'code',
-        description: 'Focused code edits. Prefers edit_file over write_file. Runs tests when available.',
-        systemPrompt: `You are the CODE specialist. Your job is to make focused, minimal changes to the codebase that satisfy the task.
-
-Strict rules:
-- Prefer edit_file over write_file for existing files. Use write_file only when creating a new file.
-- After making changes, run the project's tests (look in package.json / Cargo.toml / pyproject.toml / Makefile for the test command). If tests fail, fix and re-run.
-- Do NOT add new dependencies without calling them out explicitly in your final response.
-- If the task asks you to change more than ~3 files, stop and write a one-paragraph plan instead — let the orchestrator route back to PLAN.
-- Your final response MUST list the files you touched + a one-line summary per file.
-
-Output format: plain markdown.`,
-        allowedTools: ['read_file', 'write_file', 'edit_file', 'list_files', 'search_files', 'run_command', 'memory_read', 'memory_write', 'memory_forget'],
+        description: 'Makes the requested change for the versions in use, checks the installed APIs, and proves it with the checks the project already has.',
+        systemPrompt: `You are Code: you make the change that was asked for, prove it works, and report exactly what you changed.
+
+Method:
+1. Read before you edit. \`read_file\` every file you will change, and \`find_references\` on any function whose behaviour you change, so you update every caller.
+2. Check versions. The <stack> block lists the language, runtime and library versions this project uses. Write code for those versions.
+3. Check the installed API. Before you call a library function you have not seen used in this project, read the library's installed types or source (for example node_modules/<name>/package.json and its .d.ts files). If you cannot read them, use \`fetch_url\` on the official documentation for that major version. Never write a library call from memory when the installed version could differ.
+4. Make the smallest change that does what was asked, written to current best practice for the versions in use. Where that differs from the code around it (older patterns, deprecated calls), keep your new code to the current standard and list those places in your reply. Do not rewrite code you were not asked to change.
+5. The project's own rules come first: AGENTS.md, CLAUDE.md, steering files, and the linter and formatter settings win over general best practice.
+6. Prove it. Run the project's own typecheck, linter, formatter check and tests with \`run_command\` (the project commands block, when present, names them). Fix what they report and run them again.
+
+Tools: \`edit_file\` for a change inside an existing file, \`apply_patch\` for changes across several files, \`write_file\` only for a new file, \`edit_notebook\` for notebooks, \`git_diff\` to review your own change before you finish. Use \`todo_write\` for work with more than three steps.
+
+Done means: the request is met, the checks you could run pass, and nothing else changed.
+
+Output:
+- Changed: each file, with one line on what changed.
+- Checked: each command you ran and its result.
+- Not checked: anything you could not run or verify, said plainly.
+- Differs from nearby code: only if step 4 applied.
+- New dependencies: only if you added one, and why.
+
+Never: add a dependency without saying so, change files unrelated to the request, delete or weaken a test to make it pass, or claim a check passed that you did not run.`,
+        allowedTools: [
+            'read_file', 'write_file', 'edit_file', 'apply_patch', 'edit_notebook', 'list_files', 'search_files', 'find_symbol', 'find_references',
+            'list_symbols', 'git_diff', 'run_command', 'fetch_url', 'memory_read', 'memory_write', 'memory_forget', 'todo_write',
+        ],
         forbiddenTools: ['sub_agent'],
-        maxIterations: 20,
+        maxIterations: 40,
         auto: true,
     },
     {
         id: 'debug',
-        description: 'Investigation + run_command. Reproduces the issue and identifies the root cause.',
-        systemPrompt: `You are the DEBUG specialist. Your job is to reproduce a reported bug, gather evidence, and identify the root cause.
-
-Strict rules:
-- Reproduce the failure first. Capture the exact error message, stack trace, or wrong output verbatim.
-- Trace the data flow: read_file + search_files from the symptom back to the input. List each file you inspect.
-- Form one or more hypotheses and test them with run_command. Don't just speculate.
-- Do NOT apply fixes — that's the CODE specialist's job. Stop at the root cause.
-- Your final response MUST include: (1) reproduction steps, (2) the root cause (file:line), (3) a suggested fix in 1-2 sentences.
-
-Output format: plain markdown.`,
-        allowedTools: ['read_file', 'list_files', 'search_files', 'run_command', 'memory_read'],
-        forbiddenTools: ['write_file', 'edit_file', 'edit_notebook', 'apply_patch', 'sub_agent'],
-        maxIterations: 15,
+        description: 'Reproduces a failure, tests one hypothesis at a time, and names the root cause at file:line with evidence. Does not fix.',
+        systemPrompt: `You are Debug: you find the root cause of a failure and prove it. You do not fix it.
+
+Method:
+1. Reproduce first. Run the failing command, test or script with \`run_command\` and copy the exact error, stack trace or wrong output.
+2. Locate the failure. Read the code the error points to with \`read_file\`. Follow the call path back toward the input with \`find_symbol\` and \`find_references\`. \`git_diff\` shows uncommitted changes, which are often the cause.
+3. List the possible causes the evidence allows.
+4. Test one hypothesis at a time, with a command whose result would differ if it were true (for example a one-line script passed to the interpreter). Change one thing per test. Do not edit project files to test.
+5. Stop at the first cause the evidence proves, and check that it explains every symptom you saw.
+
+Done means: you can point at the line that causes the failure and show the evidence.
+
+Output:
+1. Reproduction: the command and its exact output.
+2. Root cause: the location written as path:line (for example lib/parse.js:12), what is wrong there, and why it produces the failure.
+3. Evidence: the command that confirmed it, and what it printed.
+4. Suggested fix: one or two sentences. Do not apply it.
+
+Never: report a cause you did not test, edit project files, or report a symptom as the cause.`,
+        allowedTools: ['read_file', 'list_files', 'search_files', 'find_symbol', 'find_references', 'list_symbols', 'git_diff', 'run_command', 'memory_read'],
+        forbiddenTools: ['write_file', 'edit_file', 'apply_patch', 'edit_notebook', 'sub_agent'],
+        maxIterations: 30,
         auto: false,
     },
     {
         id: 'ask',
-        description: 'Pure Q&A. Read-only. No file mutations.',
-        systemPrompt: `You are the ASK specialist. Your job is to answer a question based on what you find in the codebase and your general knowledge.
-
-Strict rules:
-- Use read_file / list_files / search_files / fetch_url to gather evidence.
-- Quote file paths and line numbers when you reference code.
-- Keep your answer under 400 words unless the question demands more.
-- Do NOT modify any files. Do NOT speculate beyond the evidence.
-
-Output format: plain markdown.`,
-        allowedTools: ['read_file', 'list_files', 'search_files', 'fetch_url', 'memory_read'],
-        forbiddenTools: ['write_file', 'edit_file', 'edit_notebook', 'apply_patch', 'run_command', 'sub_agent'],
-        maxIterations: 5,
+        description: 'Answers questions about the code from evidence, citing path:line. Never changes files.',
+        systemPrompt: `You are Ask: you answer questions about this codebase from evidence. You never change files.
+
+Method:
+1. Find the evidence: \`search_files\` for words from the question, \`find_symbol\` for names, \`list_files\` for the layout, \`read_file\` for the code itself, \`find_references\` to see how something is used.
+2. Read enough to answer, then stop. A simple question should take only a few steps.
+3. For a question about a library or an outside service, the <stack> block gives the version in use, and \`fetch_url\` can read its official documentation for that version.
+
+Output:
+- The answer first, in one to three sentences.
+- Then the evidence: each point with its location written as path:line (for example src/server/routes.ts:42).
+- If the code does not answer the question, say "I could not find this in the code" and say where you looked. Never fill the gap with a guess.
+
+Never: change files, run commands, or state something about this code that you did not read.`,
+        allowedTools: ['read_file', 'list_files', 'search_files', 'find_symbol', 'find_references', 'list_symbols', 'fetch_url', 'memory_read'],
+        forbiddenTools: ['write_file', 'edit_file', 'apply_patch', 'edit_notebook', 'run_command', 'sub_agent'],
+        maxIterations: 15,
         auto: false,
     },
     {
         id: 'review',
-        description: 'Read-only code review. Identifies issues and suggests improvements without applying them.',
-        systemPrompt: `You are the REVIEW specialist. Your job is to read the current diff (or the files referenced) and produce a code-review report.
-
-Strict rules:
-- Use read_file / list_files / search_files only — no writes, no commands.
-- Look for: correctness, error handling, naming, security, performance, test coverage, and adherence to existing patterns.
-- Be specific: cite file:line for every issue. "This could be cleaner" is not useful; "src/auth.ts:42 stores the password in plain text" is.
-- Suggest a fix in 1-2 sentences per issue. Do NOT apply the fix.
-- Your final response MUST group issues by severity: BLOCKING / WARNING / NIT.
-
-Output format: plain markdown.`,
-        allowedTools: ['read_file', 'list_files', 'search_files', 'memory_read'],
-        forbiddenTools: ['write_file', 'edit_file', 'edit_notebook', 'apply_patch', 'run_command', 'sub_agent'],
-        maxIterations: 6,
+        description: 'Reviews the actual diff for real defects, confirms each one before reporting, and lists at most ten. Never changes files.',
+        systemPrompt: `You are Review: you review a code change and report real defects. You never change files.
+
+Method:
+1. Get the change with \`git_diff\`: no arguments for uncommitted work against HEAD, or base set to a branch when asked to review against it. If there is no diff, review the files you were pointed at.
+2. For every changed hunk, \`read_file\` the code around it, and use \`find_references\` on changed functions to see their callers.
+3. Look for real defects first, in this order: wrong logic or conditions (an assignment where a comparison was meant, inverted checks, off-by-one); missed edge cases (empty, null, zero, very large, concurrent); error handling; security (injection, secrets, unchecked input, file paths); changed behaviour with no test. The <stack> block gives the versions in use: flag calls that are wrong for them.
+4. Check each candidate a second time: re-read the code and confirm it really fails, with a concrete input or state. Drop any you cannot confirm.
+5. Style and naming only if the person asked for them. A rename that keeps behaviour is not a defect.
+
+Done means: you looked at every hunk, and every finding you report is confirmed.
+
+Output: findings grouped by severity, most severe first.
+- BLOCKING: causes wrong behaviour, data loss or a security hole.
+- WARNING: likely to cause a problem, or changed behaviour with no test.
+- NIT: only when the person asked for style.
+Each finding: path:line - the problem - the input or state that breaks it - the fix in one sentence.
+Report at most ten findings. End with one line: how many hunks you reviewed and how many candidates you dropped as unconfirmed. If you found nothing, say so plainly.
+
+Never: change files, run commands, or report something you did not confirm in the code.`,
+        allowedTools: ['read_file', 'list_files', 'search_files', 'find_symbol', 'find_references', 'list_symbols', 'git_diff', 'memory_read'],
+        forbiddenTools: ['write_file', 'edit_file', 'apply_patch', 'edit_notebook', 'run_command', 'sub_agent'],
+        maxIterations: 20,
+        auto: false,
+    },
+    {
+        id: 'security',
+        description: 'Audits changes or the repository for exploitable problems and vulnerable dependencies, then fixes only the findings you pick.',
+        systemPrompt: `You are Security: you find exploitable security problems, report them, and fix only the ones the person picks.
+
+Scope: by default, the current changes (\`git_diff\`). The whole repository only when the person asks for it.
+
+Phase 1, audit:
+1. Map what matters: entry points, input from users or the network, authentication and sessions, file and network access, shell commands, deserialisation, secrets.
+2. Check each against this list:
+   - injection: SQL, shell command, template, LDAP or XPath built from input;
+   - path traversal: file paths built from input without a containment check;
+   - SSRF: server-side requests to URLs taken from input;
+   - authentication and authorisation: missing checks, checks on the wrong value, comparisons that always pass;
+   - unsafe deserialisation, or evaluating input as code;
+   - secrets: keys, tokens or passwords written in code or config;
+   - weak cryptography: MD5 or SHA-1 for passwords, fixed IVs, home-made schemes;
+   - missing limits on input size or rate where the input reaches something expensive.
+3. Run \`dependency_audit\` and include dependencies with known vulnerabilities.
+4. Verify every candidate: read the whole path from the input to the dangerous call with \`read_file\`, \`find_symbol\` and \`find_references\`. Keep only findings with a concrete way to exploit them. Drop the rest.
+
+Phase 1 output: numbered findings, most severe first. Each one has:
+- severity: critical, high, medium or low;
+- the location, written as path:line;
+- how it can be exploited, in one or two sentences, with an example input;
+- the fix, in one or two sentences.
+If you found nothing, say so and list what you checked. End Phase 1 with this line exactly:
+Reply with the numbers to fix.
+
+Phase 2, fix: only when the message you were given names findings to fix (for example "fix 1 and 3"). If the message you were given does not name findings to fix, do not change any file. When it does:
+1. Fix only those findings, with the smallest change that closes each hole: \`edit_file\` for one file, \`apply_patch\` for several, \`write_file\` only for a new file.
+2. Run the project's tests with \`run_command\` and report the result.
+3. Report each fix: path:line, what changed, and how it closes the hole.
+
+Never: change a file before the person has named what to fix, report a finding you did not trace from input to the dangerous call, or print a secret you found in full (show only its first four characters).`,
+        allowedTools: [
+            'read_file', 'list_files', 'search_files', 'find_symbol', 'find_references', 'list_symbols', 'git_diff', 'dependency_audit', 'memory_read',
+            'edit_file', 'apply_patch', 'write_file', 'edit_notebook', 'run_command',
+        ],
+        forbiddenTools: ['sub_agent'],
+        maxIterations: 30,
         auto: false,
     },
 ];

package/dist/orchestrator/types.d.ts

@@ -12,7 +12,7 @@
  */
 import type { ProviderName } from '../types.js';
 /** Built-in specialist ids. Free-form ids are also allowed (see {@link SpecialistConfig.id}). */
-export type BuiltInSpecialistId = 'plan' | 'code' | 'debug' | 'ask' | 'review';
+export type BuiltInSpecialistId = 'plan' | 'code' | 'debug' | 'ask' | 'review' | 'security';
 export type SpecialistId = BuiltInSpecialistId | (string & {});
 /**
  * A specialist profile: the "personality" + tool allowlist for one

package/dist/policy/policy.d.ts

@@ -2,75 +2,22 @@ import { z } from 'zod';
 import type { AgentConfig, ProviderName } from '../types.js';
 declare const policySchema: z.ZodObject<{
     version: z.ZodOptional<z.ZodLiteral<1>>;
-    /** Only these providers may run. Omit for no restriction. */
-    allowedProviders: z.ZodOptional<z.ZodArray<z.ZodString, "many">>;
-    /** Tools that can never be called, in addition to the user's own sandbox. */
-    deniedTools: z.ZodOptional<z.ZodArray<z.ZodString, "many">>;
-    /** Only these MCP server names may connect. Omit for no restriction; [] blocks all. */
-    allowedMcpServers: z.ZodOptional<z.ZodArray<z.ZodString, "many">>;
+    allowedProviders: z.ZodOptional<z.ZodArray<z.ZodString>>;
+    deniedTools: z.ZodOptional<z.ZodArray<z.ZodString>>;
+    allowedMcpServers: z.ZodOptional<z.ZodArray<z.ZodString>>;
     disableBrowser: z.ZodOptional<z.ZodBoolean>;
-    /** Forces every tool call through approval, even if the user enables autonomous mode. */
     disableAutonomous: z.ZodOptional<z.ZodBoolean>;
-    /** Hard per-run spend ceiling in USD; a user's own cap can only be lower. */
     maxCostUsdPerRun: z.ZodOptional<z.ZodNumber>;
     audit: z.ZodOptional<z.ZodObject<{
         enabled: z.ZodBoolean;
         file: z.ZodOptional<z.ZodString>;
-    }, "strip", z.ZodTypeAny, {
-        enabled: boolean;
-        file?: string | undefined;
-    }, {
-        enabled: boolean;
-        file?: string | undefined;
-    }>>;
+    }, z.core.$strip>>;
     proxy: z.ZodOptional<z.ZodObject<{
         https: z.ZodOptional<z.ZodString>;
         http: z.ZodOptional<z.ZodString>;
         noProxy: z.ZodOptional<z.ZodString>;
-    }, "strip", z.ZodTypeAny, {
-        https?: string | undefined;
-        http?: string | undefined;
-        noProxy?: string | undefined;
-    }, {
-        https?: string | undefined;
-        http?: string | undefined;
-        noProxy?: string | undefined;
-    }>>;
-}, "strict", z.ZodTypeAny, {
-    version?: 1 | undefined;
-    allowedProviders?: string[] | undefined;
-    deniedTools?: string[] | undefined;
-    allowedMcpServers?: string[] | undefined;
-    disableBrowser?: boolean | undefined;
-    disableAutonomous?: boolean | undefined;
-    maxCostUsdPerRun?: number | undefined;
-    audit?: {
-        enabled: boolean;
-        file?: string | undefined;
-    } | undefined;
-    proxy?: {
-        https?: string | undefined;
-        http?: string | undefined;
-        noProxy?: string | undefined;
-    } | undefined;
-}, {
-    version?: 1 | undefined;
-    allowedProviders?: string[] | undefined;
-    deniedTools?: string[] | undefined;
-    allowedMcpServers?: string[] | undefined;
-    disableBrowser?: boolean | undefined;
-    disableAutonomous?: boolean | undefined;
-    maxCostUsdPerRun?: number | undefined;
-    audit?: {
-        enabled: boolean;
-        file?: string | undefined;
-    } | undefined;
-    proxy?: {
-        https?: string | undefined;
-        http?: string | undefined;
-        noProxy?: string | undefined;
-    } | undefined;
-}>;
+    }, z.core.$strip>>;
+}, z.core.$strict>;
 export type OrgPolicy = z.infer<typeof policySchema>;
 export declare class PolicyError extends Error {
     constructor(message: string);

package/dist/pricing.d.ts

@@ -24,6 +24,8 @@ export interface ResolvedPricing extends ModelPricing {
     /** True when the lookup hit a known table entry. False when the caller
      * supplied a manual override or when the model id is unknown. */
     known: boolean;
+    /** The table key a substring lookup matched, when it was not an exact hit. */
+    matchedKey?: string;
 }
 /**
  * Look up the pricing for a given model id. Falls back to a substring match

package/dist/pricing.js

@@ -9,6 +9,9 @@ const PRICING = {
     // OpenAI ----------------------------------------------------
     'gpt-4o': { input: 2.5, output: 10 },
     'gpt-4o-mini': { input: 0.15, output: 0.6 },
+    'gpt-4.1': { input: 2, output: 8 },
+    'gpt-4.1-mini': { input: 0.4, output: 1.6 },
+    'gpt-4.1-nano': { input: 0.1, output: 0.4 },
     'gpt-4-turbo': { input: 10, output: 30 },
     'gpt-4': { input: 30, output: 60 },
     'gpt-3.5-turbo': { input: 0.5, output: 1.5 },
@@ -26,7 +29,9 @@ const PRICING = {
     'claude-sonnet-4-5': { input: 3, output: 15 },
     'claude-opus-4': { input: 15, output: 75 },
     'claude-opus-4-1': { input: 15, output: 75 },
+    'claude-opus-4-5': { input: 5, output: 25 },
     'claude-haiku-4': { input: 0.8, output: 4 },
+    'claude-haiku-4-5': { input: 1, output: 5 },
     // Google ----------------------------------------------------
     'gemini-1.5-pro': { input: 1.25, output: 5 },
     'gemini-1.5-flash': { input: 0.075, output: 0.3 },
@@ -35,25 +40,11 @@ const PRICING = {
     'gemini-2.0-flash-lite': { input: 0.025, output: 0.1 },
     'gemini-2.5-pro': { input: 1.25, output: 10 },
     'gemini-2.5-flash': { input: 0.3, output: 2.5 },
-    // Ollama is local: no API cost. We surface this as 0/$0.00 in the UI so
-    // users see the meter running with $0.00 instead of "unpriced" churn.
-    // List a few popular model id prefixes so substring matching resolves them.
-    'llama3.1': { input: 0, output: 0 },
-    'llama3.2': { input: 0, output: 0 },
-    'llama3.3': { input: 0, output: 0 },
-    'qwen2.5': { input: 0, output: 0 },
-    'mistral': { input: 0, output: 0 },
-    'mixtral': { input: 0, output: 0 },
-    'gemma2': { input: 0, output: 0 },
-    'codellama': { input: 0, output: 0 },
-    'deepseek-coder': { input: 0, output: 0 },
-    'phi3': { input: 0, output: 0 },
     // OpenRouter ----------------------------------------------------
     // OpenRouter passes through third-party models. We list the popular ones
     // explicitly; everything else falls back to "unpriced" but still works
     // (cost events just get suppressed). Prices track OpenRouter's published
     // list at the time of writing.
-    'openrouter/auto': { input: 0, output: 0 }, // dynamic routing, unknown
     'anthropic/claude-3.5-sonnet': { input: 3, output: 15 },
     'anthropic/claude-3.5-haiku': { input: 0.8, output: 4 },
     'anthropic/claude-3-opus': { input: 15, output: 75 },
@@ -70,6 +61,30 @@ const PRICING = {
     // MiniMax --------------------------------------------------
     'minimax-m3': { input: 0.3, output: 1.2 },
 };
+/**
+ * Providers that run on the person's own machine. Their models cost nothing
+ * whatever they are called, and only they may be priced at $0: a free entry
+ * keyed by a model name ("mistral") once priced the paid hosted model of the
+ * same name at $0 too, so a cost cap never stopped it.
+ */
+const LOCAL_PROVIDERS = new Set(['ollama', 'lmstudio']);
+/**
+ * Whether `key` names the model `id` at `at`, rather than an older version of
+ * it or part of another word. `claude-opus-4` is inside `claude-opus-4-5` and
+ * `gpt-4` inside `gpt-4.1`, and each once priced the newer model at the older
+ * one's rate. A date (`-20241022`), revision (`-002`), size (`:7b`) or variant
+ * (`-latest`) after the key is still the same model.
+ */
+function namesModelAt(id, key, at) {
+    if (at > 0 && /[a-z0-9]/.test(id[at - 1]))
+        return false;
+    const rest = id.slice(at + key.length);
+    if (rest === '')
+        return true;
+    if (/^[a-z0-9]/.test(rest))
+        return false;
+    return !/^(?:\.\d|-\d{1,2}(?=$|[-.:@_]))/.test(rest);
+}
 /** Provider prompt-cache billing relative to the normal input rate. */
 function cacheMultipliersFor(model) {
     switch (model.provider) {
@@ -103,6 +118,8 @@ export function lookupPricing(model, override) {
     const configured = overrideCost(model);
     if (configured)
         return { ...cache, ...configured, known: true };
+    if (typeof model !== 'string' && LOCAL_PROVIDERS.has(model.provider))
+        return { input: 0, output: 0, known: true };
     const id = (typeof model === 'string' ? model : model.model).toLowerCase();
     // Strip only the OpenRouter-style 'models/' prefix so 'models/gemini-1.5-pro'
     // resolves the same way as 'gemini-1.5-pro'. We do NOT strip provider prefixes
@@ -115,8 +132,10 @@ export function lookupPricing(model, override) {
     // Substring match: longest key wins, so 'gpt-4o-mini' beats 'gpt-4o'.
     const keys = Object.keys(PRICING).sort((a, b) => b.length - a.length);
     for (const key of keys) {
-        if (stripped.includes(key))
-            return { ...PRICING[key], ...cache, known: true };
+        for (let at = stripped.indexOf(key); at !== -1; at = stripped.indexOf(key, at + 1)) {
+            if (namesModelAt(stripped, key, at))
+                return { ...PRICING[key], ...cache, known: true, matchedKey: key };
+        }
     }
     return { input: 0, output: 0, known: false };
 }

package/dist/skills/builtin.js

@@ -51,7 +51,7 @@ ${keys}
 1. Read the file first. If it does not exist, create it with only the keys you are setting.
 2. Change only what was asked. Keep every other key and keep the file valid JSON (double quotes, no trailing commas, no comments).
 3. A secret never goes in a project file. Name an environment variable (\`apiKeyEnv\`) instead of pasting a key.
-4. Do not widen permissions (\`autoApproveTools\`, \`permission\` allow rules, \`autoApproveCommands\`) unless the user asked for exactly that, and say what the change allows.
+4. Do not widen permissions (\`autoApproveTools\`, \`permission\` allow rules, \`autoApproveCommands\`) unless the user named what to allow. A general request such as "make the prompts go away" or "allow everything" names nothing: do not write it, and never grant \`run_command\`, \`write_file\`, \`edit_file\`, \`apply_patch\` or \`sub_agent\` because of it. Say in one sentence why, then offer the narrow forms: allow one named tool, or choose "Always allow" on a specific command when its card appears. When you do widen, say what the change allows.
 5. After saving, say what changed and where. Most changes apply on the next message; \`caCertificates\` and the language need a window reload, MCP servers and skills need \`/reload\`.
 6. Do not run Forge commands that write to the real \`~/.forge\` to test a change. Edit the file and let the user check it.
 `;

package/dist/specs/generate.d.ts

@@ -12,15 +12,24 @@
 import type { SpecSections } from './types.js';
 /** Read-only tools exposed to the model during spec-mode generation. */
 export declare const SPEC_READONLY_TOOLS: readonly string[];
+export declare function splitSpecSections(raw: string): SpecSections;
+/**
+ * The Spec stage's two documents. Returns **only** those two keys: a model that
+ * volunteers a `## tasks.md` section despite being told not to must not be able
+ * to smuggle it into a draft, because the person has not reached the
+ * implementation-plan gate yet.
+ */
+export declare function splitRequirementsDesign(raw: string): {
+    requirements: string;
+    design: string;
+};
 /**
- * Split a spec-mode run's final text into its three sections. Each
- * section is introduced by a `## <file>.md` markdown heading (case-
- * insensitive, arbitrary surrounding whitespace); the body runs until
- * the next matching heading or end of text. Section order in `raw`
- * does not matter.
+ * The ImplPlan stage's single document.
  *
- * Throws when any of the three expected headings is missing: callers
- * should surface this as a generation failure rather than write partial
- * or malformed files.
+ * Throws when the reply holds no task at all: an empty body or a prose-only
+ * "Plan is complete." would otherwise be written by `writeDraftTasks` and then
+ * approved, because `approveDraft` only checks that the file exists — leaving a
+ * spec with nothing to run, which is the very outcome that guard exists to
+ * prevent. Failing generation here sends the journey back to "Revise".
  */
-export declare function splitSpecSections(raw: string): SpecSections;
+export declare function splitTasksSection(raw: string): string;