@codyswann/lisa 2.121.0 → 2.122.0

package/plugins/lisa-expo-cursor/skills/eas-update-insights/SKILL.md

@@ -0,0 +1,228 @@
+---
+name: eas-update-insights
+description: "Check the health of published EAS Updates: crash rates, install/launch counts, unique users, payload size, and the split between embedded and OTA users per channel. Use when the user asks how an update is performing, whether a rollout is healthy, how many users are on the embedded build vs OTA, or wants to gate CI on update health."
+version: 1.0.0
+license: MIT
+allowed-tools: "Bash(eas *)"
+---
+
+# EAS Update Insights
+
+Query the health of published EAS Updates directly from the CLI: launches, failed launches, crash rates, unique users, payload size, the embedded-vs-OTA user split per channel, and the most popular updates per runtime version. The data is the same data that powers the update and channel detail pages on expo.dev; these commands expose it in the terminal in human and JSON form.
+
+## When to use this skill
+
+Use this when the user wants to assess the health or adoption of a published EAS Update: crash rates, install counts, unique users, bundle size, or the split between embedded and OTA users on a channel.
+
+Example prompts:
+
+- "How is the latest update doing?"
+- "Is the latest update healthy?"
+- "Is the new release crashing more than the last one?"
+- "How many users are on the latest update vs the embedded build?"
+- "Which update is most popular on production right now?"
+- "How big is our update bundle?"
+
+Also fits: post-publish rollout monitoring and regression detection.
+
+Don't use when the user needs per-user crash detail or device-level reporting; this skill only exposes aggregate EAS metrics.
+
+## Prerequisites
+
+- `eas-cli` installed (`npm install -g eas-cli`).
+- Logged in: `eas login`.
+- For `channel:insights`: run from an Expo project directory (the command resolves the project ID from `app.json`). `update:insights` only needs a login.
+
+## Commands at a glance
+
+| Command | Purpose |
+|---|---|
+| `eas update:list` | Discover recent update groups, their `group` IDs, and branch names |
+| `eas update:insights <groupId>` | Per-platform launches, failed launches, crash rate, unique users, payload size, daily breakdown |
+| `eas update:view <groupId> --insights` | Update group details + the same metrics appended |
+| `eas channel:insights --channel <name> --runtime-version <version>` | Embedded/OTA user counts, most popular updates, cumulative metrics for a channel + runtime |
+
+All of these support `--json --non-interactive` for programmatic parsing.
+
+## Discovering IDs
+
+Before querying insights for an update group, you need its `group` ID. Use `eas update:list` with either `--branch <name>` (updates on that branch) or `--all` (updates across all branches). Always pass `--json --non-interactive` when running non-interactively; without a branch/`--all` flag the command will otherwise prompt for a branch selection:
+
+```bash
+# Latest group id across all branches
+eas update:list --all --json --non-interactive | jq -r '.currentPage[0].group'
+
+# Latest group id on a specific branch
+eas update:list --branch production --json --non-interactive | jq -r '.currentPage[0].group'
+```
+
+The JSON response has a `currentPage` array with one entry per update group (both platforms of the same publish are collapsed into one entry):
+
+```json
+{
+  "currentPage": [
+    {
+      "branch": "production",
+      "message": "\"Fix checkout crash\" (1 week ago by someone)",
+      "runtimeVersion": "1.0.6",
+      "group": "03d5dfcf-736c-475a-8730-af039c3f4d06",
+      "platforms": "android, ios",
+      "isRollBackToEmbedded": false
+    }
+  ]
+}
+```
+
+Entries also carry `codeSigningKey` and `rolloutPercentage`, but only when those features are in use for the group (undefined values are omitted from the JSON output).
+
+When called with `--branch <name>`, the response also includes `name` (the branch name) and `id` (the branch ID) at the top level.
+
+## `eas update:insights <groupId>`
+
+Shows launches, failed launches, crash rate, unique users, launch asset count, and average payload size for a single update group, broken down **per platform** (iOS, Android), plus a daily breakdown of launches and failures.
+
+### Basic use
+
+```bash
+eas update:insights 03d5dfcf-736c-475a-8730-af039c3f4d06
+```
+
+### Flags
+
+| Flag | Description |
+|---|---|
+| `--days <N>` | Look back N days. Default: **7**. Mutually exclusive with `--start`/`--end`. |
+| `--start <iso-date>` / `--end <iso-date>` | Explicit time range, e.g. `--start 2026-04-01 --end 2026-04-15`. |
+| `--platform <ios\|android>` | Filter to a single platform. Omit to see all platforms in the group. |
+| `--json` | Machine-readable output. Implies `--non-interactive`. |
+| `--non-interactive` | Required when scripting. |
+
+### JSON output shape
+
+Top level: `groupId`, `timespan` (`start`, `end`, `daysBack`), and `platforms[]` with one entry per platform the group was published to. Each platform entry has `updateId`, `totals` (`uniqueUsers`, `installs`, `failedInstalls`, `crashRatePercent`), `payload` (`launchAssetCount`, `averageUpdatePayloadBytes`), and a `daily[]` time series of `{ date, installs, failedInstalls }`.
+
+For the complete schema and field reference, see [references/update-insights-schema.md](./references/update-insights-schema.md).
+
+Fields that matter for health assessment:
+
+- `platforms[].totals.crashRatePercent`, computed as `failedInstalls / (installs + failedInstalls) * 100`. Zero when there are no installs.
+- `platforms[].totals.installs` and `uniqueUsers` give the adoption signal.
+- `platforms[].daily` is a time series, useful for spotting a sudden spike in failures.
+
+### Errors
+
+- `Could not find any updates with group ID: "<id>"` — group doesn't exist or you lack access.
+- `Update group "<id>" has no ios update (available platforms: android)` — `--platform ios` was used but the group wasn't published for iOS.
+- `EAS Update insights is not supported by this version of eas-cli. Please upgrade ...` — the server deprecated a field the CLI relies on. Run `npm install -g eas-cli@latest`.
+
+## `eas update:view <groupId> --insights`
+
+Extends the standard `update:view` output with the same per-platform insights, inline.
+
+```bash
+# Human-readable
+eas update:view 03d5dfcf-... --insights
+eas update:view 03d5dfcf-... --insights --days 30
+
+# JSON: wrapped as { updates: [...], insights: {...} }
+eas update:view 03d5dfcf-... --json --insights
+```
+
+Without `--insights`, `update:view` behaves exactly as before — no JSON shape change for existing consumers. The `--days` / `--start` / `--end` flags only apply when `--insights` is set; passing them alone errors.
+
+## `eas channel:insights --channel <name> --runtime-version <version>`
+
+Shows, per channel, how many users are on the embedded build vs over-the-air updates and which updates are pulling the most traffic. Must be run from an Expo project directory.
+
+### Basic use
+
+```bash
+eas channel:insights --channel production --runtime-version 1.0.6
+```
+
+### Flags
+
+| Flag | Description |
+|---|---|
+| `--channel <name>` | **Required.** The channel name (e.g. `production`, `staging`). |
+| `--runtime-version <version>` | **Required.** Match exactly what was published. Check `runtimeVersion` values in `update:list`. |
+| `--days <N>` | Look back N days. Default: **7**. |
+| `--start` / `--end` | Explicit time range, like `update:insights`. |
+| `--json` / `--non-interactive` | Machine-readable output. |
+
+### JSON output shape
+
+Top level: `channel`, `runtimeVersion`, `timespan`, `embeddedUpdateTotalUniqueUsers`, `otaTotalUniqueUsers`, `mostPopularUpdates[]` (each with `rank`, `groupId`, `message`, `platform`, `totalUniqueUsers`), `cumulativeMetricsAtLastTimestamp[]`, plus chart-shaped `uniqueUsersOverTime` and `cumulativeMetricsOverTime` objects with `labels` and `datasets`.
+
+For the complete schema and field reference, see [references/channel-insights-schema.md](./references/channel-insights-schema.md).
+
+Fields that matter:
+
+- `embeddedUpdateTotalUniqueUsers` is the count of users running the embedded (binary-bundled) build.
+- `mostPopularUpdates[]` is updates ranked by `totalUniqueUsers`. **Caveat**: this is the top-N the server returns; `otaTotalUniqueUsers` is a sum of that list and may undercount total OTA reach if more than top-N updates are active.
+- `uniqueUsersOverTime` and `cumulativeMetricsOverTime` are daily data series for charting.
+
+### Errors
+
+- `Could not find channel with the name <name>` — typo or wrong account.
+- "No update launches recorded" in the table / empty `mostPopularUpdates` in JSON — no OTA update has been launched for that channel + runtime yet. Usually means the channel is still serving the embedded build only.
+
+## Common workflows
+
+### Verify the update I just published is healthy
+
+```bash
+# 1. Grab the latest publish on production
+GROUP_ID=$(eas update:list --branch production --json --non-interactive \
+  | jq -r '.currentPage[0].group')
+
+# 2. Give it some adoption time (minutes to hours), then check crash rate
+eas update:insights "$GROUP_ID" --json --non-interactive \
+  | jq '.platforms[] | {platform, installs: .totals.installs, crashRate: .totals.crashRatePercent}'
+```
+
+Compare the `crashRate` across platforms and against previous releases; sudden spikes or asymmetric behaviour (iOS spiking while Android is flat, or vice versa) is the signal to investigate.
+
+### Compare adoption between two channels
+
+```bash
+for channel in production staging; do
+  echo "--- $channel ---"
+  eas channel:insights --channel "$channel" --runtime-version 1.0.6 --json --non-interactive \
+    | jq '{
+        channel,
+        embedded: .embeddedUpdateTotalUniqueUsers,
+        ota: .otaTotalUniqueUsers,
+        topUpdate: .mostPopularUpdates[0]
+      }'
+done
+```
+
+### Detect a rollout regression in the last 24 hours
+
+```bash
+eas update:insights "$GROUP_ID" --days 1 --json --non-interactive \
+  | jq '.platforms[] | select(.totals.crashRatePercent > 1)'
+```
+
+### Summarize group metrics for release notes
+
+```bash
+eas update:view "$GROUP_ID" --insights --days 30
+```
+
+Human-readable group details plus 30 days of launches/failures per platform — suitable for pasting into a changelog or incident review.
+
+## Output tips
+
+- Pipe JSON through `jq`; payloads are structured for easy filtering.
+- `--json` implies `--non-interactive`, but passing both is explicit and scripting-friendly.
+- Dates in `daily[].date` are UTC ISO timestamps; the human-readable table renders them as `YYYY-MM-DD` (UTC).
+- The CLI table labels say "Launches" / "Crashes" while JSON uses `installs` / `failedInstalls`. Same field, different display name.
+
+## Limitations
+
+- **Unique users across platforms** may double-count users who run the same publish on both iOS and Android. The same caveat applies to `otaTotalUniqueUsers` in channel insights, which is a sum over `mostPopularUpdates`.
+- **Fresh publishes** may show zeros for a short period while the metrics pipeline catches up.
+- **Installs are downloads, not launches**: the `installs` / "Launches" field counts users who downloaded the manifest and launch asset. A confirmed run only registers on the user's *next* update check (typically up to 24h later, depending on the app's update policy). So metrics lag the real-world state slightly.
+- **Crashes are self-reported**: `failedInstalls` / "Crashes" counts updates that errored during install/launch and were reported on the next update check. Crashes that don't trigger an update request (e.g. process kill before recovery) won't appear.

