@codyswann/lisa 4.33.11 → 4.33.13

package/plugins/src/base/hooks/parity-safety-net.sh

@@ -1019,14 +1019,40 @@ readonly GIT_CMD='(^|[^[:alnum:]_-])git[[:space:]]+'"$GIT_GLOBAL_OPTS"
 # match. The preceding-char class still excludes `.`, `/`, and `-` to keep
 # `--rm`-style flags and `foo.rm` names out.
 readonly RM_CMD='(^|[^[:alnum:]_./-])([[:alnum:]_./-]*/)?rm'
+# Where a recursive-forced flag cluster is allowed to END.
+#
+# It used to be `([[:space:]]|$)` — whitespace or end of segment — and a closing
+# parenthesis is neither, so a SUBSHELL-wrapped pipeline fell out of every guard
+# built on these two patterns while its brace-wrapped twin was caught: `{ find
+# .git -type d | parallel rm -rf; }` matched because the `;` supplied the
+# boundary, and `(find .git -type d | parallel rm -rf)` did not (issue #3494).
+#
+# So the two STATEMENT-GROUPING terminators join whitespace here, and nothing
+# else. The general spelling — "any character that cannot be part of a flag",
+# `([^[:alnum:]-]|$)` — is the more principled statement of the intent, and is
+# deliberately NOT used: these patterns feed the rm TARGET WALK, the guard with
+# this file's longest false-positive history, and it would newly match ordinary
+# prose punctuation (`echo "rm -rf, then …"` on the comma). Paren and semicolon
+# buy the brace/paren parity the defect is about and buy nothing else.
+#
+# The cluster must still END at the boundary, so `-rfoo` is not read as `-rf`.
+readonly RM_RF_END='([[:space:];)]|$)'
 # rm invoked with BOTH a recursive and a force flag — clustered (-rf/-fr, any
 # extra letters) or split, in either order. The split gate pairs ANY recursive
 # form (short cluster containing r, or --recursive) with ANY force form (short
 # cluster containing f, or --force), so mixed spellings like `rm -r --force /`
 # and `rm --recursive -f /` cannot slip between the short/short and long/long
 # alternations (PR #1976 review).
-readonly RM_RF_CLUSTER="$RM_CMD"'([[:space:]]+-[[:alnum:]-]+)*[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)([[:space:]]|$)'
-readonly RM_RF_SPLIT="$RM_CMD"'(([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*r[[:alnum:]]*|--recursive)([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*f[[:alnum:]]*|--force)([[:space:]]|$)|([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*f[[:alnum:]]*|--force)([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*r[[:alnum:]]*|--recursive)([[:space:]]|$))'
+#
+# The FLAG TAILS are named separately from the `rm`-anchored patterns because
+# the find/xargs family below needs the identical flag vocabulary against a
+# different verb anchor. Before #3494 it carried its own short-cluster-only copy
+# and therefore missed `rm --recursive --force` — a divergence that could only
+# happen because the spelling set was written twice.
+readonly RM_RF_TAIL_CLUSTER='([[:space:]]+-[[:alnum:]-]+)*[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)'"$RM_RF_END"
+readonly RM_RF_TAIL_SPLIT='(([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*r[[:alnum:]]*|--recursive)([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*f[[:alnum:]]*|--force)'"$RM_RF_END"'|([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*f[[:alnum:]]*|--force)([[:space:]][^;&|]*)?[[:space:]](-[[:alnum:]]*r[[:alnum:]]*|--recursive)'"$RM_RF_END"')'
+readonly RM_RF_CLUSTER="$RM_CMD$RM_RF_TAIL_CLUSTER"
+readonly RM_RF_SPLIT="$RM_CMD$RM_RF_TAIL_SPLIT"
 
 # 1. Recursive forced delete (`rm -rf`) of a filesystem root, home, or top-level
 #    wildcard. Two gates ANDed: the statement must invoke `rm` with BOTH a
@@ -1667,8 +1693,31 @@ fi
 if matches '(^|[^[:alnum:]_./-])find[[:space:]][^;&|]*-exec[[:space:]]+rm[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)([[:space:]]|$)'; then
   block "find -exec rm -rf performs a recursive forced delete on unreviewed paths"
 fi
