@codyswann/lisa 4.63.0 → 4.64.1

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "4.63.0",
+  "version": "4.64.1",
   "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": "4.63.0",
+  "version": "4.64.1",
   "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": "4.63.0",
+  "version": "4.64.1",
   "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": "4.63.0",
+  "version": "4.64.1",
   "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": "4.63.0",
+  "version": "4.64.1",
   "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": "4.63.0",
+  "version": "4.64.1",
   "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": "4.63.0",
+  "version": "4.64.1",
   "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": "4.63.0",
+  "version": "4.64.1",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "4.63.0",
+  "version": "4.64.1",
   "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": "4.63.0",
+  "version": "4.64.1",
   "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": "4.63.0",
+  "version": "4.64.1",
   "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": "4.63.0",
+  "version": "4.64.1",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/rules/eager/tool-access-gate.md

@@ -1,21 +1,23 @@
 # Tool Access Gate (load-bearing)
 
+- If you can't reach something you need, such as a repository, a secret, an API, or a connector, say exactly what's missing in your first message and stop. Don't substitute, mock, or guess.
+
+If the missing access is discovered after work begins, say exactly what's
+missing in your next message and stop.
+
 Only take on work you can finish. Before implementation starts — and again the
 moment a new requirement surfaces mid-flow — enumerate every external tool the
 work item needs (implementation, proof command, remote verification: AWS CLI,
 Figma, Jam, Sentry, SonarCloud, PostHog, device/browser harnesses, databases,
 deploy targets, …) and **prove access with a cheap read-only probe**, routing
-through the matching `*-access` skill where one exists. Presence on PATH is not
-access; a probe failure counts only after exhausting documented credential
-sources.
+through the matching `*-access` skill where one exists. Resolve credentials through the documented access path before probing;
+presence on PATH is not access. If that path or the probe cannot provide the
+required access, report the gap and stop.
 
-If a required tool is inaccessible: **break out — never work around it.** Post
-an "Access Needed" comment on the work item (plain-English summary, the exact
-credential/role/env var to grant, and the probe that must pass), transition it
-to the configured blocked state with the `human_needed` marker, and write a
-`blocked` verification verdict. Substituting weaker verification, mocking the
-inaccessible system, guessing at tool contents, or narrowing scope to dodge the
-gap are all forbidden.
+The message must name the missing resource, the operation it blocks, and any
+known access requirement, without exposing secret values. Substituting weaker
+verification, mocking the inaccessible system, guessing at its contents, or
+narrowing scope to dodge the gap are all forbidden.
 
-Full contract (probe table, comment format, resume path):
+Full contract (probe table, blocker report, resume path):
 [reference/tool-access-gate.md](../reference/tool-access-gate.md).

package/plugins/src/base/rules/reference/tool-access-gate.md

@@ -1,9 +1,14 @@
 # Tool Access Gate
 
+- If you can't reach something you need, such as a repository, a secret, an API, or a connector, say exactly what's missing in your first message and stop. Don't substitute, mock, or guess.
+
+If the missing access is discovered after work begins, say exactly what's
+missing in your next message and stop.
+
 A flow may only take on work it can actually finish. If completing a work item —
 including its empirical verification — requires an external tool or system the
-agent cannot access, the flow must **break out and report the missing access on
-the work item**, never work around it. This is the flow-side arm of the factory
+agent cannot access, the flow must **tell the user exactly what access is missing and stop**, never
+work around it. This is the flow-side arm of the factory
 contract: intake validates that the factory has "the tooling *and provable
 access to that tooling*"; this gate re-proves that promise at execution time and
 enforces it for tools discovered mid-flow.
@@ -31,7 +36,8 @@ enforces it for tools discovered mid-flow.
    environment.
 2. **Continuously** — the moment a previously unknown tool requirement surfaces
    mid-flow (e.g. verification turns out to need CloudWatch log capture), probe
-   it right then and record the new tool + probe result in the same places the
+   it right then. If access is unavailable, report it and stop. Otherwise, record
+   the new tool + probe result in the same places the
    preflight wrote to (the plan/tracker artifact and the affected tasks'
    `metadata.required_access`) before continuing. Discovery timing changes
    nothing about the protocol.