package/plugins/lisa-expo-cursor/skills/eas-update-insights/references/channel-insights-schema.md

@@ -0,0 +1,47 @@
+# `eas channel:insights` JSON schema
+
+Complete JSON output shape returned by `eas channel:insights --channel <name> --runtime-version <version> --json --non-interactive`.
+
+```json
+{
+  "channel": "production",
+  "runtimeVersion": "1.0.6",
+  "timespan": { "start": "...", "end": "...", "daysBack": 7 },
+  "embeddedUpdateTotalUniqueUsers": 2401,
+  "otaTotalUniqueUsers": 8312,
+  "mostPopularUpdates": [
+    {
+      "rank": 1,
+      "groupId": "abc123",
+      "message": "Fix checkout crash",
+      "platform": "ios",
+      "totalUniqueUsers": 4210
+    }
+  ],
+  "cumulativeMetricsAtLastTimestamp": [
+    { "id": "...", "label": "Embedded update", "data": 12345 },
+    { "id": "...", "label": "Embedded update failed installs", "data": 0 }
+  ],
+  "uniqueUsersOverTime": { "labels": ["..."], "datasets": [ { "id": "...", "label": "...", "data": [100, 200] } ] },
+  "cumulativeMetricsOverTime": { "labels": ["..."], "datasets": [ { "id": "...", "label": "...", "data": [10, 20] } ] }
+}
+```
+
+## Field reference
+
+| Path | Meaning |
+|---|---|
+| `channel` | The channel queried. |
+| `runtimeVersion` | The runtime version filter used. Channel insights are always scoped to a single runtime. |
+| `timespan.start` / `.end` / `.daysBack` | Window bounds (UTC ISO) and size in days. |
+| `embeddedUpdateTotalUniqueUsers` | Distinct users running the embedded (binary-bundled) build in the window. |
+| `otaTotalUniqueUsers` | Sum of `totalUniqueUsers` across `mostPopularUpdates`. May undercount if more than top-N updates are active (see caveat below). |
+| `mostPopularUpdates[]` | Top-N updates ranked by `totalUniqueUsers`. Each entry has `rank`, `groupId`, `message`, `platform`, `totalUniqueUsers`. |
+| `cumulativeMetricsAtLastTimestamp[]` | Snapshot totals at the end of the window, labelled (e.g., "Embedded update", "Embedded update failed installs"). |
+| `uniqueUsersOverTime` | Chart-shaped object with `labels` (dates) and `datasets` for plotting unique users over time. |
+| `cumulativeMetricsOverTime` | Chart-shaped object for plotting cumulative metrics over time. |
+
+## Caveats
+
+- `otaTotalUniqueUsers` is a sum of `mostPopularUpdates[].totalUniqueUsers`. If more OTA updates are active than the top-N the server returns, this figure undercounts true OTA reach.
+- A user running the same publish on both iOS and Android may be counted on each platform. Don't treat `uniqueUsers` as cross-platform-deduped.

