takomi 2.1.36 → 2.1.38

package/.pi/extensions/takomi-subagents/pi-subagents-engine.ts

@@ -54,7 +54,8 @@ function createState(): SubagentState {
   };
 }
 
-function resolveMode(params: TakomiSubagentToolParams): "single" | "parallel" | "chain" | undefined {
+function resolveMode(params: TakomiSubagentToolParams): "single" | "parallel" | "chain" | "action" | undefined {
+  if (params.action) return "action";
   const hasChain = Boolean(params.chain?.length);
   const hasParallel = Boolean(params.tasks?.length);
   const hasSingle = Boolean(params.agent && params.task);
@@ -205,13 +206,27 @@ function toSubagentParams(params: TakomiSubagentToolParams, rootCwd: string, dis
   const base = {
     agentScope: params.agentScope ?? "both",
     cwd: rootCwd,
-    context: "fresh" as const,
-    async: false,
+    ...(params.context ? { context: params.context } : {}),
+    ...(params.async !== undefined ? { async: params.async } : {}),
+    ...(params.concurrency !== undefined ? { concurrency: params.concurrency } : {}),
+    ...(params.worktree !== undefined ? { worktree: params.worktree } : {}),
     clarify: params.clarify === true,
     includeProgress: true,
     sessionDir: stableConversationSessionDir(rootCwd, tasks),
   };
 
+  if (mode === "action") {
+    return {
+      ...base,
+      action: params.action,
+      agent: params.agent,
+      chainName: params.chainName,
+      id: params.id,
+      message: params.message,
+      index: params.index,
+    };
+  }
+
   if (mode === "single") {
     const task = tasks[0]!;
     const mapped = mapSingleTask(task, names, rootCwd);

package/.pi/extensions/takomi-subagents/tool-runner.ts

@@ -25,11 +25,20 @@ export type TakomiSubagentToolTask = {
 };
 
 export type TakomiSubagentToolParams = Partial<TakomiSubagentToolTask> & {
+  action?: "list" | "get" | "models" | "status" | "interrupt" | "resume" | "doctor";
   tasks?: TakomiSubagentToolTask[];
   chain?: TakomiSubagentToolTask[];
   confirmLaunch?: boolean;
   previewOnly?: boolean;
   clarify?: boolean;
+  context?: "fresh" | "fork";
+  async?: boolean;
+  concurrency?: number;
+  worktree?: boolean;
+  id?: string;
+  message?: string;
+  index?: number;
+  chainName?: string;
   agentScope?: TakomiAgentScope;
 };
 
@@ -247,6 +256,32 @@ export async function executeTakomiSubagentTool(
   const profile = await loadTakomiProfile(rootCwd);
   const runtimeLaunchMode = readRuntimeLaunchMode(ctx);
   const agentScope = params.agentScope ?? "both";
+
+  if (params.action) {
+    try {
+      const nativeResult: any = await engine.execute(
+        "takomi-tool",
+        { ...params, cwd: rootCwd, agentScope },
+        signal,
+        onUpdate as any,
+        ctx,
+      );
+      return {
+        ...nativeResult,
+        details: {
+          ...(nativeResult?.details ?? {}),
+          takomi: {
+            action: params.action,
+            agentScope,
+          },
+        },
+      };
+    } catch (error) {
+      const message = error instanceof Error ? error.message : String(error);
+      return textResult(message, { results: [], action: params.action, agentScope }, true);
+    }
+  }
+
   const agents = discoverTakomiAgents(rootCwd, agentScope);
   const byName = new Map<string, TakomiAgentConfig>(agents.map((agent) => [agent.name, agent]));
   const mode = resolveMode(params);
@@ -328,10 +363,10 @@ export async function executeTakomiSubagentTool(
   }
   try {
     const nativeParams: TakomiSubagentToolParams = mode === "single"
-      ? { ...params, ...tasks[0]!, agentScope }
+      ? { ...params, ...tasks[0]!, cwd: rootCwd, agentScope }
       : mode === "parallel"
-        ? { ...params, tasks, agentScope }
-        : { ...params, chain: tasks, agentScope };
+        ? { ...params, cwd: rootCwd, tasks, agentScope }
+        : { ...params, cwd: rootCwd, chain: tasks, agentScope };
 
     const nativeResult: any = await engine.execute(
       "takomi-tool",

package/.pi/prompts/takomi-prompt.md

@@ -16,9 +16,11 @@ Always-on Takomi behavior.
 - Do not blend architecture, design, and implementation sloppily.
 - When the right path is clear, make a recommendation instead of hedging.
 - For broad work, Genesis may create the orchestration session that carries work into later stages.
-- Orchestration sessions use canonical timestamp IDs: `orch-YYYYMMDD-HHMMSS`.
-- Orchestration sessions are markdown-first: author `master_plan.md` and task packets first, then call `takomi_board` with the same `sessionId`, `masterPlanMarkdown`, task `taskMarkdown`, and matching task statuses. Do not create a second board session for already-authored session docs.
-- `takomi_board` never runs subagents. Use `takomi_subagent` for execution, then come back to `takomi_board update_task` to record results.
+- Orchestration sessions use canonical timestamp IDs: `orch-YYYYMMDD-HHMMSS`.
+- Orchestration sessions are markdown-first: author `master_plan.md` and task packets first, then call `takomi_board` with the same `sessionId`, `masterPlanMarkdown`, task `taskMarkdown`, and matching task statuses. Do not create a second board session for already-authored session docs.
+- `takomi_board` never runs subagents. Use `takomi_subagent` for execution, then come back to `takomi_board update_task` to record results.
+- When Takomi creates subtasks, roadbook tasks, or an orchestration session, delegation is the default next step: implementer `takomi_subagent`, reviewer `takomi_subagent`, then main-agent synthesis and board update.
+- Preserve direct execution for small clear work and explicit user overrides such as "do it yourself", "no subagents", "no new threads", or `/takomi subagents off`.
 
 ## Shared Mode Pattern
 - Load context before acting.
@@ -57,5 +59,5 @@ Before using `takomi_subagent`, setting a model override, or naming a provider/m
 - Design for sitemap, design system, mockups, and visual direction
 - Build for implementation, verification, and handoff
 - Review for audits, QA, or high-risk changes
-- Orchestration for broad, multi-step, or delegated work
+- Orchestration for broad, multi-step, or delegated work
 

package/.pi/takomi/policies/subagent-routing.md

@@ -1,6 +1,14 @@
 # Subagent Routing Policy
 
-Use subagents when delegation reduces risk, improves parallelism, or provides specialist review. Do not delegate small direct tasks just because the tool exists.
+Once Takomi decomposes work into subtasks, roadbook tasks, or an orchestration session, use subagents by default. The main agent should coordinate, synthesize, update the board, and hand off to the user rather than acting as the primary implementer.
+
+Do not delegate small direct tasks just because the tool exists. Direct execution is also allowed when the user says "do it yourself", "no subagents", "no new threads", disables subagents with `/takomi subagents off`, or the required delegation tooling is unavailable.
+
+Default decomposed-work loop:
+
+1. Send implementation to an implementer `takomi_subagent`.
+2. Send the result to a separate reviewer `takomi_subagent`.
+3. Let the main orchestrator synthesize, update the roadbook/board, and accept or redispatch.
 
 Before calling `takomi_subagent`:
 

package/.pi/takomi/policies/takomi-lifecycle-routing.md

@@ -2,6 +2,8 @@
 
 Default to direct execution for small, clear tasks. Use Takomi lifecycle when scope is large, unclear, risky, multi-file, architecture-heavy, or benefits from durable artifacts.
 
+When lifecycle routing creates subtasks, roadbook tasks, or an orchestration session, execution becomes delegation-first by default. The main agent remains responsible for context, sequencing, synthesis, board updates, acceptance, redispatch, and final user handoff.
+
 Lifecycle:
 
 1. Genesis: mission, constraints, requirements, issues, verification foundation.
@@ -9,4 +11,4 @@ Lifecycle:
 3. Build: focused implementation tasks with verification.
 4. Review/Finalize: regression, quality, docs, handoff.
 
-Broad/meta-system projects must be decomposed into meaningful tasks. A single-task Genesis requires explicit justification.
+Broad/meta-system projects must be decomposed into meaningful tasks. Decomposed broad work should not be executed primarily by the parent agent unless the user explicitly says "do it yourself", "no subagents", "no new threads", or otherwise opts out. A single-task Genesis requires explicit justification.

package/README.md

@@ -50,6 +50,8 @@ Legacy commands like `takomi install pi`, `takomi sync pi`, `takomi upgrade`, an
 
 During `takomi setup pi` or `takomi setup pi-features`, Takomi offers optional Pi feature packs with recommended/manual/select-all/skip choices. Current defaults install **Takomi Interview** (`npm:@juicesharp/rpiv-ask-user-question`) so models can ask structured clarification questions. **Takomi Todo** (`npm:@juicesharp/rpiv-todo`), **Takomi Browser QA** (`npm:pi-chrome`), and **Takomi Doc Preview** (`npm:pi-markdown-preview`) remain opt-in. `takomi refresh` runs Pi's package updater so installed optional, custom, old, and new Pi packages are reconciled together.
 
+Takomi keeps `pi-subagents` installed as an internal runtime module, but setup/refresh now detects legacy raw Pi subagent activation (`npm:pi-subagents` in Pi settings or `~/.pi/agent/extensions/subagent`) and offers to disable it so models see `takomi_subagent` instead of two competing subagent tools.
+
 ### Context Manager
 
 Takomi now ships a Pi-native `takomi-context-manager` extension. It reduces prompt bloat with progressive context loading:
@@ -60,6 +62,7 @@ Takomi now ships a Pi-native `takomi-context-manager` extension. It reduces prom
 - `takomi_subagent` is guarded by routing-policy context and can recover from wrong-provider model choices
 - `/context-report` shows prompt compaction, loaded skills/policies, blocked actions, model-routing corrections, and duplicate extension diagnostics
 
+`context_report` is context-manager-specific rather than a clone of Pi's Alt-C window. It restores its own hidden snapshots and Pi tool-result history after `/reload`/restart, and labels any remaining gaps instead of reporting fresh in-memory zeros as session truth. It supports `mode: "summary" | "verbose" | "problems"`; `verbose: true` remains a compatibility alias for `mode: "verbose"`. The `/context-report` slash command supports argument completions for `summary`, `verbose`, and `problems`.
 
 ### Option A: Global Install (Best for Multi-IDE Users) ⭐
 
@@ -112,17 +115,25 @@ run vibe genesis
 continue build with takomi
 ```
 
-Install the Takomi protocol suite:
-
-```bash
-npx -y skills add https://github.com/JStaRFilms/VibeCode-Protocol-Suite --skill takomi
-```
-
-Original Takomi-authored skills in this bundle include `21st-dev-components`, `takomi`, `global-brand-namer`, `jstar-reviewer`, and the core VibeCode/Takomi workflow skills that ship with the CLI.
-
----
-
-## 📦 Skill Ecosystem
+Install the Takomi protocol suite:
+
+```bash
+npx -y skills add https://github.com/JStaRFilms/VibeCode-Protocol-Suite --skill takomi
+```
+
+Original Takomi-authored skills in this bundle include `21st-dev-components`, `takomi`, `global-brand-namer`, `jstar-reviewer`, and the core VibeCode/Takomi workflow skills that ship with the CLI.
+
+### Codex Plugin Quick Start
+
+For the newer repo-local Codex plugin path, enable `takomi-codex` from `.agents/plugins/marketplace.json`. That marketplace entry points Codex at `./plugins/takomi-codex`, which includes plugin metadata, the `takomi-codex` skill, and local verification scripts.
+
+This plugin path is distinct from `skills add --skill takomi`, which installs the older global Takomi skill. Use natural language such as `use takomi-codex to inspect this repo`, `use Takomi to plan this feature`, or `create a Takomi roadbook for this work`.
+
+See [Takomi Codex Onboarding](docs/takomi-codex-onboarding.md) for activation, first-run verification, policy loading, roadbooks, dry-run dispatch, no-Pi fallback, and troubleshooting.
+
+---
+
+## 📦 Skill Ecosystem
 
 Think of skills as specialized team members you can summon on demand. From security audits to AI video generation — there's a skill for that.
 

package/assets/.agent/skills/exam-creator-skill/SKILL.md

@@ -0,0 +1,182 @@
+---
+name: exam-creator-skill
+description: Creates and revises school exam papers using Johno's preferred workflow. Use for JSS/Primary exam generation, remixing questions from lesson notes or chat transcripts, building question papers plus marking schemes, creating assets folders for diagrams, applying the 40-mark house style, producing compact DOCX output, and running draft/marking/verification passes with room for user feedback and revisions.
+---
+
+# Exam Creator Skill
+
+Use this skill when building or revising school exam papers, especially for OBHIS / Olive Blessed Crest Academy.
+
+See the detailed house rules in [references/workflow-rulebook.md](references/workflow-rulebook.md).
+See the model routing policy in [references/model-routing-policy.md](references/model-routing-policy.md).
+
+## Core Principle
+
+Follow the user's house style by default, but always leave room for correction. If the user gives a new rule, prefer the new rule and update the working assumptions before generating more papers.
+
+Terminology rule: when the user says **Gemini**, treat that as **Gemini via the agy CLI** unless the user explicitly says otherwise.
+
+## Default Workflow
+
+1. **Identify the subject, class, term, and destination folder.**
+2. **Collect the authority material**:
+   - lesson notes
+   - ChatGPT transcripts
+   - sample exam layout if provided
+   - photographed handwritten pages, when provided
+3. **For photographed handwritten pages, extract with multimodal vision first**:
+   - use a multimodal model/subagent to read the image directly
+   - batch images in small ordered groups, usually 3-5 images per extraction task
+   - explicitly forbid OCR/Tesseract/Python preprocessing on the first pass unless the model is not multimodal
+   - use OCR only as fallback when direct model vision is unavailable or fails on a specific page
+   - preserve image filename/page references for every uncertain item
+4. **Confirm the paper pattern before drafting** if any of these are unclear:
+   - subject family (Mathematics/English vs other subjects)
+   - mark split
+   - question counts
+   - whether theory is answer-all or answer-any
+5. **Create or reuse clean folders**:
+   - `Questions/`
+   - `Marking Scheme/` only when requested
+   - `Questions/assets/` for all generated SVG/PNG/image diagrams
+6. **Draft the paper first.**
+7. **Create the marking scheme second only when requested.**
+8. **Run an independent verification pass third.**
+9. **Apply user feedback and rerender** instead of defending the first draft.
+
+## Preferred Multi-Agent Pattern
+
+Default model split:
+- orchestrator: parent assistant
+- drafting: Gemini via agy CLI by default, escalate to GPT 5.4 High when the paper is tricky
+- marking: Gemini via agy CLI
+- verification: GPT
+
+When subagents are available, use this split:
+
+- **Drafting agent**: creates the paper and diagram assets.
+- **Marking agent**: creates the marking scheme and validates every objective answer.
+- **Review agent**: independently rechecks answers, numbering, marks, wording, and diagram correctness.
+
+If subagents are not available, still preserve the same three-pass logic manually.
+
+## House Rules To Hardcode
+
+### 1) Marks and paper shape
+
+#### Mathematics and English
+Use this as the default unless the user overrides it:
+
+- total exam score: **40 marks**
+- **50 objective questions**
+- each objective = **1/2 mark**
+- objective total = **25 marks**
+- **5 theory questions**
+- student answers **any 3**
+- theory total = **15 marks**
+- no separate Section B short-answer block unless the user explicitly asks for one
+
+#### Other subjects
+Default assumption:
+
+- still over **40 marks** total
+- can include open-ended plus theory sections
+- if the exact split is not stated, ask before finalizing
+
+Never silently reuse the old 100-mark structure unless the user explicitly asks for it.
+
+### 2) Layout rules
+
+For the final paper DOCX, prefer:
+
+- **Times New Roman**
+- use one font size consistently within a paper; **start with 14 pt** and only reduce it if layout pressure makes it necessary
+- narrow margins
+- every exam header should include, in this order where possible: school name, academic session, term/exam title, pupil name/date line, examination number/time line, class, arm, subject, and instructions
+- header must be **1-column**
+- body should be **1-column by default**; use 2-column or 3-column only when it genuinely improves fit for dense objective papers
+- do not apply a multi-column body just because the skill mentions compact layout; use judgment per subject
+- bold black headings instead of oversized decorative headings
+- objective options must start on the **same line as the question** whenever possible; keep them inline with about 3 spaces between choices, not vertically stacked unless unavoidable
+- if the paper looks like it will run to **3 pages**, try a **2-column or 3-column body layout** before reducing the font size; use judgment based on content density
+- preserve the school name and student-detail heading fields from the source, or leave clear blanks/placeholders if they are not provided
+- if the source uses an arm/stream/class line, keep it but do not hardcode labels like `Arm:` unless the source explicitly requires them
+- when using separate header/body sections in DOCX, make the body section **continuous** so it does not jump to a new page
+- avoid hard page breaks between the heading block and the paper body unless the user explicitly asks for a new page
+- remove explicit `Total Marks: ...` header line unless requested
+- target about **2 pages** per paper where practical
+
+### 3) Diagram and image rules
+
+- Keep all generated figures inside `Questions/assets/`.
+- Choose the diagram method by complexity:
+  - simple geometric/line diagrams, tables, clocks, arrows, and labels: SVG first; generate PNG copies if DOCX rendering needs them
+  - pictorial objects for young pupils, e.g. mango, pot, bucket, moon, table, cup, house, animals, people, classroom objects: prefer Anti-Gravity image generation or another image-generation path, then place the generated PNG/JPG in `Questions/assets/`
+  - hybrid diagrams: combine clean SVG labels/structure with generated image assets when useful
+- When using Anti-Gravity for diagrams, explicitly tell it whether to generate images, use SVG, or use a hybrid method, and require it to report which method was used.
+- Never include the teacher's written answer labels in student-facing diagrams. If the source labels a keyboard as "Keyboard" or groups division answers for marking guidance, remove that answer/label from the final exam.
+- Keep diagrams separated when the source has separate question items or separate objects that must be arranged on the paper. Do not combine unrelated drawings into one asset just for convenience; combine only when the source/question explicitly presents them as one group.
+- Preserve the source question order for diagram-heavy nursery/primary papers by rebuilding from the original images, not only from extraction summaries.
+- If an item asks pupils to colour an object or flag, do not colour it in the exam; provide an outline only unless the instruction asks for a sample.
+- Keep angle labels and vertex labels clearly visible for geometry.
+- Avoid placing numbers directly on triangle edges.
+- If labels are cramped, move them outward and add white-backed label boxes if needed.
+
+### 4) Feedback loop
+
+After each significant draft:
+
+- expect user corrections
+- revise quickly
+- update the source files and rerender the DOCX
+- if the DOCX is locked/open, save a `v2` file rather than failing the task
+
+## Output Expectations
+
+For each subject batch, try to maintain:
+
+- editable paper source, usually `questions.md`
+- concise support/source metadata if useful
+- final DOCX for the paper
+- marking scheme source
+- final DOCX for the marking scheme when requested
+- objective-validation notes
+- verification report
+- all diagrams in `Questions/assets/`
+
+## Authoring Guidance
+
+- Keep questions standard and school-appropriate.
+- Remix questions reasonably from the provided curriculum material.
+- Stay within the authority source unless the user allows expansion.
+- Make objective questions unambiguous.
+- Do not leak answers from teacher notes, source annotations, labels, grouped examples, or marking cues into the student-facing paper.
+- For handwritten sources, try hard to infer unclear words from context, subject vocabulary, options, and neighboring pages before marking `[unclear]`.
+- If uncertainty remains, create a user-review list with image filename/page number, question number, cropped/quoted context if possible, and the competing interpretations. Ask the user instead of leaving unexplained uncertainty in the final paper.
+- Ensure the marking scheme matches final numbering exactly when a marking scheme is requested.
+- For diagrams, refer to them consistently as Diagram A, B, C, etc.
+
+## Required Clarifications
+
+Ask the user before proceeding when any of the following is missing:
+
+- subject
+- class level
+- authority source
+- sample layout path if layout matching matters
+- exact marks pattern for non-Math/non-English subjects
+- desired final format if not obvious
+- final interpretation of handwritten items that remain ambiguous after a multimodal-first extraction pass and contextual inference
+
+## Safe Revision Rules
+
+When updating an already-generated paper:
+
+1. revise the editable source first
+2. revise the marking scheme next if numbering/marks changed
+3. rerun validation/verification if answers, wording, or diagrams changed
+4. rerender DOCX last
+
+## Reference
+
+Load and follow [references/workflow-rulebook.md](references/workflow-rulebook.md) when you need the exact house style details.

package/assets/.agent/skills/exam-creator-skill/references/model-routing-policy.md

@@ -0,0 +1,48 @@
+# Exam Creator Model Routing Policy
+
+Use this routing policy for the exam-creation workflow unless the user overrides it.
+
+## Terminology Rule
+
+When the user says **Gemini**, interpret that as **Gemini via the agy CLI** unless the user explicitly says otherwise.
+
+## Default Routing
+
+- **Orchestrator:** parent assistant / orchestrator
+- **Drafting agent:** **Gemini via agy CLI**
+- **Marking agent:** **Gemini via agy CLI**
+- **Verification agent:** **GPT**
+
+## Why This Is The Default
+
+- Drafting and marking are the highest-volume steps.
+- Gemini is preferred there because it is cheaper and faster.
+- Verification is the quality gate, so GPT is preferred for the final correctness check.
+
+## Escalation Rule For Drafting
+
+Upgrade the **drafting agent** from Gemini via agy CLI to **GPT 5.4 High** when any of these are true:
+
+- the source notes are messy or inconsistent
+- the subject requires tighter wording judgment
+- ambiguity risk is high
+- the diagram/question structure is more delicate than usual
+- the paper is Mathematics or English and extra care is desired
+
+## Practical Modes
+
+### Default cheap/fast mode
+- Orchestrator → parent assistant
+- Drafting → Gemini via agy CLI
+- Marking → Gemini via agy CLI
+- Verification → GPT
+
+### Escalated drafting mode
+- Orchestrator → parent assistant
+- Drafting → GPT 5.4 High
+- Marking → Gemini via agy CLI
+- Verification → GPT
+
+## Guiding Principle
+
+Use **Gemini via agy CLI for drafting and marking by default**, **GPT for verification**, and only upgrade drafting to **GPT 5.4 High** when the paper is tricky enough to justify the extra cost.

package/assets/.agent/skills/exam-creator-skill/references/workflow-rulebook.md

@@ -0,0 +1,115 @@
+# OBHIS Exam Workflow Rulebook
+
+This reference captures the current house style agreed during the Mathematics paper workflow.
+
+## Scope
+
+Use this rulebook for OBHIS / Olive Blessed Crest Academy exam generation unless the user gives a newer rule.
+
+## Terminology Rule
+
+When the user says **Gemini**, interpret that as **Gemini via the agy CLI** unless the user explicitly says otherwise.
+
+## Workflow Summary
+
+1. Gather source materials.
+2. For photographed handwritten pages, run a multimodal-first extraction pass before OCR:
+   - use direct model vision on the image files
+   - batch images in small ordered groups, usually 3-5 images per model task
+   - explicitly forbid OCR/Tesseract/Python preprocessing on the first pass
+   - use OCR only as fallback when direct vision is unavailable or fails for a specific page
+3. Confirm subject-specific mark pattern.
+4. Create clean folder structure.
+5. Draft question paper.
+6. Build marking scheme only when requested.
+7. Independently verify.
+8. Incorporate user feedback.
+9. Rerender deliverables.
+
+## Folder Structure
+
+Preferred output structure:
+
+- `Questions/`
+  - `questions.md`
+  - final exam `.docx`
+  - `assets/`
+    - all SVG diagrams
+    - all PNG diagram copies used for Word export
+- `Marking Scheme/` only when requested
+  - `marking-scheme.md`
+  - `objective-validation.md`
+  - `verification-report.md`
+  - marking-scheme `.docx` if needed
+
+## Subject Rules
+
+### Mathematics and English
+
+Default pattern:
+
+- exam total = **40 marks**
+- objective count = **50**
+- objective marks = **0.5 each**
+- objective total = **25 marks**
+- theory questions = **5**
+- answer any = **3**
+- theory total = **15 marks**
+- no separate short-answer section by default
+
+### Other Subjects
+
+Current preference:
+
+- may still use open-ended and theory sections
+- still intended to fit the 40-mark exam system
+- exact split should be clarified before final generation if not explicitly stated
+
+## Layout Rules
+
+- use **Times New Roman**
+- default body size **12 pt**
+- narrow margins
+- compact layout
+- header must be 1-column and should include: school name, academic session, term/exam title, pupil name/date, examination number/time, class, arm, subject, and instructions
+- body is **1-column by default**
+- use 2-column/3-column body only when a dense objective paper genuinely needs it for fit; do not apply columns mechanically to every subject
+- headings should be bold and black, not oversized
+- objective options should appear inline or compactly, not stacked unless unavoidable
+- remove `Total Marks` line unless requested
+- try to keep each paper around **2 pages** where practical
+
+## Diagram Rules
+
+- store diagrams in `Questions/assets/`
+- simple line/geometry diagrams: prefer SVG masters plus PNG export copies
+- pictorial nursery/primary objects (mango, pot, bucket, moon, table, cup, animals, classroom objects, etc.): prefer Anti-Gravity image generation or another image-generation path instead of rough SVG-only drawings
+- Anti-Gravity can generate images; when using it, instruct whether to generate images, use SVG, or use a hybrid method, and require a report of the method used
+- do not include answer labels from the teacher’s source in the student-facing diagram, e.g. do not label the keyboard as “Keyboard” when the question asks pupils to identify it
+- keep separate source drawings as separate assets unless the question explicitly presents them as one grouped diagram; this helps preserve order and layout
+- for diagram-heavy papers, rebuild the draft directly from the original tagged images instead of relying only on extraction summaries
+- do not show worked/grouped answers in division or counting diagrams when the child is supposed to solve them
+- if pupils are asked to colour an object or flag, leave it as an outline unless the exam explicitly asks for a sample
+- labels must be readable when labels are part of the prompt rather than the answer
+- angle values must not be hidden by edges
+- move text away from lines when needed
+- rerender diagrams if the user reports visibility problems
+
+## Review Rules
+
+- objective answer validation is mandatory when a marking scheme or answer key is requested
+- marking scheme must match final numbering when requested
+- verification should independently confirm correctness
+- for handwritten sources, infer unclear text aggressively from context before marking it unclear
+- any remaining ambiguous handwriting must be captured in a user-review list with image filename/page reference, question number, and candidate interpretations
+- if a wording ambiguity is found, fix the paper and then realign the scheme when a scheme exists
+
+## Feedback Rules
+
+- user feedback overrides previous assumptions
+- update future papers to follow the corrected rule
+- if a DOCX is locked, save a versioned file such as `v2`
+
+## Notes
+
+This rulebook is intentionally opinionated because it represents Johno's workflow. Keep it flexible enough to ask follow-up questions whenever a new subject or mark pattern does not clearly fit the stored defaults.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "takomi",
-  "version": "2.1.36",
+  "version": "2.1.38",
   "description": "🎯 Stop wrestling with AI. Start building with purpose. The artisan's toolkit for agent workflows, Codex skills, and original Takomi capabilities like 21st.dev integration.",
   "type": "module",
   "bin": {
@@ -50,7 +50,7 @@
     "commander": "^13.1.0",
     "figlet": "^1.8.0",
     "fs-extra": "^11.3.0",
-    "pi-subagents": "0.28.0",
+    "pi-subagents": "0.31.0",
     "picocolors": "^1.1.1",
     "prompts": "^2.4.2"
   },

package/src/cli.js

@@ -44,7 +44,7 @@ import {
   isStoreInitialized,
 } from './store.js';
 import { runDoctor } from './doctor.js';
-import { ensurePiInstalled, ensurePiSubagentsInstalled, launchTakomiHarness, printPiInstallResult, printPiSubagentsInstallResult, updatePiCliPackage, updatePiManagedPackages, printPiManagedPackageUpdateResult } from './pi-harness.js';
+import { disableRawPiSubagentsActivation, ensurePiInstalled, ensurePiSubagentsInstalled, formatRawPiSubagentsDisableActions, formatRawPiSubagentsFindings, inspectRawPiSubagentsActivation, launchTakomiHarness, printPiInstallResult, printPiSubagentsInstallResult, updatePiCliPackage, updatePiManagedPackages, printPiManagedPackageUpdateResult } from './pi-harness.js';
 import { installPiHarnessAssets, printPiInstallSummary, syncPiHarnessAssets, validatePiHarnessInstall } from './pi-installer.js';
 import { offerPiOptionalFeatures } from './pi-optional-features.js';
 import {
@@ -461,6 +461,37 @@ async function installAllTargets(options = {}) {
   await installSkillsTarget();
 }
 
+async function offerRawPiSubagentsHardening({ interactive = process.stdin.isTTY && process.stdout.isTTY } = {}) {
+  const audit = await inspectRawPiSubagentsActivation({ cwd: process.cwd() });
+  if (!audit.findings.length) return;
+
+  console.log(pc.yellow('\n⚠ Raw Pi subagents activation detected'));
+  console.log(pc.dim(formatRawPiSubagentsFindings(audit.findings)));
+  console.log(pc.dim('\nTakomi keeps pi-subagents installed as an internal module, but raw Pi activation exposes the separate `subagent` tool next to `takomi_subagent`.'));
+
+  let shouldDisable = process.env.TAKOMI_DISABLE_RAW_PI_SUBAGENTS === '1';
+  if (interactive && process.env.TAKOMI_DISABLE_RAW_PI_SUBAGENTS !== '1') {
+    const response = await prompts({
+      type: 'confirm',
+      name: 'disable',
+      message: 'Disable raw Pi subagents activation so agents only see takomi_subagent?',
+      initial: true,
+    });
+    shouldDisable = response.disable === true;
+  }
+
+  if (!shouldDisable) {
+    console.log(pc.yellow(interactive
+      ? 'Leaving raw Pi subagents activation unchanged.'
+      : 'Non-interactive run: leaving raw Pi subagents activation unchanged. Set TAKOMI_DISABLE_RAW_PI_SUBAGENTS=1 to disable automatically.'));
+    return;
+  }
+
+  const result = await disableRawPiSubagentsActivation({ cwd: process.cwd() });
+  console.log(pc.green('✔ Disabled raw Pi subagents activation'));
+  console.log(pc.dim(formatRawPiSubagentsDisableActions(result.actions)));
+}
+
 async function installPiTarget(options = {}) {
   const { offerOptionalFeatures = true } = options;
   console.log(pc.magenta('🧭 Pi Harness Preflight\n'));
@@ -493,12 +524,14 @@ async function installPiTarget(options = {}) {
     const result = await installPiHarnessAssets(program.version());
     const validation = await validatePiHarnessInstall();
     printPiInstallSummary(result, validation);
+    await offerRawPiSubagentsHardening();
     if (offerOptionalFeatures) {
       console.log(pc.cyan('\n🧩 Optional Takomi Pi feature packs...\n'));
       await offerPiOptionalFeatures({ interactive: true });
     }
     console.log(pc.cyan('\n📦 Checking Pi-managed extension package updates...\n'));
     printPiManagedPackageUpdateResult(await updatePiManagedPackages());
+    await offerRawPiSubagentsHardening();
     console.log(pc.dim('\nNext: cd <project> && takomi\n'));
   } catch (error) {
     console.log(pc.red('\nPi harness asset install failed.'));
@@ -512,8 +545,10 @@ async function installPiOptionalFeaturesTarget() {
   printPiInstallResult(pi);
   if (!pi.ok) return;
   await offerPiOptionalFeatures({ interactive: true });
+  await offerRawPiSubagentsHardening();
   console.log(pc.cyan('\n📦 Checking Pi-managed extension package updates...\n'));
   printPiManagedPackageUpdateResult(await updatePiManagedPackages());
+  await offerRawPiSubagentsHardening();
 }
 
 async function syncPiTarget() {
@@ -522,8 +557,10 @@ async function syncPiTarget() {
     const result = await syncPiHarnessAssets(program.version());
     const validation = await validatePiHarnessInstall();
     printPiInstallSummary(result, validation);
+    await offerRawPiSubagentsHardening();
     console.log(pc.cyan('\n📦 Checking Pi-managed extension package updates...\n'));
     printPiManagedPackageUpdateResult(await updatePiManagedPackages());
+    await offerRawPiSubagentsHardening();
   } catch (error) {
     console.log(pc.red('\nPi sync failed.'));
     console.log(pc.dim(String(error?.message || error)));