@codyswann/lisa 2.263.0 → 2.265.0

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.263.0",
+  "version": "2.265.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.263.0",
+  "version": "2.265.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.263.0",
+  "version": "2.265.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.263.0",
+  "version": "2.265.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.263.0",
+  "version": "2.265.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.263.0",
+  "version": "2.265.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.263.0",
+  "version": "2.265.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.263.0",
+  "version": "2.265.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.263.0",
+  "version": "2.265.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.263.0",
+  "version": "2.265.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.263.0",
+  "version": "2.265.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.263.0",
+  "version": "2.265.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.263.0",
+  "version": "2.265.0",
   "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": "2.263.0",
+  "version": "2.265.0",
   "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": "2.263.0",
+  "version": "2.265.0",
   "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": "2.263.0",
+  "version": "2.265.0",
   "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": "2.263.0",
+  "version": "2.265.0",
   "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": "2.263.0",
+  "version": "2.265.0",
   "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": "2.263.0",
+  "version": "2.265.0",
   "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-agy/plugin.json

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

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

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

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

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

package/plugins/src/base/agents/security-specialist.md

@@ -35,13 +35,30 @@ Structure your findings as:
 - [ ] No XSS vectors in user-facing output
 - [ ] Dependencies free of known CVEs
 
-### Vulnerabilities Found
-- [vulnerability] -- where in the code, how to prevent
+### Security (proven)
+- [finding] -- where in the code, how to prevent
+  - reproducer: [evidence ref]
+  - impact: [who can do what, to what data, under what preconditions]
+  - reason: reproducer + bounded impact
+
+### Security (unproven)
+- [finding] -- where in the code, how to prevent
+  - reproducer: [evidence ref if one exists, else `none`]
+  - impact: [bounded statement if one exists, else `unproven`]
+  - reason: [which half is missing -- e.g. "impact bounded, but never reproduced"]
+    -- kept in the security section, not demoted
 
 ### Recommendations
 - [recommendation] -- priority (critical/warning/suggestion)
 ```
 
+A finding is **proven** only with both a reproducer evidence ref and a bounded impact statement;
+missing either, it stays **unproven** inside the security section. Record the two halves
+independently -- keep whichever one you have and let the `reason` name the missing half; never
+overwrite a real value with a placeholder. The full bar, the per-finding fields, and the
+`security.review.unprovenBucket` policy point live in the `security-review` skill -- follow it, do
+not restate it.
+
 ## Rules
 
 - Focus on the specific changes proposed, not a full security audit of the entire codebase

package/plugins/src/base/rules/eager/claim-evidence-mapping.md

@@ -37,9 +37,36 @@ rule 5).
 A claim carries three fields — `claim_id`, `boundary`, and `required_evidence_kinds` — named here so
 every downstream surface uses one spelling. This ticket only writes the contract down; the schema and
 gate that make these fields executable ship with **BCE-2 (#1836)** — do not assume that surface is
-present in this branch. A claim with no reaching evidence is **Not established** (defined fully in
-**BCE-3 (#1837)**), an artifact's identity is pinned in **BCE-4 (#1838)**, and the conservative
-security-bucket default is set in **BCE-5 (#1839)** — each named here, defined there.
+present in this branch.
+
+## Security buckets (conservative by default)
+
+A security finding is **proven** only with both a reproducer of a reaching kind and a bounded
+impact/exploitability statement; missing either, it renders **unproven** with its reason and **stays
+in the security section** — never auto-demoted to maintenance. The label is one policy point,
+`security.review.unprovenBucket` (default `security-unproven`); the procedure lives in the
+`lisa-security-review` skill.
+
+## Artifact identity (pinned, never assumed)
+
+A claim applies only to the artifact its evidence was collected against. Every verdict pins
+`artifact.head_sha` — the commit the run observed — and every evidence entry pins the
+`artifact_head_sha` in force when it was captured, its `sha256` content digest, and `captured_at`.
+Evidence collected on a pre-merge head is valid for the merge commit **only** when that head is a
+parent of the merge, per the ancestry + deploy-run definition of "what shipped" that
+`lisa-drive-pr-to-merge` already owns — cite it, never write a second one. A mismatched SHA or a
+recomputed digest that disagrees fails loudly, naming both SHAs / the evidence id, and verification
+re-runs against the merged head before completion is declared. Full definition: the reference body.
+
+## Not established (required, never omitted)
+
+A claim with no reaching evidence is **Not established**, and every report says so out loud. Each
+evidence comment and verdict carries a `Not established` section listing what was *not* proved —
+boundaries not exercised, environments not tested, behavior consciously out of scope. It is never
+omitted and never blank: with nothing outstanding it still renders `None outstanding — reviewed`, and
+`not_established_reviewed` attests the list was reviewed even when the list itself is empty. This
+generalizes the required, never-empty `Known limits` field of `lisa-improve-harness`. Full definition
+and operator-voice exemplars: the reference body.
 
 ## No behavior change; degrade, never block
 

package/plugins/src/base/rules/reference/claim-evidence-mapping.md

@@ -80,12 +80,11 @@ defines the names; it stores nothing:
 | `required_evidence_kinds` | the evidence kind(s) that reach that boundary, from the `verification` artifact-type set |
 
 A claim whose `required_evidence_kinds` has no captured, reaching artifact is **Not established** —
-the concept is named here and defined fully, with its evidence templates, in **BCE-3 (#1837)**; do
-not assume that section is present in this branch. Artifact identity — what makes two captured
-artifacts the same or different — is pinned in **BCE-4 (#1838)**, and the conservative default
-bucket for a security-sensitive claim is set in **BCE-5 (#1839)**. Each is named here as the field
-BCE-2's schema will carry; none is defined by this contract. Each ships with that ticket — do not
-assume its section is present in this branch.
+defined in full, with its evidence templates, in the section below. Artifact identity — what makes
+two captured artifacts the same or different — is defined in the *Artifact identity* section below
+(shipped by BCE-4, #1838). The bucket a security-sensitive claim lands in is defined in the *Security
+buckets* section below (shipped by BCE-5, #1839). Where such a sibling surface is not installed in a
+given branch, name what you can and continue.
 
 ### Worked example
 
@@ -114,13 +113,161 @@ Claim: "The service is deployed and healthy."
                       response from the target environment.
 ```
 
