@mmerterden/multi-agent-pipeline 15.2.0 → 15.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md
CHANGED
|
@@ -16,6 +16,22 @@ Internal file-layout changes that don't affect the slash-command surface are sti
|
|
|
16
16
|
|
|
17
17
|
## [Unreleased]
|
|
18
18
|
|
|
19
|
+
## [15.3.0] - 2026-08-15
|
|
20
|
+
|
|
21
|
+
### Added
|
|
22
|
+
|
|
23
|
+
- **`/multi-agent:setup` onboards the usage-dashboard token (opt-in, one-time).**
|
|
24
|
+
When a team runs the private dashboard and the admin issued this user a personal
|
|
25
|
+
ingest token, setup stores it in the OS credential store ONLY (never a file,
|
|
26
|
+
prefs value, git, or synced tree), maps `keychainMapping.usage_ingest`, and
|
|
27
|
+
turns logging on. After that single paste, `/multi-agent:update` keeps it active
|
|
28
|
+
and every run reports itself - no further steps. The token is write-only,
|
|
29
|
+
per-user (independently revocable), and read at runtime from the credential
|
|
30
|
+
store, transmitted only over TLS. Skipping the prompt leaves logging fully off.
|
|
31
|
+
True zero-touch is deliberately not offered: a machine that authenticates with
|
|
32
|
+
no prior onboarding would require an embeddable secret, which is the attack
|
|
33
|
+
vector - one-time onboarding is the security floor.
|
|
34
|
+
|
|
19
35
|
## [15.2.0] - 2026-08-15
|
|
20
36
|
|
|
21
37
|
### Added
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@mmerterden/multi-agent-pipeline",
|
|
3
|
-
"version": "15.
|
|
3
|
+
"version": "15.3.0",
|
|
4
4
|
"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.",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "index.js",
|
|
@@ -206,6 +206,40 @@ Save the resolved mapping to preferences:
|
|
|
206
206
|
|
|
207
207
|
`null` = not mapped (missing or skipped). Pipeline phases read this mapping to retrieve tokens dynamically - never hardcoded key names.
|
|
208
208
|
|
|
209
|
+
### Step 2.7 - Usage dashboard token (optional, opt-in)
|
|
210
|
+
|
|
211
|
+
Only relevant when the team runs a private usage dashboard and the admin has issued this user a personal ingest token. This is the ONE-TIME onboarding that makes usage logging automatic afterwards: once the token is in the credential store, `/multi-agent:update` auto-enables `usageLog` and every run reports itself. Skipping it leaves logging fully off.
|
|
212
|
+
|
|
213
|
+
Ask (in `outputLanguage`), and proceed only on an explicit yes:
|
|
214
|
+
|
|
215
|
+
```
|
|
216
|
+
Do you have a usage-dashboard ingest token from your admin?
|
|
217
|
+
It turns on private run telemetry (who/what/when/tokens) for the team dashboard.
|
|
218
|
+
[ Paste token / Skip ]
|
|
219
|
+
```
|
|
220
|
+
|
|
221
|
+
On paste, store the secret in the credential store ONLY - never in a file, prefs value, git, or any synced/published tree. Use the standard per-user key name so it is revocable independently and consistent across the user's machines:
|
|
222
|
+
|
|
223
|
+
```bash
|
|
224
|
+
~/.claude/lib/credential-store.sh set "${USER}_Usage_Ingest_Token" "<pasted-token>"
|
|
225
|
+
```
|
|
226
|
+
|
|
227
|
+
Then map it and enable logging (the token itself stays in the credential store; only the logical mapping + the on-switch land in prefs):
|
|
228
|
+
|
|
229
|
+
```bash
|
|
230
|
+
node -e '
|
|
231
|
+
const fs=require("fs"),os=require("os"),p=os.homedir()+"/.claude/multi-agent-preferences.json";
|
|
232
|
+
const j=JSON.parse(fs.readFileSync(p,"utf8"));
|
|
233
|
+
j.global=j.global||{}; j.global.keychainMapping=j.global.keychainMapping||{};
|
|
234
|
+
j.global.keychainMapping.usage_ingest=process.argv[1];
|
|
235
|
+
j.global.usageLog=Object.assign({enabled:true},j.global.usageLog||{},{enabled:true});
|
|
236
|
+
fs.writeFileSync(p,JSON.stringify(j,null,2)+"\n");
|
|
237
|
+
' "${USER}_Usage_Ingest_Token"
|
|
238
|
+
echo " -> usage logging onboarded (token in credential store; logging on)"
|
|
239
|
+
```
|
|
240
|
+
|
|
241
|
+
Security notes to surface to the user: the token is **write-only** (it can only append activity metadata to the dashboard - no read access, no other scope), it is stored **only in the OS credential store**, and it is **per-user** so the admin can revoke this one token without affecting anyone else. `usage-report.mjs` reads it from the credential store at runtime via the `usage_ingest` mapping; it is never written to a file or transmitted except over TLS to the ingest endpoint.
|
|
242
|
+
|
|
209
243
|
### Auto-learned fields (no setup step needed)
|
|
210
244
|
|
|
211
245
|
**Jira Project Key**: auto-learned from pipeline usage. User runs `/multi-agent ABC-123` → `ABC` is extracted and saved to `prefs.global.defaultJiraKey` (first ever) and `prefs.projects[{project}].jiraProjectKeys` (per-project). Multiple keys accumulate over time - most recent first, deduped. Phase 0 Step 1 (Parse Input) handles extraction.
|