-if matches '(^|[^[:alnum:]_./-])xargs[[:space:]]([^;&|]*[[:space:]])?rm[[:space:]]+(-[[:alnum:]]*r[[:alnum:]]*f|-[[:alnum:]]*f[[:alnum:]]*r)([[:space:]]|$)'; then
-  block "xargs rm -rf performs a recursive forced delete on dynamic stdin input"
+# A command that reads its operands from STDIN and runs a program on them. The
+# targets are therefore whatever the upstream stage emitted, which is exactly
+# what makes a recursive forced delete behind one unauditable.
+#
+# Three fail-opens closed here (issue #3494), all of them the same mistake —
+# this rule was written standalone instead of inheriting vocabulary the file
+# already had:
+#
+#   1. The old prefix was `(^|[^[:alnum:]_./-])xargs`, whose excluded class
+#      contains `/`, so the character before `xargs` in `/usr/bin/xargs` was
+#      itself disqualifying and a PATH-SPELLED invocation never matched.
+#      `gxargs` — the GNU findutils spelling shipped by macOS package managers —
+#      failed the same way on the alphanumeric side. RM_CMD above solved this
+#      exact problem for `rm` by putting the boundary before the WHOLE path and
+#      making the directory part optional; that shape is reused verbatim.
+#   2. `parallel` was absent. It is a drop-in `xargs` substitute reaching the
+#      same delete on the same unaudited stdin, and guard 14 below already had
+#      to name it in its own evidence — it was missing only here.
+#   3. The flag set was a short-cluster-only copy, so `rm --recursive --force`
+#      was allowed where `rm -rf` was refused. It now uses the SAME tails as the
+#      rm walk, which is what makes that class of divergence unrepeatable.
+readonly STDIN_DELETER='(^|[^[:alnum:]_./-])([[:alnum:]_./-]*/)?(g?xargs|parallel)[[:space:]]([^;&|]*[[:space:]])?rm'
+if matches "$STDIN_DELETER$RM_RF_TAIL_CLUSTER" \
+  || matches "$STDIN_DELETER$RM_RF_TAIL_SPLIT"; then
+  block "xargs/parallel rm -rf performs a recursive forced delete on dynamic stdin input"
 fi
 
 # 12. Disk destroyers, always on (exceeds upstream, which only scans these

package/plugins/src/base/rules/eager/blocker-containment.md

@@ -37,6 +37,15 @@ A dependency need not deliver code. A blocker **closed as completed** that posit
 
 This requires a **positive determination**, never an absence. "I could not find a PR" is fail-closed under the rule above; "the item declares it ships no code" is this carve-out. Collapsing the two turns the carve-out into a universal bypass.
 
+## Ancestry answers a development question, not a deployment one
+
+This rule requires an ancestry test. `deployed-state-readback` says ancestry is **never** evidence of deployment. Both are correct — they answer different questions:
+
+- **Here:** *is the blocker's code on the branch I will build from?* An `is blocked by` link is a **development** dependency, satisfied once the code is on your base branch. Ancestry is the right test, and waiting for production strands dependents.
+- **There:** *is this thing live?* A commit can be an ancestor of the default branch and never have shipped — a discarded pipeline execution leaves it merged and undeployed. Ancestry is provably insufficient.
+
+Never use this rule's test to answer a "does it already exist in the environment?" question.
+
 ## Human override
 
 A human statement on the item that the dependency is satisfied clears it, and outranks a failed containment check. Record it as the reason in the run record. This is the escape hatch for cross-repo and untracked dependencies, and it is the only one. An automation may never synthesize one on its own behalf.

package/plugins/src/base/rules/eager/deployed-state-readback.md

