@codyswann/lisa 2.232.0 → 2.233.0

package/plugins/src/base/skills/lisa-qa-clear/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: lisa-qa-clear
+description: "Bulk-clear tickets a human QA tester cannot verify. Finds tickets in the configured QA queue status that are scoped entirely to non-user-facing repos (API/backend services, infrastructure) — where QA has only end-user access and nothing observable to test — and transitions them to the configured certified status, reporting the moved list for the record. Runnable from any coding agent as a single instruction like 'move all backend- and infrastructure-only tickets from the QA queue to certified'."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
+---
+
+# QA Clear: $ARGUMENTS
+
+Human QA can only judge what a user can see. Tickets whose entire scope is a
+non-user-facing repo were already verified by the automated lifecycle before reaching the
+QA queue; holding them for a human who cannot observe them is pure queue noise. Clear
+them in one auditable batch.
+
+## Config resolution
+
+Read `.lisa.config.json`:
+
+- **QA queue status** — `jira.workflow.qa.queue`, falling back to
+  `jira.workflow.done.staging`.
+- **Certified status** — `jira.workflow.qa.certified`. Required; if missing, stop and
+  instruct the operator — never guess a terminal status.
+- **Tracker dispatch** — `tracker` decides the surface as everywhere; on GitHub or
+  Linear the status names above map to the equivalent labels/states.
+- **Non-user-facing repos** — `qa.nonUserFacingRepos` (array of repo names, e.g.
+  `["api", "infrastructure"]`). If the key is missing, derive a proposal from
+  the project registry (repos with no UI framework signals — no expo/react/native/web
+  app surface) and **present it for operator confirmation before moving anything**; never
+  bulk-transition on an unconfirmed inference. Recommend persisting the confirmed list to
+  the config.
+
+## Procedure
+
+1. Query all tickets in the QA queue status.
+2. Classify each by repo scope, in order:
+   - `repo:<name>` label or matching component → that repo.
+   - Unlabeled → determine the repo from the ticket content (description, AC, technical
+     approach) exactly as build-intake's repo-scope gate does, and stamp the
+     `repo:<name>` label while you're there so the next sweep is cheap.
+   - Undeterminable → leave in place; flag for the operator.
+3. Partition:
+   - **Every** touched repo is non-user-facing → eligible to clear.
+   - Any user-facing repo in scope (including mixed-scope) → stays in the queue for the
+     human pass via `lisa-qa-queue`.
+4. For each eligible ticket, in this order — the pairing must be failure-safe:
+   1. Post the audit comment first:
+      `[lisa-qa-clear] Certified without human QA: scope is <repo(s)>, not observable
+      with end-user access. Verified by the automated lifecycle pre-promotion.`
+   2. Then transition to the certified status.
+   3. Verify both halves landed before counting the ticket as moved. A comment without
+      the transition, or a transition without the comment, is a **partial** — report it
+      as such, never as completed.
+5. Report the batch:
+
+```text
+## QA Clear — <date>
+Moved to <certified>: <n> (<KEY-1>, <KEY-2>, …) — repo per ticket
+Left in queue (user-facing): <n>
+Left in queue (undeterminable repo — needs operator): <keys or none>
+```
+
+The operator (or tester) reviews the moved list; anything that "sounds user-facing" can
+be pulled back with a single instruction — the transition is reversible and the comment
+marks exactly what was auto-cleared.
+
+## Rules
+
+- Never clear a mixed-scope ticket — partial human-verifiability means human QA.
+- Never bulk-move on an inferred repo list without explicit operator confirmation.
+- Every cleared ticket carries the audit comment; a transition without the comment is a
+  bug in this procedure.
+- Idempotent by repair, not by skip: a ticket is complete only when it has BOTH the
+  `[lisa-qa-clear]` comment AND the certified status. Re-runs finish partials — comment
+  present but not certified → transition it; certified but no comment → post the
+  comment. Only fully-complete tickets are skipped silently.

