@codyswann/lisa 4.55.5 → 4.55.6

package/plugins/lisa/rules/reference/do-it-now.md

@@ -1,37 +1,19 @@
 # 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/rules/reference/observability-audit.md

@@ -115,10 +115,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/rules/reference/ready-role-filing.md

@@ -8,13 +8,17 @@
 
 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.
 
@@ -60,7 +64,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/rules/reference/rejection-detection.md

@@ -186,6 +186,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):
@@ -211,7 +217,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:
 
@@ -219,7 +225,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/rules/reference/tracked-work.md

@@ -1,5 +1,7 @@
 # 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/rules/reference/upstream-to-lisa.md

@@ -1,55 +1,26 @@
 # 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.

package/plugins/lisa/skills/lisa-exploratory-qa/SKILL.md

@@ -1,13 +1,15 @@
 ---
 name: lisa-exploratory-qa
-description: First-time-user exploratory QA pass for ANY product type (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK) that FEEDS THE LIFECYCLE. Use when asked to experience a product the way a brand-new end user would — 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 data is never mutated by accident, and explores through the project's personas when it defines them) to find anything confusing, broken, or hard to use. Static route scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient evidence. Instead of writing a report file, it files every finding as a tracked work item via lisa-tracker-write. A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa-intake) or left in the backlog for human triage (default). For gaps in the automated test suite, use e2e-coverage-gaps instead.
+description: First-time-user exploratory QA pass for ANY product type (DOM web app, HTTP/API backend, canvas game, CLI/library, IaC/CDK) that FEEDS THE LIFECYCLE. Use when asked to experience a product the way a brand-new end user would — 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 data is never mutated by accident, and explores through the project's personas when it defines them) to find anything confusing, broken, or hard to use. Static route scans, HTTP fetches, screenshots alone, or console/network checks alone are not sufficient evidence. Instead of writing a report file, it files worthwhile findings as tracked work items via lisa-tracker-write. A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa-intake) or left in the backlog for human triage (default). For gaps in the automated test suite, use e2e-coverage-gaps instead.
 ---
 
 # Exploratory QA
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
 ## Overview
 
-Experience the product the way a **brand-new end user** would: drive its real consumer-facing interface and actually try to use it, then surface anything **confusing, broken, or hard to understand**. This is a usability/experience pass, **not** a test-coverage audit (for that, use `e2e-coverage-gaps`). Every finding is filed as a tracked work item so it enters the Lisa lifecycle — no static report file.
+Experience the product the way a **brand-new end user** would: drive its real consumer-facing interface and actually try to use it, then surface anything **confusing, broken, or hard to understand**. This is a usability/experience pass, **not** a test-coverage audit (for that, use `e2e-coverage-gaps`). Accepted worthwhile findings enter the Lisa lifecycle as bounded tracked work — no static report file.
 
 **How you drive the product is owned by the `use-the-product` core skill.** Invoke it first: it detects the product type (web / API / game / CLI / IaC), resolves the target environment and its **mutation policy** (so you never mutate production without an explicit, justified opt-in), and discovers the project's **personas** so you can explore as each one. This skill supplies the **QA lens** — what to look for and how to file it.
 
