@codyswann/lisa 4.55.4 → 4.55.6

package/plugins/lisa-rails-agy/skills/e2e-coverage-gaps/SKILL.md

@@ -1,16 +1,18 @@
 ---
 name: e2e-coverage-gaps
-description: Playwright/e2e coverage-gap explorer that FEEDS THE LIFECYCLE. Use when asked to find paths the automated end-to-end suite does NOT cover — routes with no test at all, or flows that are only happy-path tested (missing error, validation, permission, empty, loading, and edge states). It inventories the app's routes and the existing Playwright tests, explores the running app to confirm each uncovered or under-covered path is real and reachable, and files one build-ready missing-test ticket per gap via lisa-tracker-write. For human usability/experience issues (confusing, cramped, or broken UI), use the lisa-exploratory-qa skill instead.
+description: Playwright/e2e coverage-gap explorer that FEEDS THE LIFECYCLE. Use when asked to find paths the automated end-to-end suite does NOT cover — routes with no test at all, or flows that are only happy-path tested (missing error, validation, permission, empty, loading, and edge states). It inventories the app's routes and the existing Playwright tests, explores the running app to confirm each uncovered or under-covered path is real and reachable, and files bounded build-ready work for worthwhile test gaps via lisa-tracker-write. For human usability/experience issues (confusing, cramped, or broken UI), use the lisa-exploratory-qa skill instead.
 ---
 
 # E2E Coverage Gaps
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
 ## Overview
 
 Find where the automated end-to-end (Playwright) suite is **blind**: routes with no test at all, and
 flows that only assert the **happy path** while ignoring error, permission, empty, loading, and edge
 cases. Inventory the app's routes and the existing tests, explore the running app to confirm each gap
-is real and reachable, then file each gap as a **build-ready missing-test work item** so it enters the
+is real and reachable, then group worthwhile gaps into **bounded build-ready missing-test work items** so it enters the
 Lisa lifecycle.
 
 This skill is purely about **automated-coverage gaps**. It does not judge whether the UI is confusing
@@ -62,15 +64,18 @@ Map routes/flows against existing coverage and classify each gap:
 
 ### 5. Explore to Confirm
 
+- Apply `do-it-now`'s **Worth doing** guidance: missing coverage alone is not a defect. Identify a required behavior or credible material risk; decline low-value gaps without filing and group related accepted gaps.
 - Navigate each candidate gap in the running app to confirm it is real, reachable, and worth a test.
   Discard gaps that aren't actually reachable or are intentionally out of scope.
 
-### 6. File One Ticket Per Gap
+### 6. File Bounded Work for Accepted Gaps
 
-Each confirmed gap becomes a leaf **missing-test** work item created via `lisa-tracker-write` (the
+Each accepted gap or coherent group becomes a leaf **missing-test** work item created 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), `issue_type: Task`, **build-ready per the `ready` flag
-(default `true`)**. Pass `build_ready` explicitly on every create. Each ticket MUST specify:
+(default `true`)**. For `ready=true`, pass `build_ready: true`. For `ready=false`,
+pass `human_gate: "Coverage work explicitly held for operator prioritization"` instead.
+Each ticket MUST specify:
 
 - The **route/flow** and the exact **user behavior the test must assert**.
 - **Which scenario is missing** (uncovered vs which non-happy path: error / validation / permission /
@@ -80,11 +85,18 @@ call a vendor `*-write-*` skill directly), `issue_type: Task`, **build-ready per
 
 ### Idempotency — don't spam duplicates
 