package/plugins/src/base/skills/lisa-qa-fail/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: lisa-qa-fail
+description: "QA failure front door. Takes a human tester's plain-language failure description, finds the right ticket (the served ticket, or the original via duplicate-discovery when the report arrives untied), writes the structured failure report (repro / expected vs. actual / which acceptance criterion failed), diagnoses the EXPECTATION GAP — why the implementing agent's done-evidence said done when QA says it isn't — applies the qa-fail label that makes lisa-rework-triage detection deterministic, and transitions the ticket back to the build-ready status. QA never words a ticket again; agents never guess what QA meant."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
+---
+
+# QA Fail: $ARGUMENTS
+
+Convert a human failure observation into the exact artifact the fixing agent needs. Two
+inputs arrive together or the report cannot be filed: a **target ticket** and the
+**tester's verbatim description** (what they did, what they expected, what happened,
+plus any screenshots).
+
+## Phase 1 — Resolve the target ticket
+
+- **Tied report** (invoked from `lisa-qa-queue` with a key): use it.
+- **Untied report** ("I found something broken: …"): run duplicate-discovery BEFORE any
+  write, reusing the mandatory relationship-discovery searches defined by the configured
+  tracker's write skill (dispatched through `lisa-tracker-write`): search open and
+  recently-closed tickets in the affected area, and the current QA-queue set. If an existing ticket
+  covers it, that ticket is the target — update it, never file a twin. Only when the
+  search documents no match, create a new Bug via `lisa-tracker-write` (which enforces
+  the full quality gates) and treat it as the target. Report which path was taken.
+
+## Phase 2 — Structured failure report
+
+Fetch the bundle via `lisa-tracker-read`. Post one comment:
+
+```text
+[lisa-qa-fail] QA failure — <one-line summary>
+Reported by: <tester> on <date>, against <environment>
+Steps to reproduce: <numbered, from the tester's words>
+Expected: <what the ticket/AC promised, quoted or paraphrased faithfully>
+Actual: <what the tester observed, verbatim where possible>
+Failed acceptance criterion: <AC number/text from the ticket — or "not covered by any AC" (see gap)>
+Attachments: <screenshots if provided>
+```
+
+Preserve the tester's language in `Actual` — their words are the evidence; your job is
+structure, not rewording.
+
+## Phase 3 — Expectation-gap diagnosis
+
+Answer explicitly: **why did the implementing agent believe this was done?** Locate the
+prior cycle's done-evidence — the build-evidence comment (`lisa-tracker-evidence` output),
+the merged PR's verification section, and any codified regression test — and compare it
+against the failure. Classify the gap (exactly one):
+
+| Gap | Meaning |
+|-----|---------|
+| `ac-mismatch` | The evidence verified a different reading of the AC than QA's — the criterion is ambiguous or the ticket distorted it. |
+| `verification-weakness` | The evidence never actually exercised the failing path (asserted adjacent behavior, mocked the surface, or skipped the step). |
+| `environment-difference` | Verified where it works (e.g. dev) but fails on the QA environment — config, data, or deployment drift. |
+| `data-difference` | Behavior depends on data present in one environment and absent in the other. |
+| `regression-since-merge` | The evidence was genuinely valid when produced; later merges broke it. |
+| `not-covered-by-ac` | QA's expectation is real but no AC promises it — a spec gap, not an implementation failure. |
+
+Append to the same comment:
+
+```text
+Expectation gap: <classification>
+Why the agent thought it was done: <2-3 lines citing the specific evidence artifact>
+```
+
+If no done-evidence exists at all, say so — `Expectation gap: no-evidence-found` is
+itself a serious finding (the verification lifecycle was skipped) and must be surfaced,
+not smoothed over.
+
+For `not-covered-by-ac`, do NOT transition the ticket — the spec question goes to the
+human product gate. Flag it in the response and stop after posting.
+
+## Phase 4 — Label and transition
+
+1. Apply the `qa-fail` label — this is the deterministic rework signal `lisa-rework-triage`
+   keys on at next claim, and the gap classification above becomes its primary evidence.
+2. Transition the ticket to the build-ready status (`jira.workflow.ready`, or the
+   configured tracker's equivalent ready label/state when `tracker` is GitHub or
+   Linear). The rework loop takes it from here: intake claims it, `lisa-ticket-triage` Phase 2.5 runs
+   `lisa-rework-triage`, and the fix proceeds with full context.
+3. Confirm to the tester in one plain sentence: what was recorded, and that the fix is
+   queued — no further action needed from them.
+
+## Rules
+
+- Never file a new ticket without the documented duplicate search (Phase 1).
+- Never paraphrase away the tester's observation; structure around it.
+- One `[lisa-qa-fail]` comment per failure event — if the same tester reports the same
+  failure again before a fix ships, add a short "seen again <date>" line to the existing
+  comment instead of a new block.
+- The expectation gap must cite a specific evidence artifact or say `no-evidence-found` —
+  a gap classification without a citation is a guess, and guesses are worse than
+  `no-evidence-found`.

