@codyswann/lisa 2.239.0 → 2.240.0

package/plugins/lisa-cursor/skills/lisa-attribute-failure/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: lisa-attribute-failure
+description: "Event-triggered root-cause attribution for an arbitrary failure: decide, with cited evidence, whether the defect is Lisa's fault or the project's. Accepts a failure event (defect description, implicated files, rule/skill/hook in play) and returns a verdict of lisa | project | ambiguous plus the evidence relied on. Read-only — it never files, writes, or remediates; callers (lisa-doctor findings, the learning judgment gate, rework triage) consume the verdict. Extracted from lisa-doctor's upstream Lisa change-history diagnosis (#1494) so the same attribution procedure can run on ANY failure event, not only doctor config-audit findings."
+allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
+---
+
+# Attribute Failure
+
+Attribute ONE failure event to Lisa or the project, with cited evidence. Failure event: $ARGUMENTS
+
+Before a Lisa-caused failure can be routed upstream, something has to say — with evidence — "this was Lisa's fault, not the project's." A failure has two possible causes: the project drifted, or **Lisa itself changed or shipped the defect**. This skill must distinguish them instead of blaming the project by default, and equally must never blame Lisa without conclusive evidence. Wrong attribution in either direction is the failure mode; **inconclusive evidence is always `ambiguous`, and ambiguous stays local and low-confidence — never upstream.**
+
+## Input — the failure event
+
+Accept the event as JSON or `key=value` fields. This procedure is **event-triggered, not version-window-keyed**: any failure can be attributed, not only a doctor config-audit finding.
+
+- `defect` — what went wrong, in plain language (required)
+- `implicated_files` — the file paths where the defect lives or manifests (required when known)
+- `surface_in_play` — the Lisa rule / skill / hook / template / workflow involved, if any
+- `installed_version` / `latest_version` — the Lisa version window, when the caller knows it; otherwise resolve it as signal 3 describes
+- `failure_class` — a short slug naming the class of failure (used by downstream filing for the root-cause key)
+
+## Output — the verdict
+
+Return exactly one verdict — `lisa` | `project` | `ambiguous` — plus the evidence it relied on:
+
+```text
+## Attribution: [lisa | project | ambiguous]
+
+**Signal:** [managed-surface | shipped-artifact-behavior | upstream-history | none-conclusive]
+**Lisa surface at fault:** [path or rule/skill/hook name | n/a]
+**Cited evidence:**
+- [each item names the signal it came from and the concrete citation: file path + ownership proof, shipped artifact text, or commit sha/subject/version]
+**Confidence note:** [why the evidence is conclusive, or exactly what was inconclusive]
+```
+
+Verdict rules:
+
+- **`lisa`** — at least one signal conclusively pins the defect on a Lisa-shipped surface or upstream change, and the evidence names that surface. Never emit `lisa` from degraded, truncated, or unverified history.
+- **`project`** — the implicated files are project-owned, no shipped Lisa artifact drove the behavior, and the upstream-history window shows no relevant Lisa change. Cite the absence explicitly (which paths were checked, which window showed no relevant change).
+- **`ambiguous`** — anything else: unresolvable version window, unreachable history, partial ownership, conflicting signals. Ambiguous is treated as local and low-confidence; nothing is escalated upstream from it.
+
+## The three signals (evaluate in order)
+
+### Signal 1 — the defect lives in a Lisa-managed surface
+
+Resolve ownership of each implicated file the way doctor's config audit does:
+
+- **Copy-overwrite / managed**: the path is populated by `lisa apply` from a stack template (`typescript/`, `expo/`, `nestjs/`, `cdk/`, `harper-fabric/`, `rails/` copy-overwrite trees), is a plugin-distributed rule/skill/hook/agent/command surface, carries Lisa governance markers or a Lisa version stamp, or is governed by `package.lisa.json` `force` keys. A defect in the shipped content of such a surface is **Lisa's fault** — any local edit would be overwritten on the next `lisa apply`.
+- **Create-only**: the local copy is project-owned after scaffolding, but if the defect is faithful to the template as shipped, the template is still Lisa's fault (every newly scaffolded repo inherits it). Cite the template origin, and note the local copy will not be overwritten.
+- **Project-owned**: not from a Lisa template and not Lisa-managed — signal 1 is negative; continue.
+
+If the project locally modified a managed surface and the defect lives in the local modification, that is project drift, not a Lisa defect — signal 1 is negative for `lisa` and positive evidence for `project`.
+
+### Signal 2 — a shipped Lisa rule/skill/hook drove the wrong behavior
+
+Read the shipped artifact named in `surface_in_play` (the plugin-distributed rule, skill, hook, agent, or CI workflow as Lisa ships it — not a local fork). If following its instructions or configuration as shipped produces the observed defect, the verdict is `lisa`: cite the artifact path and the specific shipped text or configuration that drove the behavior. If the artifact is shipped correct and was misapplied locally, that is evidence for `project`.
+
+### Signal 3 — the upstream-history window shows Lisa changed the relevant contract
+
+This is the #1494 doctor procedure, unchanged in behavior — here it is the third signal, not the trigger. Whenever signals 1-2 are not conclusive on their own — and always before a definitive `project` verdict — pull Lisa's own git history for the version window and read what actually changed:
+
+1. **Resolve the version window.** Use the caller-supplied `installed_version`/`latest_version` when present; otherwise determine the project's installed Lisa version (the `@codyswann/lisa` entry in `package.json`/lockfile, or the plugin version stamp on the active runtime) and the latest published version (`npm view @codyswann/lisa version`, or the update check's cached result). An unresolvable window makes this signal inconclusive — it can support `ambiguous`, never `lisa`.
+2. **Pull the upstream history for that window** (read-only; no clone required when `gh` is available):
+
+   ```bash
+   gh api "repos/CodySwannGT/lisa/compare/v<installed>...v<latest>" \
+     --paginate --slurp |
+     jq '{total_commits: .[0].total_commits, files: [.[0].files[]?.filename], commits: [.[].commits[]? | {sha, subject: (.commit.message | split("\n")[0]), api_url: .url, html_url, parents: [.parents[]?.sha]}]}'
+   ```
+
+   `--paginate` fetches every page of commits, and `--slurp` gathers those pages into a single
+   array before the external `jq` projection runs. GitHub CLI does not permit its built-in `--jq`
+   flag together with `--slurp`, so keep the pipe as shown; without `--slurp`, paginated responses
+   are not one merged input. `total_commits` and `files` only need the first page
+   (files are capped at 300 and not repeated on later pages); `commits` flattens across all pages
+   while retaining each commit SHA and URLs needed for accurate follow-up.
+
+   After path-scoping identifies a candidate commit, fetch its targeted file-level diff context by
+   the retained SHA rather than attributing from the subject alone:
+
+   ```bash
+   gh api "repos/CodySwannGT/lisa/commits/<sha>" \
+     --jq '{sha, files: [.files[]? | select(.filename == "<relevant-path>" or (.filename | startswith("<relevant-prefix>/"))) | {filename, status, additions, deletions, changes, patch}]}'
+   ```
+
+   Preserve the returned filename, status, counts, and available patch with the SHA in the
+   upstream-history projection. A missing or truncated `patch` is not proof of no relevant change;
+   use the compare diff fallback below or downgrade the attribution to `ambiguous` when
+   commit-level context cannot be established.
+
+   The compare endpoint paginates commits (250 without `--paginate`) and only lists changed files
+   on the first page, capped at 300 total — a large version window can silently drop commits or
+   files. If `total_commits` or the file count looks truncated, re-run with the
+   `application/vnd.github.diff` accept header (`gh api ... -H "Accept: application/vnd.github.diff"`)
+   to pull the full patch text, or fall back to the bounded-fetch `git log` below. When completeness
+   still can't be established, say so in the evidence and return `ambiguous` rather than attributing
+   with unverified confidence.
+
+   Fallbacks, in order: `gh api repos/CodySwannGT/lisa/commits?path=<template-path>` for a
+   path-scoped view — note this endpoint has no way to bound results to the `v<installed>..v<latest>`
+   window, so treat its output as best-effort context only, not authoritative attribution; a
+   finite-depth, explicit-tag fetch, which is bounded to the two version refs and should be preferred
+   for definitive attribution; or the local marketplace/plugin cache checkout when the runtime has
+   one. For the fetch fallback, use a temporary directory and a fixed history ceiling:
+
+   ```bash
+   lisa_history_dir="$(mktemp -d)"
+   git init "$lisa_history_dir"
+   git -C "$lisa_history_dir" remote add origin https://github.com/CodySwannGT/lisa.git
+   git -C "$lisa_history_dir" fetch --no-tags --filter=blob:none --depth=256 origin \
+     refs/tags/v<installed>:refs/tags/v<installed> \
+     refs/tags/v<latest>:refs/tags/v<latest>
+   git -C "$lisa_history_dir" merge-base --is-ancestor v<installed> v<latest>
+   git -C "$lisa_history_dir" log --format='%H%x09%s' v<installed>..v<latest> -- <paths>
+   git -C "$lisa_history_dir" show --format=fuller --stat --patch <relevant-sha> -- <paths>
+   ```
+
+   The explicit tag refspecs, `--no-tags`, and finite `--depth=256` make this fetch bounded. Do not
+   silently deepen beyond that ceiling. If `merge-base --is-ancestor` fails, the shallow window is
+   incomplete (or the tags are not on one ancestry line): do not make definitive attribution from
+   it. If none of the bounded sources are reachable, or only the unbounded path-scoped fallback is
+   reachable, report the gap in the evidence and return `ambiguous` — never fail the caller's flow
+   because history was unavailable or incomplete, and never let a degraded history produce `lisa`.
+3. **Scope the reading to what the failure touches.** Filter the commit list to the paths that
+   generate the failing surface: the detected stacks' template dirs (`typescript/`, `expo/`, …),
+   `plugins/src/base/` for skills/hooks/rules, `scripts/` for governance scripts, and the shipped
+   config factories (`src/configs/`). A failure about a lint rule reads the lint-config commits,
+   not the whole log.
+4. **Attribute.** When the upstream history shows Lisa changed the relevant contract (a tightened
+   lint rule, a renamed check context, a new required config key), the verdict is `lisa` — cite the
+   commit subject/version. When history shows no relevant upstream change and signals 1-2 are also
+   negative, the project drifted — the verdict is `project`, citing the absence of a relevant
+   upstream change as the evidence.
+
+## Rules
+
+- **Read-only.** This skill reads the project and Lisa's repository; it never writes to either, never files issues, and never remediates. Filing the upstream ticket on a `lisa` verdict is the caller's flow (`lisa-persist-learning`, `handoff-upstream` disposition); doctor maps verdicts into its findings; remediation stays with whoever called.
+- **Never block.** Attribution failure, missing tooling (`gh` unavailable), or degraded history degrades to `ambiguous` with the gap named in the evidence — it never raises an error that stops the caller's build or audit.
+- **Every verdict cites its evidence.** An attribution without a named signal and concrete citation is invalid — return `ambiguous` instead. Evidence destined for upstream surfaces quotes ONLY Lisa-owned surface text (never host env values, tokens/credentials, PII, or proprietary host code — link the host issue instead of quoting it); the binding redaction procedure lives in `lisa-persist-learning`'s `handoff-upstream` step.
+- **Ambiguous never escalates.** `ambiguous` is a terminal local verdict: low-confidence, no upstream filing, no durable local rule derived from it.
+- **Headless-safe and idempotent**: no prompts, no side effects, same event in → same verdict out.