@@ -0,0 +1,47 @@
+# Deployed-State Readback (load-bearing)
+
+**A build ticket asserts that something is missing from a running system. That assertion must come from reading the running system, never from reading the source.** Source tells you what the code says; only the environment tells you what is deployed. A ticket authored from source alone specifies work against a system it has not observed.
+
+**One vendor-neutral contract, cited by** the Phase 2 research step of `lisa-notion-to-tracker`, `lisa-github-to-tracker`, `lisa-linear-to-tracker`, and `lisa-confluence-to-tracker` (the `leaf-only-lifecycle` / `repo-scope-split` precedent: one shared slug, never four divergent forks).
+
+## The waiver this replaces was scoped to the wrong axis
+
+Phase 2 has two halves — codebase research and a live product walkthrough — and the walkthrough was waived for work that is *"purely backend with no user-visible surface."*
+
+"Is it user-facing?" is a question about the **observation method**: browser, API client, or resource readback. It was being used to answer a different question — **"should we observe live state at all?"** Backend, infrastructure, CI, and dependency work all have live state. It simply is not visible through a browser. Waiving the browser step correctly, and live grounding along with it, is what let tickets be authored for work that had already shipped.
+
+So the skip is **not** "no live check". It is **a different probe**.
+
+## Routing
+
+| The work | Probe |
+|---|---|
+| User-facing surface | `lisa-product-walkthrough` against the running app |
+| HTTP / API backend | Call the deployed endpoint and read the response |
+| Infrastructure / IaC | **Describe the deployed resource in the account** |
+| CI / workflow config | Read the config the running pipeline actually used |
+| Dependency / package pin | Read the **installed** artifact, and the registry |
+| Screen that does not exist yet | No probe; record why |
+
+## What is never accepted as evidence of deployment
+
+**Git ancestry, a merge check, and `cdk synth` are not deployment evidence.** A commit can be an ancestor of the default branch and never have shipped: a pipeline running `executionMode: SUPERSEDED` discards queued executions, so an intermediate commit's deploy is silently dropped. `git log`, a merge check, and a synth all report "present" while the environment does not have it.
+
+Read the deployed thing back. Do not infer it from anything upstream of the deploy.
+
+**This does not conflict with `blocker-containment`, which requires exactly the ancestry test this rule rejects.** The two answer different questions and both are right:
+
+- `blocker-containment` asks a **development** question — *is the blocker's code on the branch I will build from?* Ancestry is the correct and sufficient test.
+- This rule asks a **deployment** question — *is this live?* Ancestry is provably insufficient, per the discarded-execution case above.
+
+Neither may be used to answer the other's question.
+
+## An unanswerable probe is not a "no"
+
+If the deployed state cannot be read back — no credentials, no such environment, the resource is not addressable — **record that the check could not be performed**. Absence of evidence is not evidence of absence, and defaulting an unreadable probe to "not deployed" reintroduces the whole defect while appearing to satisfy the rule.
+
+## Record the readback on the ticket
+
+Write what was probed, how, and what came back. Claim-time triage then inherits evidence instead of re-deriving it from source — which is the same mistake one stage later.
+
+Full contract (per-lane probe definitions, the discarded-execution hazard, the doctrine this applies, and worked examples): [reference/deployed-state-readback.md](../reference/deployed-state-readback.md).

package/plugins/src/base/rules/reference/blocker-containment.md

@@ -85,6 +85,19 @@ An explicit human statement on the dependent — in the body or in a comment —
 
 This is the sanctioned escape hatch for the cases the predicate genuinely cannot reach: a cross-repository blocker (two repositories have no shared ancestry, so containment is undefined), a dependency on work tracked outside any connected system, or a vendor whose PR linkage is unreadable. It is the **only** escape hatch. An automation may never synthesize one on its own behalf.
 
+## Ancestry here, but never for a deployment question
+
+`deployed-state-readback` states that git ancestry, a merge check and `cdk synth` are never evidence that something is deployed. That is not a contradiction of the predicate above; the two rules answer different questions and each uses the test appropriate to its own.
+
+| Rule | Question | Ancestry |
+|---|---|---|
+| this rule | **Development** — is the blocker's code on the branch I will build from? | Correct and sufficient |
+| `deployed-state-readback` | **Deployment** — is this live? | Provably insufficient |
+
+An `is blocked by` link is satisfied once the code you need is on your base branch; whether it has reached production is irrelevant to whether you can build against it — that is the whole point of the #1112 case this rule preserves. A "this already exists, do not build it" claim is satisfied only by reading the running system back, because a discarded pipeline execution leaves a commit merged and unshipped while `git log` still reports it present.
+
+**Neither test may be used to answer the other's question.** A surface that needs both runs both.
+
 ## What this rule does not do
 
 It does not decide **when** a dependency edge should exist, dissolve an edge once satisfied, or govern what a surface does after clearing — re-dispatch, re-validation, and lifecycle transitions remain the consuming skill's business. It governs exactly one question: given an edge, is it satisfied.

