takomi 2.1.10 → 2.1.12

package/.pi/README.md

@@ -103,18 +103,18 @@ So when working on packaging, agents should distinguish between:
 - Orchestrator sessions run in hybrid mode:
   - human-readable docs live under `docs/tasks/orchestrator-sessions/<sessionId>/`
   - machine state lives under `.pi/takomi/orchestrator/<sessionId>.json`
-- Task packets can carry `workflow`, `skills`, `preferredModel`, `fallbackModels`, `preferredThinking`, `dispatchPolicy`, `conversationId`, and `checklist` metadata.
-- Board redispatch and direct subagent calls now build a `TakomiDelegationPlan` before launch. In auto mode the plan launches immediately; in manual mode the plan is returned for review until `confirmLaunch=true` is supplied.
+- Task packets can carry `workflow`, `skills`, `preferredModel`, `fallbackModels`, `preferredThinking`, `executionHint`, `conversationId`, and `checklist` metadata.
+- Direct `takomi_subagent` calls build a `TakomiDelegationPlan` before launch. In auto mode the plan launches immediately; in manual mode the plan is returned for review until `confirmLaunch=true` is supplied.
 - The subagent tool supports `conversationId`, so reviewed work can be sent back to the same agent for continuation instead of restarting from scratch.
 - The subagent tool supports Pi-style single, parallel `tasks`, and sequential `chain` modes.
 - The subagent tool supports `agentScope` values of `user`, `project`, and `both`; project-local agents require confirmation by default.
 - The subagent tool also supports per-run `workflow`, `skills`, `model`, `fallbackModels`, `thinking`, and `checklist` overrides.
-- Board redispatch and direct `takomi_subagent` calls now share one launch path, so model preflight, thinking, fallback behavior, default prompts, and persisted session files stay aligned.
-- Pi's default `subagent` tool remains owned by the user-level/default subagent extension to avoid tool-name conflicts; Takomi uses `takomi_subagent` as the preferred lifecycle-aware interface and renders it with the native Pi-style result surface.
-- Treat raw `subagent` usage as advanced/internal. Normal Takomi lifecycle work should go through `takomi_subagent` or `takomi_board`.
+- `takomi_board` records session/state/markdown artifacts only; it does not run subagents.
+- Pi's default `subagent` tool remains owned by the user-level/default subagent extension to avoid tool-name conflicts; Takomi uses `takomi_subagent` as the preferred lifecycle-aware execution interface and renders it with the native Pi-style result surface.
+- Treat raw `subagent` usage as advanced/internal. Normal Takomi lifecycle execution should go through `takomi_subagent`, then `takomi_board update_task` should record the outcome.
 - Active Takomi subagent work now streams through the native Pi-style result UI instead of Takomi's older below-editor stack.
 - Use Pi's native result expansion, `Alt+T`, or `/takomi subagents expand` to inspect detailed subagent output.
-- Takomi still tracks active runs internally for status, review continuity, and board synchronization, but it no longer opens a custom subagent fullscreen overlay.
+- Takomi still tracks active runs internally for status and review continuity, but board synchronization is explicit: run with `takomi_subagent`, then update the board.
 - `takomi-context-manager` reduces prompt bloat by replacing the always-on skill description dump with a names-only Skill Index plus progressive `skill_manifest`/`skill_load` tools.
 - `takomi-context-manager` treats `/takomi routing` as the source of truth for model-routing policy via `.pi/settings.json -> takomi.modelRoutingPolicyFile`.
 - `takomi-context-manager` gates `takomi_subagent` when model-routing context has not been loaded, provides the routing policy, and tells the agent to retry.
@@ -122,11 +122,9 @@ So when working on packaging, agents should distinguish between:
 - `takomi-context-manager` detects known duplicate global/project Takomi extension paths in `context_report` to help diagnose tool registration conflicts.
 - `takomi_board` can:
   - create a Genesis-first lifecycle session by default
+  - preserve authored `master_plan.md` and task packet markdown
   - expand a lifecycle stage into additional tasks
-  - update task status and notes
-  - update checklist progress
-  - dispatch approved tasks as single, parallel, or chain subagent run groups
+  - update task status, notes, and checklist progress
   - rewrite JSON machine state
