@mmerterden/multi-agent-pipeline 17.5.0 → 17.5.1

package/CHANGELOG.md

@@ -14,6 +14,34 @@ Internal file-layout changes that don't affect the slash-command surface are sti
 
 ---
 
+## [17.5.1] - 2026-09-15
+
+### Documentation
+
+17.5.0 shipped base-branch evidence and documented it in the feature ref and the
+CHANGELOG only. `README.md`, `README.tr.md` and `docs/features.md` all ship in
+the npm tarball, and `docs/features.md` calls itself the complete catalog - so
+the published package described less than it contained, and the npm page showed
+a release missing one of its two features.
+
+- Both READMEs gain a "Base branch: evidence, then a question" section: what is
+  collected, that no field id or branch prefix is hardcoded, that an uncut
+  release is a note rather than an option, that a failed fetch degrades loudly,
+  and the pref that turns it off.
+- `docs/features.md` gains the full section, and its modifier-flag table stops
+  presenting `--local` as the only route to local mode - the workspace is a
+  question at Step 5b now, which 17.5.0 changed without updating that table.
+- `docs/features.md` said the toolkit has "80+ tools". It has 99.
+
+### Website
+
+- The base-branch card, and three counts corrected against the filesystem:
+  `ai-ios-toolkit` 147 -> 134 skills (its own breakdown summed to 251 against a
+  stated total of 238), and the Remote Control entry's 35 -> 56 commands and
+  263 -> 212 skills.
+
+---
+
 ## [17.5.0] - 2026-09-15
 
 Four defects from one live run of `/multi-agent`, all in Phase 0, all visible in

package/README.md

@@ -72,6 +72,14 @@ checkout):
 
 `/multi-agent:analysis` runs its own shorter chain and, since v16.12.0, reviews what it wrote before publishing it: the draft goes through the same three-reviewer set and triage as a code diff, a blocking finding returns it to synthesis with dispatch closed, and the gaps that survive are either searched, asked about, or recorded with an owner. It used to publish behind a structural validator alone.
 
+### Base branch: evidence, then a question
+
+Phase 0 Step 3 collects the candidates **with the evidence behind each one** before it asks. An issue carrying a target version, or linking a separate issue that represents the release, already names the branch on a repo whose release branches encode the version - so that becomes a ranked row whose description says why, next to rows that say "the repository's default branch" or "you used this last time". You still choose; the evidence only reorders.
+
+Nothing is hardcoded: any Jira field whose schema resolves to `version` is read whatever the board calls it, and the release-branch naming convention is inferred from the refs that exist rather than read off a table - one repo yields `<prefix>/develop_<version>`, another `release-<version>`, out of the same code. A version whose branch has not been cut yet is reported as a note, never offered as an option you cannot check out.
+
+A failed `git fetch` degrades loudly rather than silently: the list falls back to local refs, the question says so, it gains a retry row, and the exit gate refuses to close Phase 0 if a degraded run recorded its list as the remote's answer. Turn the whole thing off with `prefs.global.baseBranchEvidence.enabled: false` and Step 3 asks the way it always did.
+
 ### Workspace: worktree or local
 
 Phase 0 Step 5b asks where the branch lives. **Worktree** (`.worktrees/{id}/`) leaves your current checkout untouched; **Local** works in the project root on a new branch, which drops Phase 5 - the user-test gate checks the change out of a worktree and there is none - and needs the project root clean. `/multi-agent:local` and `--local` answer it up front. Every autopilot entry resolves it to a worktree without asking: an unattended run commits and pushes from wherever it stands, and doing that in your own checkout is what worktrees exist to prevent. `:local-autopilot` is the explicit opt-out.

package/README.tr.md

@@ -72,6 +72,14 @@ mu):
 
 `/multi-agent:analysis` kendi kısa zincirini koşar ve v16.12.0'dan beri yazdığını yayınlamadan önce review ediyor: taslak, bir kod diff'iyle aynı üç-reviewer setinden ve triyajdan geçiyor, bloklayıcı bulgu dokümanı sentez fazına geri gönderip dispatch'i kapatıyor, hayatta kalan boşluklar ya aranıyor ya sana soruluyor ya da sahibiyle birlikte kayda giriyor. Önceden yalnızca yapısal bir validator'ın arkasından yayınlıyordu.
 