package/plugins/src/base/rules/reference/deployed-state-readback.md

@@ -0,0 +1,90 @@
+# Deployed-State Readback
+
+A build ticket is a claim about a running system: *this is missing, build it.* The claim is only as good as the observation behind it, and until this rule the observation was optional for everything that did not render in a browser.
+
+It is a **single vendor-neutral contract** consumed by the Phase 2 research step of `lisa-notion-to-tracker`, `lisa-github-to-tracker`, `lisa-linear-to-tracker`, and `lisa-confluence-to-tracker`. Each cites this slug rather than restating the routing, exactly as they would cite `leaf-only-lifecycle` or `repo-scope-split`. Phase 2 had already forked into four near-identical copies; this is what stops them drifting further.
+
+## The failure this replaces
+
+Phase 2 is titled "Codebase + Live Product Research" and has two halves:
+
+- **2a — codebase research.** Source only, by construction.
+- **2b — live product walkthrough.** The only live-state input anywhere in the PRD-to-ticket path, gated on *"If the PRD touches existing user-facing surfaces"* and then waived outright: *"Skip 2b only when the work is purely backend with no user-visible surface, or affects a screen that does not yet exist in dev/prod."*
+
+So user-facing work got one live check and everything else got none. Backend, infrastructure, CI-config and dependency-pin work reached the build queue with **zero deployed-state evidence**, and nothing downstream closed the gap at authoring time: the `*-validate-issue` skills treat "live" as the live *tracker item*; the write skills' only "already exists" concept is the tracker-to-tracker `duplicates` relation; and `lisa-use-the-product`'s IaC lane defaults to `cdk synth` / `cdk diff` — still derived from source — and Phase 2 never routed non-user-facing work into it anyway.
+
+### The waiver was scoped to the wrong axis
+
+This is the whole diagnosis, and the fix follows from it.
+
+*"Is it user-facing?"* is a question about the **observation method** — do you need a browser, an API client, or a resource description call? It was being used to answer *"should we observe live state at all?"*
+
+Those come apart precisely outside the browser case. An infrastructure change has live state; a dependency pin has live state; a CI workflow has live state. None of them are visible through a browser, all of them are readable. The waiver treated "not observable *this way*" as "not observable", and every measured failure sat in that gap: tickets aimed at the wrong repository, tickets specifying the defect rather than the fix, tickets whose target version matched none of the four live version numbers in play, tickets for work that needed verification rather than implementation, and a ticket for behavior that had been in production for a month with a code comment already stating its intent verbatim.
+
+This is the same shape as `blocker-containment`'s defect: a proxy that holds in the common case, used as though it held in general.
+
+## The doctrine this applies
+
+Lisa already says this, three times over, in eager load-bearing rules — none of which the authoring path cited:
+
+- **`empirical-inquiry`** — *"find out empirically before you act… Do not reason your way to a confident-sounding answer from documentation, prior assumption, or training knowledge when the real system is right there and a quick probe would tell you the truth."*
+- **`verification`** — *"Never claim success without runtime evidence. 'The code looks correct' is not evidence."*
+- **`stale-state-claims`** — on assertions of state that expire. A PRD's *"X doesn't exist yet"* is exactly such a claim, and that rule names this outcome in advance: work *"re-planned as undone when it already shipped."*
+
+This rule is not new doctrine. It is those three, wired into the one path that was authoring claims about running systems without consulting any of them.
+
+## Routing — the skip is a different probe, never no probe
+
+Phase 2 selects a probe for each thing the candidate tickets would create or change:
+
+| The work | Probe | Reads |
+|---|---|---|
+| User-facing surface | `lisa-product-walkthrough` against `E2E_BASE_URL` | The running app |
+| HTTP / API backend | Call the deployed endpoint as the test identity | The running service |
+| Infrastructure / IaC | Describe the deployed resource in the account (`aws … describe-*`, provider read API) | The account |
+| CI / workflow config | Read the configuration the most recent pipeline run actually used | The pipeline |
+| Dependency / package pin | Read the **installed** artifact in the deployed tree, plus the registry | The artifact |
+| CLI / library | Invoke the published build's `--version` / read-only command | The published build |
+| Screen or resource that does not exist yet | None — record why, per the unanswerable-probe rule below | — |
+
+The probe is chosen by **what kind of thing it is**, never by whether a human could have clicked it.
+
+## What is never accepted as evidence of deployment
+
+**Git ancestry, a merge check, and `cdk synth` are not deployment evidence.**
+
+A commit can be an ancestor of the default branch and never have shipped. A deploy pipeline running `executionMode: SUPERSEDED` discards queued executions, so an intermediate commit's deploy is silently dropped. `git log` reports the commit present, a merge check reports it merged, and a synth reports the resource declared — while the environment does not have it. Every one of those signals is upstream of the deploy, and the deploy is the step that can fail silently.
+
+Read the deployed thing back. Do not infer it from anything upstream of the deploy.
+
+### This does not conflict with `blocker-containment`
+
+`blocker-containment` requires exactly the ancestry test this rule rejects. Both are correct, because they answer different questions:
+
+| Rule | Question | Ancestry |
+|---|---|---|
+| `blocker-containment` | **Development** — is the blocker's code on the branch I will build from? | Correct and sufficient |
+| this rule | **Deployment** — is this live? | Provably insufficient |
+
+An `is blocked by` link is satisfied when the code you need is on your base branch; whether it has reached production is irrelevant to whether you can build against it. A "this already exists" claim is satisfied only when the thing is running. **Neither test may be used to answer the other's question**, and a surface that needs both runs both.
+
+## An unanswerable probe is not a "no"
+
+If the deployed state cannot be read back — no credentials for the account, no such environment provisioned, the resource is not addressable from here — **record that the check could not be performed, and say which probe was attempted.**
+
+Defaulting an unreadable probe to "not deployed" reintroduces the entire defect while appearing to satisfy this rule, and it is the single most likely way to implement it wrongly. It is the same error `blocker-containment` guards with its fail-closed table and `lisa-repair-intake` guards with *"'No blocker found' is inconclusive, never clearance."* Absence of evidence is not evidence of absence.
+
+A ticket authored on an unanswerable probe is still allowed — some work genuinely cannot be grounded before it starts — but it carries the unanswered probe on its face, so the human at the gate and the agent at claim time both know the claim is ungrounded rather than confirmed.
+
+## Record the readback on the ticket
+
+Write what was probed, how, and what came back — the command or call, and the result. Two reasons:
+
+1. **Claim-time triage inherits evidence instead of re-deriving it.** `lisa-ticket-triage`'s `DUPLICATE_ALREADY_FIXED` verdict already demands empirical evidence; without a recorded readback it must reconstruct one from source, which is the same mistake one stage later.
+2. **An ungrounded ticket becomes visible as ungrounded.** A missing readback section is a signal, where a silently source-derived ticket looked identical to a grounded one.
+
+## What this rule does not do
+
+It does not decide whether the work is worth doing, size it, or govern anything after authoring. It governs one step: before a build ticket asserts that something is absent from a running system, that absence is observed rather than assumed.
+
+It also does not require a probe for work that creates something genuinely new — a resource with no deployed predecessor has nothing to read back, and that is the "does not exist yet" row above, recorded rather than skipped silently.

