@ttt-productions/dev-standards 0.0.3 → 0.0.4

package/claude/CLAUDE.base.md

@@ -144,10 +144,12 @@ Before starting a project's work:
 Every release of an `@ttt-productions/*` package hands its adoption to each app through a file in
 `<PACKAGES_REPO>/docs/work/adoptions/<app>/`.
 
-- **The package session writes them.** In the same change as the package edit, before the release
-  command, it writes one adoption file per released package for each app — except an app-data
-  package, whose file goes only to its own app. A package session cannot see which packages the
-  other product installs, so every other released package gets a file for every app.
+- **The package session writes them only for the apps that aren't in the conversation.** In the same
+  change as the package edit, before the release command, it writes one adoption file per released
+  package for each app outside the conversation — an app-data package's file goes only to its own
+  app. A package session cannot see which packages another product installs, so every other released
+  package gets a file for each of those apps. The app the conversation is working in adopts the
+  release itself, right after the install.
 - **The version it names** is the version the release will publish: one patch above the package's
   `package.json` version before the release.
 - **The file** is one item in the `docs/work/` item format (`<DEV_STANDARDS>/work/README.md`) —
@@ -198,9 +200,8 @@ step 5.
 ## The Normal `<APP_NAME>` Flows (named workflows — "do the normal dev/test flow" resolves HERE)
 
 These two named flows are the standing default for how work in these repos is verified and
