@codyswann/lisa 4.55.4 → 4.55.6

package/plugins/lisa-copilot/skills/lisa-learnings-audit/SKILL.md

@@ -285,7 +285,7 @@ resolved by reading the ticket, never by filing a sibling blind. Then:
 - **Closed via merged work** → done; a genuine regression later is new
   evidence and a new ticket.
 - **Closed unmerged / rejected** → the human declined. **Do NOT re-file**
-  unless new evidence **postdates the rejection** — and when re-filing, state
+  unless new evidence **postdates the rejection** and materially changes the consequence, requirement, or risk that justified the decline — and when re-filing, state
   the postdating evidence explicitly in the ticket ("rejected <date>; recurred
   <date> in <ref>"). Closed-as-rejected tickets ARE the gardener's memory of
   declined recommendations.
@@ -413,7 +413,7 @@ automation, through `lisa-tracker-write` (per `tracked-work` +
   visible prose line; matched on the marker, never the title; searched **open
   AND closed** per `rejection-detection`'s **Proposal rejection memory**. Treat
   matches by close state: **open** suppresses another proposal; **Not planned**
-  suppresses another proposal unless new evidence postdates the rejection;
+  suppresses another proposal unless new evidence postdates the rejection and materially changes the consequence, requirement, or risk that justified the decline;
   **Completed** means the prior approved action happened, so a later recurrence
   may be re-filed. The `[lisa-gardener]` search above stays what it is — the
   candidate evidence, not the dedupe key. When an existing proposal suppresses

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

@@ -344,6 +344,9 @@ This gate never blocks a legitimate flat Task/Bug: those have no open children a
 
 #### 3b. Claim
 
+Before the claim mutation, apply `claim-time-guards` — **Value before claim**, or **Worth doing** in `lisa-track` on runtimes without the rule tree (Antigravity). A ready label establishes neither value nor permission to expand scope. Respect the preceding human-hold gate; a declined incidental item consumes this cycle's one processed disposition.
+
+
 **Rejection detection runs first — before the transition below.** Per the vendor-neutral `rejection-detection` rule (cite the slug; do not restate its classification table), classify this Issue at the **top of 3b, BEFORE** the `$READY → $CLAIMED` transition — afterwards the current-lane signal is gone. Read the Issue's history via `lisa-linear-access operation: history id: <ISSUE-ID>`, keyed on **workflow-state** history, and classify it `rejection-reclaim | forward-only | never-left-ready | unknown` (a `rejection-reclaim` is a move back into `$READY` from a later lane). State names come from `.lisa.config.json`, never hardcoded.
 
 > Reading state history is strictly simpler than the label history this used to key on: `IssueHistory` inlines `fromState.name` / `toState.name` on each node, so the transition is read directly with no label-ID resolution against `list-issue-labels` and no reconstruction from `addedLabelIds`/`removedLabelIds` deltas. That reconstruction was lossy — the deltas carry no prior/next full set — which is one more reason the build lane moved to states. A failing/absent history yields `unknown` and the claim proceeds — detection never blocks the build. Issues carrying a learning marker (`[lisa-learning-drop]` / `[lisa-learning-pr]` / `[lisa-learning-upstream-handoff]`) or the `learning:needs-triage` label are never rejection triggers (no learning-about-learning). Carry the classification into the transition and lifecycle below.

package/plugins/lisa-copilot/skills/lisa-linear-write-issue/SKILL.md

@@ -6,6 +6,12 @@ allowed-tools: ["Bash", "Skill"]
 
 # Write Linear Work Item: $ARGUMENTS
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
+## Before creating incidental work
+
+Apply `do-it-now`'s **Worth doing** guidance before drafting a new incidental item. Decline low-value observations without writing a ticket or requesting a human gate; report the reason briefly to the caller. A complete spec is not evidence of value. This does not cancel explicit user requests or accepted requirements. Honor prior Not planned decisions through `rejection-detection`, including legacy issues without markers. Accepted work continues through the existing validation and readiness contract below.
+
 ## Human-gate release authorization
 
 A release requires a trusted human author, not just matching comment text. Follow

package/plugins/lisa-copilot/skills/lisa-monitor/SKILL.md

@@ -200,7 +200,7 @@ watching it. Evaluate all three. When all three hold, record `policy-obsolete` a
 - **Marker** `<!-- [lisa-automation-retire] key=monitor -->` plus a visible prose line; matched on
   the marker, never the title; searched **open AND closed** per `rejection-detection`'s **Proposal
   rejection memory**. Treat matches by close state: **open** suppresses another proposal;
-  **Not planned** suppresses another proposal unless new evidence postdates the rejection;
+  **Not planned** suppresses another proposal unless new evidence postdates the rejection and materially changes the consequence, requirement, or risk that justified the decline;
   **Completed** means the prior approved action happened, so a later recurrence may be re-filed.
   When an existing proposal suppresses filing, **the run still records `policy-obsolete` and files
   nothing** — the outcome describes this run, while the ticket is filed exactly once.

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

@@ -9,6 +9,8 @@ Route ONE candidate learning through the judgment gate and act on the verdict. C
 
 Most candidates are dropped — that is the gate working, not a failure. Nothing is ever silent (every drop leaves a visible note), and no learning content ever reaches the learnings surface outside a pull request.
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
 ## Candidate Input
 
 Accept the candidate as JSON or `key=value` fields:
@@ -68,7 +70,9 @@ The note is one line naming the classification (with its fixed plain-language gl
 
 ### `handoff-upstream` (classification `lisa-upstream`)
 
-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.
+This disposition completes the SLL-5 loop (#1583): on an accepted worthwhile 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.
+
+First apply `do-it-now`'s **Worth doing** guidance. Attribution establishes ownership, not value. Decline low-value additional hardening in the current summary without filing, persisting a rule, or asking a human; otherwise continue below. Before creating an upstream issue, consult `rejection-detection` for open and closed matches, including legacy unmarked declines.
 
 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:
 

package/plugins/lisa-copilot/skills/lisa-prd-source-write/SKILL.md

@@ -38,6 +38,7 @@ ideation_ledger_payload:              # optional; forwarded unchanged to the ven
   selected_idea: "<selected idea title/key>"
   rejected_overlap_candidates: ["<issue refs/titles considered and rejected>"]
   expected_empirical_verification_artifact: "<artifact ref or unavailable>"
+  reproposal_context: "<optional dated decline, new evidence, changed consequence, token and acknowledgment already included in the PRD body by research>"
 ```
 
 `initial_role` semantics are uniform across vendors (the role STRINGS resolve per vendor from

package/plugins/lisa-copilot/skills/lisa-project-ideation/SKILL.md

@@ -207,7 +207,10 @@ For each idea in the creation set, invoke `/lisa:research` with:
 - a structured `ideation_ledger_payload` handoff containing the selected marker, automation id and
   memory path when available, persona names, persona evidence references, rejected overlap
   candidates, repo identity, `prd_ready`, selected idea title/key, and the expected empirical
-  verification artifact. This payload is the only ideation-run metadata channel between
+  verification artifact. For a justified re-proposal, include `reproposal_context`: the dated
+  decline, dated new evidence reference, materially changed consequence, and the exact machine
+  token and human acknowledgment paragraph specified below. Research must include that paragraph
+  and token in the PRD body. This payload is the only ideation-run metadata channel between
   `project-ideation`, `research`, `prd-source-write`, and the vendor writer; keep GitHub-specific
   rendering out of this skill.
 
@@ -249,10 +252,9 @@ Per the `rejection-detection` rule's **Proposal rejection memory** section, that
 cover **open AND closed** PRDs (with a body-enumeration fallback on search-index lag), and a PRD
 **closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/
 canceled equivalent on JIRA/Linear — never a hardcoded lane string) is a **durable human decline**
-that **suppresses** re-proposing that idea. Re-propose only with evidence that **postdates the
+that **suppresses** re-proposing that idea. Re-propose only for a materially changed consequence, requirement, or risk addressing the decline, supported by evidence that **postdates the
 decline**, and state it in the new PRD as BOTH the machine token (`declined <date>; recurred <date>
-in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. It has recurred
-(<date>, <ref>), so we're raising it once more for your review.`). A PRD closed as _completed_ is
+in <ref>`) and a human acknowledgment sentence (`You declined this on <date>. New evidence (<date>, <ref>) changes the consequence, requirement, or risk: <what changed and why the decline no longer applies>.`). A PRD closed as _completed_ is
 not a decline. This is tracker-side memory; the advisory ideation memory ledger stays advisory and
 never overrides it.
 
@@ -350,7 +352,7 @@ marker-deduped teardown proposal through `lisa-tracker-write` (per `tracked-work
 - **Marker** `<!-- [lisa-automation-retire] key=exploratory-prds -->` plus a visible prose line;
   matched on the marker, never the title; searched **open AND closed** per `rejection-detection`'s
   **Proposal rejection memory**. Treat matches by close state: **open** suppresses another proposal;
-  **Not planned** suppresses another proposal unless new evidence postdates the rejection;
+  **Not planned** suppresses another proposal unless new evidence postdates the rejection and materially changes the consequence, requirement, or risk that justified the decline;
   **Completed** means the prior approved action happened, so a later recurrence may be re-filed.
   When an existing proposal suppresses filing, **the run still records `policy-obsolete` and files
   nothing** — the outcome describes this run, while the ticket is filed exactly once.

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

@@ -586,10 +586,9 @@ rule's **Proposal rejection memory** section, that marker search MUST cover **op
 tickets (body-enumeration fallback on search-index lag): an **open** match → reference it and ensure
 the `is blocked by` link is present rather than creating a duplicate; a match **closed as _not
 planned_** (GitHub `stateReason == "not_planned"`; the config-resolved equivalent on JIRA/Linear) is
-a **human decline** of that fix ticket — do **not** re-file it unless evidence **postdates the
+a **human decline** of that fix ticket — do **not** re-file it without a materially changed consequence, requirement, or risk addressing the decline, supported by evidence that **postdates the
 decline**, and the re-filed ticket MUST carry BOTH the machine token (`declined <date>; recurred
-<date> in <ref>`) and the human acknowledgment sentence (`You declined this on <date>. It has
-recurred (<date>, <ref>), so we're raising it once more for your review.`); a match closed as
+<date> in <ref>`) and the human acknowledgment sentence (`You declined this on <date>. New evidence (<date>, <ref>) changes the consequence, requirement, or risk: <what changed and why the decline no longer applies>.`); a match closed as
 _completed_ is a regression path, not a decline. Honor the backoff window and state fingerprint
 (Loop prevention) so re-runs over the same unchanged blocker are no-ops.
 

package/plugins/lisa-copilot/skills/lisa-research/SKILL.md

@@ -20,8 +20,12 @@ Produce a PRD for the problem in `$ARGUMENTS`, then create it in the configured
   structured metadata object to forward unchanged to `lisa-prd-source-write`. It carries the
   selected marker, automation id/path when available, persona names, persona evidence references,
   rejected overlap candidates, repo identity, `prd_ready`, selected idea title/key, and expected
-  empirical verification artifact. `research` may use these fields to inform the PRD body, but must
-  not discard, rename, or vendor-render them.
+  empirical verification artifact. When supplied, `reproposal_context` contains the dated decline,
+  new evidence, changed consequence, and the required machine token and human acknowledgment.
+  Include that token and acknowledgment verbatim in the synthesized PRD body before source routing,
+  so the justification survives even when the vendor's metadata renderer does not display this field.
+  Other metadata may inform the PRD body; forward the complete payload unchanged without renaming
+  or vendor-rendering its fields.
 
 ## Orchestration: agent team
 

package/plugins/lisa-copilot/skills/lisa-rework-triage/SKILL.md

@@ -6,16 +6,14 @@ allowed-tools: ["Skill", "Bash", "Read", "Glob", "Grep"]
 
 # Rework Triage: $ARGUMENTS
 
-Classify why a previous agent attempt at this ticket failed, and convert that cause into a
-structural improvement. This is the self-hardening arm of the lifecycle: every classified
-failure either hardens the harness (an upstream Lisa issue), the project (a provisioning or
-environment ticket), or the spec (a PRD defect flag). A rework cycle that fixes the bug but
-never asks *why the agent got it wrong* guarantees the mistake recurs.
+Classify why the previous attempt failed and repair the actual cause. Apply `do-it-now`'s **Worth doing** guidance before proposing additional hardening. Fixing the defect and its relevant regression test can be sufficient; a failure does not automatically justify another rule, hook, or upstream ticket.
 
 The caller MUST have run `lisa-tracker-read` first and provided the context bundle (all
 comments chronological, linked PRs with review state, issue links, parent epic). Do not
 classify from a bare summary — evidence-free classification is worse than none.
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
 ## Phase 1 — Rework detection
 
 A ticket is **rework** when it was previously implemented by this lifecycle and has returned
@@ -115,7 +113,12 @@ never one per cycle re-entry.
 
 ## Phase 4 — Route the cause to its hardening destination
 
-Each cause has exactly one destination. File through the proper write path — never raw
+For each primary or secondary cause, first decide whether additional work clears
+`do-it-now`'s **Worth doing** bar. If not, report `Hardening action: none required`
+with a brief reason in the existing triage comment. Do not create a replacement
+learning or a human gate merely to retain the declined observation.
+
+The table gives destinations for accepted additional work. File through the proper write path — never raw
 ticket creation — so every hardening artifact passes the same quality gates as any other
 Lisa work item.
 
@@ -128,7 +131,7 @@ Lisa work item.
 | `prd-defect` | Source PRD | Comment on the PRD (via the `lisa-prd-backlink` lineage) quoting the defective requirement and the QA failure; flag for product review. Do NOT silently edit the PRD — spec changes are a human gate. |
 | `implementation-defect` (no secondary) | None | Normal fix path; the classification comment is the record. Pass the pattern to the `learner` phase — repeated implementation defects of the same shape escalate to `verification-gap`. |
 
-**Secondary causes route too.** A recorded secondary cause triggers its own row's
+**Secondary causes route too — when worthwhile.** A worthwhile secondary cause uses its row's
 destination in addition to the primary's: `implementation-defect` with a
 `verification-gap` secondary files the upstream Lisa issue per the `verification-gap`
 row — the code being wrong does not excuse the verification lifecycle for passing it.
@@ -151,16 +154,16 @@ section differ:
 | Defect | `self-hardening` | A Lisa gate/skill/template did something wrong — a harness bug the kernel must fix. | none |
 | Contribution | `template-candidate` | A generalizable pattern discovered downstream that would benefit every host project — not a defect, a proposed improvement to Lisa's templates/rules/skills. | `## Proposed template change` |
 
-1. **Dedupe first.** `gh issue list -R <upstream> --state open --search "<fingerprint terms>"`
+1. **Dedupe first.** Search open AND closed items and consult `rejection-detection`'s **Proposal rejection memory**, including legacy issues without markers. `gh issue list -R <upstream> --state all --search "<fingerprint terms>"`
    — if an open issue already covers this failure class or pattern, comment the new
    occurrence on it (evidence compounds; duplicates dilute) and link it instead of filing.
 2. **File with the same bar as any ticket:** a three-audience description (what failed or
    improved for the operator, what the harness did or could do, what to change), the
-   verbatim evidence chain (PRD text → ticket AC → QA failure → gate that passed it; for
-   patterns, the downstream occurrences proving generality), and the lane's label:
-   `gh issue create -R <upstream> --title "<gate/skill>: <failure class>" --label self-hardening`
-   for defects, or
-   `gh issue create -R <upstream> --title "<template surface>: <pattern>" --label template-candidate`
+   public-safe evidence chain (PRD text → ticket AC → QA failure → gate that passed it; for
+   patterns, the occurrences proving generality). Invoke `lisa-github-write-issue` against
+   `<upstream>` using the existing public-safe attribution/projection procedure from
+   `upstream-to-lisa`. Pass `build_ready: true` unless an explicit `human_gate` was declared,
+   then pass that reason instead. Use label `self-hardening` for defects or `template-candidate`
    for contributions. A `template-candidate` filing MUST include a
    `## Proposed template change` section naming the Lisa template/rule/skill surface to
    change (e.g. `typescript/package-lisa/package.lisa.json`, a `plugins/src/base` rule)

package/plugins/lisa-copilot/skills/lisa-track/SKILL.md

@@ -22,7 +22,23 @@ continue through the existing path and never override an independently declared
 
 Establish the tracked-work invariant before any durable project mutation. Discussion and read-only orientation may proceed without this skill; code, configuration, documentation, research artifacts, plans, investigation findings, tests, commits, and pull requests may not.
 
-This flow must return exactly one canonical `(tracker_provider, work_item_ref)` pair or fail closed. It never returns an unvalidated textual guess.
+For accepted work this flow must return exactly one canonical `(tracker_provider, work_item_ref)` pair or fail closed. A declined incidental finding returns only its reason and authorizes no durable implementation. It never returns an unvalidated textual guess.
+
+## Worth doing
+
+Before filing, promoting, or claiming an incidental finding, ask whether the expected benefit justifies implementation, verification, maintenance, CI, and operator attention. Use the evidence already available; no numeric score, new tracking system, or speculative audit is required.
+
+- **Act** on concrete delivery failures, incorrect results, credible material security or data-loss risks, and recurring friction whose repair is worth its cost. A small fix can have a large consequence; security need not wait for an incident.
+- **Bundle** related small repairs when one bounded maintenance task is worth doing. Reuse an existing relevant item where possible. Do not expand unrelated work or create one ticket per wording fix.
+- **Decline** cosmetic preferences, speculative edge cases, duplicate controls, or changes whose likely benefit is smaller than their ongoing cost. Acceptable as-is is a valid engineering decision. Say why briefly in the current report, review, or issue; do not create a ticket, ledger entry, new rule, or human gate merely to record a declined observation.
+
+A reproducible imperfection proves that something happens, not that it deserves factory capacity. A complete specification establishes buildability, not value. Missing enforcement or test coverage alone does not justify new machinery; name the required behavior or credible consequence at risk. Honor explicit user requests, accepted product requirements, and material safety obligations. This rule cannot silently cancel those commitments or excuse failing required checks.
+
+## Prefer less machinery
+
+Start with the smallest sufficient correction at the owning component. Consider removing or consolidating redundant machinery before adding a hook, workflow, abstraction, registry, or test framework. Preserve required behavior and protection, and verify the consequence of the change. An isolated failure does not automatically justify a permanent control for every future session.
+
+For an existing incidental item, read its discussion, linked PRs and dependencies before declining. Close as **Not planned** (configured Jira/Linear equivalent), give the reason, and remove active lifecycle labels. Preserve human holds and committed scope unless cancellation is authorized; resolve effects on active PRs and dependent delivery first. Before re-filing, search open AND closed issues, read legacy unmarked matches, and require materially changed consequences that address the earlier reason. A later observation of the same accepted limitation is insufficient.
 
 ## Phase 1 — Resolve tracker and classify input
 
@@ -42,14 +58,16 @@ Invoke `lisa-tracker-read <ref>` and require a live result from the configured p
 
 ### File or plain text
 
+For incidental findings, apply `do-it-now` before resolving a new leaf. If the finding is declined, return the reason without creating or claiming anything; durable implementation does not start. Explicit user requests and accepted requirements remain in scope.
+
 Search conservatively before creating:
 
 1. Normalize the requested outcome and derive a short keyword set; never search with the whole prompt or secrets.
-2. Search only open/non-terminal items in the configured project and current repository through the configured provider's documented read surface:
-   - GitHub: `gh issue list --repo <org>/<repo> --state open --search "<keywords> in:title,body"`.
-   - Jira: `lisa-atlassian-access operation: search-issues` with project-scoped JQL.
-   - Linear: `lisa-linear-access operation: list-issues` scoped to the configured team/workspace.
-3. Treat search results as candidates, never proof. Live-read each plausible candidate through `lisa-tracker-read`, and discard terminal, container, blocked, held-by-gate, cross-repo, and materially different outcomes. A held candidate is never reused: attaching new work to an item a human is holding is how the hold gets spent.
+2. Search open AND closed items in the configured project and current repository through the configured provider's documented read surface. Closed items supply decision history, never an active binding:
+   - GitHub: `gh issue list --repo <org>/<repo> --state all --search "<keywords> in:title,body"`.
+   - Jira: `lisa-atlassian-access operation: search-issues` with project-scoped JQL and no status filter.
+   - Linear: `lisa-linear-access operation: list-issues` scoped to the configured team/workspace and including all states.
+3. Treat search results as candidates, never proof. Live-read each plausible candidate and its discussion through `lisa-tracker-read`. Apply `rejection-detection` to prior **Not planned** decisions, including legacy unmarked matches, before creating: suppress the same accepted limitation unless materially changed post-decline evidence addresses its reason, with the required token and acknowledgment in any new item. A completed fix may have a verified regression. For active binding, discard terminal, container, blocked, held-by-gate, cross-repo, and materially different outcomes. A held candidate is never reused: attaching new work to an item a human is holding is how the hold gets spent.
 4. Reuse only when **exactly one** live leaf is a high-confidence semantic match for the same requested outcome and repository. A shared keyword or similar title is not enough. Record the search queries, candidates, and rejection reasons in the returned resolution evidence.
 5. If there is no unique high-confidence match (zero or ambiguous candidates), create **exactly one** item by invoking `lisa-tracker-write` once. Synthesize one complete single-repository leaf (`Bug`, `Task`, `Sub-task`, or `Improvement`, never Epic/container) with the writer's required three-audience body, Gherkin acceptance criteria, repository, target environment, relationship search, and executable Validation Journey. Pass `build_ready: true` unless the caller declared a `human_gate`, in which case pass that `human_gate: "<why>"` reason instead of `build_ready: true` and never alongside it, so the writer leaves the leaf in the tracker's default backlog role — out of the lane build-intake claims from — and stamps the hold on the body as a `[lisa-human-gate]` marker. Discarding a declared gate and filing build-ready anyway is the one outcome this step must never produce. Do not create placeholder/thin tickets, do not create a hierarchy, and do not retry creation by making another item if validation fails; repair the proposed spec and retry the same writer operation only if the vendor contract supports idempotent reuse.
 6. Live-read the writer's canonical returned reference with `lisa-tracker-read`. A create response without a verified live leaf is failure.

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

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

package/plugins/lisa-cursor/commands/lisa/exploratory-qa.md

@@ -1,7 +1,7 @@
 ---
-description: "Run a first-time-user exploratory QA pass on any product type (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK): experience the product the way a brand-new end user would by driving its real consumer-facing interface via the use-the-product core (which detects the product type, resolves the per-environment mutation policy from .lisa.config.json so production is never mutated by accident, and explores through the project's personas when defined), finding anything confusing, broken, or hard to use, and filing each finding (bug or usability issue) as a tracked work item via lisa-tracker-write. Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient. The optional ready flag marks tickets build-ready (auto-picked-up by lisa-intake) or leaves them in the backlog for human triage (default). For gaps in the automated test suite, use the e2e-coverage-gaps skill if your stack provides one."
+description: "Run a first-time-user exploratory QA pass on any product type (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK): experience the product the way a brand-new end user would by driving its real consumer-facing interface via the use-the-product core (which detects the product type, resolves the per-environment mutation policy from .lisa.config.json so production is never mutated by accident, and explores through the project's personas when defined), finding anything confusing, broken, or hard to use, and filing each worthwhile finding (bug or usability issue) as a tracked work item via lisa-tracker-write. Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient. The optional ready flag marks tickets build-ready (auto-picked-up by lisa-intake) or leaves them in the backlog for human triage (default). For gaps in the automated test suite, use the e2e-coverage-gaps skill if your stack provides one."
 allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the lisa-exploratory-qa skill to experience the product the way a brand-new first-time end user would — driving its real consumer-facing interface via the use-the-product core (product-type detection, per-environment mutation policy, and persona-lensed exploration), finding anything confusing, broken, or hard to use, and filing each finding (bugs, usability/clarity issues) as a tracked work item via lisa-tracker-write, build-ready or in triage per the ready flag (default: triage). Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not enough. For automated test-coverage gaps, use the e2e-coverage-gaps skill if your stack provides one. $ARGUMENTS
+Use the lisa-exploratory-qa skill to experience the product the way a brand-new first-time end user would — driving its real consumer-facing interface via the use-the-product core (product-type detection, per-environment mutation policy, and persona-lensed exploration), finding anything confusing, broken, or hard to use, and filing each worthwhile finding (bugs, usability/clarity issues) as a tracked work item via lisa-tracker-write, build-ready or in triage per the ready flag (default: triage). Static scans, HTTP fetches, screenshots alone, or console/network checks alone are not enough. For automated test-coverage gaps, use the e2e-coverage-gaps skill if your stack provides one. $ARGUMENTS

package/plugins/lisa-cursor/rules/claim-time-guards-reference.mdc

@@ -46,6 +46,10 @@ Two guards that run when build-intake claims a ready item. Both come from acmeor
 
 It is a **single vendor-neutral contract** consumed by all three build-intake skills (`lisa-github-build-intake`, `lisa-jira-build-intake`, `lisa-linear-build-intake`). Each arm cites this slug in its claim step rather than growing its own copy, exactly as the arms cite `leaf-only-lifecycle`, `repo-scope-split`, `rejection-detection`, and `claim-archaeology`. One slug is what keeps a guard that fires on GitHub from being absent on Linear.
 
+## Value before claim
+
+After respecting human holds and resolving the issue's scope, apply `do-it-now`'s **Worth doing** guidance before claiming agent-proposed incidental work. Read current discussion, linked PRs, and dependencies. Decline low-value work as **Not planned** with a specific reason and remove active lifecycle labels; do not convert it to completed work or manufacture a replacement task. Retain explicit user commitments and meaningful delivery/safety defects. A decline is a processed disposition within the existing cycle limit, not permission to start an extra item.
+
 ## Sequencing
 
 The shared claim phase is `3a.0` repo-scope gate → `3a` leaf-only claim gate → `3b` Claim → `3c` run lifecycle → `3d` transition to done. Inside `3b`, the pre-transition window now runs four passes in a fixed order:

package/plugins/lisa-cursor/rules/do-it-now-reference.mdc

@@ -5,38 +5,20 @@ alwaysApply: false
 
 # Do It Now
 
-## The failure
+Lisa helps projects ship dependable software with less effort. Finish authorized, worthwhile work instead of leaving an unowned promise. This instruction does not turn every imperfection into an obligation.
 
-An agent notices something that needs doing — a lint rule that would have caught the bug it just fixed, a stale comment, a real defect found beside the one it was sent for, a ticket that should be flipped to ready — and writes a sentence about it instead of doing it. "Worth adding a rule for this later." "We should file that." "Follow-up: update the doc."
+## Worth doing
 
-Almost none of those happen. The note lands in a session transcript nobody re-reads, or in a report the human skims once. Even when it survives, the next session pays full price to rebuild the context that made the work obvious — which is the moment you are in right now, and it will not come back this cheap.
+Read **Worth doing** in the `lisa-track` skill for the shared value decision and preference for less machinery. That existing skill is the portable home: Antigravity does not receive the rule tree, but does receive skills. This rule's eager summary and every incidental filing/intake path point to the same guidance.
 
-The originating example: a session closed a non-reproducing bug, found a genuine defect next to it, filed a ticket for the real defect, and then left the ticket sitting outside the ready lane. Every individual step was correct. The handoff was incomplete, and the work sat.
+## Complete the accepted work
 
-## The rule
+Once scope and value are established, do the permitted work now: fix the defect, update documentation made wrong by the change, remove temporary scaffolding, and verify the result. Do not leave an accepted action as a vague follow-up. If worthwhile work must be deferred because it exceeds scope or depends on another change, track the smallest coherent outcome and give the reason.
 
-**If the factory is allowed to do it, do it in this session.** Allowed means: within scope, within your permissions, and not behind an exterior human gate. That covers the great majority of "later" items:
+Protected deployments, held PRDs, and unresolved product decisions still wait outside the factory. Prepare the authorized portion and explain what remains. Routine decisions to decline low-value incidental work belong to the agent; do not send every nit to a human.
 
-- Filing the ticket — and flipping it to the ready role so something picks it up (`tracked-work`).
-- Adding the lint rule, ast-grep pattern, or test that prevents the recurrence (`promotion-contract` — and note that promotion is atomic: enable the control, fix the existing violations, ship the diagnostic, delete the superseded prose).
-- Fixing the flaky test rather than re-running it.
-- Updating the doc, comment, or rule your change just made wrong (`stale-state-claims`).
-- Cleaning up the scaffolding you introduced.
+## Existing backlog
 
-## The exception, and its shape
+Read the issue, current discussion, linked PRs, and dependencies before deciding. A ready label or an agent's prior filing is not proof of value. For an incidental improvement that does not clear the bar, close as **Not planned** (the configured equivalent on Jira/Linear), record a short specific reason, and remove active lifecycle labels. Do not mark declined work completed or implemented. Preserve explicit human holds and committed product scope; if cancellation would affect an active PR or a dependent delivery item, resolve that relationship before closing.
 
-Lisa's exterior gates exist on purpose and this rule does not override them. A protected deployment, a held-back PRD, a low-confidence learning awaiting human review, a product judgement only a person can make — these wait for the human, by design.
-
-The exception is narrower than it first appears, because it applies to the **gated step**, not to the whole item. Do everything up to the gate now:
-
-1. Do the allowed part — file it, write it, prepare it, get it to the edge of the gate.
-2. Mark the gate explicitly, in the tracker, so it is visible outside your session.
-3. Say plainly, in your update, what is waiting on a human and what will happen once they act.
-
-"Waiting on a human" is a state you report, never a place you leave work silently.
-
-## Deferring is a decision
-
-Sometimes not doing it now is genuinely right: the change is out of scope, it would balloon the diff past reviewability, it depends on a decision not yet made, or it belongs to a different work item. Those are legitimate — and they are **decisions**, which means they get said out loud with a reason, and the deferred item becomes tracked work rather than a sentence.
-
-What is never acceptable is the implied deferral: noticing, saying nothing, and moving on. The human cannot act on what you did not tell them, and neither can the next session.
+Before re-filing, consult `rejection-detection`'s **Proposal rejection memory**, including legacy issues without markers. Repeating an accepted limitation is not new evidence that warrants reversing a decline.

package/plugins/lisa-cursor/rules/do-it-now.mdc

@@ -5,12 +5,12 @@ alwaysApply: true
 
 # Do It Now (load-bearing)
 
-If something needs to happen eventually and **the factory is allowed to do it**, do it in this session. File the ticket, flip it to ready, add the lint rule, fix the flaky test, update the doc that just went stale. Not in a "follow-up" sentence — now.
+Finish authorized, worthwhile work in this session. Lisa exists to help projects ship dependable software with less effort; more tickets, rules, or checks are not progress by themselves.
 
-**"I'll get to that later" is not an acceptable close** for work that is in scope and permitted. A deferral costs a whole future session its context, and most of them are never picked up at all.
+Before turning an incidental finding into work, apply `do-it-now`'s **Worth doing** guidance. Act on concrete delivery failures, credible material security or data-loss risks, and recurring friction whose repair is worth its cost. Prefer the smallest sufficient fix, including simplifying or removing redundant machinery while preserving required behavior.
 
-The one exception is an **exterior human gate** — a protected deploy, a held-back PRD, a low-confidence learning, a product call only a person can make. There you do the allowed part now (file it, mark the gate, flip everything you may flip) and say plainly what is waiting on a human and why.
+**Decline unnecessary work.** Cosmetic preferences, speculative edge cases, and already adequate behavior need no ticket, new rule, or human approval. Briefly state the reason in the current report or discussion when relevant. A complete specification establishes buildability, not value. Group related small repairs into one bounded maintenance task when worthwhile.
 
-Deferring is itself a decision. If you genuinely should not do it now, say so and say why; never leave it implied, and never leave it only in your own head.
+Complete the accepted scope; don't manufacture follow-ups. Human decisions and protected actions still wait at their exterior gate. Do the authorized preparation and explain what remains.
 
-Full prose: [reference/do-it-now.md](do-it-now-reference.mdc).
+Full guidance: [reference/do-it-now.md](do-it-now-reference.mdc).

package/plugins/lisa-cursor/rules/observability-audit-reference.mdc

@@ -120,10 +120,10 @@ A manual re-run next week must not duplicate last week's tickets. Mirror the `re
    - Gap: the literal `gap:<dimension>:<CURRENT_REPO>` (a dimension is missing-or-not; no hash needed).
 2. **Sentinel in the body.** Embed `<!-- lisa:monitor-finding: <fingerprint> -->` in every filed ticket.
 3. **Search before create** (this IS gate S13). Before filing, search the tracker for the fingerprint string. The search **MUST include closed/resolved tickets** (`gh issue list --search <fp> --state all` for GitHub; JQL with no status filter for JIRA; all states for Linear) — otherwise a just-closed match is invisible and the backoff and decline checks below can't fire. If an **open** ticket carries the fingerprint → skip (optionally link). Otherwise classify a closed match by **how** it closed:
-   - **Closed as _not planned_ — a permanent decline** (`rejection-detection` **Proposal rejection memory**). GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear (never a hardcoded lane string). This is a durable human "no", not a time-boxed guard: **suppress the finding regardless of age**, and re-file only with evidence that **postdates the decline**. The new ticket MUST carry BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and the human acknowledgment sentence (`You declined this on <date>. It has recurred (<date>, <ref>), so we're raising it once more for your review.`). This layers *on top of* the backoff below — a not_planned close outlives any window.
+   - **Closed as _not planned_ — a permanent decline** (`rejection-detection` **Proposal rejection memory**). GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear (never a hardcoded lane string). This is a durable human "no", not a time-boxed guard: **suppress the finding regardless of age**, and re-file only with evidence that **postdates the decline** and establishes a materially changed consequence, requirement, or risk addressing the recorded reason. Seeing the same accepted limitation on a later date is insufficient. The new ticket MUST carry BOTH the machine token (`declined <date>; recurred <date> in <ref>`) and the human acknowledgment sentence (`You declined this on <date>. New evidence (<date>, <ref>) changes the consequence, requirement, or risk: <what changed and why the decline no longer applies>.`). This layers *on top of* the backoff below — a not_planned close outlives any window.
    - **Closed as _completed_ within the recently-resolved backoff window** (`monitor.backoffHours`, default **24h** — matching the 24h Sentry event window; this is **not** the 2h `intake.repair.staleAfterHours`) → skip, to avoid re-filing a just-fixed regression before its signal has drained. A completed close **older** than the window is not a decline — a genuine recurrence is a regression and may file.
 
-   Only file when no live match, no recently-resolved completed match, and no prior not_planned decline exists.
+   Only file when no live match or recently-resolved completed match exists, and any prior not_planned decline meets the evidence and acknowledgment requirements above.
 
 ## The cap
 

package/plugins/lisa-cursor/rules/ready-role-filing-reference.mdc

@@ -13,13 +13,17 @@ alwaysApply: false
 
 Filing a work item without the ready role is an **incomplete handoff** — build-intake scans the ready lane and nothing else, so the item is never picked up. A correct write plus a missing role still loses the work.
 
+## Value precedes readiness
+
+Apply `do-it-now`'s **Worth doing** guidance before deciding to file. A declined observation produces no ticket and needs no `human_gate`; it is not an incomplete handoff. Build-ready means both worthwhile and complete enough to build. Do not invent work merely to satisfy this filing contract.
+
 ## Omitted means NOT ready — on every tracker
 
 **An omitted `build_ready` is NOT build-ready on JIRA, GitHub, and Linear alike.** Ready is an explicit claim, never an accident of which tracker a project configured. This is a **breaking change** for GitHub and Linear callers, which previously treated omission as ready; `lisa-github-validate-issue` F4's compensating omitted → `true` normalization is removed with it.
 
 ## Every filing declares one of three things
 
-- **`build_ready: true`** — complete enough to build; enters the ready lane for auto-pickup. Required for any complete defect found during other work, so it is claimable next cycle with no human flipping status.
+- **`build_ready: true`** — complete enough to build; enters the ready lane for auto-pickup. Required for an accepted worthwhile defect found during other work, so it is claimable next cycle with no human flipping status.
 - **`human_gate: "<why a human must judge this first>"`** — deliberately held outside the queue. The writer stamps a visible line plus `<!-- [lisa-human-gate] reason=<short-slug> -->` so the hold is auditable.
 - **The container declaration** — `None — container: state rolls up from children`, the canonical line `derived-branch-plan` defines and every writer stamps in place of a Target Backend Environment. A container is never build-ready (`leaf-only-lifecycle`) and needs no gate, so it declares the third thing instead. Deliberately **not** keyed on `--label type:Epic`: a declared type is a claim that costs a leaf nothing and leaves it looking buildable, where the container line costs the item the environment and Branch Plan a leaf needs to be built. It is refused alongside a by-design leaf type (`type:Bug` / `type:Task` / `type:Sub-task` / `type:Improvement`) — an item cannot be a container and a leaf at once.
 
@@ -65,7 +69,7 @@ The safe direction is the implicit one. A ticket that reaches a build queue by a
 
 A writer accepts a filing only when it carries **one** of:
 
-- **`build_ready: true`** — the item is complete enough to build and enters the ready lane for auto-pickup. This is the correct answer for a complete defect found during other work.
+- **`build_ready: true`** — the item is complete enough to build and enters the ready lane for auto-pickup. This is the correct answer for an accepted worthwhile defect found during other work.
 - **`human_gate: "<why a human must judge this first>"`** — the item is deliberately held outside the queue because a human product call is pending. The writer stamps a visible marker on the item so the hold is auditable rather than indistinguishable from an accident:
 
   ```text

package/plugins/lisa-cursor/rules/rejection-detection-reference.mdc

@@ -191,6 +191,12 @@ A proposal is **declined** when its prior item is **closed as _not planned_**:
 
 **Closed as _completed_ is NOT a decline.** A completed fix whose underlying problem later recurs is a **regression**, and the loop **may file** it — the recurrence is genuinely new work, not a re-proposal of the declined thing. Only *not planned* is the durable "no".
 
+### Agent declines and legacy issues
+
+A reasoned **Not planned** disposition made by an agent under `do-it-now` or an owner-authorized backlog audit has the same suppression effect. Do not require the owner to repeat it manually.
+
+For older issues without a stable marker, additionally search open and closed issues by the owning surface and concrete symptom, then read the body and closing discussion to establish a semantic match. A title resemblance alone is insufficient. Missing markers do not erase a documented decline. Repeating the same accepted limitation on a later date is not changed evidence; reopening the proposal requires a materially changed consequence, requirement, or risk that addresses the recorded reason.
+
 ### Marker discipline — deterministic key, open AND closed search
 
 Every loop-proposed item carries a **visible prose line** plus a marker (a bare HTML marker renders as an empty comment bubble):
@@ -216,7 +222,7 @@ This footer is **required on every proposing loop's filed ticket** (`lisa-explor
 
 ### The rule
 
-A marker hit on a **closed-as-not-planned** item **suppresses the proposal** — regardless of title similarity. Re-proposal is permitted **only** with evidence that **postdates the decline**, and the re-filed item MUST carry BOTH of the following:
+A marker hit on a **closed-as-not-planned** item **suppresses the proposal** — regardless of title similarity. Re-proposal is permitted **only** with evidence that **postdates the decline** and establishes a materially changed consequence, requirement, or risk addressing the recorded reason, and the re-filed item MUST carry BOTH of the following:
 
 1. **A machine token** for the dedupe/audit trail — generalizing the gardener's wording:
 
@@ -224,7 +230,7 @@ A marker hit on a **closed-as-not-planned** item **suppresses the proposal** —
 
 2. **A human acknowledgment sentence** in plain prose, so re-raising reads as a respectful return to an answered question rather than a machine nagging:
 
-   > You declined this on `<decline-date>`. It has recurred (`<recurrence-date>`, `<recurrence-ref>`), so we're raising it once more for your review.
+   > You declined this on `<decline-date>`. New evidence (`<recurrence-date>`, `<recurrence-ref>`) changes the consequence, requirement, or risk: `<what changed and why the decline no longer applies>`.
 
 Naming the decline date, the recurrence date, and the recurrence reference in both forms is what turns "raising it again" into an auditable, evidence-backed, operator-legible act rather than nagging. A marker hit on a closed-as-**completed** item is not a decline — it falls under the regression path above.
 

package/plugins/lisa-cursor/rules/tracked-work-reference.mdc

@@ -5,6 +5,8 @@ alwaysApply: false
 
 # Tracked Work
 
+Apply `do-it-now` before creating work from incidental findings. Declining an observation needs no new ticket. Related small accepted repairs may share one bounded maintenance leaf; traceability does not require a separate item for every nit.
+
 The project tracker is the durable operator-facing record for project work. Every session that will produce a durable project outcome must establish exactly one live configured-tracker leaf before the first durable mutation. Durable outcomes include code, tests, configuration, documentation, committed research or plans, investigation findings, commits, and pull requests. Read-only questions, discussion, and repository orientation are exempt until they turn into durable work.
 
 ## Resolve, claim, bind

package/plugins/lisa-cursor/rules/tracked-work.mdc

@@ -5,6 +5,8 @@ alwaysApply: true
 
 # Tracked Work
 
+Apply `do-it-now` before creating work from incidental findings. Declining an observation needs no new ticket. Related small accepted repairs may share one bounded maintenance leaf; traceability does not require a separate item for every nit.
+
 Before the first durable project mutation (code, tests, config, docs, committed research/plans/findings, commits, or PRs), establish exactly one live tracker leaf through `lisa-track`. Read-only discussion and orientation are exempt only while they produce no durable artifact.
 
 The mandatory order is: live-validate an explicit ref, or conservatively search and create exactly one valid leaf through `lisa-tracker-write` when no unique match exists; idempotently claim it through `lisa-tracker-claim`; then persist and verify the worktree-local binding with `node scripts/lisa-work-item.mjs link <ref>`. A tracker that answers no, and any claim or binding failure, blocks durable work; a tracker that cannot be reached does not block a commit — the offline checks still run, the skip is loud on stderr, and the required `Work-Item Traceability` check re-runs the live checks with credentials before anything merges.

package/plugins/lisa-cursor/rules/upstream-to-lisa-reference.mdc

@@ -5,56 +5,27 @@ alwaysApply: false
 
 # Upstream To Lisa
 
-When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project. This rule defines what to do so the fix is both unblocking *now* and durable *later*.
+A root cause in a Lisa-distributed artifact determines the destination of a worthwhile repair. First apply `do-it-now`'s **Worth doing** guidance. Ownership, a missing guard, or a reproducible edge case alone does not justify another issue.
 
-## When this applies
+## Accepted repairs
 
-You are working in a downstream/host project (not the Lisa source repo) and you discover one of:
+A concrete delivery failure, credible material safety risk, or recurring costly friction in a Lisa template, rule, skill, agent, hook, or CI workflow belongs upstream.
 
-- A bug or gap in a Lisa-distributed **template, rule, skill, agent, hook, or CI workflow**.
-- A **governance pattern** discovered here that should be generalized back into Lisa's templates so every project benefits.
-- Anything where the file you want to change is **Lisa-managed** — it carries Lisa governance markers, lives in a path Lisa owns, or any edit would be **overwritten on the next `lisa apply`**.
-- Anything where the root cause is in a Lisa **create-only** template, even if the generated file says Lisa will not overwrite it.
-
-The defining test: **does the root cause live in a Lisa-distributed artifact?** If yes, file upstream. The wipe-out test is a sufficient signal, not the only signal.
-
-| Template class | Local fix survives `lisa apply`? | Why it is still upstream-worthy |
+| Template class | Local fix survives `lisa apply`? | Why repair upstream? |
 | --- | --- | --- |
-| **copy-overwrite** (managed) | No — clobbered on next apply | The local fix is throwaway; without the upstream fix it re-breaks. |
-| **create-only** (first setup) | Yes — Lisa never overwrites it | No existing repo self-heals, and every newly scaffolded repo inherits the bug. |
-
-For create-only files, header text such as `Lisa will not overwrite it` is a **positive** upstream signal, not a reason to stay local. Keep the downstream fix because Lisa will not replace it, and still file upstream so future projects receive the corrected template.
-
-## What to do — both steps, always
-
-### 1. Fix it locally so you are not blocked
-
-Apply the stopgap in this project so you can keep working. Do **not** stall waiting for an upstream fix to land.
-
-- For copy-overwrite files, treat the local change as temporary: it will be clobbered when the upstream fix ships and Lisa re-applies.
-- For create-only files, keep the local change: Lisa will not overwrite it. The upstream issue is still mandatory because new projects keep inheriting the broken template until Lisa changes.
-
-### 2. File an upstream issue in the Lisa repository
-
-Use the `github-write-issue` skill (`lisa-github-write-issue`) to create a GitHub Issue **in Lisa's source repository `CodySwannGT/lisa`** — not in this project's own repo. The skill uses the `gh` CLI; the target repo must be `CodySwannGT/lisa` (e.g. `gh issue create --repo CodySwannGT/lisa ...`), because the agent's default repo is this host project.
-
-The issue should capture, following the skill's three-audience / acceptance-criteria conventions:
-
-- **Root cause** — which Lisa template/rule/skill/agent/hook/workflow is wrong or missing, with the path under `plugins/src/...` (or the relevant template source) if known.
-- **Symptom** — what broke or was missing in *this* project, and how it surfaced. Reference this project so the fix can be validated against a real case.
-- **Proposed durable fix** — the change to make in Lisa's source so it propagates to all projects on the next apply.
-- **Local stopgap applied** — note that a local fix is in place here, whether it is temporary copy-overwrite work or a retained create-only patch.
+| **copy-overwrite** | No | Prevent the local repair being replaced by the broken source. |
+| **create-only** | Yes | Stop new projects inheriting the defect. |
 
-## Do not
+A header saying `Lisa will not overwrite it` is a positive upstream ownership signal, not a reason to keep an accepted defect local. It does not establish priority or value.
 
-- Do **not** only fix it locally and move on. For copy-overwrite files, the local fix is throwaway and re-breaks on the next apply. For create-only files, the local fix survives, but the broken template still ships to every new project.
-- Do **not** edit Lisa's templates from inside this project. You are not in the Lisa repo; those edits don't exist upstream and get overwritten — they create the illusion of a fix while the real source stays broken.
-- Do **not** file the issue in this project's own repo. The durable fix is tracked in `CodySwannGT/lisa`.
+1. **Unblock the current task if needed.** Apply the smallest safe local stopgap. Keep it scoped and attributable; do not stall useful delivery waiting for an upstream release.
+2. **Search before filing.** Search open AND closed issues in the configured upstream repository (`hardening.upstreamRepo`, default `CodySwannGT/lisa`). Reuse a matching open issue. Honor **Not planned** decisions under `rejection-detection`'s **Proposal rejection memory**, including legacy unmarked issues. Check actual behavior before treating a completed issue as a regression.
+3. **File only the accepted work.** Use `lisa-github-write-issue` against the upstream repository, with the explicit readiness declaration from `ready-role-filing`. State the owning source, observed consequence or credible risk, smallest durable fix, and any local stopgap. Follow the public-safe attribution/projection procedure; never publish host names, credentials, or private source paths.
 
-## Access fallback
+Bundle related minor repairs into one bounded maintenance item when the combined benefit warrants it. Declined observations require no ticket or escalation. A generalizable governance pattern still has to justify its recurring cost across consumers; generality alone is insufficient.
 
-If you lack permission to create an issue in `CodySwannGT/lisa`, do not silently drop it. Surface the situation to the user along with the fully-drafted issue contents (root cause, symptom, proposed fix, local stopgap), so a human can file it or grant access.
+## Access and scope
 
-## Not applicable inside the Lisa repo itself
+If an accepted upstream repair cannot be filed because access is missing, prepare the public-safe issue and explain the access problem. Do not ask a human to file observations already declined on value.
 
-When you are already working **inside the Lisa source repo** (`CodySwannGT/lisa`), this rule does not apply — the fix is local to that repo, so make it directly in `plugins/src/...` (and rebuild artifacts) rather than filing an issue against yourself.
+Do not mistake editing an installed artifact for changing Lisa's source. Inside Lisa itself, use the existing tracked task, repair the shared source, and regenerate equivalent agent surfaces; no second upstream issue is needed.