package/plugins/src/base/skills/lisa-confluence-to-tracker/SKILL.md

@@ -282,7 +282,14 @@ Identical to `lisa-notion-to-tracker` Phase 2. Two complementary inputs ground P
 
 **2b. Live product walkthrough.** If the PRD touches existing user-facing surfaces, invoke the `lisa-product-walkthrough` skill against `E2E_BASE_URL` using the test user from config.
 
-Skip 2b only when the work is purely backend with no user-visible surface, or affects a screen that does not yet exist in dev/prod.
+Skip the *walkthrough* only when the work has no user-visible surface, or affects a screen that does not yet exist in dev/prod — and when you skip it, run 2c instead. Skipping 2b never means authoring the ticket with no live-state grounding.
+
+**2c. Deployed-state readback — required whenever 2b does not apply.** Per the `blocker-containment`-style shared-slug precedent, cite the `deployed-state-readback` rule for the full contract; do not restate its routing table here.
+
+2b is waived for work with no user-visible surface. That waiver is about the **observation method**, not about whether to observe: backend, infrastructure, CI-config and dependency work all have live state, it is simply not visible through a browser. So the skip selects a **different probe**, never no probe — describe the deployed resource, call the deployed endpoint, read the configuration the last pipeline run used, read the *installed* artifact. For each thing the candidate tickets would create or change, confirm it is genuinely **absent from the deployed environment** before authoring a ticket for it, and record what was probed and what came back.
+
+**Git ancestry, a merge check and `cdk synth` are never deployment evidence** — a discarded pipeline execution leaves a commit merged and unshipped, and all three still report "present". **An unanswerable probe is not a "no"**: when the state cannot be read back, record that the check could not be performed rather than defaulting to absent.
+
 
 Walkthrough findings are attached to the originating Confluence PRD as a **footer comment** (Confluence has no general "page-level discussion attached to a heading" — footer comments are the page-level equivalent), via `lisa-atlassian-access` `operation: comment-page id: <PAGE-ID> kind: footer body: "..."`. Title the comment "Current product walkthrough — `<route>`". Inherited onto the resulting epic / stories under a `## Current Product` subsection.
 