package/plugins/lisa-expo-cursor/skills/eas-update-insights/references/update-insights-schema.md

@@ -0,0 +1,69 @@
+# `eas update:insights` JSON schema
+
+Complete JSON output shape returned by `eas update:insights <groupId> --json --non-interactive`.
+
+```json
+{
+  "groupId": "03d5dfcf-736c-475a-8730-af039c3f4d06",
+  "timespan": {
+    "start": "2026-04-10T00:00:00.000Z",
+    "end": "2026-04-17T00:00:00.000Z",
+    "daysBack": 7
+  },
+  "platforms": [
+    {
+      "platform": "android",
+      "updateId": "019d72ca-...",
+      "totals": {
+        "uniqueUsers": 500,
+        "installs": 990,
+        "failedInstalls": 10,
+        "crashRatePercent": 1.0
+      },
+      "payload": {
+        "launchAssetCount": 4,
+        "averageUpdatePayloadBytes": 1115771
+      },
+      "daily": [
+        { "date": "2026-04-10T00:00:00.000Z", "installs": 182, "failedInstalls": 2 },
+        { "date": "2026-04-11T00:00:00.000Z", "installs": 195, "failedInstalls": 1 }
+      ]
+    },
+    {
+      "platform": "ios",
+      "updateId": "019d72ca-...",
+      "totals": { "uniqueUsers": 100, "installs": 1, "failedInstalls": 0, "crashRatePercent": 0 },
+      "payload": { "launchAssetCount": 4, "averageUpdatePayloadBytes": 1115771 },
+      "daily": [ { "date": "2026-04-10T00:00:00.000Z", "installs": 1, "failedInstalls": 0 } ]
+    }
+  ]
+}
+```
+
+## Field reference
+
+| Path | Meaning |
+|---|---|
+| `groupId` | The update group queried. |
+| `timespan.start` / `.end` | UTC ISO timestamps bounding the window. |
+| `timespan.daysBack` | Convenience field: size of the window in days. |
+| `platforms[]` | One entry per platform the group was published to (`ios`, `android`). |
+| `platforms[].updateId` | Platform-specific update ID (distinct from the group ID). |
+| `platforms[].totals.uniqueUsers` | Distinct users who ran this update in the window. |
+| `platforms[].totals.installs` | Launches / successful installs in the window. |
+| `platforms[].totals.failedInstalls` | Crashes / failed installs in the window. |
+| `platforms[].totals.crashRatePercent` | `failedInstalls / (installs + failedInstalls) * 100`. Zero when no installs. |
+| `platforms[].payload.launchAssetCount` | Number of assets the manifest references. |
+| `platforms[].payload.averageUpdatePayloadBytes` | Mean bundle size for the window. |
+| `platforms[].daily[]` | Per-day time series of installs and failed installs. |
+
+## `eas update:view <groupId> --insights --json`
+
+The `update:view --insights --json` command wraps the same insights payload:
+
+```json
+{
+  "updates": [ /* standard update:view entries */ ],
+  "insights": { /* same shape as eas update:insights above */ }
+}
+```

