@codyswann/lisa 2.240.0 → 2.242.0

package/plugins/lisa/rules/reference/claim-archaeology.md

@@ -0,0 +1,142 @@
+# Claim-Time Archaeology
+
+Lisa lifecycles are ONE-WAY — a done issue never reopens, so residual failures come back as NEW issues, and the causal link "issue B exists because issue A was done wrong" is invisible unless someone digs. Reopening terminal issues is out of scope, so claim-time archaeology is the only way to recover that link: at claim time, determine whether the item being claimed is round 2 of a past failure, and if so, what specifically went wrong the first time.
+
+It is a **single vendor-neutral contract** consumed by all three build-intake skills (`lisa-jira-build-intake`, `lisa-github-build-intake`, `lisa-linear-build-intake`). Each vendor arm cites this slug in its claim step rather than growing its own archaeology, exactly as the arms cite `leaf-only-lifecycle`, `repo-scope-split`, and `rejection-detection`. One slug is what keeps an ancestor found on JIRA from being missed on Linear.
+
+## Seam and sequencing — after rejection detection, before the claim transition
+
+The three build-intake skills share a uniform claim phase: `3a.0` repo-scope gate → `3a` leaf-only claim gate → `3b` Claim → `3c` run lifecycle (culminating in `lisa-implement`) → `3d` transition to done.
+
+Within `3b`, the pre-transition window runs two passes in a fixed order:
+
+1. **`rejection-detection` runs first** (top of `3b`, before the relabel — it needs the current-lane signal that the relabel destroys).
+2. **Archaeology runs second** — after the rejection classification exists, still **before the relabel/transition** `$READY → $CLAIMED`.
+
+The ordering is load-bearing: rejection-detection's classification is an **input** to archaeology's. A `rejection-reclaim` detected in pass 1 flows straight into archaeology's classification — it is reused, **not re-derived**. Archaeology never re-reads transition history to second-guess the rejection detector; forking that signal would guarantee drift between the two passes.
+
+**`lisa-implement` is NOT the seam** — it never sees the claim. Archaeology belongs to the build-intake claim phase, like the two gates before it.
+
+## Ancestry signals
+
+Three signal sources, tried in order of cheapness. Every query counts against the cost budget below.
+
+### 1. Tracker metadata (typed relations)
+
+The cheapest and most reliable signal: the relations the vendor read skills already parse. Read them from the context bundle the intake flow already fetched — do not re-fetch:
+
+- The typed relation lines — `Blocks` / `Blocked by` / `Relates to` / `Duplicates` / `Cloned from` — that `lisa-github-read-issue`, `lisa-jira-read-ticket`, and `lisa-linear-read-issue` parse into the relations table of their context bundles.
+- GitHub's native `closingIssuesReferences` (PR↔issue closure links) and timeline cross-references, surfaced by the same `lisa-github-read-issue` GraphQL read. JIRA issue links and Linear native relations (`blocks` / `blocked_by` / `relates_to` / `duplicates`) are the vendor equivalents, read through the access layers (`integration-access-layer`) — never a direct vendor API call.
+
+A relation pointing at a **closed, done** issue whose shipped work plausibly covers this issue's surface is an ancestor candidate. An "introduced by"-shaped link (this issue references the PR or issue that shipped the defect) is the strongest form.
+
+### 2. Text similarity (bounded, lexical)
+
+**The honest bound, stated plainly: no embedding machinery exists in Lisa, and none is introduced here. This signal is lexical overlap over tracker search primitives — not semantic similarity — and it will miss paraphrased descriptions.** That is acceptable: it exists to catch the common case of a new issue describing a defect in something recently shipped, using roughly the words the shipping issue used.
+
+Scope: **recently-closed** issues (closed within the recent window the budget affords, newest first) **touching the same implicated files** where file paths are named or inferable, ranked by **title/label overlap** with the issue being claimed. The primitives:
+
+- **GitHub** — `gh search issues "<key terms>" --repo <org>/<repo> --state closed --sort updated` (and `--label` narrowing where labels overlap).
+- **JIRA** — `lisa-atlassian-access operation: search-issues jql: "project = <P> AND statusCategory = Done AND resolved >= -30d AND text ~ \"<key terms>\" ORDER BY resolved DESC"`.
+- **Linear** — `lisa-linear-access operation: list-issues` filtered to completed state types, matched client-side on title/label overlap.
+
+A hit is a candidate only when the overlap is specific (shared distinctive terms, same component labels, same files named) — generic word overlap alone never promotes an ancestor.
+
+### 3. Git ancestry (deterministic, machine-readable)
+
+For the files the issue implicates (named in the body, or inferred from the similarity hits), answer "which PR last shipped this file" with **direct deterministic git commands**:
+
+```bash
+git log --follow --format='%H %aI %s' -n 5 -- <file>   # last commits touching the file
+git blame -L <range> --line-porcelain <file>            # who last shipped the implicated lines
+# The PR that shipped the file. --full-history is required: path-limited git log
+# simplifies away merge commits by default, silently dropping the merge-PR answer.
+# Two --grep patterns (OR'd) cover both merge conventions: classic merge commits
+# ("Merge pull request #<n>") and squash/rebase merges (subject ending "(#<n>)").
+# POSIX BRE only — GNU-only \+ silently matches nothing on BSD/macOS git.
+git log --full-history --grep "Merge pull request #" --grep "(#[0-9][0-9]*)" --format='%H %aI %s' -n 5 -- <file>
+```
+
+Keep the result **parseable**: a `{file, sha, pr, date}` tuple per implicated file (PR number extracted from the subject — `Merge pull request #<n>` for merge commits, the trailing `(#<n>)` for squash/rebase merges; empty when the history matches neither convention). The PR maps back to its issue via `closingIssuesReferences` / the PR body's issue reference.
+
+**Do NOT delegate this to the `git-history-analyzer` agent.** That agent can answer the question, but it returns a **prose report with no machine-readable contract** (nothing downstream can reliably parse it), it is explicitly forbidden from judging past decisions, and it reads the local repo only. For programmatic claim-time archaeology, run the deterministic query directly and keep the `{file, sha, pr, date}` result.
+
+## Learning-loop exclusion (scan-side — a learning artifact is never an ancestor)
+
+This flow produces learning PRs, candidate comments, and upstream handoffs. Those artifacts touch the same files and reference the same issues as the failures they describe — which makes them **near-perfect false-positive ancestors**. Without an explicit exclusion the flow learns from itself, recursively.
+
+Before any candidate is promoted to ancestor, exclude every artifact carrying any of these markers or labels — such an artifact is **never an ancestor**, no matter how strong its other signals:
+
+- `[lisa-learning-drop]`
+- `[lisa-learning-pr]`
+- `[lisa-learning-upstream-handoff]`
+- `[lisa-rejection-candidate]`
+- `[lisa-archaeology-candidate]` (this rule's own producer tag — archaeology's output must not seed the next claim's input)
+- the `learning:needs-triage` label
+
+This is the **scan-side** half of the no-learning-loops guard; `rejection-detection` carries the symmetric **trigger-side** half ("a learning artifact is never a rejection-reflection trigger").
+
+## Classification
+
+Exactly one of three states:
+
+| Classification | Condition |
+|---|---|
+| `rejection-reclaim` | The `rejection-detection` pass classified this claim `rejection-reclaim`. Taken directly from that result — reused, never re-derived here. Its reflection path (the `[lisa-rejection-candidate]` candidate) already covers the learning; archaeology adds nothing on top. |
+| `retry-of-done-issue` | Not a rejection-reclaim, AND an ancestry signal (§ above, post-exclusion) names a closed done issue whose shipped work this issue exists to fix. |
+| `fresh` | Everything else: no ancestor, weak/inconclusive signals, budget exhausted, or the pass errored. |
+
+Classification itself is **stateless** — a pure function of the signals read this pass, holding no cache or stored state between claims. Re-running it on the same inputs yields the same answer; idempotency of the *side effect* (the candidate) is carried by marker dedupe below.
+
+## Candidate derivation (`retry-of-done-issue` only)
+
+An ancestor alone teaches nothing — "B relates to A" is trivia. The learning lives in the **delta**: the gap between what agent A actually did and what issue B proves was actually needed.
+
+1. **Reconstruct what the ancestor shipped**, through the access layers: its merged PR (diff, description), the review threads on that PR, and the evidence comments on the ancestor issue.
+2. **Derive ONE candidate learning citing the delta** — **what was done** versus **what this issue proves was needed**. The shape is "A shipped X; B proves Y was required; the mistake was assuming X sufficed" — never "A had a bug". A **vague summary** that does not name the specific mistake is worthless and must be rejected (produce nothing rather than noise).
+3. **Route it to `lisa-persist-learning`** exactly like the rejection-reflection path: candidate fields (rule, why, provenance linking the ancestor issue + its PR + this issue, evidence links, scope hint, triggering issue) with fingerprint `sll4-sha1(rule\ntriggering_issue)[:12]`.
+
+### Graceful degrade — `lisa-persist-learning` unavailable
+
+Same fallback pattern as the rejection path, with this rule's own distinct marker. Record the candidate as a comment on the claimed item carrying a **visible prose line** plus the marker (a bare marker renders as an empty comment bubble):
+
+```text
+Recorded a candidate learning from this retry's ancestry (queued for the judgment gate): <one-line candidate rule>.
+<!-- [lisa-archaeology-candidate] key=<issue>::<ancestor> -->
+```
+
+The marker line is verbatim — the dedupe contract keys on it, not on the prose.
+
+### Idempotency — marker dedupe
+
+The key is `<issue>::<ancestor>` (the claimed item's ref, `::`, the ancestor's ref — the `::` separator keeps the key unambiguous when vendor refs themselves contain hyphens, e.g. `PROJ-123`; it is stable across re-claims of the same pair). Before producing a candidate, search for an existing `[lisa-archaeology-candidate]` comment/artifact carrying this exact key — match on the **marker, never the title** (the `lisa-github-write-prd` Phase 2 discipline). Dedupe is per **(issue, ancestor) pair**: re-claiming an issue whose archaeology already resolved the same ancestor finds the marker and short-circuits — no duplicate candidate for that pair. A re-claim that resolves a **different** ancestor is new evidence and may legitimately produce a second candidate under its own key — that is intended, not a dedupe failure.
+
+### `fresh` produces silence
+
+A `fresh` classification produces **no candidate and zero comments**. Silence is the correct output — emitting a low-value candidate on every claim is precisely the rule-pollution failure mode the learning loop names as its existential risk.
+
+## Cost budget — enforced here, configured in one place
+
+Archaeology is speculative digging on the critical path of every claim. The budget is what makes that safe.
+
+- **`archaeology.maxSteps`** — the maximum number of tracker/git queries one archaeology pass may spend, read from `.lisa.config.json`:
+
+  ```bash
+  MAX_STEPS=$(jq -r '.archaeology.maxSteps // 8' .lisa.config.json 2>/dev/null || echo 8)
+  ```
+
+  The conservative default is **8** — enough for the metadata read (free, already fetched), one or two similarity searches, and git ancestry over a handful of implicated files, and small enough that a fruitless dig on a large repo ends quickly. `lisa sync` seeds the key (registry default), and **this rule pair is the single documented place** for what the budget means — do not restate its semantics in the vendor skills.
+- **`archaeology.maxSeconds`** — optional wall-clock ceiling for the whole pass, read the same way (`jq -r '.archaeology.maxSeconds // empty'`); unset means steps alone bound the pass.
+
+**Budget exhaustion is a NORMAL outcome, not an error.** When the pass hits either ceiling with no confident ancestor, it classifies `fresh` and the claim proceeds immediately — no retry, no escalation, no blocking warning.
+
+## Never block the claim
+
+The invariant everything above hangs on: **archaeology never blocks the claim**. By construction:
+
+- Weak or inconclusive signals → degrade to `fresh`, claim proceeds.
+- Budget exhausted → degrade to `fresh`, claim proceeds.
+- The pass throws or errors (tracker outage, malformed history, missing config) → the exception is caught, classification degrades to `fresh`, and the **claim still proceeds** — a crash inside a speculative bonus feature must never strand a ready issue in the queue.
+- Unreadable ancestor evidence on a genuine retry → no candidate produced, the item is still implemented — degraded, not stopped.
+
+Headless-safe throughout: no interactive prompts, safe under intake crons.

package/plugins/lisa/skills/lisa-github-build-intake/SKILL.md

@@ -256,6 +256,8 @@ A blocker is active if it is open and has no cleared status label. Treat `status
 
 **On `rejection-reclaim`, reflect before re-implementing** (per `rejection-detection`): read the rejection evidence through the access layer — the issue comments posted after the backward transition (the QA rejection comment) and the review threads on the rejected PR via `lisa-github-read-issue` — assemble ONE candidate learning (rule, why, provenance linking the rejection comment + rejected PR, evidence links, scope hint, triggering issue, fingerprint `sll4-sha1(rule\ntriggering_issue)[:12]`), and route it to the `lisa-persist-learning` skill. If that skill is absent, record the candidate as a comment carrying a **visible prose line plus** the marker (a bare marker renders as an empty bubble) — `Recorded a candidate learning from this rejection (queued for the judgment gate): <one-line candidate rule>.` then `<!-- [lisa-rejection-candidate] key=<issue>-<transition-ts> -->` — and proceed. Dedupe on `<issue>-<backward-transition-timestamp>` — a second re-claim produces no duplicate. Unreadable/absent evidence → no candidate, still implement.
 
+**Claim-time archaeology runs second — after rejection detection, still before the relabel below.** Classify this item per the vendor-neutral `claim-archaeology` rule, with the rejection classification above as its input. All shared semantics — ancestry signals, classification, learning-loop exclusion, cost budget, candidate derivation, marker dedupe, and the never-block degrade — live in that one slug; change them there, never here. GitHub wiring only: the typed relations and `closingIssuesReferences` are already in the read bundle; text-similarity searches use `gh search issues` over recently-closed issues; the fallback candidate comment is posted with `gh issue comment`.
+
 ```bash
 gh issue edit <number> --repo <org>/<repo> --remove-label "$READY" --add-label "$CLAIMED"
 # Assign to the authenticated user ONLY when the issue is currently unassigned (attributable claim;

package/plugins/lisa/skills/lisa-jira-build-intake/SKILL.md

@@ -200,6 +200,8 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 
 **On `rejection-reclaim`, reflect before re-implementing** (per `rejection-detection`): read the rejection evidence through the access layer — the ticket comments posted after the backward transition (the QA rejection comment) via `lisa-atlassian-access operation: read-ticket` / `comment` reads and the review threads on the rejected PR — assemble ONE candidate learning (rule, why, provenance linking the rejection comment + rejected PR, evidence links, scope hint, triggering issue, fingerprint `sll4-sha1(rule\ntriggering_issue)[:12]`), and route it to the `lisa-persist-learning` skill. If that skill is absent, record the candidate via `lisa-atlassian-access operation: comment` as a comment carrying a **visible prose line plus** the marker (a bare marker renders as an empty bubble) — `Recorded a candidate learning from this rejection (queued for the judgment gate): <one-line candidate rule>.` then `<!-- [lisa-rejection-candidate] key=<issue>-<transition-ts> -->` — and proceed. Dedupe on `<issue>-<backward-transition-timestamp>` — a second re-claim produces no duplicate. Unreadable/absent evidence → no candidate, still implement.
 
+**Claim-time archaeology runs second — after rejection detection, still before the transition below.** Classify this ticket per the vendor-neutral `claim-archaeology` rule, with the rejection classification above as its input. All shared semantics — ancestry signals, classification, learning-loop exclusion, cost budget, candidate derivation, marker dedupe, and the never-block degrade — live in that one slug; change them there, never here. JIRA wiring only: the typed relations are already in the read bundle; text-similarity searches run through `lisa-atlassian-access operation: search-issues jql:` over recently-closed tickets; the fallback candidate comment is posted via `lisa-atlassian-access operation: comment`.
+
 Transition the ticket from `$READY` to `$CLAIMED` by invoking `lisa-atlassian-access` `operation: transition key: <TICKET> to: "$CLAIMED"`.
 - **Assign to the authenticated user when the ticket is unassigned.** A claim must be attributable. If the ticket has no assignee, assign it to the authenticated account — prefer acli `--assignee @me` (resolves server-side to the authenticated user, which avoids the federated-`accountId` mis-assignment), or `write-ticket` with the `accountId` from the `/rest/api/3/myself` identity probe the access skill already documents. Leave an already-assigned ticket's assignee untouched — never reassign work that already has an owner.
 - Post a `[claude-build-intake]` comment via `lisa-atlassian-access` `operation: comment key: <TICKET> body: "Claimed by Claude. Starting build."`

package/plugins/lisa/skills/lisa-linear-build-intake/SKILL.md

@@ -190,6 +190,8 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 
 **On `rejection-reclaim`, reflect before re-implementing** (per `rejection-detection`): read the rejection evidence through the access layer — the Issue comments posted after the backward transition (the QA rejection comment) via `lisa-linear-access operation: list-comments` and the review threads on the rejected PR — assemble ONE candidate learning (rule, why, provenance linking the rejection comment + rejected PR, evidence links, scope hint, triggering issue, fingerprint `sll4-sha1(rule\ntriggering_issue)[:12]`), and route it to the `lisa-persist-learning` skill. If that skill is absent, record the candidate via `lisa-linear-access operation: save-comment` as a comment carrying a **visible prose line plus** the marker (a bare marker renders as an empty bubble) — `Recorded a candidate learning from this rejection (queued for the judgment gate): <one-line candidate rule>.` then `<!-- [lisa-rejection-candidate] key=<issue>-<transition-ts> -->` — and proceed. Dedupe on `<issue>-<backward-transition-timestamp>` — a second re-claim produces no duplicate. Unreadable/absent evidence → no candidate, still implement.
 
+**Claim-time archaeology runs second — after rejection detection, still before the relabel below.** Classify this Issue per the vendor-neutral `claim-archaeology` rule, with the rejection classification above as its input. All shared semantics — ancestry signals, classification, learning-loop exclusion, cost budget, candidate derivation, marker dedupe, and the never-block degrade — live in that one slug; change them there, never here. Linear wiring only: the native relations are already in the read bundle; text-similarity searches run through `lisa-linear-access operation: list-issues` filtered to recently-closed Issues; the fallback candidate comment is posted via `lisa-linear-access operation: save-comment`.
+
 Update labels via `lisa-linear-access operation: save-issue`: remove `$READY`, add `$CLAIMED`. Resolve label IDs via `list_issue_labels` (create `$CLAIMED` if missing).
 
 **Assign to the authenticated user when the Issue is unassigned.** A claim must be attributable. If the Issue has no assignee, set its `assigneeId` to the authenticated viewer (resolve the viewer's id via the Linear MCP identity — e.g. `get_user` for the current actor) through `lisa-linear-access operation: save-issue`. Leave an already-assigned Issue's assignee untouched — never reassign work that already has an owner.

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-github-build-intake/SKILL.md

@@ -256,6 +256,8 @@ A blocker is active if it is open and has no cleared status label. Treat `status
 
 **On `rejection-reclaim`, reflect before re-implementing** (per `rejection-detection`): read the rejection evidence through the access layer — the issue comments posted after the backward transition (the QA rejection comment) and the review threads on the rejected PR via `lisa-github-read-issue` — assemble ONE candidate learning (rule, why, provenance linking the rejection comment + rejected PR, evidence links, scope hint, triggering issue, fingerprint `sll4-sha1(rule\ntriggering_issue)[:12]`), and route it to the `lisa-persist-learning` skill. If that skill is absent, record the candidate as a comment carrying a **visible prose line plus** the marker (a bare marker renders as an empty bubble) — `Recorded a candidate learning from this rejection (queued for the judgment gate): <one-line candidate rule>.` then `<!-- [lisa-rejection-candidate] key=<issue>-<transition-ts> -->` — and proceed. Dedupe on `<issue>-<backward-transition-timestamp>` — a second re-claim produces no duplicate. Unreadable/absent evidence → no candidate, still implement.
 
+**Claim-time archaeology runs second — after rejection detection, still before the relabel below.** Classify this item per the vendor-neutral `claim-archaeology` rule, with the rejection classification above as its input. All shared semantics — ancestry signals, classification, learning-loop exclusion, cost budget, candidate derivation, marker dedupe, and the never-block degrade — live in that one slug; change them there, never here. GitHub wiring only: the typed relations and `closingIssuesReferences` are already in the read bundle; text-similarity searches use `gh search issues` over recently-closed issues; the fallback candidate comment is posted with `gh issue comment`.
+
 ```bash
 gh issue edit <number> --repo <org>/<repo> --remove-label "$READY" --add-label "$CLAIMED"
 # Assign to the authenticated user ONLY when the issue is currently unassigned (attributable claim;

package/plugins/lisa-agy/skills/lisa-jira-build-intake/SKILL.md

@@ -200,6 +200,8 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 
 **On `rejection-reclaim`, reflect before re-implementing** (per `rejection-detection`): read the rejection evidence through the access layer — the ticket comments posted after the backward transition (the QA rejection comment) via `lisa-atlassian-access operation: read-ticket` / `comment` reads and the review threads on the rejected PR — assemble ONE candidate learning (rule, why, provenance linking the rejection comment + rejected PR, evidence links, scope hint, triggering issue, fingerprint `sll4-sha1(rule\ntriggering_issue)[:12]`), and route it to the `lisa-persist-learning` skill. If that skill is absent, record the candidate via `lisa-atlassian-access operation: comment` as a comment carrying a **visible prose line plus** the marker (a bare marker renders as an empty bubble) — `Recorded a candidate learning from this rejection (queued for the judgment gate): <one-line candidate rule>.` then `<!-- [lisa-rejection-candidate] key=<issue>-<transition-ts> -->` — and proceed. Dedupe on `<issue>-<backward-transition-timestamp>` — a second re-claim produces no duplicate. Unreadable/absent evidence → no candidate, still implement.
 
+**Claim-time archaeology runs second — after rejection detection, still before the transition below.** Classify this ticket per the vendor-neutral `claim-archaeology` rule, with the rejection classification above as its input. All shared semantics — ancestry signals, classification, learning-loop exclusion, cost budget, candidate derivation, marker dedupe, and the never-block degrade — live in that one slug; change them there, never here. JIRA wiring only: the typed relations are already in the read bundle; text-similarity searches run through `lisa-atlassian-access operation: search-issues jql:` over recently-closed tickets; the fallback candidate comment is posted via `lisa-atlassian-access operation: comment`.
+
 Transition the ticket from `$READY` to `$CLAIMED` by invoking `lisa-atlassian-access` `operation: transition key: <TICKET> to: "$CLAIMED"`.
 - **Assign to the authenticated user when the ticket is unassigned.** A claim must be attributable. If the ticket has no assignee, assign it to the authenticated account — prefer acli `--assignee @me` (resolves server-side to the authenticated user, which avoids the federated-`accountId` mis-assignment), or `write-ticket` with the `accountId` from the `/rest/api/3/myself` identity probe the access skill already documents. Leave an already-assigned ticket's assignee untouched — never reassign work that already has an owner.
 - Post a `[claude-build-intake]` comment via `lisa-atlassian-access` `operation: comment key: <TICKET> body: "Claimed by Claude. Starting build."`

package/plugins/lisa-agy/skills/lisa-linear-build-intake/SKILL.md

@@ -190,6 +190,8 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 
 **On `rejection-reclaim`, reflect before re-implementing** (per `rejection-detection`): read the rejection evidence through the access layer — the Issue comments posted after the backward transition (the QA rejection comment) via `lisa-linear-access operation: list-comments` and the review threads on the rejected PR — assemble ONE candidate learning (rule, why, provenance linking the rejection comment + rejected PR, evidence links, scope hint, triggering issue, fingerprint `sll4-sha1(rule\ntriggering_issue)[:12]`), and route it to the `lisa-persist-learning` skill. If that skill is absent, record the candidate via `lisa-linear-access operation: save-comment` as a comment carrying a **visible prose line plus** the marker (a bare marker renders as an empty bubble) — `Recorded a candidate learning from this rejection (queued for the judgment gate): <one-line candidate rule>.` then `<!-- [lisa-rejection-candidate] key=<issue>-<transition-ts> -->` — and proceed. Dedupe on `<issue>-<backward-transition-timestamp>` — a second re-claim produces no duplicate. Unreadable/absent evidence → no candidate, still implement.
 
+**Claim-time archaeology runs second — after rejection detection, still before the relabel below.** Classify this Issue per the vendor-neutral `claim-archaeology` rule, with the rejection classification above as its input. All shared semantics — ancestry signals, classification, learning-loop exclusion, cost budget, candidate derivation, marker dedupe, and the never-block degrade — live in that one slug; change them there, never here. Linear wiring only: the native relations are already in the read bundle; text-similarity searches run through `lisa-linear-access operation: list-issues` filtered to recently-closed Issues; the fallback candidate comment is posted via `lisa-linear-access operation: save-comment`.
+
 Update labels via `lisa-linear-access operation: save-issue`: remove `$READY`, add `$CLAIMED`. Resolve label IDs via `list_issue_labels` (create `$CLAIMED` if missing).
 
 **Assign to the authenticated user when the Issue is unassigned.** A claim must be attributable. If the Issue has no assignee, set its `assigneeId` to the authenticated viewer (resolve the viewer's id via the Linear MCP identity — e.g. `get_user` for the current actor) through `lisa-linear-access operation: save-issue`. Leave an already-assigned Issue's assignee untouched — never reassign work that already has an owner.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.240.0",
+  "version": "2.242.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.240.0",
+  "version": "2.242.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.240.0",
+  "version": "2.242.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.240.0",
+  "version": "2.242.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.240.0",
+  "version": "2.242.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.240.0",
+  "version": "2.242.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"
@@ -26,6 +26,15 @@
             "command": "${CLAUDE_PLUGIN_ROOT}/hooks/shell-write-nudge.sh"
           }
         ]
+      },
+      {
+        "matcher": "Edit|Write|NotebookEdit|Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/threshold-ratchet.sh"
+          }
+        ]
       }
     ],
     "preToolUse": [

package/plugins/lisa-copilot/hooks/threshold-ratchet-compare.mjs

@@ -0,0 +1,315 @@
+/**
+ * Threshold ratchet — comparison rules and reporting.
+ *
+ * Pure comparison layer: given a watched file's baseline and current
+ * contents, report every weakening. No filesystem or git access. See
+ * threshold-ratchet-families.mjs for extraction and threshold-ratchet.mjs
+ * for the CLI.
+ */
+import {
+  extractAllowEntries,
+  extractExemptionEntries,
+  extractK6Constraints,
+  extractNumericLeaves,
+  extractRubocopThresholds,
+  extractStrykerConstraints,
+  extractStrykerMutate,
+  familyFor,
+  parseJson,
+} from "./threshold-ratchet-families.mjs";
+
+/** Finding type: a numeric bound or boolean gate moved the weakening way. */
+const TYPE_WEAKENED = "weakened";
+/** Finding type: an exemption entry was added (Tier 3). */
+const TYPE_EXEMPTION_ADDED = "exemption-added";
+/** Family kind for .lisa.config.json (the thresholdRatchet.allow carrier). */
+const KIND_ALLOW_LIST = "allow-list";
+
+/**
+ * @typedef {object} Finding
+ * @property {string} file Repo-relative path of the gate file
+ * @property {string} key Dotted key path within the file
+ * @property {"weakened"|"removed"|"exemption-added"|"file-deleted"|"allow-added"|"unparseable"} type
+ *   Which ratchet rule the change violated
+ * @property {number|string} [base] Baseline value
+ * @property {number|string} [current] Current value
+ * @property {string} message Operator-readable explanation
+ */
+
+/**
+ * Build the "file could not be parsed" finding.
+ * @param {string} relPath Repo-relative path
+ * @returns {Finding} The unparseable-file finding
+ */
+function unparseable(relPath) {
+  return {
+    file: relPath,
+    key: "*",
+    type: "unparseable",
+    message: `${relPath} is no longer valid JSON — a broken gate file disables the gate.`,
+  };
+}
+
+/**
+ * Compare two constraint maps: report removals and direction violations.
+ * @param {string} relPath Repo-relative path the constraints came from
+ * @param {Map<string, { value: number, direction: "min"|"max" }>} base
+ *   Baseline constraints
+ * @param {Map<string, { value: number, direction: "min"|"max" }>} current
+ *   Current constraints
+ * @returns {Finding[]} One finding per removed or weakened constraint
+ */
+export function compareConstraints(relPath, base, current) {
+  const findings = [];
+  for (const [key, baseC] of base) {
+    const currentC = current.get(key);
+    if (!currentC) {
+      findings.push({
+        file: relPath,
+        key,
+        type: "removed",
+        base: baseC.value,
+        message: `${relPath}: ${key} was removed — the tuned floor would silently fall back to a default.`,
+      });
+      continue;
+    }
+    const weakened =
+      baseC.direction === "min"
+        ? currentC.value < baseC.value
+        : currentC.value > baseC.value;
+    if (weakened) {
+      const verb =
+        baseC.direction === "min" ? "may only increase" : "may only decrease";
+      findings.push({
+        file: relPath,
+        key,
+        type: TYPE_WEAKENED,
+        base: baseC.value,
+        current: currentC.value,
+        message: `${relPath}: ${key} changed ${baseC.value} → ${currentC.value} (this value ${verb}).`,
+      });
+    }
+  }
+  return findings;
+}
+
+/**
+ * Compare a stryker.conf.json pair: the break threshold plus mutate-list
+ * exemptions (new negations or removed targets shrink the gate).
+ * @param {string} relPath Repo-relative path
+ * @param {unknown} base Parsed baseline config
+ * @param {unknown} current Parsed current config
+ * @returns {Finding[]} Break-threshold and mutate-scope findings
+ */
+function compareStryker(relPath, base, current) {
+  const findings = compareConstraints(
+    relPath,
+    extractStrykerConstraints(base),
+    extractStrykerConstraints(current)
+  );
+  const baseMutate = extractStrykerMutate(base);
+  const currentMutate = extractStrykerMutate(current);
+  for (const negation of currentMutate.negations) {
+    if (!baseMutate.negations.has(negation)) {
+      findings.push({
+        file: relPath,
+        key: `mutate ${negation}`,
+        type: TYPE_EXEMPTION_ADDED,
+        message: `${relPath}: new mutation-testing exclusion "${negation}" — excluding files from a gate is a weakening.`,
+      });
+    }
+  }
+  for (const positive of baseMutate.positives) {
+    if (!currentMutate.positives.has(positive)) {
+      findings.push({
+        file: relPath,
+        key: `mutate ${positive}`,
+        type: TYPE_EXEMPTION_ADDED,
+        message: `${relPath}: mutation-testing target "${positive}" was removed — shrinking a gate's coverage is a weakening.`,
+      });
+    }
+  }
+  return findings;
+}
+
+/**
+ * Compare a k6 thresholds pair: numeric bounds plus abortOnFail downgrades.
+ * @param {string} relPath Repo-relative path
+ * @param {unknown} base Parsed baseline thresholds
+ * @param {unknown} current Parsed current thresholds
+ * @returns {Finding[]} Bound and abortOnFail findings
+ */
+function compareK6(relPath, base, current) {
+  const baseC = extractK6Constraints(base);
+  const currentC = extractK6Constraints(current);
+  const findings = compareConstraints(relPath, baseC.numeric, currentC.numeric);
+  for (const [key, wasOn] of baseC.booleans) {
+    // k6 defaults abortOnFail to false, so DELETING an explicit `true` is as
+    // much a weakening as flipping it — anything but a current `true` blocks.
+    if (wasOn && currentC.booleans.get(key) !== true) {
+      findings.push({
+        file: relPath,
+        key,
+        type: TYPE_WEAKENED,
+        base: "true",
+        current: "false",
+        message: `${relPath}: ${key} turned off — the gate no longer stops the run on failure.`,
+      });
+    }
+  }
+  return findings;
+}
+
+/**
+ * Compare an exemption-list pair (audit ignore files): report added entries.
+ * @param {string} relPath Repo-relative path
+ * @param {unknown} base Parsed baseline list
+ * @param {unknown} current Parsed current list
+ * @returns {Finding[]} One finding per newly added ignore entry
+ */
+function compareExemptions(relPath, base, current) {
+  const baseEntries = extractExemptionEntries(base);
+  const findings = [];
+  for (const entry of extractExemptionEntries(current)) {
+    if (!baseEntries.has(entry)) {
+      findings.push({
+        file: relPath,
+        key: entry,
+        type: TYPE_EXEMPTION_ADDED,
+        message: `${relPath}: new security-audit ignore entry "${entry}" — ignoring a finding weakens the gate and needs a human's sign-off.`,
+      });
+    }
+  }
+  return findings;
+}
+
+/**
+ * Compare .lisa.config.json allow lists: report added exception entries so a
+ * change can never grant itself an exception.
+ * @param {string} relPath Repo-relative path
+ * @param {unknown} base Parsed baseline config
+ * @param {unknown} current Parsed current config
+ * @returns {Finding[]} One finding per newly added allow entry
+ */
+function compareAllowList(relPath, base, current) {
+  const baseKeys = new Set(
+    extractAllowEntries(base).map(e => `${e.file} ${e.key}`)
+  );
+  const findings = [];
+  for (const entry of extractAllowEntries(current)) {
+    if (!baseKeys.has(`${entry.file} ${entry.key}`)) {
+      findings.push({
+        file: relPath,
+        key: `thresholdRatchet.allow ${entry.file}#${entry.key}`,
+        type: "allow-added",
+        message: `${relPath}: new threshold exception for ${entry.file} → ${entry.key}. Exceptions are a human decision: land this entry in its own human-approved change first, then make the threshold change.`,
+      });
+    }
+  }
+  return findings;
+}
+
+/**
+ * Compare one watched file's baseline and current contents and report every
+ * weakening. Pure: no filesystem or git access.
+ * @param {string} relPath Repo-relative path (forward slashes)
+ * @param {string | null} baselineText Baseline contents (null = file is new)
+ * @param {string | null} currentText Current contents (null = file deleted)
+ * @returns {Finding[]} Every ratchet violation in the change (empty = clean)
+ */
+export function compareFile(relPath, baselineText, currentText) {
+  const family = familyFor(relPath);
+  if (!family || baselineText === null || baselineText === undefined) return [];
+
+  if (currentText === null || currentText === undefined) {
+    if (family.kind === KIND_ALLOW_LIST) return [];
+    return [
+      {
+        file: relPath,
+        key: "*",
+        type: "file-deleted",
+        message: `${relPath} was deleted — deleting a quality gate is a weakening.`,
+      },
+    ];
+  }
+
+  if (family.kind === "rubocop-yaml") {
+    return compareConstraints(
+      relPath,
+      extractRubocopThresholds(baselineText, family.direction),
+      extractRubocopThresholds(currentText, family.direction)
+    );
+  }
+
+  const base = parseJson(baselineText);
+  const current = parseJson(currentText);
+  if (base === undefined) return [];
+  if (current === undefined) {
+    return family.kind === KIND_ALLOW_LIST ? [] : [unparseable(relPath)];
+  }
+  switch (family.kind) {
+    case "json-num":
+      return compareConstraints(
+        relPath,
+        extractNumericLeaves(base, family.direction),
+        extractNumericLeaves(current, family.direction)
+      );
+    case "stryker":
+      return compareStryker(relPath, base, current);
+    case "k6":
+      return compareK6(relPath, base, current);
+    case "exemption-list":
+      return compareExemptions(relPath, base, current);
+    case KIND_ALLOW_LIST:
+      return compareAllowList(relPath, base, current);
+    default:
+      return [];
+  }
+}
+
+/**
+ * Drop findings covered by baseline-side allow entries. `allow-added`
+ * findings are never dropped — an exception cannot approve its own creation.
+ * @param {Finding[]} findings All findings from the change
+ * @param {Array<{ file: string, key: string }>} allowEntries Baseline
+ *   (already-merged) allow list
+ * @returns {{ blocked: Finding[], allowed: Finding[] }} Findings that still
+ *   block vs. findings covered by a recorded exception
+ */
+export function applyAllowList(findings, allowEntries) {
+  const blocked = [];
+  const allowed = [];
+  for (const finding of findings) {
+    const isAllowed =
+      finding.type !== "allow-added" &&
+      allowEntries.some(
+        e =>
+          (finding.file === e.file || finding.file.endsWith(`/${e.file}`)) &&
+          (e.key === "*" || e.key === finding.key)
+      );
+    if (isAllowed) allowed.push(finding);
+    else blocked.push(finding);
+  }
+  return { blocked, allowed };
+}
+
+/**
+ * Render the operator-facing block message.
+ * @param {Finding[]} findings Blocked findings
+ * @returns {string} Multi-line report explaining what weakened and the
+ *   human-approved exception path
+ */
+export function formatReport(findings) {
+  return [
+    "⛔ Quality gate weakened — blocked by the threshold ratchet.",
+    "",
+    ...findings.map(f => `  • ${f.message}`),
+    "",
+    "Quality thresholds are a one-way ratchet: they may tighten but never",
+    "loosen. Fix the code so it meets the current gate instead of lowering the",
+    "gate. If a human decides an exception is genuinely correct, they record it",
+    "in .lisa.config.json under thresholdRatchet.allow (with a reason) in a",
+    "separate human-approved change; this check honors exceptions only after",
+    "they are merged.",
+  ].join("\n");
+}