-Before creating a ticket, search the tracker for an **open** ticket carrying a stable marker
-`[lisa-e2e-coverage-gaps] <gap-key>` in its body (the `<gap-key>` is a stable slug of route + missing
-scenario, e.g. `checkout/payment-declined` or `dashboard/empty-state@mobile`). If one exists, reference
-it instead of duplicating. **Match by the marker, never by title.** A *closed* prior ticket does not
-suppress a genuine new gap.
+Before creating a ticket, follow `rejection-detection` — **Proposal rejection memory**:
+use `<!-- [lisa-e2e-coverage-gaps] key=<candidate-key> -->` with the normalized route +
+missing scenario hashed deterministically by that rule's existing formula. Search open AND
+closed tickets, including its body-enumeration fallback for search-index lag. Match by the
+marker for any constituent gap, never by title alone. Reuse open matches. For legacy issues
+without a marker or with the older `[lisa-e2e-coverage-gaps] <gap-key>` slug marker, read
+bodies and closing discussions to establish a semantic match; title similarity
+alone is insufficient. A **Not planned** decision suppresses the same accepted
+limitation, even when seen again later. Re-propose only for a materially changed
+consequence, requirement, or risk that addresses the decline. A completed fix may
+have a real regression, which must be verified before filing. Grouped work retains
+the constituent gap markers so a later pass can find it.
 
 ## Output
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "4.55.4",
+  "version": "4.55.6",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-copilot/commands/lisa/e2e-coverage-gaps.md

@@ -1,7 +1,7 @@
 ---
-description: "Explore gaps in the automated Playwright/e2e suite: inventory the app's routes and existing tests, find routes with no coverage or flows tested only on the happy path (missing error, permission, empty, loading, and edge cases), confirm each in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write. The optional ready flag (default true) controls build-ready vs backlog. For human usability issues, use exploratory-qa instead."
+description: "Explore gaps in the automated Playwright/e2e suite: inventory the app's routes and existing tests, find routes with no coverage or flows tested only on the happy path (missing error, permission, empty, loading, and edge cases), confirm each in the running app, and file bounded build-ready work for worthwhile test gaps via lisa-tracker-write. The optional ready flag (default true) controls build-ready vs backlog. For human usability issues, use exploratory-qa instead."
 allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-rails:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS
+Use the /lisa-rails:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file bounded build-ready work for worthwhile test gaps via lisa-tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS

package/plugins/lisa-rails-copilot/skills/e2e-coverage-gaps/SKILL.md

@@ -1,16 +1,18 @@
 ---
 name: e2e-coverage-gaps
-description: Playwright/e2e coverage-gap explorer that FEEDS THE LIFECYCLE. Use when asked to find paths the automated end-to-end suite does NOT cover — routes with no test at all, or flows that are only happy-path tested (missing error, validation, permission, empty, loading, and edge states). It inventories the app's routes and the existing Playwright tests, explores the running app to confirm each uncovered or under-covered path is real and reachable, and files one build-ready missing-test ticket per gap via lisa-tracker-write. For human usability/experience issues (confusing, cramped, or broken UI), use the lisa-exploratory-qa skill instead.
+description: Playwright/e2e coverage-gap explorer that FEEDS THE LIFECYCLE. Use when asked to find paths the automated end-to-end suite does NOT cover — routes with no test at all, or flows that are only happy-path tested (missing error, validation, permission, empty, loading, and edge states). It inventories the app's routes and the existing Playwright tests, explores the running app to confirm each uncovered or under-covered path is real and reachable, and files bounded build-ready work for worthwhile test gaps via lisa-tracker-write. For human usability/experience issues (confusing, cramped, or broken UI), use the lisa-exploratory-qa skill instead.
 ---
 
 # E2E Coverage Gaps
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
 ## Overview
 
 Find where the automated end-to-end (Playwright) suite is **blind**: routes with no test at all, and
 flows that only assert the **happy path** while ignoring error, permission, empty, loading, and edge
 cases. Inventory the app's routes and the existing tests, explore the running app to confirm each gap
-is real and reachable, then file each gap as a **build-ready missing-test work item** so it enters the
+is real and reachable, then group worthwhile gaps into **bounded build-ready missing-test work items** so it enters the
 Lisa lifecycle.
 
 This skill is purely about **automated-coverage gaps**. It does not judge whether the UI is confusing
@@ -62,15 +64,18 @@ Map routes/flows against existing coverage and classify each gap:
 
 ### 5. Explore to Confirm
 
