Fox #95 #96 #99 #153 (#271)

Author: antoineatstariongroup

.claude/commands/implement-extensions-batch.md

@@ -51,6 +51,38 @@ stub-blocker test pattern (see template) when an in-scope test would otherwise
 need to traverse a still-stubbed upstream method that is NOT part of the current
 batch.
 
+## Pre-flight: detect orchestrator plan mode
+
+If the orchestrator session is itself in **plan mode** at the moment
+`/implement-extensions-batch` runs, spawned sub-agents (researchers, implementers,
+testers, reviewers) inherit that state. The Agent tool's `mode: "acceptEdits"`
+parameter does NOT override the inherited plan-mode state on the current Claude
+Code build — sub-agents will respect the `<system-reminder>` that declares plan
+mode and refuse to apply any edits, even though their prompts tell them to.
+
+Symptom: every sub-agent reports "ready to execute on exit from plan mode" and
+writes its work to its own per-agent plan file at
+`C:\Users\<user>\.claude\plans\<plan-name>-agent-<id>.md` instead of to the
+target file.
+
+Before spawning any sub-agent, check whether plan mode is active in the
+orchestrator session. If it is:
+
+1. **Stop** and surface the situation to the user with `AskUserQuestion`. Two
+   options:
+   - **Exit plan mode first** (user toggles their harness off plan mode, then
+     re-invokes the command). Cleanest.
+   - **Proceed in degraded mode**: spawn researchers as normal (they only need
+     to write to `.team-notes/`, which the orchestrator can copy into place
+     from their per-agent plan files if blocked). For Phase IT (implementers +
+     testers) and Phase RV (reviewers), the orchestrator applies the
+     production / test edits itself, reading each implementer's plan file to
+     extract the verbatim code. Reviewers can still run read-only.
+
+2. If the user picks degraded mode, set an internal `PLAN_MODE_DEGRADED=true`
+   flag for the run and follow the per-phase divergences in the **Notes for
+   the orchestrator** block below.
+
 ## Workflow
 
 ### 1. Parse `$ARGUMENTS` and validate the batch
@@ -310,6 +342,8 @@ Print to the user:
 | Sibling test failure in regression sweep | Step 11 | Dispatch a regression-sweep tester per touched fixture; in scope. |
 | Reviewer NEEDS FIX | Step 12 | Re-dispatch implementer or tester for that file only; other files' results still reported. |
 | One file's implementation fails after branch + assignment | Any step ≥ 6 | Keep the branch; surface in final summary; user decides whether to retry via `/implement-extensions` for that single file or revert. |
+| Sub-agent inherits orchestrator plan mode and refuses to edit | Phases R / IT / RV | Surface to user via `AskUserQuestion`. Either exit plan mode and retry, or proceed in degraded mode (orchestrator copies researcher specs from agent plan files into `.team-notes/`, applies implementer + tester code from agent plan files, runs reviewers as read-only). |
+| Agent's `mode: "acceptEdits"` parameter does not override inherited plan mode | Phases IT / RV | Known limitation of this Claude Code build. The orchestrator must apply the edits itself in degraded mode (see "Pre-flight: detect orchestrator plan mode"). |
 
 ## Parallelism caps (orchestrator self-enforced)
 
@@ -339,3 +373,25 @@ Print to the user:
 - If the user supplies a single file, route them to `/implement-extensions`
   with the same filename rather than creating a degenerate 1-file "batch"
   branch.
+- **Plan-mode degraded mode** (`PLAN_MODE_DEGRADED=true`):
+  - **Phase R**: researchers will write to per-agent plan files instead of
+    `.team-notes/`. After each returns, copy its plan file from
+    `C:\Users\<user>\.claude\plans\<plan-name>-agent-<id>.md` into
+    `.team-notes/<foo>-extensions-spec.md` and verify content matches the
+    schema the template expects.
+  - **Phase IT**: implementers + testers will write to per-agent plan files,
+    NOT to the production / test fixtures. The orchestrator reads each
+    agent's plan file, extracts the verbatim code, and applies the edits
+    itself via `Edit` / `Write`. Build + targeted tests still run in
+    Phase V. Do NOT mark Phase IT complete on the sub-agent's "ready to
+    execute" message alone — only after the orchestrator has applied each
+    file's diffs and the build is green.
+  - **Phase RV**: reviewers operate read-only, so plan mode does not block
+    them. No degradation needed.
+  - **Sanity check**: in degraded mode, the orchestrator does roughly 2× the
+    work it would in normal mode. Budget for it — do not silently fall
+    behind on Phase V verification just because Phase IT cost more turns.
+- The Agent tool's `mode` parameter cannot reliably escape inherited plan mode
+  on this Claude Code build. The orchestrator MUST detect plan mode at
+  pre-flight and pick the degraded-mode branch deliberately rather than
+  assuming `mode: "acceptEdits"` will work.

