@codyswann/lisa 2.231.0 → 2.233.0

package/package.json

@@ -102,7 +102,7 @@
     "form-data": ">=4.0.6"
   },
   "name": "@codyswann/lisa",
-  "version": "2.231.0",
+  "version": "2.233.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

package/plugins/lisa/.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/.codex-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/.codex-plugin/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/.codex-plugin/skills/lisa-qa-checklist/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: lisa-qa-checklist
+description: "Serve the current manual…"
+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/.codex-plugin/skills/lisa-qa-checklist/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "QA Checklist"
+short_description: "Serve the current manual…"
+default_prompt:
+  - "Use $lisa-qa-checklist: Serve the current manual…."

package/plugins/lisa/.codex-plugin/skills/lisa-qa-clear/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: lisa-qa-clear
+description: "Bulk-clear tickets a human QA…"
+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/.codex-plugin/skills/lisa-qa-clear/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "QA Clear"
+short_description: "Bulk-clear tickets a human QA…"
+default_prompt:
+  - "Use $lisa-qa-clear: Bulk-clear tickets a human QA…."

package/plugins/lisa/.codex-plugin/skills/lisa-qa-fail/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: lisa-qa-fail
+description: "QA failure front door"
+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/.codex-plugin/skills/lisa-qa-fail/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "QA Fail"
+short_description: "QA failure front door"
+default_prompt:
+  - "Use $lisa-qa-fail: QA failure front door."

package/plugins/lisa/.codex-plugin/skills/lisa-qa-queue/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: lisa-qa-queue
+description: "QA acceptance queue for human…"
+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/.codex-plugin/skills/lisa-qa-queue/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "QA Queue"
+short_description: "QA acceptance queue for human…"
+default_prompt:
+  - "Use $lisa-qa-queue: QA acceptance queue for human…."

package/plugins/lisa/.codex-plugin/skills/lisa-rework-triage/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: lisa-rework-triage
+description: "Rework detection and…"
+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.

package/plugins/lisa/.codex-plugin/skills/lisa-rework-triage/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Rework Triage"
+short_description: "Rework detection and…"
+default_prompt:
+  - "Use $lisa-rework-triage: Rework detection and…."

package/plugins/lisa/.codex-plugin/skills/lisa-ticket-triage/SKILL.md

@@ -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/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/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/commands/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