@@ -62,44 +68,31 @@ Example probes:
 | Deploy target | reach the target environment with the credentials the verify step will use |
 | Device/browser harness | the harness's own doctor/smoke entry (e.g. `playwright --version` plus a trivial headless launch) |
 
-A probe failure only counts **after exhausting the documented credential
-sources** (the same order the `verification` rule mandates): project e2e
-config/fixtures, `.lisa.config.local.json` and environment variables, then
-documented work-item credentials (e.g. `Sign-in Required`). Missing access you
-could have resolved from those sources is not a blocker — resolve it and
-proceed.
+Resolve credentials through the documented sources before probing: project
+e2e config/fixtures, `.lisa.config.local.json` and environment variables, then
+documented work-item credentials (e.g. `Sign-in Required`). If the documented
+access path or probe cannot provide the required access, report the gap and
+stop. Do not continue exploring substitute sources after confirming the gap.
 
-Record the enumeration and probe results in the flow's plan/tracker artifact
+Record successful probes in the flow's plan/tracker artifact
 (and task `metadata.required_access` where the flow's task contract carries
 it), so the verifier can confirm the gate ran.
 
 ## On failure: break out, never work around
 
-When a required tool fails its probe:
-
-1. **Stop the affected work immediately.** Do not start (or continue)
-   implementation whose completion condition cannot be proven.
-2. **Update the work item with an "Access Needed" comment** containing, for
-   each missing tool:
-   - a one-sentence plain-English summary a non-technical operator can act on
-     ("Lisa needs read access to the app's AWS logs to prove this fix works");
-   - the tool and the operation it is needed for (which acceptance criterion /
-     verification step);
-   - the exact access to grant: env var name, credential/role/permission, or
-     account invitation required;
-   - the probe command that must pass once access is granted.
-3. **Transition the work item to the configured blocked state** and apply the
-   configured `human_needed` / needs-human marker — missing access is a
-   **human-only blocker** (someone must provision credentials or grant access);
-   do not fabricate a build-ready ticket for it.
-4. **Release the verification gate honestly**: write the verdict with
-   `status: "blocked"`, and mark each acceptance criterion whose proof depends
-   on the missing tool as `status: "blocked"` with the missing-access
-   diagnosis as its `evidence`; unaffected criteria keep their real
-   `pass`/`fail` result.
-5. **Resume only when the probe passes.** When access is granted, re-run the
-   recorded probe before continuing; `repair-intake` re-validates blocked items
-   whose blockers cleared.
+When required access is unavailable, tell the user and stop. Use the first
+message if the gap is already known, or the next message if it is discovered
+mid-task. The message must state:
+
+- the exact resource that cannot be reached and the operation it blocks;
+- the observed failure and, if known, the credential name, role, permission, or
+  invitation needed — never secret values, and never a guessed diagnosis;
+- the read-only probe that must pass before work can resume.
+
+Do not substitute, mock, guess, or continue other tasks as a workaround.
+Reporting does not depend on access to a tracker, and it does not require
+creating a new ticket. Resume after the required access is available and its
+probe passes.
 
 ### Forbidden workarounds
 
@@ -116,6 +109,6 @@ None of the following ever substitutes for missing access:
   ticket points at).
 - Silently narrowing scope so the inaccessible part is "out of scope".
 
-If a *partial* set of tasks is unaffected by the missing access, those tasks may
-complete, but the work item as a whole must not be marked terminal-done while
-any acceptance criterion's proof is blocked on access.
+Keep results already obtained, but stop further work until the required access
+is available. An inaccessible tracker does not prevent reporting the blocker
+to the user. Do not claim blocked acceptance criteria have passed.

package/plugins/src/base/rules/reference/usage-accounting.md