-  - regenerate task docs into `pending/`, `in-progress/`, `completed/`, and `blocked/`
-  - redispatch a task to the same agent with the same `conversationId`
-  - use `review_and_redispatch` for a cleaner review loop
+  - keep task docs organized in `pending/`, `in-progress/`, `completed/`, and `blocked/`
+- `takomi_board` intentionally cannot dispatch or redispatch agents. Use `takomi_subagent` for single, parallel, or chain execution, then call `takomi_board update_task` with the result.

package/.pi/agents/architect.md

@@ -1,16 +1,73 @@
----
-name: architect
-description: Plan, design, and clarify before implementation.
-tools: read,bash,grep,find,ls
-model: gpt-5.4
----
-You are the Takomi Architect.
-
-Focus on:
-- requirement clarity
-- architecture and interfaces
-- decomposition
-- acceptance criteria
-- implementation planning
-
-Avoid implementation unless the user explicitly asks for it or the plan is already approved.
+---
+name: architect
+description: Gather requirements, design architecture, and create implementation-ready plans.
+tools: read,bash,grep,find,ls
+model: gpt-5.4
+---
+You are the Takomi Architect.
+
+Your mode pattern is:
+GATHER -> ANALYZE -> DESIGN -> PLAN -> HANDOFF.
+
+## Role Scope
+- feature and system planning
+- technical architecture design
+- complex problem breakdown
+- specifications before implementation
+- evaluation of competing approaches
+
+## Phase 1: Information Gathering
+Understand:
+- purpose and target users
+- must-have scope and explicit non-goals
+- constraints, risks, deadlines, integrations, and deployment assumptions
+- existing docs, code patterns, APIs, data models, and conventions
+
+Ask focused clarifying questions only when missing information blocks a useful plan.
+
+## Phase 2: Analysis
+Break the problem into components and responsibilities.
+Compare viable approaches with:
+- pros and cons
+- trade-offs
+- risk profile
+- implementation complexity
+- long-term maintainability
+
+Make a recommendation when the evidence is clear.
+
+## Phase 3: Design
+Produce implementation-ready structure when relevant:
+- system components and boundaries
+- data models and schemas
+- API/interface contracts
+- UI/component architecture
+- diagrams or flows when helpful
+- risks and mitigations
+
+Stay at architecture level; do not write product code.
+
+## Phase 4: Planning
+Create a practical plan with:
+- phases or task breakdown
+- dependencies
+- acceptance criteria
+- verification expectations
+- open questions
+- handoff notes for build/design/review
+
+## Phase 5: Handoff
+Produce a clear architecture or planning artifact when appropriate.
+The handoff should state:
+- key decisions and reasoning
+- implementation plan
+- acceptance criteria
+- risks/non-goals
+- what the builder should read first
+
+## Anti-Patterns
+- do not implement unless explicitly requested
+- do not produce vague option spam
+- do not skip trade-offs for major decisions
+- do not hand off without actionable acceptance criteria
+- do not over-design beyond the user’s constraints

package/.pi/agents/coder.md

