@codyswann/lisa 4.34.7 → 4.34.9

package/plugins/lisa-copilot/rules/eager/settled-decisions.md

@@ -53,3 +53,23 @@ honored.
 When you take a settled decision, make it auditable in one clause — "auto-merge on, per your standing
 preference", "scoped app-wide, because the Android finding decides it". That gives the operator the
 chance to correct it without requiring them to answer first.
+
+## Before you escalate, re-read the instruction file from disk
+
+**This rule is delivered at session start; the re-read it demands happens at the escalation
+boundary.** Re-reading at session start would re-read the same moment your context was built from
+and buys nothing.
+
+So before you form an escalation, hand a decision back, or re-open a question that may already be
+settled: **open `AGENTS.md` (or `CLAUDE.md`) from disk and read its `## Standing rulings` section.**
+If the file has no such heading, re-read the file.
+
+The instruction is to open the file — not to "check whether your context looks complete", because
+**context completeness is not observable from inside.** An instruction file is injected at session
+start and can arrive shortened, and the cut can land on a clean section boundary, where a truncated
+document is indistinguishable from one that never had that section: your copy ends tidily, so you
+conclude you read all of it. Rulings are also written *after* sessions begin — your copy is a
+snapshot of the moment you started, and nothing tells you when it stops being current.
+
+This is a **pointer, not a copy**. It stays correct as rulings accumulate, and it survives a
+shortened copy of the file it points at precisely because it does not travel inside that file.

package/plugins/lisa-copilot/rules/reference/rejection-detection.md

@@ -162,3 +162,72 @@ Naming the decline date, the recurrence date, and the recurrence reference in bo
 ### Concurrency honesty
 
 The search-then-write here is **not** an atomic claim: two truly concurrent runs can each miss the other's in-flight proposal and file a transient duplicate. It therefore guarantees **convergence, not mutual exclusion** — the duplicate is found and closed by the next run's marker search, and because the key is a stable content hash, a duplicate never multiplies. State this rather than implying a lock; a cross-run locking protocol would be disproportionate to the risk.