@@ -252,6 +252,10 @@ The rollup contract is additive across the hierarchy: PRDs may roll up Epics/Sto
 - Re-running with the same logical entry set must produce byte-identical output. Rewriting a legacy
   primary-only marker or the 2.222.0 transitional marker migrates once to the canonical
   primary-plus-extension layout; subsequent rewrites are byte-identical.
-- Do not include timestamps in the section preamble or token lines.
+- Do not add timestamps to the section preamble or primary usage token. Sourced
+  lifecycle timestamps belong only in the optional effectiveness extension.
 
 Idempotency is enforced by `entry_id` for direct entries and by the fixed rollup token field order for totals.
+## Delivery observations
+
+Read `references/effectiveness.md` in the `lisa-usage-accounting` skill for the optional effectiveness extension, clock definitions, and recurrence storage contract shared by every supported agent. The primary 17-field usage token remains unchanged.

package/plugins/src/base/skills/lisa-learnings-audit/SKILL.md

@@ -260,11 +260,20 @@ computed **deterministically — never estimated by the model**:
 
 1. **Normalize** the invariant text: trim leading/trailing whitespace,
    collapse every internal whitespace run to a single space, lowercase.
-2. **Hash** in Bash: `printf '%s' "$normalized" | shasum -a 256 | cut -c1-12`.
+2. **Hash** through the shared implementation: write the invariant to a text file
+   and run `lisa effectiveness fingerprint --input <file>`. This performs the
+   normalization above and returns the first 12 SHA-256 hex characters.
 
 The same knowledge item therefore always produces the same key across runs,
 regardless of which session computes it.
 
+Read `lisa effectiveness report` for committed post-control recurrence counts by
+the same `<surface>+<invariant-hash>` key. Cite the count and occurrence sources as
+evidence when deciding whether a control helped. Missing history means unknown,
+not a successful control. Counts do not automatically justify a new ticket: apply
+the existing worth-doing judgment. The learning entry's content-version fingerprint
+is a different identifier and must not be substituted for this invariant hash.
+
 Before filing anything, search the tracker for the marker in
 **open AND closed** issues — and key the search on the deterministic
 `<surface>` prefix **first**, using the hash as disambiguation only, so even

package/plugins/src/base/skills/lisa-queue-status/SKILL.md

@@ -69,6 +69,16 @@ For each inspected queue, report:
 
 The report should stay terminal-first and immediately actionable: observable queue facts first, then the smallest useful next step.
 
+## Delivery effort
+
+Alongside queue counts, run the read-only `lisa effectiveness report`. Show observed
+human interventions per accepted outcome, its numerator/denominator, and evidence
+sources. State that this covers locally observed outcomes; absent reports or null
+attention mean **unknown**, not zero. If queue-wide coverage has not been verified,
+do not imply the ratio describes the whole queue. Show the separate run clocks and
+committed recurring-failure counts when present. Do not create reports, change
+tracker state, or use PR/token counts as outcome-value proxies from this skill.
+
 ## Pull request arming (#3903)
 
 Alongside the two work queues, report the **arming state of the repo's open pull requests**. A PR whose `autoMergeRequest` is `null` is fully green and permanently unmergeable: every check passes, `mergeStateStatus` is green, nothing complains, and it waits forever. Green-and-unarmed and green-and-waiting read identically on every other surface, so this is the one place that asks the question.

package/plugins/src/base/skills/lisa-usage-accounting/SKILL.md

@@ -140,6 +140,15 @@ the managed comment path.
 
 ### Step 3 — Apply the requested operation
 
+For lifecycle rows, include the optional `effectiveness` observations defined in
+[portable effectiveness reference](references/effectiveness.md): four separate clocks, explicit unknowns, sourced human
+events, Lisa version, and worker configuration revision. Preserve extensions on old
+rows. After the canonical host write passes readback, mirror the row through
+`lisa effectiveness record --input <json-file>` for local status reports. On a
+confirmed recurrence after its control shipped, use `lisa effectiveness recurrence
+--input <json-file>` with the stable source event identity; commit that history
+through normal checks. Do not infer human minutes or invent missing runtime telemetry.
+
 All three operations use the shared utilities and rule contract; they differ only in which inputs
 they require and whether they recompute child totals:
 

