cairn-ai 0.1.9 → 0.1.10

package/.agents/workflows/cairn-plan.md

@@ -16,7 +16,7 @@ Procedure:
 8. Run complexity triage before applying agent, plugin, or delegated workflow guidance, and record it before mutating files.
 9. Use Light Path by default unless a Heavy Path condition clearly applies.
 10. Use `explorer` for independent read-only discovery, impact analysis, pattern search, and read-only verification when available.
-11. Use `worker` for bounded implementation or verification tasks with clear file ownership. When subagent tools are available, each agent may recursively delegate bounded sub-tasks to subagents. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work, keep scope, and preserve others' edits. Keep urgent blocking work local.
+11. Treat the user-called/main agent as the orchestrator: it plans, assigns, verifies, relays received subagent status events or observable lifecycle events to the user, and records evidence. Use `worker` for actual implementation edits with clear file ownership whenever subagent tools are available, on both Light Path and Heavy Path. When the subagent tool provides a progress-reporting channel, require subagents to report status when starting work, when deciding or confirming direction, during periodic progress, and when finishing; immediately relay received status events to the user. If no mid-run reporting channel exists, relay observable events such as assignment, waiting, and final completion. Require delegated subagents to provide a final report before leaving; after capturing the final report and evidence, close or release the completed subagent, then review the final report and evidence before marking the work complete. When subagent tools are available, each agent may recursively delegate bounded sub-tasks to subagents. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work, keep scope, and preserve others' edits. If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence.
 12. Write `docs/plan/<topic>.md`.
 13. Add the topic link and status to `PLAN.md`.
 14. Put the selected Light/Heavy Path, checked Heavy Path signals, tool readiness, module acceptance verification, and surface integration verification on every module task.

package/.agents/workflows/cairn-work.md

@@ -12,9 +12,9 @@ Procedure:
 4. Select one small module task.
 5. Confirm required tool readiness. If a required LSP/check tool is missing, run `node scripts/cairn.mjs toolcheck --install` or a repository-native install command before accepting a fallback.
 6. Confirm the complexity triage and selected Light/Heavy Path recorded in the plan. If missing, update the plan before mutating files.
-7. For Light Path, implement directly or use one bounded `worker`, then run focused verification.
+7. For Light Path, keep the user-called/main agent in the orchestrator role and delegate implementation edits to one bounded `worker` whenever subagent tools are available, then run focused verification.
 8. For Heavy Path, follow the plan's staged implementation and review gates without role-mapping shortcuts.