@@ -61,7 +63,7 @@ Whether you may create/edit/delete — and as which account — is set by the `u
 
 ## 6. File findings as tracked work
 
-No report file. Every finding becomes a **leaf work item** via `lisa-tracker-write` (the vendor-neutral writer — it dispatches to the configured tracker and runs the validation gate; never call a vendor `*-write-*` skill directly):
+Apply `do-it-now`'s **Worth doing** guidance first. Decline low-value observations in the run summary without a ticket or human gate; bundle related worthwhile minor findings when appropriate. No report file. Every accepted finding becomes a **leaf work item** via `lisa-tracker-write` (the vendor-neutral writer — it dispatches to the configured tracker and runs the validation gate; never call a vendor `*-write-*` skill directly):
 
 Kane never files the work item itself. Even when it marks a failure as a confirmed product bug, run Lisa's marker-based duplicate search, apply the QA lens, and route the finding through `lisa-tracker-write` exactly as for every other controller.
 
@@ -72,7 +74,7 @@ Kane never files the work item itself. Even when it marks a failure as a confirm
 
 Each finding is a flat leaf, so `build_ready` applies directly — pass it explicitly on every create.
 
-**This skill is the named human-gate exception under `ready-role-filing`.** Everywhere else in Lisa, a complete defect found during other work is filed with explicit `build_ready: true` so build-intake claims it next cycle. Exploratory QA is deliberately different, and that difference is ratified rather than drift: its findings are *candidate* defects and usability observations whose **product significance is a human call**, so auto-readying them would push judgment work into the build queue — precisely the failure the gate model exists to prevent. Its default `ready=false` is therefore an **explicit human-gate marker, never a bare omission**: every not-ready create passes `human_gate: "exploratory finding — product significance is a human product call"` alongside `build_ready: false`, and the writer stamps the auditable `[lisa-human-gate]` marker. An operator who wants a pass to feed the queue directly opts in with `ready=true`.
+**This skill is the named human-gate exception under `ready-role-filing`.** For accepted worthwhile work elsewhere in Lisa, a complete defect found during other work is filed with explicit `build_ready: true` so build-intake claims it next cycle. Exploratory QA is deliberately different, and that difference is ratified rather than drift: its findings are *candidate* defects and usability observations whose **product significance is a human call**, so auto-readying them would push judgment work into the build queue — precisely the failure the gate model exists to prevent. Its default `ready=false` is therefore an **explicit human-gate marker, never a bare omission**: every not-ready create passes `human_gate: "exploratory finding — product significance is a human product call"` alongside `build_ready: false`, and the writer stamps the auditable `[lisa-human-gate]` marker. An operator who wants a pass to feed the queue directly opts in with `ready=true`.
 
 (The sibling `e2e-coverage-gaps` skills are the contrast: a missing automated test is not a product question, so they file `build_ready: true` by default.)
 
@@ -80,11 +82,11 @@ Each ticket MUST be a complete spec (the validator rejects thin tickets): a **th
 
 ### Idempotency — don't spam duplicates
 
-Re-running a pass must not refile the same finding. Before creating a ticket, search the tracker for a ticket carrying a stable marker `[lisa-exploratory-qa] <finding-key>` in its body (the `<finding-key>` is a stable slug of surface + symptom, e.g. `settings-modal/horizontal-overflow@tablet`). Per the `rejection-detection` rule's **Proposal rejection memory** section, that marker search MUST cover **open AND closed** tickets (with a body-enumeration fallback on search-index lag), and **match by the marker, never by title.** Then split on how any prior ticket closed:
+Re-running a pass must not refile the same finding. Before creating a ticket, search the tracker for a ticket carrying a stable marker `[lisa-exploratory-qa] <finding-key>` in its body (the `<finding-key>` is a stable slug of surface + symptom, e.g. `settings-modal/horizontal-overflow@tablet`). Per the `rejection-detection` rule's **Proposal rejection memory** section, that marker search MUST cover **open AND closed** tickets (with a body-enumeration fallback on search-index lag), and **match by the marker, never by title alone; for legacy unmarked issues, read the body and closing discussion to establish the semantic match.** Then split on how any prior ticket closed:
 
 - **Open** ticket carrying the marker → reference/update it instead; do not create a second.
 - **Closed as _completed_** → does **not** suppress. A recurrence after a fix is a genuine **regression**, so file the finding.
-- **Closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear, including a Linear `duplicate` state) → a human **declined** this finding, so **suppress it**. Re-file only with evidence that **postdates the decline**, carrying 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.`).
+- **Closed as _not planned_** (GitHub `stateReason == "not_planned"`; the config-resolved won't-do/canceled equivalent on JIRA/Linear — never infer decline from a hardcoded state name) → a human **declined** this finding, so **suppress it**. Re-file only with evidence that **postdates the decline** and establishes a materially changed consequence, requirement, or risk addressing the recorded reason, carrying BOTH the machine token (`declined <date>; recurred <date> 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>.`).
 
 Every filed finding ticket MUST end with the `rejection-detection` **operator footer** as a visible prose line so the operator knows which close-reason silences it:
 
@@ -150,7 +152,7 @@ teardown proposal through `lisa-tracker-write` (per `tracked-work` + `integratio
 - **Marker** `<!-- [lisa-automation-retire] key=exploratory-bugs -->` 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/skills/lisa-github-build-intake/SKILL.md

@@ -467,6 +467,9 @@ A blocker is active if it is open and has no cleared status label. Treat `status
 
 #### 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 relabel below.** Per the vendor-neutral `rejection-detection` rule (cite the slug; do not restate its classification table), classify this item at the **top of 3b, BEFORE** the `$READY → $CLAIMED` relabel — after the relabel the current-lane signal is gone. Read the item's Label-Event History from `lisa-github-read-issue` (chronological `LabeledEvent` / `UnlabeledEvent` on the configured `$READY` label) and classify it `rejection-reclaim | forward-only | never-left-ready | unknown`. Lane names come from `.lisa.config.json` (`github.labels.build.*`), never hardcoded. A failing/absent history yields `unknown` and the claim proceeds — detection never blocks the build. Items 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 relabel and lifecycle below.
 
 **On `rejection-reclaim`, reflect before re-implementing** (per `rejection-detection`): read the rejection evidence through the access layer — the issue comments posted after the backward transition (the QA rejection comment) and the review threads on the rejected PR via `lisa-github-read-issue` — assemble ONE candidate learning (rule, why, provenance linking the rejection comment + rejected PR, evidence links, scope hint, triggering issue, fingerprint `sll4-sha1(rule\ntriggering_issue)[:12]`), and route it to the `lisa-persist-learning` skill. If that skill is absent, record the candidate as a comment carrying a **visible prose line plus** the marker (a bare marker renders as an empty bubble) — `Recorded a candidate learning from this rejection (queued for the judgment gate): <one-line candidate rule>.` then `<!-- [lisa-rejection-candidate] key=<issue>-<transition-ts> -->` — and proceed. Dedupe on `<issue>-<backward-transition-timestamp>` — a second re-claim produces no duplicate. Unreadable/absent evidence → no candidate, still implement.

package/plugins/lisa/skills/lisa-github-write-issue/SKILL.md

@@ -6,6 +6,12 @@ allowed-tools: ["Bash", "Skill", "Read"]
 
 # Write GitHub Issue: $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/skills/lisa-jira-build-intake/SKILL.md

@@ -349,6 +349,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 ticket at the **top of 3b, BEFORE** the `$READY → $CLAIMED` transition — after the transition the current-status signal is gone. Read the ticket's status changelog via `lisa-atlassian-access operation: changelog key: <TICKET>` and classify it `rejection-reclaim | forward-only | never-left-ready | unknown` (a `rejection-reclaim` is a changelog entry whose `to` is the configured `$READY` status following an earlier `review`/`done`-ward status). Status names come from `.lisa.config.json`, never hardcoded. A failing/absent changelog yields `unknown` and the claim proceeds — detection never blocks the build. Tickets 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.
 
 **On `rejection-reclaim`, reflect before re-implementing** (per `rejection-detection`): read the rejection evidence through the access layer — the ticket comments posted after the backward transition (the QA rejection comment) via `lisa-atlassian-access operation: read-ticket` / `comment` reads and the review threads on the rejected PR — assemble ONE candidate learning (rule, why, provenance linking the rejection comment + rejected PR, evidence links, scope hint, triggering issue, fingerprint `sll4-sha1(rule\ntriggering_issue)[:12]`), and route it to the `lisa-persist-learning` skill. If that skill is absent, record the candidate via `lisa-atlassian-access operation: comment` as a comment carrying a **visible prose line plus** the marker (a bare marker renders as an empty bubble) — `Recorded a candidate learning from this rejection (queued for the judgment gate): <one-line candidate rule>.` then `<!-- [lisa-rejection-candidate] key=<issue>-<transition-ts> -->` — and proceed. Dedupe on `<issue>-<backward-transition-timestamp>` — a second re-claim produces no duplicate. Unreadable/absent evidence → no candidate, still implement.

package/plugins/lisa/skills/lisa-jira-write-ticket/SKILL.md

@@ -6,6 +6,12 @@ allowed-tools: ["Bash", "Skill"]
 
 # Write JIRA Ticket: $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/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/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/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/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/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/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/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/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/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/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)