@codyswann/lisa 2.264.0 → 2.265.0

package/package.json

@@ -106,7 +106,7 @@
     "form-data": ">=4.0.6"
   },
   "name": "@codyswann/lisa",
-  "version": "2.264.0",
+  "version": "2.265.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

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

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

package/plugins/lisa/.codex-plugin/skills/lisa-security-review/SKILL.md

@@ -16,6 +16,57 @@ Identify vulnerabilities, evaluate threats, and recommend mitigations for code c
 5. **Check auth/authz** -- are access controls properly enforced for new endpoints or features?
 6. **Review dependencies** -- do new dependencies introduce known vulnerabilities?
 
+## The impact-or-exploitability bar
+
+Severity is **earned, not pattern-matched**. Every security-shaped finding is classified
+mechanically, before it is written up:
+
+| Field | What it holds |
+|-------|---------------|
+| `reproducer` | an evidence ref of a kind that reaches the claim's boundary, or `none` |
+| `impact` | a bounded impact/exploitability statement (who can do what, to what data, under what preconditions), or `unproven` |
+| `reason` | one line saying why the finding landed in its bucket |
+
+**The bar:** a finding is **proven** only when it carries **both** a reproducer **and** a bounded
+impact statement. **Missing either ⇒ unproven.** No other input changes the bucket.
+
+What counts as a reaching reproducer is defined by the `claim-evidence-mapping` contract (**BCE-1**,
+#1835), not here: an injection claim at the `http-api` boundary needs an `http-transcript`; a UI
+claim needs a `screenshot` or `recording`. A passing unit `test-run-log` reaches `code-unit` only and
+never discharges either.
+
+**Each field stands on its own.** The two halves are recorded independently: a finding with a bounded
+impact but no reproducer keeps its impact statement verbatim and only `reproducer` reads `none`; a
+finding with a reproducer but no bounded impact keeps the evidence ref and only `impact` reads
+`unproven`. **Never overwrite** a field you actually have with a missing-value placeholder — the
+`reason` line names which half is missing, and the surviving half is the head start the next reviewer
+needs.
+
+## The two buckets — conservative by default
+
+Findings render in two clearly-labeled buckets: **Security (proven)** and **Security (unproven)**.
+
+A reproducer-less finding **stays in the security section**, labeled `unproven` with its reason. It
+is **never auto-demoted** to a `maintenance` bucket and it is **not removed** from the report —
+under-reporting a real vulnerability is the worse failure, so the conservative default keeps it
+visible where a security reader looks.
+
+**Single policy point.** The unproven bucket's label is the only thing an owner may change:
+`security.review.unprovenBucket` in `.lisa.config.json`, default `security-unproven`. An owner who
+prefers true demotion sets it to a maintenance label; the finding then renders under that bucket and
+**no other classification logic changes** — the bar, the fields, and the reasons are identical.
+
+Write both buckets in operator voice (`factory-model` rule 5): a person who does not code reads this
+at the gate. "Anyone who can reach the search box can read other customers' orders — reproduced with
+the request transcript below" is usable; "possible SQLi in handler" is not.
+
+This bar governs *code-review* security findings. Dependency CVE remediation keeps its own decision
+ladder in the `security-audit-handling` rule — cite it, do not restate or fork it.
+
+Bucketing is **advisory** — it shapes the report, it does not block a merge — on the same terms as
+the boundary checks, which stay reporting-only until `verification.gate.enforceBoundaries` is `true`
+in `.lisa.config.json`.
+
 ## Output Format
 
 Structure findings as:
@@ -41,17 +92,33 @@ Structure 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, e.g. evidence/<ticket>/http-transcript-01.txt]
+  - 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)
 ```
 
+Rename the unproven heading only when `security.review.unprovenBucket` is set to something other
+than `security-unproven`; everything else stays as written.
+
 ## Rules
 
 - Focus on the specific changes proposed, not a full security audit of the entire codebase
 - Flag only real risks -- do not invent hypothetical threats for internal tooling with no user input
+- Classify every finding against the bar before writing it up; never leave a finding unbucketed
+- Never silently drop or downgrade a finding out of the security section -- `unproven` is the
+  conservative landing spot, and the reason line says why
 - Prioritize OWASP Top 10 vulnerabilities
 - If the changes are purely internal (config, refactoring, docs), report "No security concerns" and explain why
 - Always check `.gitleaksignore` patterns to understand what secrets scanning is already in place

package/plugins/lisa/.codex-plugin/skills/lisa-security-zap-scan/SKILL.md

@@ -22,10 +22,30 @@ Run a ZAP baseline security scan against the local application.
    - After the scan completes, read `zap-report.html` (or `zap-report.md` for text)
    - Summarize findings:
      - Total number of alerts by risk level (High, Medium, Low, Informational)
-     - List each Medium+ finding with its rule ID, name, and recommended fix
+     - **Every alert reaches classification** -- High, Medium, Low, and Informational alike. Risk
+       level orders the summary; it never filters it. **Nothing is dropped before classification**,
+       so no alert can leave the report unclassified. Medium+ alerts are listed first, in full (rule
+       ID, name, recommended fix); Low/Informational alerts are still listed, bucketed, and given a
+       `reason`, even when compressed to one line each.
      - Categorize findings as "infrastructure-level" (fix at CDN/proxy) vs "application-level" (fix in code)
 
-4. **Handle failures**:
+4. **Apply the impact-or-exploitability bar** -- the same bar the `lisa-security-review` skill
+   defines; follow that skill, do not restate it. A ZAP alert is not a reproducer by itself: the
+   alert names a pattern, not an exercised impact path.
+   - **Security (proven)** -- the alert carries a reproducer **and** a bounded impact statement. The
+     reproducer counts only if its evidence kind **reaches the claim's boundary** under the
+     `claim-evidence-mapping` contract (BCE-1, #1835): a ZAP request/response transcript is an
+     `http-transcript` and reaches the `http-api` boundary only. An alert whose claim is about
+     rendered UI (`browser`) or persisted state (`data`) needs evidence at *that* boundary -- a
+     transcript never proves it.
+   - **Security (unproven)** -- everything else, each with a one-line `reason` (typically
+     "alert only, no reproducer / no bounded impact", or "transcript does not reach the claim's
+     boundary"). Unproven alerts are **not dropped** and not demoted out of the security summary --
+     they render in the unproven bucket so a reader still sees them.
+   - Rename the unproven heading only if `security.review.unprovenBucket` is set to something other
+     than `security-unproven`; no other classification changes.
+
+5. **Handle failures**:
    - If the scan failed, explain what failed and suggest concrete remediation steps
 
 ## Execution

package/plugins/lisa/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/lisa/rules/eager/claim-evidence-mapping.md

@@ -37,8 +37,15 @@ 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. The conservative security-bucket default is set in **BCE-5 (#1839)** — 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)
 

package/plugins/lisa/rules/reference/claim-evidence-mapping.md

@@ -82,10 +82,9 @@ defines the names; it stores nothing:
 A claim whose `required_evidence_kinds` has no captured, reaching artifact is **Not established** —
 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 conservative default bucket for a security-sensitive claim is set in
-**BCE-5 (#1839)** — named here as a field BCE-2's schema carries, not defined by this contract, and
-it ships with that ticket. Where such a sibling surface is not installed in a given branch, name what
-you can and continue.
+(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
 
@@ -179,6 +178,28 @@ second one. Identity reconciliation is the same definition read from the evidenc
 
 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

package/plugins/lisa/skills/lisa-security-review/SKILL.md

@@ -16,6 +16,57 @@ Identify vulnerabilities, evaluate threats, and recommend mitigations for code c
 5. **Check auth/authz** -- are access controls properly enforced for new endpoints or features?
 6. **Review dependencies** -- do new dependencies introduce known vulnerabilities?
 
+## The impact-or-exploitability bar
+
+Severity is **earned, not pattern-matched**. Every security-shaped finding is classified
+mechanically, before it is written up:
+
+| Field | What it holds |
+|-------|---------------|
+| `reproducer` | an evidence ref of a kind that reaches the claim's boundary, or `none` |
+| `impact` | a bounded impact/exploitability statement (who can do what, to what data, under what preconditions), or `unproven` |
+| `reason` | one line saying why the finding landed in its bucket |
+
+**The bar:** a finding is **proven** only when it carries **both** a reproducer **and** a bounded
+impact statement. **Missing either ⇒ unproven.** No other input changes the bucket.
+
+What counts as a reaching reproducer is defined by the `claim-evidence-mapping` contract (**BCE-1**,
+#1835), not here: an injection claim at the `http-api` boundary needs an `http-transcript`; a UI
+claim needs a `screenshot` or `recording`. A passing unit `test-run-log` reaches `code-unit` only and
+never discharges either.
+
+**Each field stands on its own.** The two halves are recorded independently: a finding with a bounded
+impact but no reproducer keeps its impact statement verbatim and only `reproducer` reads `none`; a
+finding with a reproducer but no bounded impact keeps the evidence ref and only `impact` reads
+`unproven`. **Never overwrite** a field you actually have with a missing-value placeholder — the
+`reason` line names which half is missing, and the surviving half is the head start the next reviewer
+needs.
+
+## The two buckets — conservative by default
+
+Findings render in two clearly-labeled buckets: **Security (proven)** and **Security (unproven)**.
+
+A reproducer-less finding **stays in the security section**, labeled `unproven` with its reason. It
+is **never auto-demoted** to a `maintenance` bucket and it is **not removed** from the report —
+under-reporting a real vulnerability is the worse failure, so the conservative default keeps it
+visible where a security reader looks.
+
+**Single policy point.** The unproven bucket's label is the only thing an owner may change:
+`security.review.unprovenBucket` in `.lisa.config.json`, default `security-unproven`. An owner who
+prefers true demotion sets it to a maintenance label; the finding then renders under that bucket and
+**no other classification logic changes** — the bar, the fields, and the reasons are identical.
+
+Write both buckets in operator voice (`factory-model` rule 5): a person who does not code reads this
+at the gate. "Anyone who can reach the search box can read other customers' orders — reproduced with
+the request transcript below" is usable; "possible SQLi in handler" is not.
+
+This bar governs *code-review* security findings. Dependency CVE remediation keeps its own decision
+ladder in the `security-audit-handling` rule — cite it, do not restate or fork it.
+
+Bucketing is **advisory** — it shapes the report, it does not block a merge — on the same terms as
+the boundary checks, which stay reporting-only until `verification.gate.enforceBoundaries` is `true`
+in `.lisa.config.json`.
+
 ## Output Format
 
 Structure findings as:
@@ -41,17 +92,33 @@ Structure 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, e.g. evidence/<ticket>/http-transcript-01.txt]
+  - 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)
 ```
 