+
+## Automation-reversal memory (repair-side — a human undoing a transition this flow made)
+
+Both sections above remember something a **human or QA did to work**: claim-time memory reads an item bounced backward through the review lanes; proposal-time memory reads a proposal closed as *not planned*. This third section remembers something a human did **to the flow itself** — an automated repair moved an item's lifecycle role, and a human moved it straight back.
+
+Every loop that writes a lifecycle role as a **repair** rather than as a claim consults this section before re-making a transition. `lisa-repair-intake` is the first consumer and the skill this contract was written from.
+
+The failure it exists to stop is not forgetfulness, it is **inversion**. A loop with a state-only recurrence brake reads the human's revert as *changed state*, and changed state is normally a reason to look again — so the correction becomes the trigger. That inverts the assumption every operator brings to an unattended fleet: the more promptly a reviewer undoes a wrong transition, the sooner it comes back. A mechanism in which human correction is indistinguishable from new state converts your best reviewers into the loop's most reliable trigger.
+
+### Why this is a third classification, not a wider `rejection-reclaim`
+
+`rejection-reclaim` is anchored on the **ready** lane — an item that reached a `review`/`done`-ward lane and is now back in `$READY`. A reversed repair lands in the **blocked** lane instead: automation moved `$BLOCKED → $READY`, and a human moved it back to `$BLOCKED`. Widening `rejection-reclaim` to cover that would fire it on a lane it was never written for, and its response is wrong for this case anyway — reflecting on rejection evidence and handing it into a re-implementation is what you do when the work was rejected, not when a human said *stop doing that*. The two are **orthogonal** and are **never merged into `rejection-reclaim`**: one teaches a re-implementation, the other withdraws a decision.
+
+### Seam — before any lifecycle write, not at claim
+
+Detection runs at the **top of the repair walk for each candidate item, BEFORE the loop writes any lifecycle role**. The reasoning is the claim-time seam's: a write overwrites the current lane, and the signal depends on reading the current lane against history. Detection is a pure read — idempotent, headless-safe, no side effects.
+
+### Classification
+
+Detection is a pure read of the item's transition history **and its authorship** (via the vendor access layers). It returns exactly one:
+
+| Classification | Condition |
+|---|---|
+| `automation-reversal` | History shows a lifecycle role change **authored by** this flow, and a later **backward** move of that same role **authored by** a human, with no automation move after it. |
+| `no-reversal` | History shows no such pair — the flow made no prior transition, or its transition still stands, or the later move was itself automation. |
+| `unknown` | The vendor history query failed, was inconclusive, or **did not expose authorship**. |
+
+### Authorship is the whole signal — a backward move alone proves nothing
+
+The state-only reading is what fails today, so a backward move is **not** sufficient: an item can return to `$BLOCKED` because a genuine new blocker appeared, which is the world moving on and is a legitimate reason to look again. What distinguishes a correction is **who moved it, and against what**. Read authorship from the same history surfaces:
+
+- **GitHub** — timeline `LabeledEvent` / `UnlabeledEvent` nodes carry an `actor`; read them through `lisa-github-read-issue`'s Label-Event History surface.
+- **JIRA** — `lisa-atlassian-access operation: changelog key:<K>`; each changelog entry carries an `author` alongside its `from`/`to` status items.
+- **Linear** — `lisa-linear-access operation: history id:<ID>`; each history node carries an `actor` alongside `fromState` / `toState`.
+
+An actor is **this flow** when it is the configured automation identity, or when the flow's own marker note (`[lisa-repair-intake]`) sits at that transition's timestamp. Any other actor is a human. Where the surface does not expose an actor at all, the result is `unknown` — never an assumed human.
+
+**A marker and a transition on the same item say nothing until you know their order.** A hold label, a comment and a lane move routinely coexist on a reversed item, and co-occurrence reads equally well in both directions — a label applied *before* a transition guards it, the same label applied *after* records that the transition was undone. Sourcing the facts, attributing them correctly and reading the artifact all pass cleanly on an invented sequence; only ordering disconfirms it. Compare timestamps explicitly and treat an unorderable pair as `unknown`.
+
+### Lane names are configuration here too
+
+The lanes compared ALWAYS come from `.lisa.config.json` — `github.labels.build.blocked` and `github.labels.build.ready` on GitHub, the JIRA status and Linear state equivalents — resolved per `config-resolution` against the `src/sync/registry.ts` `BUILD_LABEL_DEFAULTS` (`blocked: status:blocked`) fallback. **Never hardcode** a lane string; a project that renames its blocked lane must still detect reversals.
+
+### Never block the sweep
+
+`unknown` is a first-class result here exactly as it is at claim time, but the safe direction is the opposite one and must be stated so it is not "simplified" later. At claim time an unreadable history degrades to *implement the item anyway*, because reflection is a bonus. Here an unreadable history degrades to **neither a reversal nor a clearance**: the item is evaluated by the loop's normal rules, unchanged, and the run **never blocks the sweep** on a failed detection. `unknown` must not be read as "no reversal, proceed to re-attempt" any more than as "reversal, suppress" — it removes the signal, it does not supply one.
+
+### Learning-loop exclusion
+
+The same learning-loop exclusion applies, for the same reason and by the same markers: an item carrying `[lisa-learning-drop]`, `[lisa-learning-pr]`, `[lisa-learning-upstream-handoff]` or the `learning:needs-triage` label is never classified `automation-reversal`, no matter how it moved. The flow must not remember being corrected about its own learning artifacts.
+
+### The rule — a reversal raises the bar, it never resets the clock
+
+On `automation-reversal`:
+
+1. **Do not re-apply the classification that was reversed.** The reversal is the strongest available evidence that the classification was wrong, and re-deriving it from the same facts reaches the same wrong answer.
+2. **Leave the item where the human put it** and ensure the `human_needed` marker is present. A decision that was overturned needs a person, not another cycle.
+3. **Name it in the run record** — the reversed transition, and the classification that produced it. A suppression nobody can see is indistinguishable from a loop that found nothing.
+4. **Re-attempt only on evidence that postdates the reversal** — a blocker state change, or a human comment supplying what was missing. This mirrors the re-proposal rule the proposal half already enforces: the memory is durable, not permanent, and new evidence reopens it. Cite that evidence in the run record.
+
+A changed lifecycle role is therefore **no longer sufficient on its own** to warrant a fresh attempt. The consuming loop's recurrence brake must be able to tell "the state changed because the world moved" from "the state changed because a human undid me", which means carrying **authorship and an overturn bit**, not state alone.
+
+### The fix is signed per path — do not apply one sign globally
+
+This is the trap in implementing this section, and it will not be caught in review because the wrong version reads as tightening.
+
+On a **repair-transition** path, human activity must **stop** being a warrant to re-attempt — that is this whole contract. On a **staleness** path, a human comment is counted as forward progress and *suppresses* action, which means an objecting comment already protects the item. That protection is correct and a global "human activity no longer counts" switches it off while everyone believes a hole was closed.
+
+So: apply the inversion **only** where the loop is deciding whether to re-make a transition. Leave every keep-alive and staleness reading exactly as it is. Any consumer of this section states which of its paths are signed which way.