+### Temel branch: önce kanıt, sonra soru
+
+Faz 0 Adım 3 sormadan önce adayları **her birinin arkasındaki kanıtla** topluyor. Hedef sürüm alanı taşıyan ya da release'i temsil eden ayrı bir maddeye bağlı bir issue, release dallarını sürümle adlandıran bir repoda branch'i zaten söylüyor - bu, nedenini açıklayan sıralı bir satır oluyor; yanında "reponun varsayılan dalı" ya da "geçen sefer bunu kullandın" diyen satırlar duruyor. Seçim yine senin; kanıt yalnızca sıralamayı değiştiriyor.
+
+Hiçbir şey gömülü değil: şeması `version`'a çözülen her Jira alanı, board ona ne ad verirse versin okunuyor; release dalı konvansiyonu da tablodan değil, var olan ref'lerden çıkarılıyor - aynı koddan bir repoda `<prefix>/develop_<version>`, başkasında `release-<version>` çıkıyor. Dalı henüz açılmamış bir sürüm not olarak bildiriliyor, checkout edemeyeceğin bir seçenek olarak sunulmuyor.
+
+Başarısız bir `git fetch` sessizce değil, yüksek sesle bozuluyor: liste lokal ref'lere düşüyor, soru bunu söylüyor, bir yeniden dene satırı kazanıyor, ve bozuk bir koşu listesini uzaktakinin cevabı diye kaydederse exit gate Faz 0'ı kapatmıyor. Tamamını kapatmak için `prefs.global.baseBranchEvidence.enabled: false` - Adım 3 eskisi gibi soruyor.
+
 ### Çalışma alanı: worktree mi lokal mi
 
 Faz 0 Adım 5b branch'in nerede yaşayacağını sorar. **Worktree** (`.worktrees/{id}/`) mevcut checkout'una dokunmaz; **Lokal** proje kökünde yeni bir branch'te çalışır, bu da Faz 5'i düşürür - kullanıcı-test kapısı değişikliği bir worktree'den checkout eder, ortada worktree yoktur - ve proje kökünün temiz olmasını ister. `/multi-agent:local` ve `--local` bu soruyu baştan cevaplar. Her autopilot girişi sormadan worktree'ye karar verir: gözetimsiz bir koşu nerede duruyorsa oradan commit'leyip push eder, ve bunu senin kendi checkout'unda yapmak tam olarak worktree'nin engellemek için var olduğu şeydir. `:local-autopilot` bunun açık opt-out'u.

package/docs/features.md

@@ -26,9 +26,11 @@ Each phase reads its own spec file under `pipeline/multi-agent-refs/phases/phase
 | Flag        | Effect                                                                              |
 | ----------- | ----------------------------------------------------------------------------------- |
 | `autopilot` | Skip all confirmation prompts; still fails safe on review blockers + build retries. |
-| `--local`   | No worktree - works directly in `$PROJECT_ROOT` on a local branch.                  |
+| `--local`   | Answers the workspace question up front: no worktree, work directly in `$PROJECT_ROOT` on a local branch. |
 
-Depth is not a flag. `/multi-agent` and `/multi-agent:local` ask Full or Short at Phase 0 Step 7.5, recommending from the detected `taskType`; Short strips to Init → Dev(Opus self-contained) → Review → Test → Commit → Report. Autopilot never asks and always runs Full - "fast plus unattended" was removed in v16.0.0, because something has to choose when nobody is asked and unattended is the worst place to drop analysis and planning.
+Neither the workspace nor the depth is a flag. **Where the branch lives** is asked at Phase 0 Step 5b - worktree (`.worktrees/{id}/`, your checkout untouched) or local (the project root, which drops Phase 5 because the user-test gate checks the change out of a worktree and there is none). `:local` and `--local` state it in advance; every autopilot entry resolves it to a worktree and never asks, because an unattended run commits and pushes from wherever it stands and doing that in the user's own checkout is what worktrees exist to prevent. `state.workspaceSource` records who decided - `localMode: false` alone is both "the user chose a worktree" and "nothing asked".
+
+Depth is not a flag either. `/multi-agent` and `/multi-agent:local` ask Full or Short at Phase 0 Step 7.5, recommending from the detected `taskType`; Short strips to Init → Dev(Opus self-contained) → Review → Test → Commit → Report. Autopilot never asks and always runs Full - "fast plus unattended" was removed in v16.0.0, because something has to choose when nobody is asked and unattended is the worst place to drop analysis and planning.
 
 ### Outside a Pipeline Run
 
@@ -36,7 +38,7 @@ The install is not only useful while `/multi-agent` is running. `rules/outside-t
 
 - **Onboarded service credentials.** Resolve the logical name through `credential-store.sh` and read the issue, page or log. Writes route through the pipeline commands, which carry the rules that make them safe - issues are never auto-closed, PR bodies use `Ref:`, outward prose goes through the humanizer.
 - **The stack skills enabled for this repo.** Each toolkit's own `index` skill routes. The pipeline reads the effective `enabledPlugins` rather than keeping a stack table, so a seventh toolkit needs no code change.
