@codyswann/lisa 2.231.0 → 2.232.0

package/package.json

@@ -102,7 +102,7 @@
     "form-data": ">=4.0.6"
   },
   "name": "@codyswann/lisa",
-  "version": "2.231.0",
+  "version": "2.232.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.232.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.232.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-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
+   `done.*` environment state — e.g. `On Dev`, `On Stg` — 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/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/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/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
+   `done.*` environment state — e.g. `On Dev`, `On Stg` — 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/skills/lisa-rework-triage/agents/openai.yaml

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

package/plugins/lisa/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-agy/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-agy/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-agy/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-agy/plugin.json

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