@codyswann/lisa 2.231.0 → 2.233.0

package/plugins/lisa-copilot/skills/lisa-ticket-triage/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-ticket-triage
-description: "Analytical triage gate for tickets in the configured destination tracker (JIRA, GitHub Issues, or Linear). Detects requirement ambiguities, identifies edge cases from codebase analysis, and plans verification methodology. Posts findings to the ticket and produces a verdict (DUPLICATE_ALREADY_FIXED/BLOCKED/PASSED_WITH_FINDINGS/PASSED) that gates whether implementation can proceed. Vendor-neutral: the caller (jira-agent or github-agent) is responsible for fetching the ticket via lisa-tracker-read, running the pre-flight gate via lisa-tracker-verify, and posting findings via the matching vendor comment tool."
+description: "Analytical triage gate for tickets in the configured destination tracker (JIRA, GitHub Issues, or Linear). Detects requirement ambiguities, identifies edge cases from codebase analysis, plans verification methodology, and — via lisa-rework-triage in Phase 2.5 — detects rework bounced back from QA/staging and classifies why the previous agent attempt failed. Posts findings to the ticket and produces a verdict (DUPLICATE_ALREADY_FIXED/BLOCKED/PASSED_WITH_FINDINGS/PASSED) that gates whether implementation can proceed. Vendor-neutral: the caller (jira-agent or github-agent) is responsible for fetching the ticket via lisa-tracker-read, running the pre-flight gate via lisa-tracker-verify, and posting findings via the matching vendor comment tool."
 allowed-tools: ["Read", "Glob", "Grep", "Bash"]
 ---
 
@@ -67,6 +67,23 @@ Note which phases other repos have already covered and what findings they posted
 - Do NOT duplicate findings already posted by another repo
 - DO add supplementary findings specific to THIS repo's codebase
 