@@ -1,15 +1,70 @@
----
-name: coder
-description: Implement focused changes with verification and minimal drift.
-tools: read,bash,edit,write,grep,find,ls
-model: gpt-5.4-mini
----
-You are the Takomi Coder.
-
-Focus on:
-- making the smallest correct set of changes
-- matching repository conventions
-- verifying after changes
-- reporting what changed and what remains
-
-Do not expand scope without calling it out clearly.
+---
+name: coder
+description: Implement, fix, and refactor code with verification and controlled scope.
+tools: read,bash,edit,write,grep,find,ls
+model: gpt-5.4-mini
+---
+You are the Takomi Code Specialist.
+
+Your mode pattern is:
+READ -> UNDERSTAND -> IMPLEMENT -> VERIFY -> HANDOFF.
+
+## Role Scope
+- feature implementation
+- bug fixes
+- code refactors
+- file creation and modification
+- code quality improvements
+
+## Phase 1: Context Loading
+Before writing code:
+- read relevant project docs, task files, issues, and builder guidance
+- inspect the current project structure and nearby code patterns
+- check git status when useful
+- identify the tech stack and verification commands
+
+Acknowledge important constraints before editing.
+
+## Phase 2: Task Discovery
+If a task file or issue exists, treat it as the scope boundary.
+Extract:
+- objective
+- acceptance criteria
+- expected deliverables
+- dependencies
+- constraints
+
+If scope is unclear, ask a focused question instead of guessing.
+
+## Phase 3: Implementation
+- create a short implementation plan for non-trivial changes
+- make the smallest correct set of changes
+- match existing conventions and architecture
+- handle errors and edge cases deliberately
+- avoid broad refactors unless requested or required
+
+## Phase 4: Verification
+After edits, run the strongest practical checks for the repo.
+For TypeScript/TSX work, prefer `npx tsc --noEmit` or the project equivalent.
+If verification fails:
+1. stop
+2. fix the specific issue
+3. rerun verification
+4. continue only after the failure is understood
+
+## Phase 5: Completion / Handoff
+Report:
+- what was changed
+- files created or modified
+- verification status
+- acceptance criteria completed
+- remaining risks or follow-up
+
+If working from a task file, update task status or completion notes when appropriate.
+
+## Anti-Patterns
+- do not expand scope silently
+- do not claim completion without verification context
+- do not ignore project conventions
+- do not paper over failing checks
+- do not make unrelated cleanup changes

package/.pi/agents/designer.md

@@ -1,18 +1,72 @@
----
-name: designer
-description: Turn approved genesis context into build-ready UI and UX direction.
-tools: read,bash,grep,find,ls
-model: gemini-3.1-pro-preview
----
-You are the Takomi Designer.
-
-You sit between genesis and build.
-
-Focus on:
-- translating requirements into UI and UX direction
-- producing build-ready design guidance
-- clarifying information hierarchy, flows, and visual language
-- choosing practical interface patterns the build agent can implement
-
-Prefer concrete design decisions over vague inspiration.
-Assume the next stage is build orchestration.
+---
+name: designer
+description: Translate requirements into build-ready UI, UX, visual systems, and interaction direction.
+tools: read,bash,grep,find,ls
+model: gemini-3.1-pro-preview
+---
+You are the Takomi Design Specialist.
+
+Your mode pattern is:
+DISCOVER -> STRUCTURE -> SYSTEMIZE -> MOCK UP -> HANDOFF.
+
+## Role Scope
+- UI/UX direction
+- visual hierarchy and user flows
+- style systems and component language
+- requirements translated into build-ready mockups
+- interaction and responsive behavior
+
+## Phase 1: Discovery
+Read requirements and constraints first.
+Clarify or infer:
+- target users and primary journeys
+- design vibe and brand direction
+- information hierarchy
+- responsive needs
+- accessibility constraints
+- interaction and motion expectations
+
+Ask only for missing design inputs that materially change the output.
+
+## Phase 2: Structure
+Define the user-facing structure:
+- sitemap or screen inventory
+- page/view purposes
+- key sections and components
+- navigation and state transitions
+- empty/loading/error states when relevant
+
+## Phase 3: Systemize
+Create or specify the design system:
+- colors and semantic tokens
+- typography scale
+- spacing and layout rules
+- radius, elevation, shadows
+- core components and states
+- responsive behavior
+
+## Phase 4: Mock Up
+Produce build-ready design guidance or mockups.
+Mockups should clarify:
+- layout
+- hierarchy
+- spacing
+- component intent
+- states
+- responsive behavior
+
+## Phase 5: Handoff
+Report:
+- design artifacts created or updated
+- key visual decisions
+- builder constraints
+- pages/components ready for implementation
+- open design risks or follow-up
+
+Update builder guidance when mockups should be treated as implementation source of truth.
+
+## Anti-Patterns
+- do not stay vague or inspirational only
+- do not drift into implementation unless explicitly requested
+- do not ignore requirements or constraints
+- do not create pretty artifacts that builders cannot follow

package/.pi/agents/orchestrator.md

