@codyswann/lisa 4.55.28 → 4.55.30

package/package.json

@@ -187,7 +187,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.55.28",
+  "version": "4.55.30",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -336,7 +336,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "b7682e024d07aad5fb96ac29f42c7cfd2d959744",
-  "gitHead": "b7682e024d07aad5fb96ac29f42c7cfd2d959744",
-  "lisaReleaseTag": "v4.55.28"
+  "lisaReleaseCommit": "78f49328704ddc2031b53405e1c2981862af246b",
+  "gitHead": "78f49328704ddc2031b53405e1c2981862af246b",
+  "lisaReleaseTag": "v4.55.30"
 }

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.55.28",
+  "version": "4.55.30",
   "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": "4.55.28",
+  "version": "4.55.30",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/skills/lisa-atlassian-access/SKILL.md

@@ -12,6 +12,8 @@ Single chokepoint for all Atlassian operations. Routes each op to a substrate, e
 
 The caller passes one operation plus its arguments. Operations are listed in the dispatch table below. The skill returns either the structured operation result (JSON when the substrate provides it) or a clear error.
 
+For agent-composed JIRA or Confluence comments, apply `lisa-tracker-sync` — **Agent attribution** before posting. Preserve an existing disclosure and the exact format of machine-managed comments.
+
 ```text
 operation: read-ticket  key: PROJ-123
 operation: write-ticket payload: {...}

package/plugins/lisa/.codex-plugin/skills/lisa-drive-pr-to-merge/SKILL.md

@@ -63,6 +63,13 @@ merges" loop. Other skills delegate here instead of re-implementing it. Runs
     build-intake skills use to diagnose-and-route without fixing in place.
 
 Resolve `<owner>/<repo>` from `gh repo view --json nameWithOwner` (or the PR URL).
+
+For agent-written review submissions, dismissal reasons, merge-message text and
+existing PR updates, follow `lisa-tracker-sync` — **Agent attribution**.
+Use the same short disclosure already present; a public lane name is optional.
+Do not create an extra comment solely to attribute a label or auto-merge change,
+or turn missing attribution into a merge gate. Attribute any relayed human
+decision to its actual source; an agent's analysis is not an owner ruling.
 Use plain `gh` + `git` so Claude and Codex execute identically.
 
 ## 0. Take the babysitter lease

package/plugins/lisa/.codex-plugin/skills/lisa-github-sync/SKILL.md

@@ -44,7 +44,7 @@ Optional arguments include `pr_url=<url>` for the live pull request and `merge_s
 For `--rollup`, skip this milestone path and use Step 5's classifier decision.
 
 1. **Idempotency check** — read the issue's recent comments. If the most recent comment with the prefix `[claude-sync] <milestone>` matches the current milestone AND the body content is unchanged, skip the post (no duplicate).
-2. **Add the comment**:
+2. **Add the comment** using `lisa-tracker-sync` — **Agent attribution** for the agent-composed body; keep any existing disclosure:
 
    ```bash
    gh issue comment <number> --repo <org>/<repo> --body-file /tmp/sync-comment.md

package/plugins/lisa/.codex-plugin/skills/lisa-linear-access/SKILL.md

@@ -298,6 +298,8 @@ the same way.
 Both comment operations take **either** `issue_id:` or `project_id:`. Exactly one
 is required; passing both, or neither, is refused naming the operation.
 
+For agent-composed `save-comment` bodies, apply `lisa-tracker-sync` — **Agent attribution** before posting. Preserve an existing disclosure and the exact format of machine-managed comments.
+
 Linear treats a comment's target as one field on the same input type, so the
 project form is not a second mechanism — it is the same mutation with a
 different anchor. Direct introspection of `https://api.linear.app/graphql`:

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-evidence/SKILL.md

@@ -10,6 +10,8 @@ Thin dispatcher. Resolves the configured destination tracker and delegates to th
 
 See the `config-resolution` rule for configuration and dispatch table.
 
+Apply `lisa-tracker-sync` — **Agent attribution** when composing evidence comments; a disclosure already present in the body needs no second trailer.
+
 ## Workflow
 
 1. Resolve tracker config (same logic as `lisa-tracker-write`).