+- Apply `do-it-now`'s **Worth doing** guidance: missing coverage alone is not a defect. Identify a required behavior or credible material risk; decline low-value gaps without filing and group related accepted gaps.
 - Navigate each candidate gap in the running app to confirm it is real, reachable, and worth a test.
   Discard gaps that aren't actually reachable or are intentionally out of scope.
 
-### 6. File One Ticket Per Gap
+### 6. File Bounded Work for Accepted Gaps
 
-Each confirmed gap becomes a leaf **missing-test** work item created via `lisa-tracker-write` (the
+Each accepted gap or coherent group becomes a leaf **missing-test** work item created 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), `issue_type: Task`, **build-ready per the `ready` flag
-(default `true`)**. Pass `build_ready` explicitly on every create. Each ticket MUST specify:
+(default `true`)**. For `ready=true`, pass `build_ready: true`. For `ready=false`,
+pass `human_gate: "Coverage work explicitly held for operator prioritization"` instead.
+Each ticket MUST specify:
 
 - The **route/flow** and the exact **user behavior the test must assert**.
 - **Which scenario is missing** (uncovered vs which non-happy path: error / validation / permission /
@@ -80,11 +85,18 @@ call a vendor `*-write-*` skill directly), `issue_type: Task`, **build-ready per
 
 ### Idempotency — don't spam duplicates
 
-Before creating a ticket, search the tracker for an **open** ticket carrying a stable marker
-`[lisa-e2e-coverage-gaps] <gap-key>` in its body (the `<gap-key>` is a stable slug of route + missing
-scenario, e.g. `checkout/payment-declined` or `dashboard/empty-state@mobile`). If one exists, reference
-it instead of duplicating. **Match by the marker, never by title.** A *closed* prior ticket does not
-suppress a genuine new gap.
+Before creating a ticket, follow `rejection-detection` — **Proposal rejection memory**:
+use `<!-- [lisa-e2e-coverage-gaps] key=<candidate-key> -->` with the normalized route +
+missing scenario hashed deterministically by that rule's existing formula. Search open AND
+closed tickets, including its body-enumeration fallback for search-index lag. Match by the
+marker for any constituent gap, never by title alone. Reuse open matches. For legacy issues
+without a marker or with the older `[lisa-e2e-coverage-gaps] <gap-key>` slug marker, read
+bodies and closing discussions to establish a semantic match; title similarity
+alone is insufficient. A **Not planned** decision suppresses the same accepted
+limitation, even when seen again later. Re-propose only for a materially changed
+consequence, requirement, or risk that addresses the decline. A completed fix may
+have a real regression, which must be verified before filing. Grouped work retains
+the constituent gap markers so a later pass can find it.
 
 ## Output
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "4.55.4",
+  "version": "4.55.6",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails-cursor/commands/lisa/e2e-coverage-gaps.md

@@ -1,7 +1,7 @@
 ---
-description: "Explore gaps in the automated Playwright/e2e suite: inventory the app's routes and existing tests, find routes with no coverage or flows tested only on the happy path (missing error, permission, empty, loading, and edge cases), confirm each in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write. The optional ready flag (default true) controls build-ready vs backlog. For human usability issues, use exploratory-qa instead."
+description: "Explore gaps in the automated Playwright/e2e suite: inventory the app's routes and existing tests, find routes with no coverage or flows tested only on the happy path (missing error, permission, empty, loading, and edge cases), confirm each in the running app, and file bounded build-ready work for worthwhile test gaps via lisa-tracker-write. The optional ready flag (default true) controls build-ready vs backlog. For human usability issues, use exploratory-qa instead."
 allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---
 
-Use the /lisa-rails:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file one build-ready missing-test ticket per gap via lisa:tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS
+Use the /lisa-rails:e2e-coverage-gaps skill to inventory the app's routes and the existing Playwright suite, find uncovered and happy-path-only paths, confirm each gap in the running app, and file bounded build-ready work for worthwhile test gaps via lisa-tracker-write (build-ready per the ready flag, default true). For human usability/experience findings, use /lisa:exploratory-qa. $ARGUMENTS