-- **The `multi-agent-toolkit` MCP.** 80+ tools for a running app.
+- **The `multi-agent-toolkit` MCP.** 99 tools for a running app.
 
 Uninstall preserves the whole layer - tokens, the reader that opens them, the mapping that names them, the MCP registration. It is 1.5 kB of always-loaded text; the detail lives in a ref that loads on demand, and a gate keeps both under a ceiling because every byte there is paid by every session.
 
@@ -74,6 +76,21 @@ Stack skill sets ship as versioned plugins in the `multi-agent-plugins` marketpl
 /multi-agent:stack all         # every stack plugin
 ```
 
+### Base-Branch Evidence (Phase 0 Step 3, `prefs.global.baseBranchEvidence.enabled`)
+
+Step 3 used to ask one question with a list it could not vouch for. `git fetch origin` ran, its exit code was discarded, and `git branch -r` printed the remote-tracking cache either way - so on a restricted network a weeks-old local list was presented as the remote's answer, with nothing saying so. And the answer was usually derivable: an issue carrying a target version, or linking a separate issue that represents the release, already names the branch on a repo whose release branches encode the version.
+
+`base-branch-candidates.mjs` collects candidates **with the evidence behind each one**, ranks them, and the picker row's description IS the evidence - "matches version 1.51.0 from the field Target Version" and "the repository's default branch" are different answers to the same question. A human still chooses; the derivation only reorders the rows.
+
+Nothing is tabled, and that is the design rather than a detail:
+
+- **No Jira field id is hardcoded.** A board's "target version" is a custom field whose id differs per instance. What is stable is the schema: any field resolving to type `version` is read, whatever it is called. A linked issue or parent whose own fix-version or summary names a version is the second source, and `baseBranchEvidence.preferLinkedRelease` raises it above the version field on boards where selecting the release issue is what opens the branch.
+- **No branch prefix is tabled.** The release-branch template is inferred from the refs that exist, so one repo yields `<prefix>/develop_<version>` and another `release-<version>` out of the same code. The rule-5 filter carries a version alternative for the same reason: a word list that ranks is fine, one that discards is the prefix table this replaces.
+- **A predicted branch is a note, never an option.** "That version has no branch on the remote yet" is a real answer; an option the user picks has to be checkoutable.
+- **A failed fetch degrades loudly.** `refProvenance` rides on every candidate, the picker says the refs may be stale and gains a retry row, and `phase0-exit-gate.mjs` refuses to close Phase 0 if a degraded fetch recorded its list as `remote`.
+
+Autopilot resolves `remembered` → `derived` → `default` and records which fired; `derived` requires issue evidence for the branch it chose. With `baseBranchEvidence.autopilotAsksOnIssue` (**off by default**) an ambiguous derivation posts one comment on the Jira or GitHub issue asking which branch, then halts on circuit-breaker trigger 6 and waits for `resume`. A question, never a state change: no transition, no close, `Ref:` never `Closes:`, copy in `outputLanguage`.
+
 ### Task Type Detection
 
 Phase 0 Step 9 classifies every task before Phase 1 starts. Deterministic priority order: Figma URL → instruction file path → git diff heuristic → Jira issue type → branch name → description keywords → user prompt (autopilot defaults to `feature`).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mmerterden/multi-agent-pipeline",
-  "version": "17.5.0",
+  "version": "17.5.1",
   "description": "8-phase AI development pipeline with full orchestration on Claude Code, Copilot CLI and Codex CLI. Analysis, planning, TDD, CLI-aware parallel review with consensus surfacing + Fable triage, default-FAIL evidence gates, secret + intent guards, per-phase cost ledger, persistent learnings memory, wiki generation, commit automation. Token-preserving uninstall.",
   "type": "module",
   "main": "index.js",