-sequenced. They are DEFAULTS, not cages: DJ may override any step with explicit in-conversation
-instructions (e.g. "do the normal test flow, but WAIT for my go before starting dev:e2e — I'm
-using the machine"), and an override governs exactly what it names, nothing more. A repo changes a
+sequenced. They are DEFAULTS, not cages: DJ may override any step with an explicit instruction; the
+override governs exactly what it names, for that conversation only. A repo changes a
 flow only under its `<APP_NAME>` additions heading. In a repo whose `<APP_NAME>` is none
 (ttt-packages) the Test Flow does not apply — its gate is its own `CLAUDE.md` § Verification — and
 the Dev Flow's steps 1–4 are its whole share.
@@ -221,9 +222,10 @@ the Dev Flow's steps 1–4 are its whole share.
    (RULE-STD-QUALITY-008 — Claude operates the restart).
 5. Kill `dev:e2e` when done and STOP — wait for DJ's push.
 
-**When the session is orchestrating agents, stages 2–5 belong to ONE agent, never the orchestrator.**
-That agent starts `dev:e2e`, runs the live stages, fixes root causes (restarting the stack per stage
-4), and kills it; the orchestrator only takes its report. "Claude-operated" here means that agent.
+**In a conversation DJ has called an orchestrator, the Normal Test Flow is run by one test agent,
+never the orchestrator.** A failure goes back to the orchestrator, which sends it to the agent that
+built the failing code; that agent fixes it and reports. The same test agent then reruns the flow,
+restarting `dev:e2e` per stage 4. In an inline conversation, the session runs the Test Flow itself.
 
 Not part of this flow: hosted-dev E2E runs (always separately commanded — `<HOSTED_E2E_DOC>`) and
 `npm run dev:local` (DJ's manual dev surface).
@@ -235,29 +237,23 @@ Not part of this flow: hosted-dev E2E runs (always separately commanded — `<HO
    change as the package edit.
 3. ttt-packages `npm run test:quiet` green.
 4. Hand DJ ONLY the release command (`./scripts/release-multiple.sh <folders…> patch`, its own fenced
-   block) — then STOP. No install commands: Claude does the installs.
-5. DJ runs the publish and says so. Claude then starts a 20-minute clock and checks npm every 30
-   seconds until every released package's new version is the `@latest` on npm; then Claude runs the
-   installs itself (`@latest --prefer-online`, at the root and in every consuming folder that declares
-   the package — `<INSTALL_FOLDERS>`), confirms each lockfile names the new version, adopts the
-   adoption files (§ Adoption files), and continues straight into the app work with no further go.
-   While it polls, the session works on whatever does not depend on the release — the publish-wait
-   overlap in `<DEV_STANDARDS>/development-preferences.md` § Shared-package publish.
-   A version still missing from npm after 20 minutes = stop and tell DJ which package; never install
-   anything but the published version.
-   **What "published" means, and what to poll for.** When DJ says "published" (or "publish is
-   running"), he has just RUN the release command: the script is still running and the packages are
-   still building, so nothing may be on npm yet, and the version numbers in the checkout may not be
-   bumped yet. `release-multiple.sh` first runs its `test:quiet` preflight (minutes); then, per package,
-   `release-package.sh` bumps the version, commits `Release <pkg> vX.Y.Z`, tags it, and pushes; the
-   tag triggers ttt-packages' `publish.yml` GitHub Actions job, which builds and publishes to npm. So
-   the version to wait for is the NEW one — one patch above the package's `package.json` version
-   before the release, or the version its `Release <pkg> v…` commit names once that lands — never the
-   `package.json` version in the checkout at the moment DJ speaks, which can still be the old one
-   (compared against npm `@latest`, it reads a stale match as "live"). A version is available only
-   when npm `@latest` names it AND its tarball
-   (`https://registry.npmjs.org/@ttt-productions/<pkg>/-/<pkg>-<version>.tgz`) answers 200: the
-   registry can report the new `@latest` minutes before it serves the tarball, and an install in that
-   gap fails `E404`.
+   block), with one line under it naming the versions it will publish — the same versions its
+   adoption files name, one patch above each package's `package.json` version before the release
+   (e.g. "Publishes chat-core 0.11.8 and chat-react 0.13.20.") — then STOP. No install commands:
+   Claude does the installs.
+5. DJ runs the publish and says so, at any point: the script just started, its preflight still
+   running, or the packages already published and GitHub Actions running. Claude then starts a
+   20-minute clock and checks npm every 30 seconds for exactly the versions named in step 4 — it never
+   re-reads `package.json` or git to find them. A version is available only when npm `@latest` names
+   it AND its tarball (`https://registry.npmjs.org/@ttt-productions/<pkg>/-/<pkg>-<version>.tgz`)
+   answers 200: the registry can report the new `@latest` minutes before it serves the tarball, and
+   an install in that gap fails `E404`. Then Claude runs the installs itself (`@latest
+   --prefer-online`, at the root and in every consuming folder that declares the package —
+   `<INSTALL_FOLDERS>`), confirms each lockfile names the new version, adopts the release in its own
+   app (§ Adoption files), and continues straight into the app work with no further go. While it
+   polls, the session works on whatever does not depend on the release — the publish-wait overlap in
+   `<DEV_STANDARDS>/development-preferences.md` § Shared-package publish. A version still missing from
+   npm after 20 minutes = stop and tell DJ which package; never install anything but the published
+   version.
 6. All `<APP_NAME>` work; when the entire change set is done, run the Normal `<APP_NAME>` Test Flow.
 7. Stop and wait for DJ's push.

package/development-preferences.md

@@ -23,6 +23,16 @@ shared copy, in `@ttt-productions/dev-standards`, that every repo reads.
   it goes. Nothing is filed, parked, or written up without DJ's word.
 - A doc's "staged / later / deferred" label is never DJ's decision; only DJ's own explicit deferral
   parks an item.
+- **DJ's rules live only in his rule docs** — the rulebooks, this file, `CLAUDE.md` / `AGENTS.md`,
+  and the workflows. An instruction DJ gives in a conversation lasts for that conversation only; it
+  becomes a standing rule only when he says to write it into the rules. No plan, work item, ledger,
+  or prompt ever holds a rule, an instruction, or reasoning, and a session never takes a rule from
+  one.
+- **There are no handoff docs.** When DJ asks to get ready for a new conversation, the session gives
+  a small copy-paste prompt in chat that points at the items being worked; the items hold only what
+  is left. The prompt carries nothing else except open questions DJ chose to move. An item whose
+  only remaining work is the Normal Test Flow or a hosted E2E run is deleted; if a conversation
+  switches at that point, the prompt says to run it.
 - "Finish everything" / "do it all" means every single thing DJ has decided, with nothing left
   undone or parked. It never means deciding anything for DJ: when finishing needs a decision he has
   not made, ask that one question and keep doing the rest. Never stop for complexity, size, time of
@@ -51,22 +61,39 @@ shared copy, in `@ttt-productions/dev-standards`, that every repo reads.
 - An answer that REDIRECTS is not approval to build the revision — show the revised artifact in
   chat and get a clean confirm before implementing.
 - No new-conversation or handoff proposals unless DJ asks.
+- **Every question is tracked until DJ answers it.** A question about the item being worked is asked
+  when it is found; the parts of that item that depend on the answer wait, and everything else keeps
+  going. A problem found outside the item never stops work: it is reported in chat with what was
+  verified and a recommendation, and stays open for DJ. When DJ has said he is away, no question
+  blocks: it goes in chat, the session finishes every part that does not depend on it, and moves to
+  the next item.
+- **No Normal Test Flow while any question is open.** An answer can change code, and a test run
+  before it is worthless. The open questions are asked first, any code they change is done, and then
+  the Test Flow runs once.
+- Open questions are asked one at a time, as questions, never buried in a status message. The
+  session never answers, files, or drops one itself.
+- When DJ asks whether the conversation is good to end, or says to start a new one, the session first
+  says how many questions are open and asks whether to answer them here or move them into the new
+  conversation's prompt.
 
 ## Git, publish, deploy, and the dev stacks
 
-- DJ does ALL git: staging, commits, pushes, publishing, installs he has not handed over, and
-  deployments. Hand him exact commands; never run them. Never commit or push. DJ stages files
-  continuously while work is running so he can see what is changing; never treat a staged/unstaged
-  change as a sign of someone else's work, and never bring up staging, the index, or other git state
-  with DJ.
+- DJ does ALL git — staging, commits, pushes, branches, publishing, installs he has not handed over,
+  and deployments. An AI runs none of it unless DJ commands that exact action in the conversation;
+  otherwise it hands him the exact command. DJ stages files continuously while work is running so he
+  can see what is changing; never treat a staged/unstaged change as a sign of someone else's work,
+  and never bring up staging, the index, or other git state with DJ.
+- Git and GitHub (`git log`, `git status`, diffs, `gh`, Actions runs) are read only when DJ says it is
+  needed. A problem DJ brings is fixed from the current code; when and why it changed is not looked
+  up unless he asks.
 - Never instruct DJ to push or deploy — deploy IS `git push`. Never nag about deploys, indexes, or
   seed buttons.
 - Never discard, overwrite, reset, clean, or revert existing work unless DJ explicitly asks.
   Preserve unrelated uncommitted work; DJ or another tool may be working concurrently.
 - `dev:local` (DJ's manual dev stack) is DJ-only, always — never start or stop it.
 - `dev:e2e` (the verification stack) is session-operated only inside the repo's Normal Test Flow or
-  on DJ's explicit command. DJ's in-conversation instruction overrides any flow step ("wait for my go
-  before starting dev:e2e") and governs exactly what it names.
+  on DJ's explicit command. DJ's in-conversation instruction overrides any flow step and governs
+  exactly what it names, for that conversation only.
 - Never kill a running dev stack on your own judgment ("ports look wrong" = say what you see and
   WAIT). Never run e2e against a stale build.
 - Hosted-dev E2E runs happen only when DJ commands one, and follow the repo's hosted-E2E run doc
@@ -130,15 +157,25 @@ shared copy, in `@ttt-productions/dev-standards`, that every repo reads.
 - No half-working, dead, or known-bad code — build it or remove it. On a second sighting of a defect
   class, tell DJ and propose killing the CLASS system-wide plus a regression guard; do it only on
   DJ's command.
+- **Never make yourself an exception.** Code that breaks a rule, guard, or lint check is fixed. An
+  exception is asked for only when there is genuinely no other way, and it goes to DJ with that
+  reason, why no fix works. Nothing is exempted without his yes. Every exception he approves carries
+  its reason at the exception itself, so anyone reading it years later knows at once why it exists:
+  the guard entry's reason field, the comment on the `eslint-disable` / `prettier-ignore` line, or,
+  for a design-level exception, the design doc it belongs to. The reason states why the exception
+  exists, never who approved it.
 - Reviewing an external plan (ChatGPT/Codex/etc.) means answering "is this the BEST code to solve
   my problem" — never just verifying its claims. Evaluate the design space (alternatives, root cause,
   structure) and fold an optimality verdict into the reviewed doc.
 - V1-scope discipline: confirm the trigger exists in V1 before asking DJ to design.
 - Docs stay lean — never a "done" log. Tracking docs hold only remaining work; finished work is
   DELETED.
+- **Working files** a session needs — extracted text, a one-off script, intermediate output — go in
+  `C:\DjDev\claude-scratchpad\<YYYY-MM-DD>-<topic>\`, never in a temp folder, loose in `C:\DjDev`,
+  or inside a repo. A session writes there only when the work needs a file, never for a conversation
+  that is only talking, and deletes its folder when that work is done.
 - Working state that must outlive the session — orchestration ledgers, agent change logs, file
-  claims, handoff notes — is never kept in a temp or scratchpad folder. It lives in the repo beside
-  the work it tracks and is deleted when the work finishes.
+  claims — lives in the repo beside the work it tracks and is deleted when the work finishes.
 - Help with EVERY step, including non-code and operational ones — real artifacts (policies,
   runbooks, click-by-click), never a "your job" checklist. Walk-throughs go one step at a time, dev
   AND prod. A non-code or console step becomes a self-contained Claude web prompt (full context,
@@ -150,6 +187,19 @@ shared copy, in `@ttt-productions/dev-standards`, that every repo reads.
 
 ## Agents
 
+- **Every conversation is inline unless DJ says, in that conversation, that it is an orchestrator.**
+  No doc, plan, ledger, or prompt makes a conversation an orchestrator.
+- **Inline:** the session does the research and the work itself. When a piece of the work would be
+  done better by agents — LOW for mechanical work applied from written examples, HIGH for thinking
+  work or review — it proposes them to DJ with each agent's exact task and files, and launches them
+  only on his yes. Launching agents, a predefined wave included, never makes it an orchestrator; it
+  still runs its own Normal Test Flow.
+- **Orchestrator:** the session saves its context for managing agents and does not read or edit code
+  itself. It first launches read-only agents to understand the system, then gives each building
+  agent the high-level picture and the design: build this, this way. An agent that finds a better or
+  different way stops and comes back instead of building it. Agents run in waves of a few at a time,
+  each owning its files, no file owned twice. LOW agents never decide; they apply the examples the
+  HIGH session gives them.
 - The main session owns edits unless DJ explicitly approves parallel implementers with disjoint file
   ownership. Nothing spawns without DJ's yes.
 - Every prompt that spawns an agent names that agent's mandatory reading as explicit

package/model-tiers.md

@@ -22,5 +22,5 @@ follows the session unless a doc names one.
   task applies a fixed set of written patterns to many files; its prompt names every pattern and
   makes anything outside them a stop that returns to the HIGH session that spawned it. That session
   and its reviewer stay HIGH.
-- **The orchestrator is the session itself** — DJ picks its model when he starts it. Every SPAWNED
+- **The session runs on the model DJ picks when he starts it.** Every SPAWNED
   agent's tier is binding.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@ttt-productions/dev-standards",
-    "version": "0.0.3",
+    "version": "0.0.4",
     "repository": {
         "type": "git",
         "url": "git+https://github.com/ttt-productions/ttt-packages.git",

package/rules/quality/core-rules.md

@@ -77,7 +77,7 @@ A test proves the business rule, never the code's current output: its expected v
 ### RULE-STD-QUALITY-006 — Lint and format: zero suppression in apps, reasoned disables in packages; one enforced format
 **Scope.** both
 
-**Rule.** The lint half is split by scope; the format half is the same for both. **Apps** are zero suppression: no `eslint-disable` comment anywhere in the linted trees — source, Functions, E2E, scripts, and config. When a rule fires, fix the root cause, and solve a genuine false positive structurally — rename, refactor, or scope the rule — never by suppressing the line; external-authority state pruning uses the sanctioned render-phase adjustment, not a suppressed effect. A `warn`-level finding is a finding to fix, and a rule is never turned off, nor `ignores` widened, to pass failing code. New app code also follows the conventions the lint config forces, listed below. **Packages** permit an `eslint-disable-next-line` only for a narrow intentional case, carrying its reason on the line; it is preferred over weakening the rule, and a real violation is fixed at its source.
+**Rule.** The lint half is split by scope; the format half is the same for both. **Apps** are zero suppression: no `eslint-disable` comment anywhere in the linted trees — source, Functions, E2E, scripts, and config. When a rule fires, fix the root cause, and solve a genuine false positive structurally — rename, refactor, or scope the rule — never by suppressing the line; external-authority state pruning uses the sanctioned render-phase adjustment, not a suppressed effect. A `warn`-level finding is a finding to fix, and a rule is never turned off, nor `ignores` widened, to pass failing code. New app code also follows the conventions the lint config forces, listed below. **Packages** permit an `eslint-disable-next-line` only for a narrow intentional case where no fix works, on DJ's yes, carrying its reason on the line; it is preferred over weakening the rule, and a real violation is fixed at its source.
 
 Every code file — source, tests, scripts, and config — is in the one format Prettier writes from the shared Prettier config (this package's `config/prettier.json`); `test:quiet`'s format stage writes that format and then checks it, a check-only run (a package release preflight, `test:all`) only checks, so a release never publishes formatting nobody committed, and the check fails a file that is not formatted; `eslint-config-prettier` keeps ESLint out of formatting. A file is formatted by running Prettier, never reflowed by hand.
 
@@ -92,14 +92,14 @@ Every code file — source, tests, scripts, and config — is in the one format
 - An anonymous React wrapper component returned from a test helper (assign `displayName`).
 - Straight `'`/`"` in JSX text content (use `'`/`"`).
 - Suppressing `exhaustive-deps` instead of fixing at the source (destructure the stable `mutate`; memoize a derived dep; destructure the specific prop fields used).
-- An unformatted code file; a `prettier-ignore` without its reason; an ESLint formatting rule that fights Prettier.
+- An unformatted code file; a `prettier-ignore` without its reason, or added when a fix works or without DJ's yes; an ESLint formatting rule that fights Prettier.
 
 **References.** RULE-STD-ENG-008; this package's `node/eslint` bases and `config/prettier.json`; each repo's ESLint config and `.prettierignore`.
 
 ### RULE-STD-QUALITY-007 — Guard tests enforce ownership and boundaries, never inventories
 **Scope.** both
 
-**Rule.** Structural guard tests (the repo-guards suite each repo runs in its gate — an app's guard suite, ttt-packages' boundary suite) enforce a forbidden boundary or single-owner rule against the current clean baseline — every allowlist entry carrying a one-line justification — so that a NEW regression fails the build. A guard must not mirror an exhaustive list of today's files, exports, packages, or domains: an inventory-mirror breaks on every legitimate addition and audits nothing.
+**Rule.** Structural guard tests (the repo-guards suite each repo runs in its gate — an app's guard suite, ttt-packages' boundary suite) enforce a forbidden boundary or single-owner rule against the current clean baseline — every allowlist entry carrying a one-line justification — so that a NEW regression fails the build. An entry is added only when no fix works, on DJ's yes, with its reason in the entry. A guard must not mirror an exhaustive list of today's files, exports, packages, or domains: an inventory-mirror breaks on every legitimate addition and audits nothing.
 
 **Why.** A brittle inventory-mirror is churn, not enforcement; the value is catching the next violation, not counting the current files.
 
@@ -127,7 +127,7 @@ Every code file — source, tests, scripts, and config — is in the one format
 ### RULE-STD-QUALITY-009 — A test loads the code it tests when its file loads
 **Scope.** both
 
-**Rule.** A test imports the code it tests at the top of its file — a static import, or a top-level `await import()` — never inside a case, a hook, or a helper they call, and never resets the module registry. A case that needs other state gets it without a reload: an environment the code reads at load is set in `vi.hoisted` before the import, per-instance state is cleared through the module's test-only `__reset…()` seam, and a flag the code reads once is read when it is called instead. A file whose fresh module per case is itself what it proves is a reviewed entry with its why, and an entry whose file no longer does is stale. The repo-guards `testCaseModuleLoads` guard enforces it.
+**Rule.** A test imports the code it tests at the top of its file — a static import, or a top-level `await import()` — never inside a case, a hook, or a helper they call, and never resets the module registry. A case that needs other state gets it without a reload: an environment the code reads at load is set in `vi.hoisted` before the import, per-instance state is cleared through the module's test-only `__reset…()` seam, and a flag the code reads once is read when it is called instead. A file whose fresh module per case is itself what it proves is a reviewed entry with its why — an entry is added only when no fix works, on DJ's yes, with its reason in the entry — and an entry whose file no longer does is stale. The repo-guards `testCaseModuleLoads` guard enforces it.
 
 **Why.** A module's first load pulls its whole graph; inside a case that cold load is timed as the case's own work, so a file's first case was slow for nothing it did and, under the full parallel run, crossed its timeout.
 

package/workflows/claude/fan-out-implementation.md

@@ -13,8 +13,11 @@ description: Claude Code workflow (Build or fix). Use when the work is big enoug
 
 ## Before anything spawns
 
-1. The normal preflight, plus the routed rules and `docs/design/*.md` for every area involved.
-2. Re-verify the work against the current code.
+1. The normal preflight. This session saves its context for managing agents and does not read or
+   edit code itself (`<DEV_STANDARDS>/development-preferences.md` § Agents).
+2. Launch read-only agents to read the routed rules, the `docs/design/*.md` for every area involved,
+   and the current code, and report the system back; the design each building agent gets comes from
+   their reports.
 3. Propose to DJ: the number of agents and each one's exact scope and owned files. Nothing spawns
    without DJ's yes.
 4. App-side work: confirm every shared package it depends on is at `@latest` first. Package work and
@@ -22,12 +25,13 @@ description: Claude Code workflow (Build or fix). Use when the work is big enoug
 
 ## Every spawned prompt
 
+- The high-level picture and the design to build: build this, this way.
 - The agent's exact scope and owned files, and its mandatory reading as explicit read-before-acting
   paths: the routed rule files (shared and the app's) and `docs/design/*.md` for its area
   (RULE-STD-ENG-010).
 - A hard ban on spawning agents.
-- A kill-and-escalate clause: a needed package change, or anything unexpected → stop and report to
-  this session.
+- A kill-and-escalate clause: a needed package change, a better or different way than the design,
+  or anything unexpected → stop and report to this session.
 - Targeted tests only, on its own work.
 - Tier per `<DEV_STANDARDS>/model-tiers.md` (implementation agents; a mechanical-only part uses
   `mechanical-fan-out.md` instead).
@@ -37,7 +41,7 @@ description: Claude Code workflow (Build or fix). Use when the work is big enoug
 - Adversarial review agents at the HIGH tier over the landed work, each also checking every new or
   changed test against the business rule it claims to prove (RULE-STD-QUALITY-001; testing-coverage
   playbook).
-- Exactly ONE final full gate after every agent has landed: the Normal `<APP_NAME>` Test Flow. Its
-  live stage (start `dev:e2e`, run, fix, restart, kill) belongs to ONE agent, never this session —
-  this session takes its report.
+- Exactly ONE final full gate after every agent has landed: the Normal `<APP_NAME>` Test Flow, run
+  as `<DEV_STANDARDS>/claude/CLAUDE.base.md` § The Normal `<APP_NAME>` Flows says for an
+  orchestrator.
 - Delete the finished `docs/work/` items and the ledger, then stop for DJ's push.

package/workflows/claude/fix-known-errors-inline.md

@@ -25,7 +25,9 @@ description: Claude Code workflow (Build or fix). Use when DJ wants known, decid
   Normal `<APP_NAME>` Dev Flow (`<DEV_STANDARDS>/claude/CLAUDE.base.md`).
 - Every fix ships a regression test that fails before the fix and proves the business rule
   (RULE-STD-QUALITY-001). Design docs the fix changes are updated in the same change.
-- A large mechanical change found along the way → `mechanical-fan-out.md`, which asks DJ first.
+- A piece of the work agents would do better → propose LOW or HIGH agents for it to DJ, staying
+  inline (`<DEV_STANDARDS>/development-preferences.md` § Agents); a large mechanical change uses
+  `mechanical-fan-out.md`.
 
 ## Finishing
 

package/workflows/claude/implement-an-approved-plan.md

@@ -23,8 +23,9 @@ description: Claude Code workflow (Build or fix). Use when a multi-task plan DJ
 
 - Packages-first: every package-side task in the plan lands, gates, and is released before any
   app-side task (Normal `<APP_NAME>` Dev Flow, `<DEV_STANDARDS>/claude/CLAUDE.base.md`).
-- Build inline. Large mechanical parts → `mechanical-fan-out.md`; big parallel thinking work →
-  propose `fan-out-implementation.md` to DJ.
+- Build inline. A piece of the work agents would do better → propose LOW or HIGH agents for it to
+  DJ, staying inline (`<DEV_STANDARDS>/development-preferences.md` § Agents); large mechanical parts
+  use `mechanical-fan-out.md`.
 - Approval covers exactly the approved tasks — no adjacent refactors.
 - Every task ships its regression test (RULE-STD-QUALITY-001) and its doc updates.
 

package/workflows/claude/mechanical-fan-out.md

@@ -34,5 +34,5 @@ through this; it stays inline or goes to `fan-out-implementation.md`.
 5. **One HIGH reviewer** checks all the agents' changes together once every agent is done: each
    change matches a listed pattern, nothing outside the patterns slipped in, and every new or changed
    test proves the business rule it claims, not the code's current output (RULE-STD-QUALITY-001).
-6. **One final gate.** Back in the calling workflow: the Normal Test Flow once, for the whole change
-   set. Its live stage belongs to ONE agent, never the orchestrating session.
+6. **One final gate.** Back in the calling workflow: the inline session runs the Normal Test Flow
+   once, for the whole change set.

package/workflows/claude/work-a-project-step.md

@@ -21,8 +21,9 @@ description: Claude Code workflow (Build or fix). Use when DJ names a step of a
 3. Work the step, or one focused slice of it. A step with a publish stop: ALL its package work first,
    then the release command, per the Normal `<APP_NAME>` Dev Flow
    (`<DEV_STANDARDS>/claude/CLAUDE.base.md`).
-4. Large mechanical parts → `mechanical-fan-out.md`; big parallel work → propose
-   `fan-out-implementation.md` to DJ.
+4. A piece of the work agents would do better → propose LOW or HIGH agents for it to DJ, staying
+   inline (`<DEV_STANDARDS>/development-preferences.md` § Agents); large mechanical parts use
+   `mechanical-fan-out.md`.
 5. The Normal `<APP_NAME>` Test Flow, once, on the change set.
 6. Delete each finished item from the step's work doc. When the step is done, delete its folder and
    its section in `PLAN.md` — never renumber.