+Rename the unproven heading only when `security.review.unprovenBucket` is set to something other
+than `security-unproven`; everything else stays as written.
+
 ## Rules
 
 - Focus on the specific changes proposed, not a full security audit of the entire codebase
 - Flag only real risks -- do not invent hypothetical threats for internal tooling with no user input
+- Classify every finding against the bar before writing it up; never leave a finding unbucketed
+- Never silently drop or downgrade a finding out of the security section -- `unproven` is the
+  conservative landing spot, and the reason line says why
 - Prioritize OWASP Top 10 vulnerabilities
 - If the changes are purely internal (config, refactoring, docs), report "No security concerns" and explain why
 - Always check `.gitleaksignore` patterns to understand what secrets scanning is already in place

package/plugins/lisa/skills/lisa-security-zap-scan/SKILL.md

@@ -22,10 +22,30 @@ Run a ZAP baseline security scan against the local application.
    - After the scan completes, read `zap-report.html` (or `zap-report.md` for text)
    - Summarize findings:
      - Total number of alerts by risk level (High, Medium, Low, Informational)
-     - List each Medium+ finding with its rule ID, name, and recommended fix
+     - **Every alert reaches classification** -- High, Medium, Low, and Informational alike. Risk
+       level orders the summary; it never filters it. **Nothing is dropped before classification**,
+       so no alert can leave the report unclassified. Medium+ alerts are listed first, in full (rule
+       ID, name, recommended fix); Low/Informational alerts are still listed, bucketed, and given a
+       `reason`, even when compressed to one line each.
      - Categorize findings as "infrastructure-level" (fix at CDN/proxy) vs "application-level" (fix in code)
 