package/plugins/src/base/skills/lisa-github-to-tracker/SKILL.md

@@ -269,7 +269,14 @@ Identical to `lisa-notion-to-tracker` Phase 2 / `lisa-confluence-to-tracker` / `
 
 **2b. Live product walkthrough.** If the PRD touches existing user-facing surfaces, invoke `lisa-product-walkthrough` against `E2E_BASE_URL` using the test user from config.
 
-Skip 2b only when the work is purely backend with no user-visible surface, or affects a screen that does not yet exist.
+Skip the *walkthrough* only when the work has no user-visible surface, or affects a screen that does not yet exist in dev/prod — and when you skip it, run 2c instead. Skipping 2b never means authoring the ticket with no live-state grounding.
+
+**2c. Deployed-state readback — required whenever 2b does not apply.** Per the `blocker-containment`-style shared-slug precedent, cite the `deployed-state-readback` rule for the full contract; do not restate its routing table here.
+
+2b is waived for work with no user-visible surface. That waiver is about the **observation method**, not about whether to observe: backend, infrastructure, CI-config and dependency work all have live state, it is simply not visible through a browser. So the skip selects a **different probe**, never no probe — describe the deployed resource, call the deployed endpoint, read the configuration the last pipeline run used, read the *installed* artifact. For each thing the candidate tickets would create or change, confirm it is genuinely **absent from the deployed environment** before authoring a ticket for it, and record what was probed and what came back.
+
+**Git ancestry, a merge check and `cdk synth` are never deployment evidence** — a discarded pipeline execution leaves a commit merged and unshipped, and all three still report "present". **An unanswerable probe is not a "no"**: when the state cannot be read back, record that the check could not be performed rather than defaulting to absent.
+
 
 Walkthrough findings are surfaced back to product via the orchestrating intake skill (`lisa-github-prd-intake`), which posts them as a comment on the PRD issue. This skill itself does NOT post to GitHub — it only reads. The walkthrough section is also inherited onto the resulting Epic / Stories under a `## Current Product` subsection.
 

package/plugins/src/base/skills/lisa-linear-to-tracker/SKILL.md

@@ -266,7 +266,14 @@ Identical to `lisa-notion-to-tracker` Phase 2 and `lisa-confluence-to-tracker` P
 
 **2b. Live product walkthrough.** If the PRD touches existing user-facing surfaces, invoke the `lisa-product-walkthrough` skill against `E2E_BASE_URL` using the test user from config.
 
-Skip 2b only when the work is purely backend with no user-visible surface, or affects a screen that does not yet exist in dev/prod.
+Skip the *walkthrough* only when the work has no user-visible surface, or affects a screen that does not yet exist in dev/prod — and when you skip it, run 2c instead. Skipping 2b never means authoring the ticket with no live-state grounding.
+
+**2c. Deployed-state readback — required whenever 2b does not apply.** Per the `blocker-containment`-style shared-slug precedent, cite the `deployed-state-readback` rule for the full contract; do not restate its routing table here.
+
+2b is waived for work with no user-visible surface. That waiver is about the **observation method**, not about whether to observe: backend, infrastructure, CI-config and dependency work all have live state, it is simply not visible through a browser. So the skip selects a **different probe**, never no probe — describe the deployed resource, call the deployed endpoint, read the configuration the last pipeline run used, read the *installed* artifact. For each thing the candidate tickets would create or change, confirm it is genuinely **absent from the deployed environment** before authoring a ticket for it, and record what was probed and what came back.
+
+**Git ancestry, a merge check and `cdk synth` are never deployment evidence** — a discarded pipeline execution leaves a commit merged and unshipped, and all three still report "present". **An unanswerable probe is not a "no"**: when the state cannot be read back, record that the check could not be performed rather than defaulting to absent.
+
 
 Walkthrough findings are surfaced back to product via the orchestrating intake skill (`lisa-linear-prd-intake`), which posts them on the project's sentinel feedback issue. This skill itself does NOT post to Linear — it only reads. The walkthrough section is also inherited onto the resulting epic / stories under a `## Current Product` subsection in the JIRA description.
 