package/plugins/lisa-rails-cursor/skills/e2e-coverage-gaps/SKILL.md

@@ -1,16 +1,18 @@
 ---
 name: e2e-coverage-gaps
-description: Playwright/e2e coverage-gap explorer that FEEDS THE LIFECYCLE. Use when asked to find paths the automated end-to-end suite does NOT cover — routes with no test at all, or flows that are only happy-path tested (missing error, validation, permission, empty, loading, and edge states). It inventories the app's routes and the existing Playwright tests, explores the running app to confirm each uncovered or under-covered path is real and reachable, and files one build-ready missing-test ticket per gap via lisa-tracker-write. For human usability/experience issues (confusing, cramped, or broken UI), use the lisa-exploratory-qa skill instead.
+description: Playwright/e2e coverage-gap explorer that FEEDS THE LIFECYCLE. Use when asked to find paths the automated end-to-end suite does NOT cover — routes with no test at all, or flows that are only happy-path tested (missing error, validation, permission, empty, loading, and edge states). It inventories the app's routes and the existing Playwright tests, explores the running app to confirm each uncovered or under-covered path is real and reachable, and files bounded build-ready work for worthwhile test gaps via lisa-tracker-write. For human usability/experience issues (confusing, cramped, or broken UI), use the lisa-exploratory-qa skill instead.
 ---
 
 # E2E Coverage Gaps
 
+On runtimes without the rule tree (Antigravity), read **Worth doing** in `lisa-track` for the same value and decline policy.
+
 ## Overview
 
 Find where the automated end-to-end (Playwright) suite is **blind**: routes with no test at all, and
 flows that only assert the **happy path** while ignoring error, permission, empty, loading, and edge
 cases. Inventory the app's routes and the existing tests, explore the running app to confirm each gap
-is real and reachable, then file each gap as a **build-ready missing-test work item** so it enters the
+is real and reachable, then group worthwhile gaps into **bounded build-ready missing-test work items** so it enters the
 Lisa lifecycle.
 
 This skill is purely about **automated-coverage gaps**. It does not judge whether the UI is confusing
@@ -62,15 +64,18 @@ Map routes/flows against existing coverage and classify each gap:
 
 ### 5. Explore to Confirm
 
+- Apply `do-it-now`'s **Worth doing** guidance: missing coverage alone is not a defect. Identify a required behavior or credible material risk; decline low-value gaps without filing and group related accepted gaps.
 - Navigate each candidate gap in the running app to confirm it is real, reachable, and worth a test.
   Discard gaps that aren't actually reachable or are intentionally out of scope.
 
-### 6. File One Ticket Per Gap
+### 6. File Bounded Work for Accepted Gaps
 
-Each confirmed gap becomes a leaf **missing-test** work item created via `lisa-tracker-write` (the
+Each accepted gap or coherent group becomes a leaf **missing-test** work item created 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), `issue_type: Task`, **build-ready per the `ready` flag
-(default `true`)**. Pass `build_ready` explicitly on every create. Each ticket MUST specify:
+(default `true`)**. For `ready=true`, pass `build_ready: true`. For `ready=false`,
+pass `human_gate: "Coverage work explicitly held for operator prioritization"` instead.
+Each ticket MUST specify:
 
 - The **route/flow** and the exact **user behavior the test must assert**.
 - **Which scenario is missing** (uncovered vs which non-happy path: error / validation / permission /
@@ -80,11 +85,18 @@ call a vendor `*-write-*` skill directly), `issue_type: Task`, **build-ready per
 
 ### Idempotency — don't spam duplicates
 
