@mmerterden/multi-agent-pipeline 20.2.0 → 20.3.0

package/pipeline/multi-agent-refs/analysis/synthesis.md

@@ -89,11 +89,10 @@ For each `platform` in `state.analysisSpec.platforms[]`:
 2. **Apply per-platform omission rules.** Backend-only file drops Sections 5, 6, 7, 8, 16. Web with no UI inventory still keeps 5 (UI exists in code). Sections 1, 2, 4, 9, 13, 14, 20, 21 always present per Locked decision 2 + 13; their numbers are canonical and never re-flowed.
 3. **Resolve the section set from evidence, not from a mode.** There is one
    pipeline. A section renders when it has evidence and is dropped when it does
-   not, per Locked 2. Lite mode used to answer this question with a fixed list
-   (1, 2, 4, 9, 13, 14, 21 plus optional 23) chosen by a three-signal score, and
-   that list fought Locked 2 in both directions: a small feature with rich
-   business rules lost Section 15 because it was not on the list, and a feature
-   with no API contract kept Section 9 because it was. Evidence decides now.
+   not, per Locked 2. A fixed section list chosen by a size score would fight
+   Locked 2 in both directions: a small feature with rich business rules would
+   lose Section 15 for not being on the list, and a feature with no API contract
+   would keep Section 9 for being on it.
 4. **Produce YAML front-matter header** (see `$HOME/.claude/multi-agent-refs/analysis-template.md`). Include `profile: <state.analysisSpec.profile | global>` and `platform: <platform | none>` so the validator applies the right contract per profile (Locked 31) and recognises the stack-optional render (Locked 34), plus `ui_tests: <state.analysisSpec.options.uiTests | false>`, `a11y_depth: <state.analysisSpec.options.a11yDepth | basic>` and `redesign: <state.analysisSpec.options.redesign | false>` so the pre-dispatch validator can enforce the opt-in coverage (15.6 present when ui_tests, 16.2 walkthrough present when a11y_depth is full, 4.5 / 4.6 / 9.5 present when redesign). `status` is written only by `/multi-agent:analysis-resolve`; a rendered document is a draft.
 5. **Read conventions for this platform's repo.** For each cell Pass B fills in Section 13 and in any per-platform projection (Sections 5, 6, 7, 8, 10, 11, 13, 14, 15, 16, 17), read `state.analysisSpec.evidence.conventions[<repo>].<field>` and emit the value with a footnote (Locked 24). If `conventionOverrides` has an entry for that field, use the override and footnote with `^[user-override: <reason>]` instead of evidence path.
 6. **Concatenate non-null sections in canonical order.** Each rendered section keeps its canonical template number, so omitted sections DO leave gaps - `1, 2, 4, 9, 13, 14, 21` is a correct rendered document. Locked 30 cites sections by number across the whole document; re-flowing them would break every one of those references.

package/pipeline/multi-agent-refs/analysis-template.md

@@ -1,5 +1,5 @@
 ---
-description: "v3 canonical template for /multi-agent:analysis. 23 sections. Platform-agnostic concept layer (Pass A) projected per-platform with repo-driven naming (Pass B). Includes Lite mode for small features."
+description: "v3 canonical template for /multi-agent:analysis. 23 sections. Platform-agnostic concept layer (Pass A) projected per-platform with repo-driven naming (Pass B). Sections are chosen from evidence by the omission table."
 ---
 
 # Analysis Template v3 - 23 Sections
@@ -10,18 +10,11 @@ description: "v3 canonical template for /multi-agent:analysis. 23 sections. Plat
 
 > **Language**: This file is read as a system prompt. Prose stays English. Example tables and headings carry bilingual TR / EN scaffolds; the runtime renderer picks the right column per `outputLanguage`.
 