package/plugins/src/base/skills/lisa-notion-to-tracker/SKILL.md

@@ -254,7 +254,14 @@ Key things to look for:
 
 **2b. Live product walkthrough.** If the PRD touches existing user-facing surfaces (modifies a screen, adds something next to existing functionality, fixes current behavior, re-styles an existing flow), invoke the `lisa-product-walkthrough` skill against `E2E_BASE_URL` using the test user from config. This grounds the ticket plan in what's actually shipped — design-vs-current-product divergence, reuse candidates, and behavioral surprises that the PRD didn't anticipate become inputs to ticket creation rather than discoveries during implementation.
 
-Skip 2b only when the work is purely backend with no user-visible surface, or affects a screen that does not yet exist in dev/prod.
+Skip the *walkthrough* only when the work has no user-visible surface, or affects a screen that does not yet exist in dev/prod — and when you skip it, run 2c instead. Skipping 2b never means authoring the ticket with no live-state grounding.
+
+**2c. Deployed-state readback — required whenever 2b does not apply.** Per the `blocker-containment`-style shared-slug precedent, cite the `deployed-state-readback` rule for the full contract; do not restate its routing table here.
+
+2b is waived for work with no user-visible surface. That waiver is about the **observation method**, not about whether to observe: backend, infrastructure, CI-config and dependency work all have live state, it is simply not visible through a browser. So the skip selects a **different probe**, never no probe — describe the deployed resource, call the deployed endpoint, read the configuration the last pipeline run used, read the *installed* artifact. For each thing the candidate tickets would create or change, confirm it is genuinely **absent from the deployed environment** before authoring a ticket for it, and record what was probed and what came back.
+
+**Git ancestry, a merge check and `cdk synth` are never deployment evidence** — a discarded pipeline execution leaves a commit merged and unshipped, and all three still report "present". **An unanswerable probe is not a "no"**: when the state cannot be read back, record that the check could not be performed rather than defaulting to absent.
+
 
 Walkthrough findings are attached to the originating Notion PRD as a comment ("Current product walkthrough — `<route>`") and inherited onto the resulting epic / stories under a `## Current Product` subsection.
 

package/typescript/copy-contents/.husky/pre-commit

@@ -243,20 +243,24 @@ elif command -v gitleaks >/dev/null 2>&1; then
   fi
   echo "✅ No secrets detected"
 else
+  # Blocks rather than warns. This branch used to print the warning below and
+  # continue with exit 0, which made "gitleaks is not installed" and "no
+  # secrets were found" the same observable: a green commit. A credential scan
+  # that cannot run has not cleared the commit, and the lint-staged preflight
+  # further down already states the rule this branch was breaking — a check
+  # that cannot RUN is not a skip and not a pass.
   echo ""
-  echo "⚠️  WARNING: Gitleaks is not installed!"
+  echo "❌ Commit blocked: Gitleaks is required and is not installed."
   echo ""
-  echo "Gitleaks helps prevent secrets from being committed to your repository."
+  echo "Gitleaks is what stops secrets reaching this repository's history, and"
+  echo "without it this hook cannot tell a clean commit from an unscanned one."
   echo ""
   echo "To install Gitleaks:"
   echo "  macOS:    brew install gitleaks"
   echo "  Windows:  scoop install gitleaks  # or choco install gitleaks"
   echo "  Linux:    See https://github.com/gitleaks/gitleaks#installing"
   echo ""
-  echo "After installation, your commits will be automatically scanned for secrets."
-  echo ""
-  echo "Continuing without secret scanning..."
-  echo ""
+  exit 1
 fi
 
 # Check if native changes require runtime version bump