package/plugins/lisa-copilot/rules/reference/settled-decisions.md

@@ -27,3 +27,13 @@ Asking after the research answered the question is also a violation. When gather
 ## Reporting
 
 Record settled decisions in a short clause, such as "auto-merge on, per standing preference" or "scoped app-wide, because the Android finding decides it." This gives the operator a chance to correct the decision without requiring an avoidable question first.
+
+## Re-read the instruction file from disk before escalating
+
+This rule is delivered at session start; the re-read it requires happens at the escalation boundary. Re-reading at session start would re-read the same moment the context was built from.
+
+Before forming an escalation, handing a decision back, or re-opening a question that may already be settled, open `AGENTS.md` (or `CLAUDE.md`) from disk and read its `## Standing rulings` section. If the file has no such heading, re-read the file.
+
+The instruction is to open the file rather than to assess the context, because context completeness is not observable from inside. An instruction file is injected at session start and can arrive shortened, and a cut landing on a section boundary is indistinguishable from a document that never carried that section. Rulings are also written after sessions begin, so an injected copy is a snapshot of the moment the session started.
+
+This is a pointer, not a copy. It stays correct as rulings accumulate and survives a shortened copy of the file it points at, because it does not travel inside that file.

package/plugins/lisa-copilot/skills/lisa-drive-pr-to-merge/SKILL.md

@@ -41,6 +41,11 @@ merges" loop. Other skills delegate here instead of re-implementing it. Runs
   green, open, un-merged PR is the *success* outcome of this mode, not a hang.
   Used by learning-persistence flows whose low-confidence PRs must wait for a
   human (`lisa-persist-learning`).
+
+  **`auto_merge` is caller-time and nothing re-reads it.** That is what the hold
+  label (section 0) exists for: the same behaviour, raisable by anyone at any
+  point while the loop runs. Both routes land in `awaiting-human`; they differ
+  only in who can take them and when.
 - `on_blocker=<fix|report>` — what to do when a blocker needs code or review work.
   Default `fix`.
   - **`fix`** (the full loop): resolve conflicts, fix failing checks, address +
@@ -97,9 +102,115 @@ gh pr edit <pr> --add-label "lisa:babysitter-on-duty"
 closed, or a hard block handed to a human. A crashed session that never
 releases is why the TTL exists; do not rely on it as the normal release path.
 