-9. When delegating implementation to `worker`, state the file ownership clearly. When subagent tools are available, each agent may recursively delegate bounded sub-tasks to subagents. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work, keep scope, and preserve others' edits.
+9. Delegate actual implementation edits to `worker` with clear file ownership on both Light Path and Heavy Path whenever subagent tools are available. When the subagent tool provides a progress-reporting channel, require subagents to report status to the orchestrator when starting work, when deciding or confirming direction, during periodic progress, and when finishing; immediately relay received status events to the user. If no mid-run reporting channel exists, relay observable events such as assignment, waiting, and final completion. Require delegated subagents to provide a final report before leaving; after capturing the final report and evidence, close or release the completed subagent, then review the final report and evidence before marking the work complete. When subagent tools are available, each agent may recursively delegate bounded sub-tasks to subagents. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work, keep scope, and preserve others' edits. If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence.
 10. Re-run module acceptance verification.
 11. Re-run surface integration verification.
 12. Record tool readiness and verification evidence in `docs/plan/<topic>.md` and update `PLAN.md`.

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "cairn",
-  "version": "0.1.9",
+  "version": "0.1.10",
   "description": "Token-efficient agent harness with tool readiness for Codex, Claude Code, and Antigravity.",
   "author": {
     "name": "WkNam"
@@ -26,7 +26,11 @@
       "Run cairn-toolcheck before planning implementation work.",
       "Before non-trivial implementation, run cairn-plan for this task without asking me for discoverable facts.",
       "When planning, first understand the whole work, then classify it into small executable tasks; if a task needs further breakdown, split it into sub-tasks.",
+      "The user-called/main agent is the orchestrator: plan, assign, verify, and record evidence; actual implementation edits must be delegated to worker subagents whenever subagent tools are available, on both Light Path and Heavy Path.",
+      "When the subagent tool provides a progress-reporting channel, subagents report status to the orchestrator when starting work, when deciding or confirming direction, during periodic progress, and when finishing; the orchestrator must immediately relay received status events to the user. If no mid-run reporting channel exists, the orchestrator relays observable events such as assignment, waiting, and final completion.",
+      "When a delegated subagent finishes, it must provide its final report before leaving; after the orchestrator captures the final report and evidence, the orchestrator must close or release the completed subagent, then review the final report and evidence before marking the work complete.",
       "When subagent tools are available, each agent may recursively delegate bounded sub-tasks to subagents; every child subagent must read MEMORY.md, keep scope, and preserve others' edits.",
+      "If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence; do not stop before local implementation solely because subagent tools are unavailable.",
       "Record Light Path or Heavy Path complexity triage in docs/plan/<topic>.md before mutating files.",
       "Run cairn-work from the current PLAN.md and pass dry-run/check, module acceptance, and surface integration gates.",
       "If I ask a side question, status question, or narrow clarification while a plan or task is still active, answer it briefly and then resume the previous active work unless I explicitly ask you to pause, stop, or switch tasks."

package/README.ko.md

@@ -17,16 +17,20 @@ Cairn은 도구 준비 상태도 작업의 일부로 다룹니다. LSP, typechec
 
 Cairn은 LazyCodex(`https://github.com/code-yeongyu/lazycodex`)의 영향을 받았습니다. 영향을 받은 부분은 설치 가능한 에이전트 하네스 구조, Codex hook trust/setup 처리, project memory, planning skills, 실행 가능한 workflow commands, diagnostics, 그리고 local agent surfaces 전반의 skill/agent packaging입니다.
 
-Cairn은 실행 정책에서는 LazyCodex와 다릅니다. LazyCodex의 role-chain execution model이나 open-ended completion loop는 채택하지 않습니다. 대신 Light/Heavy Path triage, 제한된 `explorer`/`worker` 위임, 두 검증 게이트, 명시적 stop condition을 사용합니다.
+Cairn은 실행 정책에서는 LazyCodex와 다릅니다. LazyCodex의 role-chain execution model이나 open-ended completion loop는 채택하지 않습니다. 대신 Light/Heavy Path triage, main-agent orchestration, 제한된 `explorer`/`worker` 위임, 두 검증 게이트, 명시적 stop condition을 사용합니다.
 
 ## Complexity Triage
 
 모든 구현 작업은 agent, plugin, delegated workflow 지침을 적용하기 전에 먼저 complexity triage를 거칩니다. triage는 사용자에게 묻지 않고 저장소 탐색, 예상 변경 범위, 위험 신호를 기준으로 결정합니다.
 
-- Light Path: 기존 아키텍처 레이어 안의 좁은 변경입니다. 기본값이며, 직접 구현하거나 하나의 제한된 `worker`를 사용한 뒤 검증 게이트를 유지합니다.
+- Light Path: 기존 아키텍처 레이어 안의 좁은 변경입니다. 기본값이지만, 사용자가 호출한 main agent는 여전히 orchestration을 맡고 subagent 도구가 있으면 구현 편집을 하나의 제한된 `worker`에 위임한 뒤 검증 게이트를 유지합니다.
 - Heavy Path: 새 디렉터리/모듈/레이어, 새 도메인 모델/서비스/추상화, 보안/세션/인증, 외부 API/message queue/payment, DB schema/migration, concurrency/transaction/cache 변경, 여러 도메인 리팩터링, 또는 사용자의 extra-care 요청입니다.
 
-선택된 path와 근거는 계획 산출물이 있을 때 `docs/plan/<topic>.md`에 기록합니다. Light Path에서도 두 검증 게이트는 유지됩니다.
+선택된 path와 근거는 계획 산출물이 있을 때 `docs/plan/<topic>.md`에 기록합니다. Light Path에서도 두 검증 게이트는 유지됩니다. subagent 도구가 없으면 main agent가 implementation을 직접 인계하고, 그 takeover를 evidence에 기록합니다.
+
+subagent 도구가 progress-reporting channel을 제공하면 subagent는 작업 시작, 방향 결정/확인, 주기적 진행, 완료 시점에 orchestrator에게 상태를 보고합니다. orchestrator는 받은 status event를 즉시 사용자에게 전달합니다. mid-run reporting channel이 없으면 orchestrator는 할당, 대기, 최종 완료처럼 관측 가능한 event를 사용자에게 전달합니다.
+
+위임받은 subagent는 작업을 마치면 퇴근 전에 final report를 남깁니다. orchestrator가 final report와 evidence를 회수한 뒤 완료된 subagent를 close/release합니다. 그 다음 orchestrator가 final report와 evidence를 검토한 뒤 작업 완료 여부를 판단합니다.
 
 ## Tool Readiness
 
@@ -124,7 +128,7 @@ Cairn의 재사용 지침은 전역 사용을 위해 영어로 작성됩니다.
 ## Delegation
 
 - `explorer`: 가능한 경우 read-only codebase discovery, impact analysis, pattern search, read-only verification을 처리합니다.
-- `worker`: 명확한 file ownership이 있는 제한된 implementation 또는 verification task를 처리합니다.
-- Main session: 다음 단계가 즉시 결과에 의존하는 urgent blocking work를 로컬에서 처리합니다.
+- `worker`: 명확한 file ownership이 있는 실제 implementation edit 또는 verification task를 처리합니다.
+- Main session: orchestrate, verify, evidence 기록을 맡으며, 다음 단계가 즉시 결과에 의존하는 urgent non-implementation blocking work만 로컬에서 처리합니다. 다만 subagent 도구가 없으면 main agent가 implementation을 직접 인계합니다.
 
 모든 delegation prompt는 TASK, EXPECTED OUTCOME, REQUIRED TOOLS, MUST DO, MUST NOT DO, CONTEXT 여섯 섹션을 사용합니다.

package/README.md

@@ -25,16 +25,20 @@ Cairn also treats tool readiness as part of the work. LSP, typecheck, lint, dry-
 
 Cairn is influenced by LazyCodex (`https://github.com/code-yeongyu/lazycodex`). The borrowed ideas are the installable agent-harness shape, Codex hook trust/setup handling, project memory, planning skills, executable workflow commands, diagnostics, and skill/agent packaging across local agent surfaces.
 
-Cairn intentionally diverges from LazyCodex in the execution policy. It does not adopt LazyCodex's role-chain execution model or open-ended completion loops. Cairn uses Light/Heavy Path triage, bounded `explorer`/`worker` delegation, two verification gates, and explicit stop conditions instead.
+Cairn intentionally diverges from LazyCodex in the execution policy. It does not adopt LazyCodex's role-chain execution model or open-ended completion loops. Cairn uses Light/Heavy Path triage, main-agent orchestration, bounded `explorer`/`worker` delegation, two verification gates, and explicit stop conditions instead.
 
 ## Complexity Triage
 
 Every implementation task passes complexity triage first, before agent, plugin, or delegated workflow guidance. Triage is decided from repository exploration, expected change scope, and risk signals without asking the user.
 
-- Light Path: narrow changes inside existing architecture layers. This is the default. Implement directly or use one bounded `worker`, then keep the verification gate.
+- Light Path: narrow changes inside existing architecture layers. This is the default. The user-called/main agent still orchestrates and delegates implementation edits to one bounded `worker` whenever subagent tools are available, then keeps the verification gate.
 - Heavy Path: new directory/module/layer, new domain model/service/abstraction, security/session/auth, external API/message queue/payment, DB schema/migration, concurrency/transaction/cache changes, cross-domain refactor, or explicit extra-care request.
 
-The selected path and rationale are recorded in `docs/plan/<topic>.md` when a plan artifact exists. Even on Light Path, the two verification gates remain.
+The selected path and rationale are recorded in `docs/plan/<topic>.md` when a plan artifact exists. Even on Light Path, the two verification gates remain. If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence.
+
+When the subagent tool provides a progress-reporting channel, subagents report status to the orchestrator when starting work, when deciding or confirming direction, during periodic progress, and when finishing. The orchestrator immediately relays received status events to the user. If no mid-run reporting channel exists, the orchestrator relays observable events such as assignment, waiting, and final completion.
+
+When a delegated subagent finishes, it provides a final report before leaving. After the orchestrator captures that final report and evidence, the completed subagent is closed or released. The orchestrator then reviews the final report and evidence before marking the work complete.
 
 ## Tool Readiness
 
@@ -132,7 +136,7 @@ Cairn's reusable instructions are written in English for global use. User-visibl
 ## Delegation
 
 - `explorer`: handles read-only codebase discovery, impact analysis, pattern searches, and read-only verification when available.
-- `worker`: handles bounded implementation or verification tasks with clear file ownership.
-- Main session: keeps urgent blocking work local when the next step depends immediately on the result.
+- `worker`: handles actual implementation edits or verification tasks with clear file ownership.
+- Main session: orchestrates, verifies, and records evidence; it keeps only urgent non-implementation blocking work local when the next step depends immediately on the result, except that unavailable subagent tools make the main agent take over implementation directly.
 
 Every delegation prompt uses six sections: TASK, EXPECTED OUTCOME, REQUIRED TOOLS, MUST DO, MUST NOT DO, CONTEXT.

package/commands/cairn-plan.md

@@ -18,7 +18,7 @@ Procedure:
 8. Run complexity triage before applying agent, plugin, or delegated workflow guidance, and record it before mutating files.
 9. Use Light Path by default unless a Heavy Path condition clearly applies.
 10. Use `explorer` for independent read-only discovery, impact analysis, pattern search, and read-only verification when available.
-11. Use `worker` for bounded implementation or verification tasks with clear file ownership. When subagent tools are available, each agent may recursively delegate bounded sub-tasks to subagents. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work, keep scope, and preserve others' edits. Keep urgent blocking work local.
+11. Treat the user-called/main agent as the orchestrator: it plans, assigns, verifies, relays received subagent status events or observable lifecycle events to the user, and records evidence. Use `worker` for actual implementation edits with clear file ownership whenever subagent tools are available, on both Light Path and Heavy Path. When the subagent tool provides a progress-reporting channel, require subagents to report status when starting work, when deciding or confirming direction, during periodic progress, and when finishing; immediately relay received status events to the user. If no mid-run reporting channel exists, relay observable events such as assignment, waiting, and final completion. Require delegated subagents to provide a final report before leaving; after capturing the final report and evidence, close or release the completed subagent, then review the final report and evidence before marking the work complete. When subagent tools are available, each agent may recursively delegate bounded sub-tasks to subagents. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work, keep scope, and preserve others' edits. If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence.
 12. Write `docs/plan/<topic>.md`.
 13. Add the topic link and status to `PLAN.md`.
 14. Put the selected Light/Heavy Path, checked Heavy Path signals, tool readiness, module acceptance verification, and surface integration verification on every module task.

package/commands/cairn-work.md

@@ -14,9 +14,9 @@ Procedure:
 4. Select one small module task.
 5. Confirm required tool readiness. If a required LSP/check tool is missing, run `node scripts/cairn.mjs toolcheck --install` or a repository-native install command before accepting a fallback.
 6. Confirm the complexity triage and selected Light/Heavy Path recorded in the plan. If missing, update the plan before mutating files.
-7. For Light Path, implement directly or use one bounded `worker`, then run focused verification.
+7. For Light Path, keep the user-called/main agent in the orchestrator role and delegate implementation edits to one bounded `worker` whenever subagent tools are available, then run focused verification.
 8. For Heavy Path, follow the plan's staged implementation and review gates without role-mapping shortcuts.
-9. When delegating implementation to `worker`, state the file ownership clearly. When subagent tools are available, each agent may recursively delegate bounded sub-tasks to subagents. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work, keep scope, and preserve others' edits.
+9. Delegate actual implementation edits to `worker` with clear file ownership on both Light Path and Heavy Path whenever subagent tools are available. When the subagent tool provides a progress-reporting channel, require subagents to report status to the orchestrator when starting work, when deciding or confirming direction, during periodic progress, and when finishing; immediately relay received status events to the user. If no mid-run reporting channel exists, relay observable events such as assignment, waiting, and final completion. Require delegated subagents to provide a final report before leaving; after capturing the final report and evidence, close or release the completed subagent, then review the final report and evidence before marking the work complete. When subagent tools are available, each agent may recursively delegate bounded sub-tasks to subagents. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work, keep scope, and preserve others' edits. If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence.
 10. For Heavy Path, run the recorded automated test command and record explicit `Tests:` evidence before any completion claim.
 11. Re-run module acceptance verification.
 12. Re-run surface integration verification.

package/docs/model-guidance/README.md

@@ -17,6 +17,11 @@ The goal is not to make prompts long by model. The goal is to stabilize the same
 - Keep detailed judgment in `docs/memory/`, `docs/plan/`, and `docs/model-guidance/`.
 - Preserve proper nouns, file names, variable names, service names, alert names, MCP tool names, and agent names exactly as written.
 - Select Light Path or Heavy Path before implementation.
+- Treat the user-called/main agent as the orchestrator: it plans, assigns, verifies, and records evidence.
+- Delegate actual implementation edits to `worker` subagents whenever subagent tools are available, regardless of Light Path or Heavy Path.
+- When the subagent tool provides a progress-reporting channel, require subagents to report status to the orchestrator when starting work, when deciding or confirming direction, during periodic progress, and when finishing; the orchestrator must immediately relay received status events to the user. If no mid-run reporting channel exists, the orchestrator relays observable events such as assignment, waiting, and final completion.
+- When a delegated subagent finishes, require a final report before it leaves; after capturing the final report and evidence, the orchestrator closes or releases the completed subagent, then reviews the final report and evidence before marking the work complete.
+- If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence.
 - Detect required LSP, typecheck, lint, dry-run, and verification tools before implementation.
 - Missing required tools must trigger a project-local, repository-native, or ephemeral install attempt before they can be treated as unavailable.
 - Every implementation task must pass module acceptance verification and surface integration verification.
@@ -27,5 +32,5 @@ The goal is not to make prompts long by model. The goal is to stabilize the same
 ## Delegation Defaults
 
 - `explorer`: use for read-only codebase discovery, impact analysis, pattern searches, and read-only verification when available.
-- `worker`: use for bounded implementation or verification tasks with clear file ownership.
-- Main session: keep urgent blocking work local when the next step depends immediately on the result.
+- `worker`: use for actual implementation edits or verification tasks with clear file ownership.
+- Main session: orchestrate, immediately relay received subagent status events or observable subagent lifecycle events to the user, verify, and record evidence; keep only urgent non-implementation blocking work local when the next step depends immediately on the result, except that unavailable subagent tools make the main agent take over implementation directly.

package/docs/model-guidance/codex.md

@@ -1,10 +1,14 @@
 # Codex Model Guidance
 
-Codex-family models are strong at small implementation tasks, explicit tool use, and repeatable verification. In Cairn, prefer them for bounded `worker` tasks and structurally clear planning.
+Codex-family models are strong at small implementation tasks, explicit tool use, and repeatable verification. In Cairn, prefer them for bounded `worker` tasks and structurally clear planning. When Codex is the user-called/main agent, it orchestrates instead of making implementation edits directly whenever subagent tools are available.
 
 ## Use Strengths
 
 - Quickly handle implementation tasks with clear file scope.
+- As `worker`, make actual implementation edits within the assigned file scope.
+- As the user-called/main agent, delegate implementation edits to `worker` whenever subagent tools are available.
+- As a subagent, report status to the orchestrator when the current subagent tool provides a progress-reporting channel, including when starting work, when deciding or confirming direction, during periodic progress, and when finishing.
+- As a subagent, provide a final report before leaving when assigned work is complete.
 - Read existing patterns and make minimal changes in the same style.
 - Run repository tool readiness checks and bootstrap missing command-line tools.
 - Capture module acceptance verification and surface integration verification from command results.
@@ -14,6 +18,7 @@ Codex-family models are strong at small implementation tasks, explicit tool use,
 ## Adjustment Rules
 
 - Do not start implementation without a plan.
+- Do not stop before local implementation solely because subagent tools are unavailable; the main agent takes over implementation directly and records that takeover in evidence.
 - Keep work units small. Split large changes into smaller plan tasks.
 - If `apply_patch` is unstable in the environment, use an editing tool or a clear file update path.
 - Do not duplicate the same exploration. Wait for already delegated searches.
@@ -34,7 +39,10 @@ Codex-family models are strong at small implementation tasks, explicit tool use,
 
 ### Implementation
 
-- Edit only within the file scope listed in the plan.
+- If acting as the user-called/main agent, orchestrate the work and delegate actual implementation edits to `worker` whenever subagent tools are available, regardless of Light Path or Heavy Path.
+- If acting as the user-called/main agent, immediately relay received subagent status events to the user. If no mid-run reporting channel exists, relay observable events such as assignment, waiting, and final completion.
+- If acting as the user-called/main agent, close or release completed subagents after capturing their final report and evidence, then review the final report and evidence before marking the work complete.
+- If acting as `worker`, edit only within the file scope listed in the plan.
 - Confirm required tools are available. Install or bootstrap missing required tools before implementation.
 - Run the recorded dry-run or check command before external-state mutation when applicable.
 - After changes, run both module acceptance verification and surface integration verification.
@@ -46,3 +54,6 @@ Codex-family models are strong at small implementation tasks, explicit tool use,
 - Handle search, file listing, command checks, and QA artifact capture.
 - Use `explorer` for independent read-only discovery or read-only verification when available.
 - When using `worker`, state clear file ownership and tell the worker not to revert others' edits.
+- Tell subagents to report status when the tool provides a progress-reporting channel: starting work, deciding or confirming direction, periodic progress, and finishing.
+- Tell subagents to provide a final report before leaving, then close or release them after evidence is captured. Review the final report and evidence before marking the work complete.
+- If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cairn-ai",
-  "version": "0.1.9",
+  "version": "0.1.10",
   "description": "Token-efficient agent harness with tool readiness for Codex, Claude Code, and Antigravity",
   "license": "MIT",
   "author": {

package/scripts/cairn-state.mjs

@@ -1,6 +1,6 @@
 #!/usr/bin/env node
 import { realpathSync } from "node:fs";
-import { mkdir, readFile, writeFile } from "node:fs/promises";
+import { mkdir, readFile, readdir, writeFile } from "node:fs/promises";
 import { isAbsolute, join, relative, resolve } from "node:path";
 import { fileURLToPath, pathToFileURL } from "node:url";
 
@@ -92,7 +92,7 @@ export async function runStateResult(event = "manual", { root = process.env.HARN
     };
   }
   if (event === "stop" || event === "subagent-stop") {
-    const pending = await pendingActivePlanItems(resolvedRoot);
+    const pending = await pendingPlanItems(resolvedRoot);
     if (pending.length > 0) {
       return {
         status: 1,
@@ -119,32 +119,50 @@ async function writeIfMissing(path, content) {
   }
 }
 
-async function pendingActivePlanItems(root) {
+async function pendingPlanItems(root) {
   const planPath = join(root, "PLAN.md");
   const plan = await readFile(planPath, "utf8");
   const activePlans = markdownLinksToPlanFiles(section(plan, "Active Plans"));
+  const completedPlans = markdownLinksToPlanFiles(section(plan, "Completed Plans"));
+  const indexedPlans = new Map();
+  for (const relativePath of activePlans) indexedPlans.set(relativePath, "active");
+  for (const relativePath of completedPlans) {
+    if (!indexedPlans.has(relativePath)) indexedPlans.set(relativePath, "completed");
+  }
+  for (const relativePath of await docsPlanFiles(root)) {
+    if (!indexedPlans.has(relativePath)) indexedPlans.set(relativePath, "unindexed");
+  }
   const pending = [];
 
-  for (const relativePath of activePlans) {
+  for (const [relativePath, indexState] of indexedPlans) {
     const path = resolve(root, relativePath);
     const pathFromRoot = relative(root, path);
     if (pathFromRoot.startsWith("..") || isAbsolute(pathFromRoot)) continue;
     const text = await readPlanFile(path);
     if (text === null) {
-      pending.push({ path: relativePath, unchecked: ["active plan file is missing"], emptyEvidence: [] });
+      pending.push({ path: relativePath, indexIssues: [`${indexState} plan file is missing`], unchecked: [], emptyEvidence: [] });
       continue;
     }
+    const indexIssues = indexState === "unindexed" ? ["not linked in PLAN.md Active Plans or Completed Plans"] : [];
     const unchecked = [...text.matchAll(/^\s*-\s+\[\s\]\s+(.+)$/gm)].map((match) => match[1].trim());
     const emptyEvidence = emptyEvidenceItems(text);
     const missingHeavyPathTests = heavyPathMissingTests(text);
-    if (unchecked.length > 0 || emptyEvidence.length > 0 || missingHeavyPathTests.length > 0) {
-      pending.push({ path: relativePath, unchecked, emptyEvidence, missingHeavyPathTests });
+    if (indexIssues.length > 0 || unchecked.length > 0 || emptyEvidence.length > 0 || missingHeavyPathTests.length > 0) {
+      pending.push({ path: relativePath, indexIssues, unchecked, emptyEvidence, missingHeavyPathTests });
     }
   }
 
   return pending;
 }
 
+async function docsPlanFiles(root) {
+  const entries = await readdir(join(root, "docs", "plan"), { withFileTypes: true });
+  return entries
+    .filter((entry) => entry.isFile() && entry.name.endsWith(".md"))
+    .map((entry) => `docs/plan/${entry.name}`)
+    .sort();
+}
+
 async function readPlanFile(path) {
   try {
     return await readFile(path, "utf8");
@@ -206,6 +224,7 @@ function stopBlockedMessage({ event, ko, pending }) {
 
 function formatPendingItem(item) {
   const reasons = [
+    ...(item.indexIssues ?? []).map((label) => `index: ${label}`),
     ...item.unchecked.map((label) => `unchecked: ${label}`),
     ...item.emptyEvidence.map((label) => `empty evidence: ${label}`),
     ...(item.missingHeavyPathTests ?? []).map((label) => `missing tests: ${label}`),

package/scripts/cairn.mjs

@@ -56,60 +56,63 @@ function isCliEntry() {
   }
 }
 
+const planExecutionPolicy = "The user-called/main agent is the orchestrator; implementation edits go to worker subagents whenever subagent tools are available. When the subagent tool provides a progress-reporting channel, subagents report status to the orchestrator when starting work, when deciding or confirming direction, during periodic progress, and when finishing; the orchestrator must immediately relay received status events to the user. If no mid-run reporting channel exists, the orchestrator relays observable events such as assignment, waiting, and final completion. When a delegated subagent finishes, it must provide its final report before leaving; after the orchestrator captures the final report and evidence, the orchestrator must close or release the completed subagent, then review the final report and evidence before marking the work complete. If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence.";
+const workExecutionPolicy = "The user-called/main agent orchestrates, while worker subagents perform implementation edits whenever subagent tools are available. When the subagent tool provides a progress-reporting channel, subagents report status to the orchestrator when starting work, when deciding or confirming direction, during periodic progress, and when finishing; the orchestrator must immediately relay received status events to the user. If no mid-run reporting channel exists, the orchestrator relays observable events such as assignment, waiting, and final completion. When a delegated subagent finishes, it must provide its final report before leaving; after the orchestrator captures the final report and evidence, the orchestrator must close or release the completed subagent, then review the final report and evidence before marking the work complete. If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence.";
+
 const messages = {
   en: {
     memory: "Use the cairn-memory skill. Keep MEMORY.md as a short index and write details to docs/memory/<domain>.md.",
-    plan: "Use the cairn-plan skill before non-trivial implementation. Every agent must first read the project-root MEMORY.md for domain knowledge and repository policy. Understand the whole work first, then classify it into executable tasks and sub-tasks. Keep PLAN.md as an index, write detailed plans to docs/plan/<topic>.md, and record Light/Heavy Path triage before any mutation.",
-    work: "Use the cairn-work skill only after a plan exists. Every agent must first read the project-root MEMORY.md for domain knowledge and repository policy. Execute one module task using the recorded Light/Heavy Path route, and capture dry-run/check, module, and surface evidence. If the user asks a side question while work is active, answer briefly and then resume unless they explicitly ask to pause, stop, or switch tasks.",
+    plan: `Use the cairn-plan skill before non-trivial implementation. Every agent must first read the project-root MEMORY.md for domain knowledge and repository policy. Understand the whole work first, then classify it into executable tasks and sub-tasks. Keep PLAN.md as an index, write detailed plans to docs/plan/<topic>.md, and record Light/Heavy Path triage before any mutation. ${planExecutionPolicy}`,
+    work: `Use the cairn-work skill only after a plan exists. Every agent must first read the project-root MEMORY.md for domain knowledge and repository policy. Execute one module task using the recorded Light/Heavy Path route: ${workExecutionPolicy} Capture dry-run/check, module, and surface evidence. If the user asks a side question while work is active, answer briefly and then resume unless they explicitly ask to pause, stop, or switch tasks.`,
     review: "Use the cairn-review skill. Compare evidence against PLAN.md and MEMORY.md.",
     usage: "Usage: cairn install|upgrade|doctor|uninstall|init|memory|plan|work|review|toolcheck",
   },
   ko: {
     memory: "cairn-memory 스킬을 사용하세요. MEMORY.md는 짧은 색인으로, 상세 내용은 docs/memory/<domain>.md에 기록합니다.",
-    plan: "중요 구현 전에는 cairn-plan 스킬을 사용하세요. 모든 에이전트는 도메인 지식과 저장소 정책을 위해 프로젝트 루트 MEMORY.md를 먼저 읽어야 합니다. 먼저 전체 작업을 파악한 뒤 실행 가능한 task와 필요한 sub-task로 분류합니다. PLAN.md는 색인으로, 상세 계획은 docs/plan/<topic>.md에 기록하며 파일 변경 전 Light/Heavy Path 트리아지를 남깁니다.",
-    work: "계획이 있을 때만 cairn-work 스킬을 사용하세요. 모든 에이전트는 도메인 지식과 저장소 정책을 위해 프로젝트 루트 MEMORY.md를 먼저 읽어야 합니다. 기록된 Light/Heavy Path 경로로 하나의 모듈 작업을 실행하며 dry-run/check, 모듈, 표면 증거를 확보합니다. 작업 중 사용자가 곁가지 질문을 하면 짧게 답한 뒤, 명시적으로 일시중지/중단/작업 전환을 요청한 경우가 아니면 이전 active work를 계속합니다.",
+    plan: `중요 구현 전에는 cairn-plan 스킬을 사용하세요. 모든 에이전트는 도메인 지식과 저장소 정책을 위해 프로젝트 루트 MEMORY.md를 먼저 읽어야 합니다. 먼저 전체 작업을 파악한 뒤 실행 가능한 task와 필요한 sub-task로 분류합니다. PLAN.md는 색인으로, 상세 계획은 docs/plan/<topic>.md에 기록하며 파일 변경 전 Light/Heavy Path 트리아지를 남깁니다. ${planExecutionPolicy}`,
+    work: `계획이 있을 때만 cairn-work 스킬을 사용하세요. 모든 에이전트는 도메인 지식과 저장소 정책을 위해 프로젝트 루트 MEMORY.md를 먼저 읽어야 합니다. 기록된 Light/Heavy Path 경로로 하나의 모듈 작업을 실행합니다. ${workExecutionPolicy} dry-run/check, 모듈, 표면 증거를 확보합니다. 작업 중 사용자가 곁가지 질문을 하면 짧게 답한 뒤, 명시적으로 일시중지/중단/작업 전환을 요청한 경우가 아니면 이전 active work를 계속합니다.`,
     review: "cairn-review 스킬을 사용하세요. PLAN.md와 MEMORY.md 기준으로 증거를 비교합니다.",
     usage: "사용법: cairn install|upgrade|doctor|uninstall|init|memory|plan|work|review|toolcheck",
   },
   ja: {
     memory: "cairn-memory スキルを使用してください。MEMORY.md は短い索引にし、詳細は docs/memory/<domain>.md に記録します。",
-    plan: "cairn-plan スキルを使用してください。PLAN.md は索引にし、詳細計画は docs/plan/<topic>.md に記録します。",
-    work: "cairn-work スキルを使用してください。1つのモジュールスライスを実行し、モジュール証拠と表面証拠を取得します。",
+    plan: `cairn-plan スキルを使用してください。PLAN.md は索引にし、詳細計画は docs/plan/<topic>.md に記録します。${planExecutionPolicy}`,
+    work: `cairn-work スキルを使用してください。1つのモジュールスライスを実行し、モジュール証拠と表面証拠を取得します。${workExecutionPolicy}`,
     review: "cairn-review スキルを使用してください。PLAN.md と MEMORY.md に照らして証拠を比較します。",
     usage: "使い方: cairn install|upgrade|doctor|uninstall|init|memory|plan|work|review|toolcheck",
   },
   zh: {
     memory: "使用 cairn-memory skill。将 MEMORY.md 保持为简短索引，并将详细内容写入 docs/memory/<domain>.md。",
-    plan: "使用 cairn-plan skill。将 PLAN.md 保持为索引，并将详细计划写入 docs/plan/<topic>.md。",
-    work: "使用 cairn-work skill。执行一个模块切片，并收集模块证据。",
+    plan: `使用 cairn-plan skill。将 PLAN.md 保持为索引，并将详细计划写入 docs/plan/<topic>.md。${planExecutionPolicy}`,
+    work: `使用 cairn-work skill。执行一个模块切片，并收集模块证据。${workExecutionPolicy}`,
     review: "使用 cairn-review skill。根据 PLAN.md 和 MEMORY.md 对比证据。",
     usage: "用法: cairn install|upgrade|doctor|uninstall|init|memory|plan|work|review|toolcheck",
   },
   es: {
     memory: "Usa la skill cairn-memory. Mantén MEMORY.md como un índice breve y escribe los detalles en docs/memory/<domain>.md.",
-    plan: "Usa la skill cairn-plan. Mantén PLAN.md como índice y escribe los planes detallados en docs/plan/<topic>.md.",
-    work: "Usa la skill cairn-work. Ejecuta un solo segmento de módulo y captura evidencia de módulo y de superficie.",
+    plan: `Usa la skill cairn-plan. Mantén PLAN.md como índice y escribe los planes detallados en docs/plan/<topic>.md. ${planExecutionPolicy}`,
+    work: `Usa la skill cairn-work. Ejecuta un solo segmento de módulo y captura evidencia de módulo y de superficie. ${workExecutionPolicy}`,
     review: "Usa la skill cairn-review. Compara la evidencia con PLAN.md y MEMORY.md.",
     usage: "Uso: cairn install|upgrade|doctor|uninstall|init|memory|plan|work|review|toolcheck",
   },
   fr: {
     memory: "Utilisez la skill cairn-memory. Gardez MEMORY.md comme index court et écrivez les détails dans docs/memory/<domain>.md.",
-    plan: "Utilisez la skill cairn-plan. Gardez MEMORY.md comme index et écrivez les plans détaillés dans docs/plan/<topic>.md.",
-    work: "Utilisez la skill cairn-work. Exécutez une tranche de module et capturez les preuves de module et de surface.",
+    plan: `Utilisez la skill cairn-plan. Gardez MEMORY.md comme index et écrivez les plans détaillés dans docs/plan/<topic>.md. ${planExecutionPolicy}`,
+    work: `Utilisez la skill cairn-work. Exécutez une tranche de module et capturez les preuves de module et de surface. ${workExecutionPolicy}`,
     review: "Utilisez la skill cairn-review. Comparez les preuves avec PLAN.md et MEMORY.md.",
     usage: "Utilisation: cairn install|upgrade|doctor|uninstall|init|memory|plan|work|review|toolcheck",
   },
   de: {
     memory: "Verwenden Sie die Skill cairn-memory. Halten Sie MEMORY.md als kurzen Index und schreiben Sie Details nach docs/memory/<domain>.md.",
-    plan: "Verwenden Sie die Skill cairn-plan. Halten Sie MEMORY.md als Index und schreiben Sie Detailpläne nach docs/plan/<topic>.md.",
-    work: "Verwenden Sie die Skill cairn-work. Führen Sie einen Modulabschnitt aus und erfassen Sie Modul- und Oberflächenbelege.",
+    plan: `Verwenden Sie die Skill cairn-plan. Halten Sie MEMORY.md als Index und schreiben Sie Detailpläne nach docs/plan/<topic>.md. ${planExecutionPolicy}`,
+    work: `Verwenden Sie die Skill cairn-work. Führen Sie einen Modulabschnitt aus und erfassen Sie Modul- und Oberflächenbelege. ${workExecutionPolicy}`,
     review: "Verwenden Sie die Skill cairn-review. Vergleichen Sie Belege mit PLAN.md und MEMORY.md.",
     usage: "Verwendung: cairn install|upgrade|doctor|uninstall|init|memory|plan|work|review|toolcheck",
   },
   pt: {
     memory: "Use a skill cairn-memory. Mantenha MEMORY.md como um índice curto e escreva detalhes em docs/memory/<domain>.md.",
-    plan: "Use a skill cairn-plan. Mantenha MEMORY.md como índice e escreva planos detalhados em docs/plan/<topic>.md.",
-    work: "Use a skill cairn-work. Execute uma fatia de módulo e capture evidências de módulo e de superfície.",
+    plan: `Use a skill cairn-plan. Mantenha MEMORY.md como índice e escreva planos detalhados em docs/plan/<topic>.md. ${planExecutionPolicy}`,
+    work: `Use a skill cairn-work. Execute uma fatia de módulo e capture evidências de módulo e de superfície. ${workExecutionPolicy}`,
     review: "Use a skill cairn-review. Compare evidências com PLAN.md e MEMORY.md.",
     usage: "Uso: cairn install|upgrade|doctor|uninstall|init|memory|plan|work|review|toolcheck",
   },

package/skills/cairn-plan/SKILL.md

@@ -31,9 +31,13 @@ Plan from the whole work down. First understand the full requested outcome and a
 10. Run complexity triage before applying workflow guidance from agents, plugins, or delegated roles. Record the route before any implementation task.
 11. Delegate according to the selected path and model guidance instead of asking the user.
    - Use `explorer` for independent read-only codebase discovery, impact analysis, pattern searches, and read-only verification that can run in parallel when the current tool list supports it.
-   - Use `worker` for bounded implementation tasks with clear file ownership, disjoint write scope, or verification tasks that can run while the main session continues.
+   - Treat the user-called/main agent as the orchestrator: it plans, assigns, verifies, and records evidence.
+   - Use `worker` for actual implementation edits with clear file ownership whenever subagent tools are available, on both Light Path and Heavy Path.
+   - When the subagent tool provides a progress-reporting channel, require subagents to report status to the orchestrator when starting work, when deciding or confirming direction, during periodic progress, and when finishing; the orchestrator must immediately relay received status events to the user. If no mid-run reporting channel exists, relay observable events such as assignment, waiting, and final completion.
+   - Require delegated subagents to provide a final report before leaving; after capturing the final report and evidence, close or release the completed subagent, then review the final report and evidence before marking the work complete.
    - When subagent tools are available, each agent may recursively delegate bounded sub-tasks to subagents, subject to the current surface's depth and concurrency limits.
-   - Keep urgent blocking work local when the next step depends immediately on the result.
+   - If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence; do not stop before local implementation solely because subagent tools are unavailable.
+   - Keep urgent non-implementation blocking work local when the next step depends immediately on the result.
    - Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work, keep scope, and tell workers they are not alone in the codebase and must not revert others' edits.
 12. Create `docs/plan/<topic>.md` from `templates/work-plan.md`.
 13. Add a short index entry to `PLAN.md`.
@@ -47,7 +51,7 @@ This decision takes priority over plugin, agent, or delegated workflow guidance
 
 ### Light Path
 
-Use Light Path for narrow changes inside existing architecture layers. Skip planning/review agents and implement directly or with one `worker`, but keep the verification gate.
+Use Light Path for narrow changes inside existing architecture layers. Skip planning/review agents when appropriate, but actual implementation edits still go to `worker` whenever subagent tools are available. Keep the verification gate.
 
 Light Path conditions:
 
@@ -64,7 +68,7 @@ Light Path examples:
 - Change copy text or constants.
 - Fix one clearly scoped bug.
 
-Light Path flow: direct edit or single `worker` -> focused verification by the main agent or a scoped verification `worker` -> report. If there is no plan artifact, use the original user request and the diff as the verification baseline.
+Light Path flow: main-agent orchestration -> bounded `worker` implementation when subagent tools are available -> main-agent takeover when subagent tools are unavailable -> focused verification by the main agent or a scoped verification `worker` -> report. If there is no plan artifact, use the original user request and the diff as the verification baseline.
 
 ### Heavy Path
 
@@ -92,12 +96,16 @@ Heavy Path flow: plan -> pre-implementation review -> bounded `worker` implement
 - Heavy Path conditions found, if any.
 - Heavy Path conditions checked and not found.
 - Roles or delegation omitted in Light Path and why.
+- Any unavailable subagent tool main-agent takeover and its evidence record.
 - Pre-implementation decisions that review must resolve in Heavy Path.
 
 ## Planning Rules
 
 - Every plan must be decision-complete.
 - Every plan must describe the whole work first, then classify it into executable tasks and any needed sub-tasks.
+- Every plan must treat the user-called/main agent as the orchestrator and assign actual implementation edits to `worker` whenever subagent tools are available, regardless of Light Path or Heavy Path.
+- Every plan must require subagents to report status when the subagent tool provides a progress-reporting channel. If no mid-run reporting channel exists, the orchestrator must relay observable events such as assignment, waiting, and final completion.
+- Every plan must require delegated subagents to provide a final report before leaving, require the orchestrator to close or release completed subagents after capturing final report and evidence, and require the orchestrator to review the final report and evidence before marking work complete.
 - Every plan must allow recursive subagent delegation for bounded sub-tasks when the current agent surface supports it.
 - Every plan must include complexity triage and the selected path.
 - Every plan must explicitly list Heavy Path signals checked, even when Light Path is selected.
@@ -139,7 +147,7 @@ Prefer repository-native dry-run and check modes before mutating external state.
 TASK: Produce <role> input needed for the <topic> plan.
 EXPECTED OUTCOME: Return concrete decisions, file paths, dependencies, risks, and evidence requirements.
 REQUIRED TOOLS: Read-only repository exploration, tool readiness checks, LSP/symbol tools, local command checks.
-MUST DO: Read the project-root `MEMORY.md` before doing assigned work. Preserve proper nouns exactly. Prefer repository evidence. Install or bootstrap missing required tools before declaring them unavailable. Identify assumptions. Use `explorer` for read-only discovery and `worker` for bounded implementation or verification when available and useful. When subagent tools are available, allow recursive delegation of bounded sub-tasks. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work. Tell workers they are not alone in the codebase and must not revert others' edits. Use the OS locale for user-visible text.
+MUST DO: Read the project-root `MEMORY.md` before doing assigned work. Preserve proper nouns exactly. Prefer repository evidence. Install or bootstrap missing required tools before declaring them unavailable. Identify assumptions. Treat the user-called/main agent as the orchestrator. Use `explorer` for read-only discovery and `worker` for actual implementation edits or verification when subagent tools are available, regardless of Light Path or Heavy Path. When the subagent tool provides a progress-reporting channel, require subagents to report status to the orchestrator when starting work, when deciding or confirming direction, during periodic progress, and when finishing; the orchestrator must immediately relay received status events to the user. If no mid-run reporting channel exists, relay observable events such as assignment, waiting, and final completion. Require delegated subagents to provide a final report before leaving; after capturing the final report and evidence, close or release the completed subagent, then review the final report and evidence before marking the work complete. If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence. When subagent tools are available, allow recursive delegation of bounded sub-tasks. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work. Tell workers they are not alone in the codebase and must not revert others' edits. Use the OS locale for user-visible text.
 MUST NOT DO: Edit production code. Ask the user. Expand scope. Delegate vague or unbounded work.
 CONTEXT: User request, MEMORY.md, relevant docs/memory notes, applied model guidance, repository root.
 ```

package/skills/cairn-work/SKILL.md

@@ -13,6 +13,12 @@ Execute only one module task at a time. Instead of a repeated red-green loop, pr
 
 Every work run starts by reading the project-root `MEMORY.md` before choosing or executing a task. Every delegated agent must also read the project-root `MEMORY.md` before doing its assigned task.
 
+The user-called/main agent is the orchestrator for work execution: it selects the task, assigns implementation, verifies results, and records evidence. Actual implementation edits belong to `worker` subagents whenever subagent tools are available, regardless of Light Path or Heavy Path.
+
+When the subagent tool provides a progress-reporting channel, subagents report status to the orchestrator when starting work, when deciding or confirming direction, during periodic progress, and when finishing. The orchestrator must immediately relay received status events to the user. If no mid-run reporting channel exists, the orchestrator relays observable events such as assignment, waiting, and final completion.
+
+Delegated subagents must provide a final report before leaving. After the orchestrator captures the final report and evidence, it must close or release the completed subagent, then review the final report and evidence before marking the work complete.
+
 If the user asks a side question, status question, or narrow clarification while the selected task is still active, answer it briefly and then resume the previous active work unless the user explicitly asks to pause, stop, or switch tasks.
 
 When subagent tools are available, each agent may recursively delegate bounded sub-tasks to subagents. Every child subagent must read the project-root `MEMORY.md`, keep the assigned scope, and preserve others' edits.
@@ -26,9 +32,9 @@ When subagent tools are available, each agent may recursively delegate bounded s
 5. Confirm that required LSP, typecheck, lint, dry-run, and verification tools are available from the plan's tool readiness section.
 6. If a required tool is missing, run `node scripts/cairn.mjs toolcheck --install` or the closest repository-native install command, then rerun the tool before continuing.
 7. Confirm the selected Light Path or Heavy Path in the plan. If the plan lacks complexity triage, stop and update the plan before mutating files.
-8. For Light Path, implement directly or delegate to one bounded `worker`; keep the verification gate.
+8. For Light Path, keep the main agent in the orchestrator role and delegate implementation edits to one bounded `worker` whenever subagent tools are available; keep the verification gate.
 9. For Heavy Path, follow the full planning and review pipeline recorded in the plan. Run pre-implementation review before mutation and read-only review after evidence exists.
-10. Delegate implementation to `worker` with exact files, ownership, constraints, and model-specific adjustment rules. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work, keep scope, and preserve others' edits. Use `explorer` for parallel read-only discovery or verification when available and useful. Allow recursive delegation only for bounded sub-tasks when the current surface supports it.
+10. Delegate implementation to `worker` with exact files, ownership, constraints, and model-specific adjustment rules on both Light Path and Heavy Path whenever subagent tools are available. Tell every delegated agent and child subagent to read the project-root `MEMORY.md` before work, keep scope, preserve others' edits, and report status when the subagent tool provides a progress-reporting channel. Immediately relay received status events to the user. If no mid-run reporting channel exists, relay observable events such as assignment, waiting, and final completion. Require delegated subagents to provide a final report before leaving; after capturing final report and evidence, close or release the completed subagent, then review the final report and evidence before marking the work complete. Use `explorer` for parallel read-only discovery or verification when available and useful. Allow recursive delegation only for bounded sub-tasks when the current surface supports it. If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence.
 11. Before mutating external state, run the task dry-run or check command when one is recorded. If none exists, record the absence and continue with the smallest reversible command available.
 12. For Heavy Path, run the recorded automated test command and record explicit `Tests:` evidence before claiming completion.
 13. `worker` must return changed files, tool readiness result, dry-run or check result when applicable, automated test result for Heavy Path, module acceptance command and result, surface integration command or QA artifact, and cleanup notes.
@@ -44,7 +50,7 @@ When subagent tools are available, each agent may recursively delegate bounded s
 TASK: Implement task <task-id> for <topic>.
 EXPECTED OUTCOME: Minimal code or documentation change satisfying the task contract.
 REQUIRED TOOLS: Scoped file editing, tool readiness checks, existing test/build commands, surface QA commands.
-MUST DO: Read the project-root `MEMORY.md` before doing assigned work and follow its policy. Stay within the listed file scope and ownership. Assume you are not alone in the codebase; do not revert others' edits. When subagent tools are available, recursively delegate only bounded sub-tasks and pass these same constraints to every child subagent. Install or bootstrap missing required tools before declaring them unavailable. Run dry-run or check mode before external-state mutation when available. Provide module evidence and surface evidence. Use the OS locale for user-visible text.
+MUST DO: Read the project-root `MEMORY.md` before doing assigned work and follow its policy. Stay within the listed file scope and ownership. Assume you are not alone in the codebase; do not revert others' edits. Treat the user-called/main agent as the orchestrator; delegate actual implementation edits to `worker` whenever subagent tools are available, regardless of Light Path or Heavy Path. When the subagent tool provides a progress-reporting channel, require subagents to report status to the orchestrator when starting work, when deciding or confirming direction, during periodic progress, and when finishing; the orchestrator must immediately relay received status events to the user. If no mid-run reporting channel exists, relay observable events such as assignment, waiting, and final completion. Require delegated subagents to provide a final report before leaving; after capturing final report and evidence, close or release the completed subagent, then review the final report and evidence before marking the work complete. If subagent tools are unavailable, the main agent takes over implementation directly and records that takeover in evidence. When subagent tools are available, recursively delegate only bounded sub-tasks and pass these same constraints to every child subagent. Install or bootstrap missing required tools before declaring them unavailable. Run dry-run or check mode before external-state mutation when available. Provide module evidence and surface evidence. Use the OS locale for user-visible text.
 MUST NOT DO: Ask the user. Skip LSP/typecheck/lint because a tool is missing without attempting installation. Refactor unrelated code. Continue an open-ended verification loop. Treat a side question as permission to abandon the active task. Delegate vague or unbounded work. Claim completion without evidence. Modify files outside the assigned ownership.
 CONTEXT: docs/plan/<topic>.md task, relevant docs/memory notes, applied model guidance, exact files, verification commands.
 ```
@@ -84,6 +90,7 @@ Run the closest available dry-run or check mode before commands that mutate exte
 
 - Both verification gates passed in the current turn.
 - Heavy Path work has explicit automated test evidence in the current plan.
+- Implementation edits were delegated to `worker` when subagent tools were available, or the main agent took over implementation directly and recorded that takeover in evidence when subagent tools were unavailable.
 - Required LSP/check/verification tools were available, installed, or recorded as blockers with attempted commands.
 - Dry-run or check evidence exists when the task could mutate external state, or the plan records why no dry-run exists.
 - The required Light Path or Heavy Path flow was followed.