-Before creating a ticket, search the tracker for an **open** ticket carrying a stable marker
-`[lisa-e2e-coverage-gaps] <gap-key>` in its body (the `<gap-key>` is a stable slug of route + missing
-scenario, e.g. `checkout/payment-declined` or `dashboard/empty-state@mobile`). If one exists, reference
-it instead of duplicating. **Match by the marker, never by title.** A *closed* prior ticket does not
-suppress a genuine new gap.
+Before creating a ticket, follow `rejection-detection` — **Proposal rejection memory**:
+use `<!-- [lisa-e2e-coverage-gaps] key=<candidate-key> -->` with the normalized route +
+missing scenario hashed deterministically by that rule's existing formula. Search open AND
+closed tickets, including its body-enumeration fallback for search-index lag. Match by the
+marker for any constituent gap, never by title alone. Reuse open matches. For legacy issues
+without a marker or with the older `[lisa-e2e-coverage-gaps] <gap-key>` slug marker, read
+bodies and closing discussions to establish a semantic match; title similarity
+alone is insufficient. A **Not planned** decision suppresses the same accepted
+limitation, even when seen again later. Re-propose only for a materially changed
+consequence, requirement, or risk that addresses the decline. A completed fix may
+have a real regression, which must be verified before filing. Grouped work retains
+the constituent gap markers so a later pass can find it.
 
 ## Output
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.55.4",
+  "version": "4.55.6",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.55.4",
+  "version": "4.55.6",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.55.4",
+  "version": "4.55.6",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.55.4",
+  "version": "4.55.6",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "4.55.4",
+  "version": "4.55.6",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.55.4",
+  "version": "4.55.6",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.55.4",
+  "version": "4.55.6",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki/scripts/_wiki-lib.mjs

@@ -125,10 +125,10 @@ export function extractMarkdownLinks(text) {
   return targets;
 }
 
