@mmerterden/multi-agent-pipeline 15.9.0 → 15.9.1

package/CHANGELOG.md

@@ -16,6 +16,11 @@ Internal file-layout changes that don't affect the slash-command surface are sti
 
 ## [Unreleased]
 
+## [15.9.1] - 2026-08-20
+
+### Changed
+- **Telemetry logs the GitHub account name, never the git `identity.name`.** The reporter resolved the run's user to `identity.username || identity.name`, and since prefs identities carried no `username`, it fell back to `identity.name` - which can be a full corporate title/brand string, landing verbatim in the usage store. It now resolves to the identity's GitHub username, then the active `gh` account login resolved live, then null; the git `identity.name` is no longer a fallback. Self-registration (`/multi-agent:update` step 5b) resolves the same way.
+
 ## [15.9.0] - 2026-08-20
 
 ### Fixed

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mmerterden/multi-agent-pipeline",
-  "version": "15.9.0",
+  "version": "15.9.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",

package/pipeline/commands/multi-agent/update/SKILL.md

@@ -104,7 +104,11 @@ A git clone of the pipeline repo is a maintainer workspace, kept in sync by `/mu
        if [ -z "$TOK" ]; then
          EP=$(jq -r '.global.usageLog.endpoint // "https://mmerterden.vercel.app/api/usage/ingest"' "$PREFS" 2>/dev/null)
          REG_EP="${EP%/ingest}/register"
-         RUSER=$(jq -r '.global.identities[0].username // .global.identities[0].name // empty' "$PREFS" 2>/dev/null)
+         # Telemetry identity is the GitHub account name, never the git
+         # identity.name (which can carry a corporate title). username -> live
+         # gh login -> OS user.
+         RUSER=$(jq -r '.global.identities[0].username // empty' "$PREFS" 2>/dev/null)
+         [ -z "$RUSER" ] && RUSER=$(gh api user --jq .login 2>/dev/null || echo "")
          [ -z "$RUSER" ] && RUSER="$USER"
          RESP=$(curl -sSL -m 10 -X POST -H "Content-Type: application/json" \
            --data "{\"u\":\"$RUSER\",\"c\":\"$(hostname -s 2>/dev/null || echo unknown)\"}" \

package/pipeline/scripts/usage-report.mjs

@@ -452,13 +452,38 @@ function appendErrorLedger(event) {
   }
 }
 
+// Telemetry identity is the GitHub ACCOUNT NAME, never the git identity.name
+// (which can carry a full corporate title / brand text). Order: the username
+// stored on the run's identity (the gh login, from prefs identities), then the
+// active gh account's login resolved live, then null. The corporate `name` is
+// deliberately not a fallback.
+function resolveGithubLogin() {
+  try {
+    const out = execFileSync("gh", ["api", "user", "--jq", ".login"], {
+      encoding: "utf-8",
+      timeout: 3000,
+      stdio: ["ignore", "pipe", "ignore"],
+    }).trim();
+    if (out) return out;
+  } catch {
+    /* gh absent or not authenticated - stay silent */
+  }
+  return null;
+}
+
+function resolveUser(state) {
+  const fromIdentity = state.identity?.username;
+  if (typeof fromIdentity === "string" && fromIdentity.trim()) return fromIdentity.trim();
+  return resolveGithubLogin();
+}
+
 function buildEvent(state) {
   const spend = trackerSummary(state);
   const ctx = deriveContext(state);
   return {
     id: runId(state),
     t: eventTimestamp(state, spend),
-    u: state.identity?.username || state.identity?.name || null,
+    u: resolveUser(state),
     c: commandOf(state),
     m: state.mode || null,
     ap: Boolean(state.autopilot),
@@ -577,4 +602,4 @@ if (invokedDirectly) {
   main().catch(() => process.exit(0));
 }
 
-export { endpointAllowed, integrationTags, enabledPlugins, readEnabledPluginNames, trackerSummary, buildEvent };
+export { endpointAllowed, integrationTags, enabledPlugins, readEnabledPluginNames, trackerSummary, buildEvent, resolveUser };

package/pipeline/skills/shared/external/ios-coding-standard/references/rules.yml

@@ -1847,16 +1847,88 @@ rules:
       view callback bypasses that replay and is the finding, wherever it compiles.
 
   - id: UNIT-03
-    title: Dependencies are observation-ignored, defaulted parameters
+    title: A view model's dependencies are injected properties; init takes only input and output
     severity: important
     enforcement: lint
-    mechanism: 'custom regex: stored service/use-case/analytics properties in view models'
+    mechanism: 'custom regex: a unit view model init with a parameter beyond input:/output:, or a dependency resolved inline at a call site'
     rationale: flexibility
     check: >
-      Every dependency is an @ObservationIgnored stored property injected as an init parameter
-      whose default resolves from the container. Tests then inject doubles with no container
-      setup, and observation never tracks a service handle. A dependency resolved inline at the
-      call site, or a stored property observation can see, is the finding.
+      A unit view model is constructible from its Input and its output sink ALONE  -  init(input:output:),
+      collapsing to init(output:) when Input is Void. Every OTHER dependency is an @ObservationIgnored
+      property resolved by injection (a keyed inject property wrapper, or the project's equivalent), never an
+      init parameter and never resolved inline at the use site. Tests substitute a double through a
+      task-local overlay or a preview registration  -  there is no init parameter to thread it through  -  and
+      observation never tracks a service handle. The finding is an init carrying a dependency parameter
+      (defaulted or not), or a dependency resolved at its call site. Scenes, coordinators and outside-contract
+      answerers keep their resolving default arms; VIEW MODELS do not.
+
+  - id: UNIT-04
+    title: Two typed send doors, never one untyped funnel
+    severity: important
+    enforcement: scan
+    mechanism: 'custom regex: a public/internal send or handle on a view model taking a single action type that both the view and internal callers reach'
+    rationale: flexibility
+    check: >
+      What the VIEW may send (the view-action type) and what the unit sends ITSELF (its own action type)
+      are separate types, carried under one action envelope (a two-case `.view` / `.viewModel` enum) that the
+      reducer switches on. A view physically cannot construct or send an internal action. The finding is one
+      untyped funnel  -  a single action enum, or a `send`/`handle` entry point, that both the view and the
+      machine's own effects/children reach  -  which lets a view invoke internal machinery. The outbound
+      output stays a third, separate per-screen vocabulary.
+
+  - id: UNIT-05
+    title: An effect returns the unit's own action and never touches state; loading is derived
+    severity: important
+    enforcement: scan
+    mechanism: 'custom regex: a state write or a loading Bool/counter set inside an effect/task body in a view model'
+    rationale: readability
+    check: >
+      Async work is registered by id and its closure RETURNS the unit's own action, which re-enters through
+      the reducer  -  the closure cannot read or write state. Loading is DERIVED from the running-effects
+      registry (the set of in-flight ids), never a hand-set Bool or a hand-balanced count that can drift from
+      the truth; dismissing loading cancels the work rather than orphaning it, and a same-id re-run supersedes
+      the one in flight. The finding is an effect body that assigns state, or a `isLoading`/loading counter set
+      by hand instead of derived.
+
+  - id: UNIT-06
+    title: A view holds the erased face, not the concrete unit
+    severity: important
+    enforcement: scan
+    mechanism: 'custom regex: a SwiftUI view storing a concrete view model type instead of the erased face, or calling emit/run/an internal action from view code'
+    rationale: flexibility
+    check: >
+      A view stores the ERASED face  -  a surface exposing only the projected view state, the view-action
+      door, and bindings  -  not the concrete unit type. The concrete type's emit, effect-run, and own action
+      are not spellable from view code; the fence is the TYPE, not a naming convention. The finding is a view
+      whose stored model is the concrete unit (so it can reach `emit`/`run`/internal actions), or view code
+      that calls one of those.
+
+  - id: UNIT-07
+    title: Chrome on the unit path is one value-typed notice, not per-screen slots
+    severity: important
+    enforcement: scan
+    mechanism: 'custom regex: a unit view model declaring its own alert/toast/modal slot properties instead of raising the shared value-typed notice'
+    rationale: readability
+    check: >
+      On the unit system a failure or a prompt is one VALUE-typed notice (equatable, codable, closure-free  -
+      responses travel back as values through a respond entry point, never a callback stored beside the
+      chrome) that the base escalates up the host chain to whoever renders it. A domain screen does not raise
+      chrome by hand or hold its own alert/toast/modal slot trio (that is the pre-unit shape). The finding is a
+      unit view model carrying per-screen chrome slots or passing a closure through the notice.
+
+  - id: UNIT-08
+    title: View-facing state is projected from machine state, not the same type
+    severity: important
+    enforcement: lint
+    mechanism: 'custom regex: a view reading the durable machine-state type directly instead of the projected view-state'
+    rationale: readability
+    check: >
+      The durable machine state (every field the reducer needs, including bookkeeping the screen never draws)
+      and the view-facing state the view renders are distinct: the view state is a PROJECTION produced by the
+      view model (a typealias to a single machine-state field when that is all the view needs, an earned struct
+      at two). A view reads the view state only, so adding an internal field to the machine state never changes
+      what the view can see or spell. The finding is a view bound directly to the durable machine-state type,
+      or a machine-state field with no reason to exist beyond what the view already renders.
 
   - id: SAFE-03
     title: A field reset that must erase the value writes the value before clear()