+## Artifact identity — what the evidence was collected against
+
+A claim reaches only as far as its evidence's *kind*; it applies only to the *artifact* that evidence
+was collected against. **Artifact identity is what makes two captured artifacts the same or
+different**: one repository, at one commit, in one environment, at one moment. Evidence that does not
+say which artifact it observed is not evidence about anything in particular — it silently transfers
+to whatever ships next, which is exactly how an auto-merge race ships code no verification ever
+touched.
+
+Identity is carried in two places, and they must agree:
+
+| Where | Field | What it pins |
+|---|---|---|
+| `artifact` (once per verdict) | `repository` | the `owner/repo` the run observed |
+| | `base_sha` | the base the change was measured against |
+| | `head_sha` | **the commit the verification actually observed** — required for a v2 pass |
+| | `build_id` | the build/run the evidence came from, where one exists |
+| | `environment` | where it ran (local, preview, staging, production) |
+| | `observed_at` | when the run observed it (ISO-8601 UTC) |
+| `evidence[]` (per artifact) | `artifact_head_sha` | the `head_sha` in force **when that artifact was captured** |
+| | `sha256` | content digest of the committed evidence file |
+| | `captured_at` | when that artifact was captured (ISO-8601 UTC) |
+
+`head_sha` pins the *build*; `sha256` pins the *bytes*. Together they answer both identity questions:
+"which artifact was this collected against" and "is this still the artifact that was collected". The
+`sha256` + commit-ref discipline is the same one Lisa's upstream-evidence manifest already uses — it
+is cited as prior art here, not reinvented.
+
+### Two identity failures, both loud
+
+- **`artifact_mismatch`** — an `evidence[]` entry whose `artifact_head_sha` differs from the verdict's
+  `artifact.head_sha`. The evidence describes a different build than the one the verdict claims. The
+  identity check fails **loudly, naming both SHAs** (the evidence's and the verdict's) so an operator
+  can see which build each half is talking about.
+- **`evidence_digest_mismatch`** — on read, recompute the `sha256` of each committed evidence file. If
+  the bytes no longer match the recorded digest, the artifact has changed since it was recorded: the
+  check fails, it names the evidence id, and blocks completion. A digest that cannot be recomputed
+  (file absent) is the same failure.
+
+Neither failure is ever summarized as "verification failed". Name the field, the ids, and both SHAs —
+a person who does not code reads this at the gate (`factory-model` rule 5). Both checks are
+**advisory-first**: reported to the operator but non-blocking until
+`verification.gate.enforceBoundaries` is `true` in `.lisa.config.json` — the same ratchet flag the
+boundary checks and the Stop-hook gate ride.
+
+### The merge race — one definition, two guards
+
+"The artifact that shipped" is already defined once, in `lisa-drive-pr-to-merge`: the **ancestry**
+check (is the verified commit an ancestor of the merged base branch, and is the merge commit's parent
+that verified head rather than a stale one) **plus** the **deploy-run** check (a deploy/release run
+actually fired for the merge SHA or an including descendant). Cite that definition; never write a
+second one. Identity reconciliation is the same definition read from the evidence side:
+
+- Evidence collected on a **pre-merge head** is valid for the merge commit **only when that head is a
+  parent of the merge** — i.e. it satisfies that skill's ancestry check against the merged head. If a
+  late commit raced past the merge, the merged head is not the verified one and the evidence does not
+  transfer.
+- Ancestry alone is never enough. That skill's rule stands unchanged here: **never report shipped on
+  ancestry alone** — the deploy-run check must also pass before completion is declared.
+- On mismatch (`artifact.head_sha` ≠ the reconciled merge SHA), completion is not declared. Flag the
+  mismatch naming both SHAs and **re-run verification against the merged head**; the re-run's verdict
+  is what may declare completion.
+
+Two guards, one definition — so they cannot disagree about what shipped.
+
+## Security buckets — the impact-or-exploitability bar
+
+A security-shaped claim is a claim like any other: it reaches only as far as its evidence. Applied to
+security findings (shipped by BCE-5, #1839), that yields two buckets and one bar:
+
+- **Security (proven)** — the finding carries **both** a `reproducer` (an evidence ref of a kind that
+  reaches the claim's boundary, per the taxonomy above — e.g. an `http-transcript` for an injection
+  claim at `http-api`) **and** a bounded `impact`/exploitability statement.
+- **Security (unproven)** — **missing either**. It keeps a one-line `reason` and **stays in the
+  security section**: a reproducer-less finding is **never auto-demoted** to a `maintenance` bucket,
+  because under-reporting a real vulnerability is the worse failure.
+
+The unproven bucket's label is the single configurable policy point —
+`security.review.unprovenBucket` in `.lisa.config.json`, default `security-unproven`. An owner who
+prefers true demotion flips that one value; no other classification logic changes. Like the boundary
+checks, bucketing is **advisory** — it shapes the report, not the merge — until
+`verification.gate.enforceBoundaries` is `true`.
+
+The full procedure — per-finding fields, report shape, ZAP alignment — lives in the
+`lisa-security-review` skill (with `lisa-security-zap-scan` citing it); dependency-CVE remediation
+keeps its separate ladder in `security-audit-handling`. Cite those slugs; do not restate them here.
+
+## The "Not established" section — required, never omitted
+
+Every report that asserts something was verified also states, in the same breath, **what it did not
+establish**. This is one section, it is **required**, and it is **never omitted and never blank** —
+on the evidence comment, in the committed `evidence/<ticket>/verdict.json`, and in the
+`verification-status.json` verdict BCE-2's gate reads.
+
+**Where it appears and what it says**
+
+| Surface | Shape |
+|---|---|
+| Evidence comment (tracker + PR `## Evidence` section) | a `## Not established` heading, one plain-language bullet per item |
+| `evidence/<ticket>/verdict.json` | `not_established: []` plus `not_established_reviewed: true` |
+| `.lisa/verification-status.json` (schema v2) | per-claim `not_established[]` plus the top-level `not_established_reviewed` flag |
+
+**The empty case is not the omitted case.** A verification that genuinely left nothing unproved still
+renders the heading, with the single line:
+
+```text
+## Not established
+
+None outstanding — reviewed
+```
+
+An absent heading, or a heading with nothing under it, is a defect — it is indistinguishable from
+never having asked the question. The list may be empty; the section may not be blank.
+
+**Machine-readable semantics (as shipped by BCE-2, #1836).** `not_established` is the list — it may
+be empty. `not_established_reviewed` is the boolean attestation that the list was actually
+reviewed — **the flag may never be omitted**. That asymmetry is the whole mechanism: an empty list
+plus a present flag means "we looked and found nothing outstanding"; an absent flag means nobody
+looked. The Stop-hook gate treats an absent flag as a v2 contract violation, reported to stderr and
+**advisory** until `verification.gate.enforceBoundaries` is `true` in `.lisa.config.json` (the same
+ratchet flag the boundary checks ride); evidence surfaces refuse the post on the same terms.
+
+**What belongs under the heading** — written in operator voice (`factory-model` rule 5: a person who
+does not code reads this at the gate), not in engineering shorthand:
+
+- **Boundaries not exercised** — a claim's boundary that no captured artifact reached. *"The checkout
+  button was proved in the browser; the order's persisted row was never queried, so the `data`
+  boundary is not established."*
+- **Environments not tested** — where it was and was not run. *"Checked on production Chrome at
+  1440×900 only. Not checked on mobile Safari, and not checked against the staging database."*
+- **Claims consciously out of scope** — deliberately excluded behavior, named so nobody infers it.
+  *"Refunds were not touched or tested; this change covers new orders only."*
+- **Anything a green quality check might be mistaken for proving.** *"Unit tests pass for the submit
+  handler. That establishes the code-unit boundary only — it is not evidence the button works."*
+
+Each item names the thing, not a category: "not tested on mobile Safari" is usable at a gate; "some
+environments untested" is not.
+
+### Philosophical precedent for this section
+
+This generalizes `lisa-improve-harness`'s **`Known limits`** field — a required, never-empty line on
+every result record. That skill says it plainly:
+*"A record with nothing in it is invalid on its face"* — because a single-trajectory loop always has
+limits. The same is true of any verification:
+it ran somewhere, on something, once. `Known limits` (one record) and `not_established` (every claim
+in the factory) are the same discipline with the same never-empty rule; read either and you should
+recognize the other.
+
 ## Philosophical precedent
 
 This generalizes the **bounded-claim discipline** of `lisa-improve-harness`: one trajectory supports
 one trajectory's claim, and a result record may claim only what its cited evidence reaches. Here the
 same discipline is applied to every claim in the factory — a claim reaches exactly as far as the
-*kind* of evidence behind it, and no further. BCE-3 generalizes the *Not established* half of that
-discipline into a first-class report state.
+*kind* of evidence behind it, and no further. The *Not established* half of that discipline is a
+first-class report state — see the required, never-omitted section above.
 
 ## No behavior change; degrade, never block
 

package/plugins/src/base/rules/reference/verification.md

@@ -151,6 +151,32 @@ Do not invent types inline; if none fits, propose extending this table. The lega
 
 The manifest is the single source of truth for "what evidence is required": authored once in the Validation Journey, enforced at write time, replayed during `tracker-journey` (which captures each artifact **in its declared type**), and checked again before the ticket closes. There is no second list to keep in sync.
 
+### Every evidence surface names what it did NOT establish
+
+An evidence comment that lists only what passed is unreadable at a gate: a journey that skipped an edge state looks exactly like one that covered it. So every evidence comment — and the committed `evidence/<ticket>/verdict.json` — carries two extra sections, defined in full by the `claim-evidence-mapping` rule:
+
+- **Artifact identity** — what the evidence was collected against, as values rather than placeholders: the `repository`, the `head_sha` the run observed, the `environment`, and per artifact its `sha256` digest and `captured_at`. Defined in full by the `claim-evidence-mapping` rule.
+- **Not established** — a **required, never-omitted** heading listing what the verification did *not* prove: boundaries not exercised, environments not tested, behavior consciously out of scope. When nothing is outstanding it still renders, reading `None outstanding — reviewed`. It is never blank.
+
+The committed verdict carries the machine-readable half:
+
+```
+evidence/<ticket>/verdict.json
+  not_established: []            # what was NOT proved; may be empty
+  not_established_reviewed: true # attests the list was reviewed; may NEVER be omitted
+  artifact: { repository, base_sha, head_sha, build_id, environment, observed_at }
+  evidence: [ { evidence_id, kind, locator,
+                artifact_head_sha,   # the head_sha in force when THIS artifact was captured
+                sha256,              # content digest of the committed evidence file
+                captured_at } ]
+```
+
+`artifact.head_sha` pins the build the verification observed; each entry's `sha256` pins the bytes. An entry whose `artifact_head_sha` differs from `artifact.head_sha` is an `artifact_mismatch` and a recomputed digest that disagrees is an `evidence_digest_mismatch` — each fails loudly, naming both SHAs or the evidence id, and blocks completion. At completion the pinned `head_sha` is reconciled against **the merged head** using the ancestry + deploy-run definition of "what shipped" that `lisa-drive-pr-to-merge` already owns (cite it; there is no second definition): pre-merge evidence counts only when its head is a parent of the merge, and on a merge-race mismatch verification re-runs against the merged head before completion is declared.
+
+The list may be empty; the flag may not be missing. An absent `not_established_reviewed` is indistinguishable from nobody having asked the question, so the evidence-posting gate in `tracker-evidence` refuses the post, and the Stop-hook gate reports it as a v2 contract violation (advisory until `verification.gate.enforceBoundaries` is ratcheted on). This generalizes the required, never-empty `Known limits` field of `lisa-improve-harness` to every evidence surface.
+
+The boundary each artifact type reaches — and therefore which claim a captured artifact can discharge — is the `claim-evidence-mapping` rule's taxonomy; the type table above is its evidence-kind source.
+
 ### Cross-work-item evidence references are non-claiming
 
 When prose needs to point at evidence declared by another work item, use the dedicated reference form:

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

@@ -24,6 +24,16 @@ Upload captured evidence and generated templates to the GitHub PR description an
   - `comment.md` — GitHub markdown body for both the issue comment and the PR description's `## Evidence` section.
   - (Optional) `comment.txt` — kept for parity with the JIRA path; not used here.
 
+## Comment-body preflight (required)
+
+Before posting or updating anything, check the evidence body (`comment.md`, and `comment.txt` where this skill uses it):
+
+- It contains a `## Not established` heading. That heading is **never omitted and never blank** — when nothing is outstanding it still renders `None outstanding — reviewed`; otherwise it names, in plain operator language, what the verification did not prove.
+- The accompanying verdict carries `not_established_reviewed: true` (the list may be empty; the flag may never be omitted).
+- It contains a `## Artifact identity` heading carrying **values, not placeholders** — the repository, the `head_sha` the verification observed, the `environment`, and per artifact its `sha256` digest and `captured_at`. **Refuse to post** a body whose identity heading is absent or unpopulated, or whose recorded `artifact_head_sha` disagrees with the verdict's `artifact.head_sha` — report the evidence id and **both SHAs**. Definition: the `claim-evidence-mapping` rule.
+
+If either is missing, **refuse to post**: stop and report the missing Not-established review to the caller instead of publishing. Composing the body is `lisa-tracker-evidence`'s job (see its UI Evidence Checklist); this skill only refuses to publish one that omits the section. The section is defined by the `claim-evidence-mapping` rule and generalizes `lisa-improve-harness`'s required, never-empty `Known limits` field.
+
 ## Workflow
 
 1. **Resolve refs**

package/plugins/src/base/skills/lisa-jira-evidence/SKILL.md

@@ -42,6 +42,16 @@ Upload captured evidence and generated templates to GitHub PR description and JI
   - `comment.txt` — JIRA wiki markup (generated by `generate-templates.py`)
   - `comment.md` — GitHub markdown (generated by `generate-templates.py`)
 
+## Comment-body preflight (required)
+
+Before posting or updating anything, check the evidence body (`comment.md`, and `comment.txt` where this skill uses it):
+
+- It contains a `## Not established` heading. That heading is **never omitted and never blank** — when nothing is outstanding it still renders `None outstanding — reviewed`; otherwise it names, in plain operator language, what the verification did not prove.
+- The accompanying verdict carries `not_established_reviewed: true` (the list may be empty; the flag may never be omitted).
+- It contains a `## Artifact identity` heading carrying **values, not placeholders** — the repository, the `head_sha` the verification observed, the `environment`, and per artifact its `sha256` digest and `captured_at`. **Refuse to post** a body whose identity heading is absent or unpopulated, or whose recorded `artifact_head_sha` disagrees with the verdict's `artifact.head_sha` — report the evidence id and **both SHAs**. Definition: the `claim-evidence-mapping` rule.
+
+If either is missing, **refuse to post**: stop and report the missing Not-established review to the caller instead of publishing. Composing the body is `lisa-tracker-evidence`'s job (see its UI Evidence Checklist); this skill only refuses to publish one that omits the section. The section is defined by the `claim-evidence-mapping` rule and generalizes `lisa-improve-harness`'s required, never-empty `Known limits` field.
+
 ## Usage
 
 ```bash

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

@@ -41,6 +41,16 @@ The caller must produce:
 
 If any of these are missing, stop and report.
 
+## Comment-body preflight (required)
+
+Before posting or updating anything, check the evidence body (`comment.md`, and `comment.txt` where this skill uses it):
+
+- It contains a `## Not established` heading. That heading is **never omitted and never blank** — when nothing is outstanding it still renders `None outstanding — reviewed`; otherwise it names, in plain operator language, what the verification did not prove.
+- The accompanying verdict carries `not_established_reviewed: true` (the list may be empty; the flag may never be omitted).
+- It contains a `## Artifact identity` heading carrying **values, not placeholders** — the repository, the `head_sha` the verification observed, the `environment`, and per artifact its `sha256` digest and `captured_at`. **Refuse to post** a body whose identity heading is absent or unpopulated, or whose recorded `artifact_head_sha` disagrees with the verdict's `artifact.head_sha` — report the evidence id and **both SHAs**. Definition: the `claim-evidence-mapping` rule.
+
+If either is missing, **refuse to post**: stop and report the missing Not-established review to the caller instead of publishing. Composing the body is `lisa-tracker-evidence`'s job (see its UI Evidence Checklist); this skill only refuses to publish one that omits the section. The section is defined by the `claim-evidence-mapping` rule and generalizes `lisa-improve-harness`'s required, never-empty `Known limits` field.
+
 ## Phase 1 — Resolve Linear Issue
 
 1. Parse the identifier from `$ARGUMENTS`.