package/typescript/copy-contents/.husky/pre-push

@@ -88,6 +88,44 @@ if ! command -v node >/dev/null 2>&1; then
   exit 1
 fi
 
+# jq is required too, and it is proved HERE rather than at the first step that
+# needs it.
+#
+# jq decides five things in this hook, not one: the dependency-vulnerability
+# audit below, and — through `jq -e '.scripts[...]'` — whether `lint:slow`,
+# `knip:check`, `knip` and `test:mutation` exist at all. A false result from
+# those four probes is indistinguishable from a project that configures none of
+# them, so a machine without jq printed "Skipping slow lint rules (lint:slow
+# not configured)" about a project that configures it, ran no audit at all, and
+# pushed green.
+#
+# That is the failure this whole subsystem exists to prevent: a control
+# returning success for an input it never examined. Absence of the tool and
+# absence of findings produced the identical observable — a clean push — so
+# nothing downstream could tell an audited push from an unaudited one, and the
+# audit is not decoration: it blocks real pushes on real HIGH advisories.
+#
+# The audit block used to warn and continue here, on the reasoning that jq "may
+# legitimately be absent". That was written when jq gated one optional audit.
+# The honest treatment is the one node gets immediately above, and the one the
+# pre-commit lint-staged preflight already states in as many words: a check
+# that cannot RUN is not a skip and not a pass — it blocks.
+if ! command -v jq >/dev/null 2>&1; then
+  echo "❌ Push blocked: jq is required and is not installed."
+  echo ""
+  echo "   Without jq this hook cannot run the dependency-vulnerability audit,"
+  echo "   and cannot read package.json to tell whether lint:slow, knip and"
+  echo "   test:mutation are configured — so it would skip all four and report"
+  echo "   a clean push it never earned."
+  echo ""
+  echo "To install jq:"
+  echo "  macOS:    brew install jq"
+  echo "  Windows:  choco install jq  # or scoop install jq"
+  echo "  Linux:    apt-get install jq"
+  echo ""
+  exit 1
+fi
+
 # BEGIN: push destination guard
 # ---------------------------------------------------------------------------
 # Refuse a push whose RESOLVED destination is a deploy branch it was not aimed
@@ -388,20 +426,12 @@ fi
 # Run security audit
 echo "🔒 Running security audit..."
 
-# jq is required for all audit paths (JSON config reading, npm/yarn filtering)
+# jq is required for all audit paths (JSON config reading, npm/yarn filtering),
+# and is proved present at the top of this hook. There is deliberately no
+# "jq is missing, continue anyway" branch here: that branch made a missing tool
+# and a clean audit print the same thing.
 if lisa_gate_covers dependency-vulnerability; then
   echo "ℹ️  Covered by the dependency-vulnerability gate; the built-in audit stands down."
-elif ! command -v jq >/dev/null 2>&1; then
-  echo ""
-  echo "⚠️  WARNING: jq is not installed - required for security audit"
-  echo ""
-  echo "To install jq:"
-  echo "  macOS:    brew install jq"
-  echo "  Windows:  choco install jq  # or scoop install jq"
-  echo "  Linux:    apt-get install jq"
-  echo ""
-  echo "Continuing without security audit..."
-  echo ""
 else
   # Load GHSA exclusion IDs from JSON config files (managed + project-local)
   load_audit_exclusions() {
@@ -687,10 +717,10 @@ fi
 # did before — slower, but never with the integration tree silently dropped,
 # which is the failure direction that would actually cost something.
 #
-# Resolved with node rather than jq: this hook already refuses to run at all
-# without node, whereas jq may legitimately be absent — the audit block above
-# says so in as many words. Deciding this with jq would hand every jq-less
-# machine the slow path without a word.
+# Resolved with node rather than jq. This used to be a real distinction — jq
+# was optional and node was not — and it stopped being one when jq became a
+# hard requirement at the top of this hook. Either would answer correctly now;
+# node stays because rewriting a working probe buys nothing.
 # The unit script is selected only when it carries LISA_COVERAGE_SCOPE=unit.
 # That marker is not decoration: the threshold factory reads it and enforces the
 # `unit` block, so a `test:cov:unit` without it is measured against the floor