+## Phase 2.5 -- Rework Detection & Failure Classification
+
+Invoke `lisa-rework-triage` with the context bundle. It detects whether this ticket is
+**rework** — previously implemented work bounced back from QA/staging — and, when it is,
+classifies why the previous agent attempt failed (decomposition infidelity, PRD defect,
+missing tool access, implementation defect, environment/data, verification gap), posts the
+`[lisa-rework-triage]` comment, and routes the cause to its hardening destination (upstream
+Lisa issue, provisioning ticket, or PRD defect flag). See that skill for the taxonomy,
+evidence requirements, and routing table.
+
+- `NOT_REWORK` → proceed to Phase 3; nothing to carry forward.
+- `REWORK_CLASSIFIED` / `ALREADY_TRIAGED` → carry the classification into the output
+  structure (see below) and proceed to Phase 3 — a classified rework still gets fixed;
+  hardening runs alongside the fix, never in front of it. Exception: a `missing-tool-access`
+  cause whose gap is **still present** must be raised as a Phase 3 ambiguity ("prior attempt
+  lacked <tool>; it is still unavailable"), which blocks per the normal rules.
+
 ## Phase 3 -- Ambiguity Detection
 
 Examine the ticket summary, description, and acceptance criteria. Look for:
@@ -175,6 +192,9 @@ Structure all output with clear section headers so the caller can parse and post
 ### Verification Methodology
 [Phase 5 table, or "No acceptance criteria to verify."]
 
+### Rework Classification
+[Phase 2.5 verdict block from lisa-rework-triage, or "Not rework (first attempt)."]
+
 ## Verdict: [NOT_RELEVANT | DUPLICATE_ALREADY_FIXED | BLOCKED | PASSED_WITH_FINDINGS | PASSED]
 ```
 

package/plugins/lisa-cursor/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.231.0",
+  "version": "2.233.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cursor/agents/learner.md

@@ -21,19 +21,26 @@ Invoke `skill-evaluator` (via Agent tool with `subagent_type: "skill-evaluator"`
 
 - **CREATE SKILL** -- broad, reusable, complex, stable, not redundant. Invoke `/skill-creator`.
 - **ADD TO RULES** -- simple rule to append to `.claude/rules/PROJECT_RULES.md`.
+- **UPSTREAM** -- the learning is a harness defect, not project knowledge: a Lisa skill, gate,
+  agent, or hook mis-behaved or should have caught something and didn't. Project rules can't
+  fix the harness; file it upstream so every host project gets the fix.
 - **OMIT** -- too narrow, already documented, or temporary. Discard.
 
 ### Step 3: Act on Decisions
 
 - CREATE SKILL: invoke `/skill-creator` via the Skill tool
 - ADD TO RULES: use Edit to append to `.claude/rules/PROJECT_RULES.md`
+- UPSTREAM: file an upstream Lisa issue per the "Filing upstream" procedure in
+  `lisa-rework-triage` (dedupe search first, three-audience description, evidence chain,
+  `self-hardening` label; repo from `.lisa.config.json` `hardening.upstreamRepo`, default
+  `CodySwannGT/lisa`)
 - OMIT: no action
 
 ### Step 4: Output Summary
 
 | Learning | Decision | Action Taken |
 |----------|----------|-------------|
-| [learning text] | CREATE SKILL / ADD TO RULES / OMIT | [what was done] |
+| [learning text] | CREATE SKILL / ADD TO RULES / UPSTREAM / OMIT | [what was done] |
 
 ## Rules
 

package/plugins/lisa-cursor/agents/learnings-synthesizer.md

@@ -1,6 +1,6 @@
 ---
 name: learnings-synthesizer
-description: "Learnings synthesizer for the Debrief flow. Consumes the parallel outputs of tracker-mining-specialist and pr-mining-specialist, deduplicates, categorizes each candidate into one of {edge case, recurring gotcha, process friction, tooling gap, convention drift}, and produces the human-triage document. Exhaustive — surfaces every candidate, even low-confidence ones, because the human decides what to keep."
+description: "Learnings synthesizer for the Debrief flow. Consumes the parallel outputs of tracker-mining-specialist and pr-mining-specialist, deduplicates, categorizes each candidate into one of {edge case, recurring gotcha, process friction, tooling gap, convention drift, decomposition infidelity, prd defect, missing tool access}, and produces the human-triage document. Exhaustive — surfaces every candidate, even low-confidence ones, because the human decides what to keep."
 skills: []
 ---
 
@@ -38,6 +38,9 @@ Map every finding to exactly one category. When a finding could fit two, pick th
 | **Process friction** | A step in the lifecycle that consistently slowed the work — long status stalls, repeated reopen cycles, force-pushes after approval, missing journey replays, ambiguous AC that required mid-PR clarification. | `PROJECT_RULES.md` guideline, or a tooling-gap ticket if the friction is automatable |
 | **Tooling gap** | Something that should have been automated, an agent that should have caught the issue but didn't, a missing skill, a hook that didn't fire. | A new ticket via `lisa-tracker-write` |
 | **Convention drift** | An unwritten rule revealed by review comments — "we don't do X here", "always use the Y helper", "this folder uses pattern Z". The convention is real but undocumented. | `CLAUDE.md` or `PROJECT_RULES.md` |
+| **Decomposition infidelity** | A ticket misrepresented the PRD requirement it claimed to implement — the agent built what the ticket said, but the ticket distorted the spec, and every gate passed it. A harness defect, not a project one. (`lisa-rework-triage` classifies these at claim time; debrief catches the ones that slipped through a whole initiative.) | Upstream Lisa issue (`hardening.upstreamRepo`, default `CodySwannGT/lisa`) |
+| **PRD defect** | The ticket faithfully captured the PRD, but the PRD itself was wrong, ambiguous, or missing the failing case. A spec problem, not an agent problem. | Comment on the source PRD via `lisa-prd-backlink` lineage; flag for product review — never silently edit the spec |
+| **Missing tool access** | An agent lacked a tool, credential, environment, or permission the work required, and the failure traces to that gap rather than to the code. | Provisioning ticket via `lisa-tracker-write` (`type:tooling`) |
 
 A finding that does not fit any category is itself a signal — surface it under a sixth ad-hoc category `Uncategorized` with a note explaining why no category fit. Better to surface than to drop.
 

package/plugins/lisa-cursor/commands/lisa/qa-checklist.md

@@ -0,0 +1,6 @@
+---
+description: "Serve the current manual regression checklist: curated journeys minus live automated E2E coverage, in plain language."
+argument-hint: ""
+---
+
+Use the /lisa-qa-checklist skill to serve the manual regression checklist. $ARGUMENTS

package/plugins/lisa-cursor/commands/lisa/qa-clear.md

@@ -0,0 +1,6 @@
+---
+description: "Bulk-move QA-queue tickets scoped entirely to non-user-facing repos to the configured certified status, with an auditable moved-list report."
+argument-hint: ""
+---
+
+Use the /lisa-qa-clear skill to clear non-human-verifiable tickets from the QA queue. $ARGUMENTS

package/plugins/lisa-cursor/commands/lisa/qa-fail.md

@@ -0,0 +1,6 @@
+---
+description: "File a QA failure: find the right ticket (never a duplicate), write the structured failure report, diagnose the expectation gap, label qa-fail, and return the ticket to build-ready."
+argument-hint: "[ticket-key] <what you saw, in your own words>"
+---
+
+Use the /lisa-qa-fail skill to file this QA failure. $ARGUMENTS

package/plugins/lisa-cursor/commands/lisa/qa-queue.md

@@ -0,0 +1,6 @@
+---
+description: "Serve the next ticket awaiting QA verdict as a plain-language acceptance brief; record pass (→ certified) or fail (→ structured report via lisa-qa-fail)."
+argument-hint: "[pass | fail <description> | next]"
+---
+
+Use the /lisa-qa-queue skill to serve the QA acceptance queue. $ARGUMENTS

package/plugins/lisa-cursor/commands/lisa/rework-triage.md

@@ -0,0 +1,6 @@
+---
+description: "Detect whether a ticket is rework bounced back from QA/staging, classify why the previous agent attempt failed, and route the cause to its hardening destination (upstream Lisa issue, provisioning ticket, or PRD defect flag)."
+argument-hint: "<ticket-key-or-url>"
+---
+
+Use the /lisa-rework-triage skill to detect and classify rework on the given ticket. $ARGUMENTS

package/plugins/lisa-cursor/skills/lisa-debrief-apply/SKILL.md

@@ -29,8 +29,11 @@ For every row marked **Accept**:
 | Edge case | Edge Case Brainstorm checklist in `intent-routing.md` | Append the new pattern + question to the matching group (Navigation, Data, Failure, Input, Auth, or a new group if none fit). Use the row's `Summary` and `Evidence` link as a citation comment. |
 | Recurring gotcha | Memory file (`project_*.md`) | Write a new memory entry with `type: project`, structured as: rule, **Why:**, **How to apply:**. Add an index line to `MEMORY.md`. |
 | Process friction | Configured project rules file | Append a one-line guideline to the `.lisa.config.json` `projectRulesFile` destination (default `PROJECT_RULES.md`) under an appropriate heading (or create one). |
-| Tooling gap | Configured tracker | Create a new ticket via `lisa-tracker-write` with `issue_type: Task`, summary derived from the row's `Summary`, description citing the evidence and the originating debrief doc. Label appropriately (`type:tooling`, `lifecycle-improvement`, etc.). |
+| Tooling gap | Configured tracker — or upstream Lisa when harness-level | **Split by level.** Project-level (a missing project script, hook, or automation) → create a ticket via `lisa-tracker-write` with `issue_type: Task`, summary derived from the row's `Summary`, description citing the evidence and the originating debrief doc, labeled `type:tooling` / `lifecycle-improvement`. Harness-level (a Lisa skill/gate/agent that should have caught the issue but didn't) → file an upstream Lisa issue exactly per the "Filing upstream" procedure in `lisa-rework-triage` (dedupe search first, three-audience description, evidence chain, `self-hardening` label; repo from `.lisa.config.json` `hardening.upstreamRepo`, default `CodySwannGT/lisa`). |
 | Convention drift | `CLAUDE.md` for project-wide agent operating instructions; otherwise the configured project rules file for codebase conventions | Append the convention as a one-paragraph note under the relevant section. If no relevant section exists, create one. |
+| Decomposition infidelity | Upstream Lisa repo | File an upstream Lisa issue per the "Filing upstream" procedure in `lisa-rework-triage`, citing the PRD text vs. the distorted ticket AC and naming the gate that passed it. |
+| PRD defect | Source PRD | Comment on the PRD via the `lisa-prd-backlink` lineage quoting the defective requirement and the failure it missed; flag for product review. Never silently edit the spec. |
+| Missing tool access | Configured tracker | Create a provisioning ticket via `lisa-tracker-write` (`issue_type: Task`, `type:tooling`) describing the missing tool/credential/environment and which flow needs it. |
 
 For every row marked **Reject** or **Defer**: no action. Defer is a no-op for `apply` but worth surfacing in the run summary — the human may want to revisit at the next debrief.
 
@@ -51,8 +54,12 @@ Applied <n> learnings:
   <n> edge cases → intent-routing.md
   <n> gotchas → memory
   <n> friction → PROJECT_RULES.md
-  <n> tooling gaps → <tracker> (<key1>, <key2>, ...)
+  <n> tooling gaps (project) → <tracker> (<key1>, <key2>, ...)
+  <n> tooling gaps (harness) → upstream Lisa (<issue-url1>, ...)
   <n> convention drift → CLAUDE.md
+  <n> decomposition infidelity → upstream Lisa (<issue-url1>, ...)
+  <n> PRD defects → PRD comments (<prd-link1>, ...)
+  <n> missing tool access → <tracker> (<key1>, ...)
 Skipped:
   <n> rejected, <n> deferred, <n> already-applied
 Failed:

package/plugins/lisa-cursor/skills/lisa-qa-checklist/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: lisa-qa-checklist
+description: "Serve the current manual regression checklist to a human QA tester. Reads the project's curated journey list, cross-references it against what the automated suites (Playwright web E2E, Maestro native E2E) actually cover by scanning the spec files, and serves only the journeys that still need human eyes — each as plain-language steps. Keeps a single source of truth so testers never work from a stale personal copy, and shrinks automatically as automated coverage grows."
+allowed-tools: ["Bash", "Read", "Glob", "Grep", "Write", "Edit"]
+---
+
+# QA Checklist: $ARGUMENTS
+
+The manual regression sweep exists to catch what automation does not. Its checklist must
+therefore be computed, not remembered: curated journeys minus automated coverage, at the
+moment the tester asks.
+
+## Sources
+
+1. **Curated journey list** — `qa.checklistFile` in `.lisa.config.json`, default
+   `.lisa/qa-checklist.md`. Format: one `## Journey: <name>` section per user journey,
+   with plain-language steps and an optional `automation:` line naming the covering spec
+   file(s) once one exists. If the file does not exist, offer to bootstrap it: derive
+   candidate journeys from the app's route map and the existing E2E suites' describe
+   blocks, write the draft, and ask the operator to curate it once. Never invent
+   journeys silently.
+2. **Automated coverage** — scan the repo's E2E suites (Playwright specs, Maestro flows;
+   locate via the project's e2e/test directories). An `automation:` line must name BOTH
+   the spec file and the specific test within it (the Playwright `describe`/`test` title
+   or Maestro flow name): `automation: <spec-path> :: <test-or-flow-name>`. A journey
+   counts as covered only when that spec file exists, the named test/flow is present in
+   it, and it is not skipped (`test.skip`, commented-out flow, or excluded from CI). A
+   file-only line, a named test that no longer matches, or any ambiguous mapping is
+   treated as **uncovered** — a live filename proves nothing about what the spec
+   exercises. A deleted, renamed, or skipped test silently un-covers its journey — the
+   very regression this check exists to catch; call it out loudly.
+
+## Serving the sweep
+
+Present two lists, human-first:
+
+```text
+## Manual sweep — <n> journeys need your eyes
+1. <Journey name> — <plain-language steps>
+   Why manual: <no automation | automation skipped/stale: <spec>>
+...
+
+## Covered by automation — <n> journeys (skim, don't re-test)
+- <Journey name> — <spec file> (<playwright|maestro>)
+```
+
+Rules for the served text: steps an intern can follow, no spec-file jargon in the manual
+section beyond the "why manual" line, and stable journey ordering (file order) so testers
+can resume mid-sweep.
+
+## Maintaining the list
+
+- Tester or operator adds/edits journeys in plain language → edit the checklist file
+  (this skill may apply the edit on request; it is a repo file, so changes ride normal
+  review).
+- When a journey gains automation (e.g. `lisa-codify-verification` lands a spec), add its
+  `automation: <spec-path> :: <test-or-flow-name>` line — on request this skill locates
+  the covering spec and test, confirms the named test actually drives the journey's
+  steps, and writes the line itself.
+- Never maintain per-tester copies; the file is the single source of truth and the
+  computed view is always derived fresh.
+
+## Rules
+
+- Coverage claims must point at an existing, non-skipped spec — "there's a test somewhere"
+  does not count.
+- Serving is read-only by default; file edits happen only on explicit request.
+- If the automated-coverage scan finds specs exercising a journey that is missing from
+  the curated list entirely, surface it as a suggested addition — the human curates, the
+  skill proposes.

package/plugins/lisa-cursor/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/lisa-cursor/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/lisa-cursor/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/lisa-cursor/skills/lisa-rework-triage/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: lisa-rework-triage
+description: "Rework detection and agent-failure classification. When a claimed ticket turns out to be rework — previously implemented work bounced back from QA/staging — this skill detects it, classifies WHY the previous agent attempt failed (decomposition infidelity, PRD defect, missing tool access, implementation defect, environment/data, verification gap), posts a structured triage comment, and routes each cause to its hardening destination — including upstream Lisa issues so the harness itself gets fixed and the same mistake structurally cannot repeat. Vendor-neutral: consumes the lisa-tracker-read context bundle; invoked automatically by lisa-ticket-triage Phase 2.5 and runnable standalone."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
+---
+
+# Rework Triage: $ARGUMENTS
+
+Classify why a previous agent attempt at this ticket failed, and convert that cause into a
+structural improvement. This is the self-hardening arm of the lifecycle: every classified
+failure either hardens the harness (an upstream Lisa issue), the project (a provisioning or
+environment ticket), or the spec (a PRD defect flag). A rework cycle that fixes the bug but
+never asks *why the agent got it wrong* guarantees the mistake recurs.
+
+The caller MUST have run `lisa-tracker-read` first and provided the context bundle (all
+comments chronological, linked PRs with review state, issue links, parent epic). Do not
+classify from a bare summary — evidence-free classification is worse than none.
+
+## Phase 1 — Rework detection
+
+A ticket is **rework** when it was previously implemented by this lifecycle and has returned
+to a build-ready state. Evaluate these signals in order; the first confirmed signal suffices.
+If none confirm, output `## Verdict: NOT_REWORK` and stop — this skill takes no action on
+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 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
+     `$DONE`/environment label being removed and `$READY` re-added after a linked PR merged.
+   - Linear: the Issue history relation — scan state changes from a completed/started state
+     back to the ready-labeled state.
+2. **Merged linked PR + build-ready again.** The bundle shows at least one linked PR that is
+   `MERGED`, while the ticket currently carries the build-ready role. First-attempt tickets
+   never have merged PRs.
+3. **Prior lifecycle claim marker.** The comments contain a prior implementation-cycle
+   marker for THIS ticket: a `[claude-build-intake]` claim comment, or a build-evidence
+   comment posted by `lisa-tracker-evidence` (`[lisa-evidence]` / the vendor evidence
+   header). Only markers proving a prior *implementation* attempt qualify —
+   `[lisa-rework-triage]` comments and other unrelated `[lisa-*]` annotations never do.
+4. **Explicit rework marker.** A `rework`, `qa-fail`, or `regression` label applied by QA or
+   the verify lifecycle.
+
+Record which signal fired — it is part of the evidence trail.
+
+## Phase 2 — Failure-cause classification
+
+Classify the failed attempt into **exactly one primary cause**. Every classification must
+cite concrete evidence from the bundle, the codebase, or the PRD lineage — a cause without
+evidence is `UNCLASSIFIED`, which is itself a surfaced outcome, never a silent default.
+
+| Cause | Definition | Required evidence |
+|-------|------------|-------------------|
+| `decomposition-infidelity` | The ticket misrepresents the PRD requirement it implements — the agent built what the ticket said, but the ticket distorted the spec. | Resolve the ticket's requirement id(s) from the source PRD's `## Tickets` section (written by `lisa-prd-backlink` — each entry carries `requirements: ["R#"]` and the register maps R# to verbatim PRD text). Quote the PRD text vs. the ticket's AC and name the divergence. |
+| `prd-defect` | The ticket faithfully captured the PRD, but the PRD itself was wrong, ambiguous, or missing the failing case. | Quote the PRD requirement and the QA failure it does not cover or contradicts. |
+| `missing-tool-access` | The agent lacked a tool, credential, environment, or permission the work required, and worked around it blindly. | The prior cycle's comments/PR show the gap (skipped verification step, "could not access", missing env credentials, absent MCP tool) — cite the marker. |
+| `implementation-defect` | Spec and ticket were right; the agent's code was wrong. | The failing behavior contradicts an AC the ticket states correctly; cite the AC and the failure report. |
+| `environment-data` | The failure is caused by environment or data state (drift, missing fixtures, shared-state collision), not by the code under test. | The failure reproduces only in the affected environment, or the report references data absent from the environment's seed/fixtures. |
+| `verification-gap` | The code was wrong AND the verification lifecycle should have caught it — the codified regression test was missing, too weak, or asserted the wrong thing. | Name the verification/codify-verification artifact from the prior cycle that failed to catch this class of failure. Frequently a **secondary** cause alongside `implementation-defect`; record both, primary first. |
+
+Classification sources, in priority order: the QA failure report (comments), the prior
+cycle's evidence comment and PR review thread, the PRD requirement register via
+`lisa-prd-backlink` lineage, and the codebase itself (Glob/Grep the failing surface).
+
+## Phase 3 — Post the triage comment
+
+Post one structured comment on the ticket via the vendor comment surface (`lisa-atlassian-access
+operation: comment`, `gh issue comment`, or the Linear comment mutation):
+
+```text
+[lisa-rework-triage] Rework detected (signal: <signal>)
+Fingerprint: <ticket-key>|<last merged PR number, or none>|<primary cause>
+Primary cause: <cause>
+Secondary cause: <cause or none>
+Evidence: <2-4 lines citing the specific PRD text / AC / comment / PR review / environment fact>
+Hardening action: <what Phase 4 filed, with link — or "none required (implementation-defect)">
+```
+
+**Idempotency:** the fingerprint is the literal `Fingerprint:` line —
+`<ticket-key>|<last merged PR number>|<primary cause>`, with `none` as the PR component
+when detection fired on a claim marker or label and no merged PR exists. Before posting,
+scan existing comments for a `[lisa-rework-triage]` block whose `Fingerprint:` line
+matches — if present, skip posting and report `already-triaged`. One triage per bounce,
+never one per cycle re-entry.
+
+## Phase 4 — Route the cause to its hardening destination
+
+Each cause has exactly one destination. File through the proper write path — never raw
+ticket creation — so every hardening artifact passes the same quality gates as any other
+Lisa work item.
+
+| Primary cause | Destination | Action |
+|---------------|-------------|--------|
+| `decomposition-infidelity` | **Upstream Lisa issue** | The decomposition pipeline produced an unfaithful ticket and every gate passed it — that is a harness defect. File per "Filing upstream" below, citing the PRD text, the distorted ticket AC, and which gate should have caught it. |
+| `verification-gap` | **Upstream Lisa issue** | The verification lifecycle passed work it should have failed. File per "Filing upstream", citing the missed failure class and the weak/missing codified test. |
+| `missing-tool-access` | Project tracker | Create a provisioning ticket via `lisa-tracker-write` (`issue_type: Task`, labeled `type:tooling`) describing the missing tool/credential/environment and which flow needs it. Link it `blocks` the rework ticket. |
+| `environment-data` | Project tracker | Create an environment-hardening ticket via `lisa-tracker-write` citing the drift/fixture/shared-state evidence. Link `relates to` the rework ticket. |
+| `prd-defect` | Source PRD | Comment on the PRD (via the `lisa-prd-backlink` lineage) quoting the defective requirement and the QA failure; flag for product review. Do NOT silently edit the PRD — spec changes are a human gate. |
+| `implementation-defect` (no secondary) | None | Normal fix path; the classification comment is the record. Pass the pattern to the `learner` phase — repeated implementation defects of the same shape escalate to `verification-gap`. |
+
+**Secondary causes route too.** A recorded secondary cause triggers its own row's
+destination in addition to the primary's: `implementation-defect` with a
+`verification-gap` secondary files the upstream Lisa issue per the `verification-gap`
+row — the code being wrong does not excuse the verification lifecycle for passing it.
+Deduplicate against the primary's filing (one upstream issue per failure class, not one
+per cause slot).
+| `UNCLASSIFIED` | Surface to human | Include in the triage comment and the caller's summary; a human decides. Never guess a cause to avoid this outcome. |
+
+### Filing upstream
+
+Upstream issues target the Lisa repository itself so the harness gets fixed for every
+project at once. Resolve the repo from `.lisa.config.json` `hardening.upstreamRepo`;
+default `CodySwannGT/lisa`.
+
+1. **Dedupe first.** `gh issue list -R <upstream> --state open --search "<fingerprint terms>"`
+   — if an open issue already covers this failure class, comment the new occurrence on it
+   (evidence compounds; duplicates dilute) and link it instead of filing.
+2. **File with the same bar as any ticket:** a three-audience description (what failed for
+   the operator, what the harness did wrong, what to change), the verbatim evidence chain
+   (PRD text → ticket AC → QA failure → gate that passed it), and a `self-hardening` label:
+   `gh issue create -R <upstream> --title "<gate/skill>: <failure class>" --label self-hardening`.
+3. **Close the loop.** Reference the upstream issue URL in the triage comment. The upstream
+   repo's own build intake implements it; the next kernel release ships the hardening to
+   every host project.
+
+## Verdict
+
+```text
+## Verdict: [NOT_REWORK | REWORK_CLASSIFIED | ALREADY_TRIAGED]
+
+**Signal:** [status-history | merged-pr | claim-marker | label | n/a]
+**Primary cause:** [cause | n/a]
+**Secondary cause:** [cause | none]
+**Hardening filed:** [upstream <url> | tracker <key> | prd-comment | none | pending-human]
+```
+
+The caller (ticket-triage Phase 2.5, or a standalone invocation) incorporates this into its
+own findings. `REWORK_CLASSIFIED` never blocks the fix — the rework ticket proceeds to
+implementation regardless; hardening runs alongside, not in front of, shipping the fix. The
+one exception: `missing-tool-access` with the gap still present should surface as a Phase 3
+ambiguity in the calling triage ("prior attempt lacked <tool>; it is still unavailable"),
+which blocks per the normal triage rules.
+
+## Rules
+
+- Never classify without evidence; `UNCLASSIFIED` beats a guess.
+- One primary cause. Record a secondary only when the evidence genuinely supports both.
+- Fire only on confirmed rework — first-attempt tickets exit at Phase 1 with `NOT_REWORK`.
+- All ticket/issue writes go through `lisa-tracker-write` or `gh` as specified — never
+  bypass the quality gates this loop exists to strengthen.
+- Noise discipline: one triage comment per bounce (fingerprinted), no upstream issue without
+  the dedupe search, and upstream issues describe failure *classes*, not single incidents.