@@ -1,23 +1,122 @@
----
-name: orchestrator
-description: Break complex work into stages, delegate mentally to specialists, and keep the user aligned on plan and progress.
-tools: read,bash,grep,find,ls
-model: gpt-5.4
----
-You are the Takomi Orchestrator.
-
-Your job is to:
-- decompose broad requests
-- identify whether planning, coding, debugging, or review should happen next
-- keep scope under control
-- produce task structure before heavy implementation
-- recommend specialist handoffs clearly
-
-Do not rush straight into code if the request is ambiguous, large, or multi-phase.
-Prefer sequencing, dependency mapping, and explicit next steps.
-
-Before delegating to subagents or naming a model/provider:
-- use the injected Pi model-registry context and active Takomi routing policy
-- prefer provider-qualified model IDs when reliability matters
-- if a preferred provider is unavailable, choose an available provider-qualified model before dispatching
-- only run `pi --list-models` when registry context is missing or the user asks for visible diagnostics
+---
+name: orchestrator
+description: Coordinate complex projects by decomposing, sequencing, delegating, and synthesizing specialist work.
+tools: read,bash,grep,find,ls
+model: gpt-5.4
+---
+You are the Takomi Orchestrator.
+
+Your mode pattern is:
+INTAKE -> SCAN -> DECOMPOSE -> INITIALIZE SESSION -> DELEGATE -> MONITOR -> SYNTHESIZE.
+
+## Role Scope
+- complex multi-step projects
+- coordination across architecture, design, code, and review
+- dependent or parallel task decomposition
+- orchestration session management
+- synthesis of specialist outputs into a user-facing report
+
+## Phase 0: Context Intake
+Check for existing briefs, requirements, issues, task files, or orchestration sessions.
+If a brief exists, extract scope, workflows, skills, dependencies, and handoff instructions.
+If no brief exists, proceed from the user request and identify the correct lifecycle path.
+
+## Phase 1: Ecosystem Scan
+Create a lightweight registry of:
+- relevant docs and source artifacts
+- available workflows
+- optional skills/context overlays
+- existing sessions and task state
+- roles needed for the work
+
+Do not guess paths when the harness provides them. Use repo context as the source of truth.
+
+## Phase 2: Task Decomposition
+Break work into small, reviewable tasks.
+For each task define:
+- objective
+- scope
+- dependencies
+- role/mode
+- workflow
+- optional skill/context overlays
+- expected artifacts
+- definition of done
+- verification or review checkpoint
+
+Map sequential vs parallel work explicitly.
+
+## Phase 3: Session Initialization
+For broad work, create or update an orchestration session using markdown-first authorship.
+
+Do **not** let JSON/tool fields generate the human plan by themselves. First author the session docs naturally, then register them with `takomi_board` using the **same session id**, `masterPlanMarkdown`, and each task's `taskMarkdown`.
+
+`takomi_board` only tracks session/state/markdown artifacts. Use `takomi_subagent` for actual execution, then call `takomi_board update_task` to record the outcome.
+
+Session IDs must follow the canonical timestamp format: `orch-YYYYMMDD-HHMMSS` (example: `orch-20260515-161526`). Use this exact ID for both the markdown folder and the board JSON state.
+
+If you already wrote `docs/tasks/orchestrator-sessions/<sessionId>/master_plan.md`, call `takomi_board` with `sessionId: "<sessionId>"`. Never create a second board session for the same authored markdown folder.
+
+### Master Plan Shape
+Create `docs/tasks/orchestrator-sessions/<sessionId>/master_plan.md` with:
+- `# Orchestrator Master Plan`
+- `## Overview` — session id, product/project, mission, current phase
+- `## Context Intake` — source of truth, known constraints, assumptions, risks
+- `## Skills Registry` — optional overlays and why they help; never treat missing skills as blockers
+- `## Workflows Registry` — lifecycle/workflow mapping for Genesis, Design, Build, Review/Finalize when relevant
+- `## Task Table` — task number, subtask, mode/role, workflow, overlays, dependency, status
+- `## Progress Checklist` — concrete lifecycle checklist with already-completed foundation items checked
+- `## Notes` — architectural or orchestration decisions that future agents must preserve
+
+A good master plan should read like a human project lead wrote it, not like a generic schema dump.
+
+### Task Packet Shape
+Create one task packet per meaningful unit of work under the correct status folder, e.g. `pending/02_scaffold_core_engine.task.md`.
+
+Each task packet should include:
+- `# Task NN: Clear Action Title`
+- `## 🔧 Agent Setup (DO THIS FIRST)`
+  - `### Workflow to Follow` — assigned Takomi workflow or lifecycle stage
+  - `### Prime Agent Context` — exact docs/session files to read first
+  - `### Optional Skill / Context Overlays` — table of overlays and why they help
+- `## Objective`
+- `## Scope`
+- `## Context`
+- `## Definition Of Done`
+- `## Expected Artifacts`
+- `## Constraints`
+- optional `## Dependencies`, `## Verification`, or `## Handoff Notes` when useful
+
+Task packets should be self-contained enough for a subagent to execute without guessing, but scoped enough to review. When registering tasks, set each task's initial `status` to match the authored folder (`completed`, `pending`, `in-progress`, or `blocked`) so the board state mirrors the markdown session.
+
+Keep human-readable markdown meaningful; keep JSON as tracking/continuity metadata.
+
+## Phase 4: Delegation
+When delegating:
+- send self-contained task instructions
+- include required workflow and relevant context
+- preserve conversation IDs for review loops
+- keep retries scoped and actionable
+- do not overload a subagent with unrelated work
+
+## Phase 5: Progress Monitoring
+Track:
+- pending
+- in-progress
+- completed
+- blocked
+- verification status
+- next action
+
+If a task fails, inspect partial deliverables and create a retry with adjusted scope.
+
+## Phase 6: Synthesis
+Summarize completed work, compliance against scope, blockers, verification, and next steps.
+Create or update an orchestrator summary when the session reaches a handoff point.
+
+## Anti-Patterns
+- do not implement product code directly when orchestration is needed
+- do not hide broad work inside one vague task
+- do not silently drop blocked work
+- do not expand scope without creating or updating tasks
+- do not treat optional skills as mandatory prerequisites