-4. **Handle failures**:
+4. **Apply the impact-or-exploitability bar** -- the same bar the `lisa-security-review` skill
+   defines; follow that skill, do not restate it. A ZAP alert is not a reproducer by itself: the
+   alert names a pattern, not an exercised impact path.
+   - **Security (proven)** -- the alert carries a reproducer **and** a bounded impact statement. The
+     reproducer counts only if its evidence kind **reaches the claim's boundary** under the
+     `claim-evidence-mapping` contract (BCE-1, #1835): a ZAP request/response transcript is an
+     `http-transcript` and reaches the `http-api` boundary only. An alert whose claim is about
+     rendered UI (`browser`) or persisted state (`data`) needs evidence at *that* boundary -- a
+     transcript never proves it.
+   - **Security (unproven)** -- everything else, each with a one-line `reason` (typically
+     "alert only, no reproducer / no bounded impact", or "transcript does not reach the claim's
+     boundary"). Unproven alerts are **not dropped** and not demoted out of the security summary --
+     they render in the unproven bucket so a reader still sees them.
+   - Rename the unproven heading only if `security.review.unprovenBucket` is set to something other
+     than `security-unproven`; no other classification changes.
+
+5. **Handle failures**:
    - If the scan failed, explain what failed and suggest concrete remediation steps
 
 ## Execution

package/plugins/lisa-agy/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/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-security-review/SKILL.md

@@ -16,6 +16,57 @@ Identify vulnerabilities, evaluate threats, and recommend mitigations for code c
 5. **Check auth/authz** -- are access controls properly enforced for new endpoints or features?
 6. **Review dependencies** -- do new dependencies introduce known vulnerabilities?
 
+## The impact-or-exploitability bar
+
+Severity is **earned, not pattern-matched**. Every security-shaped finding is classified
+mechanically, before it is written up:
+
+| Field | What it holds |
+|-------|---------------|
+| `reproducer` | an evidence ref of a kind that reaches the claim's boundary, or `none` |
+| `impact` | a bounded impact/exploitability statement (who can do what, to what data, under what preconditions), or `unproven` |
+| `reason` | one line saying why the finding landed in its bucket |
+
+**The bar:** a finding is **proven** only when it carries **both** a reproducer **and** a bounded
+impact statement. **Missing either ⇒ unproven.** No other input changes the bucket.
+
+What counts as a reaching reproducer is defined by the `claim-evidence-mapping` contract (**BCE-1**,
+#1835), not here: an injection claim at the `http-api` boundary needs an `http-transcript`; a UI
+claim needs a `screenshot` or `recording`. A passing unit `test-run-log` reaches `code-unit` only and
+never discharges either.
+
+**Each field stands on its own.** The two halves are recorded independently: a finding with a bounded
+impact but no reproducer keeps its impact statement verbatim and only `reproducer` reads `none`; a
+finding with a reproducer but no bounded impact keeps the evidence ref and only `impact` reads
+`unproven`. **Never overwrite** a field you actually have with a missing-value placeholder — the
+`reason` line names which half is missing, and the surviving half is the head start the next reviewer
+needs.
+
+## The two buckets — conservative by default
+
+Findings render in two clearly-labeled buckets: **Security (proven)** and **Security (unproven)**.
+
+A reproducer-less finding **stays in the security section**, labeled `unproven` with its reason. It
+is **never auto-demoted** to a `maintenance` bucket and it is **not removed** from the report —
+under-reporting a real vulnerability is the worse failure, so the conservative default keeps it
+visible where a security reader looks.
+
+**Single policy point.** The unproven bucket's label is the only thing an owner may change:
+`security.review.unprovenBucket` in `.lisa.config.json`, default `security-unproven`. An owner who
+prefers true demotion sets it to a maintenance label; the finding then renders under that bucket and
+**no other classification logic changes** — the bar, the fields, and the reasons are identical.
+
+Write both buckets in operator voice (`factory-model` rule 5): a person who does not code reads this
+at the gate. "Anyone who can reach the search box can read other customers' orders — reproduced with
+the request transcript below" is usable; "possible SQLi in handler" is not.
+
+This bar governs *code-review* security findings. Dependency CVE remediation keeps its own decision
+ladder in the `security-audit-handling` rule — cite it, do not restate or fork it.
+
+Bucketing is **advisory** — it shapes the report, it does not block a merge — on the same terms as
+the boundary checks, which stay reporting-only until `verification.gate.enforceBoundaries` is `true`
+in `.lisa.config.json`.
+
 ## Output Format
 
 Structure findings as:
@@ -41,17 +92,33 @@ Structure 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, e.g. evidence/<ticket>/http-transcript-01.txt]
+  - 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)
 ```
 
+Rename the unproven heading only when `security.review.unprovenBucket` is set to something other
+than `security-unproven`; everything else stays as written.
+
 ## Rules
 
 - Focus on the specific changes proposed, not a full security audit of the entire codebase
 - Flag only real risks -- do not invent hypothetical threats for internal tooling with no user input
+- Classify every finding against the bar before writing it up; never leave a finding unbucketed
+- Never silently drop or downgrade a finding out of the security section -- `unproven` is the
+  conservative landing spot, and the reason line says why
 - Prioritize OWASP Top 10 vulnerabilities
 - If the changes are purely internal (config, refactoring, docs), report "No security concerns" and explain why
 - Always check `.gitleaksignore` patterns to understand what secrets scanning is already in place

package/plugins/lisa-agy/skills/lisa-security-zap-scan/SKILL.md

@@ -22,10 +22,30 @@ Run a ZAP baseline security scan against the local application.
    - After the scan completes, read `zap-report.html` (or `zap-report.md` for text)
    - Summarize findings:
      - Total number of alerts by risk level (High, Medium, Low, Informational)
-     - List each Medium+ finding with its rule ID, name, and recommended fix
+     - **Every alert reaches classification** -- High, Medium, Low, and Informational alike. Risk
+       level orders the summary; it never filters it. **Nothing is dropped before classification**,
+       so no alert can leave the report unclassified. Medium+ alerts are listed first, in full (rule
+       ID, name, recommended fix); Low/Informational alerts are still listed, bucketed, and given a
+       `reason`, even when compressed to one line each.
      - Categorize findings as "infrastructure-level" (fix at CDN/proxy) vs "application-level" (fix in code)
 
-4. **Handle failures**:
+4. **Apply the impact-or-exploitability bar** -- the same bar the `lisa-security-review` skill
+   defines; follow that skill, do not restate it. A ZAP alert is not a reproducer by itself: the
+   alert names a pattern, not an exercised impact path.
+   - **Security (proven)** -- the alert carries a reproducer **and** a bounded impact statement. The
+     reproducer counts only if its evidence kind **reaches the claim's boundary** under the
+     `claim-evidence-mapping` contract (BCE-1, #1835): a ZAP request/response transcript is an
+     `http-transcript` and reaches the `http-api` boundary only. An alert whose claim is about
+     rendered UI (`browser`) or persisted state (`data`) needs evidence at *that* boundary -- a
+     transcript never proves it.
+   - **Security (unproven)** -- everything else, each with a one-line `reason` (typically
+     "alert only, no reproducer / no bounded impact", or "transcript does not reach the claim's
+     boundary"). Unproven alerts are **not dropped** and not demoted out of the security summary --
+     they render in the unproven bucket so a reader still sees them.
+   - Rename the unproven heading only if `security.review.unprovenBucket` is set to something other
+     than `security-unproven`; no other classification changes.
+
+5. **Handle failures**:
    - If the scan failed, explain what failed and suggest concrete remediation steps
 
 ## Execution

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.264.0",
+  "version": "2.265.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.264.0",
+  "version": "2.265.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.264.0",
+  "version": "2.265.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.264.0",
+  "version": "2.265.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.264.0",
+  "version": "2.265.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/lisa-copilot/agents/security-specialist.agent.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