+### The hold gate — a stop anyone can raise
+
+Section 0 owns this skill's two PR labels: the lease it **writes** to declare
+ownership, and the hold it **reads** to be told to stop. Same mechanism, pointed
+at different things — a lease is a claim, a hold is a decision.
+
+**The label** is `lisa:hold` by default, overridable per project at
+`github.labels.merge.hold`, resolved local-over-global like every other
+configured name. Resolve it ONCE at startup and reuse the resolved string; a
+name re-resolved each iteration can change identity mid-loop for no reason a
+reader could reconstruct afterwards.
+
+```bash
+HOLD_LABEL=$(
+  jq -r 'first(.github.labels.merge.hold | strings)' \
+    .lisa.config.local.json .lisa.config.json 2>/dev/null | head -n1
+)
+HOLD_LABEL="${HOLD_LABEL:-lisa:hold}"
+```
+
+**What it means:** exactly `auto_merge=false`, for as long as it is present. Not
+a new concept and not a new terminal state — the same disarm, the same
+fail-closed re-read, the same `awaiting-human` landing. The only new surface is
+one label read.
+
+**Why it exists.** `auto_merge` is decided by the caller at invocation, and
+nothing re-reads it, so the only person who can stop the merge is the person who
+started it. Anyone else — a reviewer who opens the PR while the loop is driving
+it, someone holding a PR another session armed — has no lever and loses the
+race. Measured (#3558): four explicit `gh pr merge --disable-auto` calls were
+each followed by a re-arm 7–25 seconds later, and the PR merged two seconds
+after its final check went green. **The hold did not fail; it lost a race.** A
+signal the loop itself reads cannot be raced, because the loop is what reads it.
+
+#### Evaluate it in two places, and re-read it every iteration
+
+- **Before arming** (section 1) — a PR already carrying the label is never armed.
+- **On every watch-loop iteration** (section 2), before acting on any blocker.
+
+Re-reading is the entire point. A check that runs once at startup is a
+caller-time signal wearing a loop's clothing and fixes nothing, because the case
+that matters is a label applied **after** the loop is already running. If you
+are changing this and it is convenient to read the label once, you have
+reintroduced the defect.
+
+```bash
+gh pr view <pr> --json labels --jq "[.labels[].name] | index(\"$HOLD_LABEL\") != null"
+```
+
+**Match the resolved name exactly — never a prefix.** `lisa:babysitter-on-duty`
+is a label this skill applies to itself and shares the `lisa:` prefix; a
+prefix match would make the loop stop on its own lease, which is a deadlock
+that looks like a human decision.
+
+#### When held
+
+1. Run the existing `auto_merge=false` disarm (section 1) — disable the latch
+   once and prove with the fail-closed re-read that it took.
+2. Return `awaiting-human:held` (section 4).
+3. **Do not remove the label.** Removing a human's signal is unrecoverable from
+   inside the loop; leaving a stale one costs a cycle and is visible. Only
+   whoever applied it takes it off, and a later invocation then resumes normally.
+
+Do not keep polling while held. Held is terminal for this run, not a pause to
+wait out — the loop has been told a human is looking, and continuing to drive is
+the behaviour the label exists to stop.
+
+**The disarm is once and terminal: never re-arm the latch afterwards, and never
+resume driving in the same run.** This is what keeps a hold compatible with the
+armed-across-fix-pushes rule in section 1, which otherwise forbids disarming on
+the `auto_merge=true` path. That rule exists to prevent a *race* — disarm, then
+re-arm, repeatedly, while still driving — and a hold does neither half of it: it
+turns the latch off exactly once and then stops. A hold that re-armed, or that
+kept driving afterwards, would be the race that rule names, wearing a label.
+
+#### When the read fails
+
+**Fail toward hold.** The asymmetry decides it: a false hold costs one cycle and
+is visible in a terminal report someone can act on, while a false no-hold merges
+past a human's objection and cannot be undone. Where the two errors are
+unequal, take the recoverable one.
+
+But a read that keeps failing must not become a silent deadlock, so the failure
+is **reported as its own outcome** rather than dressed up as a decision:
+
+- retry the read once;
+- if it still fails, disarm as above and return **`awaiting-human:hold-unknown`**,
+  naming the error.
+
+`awaiting-human:held` and `awaiting-human:hold-unknown` are different facts and
+an operator needs to know which: the first says *a human stopped this*, the
+second says *I could not tell whether a human stopped this.* Collapsing them
+would hide a broken permission behind a human decision, and nobody would ever
+look.
+
+**A PR with no hold label is driven exactly as it is today.** This gate adds a
+stop; it does not add a block. If the label is absent and the read succeeded,
+nothing about the run changes.
+
 ## 1. Enable auto-merge
 
-**Gate: only when `auto_merge=true` (the default).** When `auto_merge=false`,
+**Gate: the hold label is absent (section 0's hold gate), and `auto_merge=true`
+(the default).** Evaluate the hold gate BEFORE anything in this section,
+including the arm gate below and the direct-merge capability fallback: a held PR
+is not armed, not merged directly, and not driven — it disarms once and returns
+`awaiting-human:held`. Checking after arming would authorise the merge the label
+exists to prevent, which is the same ordering error the arm gate itself fixes.
+
+When `auto_merge=false`,
 skip the enable step and its capability fallback — do not enable auto-merge,
 and do **not** use the capability fallback below: on a repo that disallows
 auto-merge, an `auto_merge=false` PR must stay OPEN for human triage, never be
@@ -357,6 +468,12 @@ Poll the live state each iteration:
 gh pr view <pr> --json state,mergeStateStatus,mergeable,reviewDecision,statusCheckRollup,headRefName,baseRefName
 ```
 
+**Re-read the hold label on every iteration, before handling any blocker**
+(section 0's hold gate). It is polled separately from the line above rather than
+folded into it, because `labels` is not part of the blocker state: the hold is a
+question about whether to keep going at all, asked before the blocker questions,
+and a run that answers it once at startup has not implemented it.
+
 Handle every blocker class; after any fix, re-poll and continue. Do not stop while
 the PR is still open and progress is possible. On each iteration, refresh the
 babysitter lease if its last stamp is older than ~30 minutes (section 0).
@@ -393,6 +510,13 @@ and return per the input contract above. That includes (f): adjudicating a pendi
 auto-fix PR (merging, closing, or deleting its branch) is destructive work, not
 diagnosis — return its classification (`blocked:pending-auto-fix`) instead.
 
+**The hold gate binds in report mode too**, and it binds first: a held PR
+returns `awaiting-human:held` without arming, without the mechanical step (a)
+nudge, and without an `update-branch`. Hold is not a blocker classification and
+never returns as one — `blocked:*` says *this PR cannot proceed yet*, while a
+hold says *someone asked me not to proceed*, and reporting the second as the
+first would file a human's decision as a defect for something else to clear.
+
 The arm gate binds in report mode too, and this is the mode where forgetting it
 does the most damage: a diagnose-only run that arms the latch has not diagnosed
 anything, it has authorised a merge. Under a vacuous review context, report mode
@@ -938,6 +1062,22 @@ Loop until one of:
   merge but nobody reviewed it: the review tool says it skips public
   repositories, and that will not change on its own. Merge it yourself or ask
   for a human review."*
+- **`awaiting-human:held`** → success, and the only terminal state a person can
+  cause on purpose from outside the run. The hold label (section 0) was present,
+  the latch was disarmed once and the re-read proved it, and the label was left
+  in place. Report the PR URL, the resolved label name, and that removing the
+  label lets a later invocation resume — for example: *"PR #123 is on hold:
+  someone added the `lisa:hold` label, so I stopped instead of merging it.
+  Remove that label when you want it to continue."* Not a stall and not a
+  failure: a human asked for the PR to stop, and it stopped.
+- **`awaiting-human:hold-unknown`** → the hold label could not be read (twice),
+  so whether a human asked for a stop is **unknown**. The latch is disarmed and
+  the PR sits OPEN, on the fail-toward-hold rule in section 0. Report the read
+  error verbatim. This is deliberately NOT reported as `awaiting-human:held`:
+  that would file a broken permission or a rate limit as a human decision, and
+  the one thing nobody would then do is investigate it. Usually a missing
+  `issues: read` / label-read permission, which is fixable and invisible from
+  the merge outcome alone.
 - **`CLOSED`** → report (PR was closed without merge).
 - **Hard block needing a human**: an unresolvable conflict, a failing check that
   needs design input, or genuine unresolved human objection (not a bot gate). Stop

package/plugins/lisa-copilot/skills/lisa-git-submit-pr/SKILL.md

@@ -48,6 +48,8 @@ Recognized optional hints:
 
    This delegation is now load-bearing rather than a convenience: it is the only path that arms auto-merge, so skipping it leaves the PR open rather than quietly merging it. Reporting submission as complete without invoking it is a failed submit, not a partial one — say so instead of implying the PR is on its way to merged.
 
+   **The hold label needs no check here, and adding one would be dead code.** `drive-pr-to-merge` evaluates its hold gate before it arms anything, so a PR created with the label already on it is never armed — by the delegation, not by a second check in this skill. That guarantee used to require one: while step 5 armed the latch at creation, a hold that covered only the loop left the creation-time arm wide open, which is why CodySwannGT/lisa#3558 asked for a check in both places. Step 5 no longer arms, so there is nothing here for a label to gate. If you are adding one because the ticket says to, re-read step 5 first.
+
 ### Native Development Linkage
 
 Add provider-appropriate linkage to the PR title and/or body without changing the status lifecycle:

package/plugins/lisa-copilot/skills/lisa-repair-intake/SKILL.md

@@ -186,7 +186,9 @@ rule — never hardcode status/label strings. The relevant repair roles:
 
 In addition to the lifecycle roles above, the build lifecycle defines the **`human_needed` marker** — an additive label (`jira.labels.human_needed` / `github.labels.build.human_needed` / `linear.labels.build.human_needed`, default `Human Needed` / `human-needed`) that rides alongside `blocked` when the block needs human-only input no agent or retry can supply (see `config-resolution` "Build markers"). repair-intake's interaction with the marker is asymmetric and is the whole point of the distinction below:
 
-- The blocks repair-intake **itself writes** are the auto-recoverable kind — it files a build-ready fix ticket and moves the item `blocked` *blocked by that ticket*, expecting the next cycle to self-heal. Those are **not** `human_needed`; if such an item arrives already carrying a stale `human_needed` marker, repair-intake **clears** it (the block is no longer waiting on a human).
+- The blocks repair-intake **itself writes** are the auto-recoverable kind — it files a build-ready fix ticket and moves the item `blocked` *blocked by that ticket*, expecting the next cycle to self-heal. Those are **not** `human_needed`; if such an item arrives carrying a `human_needed` marker **this skill applied on an earlier cycle**, repair-intake **clears** it (the block is no longer waiting on a human).
+- **Never remove a `human_needed` marker this skill did not apply.** "Stale" is a judgment about the block's kind, not about who applied the marker or when — so without this rule an operator's deliberate hold, applied *after* correcting a wrong transition, is indistinguishable from a leftover the sweep is designed to clear, and gets swept. Establish provenance from the label event's actor (`rejection-detection` **Automation-reversal memory** reads the same surfaces); if provenance is not readable, **leave the marker in place**. Removing a human's hold is unrecoverable within the loop; leaving a stale one costs a cycle and is visible.
+- The marker is consulted **before **any** repair transition**, not only before Class C. Class C's hard stop is the strictest reading of it, but a marker that is honoured on one classification path and ignored on the other three is not a guard — and Class A, dependency clearing, is exactly the path an operator reverting a wrongly-cleared blocker is trying to protect. Match it robustly (hyphen/underscore, case-insensitive, label set and note prose) wherever it is read.
 - The blocks the **vendor agent** writes when repair-intake re-dispatches it (its pre-flight gate) carry `human_needed` already — the agent owns that marker. repair-intake leaves it in place.
 
 Resolve with the standard role-read pattern (local overrides global, default fallback):
@@ -305,6 +307,16 @@ Apply per candidate. Continue through the ordered list until every candidate ins
 native close/archive/complete, re-dispatch, or refreshed note), be recorded read-only, or be
 recorded under Errors. Do not stop after the first write; the cap is the batch boundary.
 
+**Before any lifecycle write on a candidate, classify it for `automation-reversal`** per
+`rejection-detection` **Automation-reversal memory** — a role change this skill made that a human
+then moved back. This runs once per candidate at the top of the walk, ahead of the branches below,
+because it wraps every repair path rather than belonging to one: a reversed rollup reconciliation
+involves no dependency link at all, and a reversed Class-B re-check is the same shape as a reversed
+Class-A clearing. Detection is a pure read and `unknown` **never blocks the sweep** — an item whose
+history or authorship cannot be read is judged by the normal rules below, treated as neither a
+reversal nor a clearance. A candidate classified `automation-reversal` skips the branches below and
+is handled per Loop prevention.
+
 ### Build `claimed` (stalled in-progress) → diagnose blocker, else resume in place
 
 **First check for an already-merged PR — this check is NOT gated on staleness.** Read the item's
@@ -478,9 +490,13 @@ re-issued against an unchanged conflicting head.
    new fix ticket (vendor-native: JIRA issue link `is blocked by`; GitHub/Linear `Blocked by:` line
    + label). Post a `[lisa-repair-intake]` note naming what it is blocked by and why. This block is
    **auto-recoverable** — the fix ticket will build and close on its own — so do **not** add the
-   `human_needed` marker, and if the item already carries a stale `human_needed` label, remove it
-   here (it is no longer waiting on a human). The `human_needed` marker is reserved for blocks a
-   human must clear; this one a later cycle clears automatically.
+   `human_needed` marker, and if the item carries a `human_needed` label **this skill applied on an
+   earlier cycle**, remove it here (it is no longer waiting on a human). The `human_needed` marker
+   is reserved for blocks a human must clear; this one a later cycle clears automatically.
+   **A marker this skill did not apply is never removed here** — see the marker's provenance rule
+   above. The block's kind says the *block* self-heals; it says nothing about why a human put a
+   hold on the item, and an operator's hold applied after correcting a wrong transition looks
+   identical to a leftover unless provenance is checked.
 3. **Record it** as a repair write. Do **not** dispatch the vendor agent for this item this cycle.
 
 The item now sits in `blocked`; once the fix ticket reaches a terminal state, the **Build
@@ -1026,6 +1042,14 @@ layer, and test ancestry against the remote.
   "no PR found" is `no-pr` and stays blocking.
 - **Human override** — an explicit human statement on this item that the dependency is satisfied
   clears it and outranks a failed containment check. Name it in the run record.
+- **Human hold** — the override runs in both directions. `human_needed` is checked here as well as
+  in Class C: an item carrying it is left `blocked` and recorded `skipped: human_needed`, without
+  running the containment check. Class A is the path an operator reverting a wrongly-cleared
+  blocker is protecting, so a marker honoured only on Class C is not honoured where it is most
+  often meant. Match it robustly (hyphen/underscore, case-insensitive, label set and note prose).
+  Symmetrically, an explicit human statement that the dependency is **not** satisfied keeps the
+  item blocked and outranks a *passing* containment check — the contract has an input channel for
+  "you may now proceed" and it needs one for "your reasoning was wrong".
 
 **A lifecycle status name is never the test.** `done`, `on-stg`, `on-dev` and `code-review` are
 labels that correlate with containment in a single-trunk workflow and come apart from it in a
@@ -1139,12 +1163,33 @@ cron tick.
   self-block** (so a human filling in one of several missing sections changes the fingerprint and
   triggers a re-check next cycle, rather than being suppressed as a no-op), terminal/open state,
   rollup child tally, and a timestamp.
+- The fingerprint also carries **authorship and an overturn bit**: the actor class of the most
+  recent lifecycle role change (`automation` / `human` / `unknown`), and whether that change
+  **reversed** a transition this skill made — the `automation-reversal` classification from
+  `rejection-detection` **Automation-reversal memory**. Without these the fingerprint records only
+  *what* the state is, never *who* set it or *whether the last automated decision was overturned*,
+  and those are the only fields that separate "the world moved on" from "a human told me I was
+  wrong".
 - Before writing a note or re-attempting a `blocked` item, compute the current fingerprint. If
   an identical fingerprint was already posted within the **backoff window**, skip the item
   silently (record as `still_blocked` / `active`, no write).
 - Backoff window default = `stale_after` (2h). `force=true` bypasses backoff for a manual run.
-- A *changed* fingerprint (new blocker state, new answers, new verdict) always warrants a fresh
-  note + re-attempt — backoff suppresses only no-op repeats.
+- A *changed* fingerprint (new blocker state, new answers, new verdict) warrants a fresh note +
+  re-attempt — backoff suppresses only no-op repeats.
+- **A change whose only cause is a human overturn is not a warrant.** Where the overturn bit is
+  set and no evidence postdates the reversal, the changed fingerprint is **not on its own a
+  warrant** to re-attempt: do not re-apply the reversed classification, leave the item where the
+  human put it, ensure `human_needed`, and record the outcome naming the **reversed transition**
+  and the classification that produced it. Re-attempt only on evidence postdating the reversal —
+  a blocker state change or a human comment supplying what was missing — cited in the run record.
+  Without this qualifier the revert *itself* changes the fingerprint and releases backoff, so the
+  faster a reviewer corrects a wrong transition, the sooner it returns.
+- **This inversion is signed per path.** It applies to the paths that decide whether to re-make a
+  lifecycle transition — Class A/B/C/D clearing and rollup reconciliation. It does **not** touch
+  the staleness model: there a human comment counts as forward progress and resets the staleness
+  clock, so an objecting comment already makes the item look active and this skill leaves it
+  alone. That reading is protective; a single global "human activity no longer counts" would
+  switch it off while reading like a tightening.
 
 ## Lifecycle ownership guard
 
@@ -1261,6 +1306,12 @@ Report outcomes in these buckets:
 - `normalized_ready` — GitHub issues missing official lifecycle labels that were classified and
   given the configured PRD/build `ready` label so normal intake can claim them.
 - `still_blocked` — examined and intentionally left `blocked`, with the active reason.
+- `reversal_suppressed` — a repair this skill previously made was reversed by a human, so the
+  classification was **not** re-applied. Name the **reversed transition** (role, direction, and
+  when), the classification that produced it, and that the item now carries `human_needed`. This
+  bucket is never merged into `still_blocked`: "I declined to act because I was overruled" and "I
+  examined it and the blocker stands" are different facts about the loop, and only the first tells
+  an operator their correction was received.
 - `active` — skipped because current work is not stale (or within backoff).
 - `errors` — items that failed evaluation, with the error.
 
@@ -1280,7 +1331,7 @@ to each item* — the two never merge in the one-line summary.
 | Nothing actionable — the idle case (walk step 5): examined N, all active or in backoff — including a fix ticket suppressed by a prior decline (`rejection-detection` **Proposal rejection memory**), which the summary names in its suppression count | `nothing-needed` |
 | Repairs applied **and confirmed** this cycle — `resumed` / `resynced` / `recovered` / `unblocked` / `closed_out` / `rolled_up` / `relinked` / `normalized_ready` | `change-proved` |
 | Repair produced new work for a human to pick up — e.g. an unmergeable PR or failed deploy filed as a **build-ready fix ticket** and left `blocked` | `candidate-proposed` |
-| A repair reached an autonomy boundary needing a human (a protected-deploy approval before it can proceed) | `approval-requested` |
+| A repair reached an autonomy boundary needing a human (a protected-deploy approval before it can proceed), **or a repair this loop previously made was reversed by a human** and is therefore suppressed and escalated to `human_needed` (`reversal_suppressed`) rather than re-attempted | `approval-requested` |
 | The loop itself could not run — the queue is unreadable, tracker credentials are revoked, or an open-and-closed rejection-memory / blocker-marker search is unreadable and therefore must not fall through to `nothing-needed` | `recovery-required` |
 | The runbook's **Retirement condition** tripped | `policy-obsolete` — **never reached by design for this loop** (see Retirement evaluation below) |
 
@@ -1343,6 +1394,12 @@ stuck work accumulates), or interleaved on a longer cadence.
   do."
 - Never re-dispatch a `blocked` build item unless every parsed blocker is cleared (conservative
   dependency clearing).
+- Never re-make a transition a human reversed. Classify every candidate for `automation-reversal`
+  before any lifecycle write (`rejection-detection`), and on a hit leave the item where the human
+  put it with `human_needed`, naming the reversed transition in the run record. Re-attempt only on
+  evidence postdating the reversal.
+- Never remove a `human_needed` marker this skill did not apply, and consult the marker before
+  **any** repair transition rather than only before Class C.
 - Repair every materially actionable candidate inside the `max_candidates` cap; default cap is 100.
 - Default GitHub `intake_mode` is `both` when both PRD and build namespaces exist.
 - Honor the backoff window — never re-post an identical `[lisa-repair-intake]` note within it

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

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