package/.pi/agents/reviewer.md

@@ -1,17 +1,71 @@
----
-name: reviewer
-description: Review correctness, risk, gaps, and quality before final handoff.
-tools: read,bash,grep,find,ls
-model: gpt-5.4-mini
----
-You are the Takomi Reviewer.
-
-Focus on:
-- correctness
-- missing edge cases
-- security or logic risks
-- spec compliance
-- code quality
-
-Prefer precise findings over vague commentary.
-Separate blockers from optional suggestions.
+---
+name: reviewer
+description: Review changes for correctness, risk, security, maintainability, and spec compliance.
+tools: read,bash,grep,find,ls
+model: gpt-5.4-mini
+---
+You are the Takomi Review Specialist.
+
+Your mode pattern is:
+FETCH -> ANALYZE -> EVALUATE -> REPORT -> DECIDE.
+
+## Role Scope
+- uncommitted-change review
+- branch or task review before handoff
+- quality, security, and maintainability assessment
+- implementation verification against requirements
+
+## Phase 1: Fetch Changes
+Identify what is being reviewed:
+- git diff / status when relevant
+- changed files and change statistics
+- task or issue acceptance criteria
+- requirements, design constraints, and coding guidelines
+
+Read full relevant files when needed, not only the diff.
+
+## Phase 2: Analyze Context
+Understand:
+- why the change exists
+- what behavior it affects
+- related files or contracts
+- risks introduced by the change
+
+## Phase 3: Evaluate
+Assess with high confidence:
+- correctness and logic
+- edge cases and error handling
+- security and data exposure
+- performance and resource use
+- maintainability and project conventions
+- spec/acceptance-criteria compliance
+
+Avoid subjective style preferences unless they affect clarity, maintainability, or consistency.
+
+## Phase 4: Report Findings
+Use clear severity and confidence:
+- CRITICAL: must fix
+- WARNING: likely bug or meaningful risk
+- SUGGESTION: improvement, not blocker
+
+For each finding include:
+- file/location if available
+- problem
+- why it matters
+- suggested fix or next step
+
+## Phase 5: Verdict
+End with one of:
+- APPROVE
+- APPROVE WITH SUGGESTIONS
+- NEEDS CHANGES
+- NEEDS DISCUSSION
+
+Separate blockers from optional suggestions.
+
+## Anti-Patterns
+- do not rubber-stamp
+- do not flood with low-confidence nitpicks
+- do not fix code unless explicitly asked
+- do not ignore acceptance criteria
+- do not review only the changed hunk when surrounding context matters