-> **Locked decisions that govern this template**: the canonical numbered list lives in `$HOME/.claude/commands/multi-agent/analysis/SKILL.md` (cite decisions by label, not by a number duplicated here, to avoid drift). The template's structure is shaped chiefly by: one-feature-per-run, section omission rule, citation discipline (incl. annotation-as-copy), forward-looking spec, humanizer punctuation policy, standards binding, per-platform output split, repo-evidence reuse-first, Figma 3-tier access, Gherkin user stories, Goals + Non-Goals paired, SVG default, Files-to-Add tag, API response variants exhaustive, screenshots embedded, all Figma variants drilled, localization mode (ownership-aware), References at bottom, platform-agnostic + Pass B render, convention extraction, Pass B footnote mandatory, Lite mode, SwiftUI Preview block (iOS), variant usage explicit, analysis self-contained (no MCP downstream), and business-rule to acceptance-criterion to test traceability.
+> **Locked decisions that govern this template**: the canonical numbered list lives in `$HOME/.claude/commands/multi-agent/analysis/SKILL.md` (cite decisions by label, not by a number duplicated here, to avoid drift). The template's structure is shaped chiefly by: one-feature-per-run, section omission rule, citation discipline (incl. annotation-as-copy), forward-looking spec, humanizer punctuation policy, standards binding, per-platform output split, repo-evidence reuse-first, Figma 3-tier access, Gherkin user stories, Goals + Non-Goals paired, SVG default, Files-to-Add tag, API response variants exhaustive, screenshots embedded, all Figma variants drilled, localization mode (ownership-aware), References at bottom, platform-agnostic + Pass B render, convention extraction, Pass B footnote mandatory, SwiftUI Preview block (iOS), variant usage explicit, analysis self-contained (no MCP downstream), and business-rule to acceptance-criterion to test traceability.
 
-## Mode selection - Full vs Lite
+## Section selection
 
-The renderer picks Full or Lite mode automatically based on signals captured in Phase 1, or honours an explicit `--lite` flag from the user.
-
-| Mode | Sections | When |
-|---|---|---|
-| Full | all 23 | Default. Used when feature has multi-screen flow, external service contracts, or complex business rules. |
-| Lite | 8 of 23: 1, 2, 4, 9, 13, 14, 21, 23 | Used when (a) Confluence spec < 100 lines AND (b) Figma frames <= 1 AND (c) repo evidence direct-match >= 8. Manual override: user passes `--lite`. |
-
-Lite mode sections retain the same scaffold as Full mode; only the section set is reduced.
+There is one mode. Every run renders against all 23 sections, and the section omission table below (Locked 2) drops each section that has no evidence, plus the default-drop sections (18, 19, 22) when their render condition is not met. A small feature therefore gets a short document because it has little evidence, not because a size score picked a fixed list: a fixed list drops Section 15 from a small feature with rich business rules, and keeps Section 9 for a feature with no API contract.
 
 ## Section duplication mode per platform (A3 hybrid)
 