-/** Extract plain-text `Source: <path>.md` citations that look like wiki paths. */
+/** Extract bare or backticked `Source: <path>.md` citations that look like wiki paths. */
 export function extractCitations(text) {
   const cites = [];
-  const re = /Source:\s*([^\s)]+\.md)/g;
+  const re = /Source:\s*`?([^\s)`]+\.md)`?/g;
   let m;
   while ((m = re.exec(text)) !== null) {
     const c = m[1];

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.55.4",
+  "version": "4.55.6",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-agy/scripts/_wiki-lib.mjs

@@ -125,10 +125,10 @@ export function extractMarkdownLinks(text) {
   return targets;
 }
 
-/** Extract plain-text `Source: <path>.md` citations that look like wiki paths. */
+/** Extract bare or backticked `Source: <path>.md` citations that look like wiki paths. */
 export function extractCitations(text) {
   const cites = [];
-  const re = /Source:\s*([^\s)]+\.md)/g;
+  const re = /Source:\s*`?([^\s)`]+\.md)`?/g;
   let m;
   while ((m = re.exec(text)) !== null) {
     const c = m[1];

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.55.4",
+  "version": "4.55.6",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-copilot/scripts/_wiki-lib.mjs

@@ -125,10 +125,10 @@ export function extractMarkdownLinks(text) {
   return targets;
 }
 
-/** Extract plain-text `Source: <path>.md` citations that look like wiki paths. */
+/** Extract bare or backticked `Source: <path>.md` citations that look like wiki paths. */
 export function extractCitations(text) {
   const cites = [];
-  const re = /Source:\s*([^\s)]+\.md)/g;
+  const re = /Source:\s*`?([^\s)`]+\.md)`?/g;
   let m;
   while ((m = re.exec(text)) !== null) {
     const c = m[1];

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.55.4",
+  "version": "4.55.6",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-wiki-cursor/scripts/_wiki-lib.mjs

@@ -125,10 +125,10 @@ export function extractMarkdownLinks(text) {
   return targets;
 }
 
-/** Extract plain-text `Source: <path>.md` citations that look like wiki paths. */
+/** Extract bare or backticked `Source: <path>.md` citations that look like wiki paths. */
 export function extractCitations(text) {
   const cites = [];
-  const re = /Source:\s*([^\s)]+\.md)/g;
+  const re = /Source:\s*`?([^\s)`]+\.md)`?/g;
   let m;
   while ((m = re.exec(text)) !== null) {
     const c = m[1];

package/plugins/src/base/commands/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/src/base/rules/eager/do-it-now.md

@@ -1,11 +1,11 @@
 # 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](../reference/do-it-now.md).
+Full guidance: [reference/do-it-now.md](../reference/do-it-now.md).

package/plugins/src/base/rules/eager/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.
+
 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/src/base/rules/eager/upstream-to-lisa.md

@@ -1,25 +1,14 @@
 # Upstream To Lisa (load-bearing)
 
-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 — a bug or gap in a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, or a governance pattern worth generalizing back to the templates. The defining test: **does the root cause live in a Lisa-distributed artifact?** If yes, file upstream, regardless of whether your local fix survives the next `lisa apply`.
+When a worthwhile fix belongs to a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, fix its source upstream so other projects benefit. Apply `do-it-now`'s **Worth doing** guidance first: Lisa ownership determines where accepted work belongs, not whether every imperfection deserves a ticket.
 
-Tell-tale signs include:
+For an accepted defect:
 
-- The file is Lisa-managed (carries Lisa governance markers, or lives in a path Lisa owns) and any edit you make here would be **overwritten on the next `lisa apply`**.
-- The file was created from a Lisa `create-only` template and carries language such as `Lisa will not overwrite it`. That header is a positive upstream signal: existing repos will keep their local copy, but every newly scaffolded repo still inherits the broken template until Lisa is fixed.
+1. Apply the smallest safe local stopgap if needed to unblock the current task.
+2. Search open and closed Lisa issues. Reuse a matching open issue. Honor **Not planned** decisions under `rejection-detection` before filing the concrete consequence and smallest durable fix; do not refile an accepted limitation.
 
-When that happens, you have **two obligations — do both**:
+For **copy-overwrite** files, a local fix may be overwritten on the next `lisa apply`. For **create-only** templates, the local fix survives, but new projects still inherit the source defect. Both can justify an upstream fix; neither bypasses the value decision.
 
-1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. For copy-overwrite files, treat the local fix as temporary because it will be clobbered when the upstream fix ships and Lisa re-applies. For create-only files, keep the local fix because Lisa will not overwrite it, but still file upstream so new repos stop inheriting the bug.
-2. **File an upstream issue in the Lisa repository.** Use the `github-write-issue` skill (`lisa-github-write-issue`) to create an issue **in Lisa's source repo `CodySwannGT/lisa`** (pass it as the target repo, e.g. `gh ... --repo CodySwannGT/lisa`) — **not** in this project's own repo. Capture: the root cause, the symptom you hit here, and the proposed durable fix in Lisa's templates/rules/skills.
+Decline low-value observations without filing or escalating them. Group related small worthwhile repairs when appropriate. Do not add permanent machinery merely because an enforcement gap can be described.
 
-## Do not
-
-- Do **not** only fix it locally and move on — even when a create-only local fix survives, the broken template keeps shipping to every new repo until it is fixed upstream.
-- Do **not** try to edit Lisa's templates from inside this project — you are not in the Lisa repo; those edits don't exist upstream and get overwritten.
-- Do **not** file the issue in this project's repo — it must land in `CodySwannGT/lisa`.
-
-If you lack access to file an issue in `CodySwannGT/lisa`, surface that to the user with the proposed issue contents rather than silently dropping it.
-
-> Not applicable when you are already working **inside the Lisa repo itself** — there the fix is local, so just make it directly.
-
-Full procedure: [reference/upstream-to-lisa.md](../reference/upstream-to-lisa.md).
+Inside Lisa, repair the shared source and regenerate the equivalent agent surfaces. Full procedure: [reference/upstream-to-lisa.md](../reference/upstream-to-lisa.md).

package/plugins/src/base/rules/reference/claim-time-guards.md

@@ -41,6 +41,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/src/base/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/src/base/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