.claude/commands/implement-extensions.md

@@ -45,6 +45,39 @@ This is the user-memory `feedback_scope_discipline.md` rule. Even when an adjace
 stub blocks dependent test coverage, surface the blocker; do not silently expand
 scope. Use the stub-blocker test pattern (see template).
 
+## Pre-flight: detect orchestrator plan mode
+
+If the orchestrator session is itself in **plan mode** at the moment
+`/implement-extensions` runs, spawned sub-agents (researcher, implementer, tester,
+reviewer) inherit that state. The Agent tool's `mode: "acceptEdits"` parameter
+does NOT override the inherited plan-mode state on the current Claude Code build
+— sub-agents will respect the `<system-reminder>` that declares plan mode and
+refuse to apply any edits, even though their prompts tell them to.
+
+Symptom: every sub-agent reports "ready to execute on exit from plan mode" and
+writes its work to its own per-agent plan file at
+`C:\Users\<user>\.claude\plans\<plan-name>-agent-<id>.md` instead of to the
+target file.
+
+Before spawning any sub-agent, check whether plan mode is active in the
+orchestrator session. If it is:
+
+1. **Stop** and surface the situation to the user with `AskUserQuestion`. Two
+   options:
+   - **Exit plan mode first** (user toggles their harness off plan mode, then
+     re-invokes the command). Cleanest.
+   - **Proceed in degraded mode**: spawn the researcher as normal (it only
+     needs to write to `.team-notes/`, which the orchestrator can copy into
+     place from the agent's plan file if blocked). For the step-6 implementer
+     + tester pair and the step-9 reviewer, the orchestrator applies the
+     production / test edits itself, reading each sub-agent's plan file to
+     extract the verbatim code. The reviewer is already read-only and runs
+     unaffected.
+
+2. If the user picks degraded mode, set an internal `PLAN_MODE_DEGRADED=true`
+   flag for the run and follow the per-step divergences in the **Notes for
+   the orchestrator** block at the bottom of this file.
+
 ## Workflow
 
 ### 1. Validate input
@@ -421,3 +454,31 @@ unresolved findings are separately surfaced in the final-summary report. The
   implementation state of the file; unresolved findings are separately surfaced
   in the final-summary report. The `gh issue edit` push must touch ONLY the
   `### Checklist` section — verify with a re-fetch + diff before reporting "done".
+- **Plan-mode degraded mode** (`PLAN_MODE_DEGRADED=true` — set in the pre-flight
+  step at the top of this file):
+  - **Step 5 (researcher)**: the researcher will write its spec to a per-agent
+    plan file under `C:\Users\<user>\.claude\plans\<plan-name>-agent-<id>.md`
+    instead of `.team-notes/<foo>-extensions-spec.md`. After it returns, copy
+    the agent plan file into `.team-notes/<foo>-extensions-spec.md` and verify
+    the content matches the schema in `.claude/team-templates/extension-impl.md`.
+  - **Step 6 (implementer + tester)**: both will write their final production
+    / test code to per-agent plan files, NOT to `{{PRODUCTION_FILE}}` /
+    `{{TEST_FILE}}`. The orchestrator reads each agent's plan file, extracts
+    the verbatim code, and applies the edits itself via `Edit` / `Write`.
+    Step 7's `dotnet build` + targeted `dotnet test` then runs against the
+    orchestrator-applied diffs as normal. Do NOT mark step 6 complete on the
+    sub-agent's "ready to execute" message alone — only after the orchestrator
+    has applied each file's diffs and the build is green.
+  - **Step 8 (regression sweep)**: same as step 6 — the regression-sweep
+    tester writes to a per-agent plan file; orchestrator applies the diffs to
+    each touched sibling fixture itself.
+  - **Step 9 (reviewer)**: read-only, so plan mode does not block it. No
+    degradation needed.
+  - **Sanity check**: in degraded mode, the orchestrator does roughly 2× the
+    work it would in normal mode (it now applies the edits the sub-agents
+    would otherwise apply themselves). Budget for it — do not silently fall
+    behind on step-7 verification just because step 6 cost more turns.
+- The Agent tool's `mode` parameter cannot reliably escape inherited plan mode
+  on this Claude Code build. The orchestrator MUST detect plan mode at
+  pre-flight and pick the degraded-mode branch deliberately rather than
+  assuming `mode: "acceptEdits"` will work.

.claude/team-templates/extension-impl.md

@@ -80,6 +80,31 @@ Don't use this template when:
                  fixtures that now fail get updated as part of the same PR.
 ```
 
+## Plan-mode-aware prompting (added 2026-05-28)
+
+If the orchestrator session is in plan mode when this template is used, sub-agents
+will inherit it and cannot apply edits. The Agent-tool `mode: "acceptEdits"`
+parameter does NOT override the inherited state on the current Claude Code build.
+
+Role prompts in this template are written so that the orchestrator can fall back
+to applying edits itself when this happens:
+
+- **Researcher** prompts always direct the agent to write the spec to its
+  declared `{{NOTES_FILE}}` location. In plan-mode-degraded runs the agent will
+  write to a per-agent plan file under
+  `C:\Users\<user>\.claude\plans\<plan-name>-agent-<id>.md` instead; the
+  orchestrator then copies it to `.team-notes/`.
+- **Implementer / tester** prompts must emit the verbatim production / test code
+  in their text response (or, equivalently, in their per-agent plan file) so it
+  survives a plan-mode block. The orchestrator extracts and applies it via
+  `Edit` / `Write`.
+- **Reviewer** prompts are already read-only and unaffected by plan mode.
+
+The `/implement-extensions-batch` command body documents the degraded-mode flow
+end-to-end in its "Pre-flight: detect orchestrator plan mode" section. The
+single-file `/implement-extensions` command should also adopt the same flow —
+see that file's notes section.
+
 ## Hard scope-discipline rule (v2)
 
 **Honor user-memory `feedback_scope_discipline.md`**: when the task names a single

CLAUDE.md

@@ -154,7 +154,7 @@ Auto-generated DTOs use structured namespaces reflecting the KerML/SysML package
 - Use 'StringBuilder.Append(char)' instead of 'StringBuilder.Append(string)' when the input is a constant unit string
 - Prefer 'string.IsNullOrWhiteSpace' over 'string.IsNullOrEmpty' when checking the non-nullable value of a string
 - Prefer switch expressions/statements over if-else chains when applicable
-- Prefer indexer syntax (e.g., 'list[^1]') and range syntax (e.g., 'array[1..^1]') over LINQ methods (e.g., 'list.Last()', 'list.Skip(1).Take(n)') when applicable
+- Prefer LINQ as much as possible — including for projection / filter / aggregation over collections (`items.Where(...).Select(...).ToList()`, `result.AddRange(items.Select(...))`, `items.Any(predicate)`, etc.) instead of hand-rolled `foreach` + `if` + `.Add()` loops. The ONE exception is straightforward positional or range access on a concrete `List`/array: `list[^1]` beats `list.Last()`, `array[1..^1]` beats `array.Skip(1).SkipLast(1)` — indexer/range syntax is more performant there. Outside that narrow exception, LINQ wins for clarity AND maintainability.
 - Prefer C# collection expressions (`[a, b, c]`, `[..xs]`, `[]`) over `new[] { ... }`, `new List<T> { ... }`, `new T[] { ... }` when constructing a collection. Applies to both production code AND tests (e.g. `Is.EqualTo([classifier1, classifier2])` not `Is.EqualTo(new[] { classifier1, classifier2 })`, `return [];` not `return new List<T>();`). Fall back to explicit construction only when type inference cannot pick the right collection type.
 - Use meaningful variable names instead of single-letter names in any context (e.g., 'charIndex' instead of 'i', 'currentChar' instead of 'c', 'element' instead of 'e')
 - Use 'NotSupportedException' (not 'NotImplementedException') for placeholder/stub methods that require manual implementation