@@ -31,7 +24,7 @@ Locked 9 - one file per selected platform under `analysis/<feature>-<platform>.m
 |---|---|---|
 | Shared verbatim | 1, 2, 3, 4, 9, 21 | Identical content in every per-platform file. Pass A renders once, Pass B copies verbatim. |
 | Per-platform projection | 5, 6, 7, 8, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 | Logical content shared; expressions (class names, paths, code snippets, test framework, identifier patterns) projected per platform from Phase 1c conventions. |
-| Footer | 22, 23 | Optional in Lite mode. In Full mode, identical across platforms. |
+| Footer | 22, 23 | Optional (see the omission table). When rendered, identical across platforms. |
 
 Backend-only run drops Sections 5 (Design), 6 (Components), 7 (Tokens), 8 (Assets), 10 (Localization keys can omit if no server-rendered text), 11 (Analytics if no backend telemetry), 12 (Deeplink/Push if no outgoing contracts), 16 (Accessibility N/A), 17 (subset: server-side input validation only).
 
@@ -45,7 +38,7 @@ feature: <FeatureName>
 platform: ios | android | web | backend | mobile | none
 profile: global | corporate
 language: tr | en
-mode: full | lite
+mode: full
 status: draft | final
 redesign: true | false
 ui_tests: true | false
@@ -106,10 +99,10 @@ Locked 2 - no `TBD` / `Not applicable` placeholder. Sections with zero evidence
 | 15 Test Plan | Backend-only run with no contract testing planned (rare) |
 | 16 Accessibility | Backend-only (no UI surface) |
 | 17 Security | No PII / auth / health data touched (rare, document explicit decision) |
-| 18 Rollout | Lite mode. In Full mode render the compact checklist only (not prose); drop if the pipeline's own commit/PR/rollout phase already covers it and no staged rollout / feature flag applies |
+| 18 Rollout | Render the compact checklist only (not prose); drop if the pipeline's own commit/PR/rollout phase already covers it and no staged rollout / feature flag applies |
 | 19 Alternatives | Default drop. Render ONLY when a real architectural decision with 2+ genuine options exists; a thin or invented alternatives list is worse than none (a real decision point already lives in Section 20) |
 | 22 Glossary | Default drop. Render ONLY on explicit request or when the doc uses more than 5 domain-specific terms a new reader would not know; otherwise define terms inline |
-| 23 Changelog | Lite mode (optional even in Full for small revisions) |
+| 23 Changelog | Optional for small revisions |
 
 Sections 1, 2, 4, 9, 13, 14, 20, 21 are never omitted.
 
@@ -278,7 +271,7 @@ Locked 30 - the traceability spine. Every business rule is deterministic and tes
 | Unwanted | `IF <unwanted condition> THEN THE SYSTEM SHALL <behaviour>` | error and edge handling |
 | Optional | `WHERE <feature is included> THE SYSTEM SHALL <behaviour>` | applies only to some configurations |
 
-EARS states the rule; Gherkin states how you check it. Each rule still maps to at least one acceptance criterion written Given / When / Then. In Full mode each acceptance criterion is then realized as unit-test scenarios in Section 15.1; in Lite mode Section 15 is not rendered, so the acceptance criterion stands alone here (it is itself the testable statement) and the 15.1 mapping is deferred to a later Full analysis or to the dev run itself. Rules come from the spec / Confluence / Jira / annotations, never invented; a rule with no source cites `[label TBD - see Open Questions]` and adds a Section 20 row.
+EARS states the rule; Gherkin states how you check it. Each rule still maps to at least one acceptance criterion written Given / When / Then. Each acceptance criterion is then realized as unit-test scenarios in Section 15.1. Section 15 renders whenever there is evidence for it, and the traceability gate applies to whatever was rendered. Rules come from the spec / Confluence / Jira / annotations, never invented; a rule with no source cites `[label TBD - see Open Questions]` and adds a Section 20 row.
 
 | BR ID | Kural / Rule (deterministic, testable) | Kaynak / Source | Kabul kriteri / Acceptance criterion (Given/When/Then) |
 |---|---|---|---|
@@ -987,7 +980,7 @@ These row types are exactly what `build-references.mjs` emits, and the example i
 
 ## 22. Sözlük / Glossary
 
-Footer. Optional in Lite mode. Alphabetical.
+Footer. Default drop (see the omission table). Alphabetical.
 
 ```markdown
 ## 22. Sözlük   <!-- TR -->

package/pipeline/multi-agent-refs/channels/jira.md

@@ -201,7 +201,7 @@ In multi-repo mode, `channels-multi-repo.sh render-jira <state> <body>` prepends
 Token comes from `prefs.global.keychainMapping.jira` → `~/.claude/lib/credential-store.sh get "$ACCOUNT_JIRA_TOKEN_KEY"`. Resolution path:
 
 1. Read `keychainMapping.jira` from prefs.
-2. Resolve via `credential-store.sh get`  -  the driver auto-delegates to `keychain.py` on macOS / Linux and PowerShell `CredentialManager` on Windows.
+2. Resolve via `credential-store.sh get`  -  the driver auto-delegates to `keychain.py`.
 3. Missing → adapter prompts the inline Token Save Flow from `setup.md` (clipboard-based); user can save now or skip this run.
 4. Expired (401) → same Save Flow with the "expired" trigger; on skip, returns `{status: "skipped", reason: "token expired"}`, does not block other adapters.
 

package/pipeline/multi-agent-refs/component-dispatch.md