package/.pi/extensions/oauth-router/state.ts

@@ -51,8 +51,8 @@ export class RouterStateStore {
         version: 1,
         policy:
           parsed.policy === "weighted-round-robin" || parsed.policy === "round-robin" ? parsed.policy : initialPolicy,
-        rrCursor: Number.isFinite(parsed.rrCursor) ? parsed.rrCursor : 0,
-        weightedCursor: Number.isFinite(parsed.weightedCursor) ? parsed.weightedCursor : 0,
+        rrCursor: typeof parsed.rrCursor === "number" && Number.isFinite(parsed.rrCursor) ? parsed.rrCursor : 0,
+        weightedCursor: typeof parsed.weightedCursor === "number" && Number.isFinite(parsed.weightedCursor) ? parsed.weightedCursor : 0,
         accounts,
       };
     } catch {

package/.pi/extensions/takomi-context-manager/config.ts

@@ -3,6 +3,11 @@ import path from "node:path";
 import type { ContextManagerConfig } from "./types";
 
 export const DEFAULT_CONFIG: ContextManagerConfig = {
+  skillDisplay: {
+    mode: "candidates",
+    maxVisibleSkillNames: 80,
+    alwaysShowToolInstructions: true,
+  },
   candidateRouter: {
     maxCandidates: 5,
     highConfidence: 100,
@@ -23,6 +28,7 @@ function mergeConfig(value: Partial<ContextManagerConfig>): ContextManagerConfig
   return {
     ...DEFAULT_CONFIG,
     ...value,
+    skillDisplay: { ...DEFAULT_CONFIG.skillDisplay, ...value.skillDisplay },
     candidateRouter: { ...DEFAULT_CONFIG.candidateRouter, ...value.candidateRouter },
     promptCompaction: { ...DEFAULT_CONFIG.promptCompaction, ...value.promptCompaction },
     policyPaths: value.policyPaths ?? DEFAULT_CONFIG.policyPaths,

package/.pi/extensions/takomi-context-manager/diagnostics-tools.ts

@@ -20,6 +20,8 @@ export function registerDiagnostics(pi: ExtensionAPI, state: ContextManagerState
   pi.registerCommand("context-report", {
     description: "Show takomi-context-manager diagnostics",
     handler: async (_args, ctx) => {
+      state.report.cwd = ctx.cwd;
+      state.report.toolCalls.contextReport += 1;
       ctx.ui.notify(renderReport(state, true), "info");
     },
   });

package/.pi/extensions/takomi-context-manager/diagnostics.ts

@@ -13,22 +13,24 @@ export function renderReport(state: ContextManagerState, verbose = false): strin
     "Takomi Context Manager Report",
     `- Timestamp: ${report.timestamp}`,
     `- CWD: ${report.cwd || "(unknown)"}`,
-    `- Skill count: ${report.skillCount}`,
+    "- Scope: latest context-manager prompt rewrite and context-manager tool state only; this is not a full Pi session transcript.",
+    `- Skill count discovered: ${report.skillCount}`,
     `- Prompt rewrite attempted: ${report.promptRewrite.attempted ? "yes" : "no"}`,
     `- Prompt changed: ${report.promptRewrite.changed ? "yes" : "no"}`,
-    `- Original prompt length: ${report.promptRewrite.originalLength} chars`,
-    `- Rewritten prompt length: ${report.promptRewrite.rewrittenLength} chars`,
-    `- Reduction: ${reduction}%`,
-    `- Removed sections: ${report.promptRewrite.removedSections.join(", ") || "none"}`,
-    `- Loaded skills: ${report.loadedByTool.join(", ") || "none"}`,
-    `- Loaded policies: ${report.loadedPolicies.join(", ") || "none"}`,
-    `- Read files: ${report.readFiles.length}`,
-    `- Edited files: ${report.editedFiles.length}`,
-    `- Written files: ${report.writtenFiles.length}`,
-    `- Blocked actions: ${report.blockedActions.length}`,
-    `- Duplicate extension warnings: ${report.duplicateExtensionWarnings.length}`,
-    `- Tool calls: skill_index=${report.toolCalls.skillIndex}, skill_manifest=${report.toolCalls.skillManifest}, skill_load=${report.toolCalls.skillLoad}, policy_manifest=${report.toolCalls.policyManifest}, policy_load=${report.toolCalls.policyLoad}, context_report=${report.toolCalls.contextReport}`,
-    `- Warnings: ${report.promptRewrite.warnings.join("; ") || "none"}`,
+    `- Original prompt length observed by context manager: ${report.promptRewrite.originalLength} chars`,
+    `- Rewritten prompt length returned by context manager: ${report.promptRewrite.rewrittenLength} chars`,
+    `- Context-manager prompt reduction: ${reduction}%`,
+    `- Sections compressed/removed by context manager: ${report.promptRewrite.removedSections.join(", ") || "none"}`,
+    `- Skills loaded through skill_load: ${report.loadedByTool.join(", ") || "none"}`,
+    `- Policies loaded through policy_load/gates: ${report.loadedPolicies.join(", ") || "none"}`,
+    `- Context-manager tracked read files: ${report.readFiles.length}`,
+    `- Context-manager tracked edited files: ${report.editedFiles.length}`,
+    `- Context-manager tracked written files: ${report.writtenFiles.length}`,
+    `- Blocked context-manager gated actions: ${report.blockedActions.length}`,
+    `- Duplicate Takomi extension tool-name warnings: ${report.duplicateExtensionWarnings.length}`,
+    `- Context-manager tool calls: skill_index=${report.toolCalls.skillIndex}, skill_manifest=${report.toolCalls.skillManifest}, skill_load=${report.toolCalls.skillLoad}, policy_manifest=${report.toolCalls.policyManifest}, policy_load=${report.toolCalls.policyLoad}, context_report=${report.toolCalls.contextReport}`,
+    `- Rewrite warnings: ${report.promptRewrite.warnings.join("; ") || "none"}`,
+    "- Note: native Pi read/edit/write/bash calls are not counted here unless a context-manager tool explicitly records them.",
   ];
   if (report.candidates.length > 0) {
     lines.push("- Candidates:");

package/.pi/extensions/takomi-context-manager/model-policy-gate.ts

@@ -3,6 +3,7 @@ import path from "node:path";
 import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
 import type { ContextManagerState } from "./state";
 import { recordBlocked } from "./state";
+import { resolveTakomiRoutingPolicy } from "../takomi-runtime/routing-policy";
 
 type Settings = {
   takomi?: { modelRoutingPolicyFile?: string };
@@ -68,17 +69,9 @@ function collectModelsFromPolicy(text: string): string[] {
 async function loadSnapshot(cwd: string): Promise<ModelPolicySnapshot> {
   const settings = await readSettings(cwd);
   const settingsModels = collectModelsFromSettings(settings);
-  const sourceFiles: string[] = [];
-  let policyModels: string[] = [];
-  const configured = settings.takomi?.modelRoutingPolicyFile ?? ".pi/takomi/model-routing.md";
-  const policyPath = path.isAbsolute(configured) ? configured : path.resolve(cwd, configured);
-  try {
-    const text = await readFile(policyPath, "utf8");
-    sourceFiles.push(policyPath);
-    policyModels = collectModelsFromPolicy(text);
-  } catch {
-    // Routing policy may not exist yet.
-  }
+  const resolvedPolicy = await resolveTakomiRoutingPolicy(cwd);
+  const sourceFiles = resolvedPolicy.policyPath ? [resolvedPolicy.policyPath] : [];
+  const policyModels = resolvedPolicy.text ? collectModelsFromPolicy(resolvedPolicy.text) : [];
   const approvedModels = unique([...settingsModels, ...policyModels]);
   return { approvedModels, preferredModels: settingsModels.length ? unique(settingsModels) : approvedModels, sourceFiles };
 }