package/plugins/src/base/skills/lisa-usage-accounting/references/effectiveness.md

@@ -0,0 +1,63 @@
+# Delivery observations (optional extension)
+
+Keep the primary 17-field usage token unchanged. New writers attach
+`LisaUsageEntry.effectiveness`; the shared serializer emits the adjacent
+`lisa:usage-effectiveness` token correlated by `entry_id`. Older readers may ignore
+the extension. New writers preserve it when rewriting historical rows.
+
+Each observation has `schema: 1` and all these fields, using `null` for unknown:
+
+- `lisaVersion`, `workerConfigRevision`: observed version/revision tags.
+- `workerWallMs`: actual execution duration for this run.
+- `feedbackMs`: measured blocking request-to-response samples in milliseconds.
+  Start when this worker issues the request; stop when its response is available.
+  Waiting on another agent is queue latency and is excluded. `[]` means a measured
+  run with no such requests; `null` means unavailable telemetry.
+- `workerSource`: runtime evidence identifier for wall time and feedback samples.
+- `attention`: observed `{id, source}` human interventions. Derive these from
+  non-bot ready-role flips, blocked-item answers, and review interventions. Dedupe
+  by stable tracker event identity. `[]` means the relevant history was inspected
+  and contained no interventions; `null` means it was not measured. Never infer
+  human minutes from gaps between comments.
+- `readyAt`, `acceptedAt`: canonical UTC timestamps from the configured ready-role
+  flip and terminal accepted outcome. The elapsed clock excludes pre-ready intake.
+  A merge or queued deployment alone is not acceptance. `lifecycleSources` holds
+  the tracker/release evidence for these timestamps.
+- `reworkSources`: observed reclaims, QA bounces, or reverts. The existing
+  `lisa-delivery-effectiveness` skill owns rework rates and other outcome measures;
+  these are observations, not a competing score.
+
+At the existing implement, verify, and intake accounting milestones, supply these
+observations even if every measurement is unknown. Collect runtime observations
+as work proceeds; do not reconstruct feedback samples from memory at the end.
+Runtime APIs differ across agents: unavailable measurements remain null on any
+agent rather than being estimated from tool/PR/token counts.
+
+After the canonical usage row is read back, mirror `{entryId, artifactRef,
+effectiveness}` with `lisa effectiveness record --input <json-file>`. Mirrors under
+`.lisa/effectiveness/` are ignored and disposable; reconstruct them from usage
+extensions when needed. Do not commit timing reports or store secrets in sources.
+The command refuses a non-ignored destination. Report write failures explicitly;
+they must not erase the canonical accounting row or claim measurement succeeded.
+
+Record an actual post-control failure using `lisa effectiveness recurrence --input
+<json-file>`. The object contains `invariant`, `surface`, `controlRef`,
+`controlShippedAt`, `occurrenceRef`, and `occurredAt`. Both timestamps use canonical
+UTC ISO strings with milliseconds. Verify that the control/learning really shipped
+before this occurrence; initial failures and unshipped proposals are not recurrences.
+Use a stable occurrence source, such as a test-run failure or tracker event, so
+replays and reports from different agents identify the same event.
+
+`.lisa/RECURRENCES.jsonl` is committed history: distinct occurrence identities are
+the durable count. Its existing built-in `merge=union` attribute retains concurrent
+branch appends, and the reader deduplicates replayed events. Never hand-increment
+a counter, compact away occurrences, or add counts to the bounded learnings ledger.
+Normal review, secret checks, and push requirements still apply to this file.
+The writer refuses missing merge setup and conflicting evidence for one identity.
+
+`lisa effectiveness report` is read-only. Its per-run feedback distribution, wall
+time, attention count, and ready-to-accepted duration remain separate. Attention
+ratios cover only the locally observed accepted outcomes, with the reported sources
+and denominator. Missing local records are unknown coverage, not zero factory effort.
+Rebuild local records for the requested reporting scope before making a scope-wide
+claim; never extrapolate a local subset to the whole queue.