@@ -120,9 +120,9 @@ On failure (the plugin skill returns an unrecoverable build/test error, or the d
 
 ## Cross-CLI behaviour (intentional divergence)
 
-Component dispatch is **no longer byte-identical across CLIs** and that is by design (see `cross-cli-contract.md` section 1.1):
+Component dispatch is **not byte-identical across CLIs**, by design (see `cross-cli-contract.md` section 1.1):
 
 - **Claude Code**: dispatches to the enabled `ai-<platform>-toolkit` marketplace plugin via the Skill tool (this doc).
-- **Copilot CLI**: has no plugin loader; it continues to use its standalone `~/.copilot/skills/figma-*` skill copies (frozen fallback). Copilot's resolution + progress lines follow those local skills.
+- **Copilot CLI**: has no plugin loader; `install/copilot.mjs` copies the enabled stack plugin's skills into `~/.copilot/skills/`, and Copilot's resolution + progress lines follow those local copies.
 
-What still MUST match across CLIs: the `taskType === "component"` classification, the `state.phases["2"].subphases[]` shape the dispatch layer writes, and the Short-run elision semantics. Figma-skill *inventory* parity is no longer enforced. `smoke-cross-cli-behavior.sh` asserts only the classification + state-shape axis for components.
+What still MUST match across CLIs: the `taskType === "component"` classification and the `state.phases["2"].subphases[]` shape the dispatch layer writes. Figma-skill *inventory* parity is not enforced. `smoke-cross-cli-behavior.sh` asserts only the classification + state-shape axis for components.

package/pipeline/multi-agent-refs/conventions-defaults.md

@@ -57,64 +57,64 @@ Apply platform default + open Section 20 risk row
 
 | Platform | Default pattern | Example |
 |---|---|---|
-| iOS | `<Feature>ViewModel` | `PassengerFlightViewModel` |
-| Android | `<Feature>ViewModel` | `PassengerFlightViewModel` |
+| iOS | `<Feature>ViewModel` | `OrderSummaryViewModel` |
+| Android | `<Feature>ViewModel` | `OrderSummaryViewModel` |
 | Backend | not applicable | (services replace state holders) |
-| Web | `use<Feature>` hook | `usePassengerFlight` |
+| Web | `use<Feature>` hook | `useOrderSummary` |
 
 ### C2b viewNaming
 
 | Platform | Default pattern | Example |
 |---|---|---|
-| iOS | `<Feature>View` | `PassengerFlightView` |
-| Android | `<Feature>Screen` | `PassengerFlightScreen` |
+| iOS | `<Feature>View` | `OrderSummaryView` |
+| Android | `<Feature>Screen` | `OrderSummaryScreen` |
 | Backend | not applicable | |
-| Web | `<Feature>Page` | `PassengerFlightPage` |
+| Web | `<Feature>Page` | `OrderSummaryPage` |
 
 ### C2c navigatorNaming
 
 | Platform | Default pattern | Example | Notes |
 |---|---|---|---|
-| iOS | `<Feature>Coordinator` | `PassengerFlightCoordinator` | Conforms to `<Domain>Router` protocol if present |
-| Android | `<Feature>Navigator` | `PassengerFlightNavigator` | Compose Navigation destination |
+| iOS | `<Feature>Coordinator` | `OrderSummaryCoordinator` | Conforms to `<Domain>Router` protocol if present |
+| Android | `<Feature>Navigator` | `OrderSummaryNavigator` | Compose Navigation destination |
 | Backend | not applicable | | |
-| Web | route file under `app/` | `app/passenger-flight/page.tsx` | Next.js App Router default |
+| Web | route file under `app/` | `app/order-summary/page.tsx` | Next.js App Router default |
 
 ### C2d useCaseNaming
 
 | Platform | Default pattern | Example |
 |---|---|---|
-| iOS | `<Verb><Feature>UseCase` | `FetchPassengerFlightUseCase` |
-| Android | `<Verb><Feature>UseCase` | `FetchPassengerFlightUseCase` |
-| Backend | `<Feature>Service` | `PassengerFlightService` |
-| Web | hook with side effect | `usePassengerFlightQuery` |
+| iOS | `<Verb><Feature>UseCase` | `FetchOrderSummaryUseCase` |
+| Android | `<Verb><Feature>UseCase` | `FetchOrderSummaryUseCase` |
+| Backend | `<Feature>Service` | `OrderSummaryService` |
+| Web | hook with side effect | `useOrderSummaryQuery` |
 
 ### C2e repositoryNaming
 
 | Platform | Default pattern | Example |
 |---|---|---|
-| iOS | `<Feature>Repository` (protocol) + `<Feature>RepositoryImpl` (class) | `PassengerFlightRepository`, `PassengerFlightRepositoryImpl` |
+| iOS | `<Feature>Repository` (protocol) + `<Feature>RepositoryImpl` (class) | `OrderSummaryRepository`, `OrderSummaryRepositoryImpl` |
 | Android | `<Feature>Repository` (interface) + `<Feature>RepositoryImpl` (class) | same |
-| Backend | `<Feature>Repository` | `PassengerFlightRepository` |
-| Web | `<feature>Api` | `passengerFlightApi` |
+| Backend | `<Feature>Repository` | `OrderSummaryRepository` |
+| Web | `<feature>Api` | `orderSummaryApi` |
 
 ### C2f dtoNaming
 
 | Platform | Default pattern | Example |
 |---|---|---|
-| iOS | `<Feature>RequestDTO`, `<Feature>ResponseDTO` | `PassengerFlightRequestDTO`, `PassengerFlightResponseDTO` |
-| Android | `<Feature>Dto` | `PassengerFlightDto` |
-| Backend | Pydantic `<Feature>In`, `<Feature>Out` | `PassengerFlightIn`, `PassengerFlightOut` |
-| Web | TypeScript `<Feature>Dto` | `PassengerFlightDto` |
+| iOS | `<Feature>RequestDTO`, `<Feature>ResponseDTO` | `OrderSummaryRequestDTO`, `OrderSummaryResponseDTO` |
+| Android | `<Feature>Dto` | `OrderSummaryDto` |
+| Backend | Pydantic `<Feature>In`, `<Feature>Out` | `OrderSummaryIn`, `OrderSummaryOut` |
+| Web | TypeScript `<Feature>Dto` | `OrderSummaryDto` |
 
 ## C3 - UI State Model
 
 | Platform | Default | Example |
 |---|---|---|
-| iOS | sealed enum | `enum PassengerFlightUIState { case loading, idle(...), error(...) }` |
-| Android | sealed interface | `sealed interface PassengerFlightUiState { data object Loading; data class Idle(...); data class Error(...) }` |
+| iOS | sealed enum | `enum OrderSummaryUIState { case loading, idle(...), error(...) }` |
+| Android | sealed interface | `sealed interface OrderSummaryUiState { data object Loading; data class Idle(...); data class Error(...) }` |
 | Backend | not applicable | services do not hold UI state |
-| Web | discriminated union | `type PassengerFlightState = { kind: 'loading' } | { kind: 'idle'; ... } | { kind: 'error'; ... }` |
+| Web | discriminated union | `type OrderSummaryState = { kind: 'loading' } | { kind: 'idle'; ... } | { kind: 'error'; ... }` |
 
 ## C4 - Test Method Naming
 
@@ -130,19 +130,19 @@ Apply platform default + open Section 20 risk row
 
 | Platform | Default pattern | Example | Rationale |
 |---|---|---|---|
-| iOS | dot notation `<feature>.<element>` | `passengerFlight.continueButton` | XCUITest query syntax friendliness |
-| Android | camelCase testTag | `passengerFlightContinueButton` | Compose testTag convention |
-| Backend | OpenAPI operationId camelCase | `fetchPassengerFlight` | Code generation friendly |
-| Web | kebab data-testid `<feature>-<element>` | `passenger-flight-continue-button` | DOM attribute readability |
+| iOS | dot notation `<feature>.<element>` | `orderSummary.continueButton` | XCUITest query syntax friendliness |
+| Android | camelCase testTag | `orderSummaryContinueButton` | Compose testTag convention |
+| Backend | OpenAPI operationId camelCase | `fetchOrderSummary` | Code generation friendly |
+| Web | kebab data-testid `<feature>-<element>` | `order-summary-continue-button` | DOM attribute readability |
 
 ## C6 - Localization Key
 
 | Platform | Default pattern | Example | Notes |
 |---|---|---|---|
-| iOS | hierarchical dot PascalCase | `PassengerFlight.ContinueButton` | Matches `Localizable.xcstrings` convention |
-| Android | flat snake_case | `passenger_flight_continue_button` | Matches `strings.xml` convention |
+| iOS | hierarchical dot PascalCase | `OrderSummary.ContinueButton` | Matches `Localizable.xcstrings` convention |
+| Android | flat snake_case | `order_summary_continue_button` | Matches `strings.xml` convention |
 | Backend | not applicable (server-side messages live in error code tables) | | |
-| Web | hierarchical dot camelCase | `passengerFlight.continueButton` | i18next + ICU MessageFormat default |
+| Web | hierarchical dot camelCase | `orderSummary.continueButton` | i18next + ICU MessageFormat default |
 
 ## C8 - SwiftUI Preview macro (iOS only)
 
@@ -162,8 +162,8 @@ Detection: scan up to 10 SwiftUI view files in the candidate set; majority pick
 |---|---|---|---|
 | iOS | Manual configurator | `<Domain>DependencyConfigurator.register<Feature>()` | Avoids framework lock-in; testable |
 | Android | Hilt module | `@Module @InstallIn(SingletonComponent::class) class <Feature>Module` | Standard Android DI |
-| Backend FastAPI | `Depends(get_<feature>_service)` | `service: PassengerFlightService = Depends(get_passenger_flight_service)` | Native FastAPI pattern |
-| Web | hook factory | `usePassengerFlightApi()` returns a memoized client | No framework DI needed |
+| Backend FastAPI | `Depends(get_<feature>_service)` | `service: OrderSummaryService = Depends(get_order_summary_service)` | Native FastAPI pattern |
+| Web | hook factory | `useOrderSummaryApi()` returns a memoized client | No framework DI needed |
 
 ## Risk row template (Section 20)
 

package/pipeline/multi-agent-refs/cross-cli-contract.md

@@ -1,7 +1,7 @@
 # Cross-CLI Contract (Claude Code · Copilot CLI · Codex CLI)
 
 <!-- toc -->
-- [1. Command Inventory (58 commands)](#1-command-inventory-58-commands)
+- [1. Command Inventory (61 commands)](#1-command-inventory-61-commands)
 - [2. Canonical Placeholder Vocabulary](#2-canonical-placeholder-vocabulary)
 - [2.6 Intentional structural divergence  -  thin dispatcher vs inlined orchestrator](#26-intentional-structural-divergence---thin-dispatcher-vs-inlined-orchestrator)
 - [2.7 One command, three different meanings: `/multi-agent:model`](#27-one-command-three-different-meanings-multi-agentmodel)
@@ -20,7 +20,7 @@
 
 ---
 
-## 1. Command Inventory (58 commands)
+## 1. Command Inventory (61 commands)
 
 ```
 analysis, analysis-jira, analysis-resolve, autopilot, autopilot-off,
@@ -28,10 +28,10 @@ autopilot-on, autopilot-status, build-optimize, channels, complaint-analysis,
 create-jira, design-check, diff-explain, doctor, feedback, forget,
 garbage-collect, graph, help, ios-coding-standard, issue, jira, kill,
 language, log, manual-test, model, prune-logs,
-prune-prompts, purge, refactor, resume, review,
+prune-prompts, purge, refactor, research, resume, review,
 review-analysis, review-issue, review-jira, route-off, route-on,
-route-status, routines, save, scan, search,
-security-review, setup, stack, status, steer, store-ready, sync, test, test-accessibility,
+route-status, routines, save, scaffold, scan, search,
+security-review, serve, setup, stack, status, steer, store-ready, sync, test, test-accessibility,
 test-dark-mode, test-dynamic-type, test-screenshots, testflight-validation,
 uninstall, update
 ```
@@ -42,7 +42,7 @@ Categories:
 - **Issue generator** (one-shot, no worktree, asks type Task/Bug/Story, hard approval gate before create): `create-jira`
 - **Pipeline entries**: `autopilot` (plus the bare `/multi-agent` in the dispatcher). The phase set is a property of the command, and every mode runs its whole set.
 - **Tail path** (the pipeline tail over work already on a branch, no run behind it): `resume`
-- **Ops commands** (one-shot, no worktree): `status`, `log`, `kill`, `steer`, `purge`, `uninstall`, `resume`, `review`, `review-jira`, `review-issue`, `analysis`, `analysis-resolve`, `complaint-analysis`, `build-optimize`, `channels`, `scan`, `search`, `diff-explain`, `garbage-collect`, `graph`, `prune-logs`, `prune-prompts`
+- **Ops commands** (one-shot, no worktree): `status`, `log`, `kill`, `steer`, `purge`, `uninstall`, `resume`, `review`, `review-jira`, `review-issue`, `analysis`, `analysis-resolve`, `research`, `scaffold`, `complaint-analysis`, `build-optimize`, `channels`, `scan`, `search`, `diff-explain`, `garbage-collect`, `graph`, `prune-logs`, `prune-prompts`, `serve`
 - **Local audits** (worktree only to build; no commit, push, PR or channels): `design-check`, `testflight-validation`, `ios-coding-standard`. `testflight-validation` additionally never invokes `altool --upload-app`  -  a validation run must not be able to ship a build by accident.
 - **Meta-ops**: `setup`, `sync`, `update`, `help`, `refactor`, `test`, `stack`, `manual-test`, `language`
 - **Routines** (user-defined routine registry; the routines they create are local-only and never synced): `save`, `routines`, `forget`
@@ -79,14 +79,7 @@ Three rules make that work:
    skill renders with an empty description, so a block entry buys nothing even when it
    fits. Parity on that host is **reachability**, not an identical listing.
 
-> This section previously claimed Copilot "retains its own standalone
-> `~/.copilot/skills/figma-*` copies as a frozen fallback". `install/copilot.mjs` pruned
-> exactly those directories, so the fallback did not exist: `create-screen`,
-> `figma-validate`, `figma-review`, `component`, `state` and `navigation` were all
-> absent, and a component task on Copilot had nothing to dispatch to. The contract
-> documented a safety net the installer deleted.
-
-What still MUST match across CLIs for component tasks: the `taskType === "component"` classification, the `state.phases["2"].subphases[]` shape the dispatch layer writes, and the Short-run elision semantics. Resolution/routing is Claude-plugin vs Copilot-local-copy by design.
+What still MUST match across CLIs for component tasks: the `taskType === "component"` classification and the `state.phases["2"].subphases[]` shape the dispatch layer writes. Resolution/routing is Claude-plugin vs Copilot-local-copy by design.
 
 ### 1.2 Store-compliance skills
 
@@ -291,9 +284,9 @@ argument-hint: "<input hint>"
 |---|---|
 | Claude → Copilot | Add `name`, `user-invocable: true`, `argument-hint`; remove `allowed-tools`; `description` stays English (localization happens only in the installed Claude tree via `description-tr` + `localize-commands.mjs`, never in repo or Copilot files) |
 | Copilot → Claude | Remove `name`, `user-invocable`, `argument-hint`; add `allowed-tools` (inferred from command's actual tool calls) |
-| Both directions | `not-for: <sibling>` carries across unchanged |
+| Both directions | `not-for: <sibling>` carries across with the same value: top-level in the command, under `metadata:` in the skill, where every key no host reads lives (`language` too) |
 
-**`not-for`** is optional and lists sibling commands this one must not be chosen for, as bare names (`not-for: jira, review-jira`). It is written for the model reading the routing surface, so it belongs beside the description rather than in prose further down. `lint-skills.mjs` also consumes it: a trigger-vocabulary collision either side has named drops off the warning list and is reported as settled instead, and a name that resolves to no sibling on the same surface is an error - a typo would otherwise leave the pair unanswered while the author believes it is handled. Both trees spell the value the same way; the `multi-agent-` prefix on the Copilot side is stripped before matching.
+**`not-for`** is optional and lists sibling commands this one must not be chosen for, as bare names (`not-for: jira, review-jira`). It is written for the model reading the routing surface, so it belongs beside the description rather than in prose further down. `lint-skills.mjs` also consumes it: a trigger-vocabulary collision either side has named drops off the warning list and is reported as settled instead, and a name that resolves to no sibling on the same surface is an error - a typo would otherwise leave the pair unanswered while the author believes it is handled. Both trees spell the value the same way and the lint reads it from either place; the `multi-agent-` prefix on the Copilot side is stripped before matching.
 
 **Invariant**: the English `description` must have the same meaning on both sides, and a `description-tr` line (when present) must be a faithful translation of it. Semantic drift is not allowed. `description-en` sidecars are an installed-tree artifact and must never appear in repo or Copilot files.
 
@@ -402,7 +395,7 @@ what keeps a secret off argv and what writes the audit entry.
 | Purpose | Canonical | Underlying backend (for debugging only) |
 |---|---|---|
 | Keychain read | `~/.claude/lib/credential-store.sh get <key>` | `security find-generic-password -a "$USER" -s <key> -w` |
-| Keychain write | `~/.claude/lib/credential-store.sh set <key> <value>` (or `keychain.py set <key> -` to stream the secret over stdin, keeping it off argv) | `security add-generic-password -a "$USER" -s <key> -w` |
+| Keychain write | `~/.claude/lib/credential-store.sh set <key> -` (the secret streams over stdin and stays off argv; `set <key> <value>` is for non-secret values) | `security add-generic-password -a "$USER" -s <key> -w` |
 | Clipboard read | `pbpaste` | -  |
 | Clipboard clear | `pbcopy < /dev/null` | -  |
 

package/pipeline/multi-agent-refs/features/autopilot-circuit-breaker.md

@@ -70,15 +70,34 @@ which came first and no queue to resume.
 disables). The count is CONSECUTIVE and read from `attempted.jsonl` rather than
 kept as a counter, because a counter is a second piece of state that can
 disagree with the ledger - and the ledger is what a person reads when they ask
-why the runner stopped.
-
-Two outcomes are deliberately not failures:
-
-- `needs-input` is a run that did its work and is waiting for a person. That is
-  the system behaving correctly, and counting it would stop a machine whose only
-  problem is that somebody has not answered yet.
+why the runner stopped. The breaker and the rate-limit backoff read the rows of
+a trailing window (`MA_AP_ATTEMPT_WINDOW_SEC`, 7 days by default), not a fixed
+number of rows, so the `blocked-*` rows a refused tick writes cannot push the
+failures out of view. One run counts once, by its `taskId`, even when it wrote
+two rows (`timed-out`, then the outcome a later tick retired it with).
+
+What counts is the outcome contract in `_autopilot-outcomes.mjs`, the one
+module the runner, intake and this breaker all read: every RETRYABLE outcome
+except `died` and `rate-limited` is a failure, and three kinds of row are
+deliberately not:
+
+- PARKED outcomes (`needs-input`, `awaiting-answer`, `verification-failed`) are
+  runs that did their work and are waiting for a person. That is the system
+  behaving correctly, and counting it would stop a machine whose only problem is
+  that somebody has not answered yet. They end a failure chain. The exception
+  is a publish refusal that describes the machine: a `verification-failed` row
+  whose `publishGate` is `remote`, `push` or `pr-create` means the push URL
+  could not be resolved or the host refused the push or the PR, which every next
+  item meets at the same step. Those count (`ENVIRONMENTAL_PUBLISH_GATES` in the
+  runner). The runner writes `publishGate` on every row the publish step
+  refused.
 - `blocked-*` items never ran at all - arming refused them - so they say nothing
-  about whether a run would have worked.
+  about whether a run would have worked. They neither count nor end a chain,
+  and they do not move the cooldown clock either: arming writes one on every
+  tick it refuses, which would otherwise keep the cooldown from running out.
+- `died` (a run the supervisor lost, e.g. across a reboot) and `rate-limited`
+  (which has its own backoff, doubling per consecutive limit) are skipped the
+  same way: neither counts, and neither passes for the success that ends a chain.
 
 When it opens, the reason goes into `queue.json.blockedReason` (so
 `autopilot-status` shows it rather than reporting an idle queue), a
@@ -112,4 +131,13 @@ correct and silently stops logging.
 what it took, what came out, how many consecutive failures preceded it. The
 human log answers "what happened just now"; this answers "how has this been
 behaving for a week", which is the question a server raises and prose cannot be
-asked.
+asked. Past `MA_AP_TICKS_MAX_BYTES` (2MB) only the newest `MA_AP_TICKS_KEEP`
+lines (5000) are kept.
+
+**The attempt log.** `attempted.jsonl` is the queue's memory, so past
+`MA_AP_ATTEMPTED_MAX_BYTES` (4MB) it is compacted, not cut. Rows from the last
+30 days stay whole. An older row stays when intake or the cleanup report still
+reads it: the newest row of its item, and every non-`blocked-*` row of an item
+that is not finished (its attempt count, research rounds and the task ids that
+tie a parked run to its worktree). The full log before compaction is kept in
+`attempted.jsonl.1`.