@mmerterden/multi-agent-pipeline 20.27.1 → 20.28.0

package/pipeline/skills/shared/external/handle-request/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: handle-request
+description: "Add the test handles a scenario needs and answer each request with ADDED, ALREADY or COULD NOT ADD plus file:line or reason. Identity values only, attribute-only diffs; iOS accessibilityIdentifier, Compose testTag, web data-testid. Use when a test needs an element handle the UI lacks."
+metadata:
+  source: multi-agent-pipeline
+  version: 1.0.0
+---
+
+# Handle request
+
+A handle is the identifier a test finds an element by: it does not change with
+copy, locale or layout. This step adds the handles a scenario list asks for,
+and nothing else.
+
+## 1. Input
+
+A list of requests, usually the "handles needed" section of
+`scenario-gap-analysis`. Each request names the element, the screen, a
+proposed identifier and the scenario it unblocks.
+
+## 2. One answer per request
+
+| Answer | When |
+|---|---|
+| `ADDED file:line` | The handle was added at that line. |
+| `ALREADY file:line` | A usable handle already exists there; give its value. |
+| `COULD NOT ADD reason` | It was not added. The reason is specific: element rendered by a third-party view, identifier must come from a shared schema that lacks the key, repository is read-only, the element is not exposed to the accessibility tree and exposing it would change what assistive technology hears. |
+
+No other answer exists. A request that is half done is split into the part
+added and the part that could not be.
+
+## 3. Rules
+
+- **Identity, never position.** A row carries the item's id
+  (`order_row_{orderId}`), never the loop index, which shifts when the list is
+  reordered or filtered. Do not rewrite a list-rendering expression to obtain
+  an index or an id; if the id is not in scope, answer COULD NOT ADD.
+- **Attribute-only diffs.** Add identifier attributes or modifiers. No logic,
+  state, flow, data, styling, renames or deletions. Anything a line loses must
+  reappear in the added line.
+- **Stable names.** Screen-scoped, descriptive, independent of visible text
+  and locale (`cart_checkout_button`). Follow the project's existing naming
+  scheme and, where it generates identifiers from a shared schema, use the
+  generated constant; a key missing from the schema is added upstream, so the
+  answer is COULD NOT ADD with that reason.
+- **One pass.** Write every requested handle before building. On mobile each
+  build costs minutes; one handle per build turns a step into hours.
+- **Out of bounds.** Build files, manifests and permissions, signing,
+  dependencies. No commit: leave the diff for a human.
+
+## 4. The handle has to be visible where the test runs
+
+A handle in source that the test driver cannot see is worse than none: it
+looks done. For each handle, confirm it reaches the tree the test reads:
+
+| Platform | Handle | Seen by the driver only when |
+|---|---|---|
+| iOS (SwiftUI, UIKit) | `accessibilityIdentifier` | the element is in the accessibility tree: not hidden, not merged into a parent element |
+| Android (Compose) | `Modifier.testTag` | inside the app's Compose tests always; for UI Automator based drivers only under `testTagsAsResourceId` on an ancestor |
+| Android (Views) | `android:id` | the view is laid out and not excluded from accessibility |
+| Web | `data-testid` (or the project's configured test id attribute) | the component forwards it to the DOM and the build under test does not strip it |
+| Flutter | `Semantics(identifier: ...)` for external drivers; `Key` for in-process tests | a `Key` works with `find.byKey` inside `flutter test` and integration tests, but never reaches the accessibility tree, so an external driver (XCUITest, UI Automator, Maestro, Appium) needs the `Semantics` identifier |
+
+Verify against the running app when a build loop exists: a UI tree dump
+(`ios_get_ui_tree`, `android_get_ui_tree`), a DOM query or `web_find`. When no
+build loop is available in this step, the report says "not verified on device"
+and gives the build and install commands for a human. Never claim a check that
+did not run.
+
+The stack plugins carry the platform detail: `ai-ios-toolkit:handle-request`,
+`ai-android-toolkit:handle-request`, `ai-frontend-toolkit:handle-request`.
+
+## 5. Check the diff before finishing
+
+- `git diff -U0` shows added handle lines; their count is greater than zero
+  unless every answer is ALREADY or COULD NOT ADD.
+- Every removed line comes back in an added line with only the identifier
+  added.
+- No file outside the UI sources the requests point to.
+
+## 6. Report
+
+```
+cart_checkout_button   ADDED      src/cart/CartFooter.tsx:31
+order_row_{orderId}    ALREADY    src/orders/OrderRow.tsx:12 (data-testid="order-row-{id}")
+map_pin                COULD NOT ADD  rendered by a third-party map view with no identifier API
+```
+
+Then: a diff summary (files, lines changed), the scenarios these handles
+unblock, and what was not verified on device, with the reason.
+
+## Related
+
+- `scenario-gap-analysis` produces the requests.
+- `test-result-triage` sends a locator-not-found result here before calling a
+  test stale.
+- `e2e-testing` for the locator order a test uses once the handle exists.

package/pipeline/skills/shared/external/scenario-gap-analysis/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: scenario-gap-analysis
+description: "Set an inventory against existing tests, sort each behaviour into COVERED, WRONGLY COVERED or MISSING, and write gaps as measurable, prioritised scenarios with cross-screen flows. Use when planning tests or auditing coverage. Not for writing tests or judging a run."
+metadata:
+  source: multi-agent-pipeline
+  version: 1.0.0
+---
+
+# Scenario gap analysis
+
+Decide **what** has to be tested, and why. How to test it belongs to the
+writing step. The output is a ranked list of measurable scenarios that a test
+writer can turn into code without asking what was meant.
+
+## 1. Read before you call anything missing
+
+Gather the inputs first, and read all of them:
+
+- **Inventory**: screens, modules, flows or endpoints in scope, from a design
+  scenario inventory, a site map, a UI tree, or exploration reports.
+- **Existing tests**: the test tree and any test catalogue. Search it for every
+  behaviour before listing that behaviour as a gap.
+- **Regression history** where the project keeps one: past bugs, regression
+  maps, incident notes. A case that broke before is the first candidate.
+- **Exploration notes**: what someone saw the product actually do.
+
+Match tests to inventory items by **identifier** (accessibility identifier,
+test id, route, endpoint path), never by a name that merely sounds similar.
+When a match is inferred rather than read, say so on that line.
+
+## 2. Three buckets
+
+| Bucket | Meaning |
+|---|---|
+| **COVERED** | A test exercises the behaviour and its assertion would fail if the behaviour broke. |
+| **WRONGLY COVERED** | A test exists and stays green while the defect is present. |
+| **MISSING** | No test exercises the behaviour. |
+
+WRONGLY COVERED is the most valuable bucket, because the suite reports safety
+it does not provide. Typical shapes:
+
+- A text scan over rendered text that never sees content injected as markup.
+- A visibility filter that passes a broken image because its width is zero.
+- An assertion on the HTTP status that passes while the body carries an error.
+- A test that seeds the store or mocks the handoff it claims to verify.
+- An existence check where the value is what matters (a total, a date, a count).
+
+For every WRONGLY COVERED line, name the test (`file:line`) and the defect it
+cannot see.
+
+## 3. Scenario schema
+
+Each MISSING or WRONGLY COVERED behaviour becomes one scenario:
+
+| Field | Content |
+|---|---|
+| Title | Usable as the test name. |
+| Priority | `bug-catching` (broke before or likely to, hurts the user directly: data, money, dates, a dead end in the funnel, leaked copy keys) / `edge` (empty, error, boundary, slow network, back navigation, session expiry, flag combinations) / `baseline` (happy path, element present). |
+| Business reason | Who loses what, or which revenue or compliance risk it carries. "Nice to have" is not a reason. |
+| Preconditions | Account, data and state the scenario needs, and where each comes from. |
+| Steps | What the user does. |
+| Measurable expectation | A claim a test can check exactly: a value, a label, a route, an element present or absent. A scenario with no measurable expectation is not written. |
+| Automation | `yes` / `no` (stays a manual check, still listed) / `needs-code` (name the missing handle or hook). |
+| Handles needed | Identity-carrying handles the test will locate by, for the handle step. |
+| Data needs | What test data the scenario requires. The agent states the need; a human supplies the value. Never invent a credential. |
+| Flakiness risk | Third-party scripts, live content, timing. Say it up front. |
+
+The machine-readable shape and a worked example are in
+[references/scenario-schema.md](references/scenario-schema.md).
+
+## 4. Cross-screen flows (at least two)
+
+Write at least two scenarios that walk a user path across screens. Only an
+analysis that has seen the whole module can write them, and they catch the
+class of defect screen tests cannot: screen A does not write the state screen
+B reads. Both screens are green on their own and the flow is broken.
+
+Rules for a flow scenario:
+
+- Every step uses the state the previous step left. No seeding a store, no
+  injecting state, no deep link or direct route to an intermediate screen.
+- Enter from the first screen and move forward the way a user does.
+- Mock only noise outside the flow (a cookie banner, an analytics beacon),
+  never the data the flow carries: whether it is carried is the measurement.
+- A long flow may be split into segments, each starting where the previous one
+  ended, with no seeding inside a segment.
+
+Screen scenarios may seed state and deep link; they measure the screen's own
+resilience. Flow scenarios may not.
+
+When the scope cannot hold two flows (a single screen, a module with one
+entry and no onward path), write the ones it holds and record the shortfall
+under could-not-measure with the reason. Never pad the count with a flow that
+seeds its own state.
+
+## 5. Judgement rules
+
+- Do not propose what is already covered. A covered case listed as missing is
+  noise, not analysis.
+- Platforms differ. Device permissions and backgrounding have no web
+  equivalent; browser back, reload, deep links, horizontal overflow and
+  keyboard navigation are web-specific.
+- Ask for handles that carry identity (`data-order-id`, a row keyed by the
+  item id), never a list index, which moves when the order changes.
+- Open with "do these three first". An unranked list of twenty is not usable.
+
+## 6. Could not measure
+
+A separate section, always present. Each line names what could not be
+measured, why (no account, environment down, screen unreachable, data
+missing), and what would make it measurable. The absence of a measurement is
+not a positive result and never folds into COVERED.
+
+## 7. Output order
+
+1. The top three, with one line each on why.
+2. Bucket table: behaviour, bucket, test `file:line` where one exists.
+3. Scenarios in priority order, flows included and marked as flows.
+4. Handles needed, grouped by screen.
+5. Data needs.
+6. Could not measure.
+
+## Related
+
+- API and service gaps: `ai-backend-toolkit:scenario-gap-analysis` adds the
+  envelope, contract and service-chain rules.
+- Adding the handles the scenarios ask for: `handle-request`.
+- Judging a run of the written tests: `test-result-triage`.
+- Driving a running app to observe behaviour first: `e2e-testing`.

package/pipeline/skills/shared/external/scenario-gap-analysis/references/scenario-schema.md

@@ -0,0 +1,60 @@
+# Scenario schema
+
+One JSON object per scenario. Field names are the contract a test writer or a
+pipeline step reads; values follow the rules in `SKILL.md`.
+
+```json
+{
+  "id": "cart-total-after-coupon",
+  "title": "Cart total reflects a percentage coupon after quantity change",
+  "bucket": "WRONGLY_COVERED",
+  "coveredBy": "tests/cart/coupon.spec.ts:42",
+  "defectNotSeen": "asserts the coupon badge exists, never the total",
+  "priority": "bug-catching",
+  "businessReason": "A wrong total charges the customer a different amount than shown",
+  "kind": "screen",
+  "preconditions": ["signed-in account with an empty cart", "coupon code valid for 10 percent"],
+  "steps": ["add item A", "apply coupon", "change quantity to 3"],
+  "expectation": "total label equals 3 x unit price x 0.9, rounded to 2 decimals",
+  "automation": "yes",
+  "handles": ["cart_total_label", "cart_item_quantity_{itemId}"],
+  "dataNeeds": [{ "name": "coupon-10-percent", "supplied": "human" }],
+  "flakinessRisk": "none known"
+}
+```
+
+| Field | Values |
+|---|---|
+| `bucket` | `COVERED`, `WRONGLY_COVERED`, `MISSING` |
+| `coveredBy` | `file:line` of the existing test, or null for MISSING |
+| `priority` | `bug-catching`, `edge`, `baseline` |
+| `kind` | `screen` or `flow` |
+| `automation` | `yes`, `no`, `needs-code` (with the reason in `automationNote`) |
+| `dataNeeds[].supplied` | always `human` for credentials and personal data |
+
+## A flow scenario
+
+```json
+{
+  "id": "flow-browse-to-confirmation",
+  "title": "Item chosen on the list arrives unchanged on the confirmation screen",
+  "bucket": "MISSING",
+  "priority": "bug-catching",
+  "kind": "flow",
+  "steps": [
+    "open the catalogue from the home screen",
+    "open item A and pick size M",
+    "add to cart and go to checkout",
+    "confirm"
+  ],
+  "expectation": "confirmation shows item A, size M, the price shown on the item screen",
+  "rules": "no store seeding, no direct route to checkout, no mock of the cart request",
+  "automation": "yes"
+}
+```
+
+## Could-not-measure entry
+
+```json
+{ "what": "refund screen", "why": "no account with a completed order", "needs": "a seeded order supplied by a human" }
+```

package/pipeline/skills/shared/external/test-result-triage/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: test-result-triage
+description: "Judge each test result on changed code as product-bug, stale-test, valid or ambiguous (the default), and list behaviour no test covers. stale-test needs a diff file:line, product-bug needs evidence. Use when tests ran on a new commit, PR or fix. Not for writing or editing tests."
+metadata:
+  source: multi-agent-pipeline
+  version: 1.0.0
+---
+
+# Test result triage
+
+The product moved to a new commit and the tests ran against it. For every test
+that ran, decide what happens next. The decision is a plan for a human (or a
+setting) to approve; this skill does not edit tests or product code.
+
+Requires `@mmerterden/multi-agent-toolkit-mcp` >= v3.25.0 for
+`test_results_classify`. On an older server, or with no server, derive the
+input statuses by hand as section 2 describes and say in the report that the
+run used the fallback.
+
+## 1. The verdicts
+
+Each test that ran gets one of four verdicts:
+
+| Verdict | Meaning | What follows |
+|---|---|---|
+| `product-bug` | The test is right: behaviour broke without intent. | A finding is filed. The test is not changed. |
+| `stale-test` | Behaviour changed on purpose, or a handle moved; the test expects the old state. | The test is revised. |
+| `valid` | The test still measures the right thing on the new code. | Nothing. |
+| `ambiguous` | The evidence does not decide it. | A human decides. |
+
+The fifth outcome, `new-scenario`, belongs to the change rather than to a test:
+behaviour the change adds that no test exercises. It goes in `newScenarios`
+(section 5) and on to `scenario-gap-analysis`, never as a verdict on a test
+that ran.
+
+**The default is `ambiguous`.** Marking a product bug as `stale-test` loosens
+the test and buries the bug, which is the most expensive mistake this step can
+make. Calling a red test `product-bug` without evidence sends a team chasing a
+bug that is not there. Every verdict other than `ambiguous` needs positive
+evidence from section 4; a red test that the change merely fails to explain
+stays `ambiguous`.
+
+## 2. Inputs
+
+- **Classified results.** When the multi-agent-toolkit MCP server provides
+  `test_results_classify`, use its output as the input. It compares the head
+  run with a base run (the unchanged commit) and a confirmation run, and gives
+  each test a status with a reason:
+
+  | Status | How triage treats it |
+  |---|---|
+  | `passed` | Rule 4. Without a change analysis, read the diff for the area the test covers before calling it `valid`. |
+  | `regression` | Green on base, red twice on head. Rules 1 to 3, in order. |
+  | `preexisting` | Red on base too, so this change did not cause it. Never `stale-test` on this diff's evidence. `ambiguous` with the reason "red before the change", listed in its own section; `product-bug` (preexisting) only with the product `file:line` that causes it. |
+  | `unstable` | Flipped on confirmation or has a recent flake history. `ambiguous`; never green, never a product bug. |
+  | `not_measured` | Base, setup or environment did not measure it. `ambiguous` with the tool's reason. |
+
+  Without the tool, derive the same distinctions by hand: a setup failure, a
+  missing device or a server that did not start is not measured, not red.
+- **The change**: the diff from base to head, commit and PR titles, release
+  notes.
+- **The change analysis**, if one ran: which areas it expected to change and
+  how (behaviour change, new feature, refactor with no behaviour change).
+- **Run evidence**: failure message, failing step, trace, screenshot or DOM.
+
+## 3. Decision rules
+
+Apply them in this order; the first that matches decides.
+
+1. **Red because an element or locator was not found** -> check the handle
+   before anything else. Search the new tree for the element (`git grep` the
+   identifier, the text, the component).
+   - The element exists but carries no handle: `ambiguous` with the reason
+     "handle missing", and a request for `handle-request`. Not a stale test.
+   - The diff renames or moves the handle on purpose: `stale-test`, with the
+     diff `file:line`.
+   - The element is gone and the removal is intentional (diff `file:line`
+     plus a title or note saying so): `stale-test`.
+   - The element is gone and nothing says it was intended: `ambiguous`,
+     unless rule 3 finds positive evidence of a bug.
+2. **Red, and the diff changes that behaviour on purpose** (a commit title, a
+   new flow, new copy) -> `stale-test`. Cite the diff `file:line` and the
+   intent signal.
+3. **Red, with positive evidence of a bug** -> `product-bug`. Positive
+   evidence is one of:
+   - the test checks a contract (data loss, an error code, an empty body,
+     request and response parity) and the diff does not change that contract
+     on purpose;
+   - a product `file:line` that produces the wrong result;
+   - the change analysis states that behaviour in this area did not change,
+     yet the test that passed on base now fails.
+   Name the behaviour that broke. A red test with none of these stays
+   `ambiguous`.
+4. **Green** -> do not pass it only because it is green. When the change
+   analysis or the diff shows the behaviour this test covers changed, check
+   whether the test asserts the old behaviour or the new one: old, passing by
+   accident, `stale-test`; new, `valid`. When neither touches the area,
+   `valid`.
+5. **Failed for an environmental reason** (timeout, server down, network,
+   device) -> `ambiguous` with the reason. Never a product bug.
+6. **Anything else** -> `ambiguous`, naming the missing evidence.
+
+A test written in this same chain that stays red after revision has often
+caught a real bug. Calling it `product-bug` still needs the product code
+`file:line` that causes it.
+
+Separately from the per-test verdicts, list behaviour the change adds that no
+test exercised as `newScenarios`.
+
+## 4. Evidence per verdict
+
+| Verdict | Required |
+|---|---|
+| `stale-test` | Diff `file:line` that changes the behaviour or the handle, and the intent signal (title, note, spec). |
+| `product-bug` | Expected versus observed from the run, the behaviour that broke, and one piece of positive evidence from rule 3. |
+| `valid` | The green run, plus for rule 4 the reason the test asserts the new behaviour or why the area is untouched. |
+| `ambiguous` | Which piece of evidence is missing. |
+| `newScenarios[]` entry | The new behaviour and the diff `file:line` that adds it. |
+
+Many tests failing on the same handle or the same fixture form a cluster: prove
+one representative, decide the cluster together, and say in the reason that it
+was decided as a cluster.
+
+## 5. Output
+
+Every test that ran gets a verdict; a red test left without one reaches a human
+as "ambiguous: no verdict given", so leaving one out only delays it.
+
+```json
+{
+  "verdicts": [
+    {
+      "testId": "checkout.spec.ts > applies coupon",
+      "verdict": "stale-test",
+      "reason": "coupon field moved into a sheet on purpose",
+      "evidence": "src/checkout/CouponSheet.tsx:18, PR title 'move coupon entry to a sheet'",
+      "inputStatus": "regression"
+    }
+  ],
+  "newScenarios": [{ "behaviour": "...", "diff": "file:line" }]
+}
+```
+
+Write a report next to it: verdict and reason per test, a summary table by
+verdict, the `preexisting` section, and what could not be measured. On a long
+run, work screen by screen and save after each one, so a timeout loses nothing
+already decided.
+
+## Boundaries
+
+- No test edits, no product code edits.
+- No red test becomes `stale-test` while there is doubt.
+- A `product-bug` verdict is a report, never an automatic change to the test.
+
+## Related
+
+- `scenario-gap-analysis` for `newScenarios` entries.
+- `handle-request` for elements that exist but carry no handle.
+- `e2e-testing` for the passed / failed / blocked verdicts of a single run.
+- `fix-review-verdicts` when the red test led to a fix that now needs review.

package/pipeline/skills/skills-index.md

@@ -3,7 +3,7 @@
 > Auto-generated by `pipeline/scripts/build-skills-index.mjs`  -  do not hand-edit.
 > Regenerate with `node pipeline/scripts/build-skills-index.mjs`.
 
-**229 skills** across 2 groups.
+**234 skills** across 2 groups.
 
 | Group | Name | Platform | Description |
 |-------|------|----------|-------------|
@@ -24,7 +24,7 @@
 | external | `app-intents` |  -  | App Intents for Siri, Shortcuts, Spotlight, widgets, Control Center and Apple Intelligence: AppIntent actions, AppEntity and EntityQuery, Ap |
 | external | `app-store-changelog` |  -  | Generate user-facing App Store release notes from git history since the last tag. Use when release notes have to be written from the commits |
 | external | `app-store-optimization` |  -  | App Store Optimization (ASO) for ranking and conversion: keyword research; app name, subtitle and 100-byte keyword field; description and pr |
-| external | `app-store-review` |  -  | App Store submission readiness and rejection prevention: Review Guidelines 2.1, 2.3, 2.5.1, 3.1.1, 4.2 and 5.1.2, PrivacyInfo.xcprivacy mani |
+| external | `app-store-review` |  -  | App Store submission readiness and rejection prevention: Review Guidelines 1.2, 2.1, 2.3, 2.3.14, 2.5.1, 2.5.19, 3.1.1, 4.2 and 5.1.2, uploa |
 | core | `apple-archive-compliance` |  -  | Apple App Store Review compliance  -  wraps the multi-agent-toolkit-mcp `ios_app_store_audit` tool (18-rule deep scan) with ITMS error code  |
 | external | `apple-on-device-ai` |  -  | On-device AI on Apple hardware: Foundation Models (SystemLanguageModel, LanguageModelSession, @Generable and @Guide structured output, tool  |
 | external | `architecture` |  -  | Stack-neutral architecture decisions: quality drivers, options with a trade-off matrix, reversibility, ADRs, fitness checks. Use when making |
@@ -61,9 +61,11 @@
 | external | `evidence-registry` |  -  | Check a package's real version, deprecation status and release notes on npm, PyPI, Maven Central or Swift Package Index. Use when a spec or  |
 | external | `fastapi-pro` |  -  | FastAPI with Pydantic v2: lifespan, settings, Annotated dependencies, async SQLAlchemy 2.0 sessions, error handlers, background work, httpx  |
 | external | `firebase` |  -  | You're a developer who has shipped dozens of Firebase projects. You've seen the easy path lead to security breaches, runaway costs, and impo |
+| external | `fix-review-verdicts` |  -  | Independent fix review with three verdicts, test-gaming, scope and root-cause, each backed by file:line findings; the result is computed fro |
 | external | `github-actions-templates` |  -  | Authoring GitHub Actions workflows: triggers, matrices, caching, concurrency, least-privilege permissions, SHA pinning, OIDC, reusable workf |
 | core | `google-play-compliance` |  -  | Google Play Store publication compliance  -  bundletool + aapt2 + apksigner orchestration + 21-rule policy catalog with Play Console error c |
 | external | `gradle-kotlin-dsl` |  -  | Configure Android builds with Gradle Kotlin DSL, version catalogs (libs.versions.toml), convention plugins (build-logic module), common conf |
+| external | `handle-request` |  -  | Add the test handles a scenario needs and answer each request with ADDED, ALREADY or COULD NOT ADD plus file:line or reason. Identity values |
 | external | `healthkit` |  -  | HealthKit on iOS, iPadOS, watchOS and visionOS: HKHealthStore authorization, sample, statistics and chart-ready collection queries, saving H |
 | external | `hig-app-icons` |  -  | iOS app icons: Icon Composer layered icons, default, dark, clear and tinted appearances, asset catalogs, alternate icons and the archive che |
 | external | `hig-components-content` |  -  | Apple HIG for content views mapped to SwiftUI: lists, tables, grids, charts, images, text, web views, empty states. Use when choosing or rev |
@@ -160,6 +162,7 @@
 | core | `multi-agent-test-accessibility` |  -  | Accessibility audit on a booted simulator / emulator: VoiceOver labels, sub-44pt tap targets, contrast, traits. Alias pinning the accessibil |
 | core | `multi-agent-test-dark-mode` |  -  | Dark mode UI test on a booted simulator / emulator: walk every screen light then dark, report contrast + colour bugs. Alias pinning the dark |
 | core | `multi-agent-test-dynamic-type` |  -  | Dynamic Type layout test on a booted simulator / emulator: re-walk every screen at XL through accessibility-extra-large, report truncation a |
+| core | `multi-agent-test-gen` |  -  | Write the tests an app lacks, stage by stage, each gated on its artefact: inventory, read-only gap analysis, handles, tests, runs, per-test  |
 | core | `multi-agent-test-screenshots` |  -  | App Store screenshot set from a booted simulator / emulator in a given locale, taken as an argument and defaulting to tr. Alias pinning the  |
 | core | `multi-agent-testflight-validation` |  -  | iOS-pinned alias of store-ready: same three gates on an iOS build, one implementation. Validates a TestFlight / App Store package, never upl |
 | core | `multi-agent-uninstall` |  -  | Uninstall the pipeline from Claude Code + Copilot CLI. Keychain access tokens are always left untouched; --all-data also clears pipeline set |
@@ -182,6 +185,7 @@
 | external | `rest-api-design` |  -  | REST API design: HTTP methods, status codes, pagination, versioning, rate limiting, caching headers, OpenAPI documentation. Use when a REST  |
 | external | `retrofit-networking` |  -  | Build networking layers on Android with Retrofit, OkHttp, and Kotlin Coroutines. Covers suspend functions in API interfaces, OkHttp intercep |
 | external | `room-database` |  -  | Implement Room database persistence on Android with @Entity, @Dao, @Database, Flow-based reactive queries, TypeConverters for complex types, |
+| external | `scenario-gap-analysis` |  -  | Set an inventory against existing tests, sort each behaviour into COVERED, WRONGLY COVERED or MISSING, and write gaps as measurable, priorit |
 | external | `search-first` |  -  | Research-before-coding workflow. Before writing a custom implementation, check what already exists (repo utilities, installed libraries, pac |
 | external | `security-review` |  -  | Run a defensive, static security review of a diff or a repo: build a run-scoped threat model, find vulnerabilities joined to OWASP + CWE wit |
 | external | `shareplay-activities` |  -  | GroupActivities and SharePlay on iOS, macOS, tvOS and visionOS: GroupActivity, GroupSession lifecycle, messengers, playback sync, file trans |
@@ -220,6 +224,7 @@
 | external | `swiftui-view-refactor` |  -  | Refactor SwiftUI views into smaller components with stable, explicit data flow. Use when a SwiftUI view has grown too large and needs splitt |
 | external | `swiftui-webkit` |  -  | Web content in SwiftUI with WebKit for SwiftUI: WebView, WebPage, observable page state, navigation policies, link interception, JavaScript  |
 | external | `tailwind-css` |  -  | Tailwind CSS v4: utility-first styling, responsive design, dark mode, custom themes, component patterns, and cn() utility. Use when styling  |
+| external | `test-result-triage` |  -  | Judge each test result on changed code as product-bug, stale-test, valid or ambiguous (the default), and list behaviour no test covers. stal |
 | external | `testing-backend` |  -  | Backend testing: pytest patterns (Python), Jest patterns (Node.js), integration testing, database fixtures/factories, API contract testing.  |
 | external | `tipkit` |  -  | TipKit in-app tips (iOS 17+): Tip protocol, TipView, popoverTip, rules, events, TipGroup, styles, CloudKit sync. Use when building or review |
 | external | `typescript-patterns` |  -  | Modern TypeScript patterns: strict mode, utility types, generics, conditional types, type guards, discriminated unions, Zod validation. Use  |

package/install/_telemetry.mjs

@@ -1,61 +0,0 @@
-/**
- * Anonymous install telemetry (opt-in only).
- *
- * Set `MULTI_AGENT_TELEMETRY=1` to enable. Nothing is sent otherwise.
- * Fire-and-forget; never throws and never delays the install.
- *
- * The payload is genuinely anonymous: package name, version, install
- * method, flags, platform/arch, and Node version. No usernames, emails,
- * hostnames, or other machine/user identifiers are collected.
- *
- * @module install/_telemetry
- */
-
-import { readFileSync } from "fs";
-import { platform, arch } from "os";
-import { join } from "path";
-
-/**
- * @param {{ packageRoot: string, flags: string[] }} ctx
- * @returns {Promise<void>}
- */
-export async function sendInstallTelemetry(ctx) {
-  if (process.env.MULTI_AGENT_TELEMETRY !== "1") return;
-
-  let method = "source";
-  const npmExecPath = process.env.npm_execpath ?? "";
-  if (npmExecPath.includes("npx-cli")) method = "npx";
-  else if (process.env.npm_config_global === "true") method = "global";
-  else if (process.env.npm_lifecycle_event === "install") method = "npm-install";
-
-  let version = "unknown";
-  try {
-    const pkg = JSON.parse(readFileSync(join(ctx.packageRoot, "package.json"), "utf-8"));
-    version = pkg.version ?? version;
-  } catch {
-    /* ignore */
-  }
-
-  const payload = {
-    package: "@mmerterden/multi-agent-pipeline",
-    version,
-    method,
-    flags: ctx.flags.filter((f) => f.startsWith("--")),
-    platform: `${platform()} ${arch()}`,
-    nodeVersion: process.version,
-  };
-
-  try {
-    const ctrl = new AbortController();
-    const timer = setTimeout(() => ctrl.abort(), 2000);
-    await fetch("https://mmerterden.vercel.app/api/install-notify", {
-      method: "POST",
-      headers: { "Content-Type": "application/json" },
-      body: JSON.stringify(payload),
-      signal: ctrl.signal,
-    });
-    clearTimeout(timer);
-  } catch {
-    // Silent fail - never break the install if telemetry is unreachable
-  }
-}