package/plugins/lisa-cursor/skills/lisa-doctor/SKILL.md

@@ -296,88 +296,39 @@ without turning the base doctor into a second `lisa-wiki-doctor`.
 A failing or warning check has two possible causes: the project drifted, or **Lisa itself changed
 upstream** since this project last updated. Doctor must distinguish them instead of blaming the
 project by default. Whenever findings need explanation — and always before proposing repairs —
-pull Lisa's own git history and read what actually changed:
+attribute the finding with real evidence.
+
+The attribution procedure itself is shared: it lives in the `lisa-attribute-failure` skill
+(extracted from this section so any failure event can be attributed, not only doctor findings).
+Doctor invokes it per finding:
 
 1. **Resolve the version window.** Determine the project's installed Lisa version (the
    `@codyswann/lisa` entry in `package.json`/lockfile, or the plugin version stamp on the active
    runtime) and the latest published version (`npm view @codyswann/lisa version`, or the update
    check's cached result).
-2. **Pull the upstream history for that window** (read-only; no clone required when `gh` is
-   available):
-
-   ```bash
-   gh api "repos/CodySwannGT/lisa/compare/v<installed>...v<latest>" \
-     --paginate --slurp |
-     jq '{total_commits: .[0].total_commits, files: [.[0].files[]?.filename], commits: [.[].commits[]? | {sha, subject: (.commit.message | split("\n")[0]), api_url: .url, html_url, parents: [.parents[]?.sha]}]}'
-   ```
-
-   `--paginate` fetches every page of commits, and `--slurp` gathers those pages into a single
-   array before the external `jq` projection runs. GitHub CLI does not permit its built-in `--jq`
-   flag together with `--slurp`, so keep the pipe as shown; without `--slurp`, paginated responses
-   are not one merged input. `total_commits` and `files` only need the first page
-   (files are capped at 300 and not repeated on later pages); `commits` flattens across all pages
-   while retaining each commit SHA and URLs needed for accurate follow-up.
-
-   After path-scoping identifies a candidate commit, fetch its targeted file-level diff context by
-   the retained SHA rather than attributing from the subject alone:
-
-   ```bash
-   gh api "repos/CodySwannGT/lisa/commits/<sha>" \
-     --jq '{sha, files: [.files[]? | select(.filename == "<relevant-path>" or (.filename | startswith("<relevant-prefix>/"))) | {filename, status, additions, deletions, changes, patch}]}'
-   ```
-
-   Preserve the returned filename, status, counts, and available patch with the SHA in the
-   upstream-history projection. A missing or truncated `patch` is not proof of no relevant change;
-   use the compare diff fallback below or downgrade attribution to `WARN` when commit-level context
-   cannot be established.
-
-   The compare endpoint paginates commits (250 without `--paginate`) and only lists changed files
-   on the first page, capped at 300 total — a large version window can silently drop commits or
-   files. If `total_commits` or the file count looks truncated, re-run with the
-   `application/vnd.github.diff` accept header (`gh api ... -H "Accept: application/vnd.github.diff"`)
-   to pull the full patch text, or fall back to the bounded-fetch `git log` below. When completeness
-   still can't be established, say so in the finding and mark it `WARN` rather than attributing
-   drift with unverified confidence.
-
-   Fallbacks, in order: `gh api repos/CodySwannGT/lisa/commits?path=<template-path>` for a
-   path-scoped view — note this endpoint has no way to bound results to the `v<installed>..v<latest>`
-   window, so treat its output as best-effort context only, not authoritative attribution; a
-   finite-depth, explicit-tag fetch, which is bounded to the two version refs and should be preferred
-   for definitive attribution; or the local marketplace/plugin cache checkout when the runtime has
-   one. For the fetch fallback, use a temporary directory and a fixed history ceiling:
-
-   ```bash
-   lisa_history_dir="$(mktemp -d)"
-   git init "$lisa_history_dir"
-   git -C "$lisa_history_dir" remote add origin https://github.com/CodySwannGT/lisa.git
-   git -C "$lisa_history_dir" fetch --no-tags --filter=blob:none --depth=256 origin \
-     refs/tags/v<installed>:refs/tags/v<installed> \
-     refs/tags/v<latest>:refs/tags/v<latest>
-   git -C "$lisa_history_dir" merge-base --is-ancestor v<installed> v<latest>
-   git -C "$lisa_history_dir" log --format='%H%x09%s' v<installed>..v<latest> -- <paths>
-   git -C "$lisa_history_dir" show --format=fuller --stat --patch <relevant-sha> -- <paths>
-   ```
-
-   The explicit tag refspecs, `--no-tags`, and finite `--depth=256` make this fetch bounded. Do not
-   silently deepen beyond that ceiling. If `merge-base --is-ancestor` fails, the shallow window is
-   incomplete (or the tags are not on one ancestry line): do not make definitive attribution from
-   it. If none of the bounded sources are reachable, or only the unbounded path-scoped fallback is
-   reachable, report the gap as a `WARN`-level observability note — never fail the audit because
-   history was unavailable or incomplete.
-3. **Scope the reading to what the finding touches.** Filter the commit list to the paths that
-   generate the failing surface: the detected stacks' template dirs (`typescript/`, `expo/`, …),
-   `plugins/src/base/` for skills/hooks/rules, `scripts/` for governance scripts, and the shipped
-   config factories (`src/configs/`). A finding about a lint rule failure reads the lint-config
-   commits, not the whole log.
-4. **Attribute the finding.** When the upstream history shows Lisa changed the contract (a
-   tightened lint rule, a renamed check context, a new required config key), say so in `Observed:`
-   with the commit subject/version, and let `Remediation:` point at the sanctioned adoption path
-   (e.g. `lisa update` + re-apply, a documented config opt-out) rather than hand-editing managed
-   files. When history shows no relevant upstream change, the project drifted — remediate on the
-   project side.
-
-This history pull is part of doctor's read-only contract: it reads Lisa's repository, never writes
-to it, and repair suggestions stay suggestions.
+2. **Invoke `lisa-attribute-failure`** with the finding as the failure event: the defect
+   description, the implicated template/config paths, the rule/skill/hook in play, and the
+   resolved version window. The skill evaluates its three ordered signals — Lisa-managed surface
+   ownership, shipped rule/skill/hook behavior, and the upstream change-history window (the
+   version-window compare procedure formerly documented inline here, preserved verbatim in that
+   skill: pagination/`--slurp` handling, targeted per-SHA diff context, truncation caveats, and
+   the bounded explicit-tag fetch fallback) — and returns `lisa` | `project` | `ambiguous` plus
+   the cited evidence.
+3. **Map the verdict into the finding.**
+   - `lisa` — Lisa changed the contract (a tightened lint rule, a renamed check context, a new
+     required config key) or shipped the defective surface. Say so in `Observed:` with the cited
+     evidence (commit subject/version or managed-surface proof), and let `Remediation:` point at
+     the sanctioned adoption path (e.g. `lisa update` + re-apply, a documented config opt-out)
+     rather than hand-editing managed files.
+   - `project` — history shows no relevant upstream change and the surface is project-owned: the
+     project drifted, so remediate on the project side.
+   - `ambiguous` — history was unavailable, truncated, or otherwise inconclusive: report the gap
+     as a `WARN`-level observability note with the evidence gap named — never fail the audit
+     because history was unavailable or incomplete, and never attribute drift with unverified
+     confidence.
+
+This diagnosis remains part of doctor's read-only contract: the attribution skill reads Lisa's
+repository, never writes to it, and repair suggestions stay suggestions.
 
 ## Output contract
 

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

@@ -325,6 +325,22 @@ If the canonical fix is merged but not yet present on the production branch, app
 
 This path is distinct from `BLOCKED`: ambiguity, open blockers, and duplicate-of-open findings remain held for human action and must not be auto-closed.
 
+#### 3c.2 Confirm applied learnings (last_confirmed bump)
+
+Run this at the end of 3c, after the lifecycle outcome is recorded and before 3d. It keeps the decay pass safe: a genuinely useful learning that keeps applying stays fresh, while dead weight ages out.
+
+1. **Identify which learnings demonstrably applied.** Resolve the learnings surface with `resolveProjectLearningsFile` and parse it with `parseLearningsFile` from `@codyswann/lisa/learnings` (never hardcode the path; a missing file skips this step silently). An entry counts as applied ONLY when its rule was explicitly cited or observably followed in this claim's plan, diff, or review responses — the plan quotes the rule or its id, or the diff does specifically what the rule mandates where the default behavior would have differed. **Presence in context is NOT application**: the ledger is loaded eagerly into every session, so counting "it was loaded" would confirm every entry on every claim and defeat decay entirely. A run that produced no plan or diff has nothing to confirm.
+2. **Bump each applied entry exactly once** via the surgical writer:
+
+   ```bash
+   node -e 'import("@codyswann/lisa/learnings").then(async m => { const r = await m.confirmLearningEntry(process.cwd(), process.argv[1], new Date().toISOString().slice(0, 10)); console.log(JSON.stringify(r)); }).catch(error => { console.log(JSON.stringify({ status: "error", id: process.argv[1], message: String(error) })); })' <entry-id> || true
+   ```
+
+   The invocation is failure-safe by construction: a rejected import or write resolves to a structured `error` result instead of a crash, and the trailing `|| true` absorbs any remaining non-zero exit (missing `node`, unresolvable package). Record an `error` or non-zero outcome in the cycle summary and continue — the bump must never abort the lifecycle.
+
+   `confirmLearningEntry` advances ONLY `last_confirmed` — rule text, why, provenance, `first_learned`, and confidence are untouched — and is idempotent within a claim: a repeat same-date bump returns `unchanged`, so an entry that applied repeatedly during one claim is bumped once, not once per application.
+3. **Never block on it.** A failed bump, an unwritable file, or a `not-found` result (the entry was pruned) is recorded under the cycle summary and the claim proceeds — shipping the issue always outranks confirming a learning about it.
+
 #### 3d. Transition to $DONE (only after the PR is merged)
 
 A `done` env state (`status:on-dev`, `status:on-stg`, or the terminal value) asserts that the code has actually reached that environment. Never set it for a PR that is merely open: auto-merge can be blocked indefinitely (a required rebase / `BEHIND` branch, failing checks, an unaddressed review), and the change may never land. Relabeling an issue `status:on-stg` on an open PR makes it *claim* a deploy that never happened. Transition only after confirming the PR merged.

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

@@ -257,6 +257,22 @@ If the canonical fix is merged but not yet present on the production branch, app
 
 This path is distinct from `BLOCKED`: ambiguity, open blockers, and duplicate-of-open findings remain held for human action and must not be auto-closed.
 
+#### 3c.2 Confirm applied learnings (last_confirmed bump)
+
+Run this at the end of 3c, after the lifecycle outcome is recorded and before 3d. It keeps the decay pass safe: a genuinely useful learning that keeps applying stays fresh, while dead weight ages out.
+
+1. **Identify which learnings demonstrably applied.** Resolve the learnings surface with `resolveProjectLearningsFile` and parse it with `parseLearningsFile` from `@codyswann/lisa/learnings` (never hardcode the path; a missing file skips this step silently). An entry counts as applied ONLY when its rule was explicitly cited or observably followed in this claim's plan, diff, or review responses — the plan quotes the rule or its id, or the diff does specifically what the rule mandates where the default behavior would have differed. **Presence in context is NOT application**: the ledger is loaded eagerly into every session, so counting "it was loaded" would confirm every entry on every claim and defeat decay entirely. A run that produced no plan or diff has nothing to confirm.
+2. **Bump each applied entry exactly once** via the surgical writer:
+
+   ```bash
+   node -e 'import("@codyswann/lisa/learnings").then(async m => { const r = await m.confirmLearningEntry(process.cwd(), process.argv[1], new Date().toISOString().slice(0, 10)); console.log(JSON.stringify(r)); }).catch(error => { console.log(JSON.stringify({ status: "error", id: process.argv[1], message: String(error) })); })' <entry-id> || true
+   ```
+
+   The invocation is failure-safe by construction: a rejected import or write resolves to a structured `error` result instead of a crash, and the trailing `|| true` absorbs any remaining non-zero exit (missing `node`, unresolvable package). Record an `error` or non-zero outcome in the cycle summary and continue — the bump must never abort the lifecycle.
+
+   `confirmLearningEntry` advances ONLY `last_confirmed` — rule text, why, provenance, `first_learned`, and confidence are untouched — and is idempotent within a claim: a repeat same-date bump returns `unchanged`, so an entry that applied repeatedly during one claim is bumped once, not once per application.
+3. **Never block on it.** A failed bump, an unwritable file, or a `not-found` result (the entry was pruned) is recorded under the cycle summary and the claim proceeds — shipping the ticket always outranks confirming a learning about it.
+
 #### 3d. Transition to $DONE (only after the PR is merged)
 
 A `done` env status (`On Dev`, `On Stg`, or the terminal value) asserts that the code has actually reached that environment. Never set it for a PR that is merely open: auto-merge can be blocked indefinitely (a required rebase / `BEHIND` branch, failing checks, an unaddressed review), and the change may never land. Setting `On Stg` on an open PR makes a ticket *claim* a deploy that never happened. Transition only after confirming the PR merged.

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

@@ -250,6 +250,22 @@ If the canonical fix is merged but not yet present on the production branch, app
 
 This path is distinct from `BLOCKED`: ambiguity, open blockers, and duplicate-of-open findings remain held for human action and must not be auto-closed.
 
+#### 3c.2 Confirm applied learnings (last_confirmed bump)
+
+Run this at the end of 3c, after the lifecycle outcome is recorded and before 3d. It keeps the decay pass safe: a genuinely useful learning that keeps applying stays fresh, while dead weight ages out.
+
+1. **Identify which learnings demonstrably applied.** Resolve the learnings surface with `resolveProjectLearningsFile` and parse it with `parseLearningsFile` from `@codyswann/lisa/learnings` (never hardcode the path; a missing file skips this step silently). An entry counts as applied ONLY when its rule was explicitly cited or observably followed in this claim's plan, diff, or review responses — the plan quotes the rule or its id, or the diff does specifically what the rule mandates where the default behavior would have differed. **Presence in context is NOT application**: the ledger is loaded eagerly into every session, so counting "it was loaded" would confirm every entry on every claim and defeat decay entirely. A run that produced no plan or diff has nothing to confirm.
+2. **Bump each applied entry exactly once** via the surgical writer:
+
+   ```bash
+   node -e 'import("@codyswann/lisa/learnings").then(async m => { const r = await m.confirmLearningEntry(process.cwd(), process.argv[1], new Date().toISOString().slice(0, 10)); console.log(JSON.stringify(r)); }).catch(error => { console.log(JSON.stringify({ status: "error", id: process.argv[1], message: String(error) })); })' <entry-id> || true
+   ```
+
+   The invocation is failure-safe by construction: a rejected import or write resolves to a structured `error` result instead of a crash, and the trailing `|| true` absorbs any remaining non-zero exit (missing `node`, unresolvable package). Record an `error` or non-zero outcome in the cycle summary and continue — the bump must never abort the lifecycle.
+
+   `confirmLearningEntry` advances ONLY `last_confirmed` — rule text, why, provenance, `first_learned`, and confidence are untouched — and is idempotent within a claim: a repeat same-date bump returns `unchanged`, so an entry that applied repeatedly during one claim is bumped once, not once per application.
+3. **Never block on it.** A failed bump, an unwritable file, or a `not-found` result (the entry was pruned) is recorded under the cycle summary and the claim proceeds — shipping the Issue always outranks confirming a learning about it.
+
 #### 3d. Relabel to $DONE (only after the PR is merged)
 
 A `done` env state (`status:on-dev`, `status:on-stg`, or the terminal value) asserts that the code has actually reached that environment. Never set it for a PR that is merely open: auto-merge can be blocked indefinitely (a required rebase / `BEHIND` branch, failing checks, an unaddressed review), and the change may never land. Relabeling an Issue `status:on-stg` on an open PR makes it *claim* a deploy that never happened. Transition only after confirming the PR merged.

package/plugins/lisa-cursor/skills/lisa-persist-learning/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: lisa-persist-learning
-description: This skill should be used when a candidate learning (from a failure signal, rejection, or debrief) needs to be judged and routed. It computes a stable fingerprint, runs the candidate through the hostile-default learning-judge gate, and performs exactly the verdict's side effects — a dropped-with-reason note on the triggering issue (drop), an upstream handoff marker (lisa-upstream), or a confidence-routed pull request that touches only the learnings surface (durable-learning). Idempotent via marker dedupe; headless-safe; never blocks the primary build flow.
+description: This skill should be used when a candidate learning (from a failure signal, rejection, or debrief) needs to be judged and routed. It computes a stable fingerprint, runs the candidate through the hostile-default learning-judge gate, and performs exactly the verdict's side effects — a dropped-with-reason note on the triggering issue (drop), an automatically filed upstream Lisa ticket with marker dedupe, evidence, and a per-run cap (lisa-upstream), or a confidence-routed pull request that touches only the learnings surface (durable-learning). Idempotent via marker dedupe; headless-safe; never blocks the primary build flow.
 ---
 
 # Persist Learning
@@ -62,20 +62,73 @@ The note is one line naming the classification (with its fixed plain-language gl
 |----------------|-------|
 | `one-off` | a one-time fluke, not a recurring pattern |
 | `misunderstanding/spec-gap` | traced to an unclear requirement, not a durable lesson |
-| `lisa-upstream` | root cause is Lisa itself; routed upstream |
+| `lisa-upstream` | root cause suspected in Lisa; routed for upstream attribution |
 
-(The `lisa-upstream` gloss is used by the handoff note below, not by a drop note.) Dedupe before posting: if any comment on the triggering issue already carries `[lisa-learning-drop] key=<fingerprint>`, do not post again — report the existing note.
+(A `lisa-upstream` classification never produces a drop note — it routes through the `handoff-upstream` flow below, whose step-1 note uses this pre-attribution wording because filing only happens after attribution confirms the Lisa surface.) Dedupe before posting: if any comment on the triggering issue already carries `[lisa-learning-drop] key=<fingerprint>`, do not post again — report the existing note.
 
 ### `handoff-upstream` (classification `lisa-upstream`)
 
-Emit the handoff marker only — file **nothing** (no upstream issue, no local rule; the upstream filing flow [SLL-5] consumes this marker later):
+This disposition completes the SLL-5 loop (#1583): on a Lisa-attributed failure the upstream Lisa ticket is filed **automatically**. Filing lives here — not in `lisa-attribute-failure` — because that skill is deliberately read-only (doctor delegates to it inside its own read-only contract), while this skill already owns exactly the verdict's side effects and the marker-dedupe discipline. Never persist a local rule for a Lisa-attributed failure; the host project's only durable trace is the brief linking note in step 6.
 
-```markdown
-<!-- [lisa-learning-upstream-handoff] key=<fingerprint> -->
-Upstream handoff (lisa-upstream — root cause is Lisa itself; routed upstream): <reason>. Nothing persisted locally; upstream filing is a separate flow.
-```
+1. **Post the handoff marker** on the triggering issue (same one-comment marker dedupe; the marker key is unchanged). The visible line must not claim a filing that has not happened yet — attribution and filing come after this step:
+
+   ```markdown
+   <!-- [lisa-learning-upstream-handoff] key=<fingerprint> -->
+   Candidate routed for upstream attribution (root cause suspected in Lisa): <reason>.
+   ```
+
+2. **Require a confirmed `lisa` verdict from `lisa-attribute-failure` — always.** Run the `lisa-attribute-failure` skill on the failure event before any filing. The judge's `cited_evidence` seeds the event (implicated files, surface in play, failure class) but never substitutes for the verdict — a path or commit reference alone is not attribution. File **only** when the skill returns a conclusive `lisa` verdict that names the Lisa surface with cited evidence. Any other outcome — `ambiguous`, `project`, or a verdict that cannot name a concrete Lisa surface — files **NOTHING** upstream: the candidate stays local and low-confidence, the run summary says attribution was inconclusive, and the step-1 note is resolved with one corrective follow-up comment on the triggering issue (marker-deduped so re-runs never repeat it; the suffix is distinct from the filing-failure marker in step 8 so one outcome never suppresses the other):
+
+   ```markdown
+   <!-- [lisa-learning-upstream-handoff] key=<fingerprint>-inconclusive -->
+   Attribution was inconclusive — nothing was filed upstream and nothing was persisted locally.
+   ```
+
+3. **Derive the root-cause key from the LISA SURFACE, never the host project or the local issue.** Two projects hitting the same Lisa bug MUST collide on the same key — that collision is the design (update, not duplicate):
+
+   ```text
+   root-cause-key = <lisa-surface>#<failure-class>
+   ```
+
+   - `<lisa-surface>` — the Lisa-relative path of the surface at fault (e.g. `plugins/src/base/skills/lisa-doctor/SKILL.md`, `typescript/copy-overwrite/.github/workflows/quality.yml`), or the canonical rule/skill/hook name when no single file applies (e.g. `lisa-doctor`, `block-no-verify`).
+   - `<failure-class>` — a short lowercase hyphen-slug for the class of failure (e.g. `pagination-truncation`, `stale-artifact-overwrite`).
+   - Normalize: lowercase, trim, collapse every whitespace run to a single `-`. The key must contain no host-project name, no local issue number, and no fingerprint — those vary per project and would defeat fleet-wide dedupe.
+
+4. **Enforce the per-run cap.** Resolve `hardening.maxUpstreamFilingsPerRun` from `.lisa.config.json` (default `5` — a conservative bound modeled on `lisa-repair-intake`'s `max_candidates` precedent). Count every upstream create **and** update this run performs; once the cap is reached, drop the remaining candidates and **note each dropped candidate visibly** (in the run summary, naming its root-cause key) — never queue a spam burst and never drop silently. A later run picks the dropped candidates up idempotently.
+
+5. **Evidence redaction (binding).** The upstream repo is PUBLIC by default (`hardening.upstreamRepo` → `CodySwannGT/lisa`) and this filing runs headless on crons — treat every drafted upstream body and comment as world-readable:
 
-Same one-comment marker dedupe on the triggering issue.
+   - Quote ONLY Lisa-owned surface text: template/rule/skill/hook excerpts and upstream commit references. The reproduction must be REDACTED — generic placeholders, never the host project's real values.
+   - Never paste host environment values, tokens/credentials, connection strings, API keys, PII (names, emails, customer data), or proprietary host code/payloads.
+   - The evidence chain names the Lisa surface and the failure class — never project payloads. When host context is essential to understand the failure, LINK the host-project issue instead of quoting it.
+   - Before filing or commenting, scan the drafted body for common secret shapes — `key=value` pairs with high-entropy values, token prefixes (`AKIA`, `ghp_`, `xox`), email addresses — and strip on match. When in doubt, leave it out: a thinner upstream ticket is recoverable; a leaked secret is not.
+
+6. **Dedupe by marker, then file or update.** The upstream marker is:
+
+   ```markdown
+   <!-- [lisa-upstream-attribution] key=<root-cause-key> -->
+   ```
+
+   Resolve the upstream repo from `.lisa.config.json` `hardening.upstreamRepo` (default `CodySwannGT/lisa`). Search **all issue states** for an existing issue carrying the marker — a closed marker-bearing ticket still owns this root cause, and searching only open issues would mint a duplicate the moment the original closes. Match on the **MARKER, never the title** — with the same eventual-consistency guard as above (`gh issue list -R <upstream> --state all --search '"<marker>" in:body' --json number,state,url`, and when the search index returns nothing, also `gh issue list -R <upstream> --state all --json number,state,body` and grep the bodies for the marker before concluding no ticket exists).
+
+   - **No existing ticket** → file via `lisa-github-write-issue` targeting the upstream repo, following the `lisa-rework-triage` "Filing upstream" discipline: a three-audience description (what failed for the operator, what the harness did wrong, what to change), the redacted evidence chain (Lisa-owned text only, per step 5: defect → Lisa surface → attribution evidence → redacted reproduction), the affected project named, and the `self-hardening` label. The body carries **exactly one** dedupe marker; **never write a markerless body** — it permanently breaks all future dedupe.
+   - **Existing ticket (open or closed)** → this is a repeat encounter: comment the new occurrence on the existing issue with this project's evidence, marker-deduped per occurrence via `<!-- [lisa-upstream-attribution-occurrence] key=<fingerprint> -->` so re-runs never duplicate the occurrence comment. Never open a second issue, and never match on the title — evidence compounds on one ticket. When the match is **CLOSED**, still comment the occurrence there and reference it in the local trace instead of filing a duplicate; do not reopen it yourself — recurrence evidence on a closed ticket signals the shipped fix may not cover this case, and reopening is the upstream maintainer's call.
+
+7. **Leave the local trace — a note, never a rule.** Post one follow-up comment on the triggering issue linking the upstream ticket:
+
+   ```markdown
+   <!-- [lisa-upstream-filed] key=<fingerprint> -->
+   Upstream ticket: <url> (root-cause key `<root-cause-key>`). No local rule persisted — the fix ships fleet-wide through Lisa.
+   ```
+
+   The learnings surface gains **no durable local rule** for a Lisa-attributed failure. Agents avoid the trap via the upstream ticket link until the fix ships.
+
+8. **Degrade gracefully.** If filing fails (auth, rate limit, network), report the failure in the run summary and continue shipping the host issue — a later run retries idempotently. Never block the primary build flow. So the step-1 note is not left dangling, post a marker-deduped corrective follow-up on the triggering issue — with its own suffix, distinct from step 2's `-inconclusive`, so an earlier inconclusive note can never suppress a filing-failure note (or vice versa):
+
+   ```markdown
+   <!-- [lisa-learning-upstream-handoff] key=<fingerprint>-filing-failed -->
+   Upstream filing did not complete — nothing was filed upstream and nothing was persisted locally; a later run retries.
+   ```
 
 ### `persist` (classification `durable-learning`)
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.239.0",
+  "version": "2.240.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"