package/plugins/lisa-expo-cursor/skills/exploratory-qa/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: exploratory-qa
+description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (machine-style labels, slow or unclear loads, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
+---
+
+# Exploratory QA
+
+## Overview
+
+Experience the app the way a **brand-new human user** would: land cold on the home page with no prior
+knowledge, then click through and actually try to use it — just like a real person. The goal is to
+surface anything **confusing, broken, or hard to understand**, and to do so at **every breakpoint**.
+
+This is a usability/experience pass, **not** a test-coverage audit. It does not look at the Playwright
+suite or hunt for coverage gaps — for that, use the `e2e-coverage-gaps` skill. Here, every finding is
+filed as a tracked work item so it enters the Lisa lifecycle — no static report file.
+
+## Parameters
+
+- **`target-url | env`** (first positional) — what to explore.
+- **`ready=true|false`** — the build-ready state for the tickets this pass creates.
+  - `ready=true` → created build-ready, so `lisa:intake` / the build-intake scanner auto-picks them up.
+  - `ready=false` (**default**) → created in the backlog (not build-ready) for a human to review and
+    promote into the queue.
+
+## Core Workflow
+
+### 1. Establish Scope
+
+- Identify the target environment, account type, and browser requirement, and read the `ready` flag
+  (default `false`).
+- **Confirm the tracker is configured.** Findings are filed as tickets, so read `tracker` from
+  `.lisa.config.json` (local overrides global). If it is unset, stop and report that the tracker must
+  be configured (via `/lisa:setup:jira` / `:github` / `:linear`) before exploratory QA can file
+  findings — do not silently fall back to a report file.
+- If credentials, tenant, or seed data are missing and cannot be discovered safely, ask one concise
+  clarifying question.
+- Treat production-like environments conservatively. Do not mutate production data unless the user
+  explicitly approves it. Prefer a test user, dev/staging environment, or isolated seeded account.
+
+### 2. Arrive Cold
+
+- Start at the home/landing page with **no prior knowledge of the app**. Do **not** pre-read the
+  codebase to learn the intended flows — discover them the way a user would, by looking and clicking.
+- Form a first impression: is it obvious what this app is, what to do first, and where to go next?
+
+### 3. Use It Like a Human
+
+Click through the visible paths and actually attempt real tasks — a first-time user explores, makes
+mistakes, and tries the obvious thing. Cover at least these dimensions unless the user narrows scope:
+
+- **Comprehension & labeling:** machine-style or developer labels shown to users (raw IDs, enum keys,
+  `snake_case`, `null`/`undefined`, untranslated i18n keys), jargon, unclear button/menu names, icons
+  with no discernible meaning.
+- **Navigation clarity:** is it obvious how to get somewhere and back? Dead ends, hidden entry points,
+  surprising redirects, broken links, no clear "home".
+- **Visual/layout quality:** cut-off or truncated text, overlap, cramped/crowded density, offscreen or
+  unreachable controls, accidental horizontal scroll, awkward empty space.
+- **Consistency / standard UX:** components, spacing, button styles, terminology, and interaction
+  patterns should be consistent across the app and follow common conventions. Flag anything
+  non-standard or that differs screen-to-screen.
+- **Load & responsiveness:** long or unclear load times, blank screens, spinners / `Loading...` /
+  `Connecting...` with no progress, anything that feels slow or janky.
+- **Scroll behavior:** unexpected scroll position, scroll jumps, nested or locked scroll, sticky
+  elements that cover content, content that cannot be reached.
+- **Behavior correctness:** does the obvious action do what a user expects? Confusing errors, silent
+  failures, disabled controls with no explanation, state that does not persist.
+- **Affordance clarity:** can the user tell what is clickable, required, in-progress, or complete?
+
+### 4. Cover All Breakpoints
+
+- Discover breakpoints from the app (design tokens, CSS, responsive layout changes) when possible; if
+  unknown, use a practical baseline: phone, tablet/narrow, desktop, plus any app-specific cutoff.
+- At each breakpoint, walk the key paths again and confirm the experience holds: expected
+  shell/navigation variant, critical controls visible and reachable, no unintended horizontal
+  overflow, intentional scroll containers still usable, nothing cut off or crowded.
+
+### 5. Watch Load & Latency
+
+- Notice time to first meaningful content and time spent in blank/loading/spinner/connecting states.
+- A page can be technically interactive but still visually incomplete — note that.
+- Treat long waits without clear progress, error, retry, or cancellation as findings. Use practical
+  labels (noticeable, slow, unacceptable) and include observed durations when available.
+
+## Mutation Discipline
+
+A real first-time user creates, edits, and deletes things — exercise those flows when the environment
+is safe.
+
+- Use unique names with a clear prefix such as `qa-` or `codex-`.
+- Before mutating, identify the cleanup path. After mutating, make a best effort to clean up through
+  the UI, then verify cleanup. If UI cleanup is unavailable, that itself is a usability finding.
+- Avoid destructive bulk actions unless the user explicitly asks or the account is clearly disposable.
+- Record all mutations performed, cleanup attempts, and any residue left behind.
+
+## Filing findings as tracked work
+
+This skill does **not** write a report file. Every finding becomes a **leaf work item** created via
+`lisa:tracker-write` (the vendor-neutral writer — it dispatches to the configured tracker and runs the
+validation gate; never call a vendor `*-write-*` skill directly). Map each finding to a type:
+
+| Finding | `issue_type` | `build_ready` |
+|---------|--------------|---------------|
+| User-visible **bug** (broken behavior) | `Bug` | the `ready` flag (default `false`) |
+| **Usability / UX / clarity issue** | `Improvement` | the `ready` flag (default `false`) |
+
+Each finding is a flat leaf (no children), so `build_ready` applies directly — pass it explicitly on
+every create. Each ticket MUST be a complete spec (the validator rejects thin tickets):
+
+- **Three-audience description** (context / business value, technical approach, stakeholder impact).
+- **For a bug:** exact reproduction steps, observed-vs-expected, the env / account / breakpoint it
+  occurred at, and console/network evidence.
+- **For a usability issue:** the observed friction (what was confusing, cramped, inconsistent, or hard
+  to understand), who it affects, **where** (route + breakpoint), and the proposed improvement.
+- **Gherkin acceptance criteria** describing the fixed behavior.
+
+### Idempotency — don't spam duplicates
+
+Re-running a pass must not refile the same finding. Before creating a ticket, search the tracker for an
+**open** ticket carrying a stable marker `[lisa-exploratory-qa] <finding-key>` in its body (the
+`<finding-key>` is a stable slug of surface + symptom, e.g. `settings-modal/horizontal-overflow@tablet`).
+If one exists, reference/update it instead of creating a duplicate; only create when none exists.
+**Match by the marker, never by title** (titles get edited). A *closed* prior ticket does not suppress a
+new one — a recurrence after a fix is a genuine regression.
+
+## Output
+
+No report file. Emit a concise in-session summary:
+
+- **Scope:** target URL/env, browser/tool, account type, build/version if visible, date.
+- **First impression:** could a new user tell what the app is and what to do first?
+- **Findings filed**, bucketed by type — bugs, usability/clarity issues — each with its **created or
+  referenced ticket ref** and its **build-ready state** (`ready` vs `triage/backlog`).
+- **Observed but not filed:** anything noticed but intentionally not ticketed, with why.
+
+## Quality Bar
+
+- Explore as a true first-time user — judge clarity, not whether you (who can read the code) can figure
+  it out.
+- Prefer concrete, reproducible findings. Every ticket must stand alone for an implementer who was not
+  in the session.
+- Do not claim cleanup succeeded unless verified.
+- File tickets per the `ready` flag (default: backlog for human triage).
+- This skill is about the human experience only — route automated-coverage gaps to `e2e-coverage-gaps`.
+- Preserve unrelated repo changes.