@@ -40,7 +42,7 @@ Apply this when authoring `evidence/comment.md` (and `evidence/comment.txt` for
 
 The checklist is tracker-agnostic — the same shape works on JIRA, GitHub Issues, and Linear. Vendor skills only own the post/transition mechanics; the comment body is your responsibility.
 
-1. **AI disclosure at the top.** Lead with "Update from Claude (AI agent, not a human)" and address the reporter / QA / PM by name.
+1. **AI disclosure at the top.** Lead with "Update from <actual runtime name> (AI agent)" and address the reporter / QA / PM by name when known. This satisfies the shared attribution convention without a second trailer.
 2. **Own any prior mistake explicitly.** If an earlier triage or build pass got something wrong, say so up front. Don't bury it.
 3. **Numbered step-by-step walk** of what you actually did in the browser/app, in plain language a non-engineer can follow:
    - Exact env (URL, viewport size — e.g. `402×874` for an iOS-sized mobile flow)

package/plugins/lisa/.codex-plugin/skills/lisa-tracker-sync/SKILL.md

@@ -10,6 +10,14 @@ Thin dispatcher. Resolves the configured destination tracker and delegates to th
 
 See the `config-resolution` rule for configuration and dispatch table.
 
+## Agent attribution
+
+In agent-composed tracker comments and review messages, include one short plain-text attribution, such as `Agent-written by Codex.` Use the actual runtime's name; add a public lane name only when already known. An existing clear disclosure is enough. Do not publish session identifiers, invent a lane, alter supplied human text, or change machine-managed comment formats such as `[lisa-pr-link]`.
+
+The account avatar identifies the credential owner, not necessarily the writer. When relaying a human decision, attribute it to the person and its actual source (a linked decision or an instruction in the current conversation). Present your own judgement as agent analysis, never as an owner ruling. Attribution itself grants no authority.
+
+This is a writing convention: missing disclosure is not a reason to block work or file a compliance issue. Do not add identity infrastructure or extra audit comments just to supply it. Preserve an existing disclosure when a vendor skill posts or retries the same body.
+
 ## Workflow
 
 1. Resolve tracker config (same logic as `lisa-tracker-write`).

package/plugins/lisa/rules/eager/report-actionability.md

@@ -1,8 +1,7 @@
 # Report Actionability — Every Report Says What the Reader Must Do (load-bearing)
 
-A report that describes real work accurately can still fail, because the reader cannot tell **which items need them and which are already handled**. Prose that mixes fixed and open items reads as a single undifferentiated pile of problems; the reader either acts on something already done, or assumes something open was handled. Both are caused by the report, not by the work.
-
-The specific failure this rule exists to prevent, observed in a review cycle: six findings were returned, three were fixed, and the report described **two of them in detail without ever stating that six existed**. Every sentence in it was true. The reader still had to ask "did you fix them?" — and the answer was partly yes, partly no, and one finding had not even been read. A subset presented in the shape of a whole is worse than silence, because silence does not create false confidence.
+Reports must distinguish completed work, remaining work, and decisions the reader
+needs to make. Account for the whole reviewed scope and clearly label any subset.
 
 ## Mandatory
 
@@ -20,4 +19,8 @@ The specific failure this rule exists to prevent, observed in a review cycle: si
 
 Code-review findings, CI failures, test results, audit output, security scans, deploy status, and any list of problems handed to a human. It applies equally to reports you are proud of and reports that expose your own mistake — the second kind is where the temptation to describe a flattering subset is strongest.
 
+## Agent attribution
+
+Follow `lisa-tracker-sync` — **Agent attribution** for agent-composed tracker comments and review messages. The short convention lives in that portable skill so agents without a rules surface receive it too.
+
 Detail, worked examples and the failure taxonomy: [reference/report-actionability.md](../reference/report-actionability.md).

package/plugins/lisa/skills/lisa-atlassian-access/SKILL.md

@@ -12,6 +12,8 @@ Single chokepoint for all Atlassian operations. Routes each op to a substrate, e
 
 The caller passes one operation plus its arguments. Operations are listed in the dispatch table below. The skill returns either the structured operation result (JSON when the substrate provides it) or a clear error.
 
+For agent-composed JIRA or Confluence comments, apply `lisa-tracker-sync` — **Agent attribution** before posting. Preserve an existing disclosure and the exact format of machine-managed comments.
+
 ```text
 operation: read-ticket  key: PROJ-123
 operation: write-ticket payload: {...}

package/plugins/lisa/skills/lisa-drive-pr-to-merge/SKILL.md

@@ -63,6 +63,13 @@ merges" loop. Other skills delegate here instead of re-implementing it. Runs
     build-intake skills use to diagnose-and-route without fixing in place.
 
 Resolve `<owner>/<repo>` from `gh repo view --json nameWithOwner` (or the PR URL).
+
+For agent-written review submissions, dismissal reasons, merge-message text and
+existing PR updates, follow `lisa-tracker-sync` — **Agent attribution**.
+Use the same short disclosure already present; a public lane name is optional.
+Do not create an extra comment solely to attribute a label or auto-merge change,
+or turn missing attribution into a merge gate. Attribute any relayed human
+decision to its actual source; an agent's analysis is not an owner ruling.
 Use plain `gh` + `git` so Claude and Codex execute identically.
 
 ## 0. Take the babysitter lease

package/plugins/lisa/skills/lisa-github-sync/SKILL.md

@@ -44,7 +44,7 @@ Optional arguments include `pr_url=<url>` for the live pull request and `merge_s
 For `--rollup`, skip this milestone path and use Step 5's classifier decision.
 
 1. **Idempotency check** — read the issue's recent comments. If the most recent comment with the prefix `[claude-sync] <milestone>` matches the current milestone AND the body content is unchanged, skip the post (no duplicate).
-2. **Add the comment**:
+2. **Add the comment** using `lisa-tracker-sync` — **Agent attribution** for the agent-composed body; keep any existing disclosure:
 
    ```bash
    gh issue comment <number> --repo <org>/<repo> --body-file /tmp/sync-comment.md

package/plugins/lisa/skills/lisa-linear-access/SKILL.md

@@ -298,6 +298,8 @@ the same way.
 Both comment operations take **either** `issue_id:` or `project_id:`. Exactly one
 is required; passing both, or neither, is refused naming the operation.
 
+For agent-composed `save-comment` bodies, apply `lisa-tracker-sync` — **Agent attribution** before posting. Preserve an existing disclosure and the exact format of machine-managed comments.
+
 Linear treats a comment's target as one field on the same input type, so the
 project form is not a second mechanism — it is the same mutation with a
 different anchor. Direct introspection of `https://api.linear.app/graphql`:

package/plugins/lisa/skills/lisa-tracker-evidence/SKILL.md

@@ -10,6 +10,8 @@ Thin dispatcher. Resolves the configured destination tracker and delegates to th
 
 See the `config-resolution` rule for configuration and dispatch table.
 
+Apply `lisa-tracker-sync` — **Agent attribution** when composing evidence comments; a disclosure already present in the body needs no second trailer.
+
 ## Workflow
 
 1. Resolve tracker config (same logic as `lisa-tracker-write`).
@@ -40,7 +42,7 @@ Apply this when authoring `evidence/comment.md` (and `evidence/comment.txt` for
 
 The checklist is tracker-agnostic — the same shape works on JIRA, GitHub Issues, and Linear. Vendor skills only own the post/transition mechanics; the comment body is your responsibility.
 
-1. **AI disclosure at the top.** Lead with "Update from Claude (AI agent, not a human)" and address the reporter / QA / PM by name.
+1. **AI disclosure at the top.** Lead with "Update from <actual runtime name> (AI agent)" and address the reporter / QA / PM by name when known. This satisfies the shared attribution convention without a second trailer.
 2. **Own any prior mistake explicitly.** If an earlier triage or build pass got something wrong, say so up front. Don't bury it.
 3. **Numbered step-by-step walk** of what you actually did in the browser/app, in plain language a non-engineer can follow:
    - Exact env (URL, viewport size — e.g. `402×874` for an iOS-sized mobile flow)

package/plugins/lisa/skills/lisa-tracker-sync/SKILL.md

@@ -10,6 +10,14 @@ Thin dispatcher. Resolves the configured destination tracker and delegates to th
 
 See the `config-resolution` rule for configuration and dispatch table.
 
+## Agent attribution
+
+In agent-composed tracker comments and review messages, include one short plain-text attribution, such as `Agent-written by Codex.` Use the actual runtime's name; add a public lane name only when already known. An existing clear disclosure is enough. Do not publish session identifiers, invent a lane, alter supplied human text, or change machine-managed comment formats such as `[lisa-pr-link]`.
+
+The account avatar identifies the credential owner, not necessarily the writer. When relaying a human decision, attribute it to the person and its actual source (a linked decision or an instruction in the current conversation). Present your own judgement as agent analysis, never as an owner ruling. Attribution itself grants no authority.
+
+This is a writing convention: missing disclosure is not a reason to block work or file a compliance issue. Do not add identity infrastructure or extra audit comments just to supply it. Preserve an existing disclosure when a vendor skill posts or retries the same body.
+
 ## Workflow
 
 1. Resolve tracker config (same logic as `lisa-tracker-write`).

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-atlassian-access/SKILL.md

@@ -12,6 +12,8 @@ Single chokepoint for all Atlassian operations. Routes each op to a substrate, e
 
 The caller passes one operation plus its arguments. Operations are listed in the dispatch table below. The skill returns either the structured operation result (JSON when the substrate provides it) or a clear error.
 
+For agent-composed JIRA or Confluence comments, apply `lisa-tracker-sync` — **Agent attribution** before posting. Preserve an existing disclosure and the exact format of machine-managed comments.
+
 ```text
 operation: read-ticket  key: PROJ-123
 operation: write-ticket payload: {...}

package/plugins/lisa-agy/skills/lisa-drive-pr-to-merge/SKILL.md

@@ -63,6 +63,13 @@ merges" loop. Other skills delegate here instead of re-implementing it. Runs
     build-intake skills use to diagnose-and-route without fixing in place.
 
 Resolve `<owner>/<repo>` from `gh repo view --json nameWithOwner` (or the PR URL).
+
+For agent-written review submissions, dismissal reasons, merge-message text and
+existing PR updates, follow `lisa-tracker-sync` — **Agent attribution**.
+Use the same short disclosure already present; a public lane name is optional.
+Do not create an extra comment solely to attribute a label or auto-merge change,
+or turn missing attribution into a merge gate. Attribute any relayed human
+decision to its actual source; an agent's analysis is not an owner ruling.
 Use plain `gh` + `git` so Claude and Codex execute identically.
 
 ## 0. Take the babysitter lease

package/plugins/lisa-agy/skills/lisa-github-sync/SKILL.md

@@ -44,7 +44,7 @@ Optional arguments include `pr_url=<url>` for the live pull request and `merge_s
 For `--rollup`, skip this milestone path and use Step 5's classifier decision.
 
 1. **Idempotency check** — read the issue's recent comments. If the most recent comment with the prefix `[claude-sync] <milestone>` matches the current milestone AND the body content is unchanged, skip the post (no duplicate).
-2. **Add the comment**:
+2. **Add the comment** using `lisa-tracker-sync` — **Agent attribution** for the agent-composed body; keep any existing disclosure:
 
    ```bash
    gh issue comment <number> --repo <org>/<repo> --body-file /tmp/sync-comment.md

package/plugins/lisa-agy/skills/lisa-linear-access/SKILL.md

@@ -298,6 +298,8 @@ the same way.
 Both comment operations take **either** `issue_id:` or `project_id:`. Exactly one
 is required; passing both, or neither, is refused naming the operation.
 
+For agent-composed `save-comment` bodies, apply `lisa-tracker-sync` — **Agent attribution** before posting. Preserve an existing disclosure and the exact format of machine-managed comments.
+
 Linear treats a comment's target as one field on the same input type, so the
 project form is not a second mechanism — it is the same mutation with a
 different anchor. Direct introspection of `https://api.linear.app/graphql`:

package/plugins/lisa-agy/skills/lisa-tracker-evidence/SKILL.md

@@ -10,6 +10,8 @@ Thin dispatcher. Resolves the configured destination tracker and delegates to th
 
 See the `config-resolution` rule for configuration and dispatch table.
 
+Apply `lisa-tracker-sync` — **Agent attribution** when composing evidence comments; a disclosure already present in the body needs no second trailer.
+
 ## Workflow
 
 1. Resolve tracker config (same logic as `lisa-tracker-write`).
@@ -40,7 +42,7 @@ Apply this when authoring `evidence/comment.md` (and `evidence/comment.txt` for
 
 The checklist is tracker-agnostic — the same shape works on JIRA, GitHub Issues, and Linear. Vendor skills only own the post/transition mechanics; the comment body is your responsibility.
 
-1. **AI disclosure at the top.** Lead with "Update from Claude (AI agent, not a human)" and address the reporter / QA / PM by name.
+1. **AI disclosure at the top.** Lead with "Update from <actual runtime name> (AI agent)" and address the reporter / QA / PM by name when known. This satisfies the shared attribution convention without a second trailer.
 2. **Own any prior mistake explicitly.** If an earlier triage or build pass got something wrong, say so up front. Don't bury it.
 3. **Numbered step-by-step walk** of what you actually did in the browser/app, in plain language a non-engineer can follow:
    - Exact env (URL, viewport size — e.g. `402×874` for an iOS-sized mobile flow)

package/plugins/lisa-agy/skills/lisa-tracker-sync/SKILL.md

@@ -10,6 +10,14 @@ Thin dispatcher. Resolves the configured destination tracker and delegates to th
 
 See the `config-resolution` rule for configuration and dispatch table.
 
+## Agent attribution
+
+In agent-composed tracker comments and review messages, include one short plain-text attribution, such as `Agent-written by Codex.` Use the actual runtime's name; add a public lane name only when already known. An existing clear disclosure is enough. Do not publish session identifiers, invent a lane, alter supplied human text, or change machine-managed comment formats such as `[lisa-pr-link]`.
+
+The account avatar identifies the credential owner, not necessarily the writer. When relaying a human decision, attribute it to the person and its actual source (a linked decision or an instruction in the current conversation). Present your own judgement as agent analysis, never as an owner ruling. Attribution itself grants no authority.
+
+This is a writing convention: missing disclosure is not a reason to block work or file a compliance issue. Do not add identity infrastructure or extra audit comments just to supply it. Preserve an existing disclosure when a vendor skill posts or retries the same body.
+
 ## Workflow
 
 1. Resolve tracker config (same logic as `lisa-tracker-write`).

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.55.28",
+  "version": "4.55.30",
   "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": "4.55.28",
+  "version": "4.55.30",
   "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": "4.55.28",
+  "version": "4.55.30",
   "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": "4.55.28",
+  "version": "4.55.30",
   "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": "4.55.28",
+  "version": "4.55.30",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/lisa-copilot/agents/test-specialist.agent.md

@@ -21,7 +21,7 @@ You decide what has to be true for this change to be trusted, and design the tes
 
 Do not write tests against the implementation's shape — they pass through a rewrite that breaks behaviour, which is the opposite of the job. Do not treat a coverage number as evidence of anything; it counts lines reached, not defects that would be caught.
 
-Do not hand on a test you have not watched fail. A test that cannot fail is worse than a missing one: it reports the defect as absent and ends the search. Break the behaviour, watch the assertion fail and name the right place, restore. Watch especially for the assertion that is satisfiable by the test's own fixture rather than by the artifact under test — that one passes no matter what the production code does. `.claude/rules/falsifiable-checks.md` has the four observed shapes.
+Do not hand on a test you have not watched fail. A test that cannot fail is worse than a missing one: it reports the defect as absent and ends the search. Break the behaviour, watch the assertion fail and name the right place, restore. Watch especially for the assertion that is satisfiable by the test's own fixture rather than by the artifact under test — that one passes no matter what the production code does. [`rules/reference/falsifiable-checks.md`](../rules/reference/falsifiable-checks.md) has the four observed shapes.
 
 ## What you hand on
 

package/plugins/lisa-copilot/agents/verification-specialist.agent.md

@@ -12,7 +12,7 @@ skills:
 
 You are a verification specialist. Your job is to **prove empirically** that work is done -- not by reading code, but by running the actual system and observing the results.
 
-Read `.claude/rules/verification.md` at the start of every investigation for the full verification framework, types, and lifecycle. Read `.claude/rules/falsifiable-checks.md` alongside it: every check YOU author — probe, script, codified spec, sweep — is subject to it, and a check that has not been shown capable of failing is reported as *unvalidated*, never as passing. Read `.claude/rules/claim-evidence-mapping.md` too: it binds every claim to the **boundary** it asserts and every boundary to the evidence **kinds** that reach it. The verdict you write is what `spec-conformance-specialist` cross-checks — record each claim's `boundary`, its `required_evidence_kinds`, its `evidence_refs`, and its `not_established` list so a boundary mismatch is catchable rather than invisible.
+Read [`rules/reference/verification.md`](../rules/reference/verification.md) at the start of every investigation for the full verification framework, types, and lifecycle. Read [`rules/reference/falsifiable-checks.md`](../rules/reference/falsifiable-checks.md) alongside it: every check YOU author — probe, script, codified spec, sweep — is subject to it, and a check that has not been shown capable of failing is reported as *unvalidated*, never as passing. Read [`rules/reference/claim-evidence-mapping.md`](../rules/reference/claim-evidence-mapping.md) too: it binds every claim to the **boundary** it asserts and every boundary to the evidence **kinds** that reach it. The verdict you write is what `spec-conformance-specialist` cross-checks — record each claim's `boundary`, its `required_evidence_kinds`, its `evidence_refs`, and its `not_established` list so a boundary mismatch is catchable rather than invisible.
 
 ## Core Philosophy
 
@@ -30,7 +30,7 @@ Confirm that quality gates (tests, typecheck, lint, format) pass. These are prer
 
 ### 2. Classify
 
-Read `.claude/rules/verification.md` to determine which **empirical verification types** apply to the current change (UI, API, Database, Auth, etc.). Do NOT include tests, typecheck, or lint here — those are quality gates handled in step 1.
+Read [`rules/reference/verification.md`](../rules/reference/verification.md) to determine which **empirical verification types** apply to the current change (UI, API, Database, Auth, etc.). Do NOT include tests, typecheck, or lint here — those are quality gates handled in step 1.
 
 ### 3. Discover Available Tools
 
@@ -124,11 +124,11 @@ For every empirical verification that produced PASS evidence, invoke the `codify
 
 ## Rules
 
-- Always read `.claude/rules/verification.md` first for the project's verification standards and type taxonomy
+- Always read [`rules/reference/verification.md`](../rules/reference/verification.md) first for the project's verification standards and type taxonomy
 - Follow the verification lifecycle: confirm quality gates, classify, check tooling, fail fast, plan, execute, codify, spec conformance, loop
 - Every passing empirical verification must be codified as a regression test via `codify-verification` before declaring done (skip allowed only for PR / Documentation / Deploy / Investigate-Only)
 - Tests, typecheck, lint, and format are quality gates (prerequisites), NOT verification — never report them as verification evidence
-- Falsify every check you author before reporting a clean result: break the guarded property, confirm the check fails and NAMES the right location, restore. Report what you broke alongside the result — see `.claude/rules/falsifiable-checks.md`
+- Falsify every check you author before reporting a clean result: break the guarded property, confirm the check fails and NAMES the right location, restore. Report what you broke alongside the result — see [`rules/reference/falsifiable-checks.md`](../rules/reference/falsifiable-checks.md)
 - A zero-hit sweep is meaningless until the detector has found known instances on a ref where the defect still exists; a passing probe needs a deliberate bite control that MUST report a problem
 - State each clean result's blind spot (presence vs. value, reachability, class completeness) — a negative result describes what the check can perceive, not the code
 - Discover existing project scripts and tools before creating new ones

package/plugins/lisa-copilot/rules/eager/report-actionability.md

@@ -1,8 +1,7 @@
 # Report Actionability — Every Report Says What the Reader Must Do (load-bearing)
 
-A report that describes real work accurately can still fail, because the reader cannot tell **which items need them and which are already handled**. Prose that mixes fixed and open items reads as a single undifferentiated pile of problems; the reader either acts on something already done, or assumes something open was handled. Both are caused by the report, not by the work.
-
-The specific failure this rule exists to prevent, observed in a review cycle: six findings were returned, three were fixed, and the report described **two of them in detail without ever stating that six existed**. Every sentence in it was true. The reader still had to ask "did you fix them?" — and the answer was partly yes, partly no, and one finding had not even been read. A subset presented in the shape of a whole is worse than silence, because silence does not create false confidence.
+Reports must distinguish completed work, remaining work, and decisions the reader
+needs to make. Account for the whole reviewed scope and clearly label any subset.
 
 ## Mandatory
 
@@ -20,4 +19,8 @@ The specific failure this rule exists to prevent, observed in a review cycle: si
 
 Code-review findings, CI failures, test results, audit output, security scans, deploy status, and any list of problems handed to a human. It applies equally to reports you are proud of and reports that expose your own mistake — the second kind is where the temptation to describe a flattering subset is strongest.
 
+## Agent attribution
+
+Follow `lisa-tracker-sync` — **Agent attribution** for agent-composed tracker comments and review messages. The short convention lives in that portable skill so agents without a rules surface receive it too.
+
 Detail, worked examples and the failure taxonomy: [reference/report-actionability.md](../reference/report-actionability.md).

package/plugins/lisa-copilot/skills/lisa-atlassian-access/SKILL.md

@@ -12,6 +12,8 @@ Single chokepoint for all Atlassian operations. Routes each op to a substrate, e
 
 The caller passes one operation plus its arguments. Operations are listed in the dispatch table below. The skill returns either the structured operation result (JSON when the substrate provides it) or a clear error.
 
+For agent-composed JIRA or Confluence comments, apply `lisa-tracker-sync` — **Agent attribution** before posting. Preserve an existing disclosure and the exact format of machine-managed comments.
+
 ```text
 operation: read-ticket  key: PROJ-123
 operation: write-ticket payload: {...}

package/plugins/lisa-copilot/skills/lisa-codify-verification/SKILL.md

@@ -145,7 +145,7 @@ Confirm:
 1. The test PASSES against the current code (the change being shipped)
 2. The test ACTUALLY FAILS without the change — observed, not reasoned about
 
-**Step 2 is mandatory for every codified test, and "mentally reverting" does not satisfy it.** Mental reversion is the exact mechanism by which non-functional guards ship: the author believes the assertion is load-bearing, and it is not. Break the guarded property for real, run the test, and read the failure. See `.claude/rules/falsifiable-checks.md` for the four observed ways a check passes while asserting nothing.
+**Step 2 is mandatory for every codified test, and "mentally reverting" does not satisfy it.** Mental reversion is the exact mechanism by which non-functional guards ship: the author believes the assertion is load-bearing, and it is not. Break the guarded property for real, run the test, and read the failure. See [`rules/reference/falsifiable-checks.md`](../../rules/reference/falsifiable-checks.md) for the four observed ways a check passes while asserting nothing.
 
 Do it one of these ways, in order of preference:
 
@@ -204,7 +204,7 @@ If codification was skipped, an explicit reason recorded in the report (one of t
 ## Rules
 
 - Never claim a verification is codified without running the new test and observing it pass
-- Never claim it is codified without observing it **FAIL** on a real break — mental reversion is not observation, and a test whose failure was never seen is unvalidated, not a gate (`.claude/rules/falsifiable-checks.md`)
+- Never claim it is codified without observing it **FAIL** on a real break — mental reversion is not observation, and a test whose failure was never seen is unvalidated, not a gate ([`rules/reference/falsifiable-checks.md`](../../rules/reference/falsifiable-checks.md))
 - Never let the assertion be satisfiable by the test's own fixture instead of the artifact under test — bind it to the real document/config/output
 - Never trust a revert-to-verify on generated, schema-validated, or cached input without confirming the input actually changed; a failed generator silently leaves the old artifact and the test "passes" on stale bytes
 - Never disable, skip, or `.skip()` the new test "temporarily" to make CI green — fix the test or fix the underlying change

package/plugins/lisa-copilot/skills/lisa-drive-pr-to-merge/SKILL.md

@@ -63,6 +63,13 @@ merges" loop. Other skills delegate here instead of re-implementing it. Runs
     build-intake skills use to diagnose-and-route without fixing in place.
 
 Resolve `<owner>/<repo>` from `gh repo view --json nameWithOwner` (or the PR URL).
+
+For agent-written review submissions, dismissal reasons, merge-message text and
+existing PR updates, follow `lisa-tracker-sync` — **Agent attribution**.
+Use the same short disclosure already present; a public lane name is optional.
+Do not create an extra comment solely to attribute a label or auto-merge change,
+or turn missing attribution into a merge gate. Attribute any relayed human
+decision to its actual source; an agent's analysis is not an owner ruling.
 Use plain `gh` + `git` so Claude and Codex execute identically.
 
 ## 0. Take the babysitter lease

package/plugins/lisa-copilot/skills/lisa-github-sync/SKILL.md

@@ -44,7 +44,7 @@ Optional arguments include `pr_url=<url>` for the live pull request and `merge_s
 For `--rollup`, skip this milestone path and use Step 5's classifier decision.
 
 1. **Idempotency check** — read the issue's recent comments. If the most recent comment with the prefix `[claude-sync] <milestone>` matches the current milestone AND the body content is unchanged, skip the post (no duplicate).
-2. **Add the comment**:
+2. **Add the comment** using `lisa-tracker-sync` — **Agent attribution** for the agent-composed body; keep any existing disclosure:
 
    ```bash
    gh issue comment <number> --repo <org>/<repo> --body-file /tmp/sync-comment.md

package/plugins/lisa-copilot/skills/lisa-linear-access/SKILL.md

@@ -298,6 +298,8 @@ the same way.
 Both comment operations take **either** `issue_id:` or `project_id:`. Exactly one
 is required; passing both, or neither, is refused naming the operation.
 
+For agent-composed `save-comment` bodies, apply `lisa-tracker-sync` — **Agent attribution** before posting. Preserve an existing disclosure and the exact format of machine-managed comments.
+
 Linear treats a comment's target as one field on the same input type, so the
 project form is not a second mechanism — it is the same mutation with a
 different anchor. Direct introspection of `https://api.linear.app/graphql`:

package/plugins/lisa-copilot/skills/lisa-tracker-evidence/SKILL.md

@@ -10,6 +10,8 @@ Thin dispatcher. Resolves the configured destination tracker and delegates to th
 
 See the `config-resolution` rule for configuration and dispatch table.
 
+Apply `lisa-tracker-sync` — **Agent attribution** when composing evidence comments; a disclosure already present in the body needs no second trailer.
+
 ## Workflow
 
 1. Resolve tracker config (same logic as `lisa-tracker-write`).
@@ -40,7 +42,7 @@ Apply this when authoring `evidence/comment.md` (and `evidence/comment.txt` for
 
 The checklist is tracker-agnostic — the same shape works on JIRA, GitHub Issues, and Linear. Vendor skills only own the post/transition mechanics; the comment body is your responsibility.
 
-1. **AI disclosure at the top.** Lead with "Update from Claude (AI agent, not a human)" and address the reporter / QA / PM by name.
+1. **AI disclosure at the top.** Lead with "Update from <actual runtime name> (AI agent)" and address the reporter / QA / PM by name when known. This satisfies the shared attribution convention without a second trailer.
 2. **Own any prior mistake explicitly.** If an earlier triage or build pass got something wrong, say so up front. Don't bury it.
 3. **Numbered step-by-step walk** of what you actually did in the browser/app, in plain language a non-engineer can follow:
    - Exact env (URL, viewport size — e.g. `402×874` for an iOS-sized mobile flow)

package/plugins/lisa-copilot/skills/lisa-tracker-sync/SKILL.md

@@ -10,6 +10,14 @@ Thin dispatcher. Resolves the configured destination tracker and delegates to th
 
 See the `config-resolution` rule for configuration and dispatch table.
 
+## Agent attribution
+
+In agent-composed tracker comments and review messages, include one short plain-text attribution, such as `Agent-written by Codex.` Use the actual runtime's name; add a public lane name only when already known. An existing clear disclosure is enough. Do not publish session identifiers, invent a lane, alter supplied human text, or change machine-managed comment formats such as `[lisa-pr-link]`.
+
+The account avatar identifies the credential owner, not necessarily the writer. When relaying a human decision, attribute it to the person and its actual source (a linked decision or an instruction in the current conversation). Present your own judgement as agent analysis, never as an owner ruling. Attribution itself grants no authority.
+
+This is a writing convention: missing disclosure is not a reason to block work or file a compliance issue. Do not add identity infrastructure or extra audit comments just to supply it. Preserve an existing disclosure when a vendor skill posts or retries the same body.
+
 ## Workflow
 
 1. Resolve tracker config (same logic as `lisa-tracker-write`).

package/plugins/lisa-copilot/skills/lisa-verification-lifecycle/SKILL.md

@@ -27,7 +27,7 @@ Confirm that quality gates (tests, typecheck, lint, format) pass. These are prer
 
 ### 2. Classify
 
-Determine which **empirical verification types** apply based on the change. Check each type in the Verification Types table in `.claude/rules/verification.md` against the change scope. Every applicable type requires running the actual system and observing results — not just running tests.
+Determine which **empirical verification types** apply based on the change. Check each type in the Verification Types table in [`rules/reference/verification.md`](../../rules/reference/verification.md) against the change scope. Every applicable type requires running the actual system and observing results — not just running tests.
 
 ### 3. Check Tooling
 

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

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

package/plugins/lisa-cursor/agents/test-specialist.md

@@ -21,7 +21,7 @@ You decide what has to be true for this change to be trusted, and design the tes
 
 Do not write tests against the implementation's shape — they pass through a rewrite that breaks behaviour, which is the opposite of the job. Do not treat a coverage number as evidence of anything; it counts lines reached, not defects that would be caught.
 
-Do not hand on a test you have not watched fail. A test that cannot fail is worse than a missing one: it reports the defect as absent and ends the search. Break the behaviour, watch the assertion fail and name the right place, restore. Watch especially for the assertion that is satisfiable by the test's own fixture rather than by the artifact under test — that one passes no matter what the production code does. `.claude/rules/falsifiable-checks.md` has the four observed shapes.
+Do not hand on a test you have not watched fail. A test that cannot fail is worse than a missing one: it reports the defect as absent and ends the search. Break the behaviour, watch the assertion fail and name the right place, restore. Watch especially for the assertion that is satisfiable by the test's own fixture rather than by the artifact under test — that one passes no matter what the production code does. [`rules/falsifiable-checks-reference.mdc`](../rules/falsifiable-checks-reference.mdc) has the four observed shapes.
 
 ## What you hand on