package/plugins/src/base/skills/lisa-qa-queue/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: lisa-qa-queue
+description: "QA acceptance queue for human testers. Serves the next ticket awaiting QA verdict from the configured QA queue status as a plain-language acceptance brief — what the ticket promises, how to exercise it on the QA environment, in words a non-technical tester can follow. On 'pass', transitions the ticket to the configured certified status. On 'fail', delegates to lisa-qa-fail for the structured failure report, expectation-gap diagnosis, and return to the build-ready status. The conversational front door for human QA acceptance on any coding agent: testers say 'what's the next item?' / 'pass' / 'fail — here's what I saw'."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
+---
+
+# QA Queue: $ARGUMENTS
+
+Serve one ticket at a time to a human QA tester and record their verdict. The tester is
+assumed **non-technical**: everything you present must be readable by an intern on their
+first day — no stack traces, no jargon, no internal identifiers without explanation.
+
+## Config resolution
+
+Read `.lisa.config.json`:
+
+- **QA queue status** — `jira.workflow.qa.queue`, falling back to `jira.workflow.done.staging`
+  (whatever status the project uses for "deployed to the environment QA tests against").
+  If neither exists, stop and report the missing config.
+- **Certified status** — `jira.workflow.qa.certified` (the project's "passed QA, ships
+  with the next release" status). Required for the pass path; if missing, stop and
+  instruct the operator to add it — never guess a terminal status.
+- **Build-ready status** — `jira.workflow.ready` (fail path, via `lisa-qa-fail`).
+- **Tracker dispatch** — as everywhere: `tracker` decides JIRA / GitHub / Linear surfaces;
+  status names above map to labels/states on non-JIRA trackers.
+
+## Serving the next item
+
+1. Query the QA queue: tickets in the queue status, oldest first, excluding tickets
+   already carrying an unresolved `[lisa-qa-fail]` verdict from this sweep. Skip tickets
+   whose repo is listed in `qa.nonUserFacingRepos` — those belong to `lisa-qa-clear`,
+   not a human tester; note any encountered so the operator knows to run the clear.
+2. Fetch the full context bundle via `lisa-tracker-read` (never serve from a bare summary).
+3. Present ONE ticket as an **acceptance brief**:
+   - **What changed, in user terms** — one or two sentences, translated from the ticket's
+     stakeholder section.
+   - **How to try it** — concrete steps on the QA environment (the `exploration` /
+     Validation Journey config supplies the URL and test credentials): where to go, what
+     to click or type, which account to use.
+   - **What success looks like** — each acceptance criterion rewritten as an observable
+     check ("you should see …"), numbered so the tester can cite one on failure.
+   - **Worth poking at** — up to three edge probes drawn from the ticket's edge-case
+     triage findings, phrased as actions ("try it with an empty search box").
+4. End with: "Say **pass**, or describe what you saw if it failed."
+
+## Recording the verdict
+
+- **Pass** — transition the ticket to the certified status via the tracker access layer,
+  post a brief `[lisa-qa-queue] QA pass` comment naming who verified and when, and offer
+  the next item.
+- **Fail** — invoke `lisa-qa-fail` with the ticket key and the tester's own words
+  (verbatim — do not paraphrase away detail; attach any screenshots they provided). That
+  skill owns the failure report, the expectation-gap diagnosis, the `qa-fail` label, and
+  the transition back to build-ready. When it completes, confirm to the tester in one
+  plain sentence what was recorded and offer the next item.
+- **Unclear / can't test** — if the tester cannot exercise the ticket (missing access,
+  feature flag off, no test data), do NOT guess a verdict. Post a
+  `[lisa-qa-queue] QA blocked: <reason>` comment, leave the status untouched, flag it in
+  the session summary for the operator, and serve the next item.
+
+## Rules
+
+- One ticket at a time — never dump the queue on the tester.
+- The tester's verbatim description is evidence; preserve it exactly in whatever is posted.
+- Never transition to certified without an explicit "pass" from the tester.
+- All tracker writes go through the access layer / `lisa-qa-fail` — this skill never
+  hand-crafts tracker mutations beyond the pass transition and its comment.
+- Session summary on request ("how did we do?"): counts of passed / failed / blocked /
+  remaining in queue.

package/plugins/src/base/skills/lisa-rework-triage/SKILL.md

@@ -24,9 +24,9 @@ If none confirm, output `## Verdict: NOT_REWORK` and stop — this skill takes n
 first-attempt work.
 
 1. **Status history shows a post-implementation regression transition.** The ticket's
-   changelog contains a transition from a post-build state (the configured `claimed`, any
-   `done.*` environment state — e.g. `On Dev`, `On Stg` — or a review state) back to the
-   configured `ready` state.
+   changelog contains a transition from a post-build state (the configured `claimed`,
+   any configured `done.*` environment state, or a review state) back to the configured
+   `ready` state.
    - JIRA: fetch the changelog via the `lisa-atlassian-access` REST substrate —
      `GET /rest/api/3/issue/<KEY>/changelog` — and scan `items[].field == "status"` entries.
    - GitHub: `gh issue view <n> --json timelineItems` (or the timeline API) — scan for the