@codyswann/lisa 2.211.2 → 2.212.0

package/plugins/lisa-copilot/rules/reference/tool-access-gate.md

@@ -0,0 +1,121 @@
+# Tool Access Gate
+
+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
+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.
+
+"Tool" means any external surface the work depends on, for example:
+
+- Cloud/provider CLIs and APIs: AWS (CloudWatch logs, S3, …), GCP, Azure
+- Design sources: Figma
+- Bug/session capture: Jam
+- Observability: Sentry, PostHog, CloudWatch
+- Quality gates: SonarCloud
+- Trackers and docs: JIRA/Confluence, Linear, Notion, GitHub
+- Device/browser harnesses: Playwright, Maestro, Detox, simulators/emulators
+- Databases, deploy targets, and protected environments
+
+## When the gate runs
+
+1. **Preflight** — after the completion condition is defined and before any
+   implementation task starts, enumerate every tool required by (a) the
+   implementation itself, (b) the proof command / verification plan, and
+   (c) remote verification and post-deploy checks. Sources for the enumeration:
+   the work item (description, comments, attachments — a Figma link or Jam
+   capture implies that tool), acceptance criteria, `testing_requirements`,
+   the `verification` metadata, and the deploy pipeline for the target
+   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
+   preflight wrote to (the plan/tracker artifact and the affected tasks'
+   `metadata.required_access`) before continuing. Discovery timing changes
+   nothing about the protocol.
+
+## Proving access
+
+Access is proven by a **cheap, read-only probe that actually exercises the
+authenticated surface** — tool presence on PATH is not access.
+
+- Vendors with an access layer MUST be probed through their `*-access` skill
+  (see the `integration-access-layer` rule): `lisa-atlassian-access`,
+  `lisa-notion-access`, `lisa-linear-access`, `lisa-jam-access`,
+  `lisa-sonarcloud-access`, `lisa-sentry-access`, `lisa-posthog-access`,
+  `lisa-expo:play-store-access`. A loud access-skill failure naming a missing
+  env var IS a failed probe.
+- Vendors without an access layer are probed with the cheapest authenticated
+  read the runtime offers (an MCP tool call, a CLI read, a REST GET).
+
+Example probes:
+
+| Tool | Probe |
+|---|---|
+| AWS CLI | `aws sts get-caller-identity`, plus the service-level read the task needs (e.g. `aws logs describe-log-groups --max-items 1`) |
+| GitHub | a repository-scoped read against the target repo (e.g. `gh api repos/<owner>/<repo> --jq .full_name`, or the exact read the work item needs) — `gh auth status` alone only proves host auth, not access to the repository |
+| Figma | a read call against the linked file via the available Figma MCP/API surface |
+| Sentry / Jam / SonarCloud / PostHog / Atlassian / Linear / Notion | the matching `*-access` skill's resolve/auth check |
+| Database | the project's documented read-only connection check |
+| 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.
+
+Record the enumeration and probe results 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.
+
+### Forbidden workarounds
+
+None of the following ever substitutes for missing access:
+
+- Swapping the verification for a weaker one the agent *can* run (unit tests or
+  code reading instead of the required log capture / UI observation).
+- Mocking, stubbing, or simulating the inaccessible system to make the proof
+  "pass".
+- Marking work done on artifact-only evidence, or asserting success without the
+  runtime evidence the completion condition demands.
+- Guessing at the tool's contents (e.g. implementing a design without reading
+  the linked Figma file, or "fixing" a bug without the Jam/Sentry evidence the
+  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.

package/plugins/lisa-copilot/skills/lisa-implement/SKILL.md

@@ -138,9 +138,18 @@ This condition is the contract the Verify flow proves and records in the verific
    1. Direct deploy the changes to dev and then Write a simple API client and call the offending API
    2. Start the server on localhost and then Use the Playwright CLI or Chrome DevTools
 
+Using the general-purpose agent in Team Lead session, run the **tool access preflight** per the `tool-access-gate` rule (loaded via the lisa plugin) before any implementation task is created or started:
+
+1. Enumerate every external tool or system this flow will need — for the implementation itself, for the proof command, and for remote verification (AWS CLI/CloudWatch, Figma, Jam, Sentry, SonarCloud, PostHog, device/browser harnesses, databases, deploy targets, trackers, …). Derive the list from the resolved work item (a linked Figma file, Jam capture, or Sentry issue implies that tool), the acceptance criteria, the testing requirements, and the completion condition above.
+2. Prove access to each with its cheapest read-only probe, routing through the matching `*-access` skill where one exists (`integration-access-layer` rule). Tool presence on PATH is not access; a probe failure counts only after exhausting the documented credential sources (project e2e config/fixtures, `.lisa.config.local.json` / env vars, documented work-item credentials).
+3. Record the enumeration and probe results in the plan artifact and in each task's `metadata.required_access`.
+4. If any required tool fails its probe, do NOT start implementation — follow the break-out protocol in the `tool-access-gate` rule: post an "Access Needed" comment on the work item (plain-English summary, the exact credential/role/env var to grant, the probe that must pass), transition the item to the configured blocked state with the `human_needed` marker, write the verification verdict with `status: "blocked"`, and stop. Working around missing access — substituting weaker verification, mocking the inaccessible system, guessing at tool contents, or narrowing scope — is never permitted, for any tool.
+
+The same gate applies **continuously**: if a tool requirement surfaces mid-flow (e.g. verification turns out to need CloudWatch log capture the runtime cannot authenticate to), probe it the moment it is discovered, record the new tool and probe result in the plan artifact and the affected tasks' `metadata.required_access` before continuing, and break out identically on failure.
+
 Using the general-purpose agent in Team Lead session, create tasks needed to complete the request.
 
-Every task MUST include this JSON metadata block. Do NOT omit `skills` (use `[]` if none), `learnings` (use `[]` if none) or `verification`.
+Every task MUST include this JSON metadata block. Do NOT omit `skills` (use `[]` if none), `learnings` (use `[]` if none), `required_access` (use `[]` if the task needs no external tool) or `verification`.
 
 ```json
 {
@@ -151,6 +160,9 @@ Every task MUST include this JSON metadata block. Do NOT omit `skills` (use `[]`
   "testing_requirements": ["..."],
   "skills": ["..."],
   "learnings": ["..."],
+  "required_access": [
+    { "tool": "<external tool/system this task or its verification needs>", "probe": "<the read-only command or *-access check that proves access>", "status": "pass|fail" }
+  ],
   "verification": {
     "type": "ui-recording|api-test|cli-test|database-check|manual-check|documentation",
     "command": "the proof command — must run the actual system and surface its result in the transcript (NOT test/typecheck/lint, those are quality gates). Phrase it so an independent verifier sees the evidence, e.g. `curl -s localhost:3000/health` not `check that health works`",
@@ -177,7 +189,7 @@ Before shutting down the team, execute the Verify flow:
       "plan": "<plan-name>",
       "status": "pass | fail | blocked | in_progress",
       "criteria": [
-        { "task": "<task id or title>", "criterion": "<the completion condition>", "status": "pass | fail", "evidence": "<the proof command run and the observed result>" }
+        { "task": "<task id or title>", "criterion": "<the completion condition>", "status": "pass | fail | blocked", "evidence": "<the proof command run and the observed result; for a blocked criterion, the blocker diagnosis (e.g. the missing access and the probe that must pass)>" }
       ],
       "updated_at": "<ISO8601 UTC>"
     }
@@ -185,10 +197,10 @@ Before shutting down the team, execute the Verify flow:
 
     Set `status: "pass"` only when every criterion is `pass` with real evidence (output from running the system, not a claim). The verdict must be judged by an agent that did NOT implement the change (the `verification-specialist`), never self-certified by the implementer. This is runtime scratch — it is gitignored and MUST NOT be committed (treat it like the secrets exclusion in the commit step).
 
-    On Claude, the `enforce-verification-gate.sh` Stop hook reads this file and **will not let the flow stop** until it shows a terminal, all-`pass` verdict — carrying over the non-bypassable completion gate of the `/goal` primitive, but checked deterministically against real evidence rather than by a transcript-only evaluator model. If you must stop before completion, write the verdict with `status: "blocked"` and the reason — that records the outcome and releases the gate instead of leaving it to spin. But a `blocked` verdict is a last resort, not a shortcut around fillable work: **first resolve every gap you can resolve yourself.** If the work item is thin — missing its Validation Journey, acceptance criteria, or other derivable detail — enrich it: derive the missing detail from the ticket context and the codebase, write it back, and proceed. Do **not** block on a gap you could have filled. Only a blocker that survives that attempt is real, and it is one of two kinds:
+    On Claude, the `enforce-verification-gate.sh` Stop hook reads this file and **will not let the flow stop** until it shows a terminal, all-`pass` verdict — carrying over the non-bypassable completion gate of the `/goal` primitive, but checked deterministically against real evidence rather than by a transcript-only evaluator model. If you must stop before completion, write the verdict with `status: "blocked"` and the reason — marking each criterion whose proof is blocked as `status: "blocked"` with the blocker diagnosis as its `evidence`, while unaffected criteria keep their real `pass`/`fail` result — that records the outcome and releases the gate instead of leaving it to spin. But a `blocked` verdict is a last resort, not a shortcut around fillable work: **first resolve every gap you can resolve yourself.** If the work item is thin — missing its Validation Journey, acceptance criteria, or other derivable detail — enrich it: derive the missing detail from the ticket context and the codebase, write it back, and proceed. Do **not** block on a gap you could have filled. Only a blocker that survives that attempt is real, and it is one of two kinds:
 
     - **Actionable blocker** — an unresolved dependency or fixable technical gap that some team or repository could build (a missing or changed schema field, an unbuilt sibling work item, a required upstream fix), **including cross-repo dependencies**. Before writing the blocked verdict you MUST (1) file a build-ready fix/dependency ticket capturing the diagnosis — in the dependency's own repository/tracker when it is cross-repo (e.g. a `[<repo>] …` ticket in the shared project, or the sibling tracker) — and (2) link the current work item to it as `is blocked by`. Only then write the verdict. This is the same discipline as the regression-spec blocker and the remote-verification-fail exits above, and it is what makes the block machine-recoverable: `repair-intake` re-dispatches a blocked item once its linked `is blocked by` dependency closes, but it cannot act on a prose-only comment. Recommending the ticket "as a human follow-up" without filing and linking it is **not** a permitted exit.
-    - **Human-only blocker** — an input the agent genuinely cannot obtain or produce no matter what it does: credentials or secrets it has no access to, or a product/design decision only a human can make. Record the blocked verdict, mark it `human_needed` (the marker `repair-intake` recognizes, so it won't churn re-dispatching it), and surface or reassign to a human; do **not** fabricate a build-ready ticket, because there is no build-ready work.
+    - **Human-only blocker** — an input the agent genuinely cannot obtain or produce no matter what it does: credentials, secrets, or **tool access** it does not have (AWS/CloudWatch, Figma, Jam, Sentry, SonarCloud, a database, a protected deploy target, …), or a product/design decision only a human can make. For missing tool access, follow the `tool-access-gate` rule's break-out protocol: post the "Access Needed" comment naming the exact credential/role/env var to grant and the probe that must pass — never work around the gap by substituting weaker verification, mocking the inaccessible system, or narrowing scope. Record the blocked verdict, mark it `human_needed` (the marker `repair-intake` recognizes, so it won't churn re-dispatching it), and surface or reassign to a human; do **not** fabricate a build-ready ticket, because there is no build-ready work.
 
     Other harnesses fall back to this prose obligation.
 3. Write the highest-practical-observation regression test encoding the verification. For user-visible bugs or user-visible Build changes with an available browser/device/e2e harness, this means a deterministic spec on the reported surface. Prove the new spec actually executed and passed in PR CI by recording a named spec log/reporter line or equivalent execution record; green CI without that named evidence does not satisfy this step.

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

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

package/plugins/lisa-cursor/hooks/enforce-verification-gate.sh

@@ -32,7 +32,7 @@
 #     "plan": "<plan-name>",
 #     "status": "pass" | "fail" | "blocked" | "in_progress",
 #     "criteria": [
-#       { "task": "...", "criterion": "...", "status": "pass" | "fail", "evidence": "..." }
+#       { "task": "...", "criterion": "...", "status": "pass" | "fail" | "blocked", "evidence": "..." }
 #     ],
 #     "updated_at": "<ISO8601 UTC>"
 #   }

package/plugins/lisa-cursor/rules/intent-routing-reference.mdc

@@ -72,8 +72,8 @@ Sequence:
 2. `product-specialist` -- define user goals, user flows (Gherkin), acceptance criteria, error states, UX concerns, and out-of-scope items
 3. **Edge Case Brainstorm sub-flow** -- run the PRD candidate through the edge-case checklist; fold accepted cases into acceptance criteria, out-of-scope, or open questions
 4. `architecture-specialist` -- assess technical feasibility, identify constraints, map existing system boundaries
-5. Synthesize findings into a PRD containing: problem statement, user stories, acceptance criteria, technical constraints, open questions, and proposed scope
-6. **Plan Phase Tooling** -- review all available skills and agents (project-defined, plugin-provided, and built-in) and determine which ones the Plan phase will need. For each recommended skill or agent, state why it is needed. If no skills or agents beyond the defaults are identified, explicitly justify why the standard set is sufficient. Include this as a "Recommended Tooling for Plan Phase" section in the PRD.
+5. Synthesize findings into a PRD containing: problem statement, user stories, acceptance criteria, technical constraints, open questions, and proposed scope. Any technically viable but genuinely unresolved choice discovered during drafting (for example, a library, framework, or architecture decision with more than one live candidate) MUST be captured as an entry under open questions -- never written into any other section, including the "Recommended Tooling for Plan Phase" section in step 6, as though it were already decided. Every open-questions entry MUST include the drafter's own recommended resolution, with a one-sentence rationale, alongside the question; an open question must never be left bare.
+6. **Plan Phase Tooling** -- review all available skills and agents (project-defined, plugin-provided, and built-in) and determine which ones the Plan phase will need. For each recommended skill or agent, state why it is needed. If no skills or agents beyond the defaults are identified, explicitly justify why the standard set is sufficient. Include this as a "Recommended Tooling for Plan Phase" section in the PRD. This section documents settled recommendations for how to run the Plan phase, meaning which skills or agents to use; it MUST NOT be used to record an unresolved product or technical decision, such as "use library X" when X vs. Y was never actually decided. If step 5 surfaced an unresolved technical choice, it belongs in open questions with a recommendation, not here.
 7. **Create the PRD in the configured source** -- invoke `lisa-prd-source-write` with the synthesized PRD (`title`, `body`, `initial_role` resolved from the caller's `prd_ready` flag — `draft` by default, `ready` when `prd_ready=true`, plus any `dedupe_key`/`marker`/`source_ref` the caller passed). The PRD **lives in the source** (Notion page / Confluence page / GitHub issue / Linear project per `.lisa.config.json` `source`); there is no separate document artifact. A `source` must be configured — if it is not, stop and report it. `prd-source-write` dedupes by marker, so re-running against the same idea references the existing PRD instead of creating a duplicate.
 8. **Record Research usage on the PRD artifact** -- invoke `lisa-usage-accounting` against the created PRD/source artifact so it gains a direct `research` usage entry in the canonical `## Lisa Usage` section at creation time. If the runtime cannot provide trustworthy usage, still write the row with `source: unavailable` and nullable token/cost fields; missing usage is never treated as zero or silently omitted.
 9. `learner` -- capture discoveries for future sessions

package/plugins/lisa-cursor/rules/tool-access-gate-reference.mdc

@@ -0,0 +1,126 @@
+---
+description: "Tool Access Gate"
+alwaysApply: false
+---
+
+# Tool Access Gate
+
+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
+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.
+
+"Tool" means any external surface the work depends on, for example:
+
+- Cloud/provider CLIs and APIs: AWS (CloudWatch logs, S3, …), GCP, Azure
+- Design sources: Figma
+- Bug/session capture: Jam
+- Observability: Sentry, PostHog, CloudWatch
+- Quality gates: SonarCloud
+- Trackers and docs: JIRA/Confluence, Linear, Notion, GitHub
+- Device/browser harnesses: Playwright, Maestro, Detox, simulators/emulators
+- Databases, deploy targets, and protected environments
+
+## When the gate runs
+
+1. **Preflight** — after the completion condition is defined and before any
+   implementation task starts, enumerate every tool required by (a) the
+   implementation itself, (b) the proof command / verification plan, and
+   (c) remote verification and post-deploy checks. Sources for the enumeration:
+   the work item (description, comments, attachments — a Figma link or Jam
+   capture implies that tool), acceptance criteria, `testing_requirements`,
+   the `verification` metadata, and the deploy pipeline for the target
+   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
+   preflight wrote to (the plan/tracker artifact and the affected tasks'
+   `metadata.required_access`) before continuing. Discovery timing changes
+   nothing about the protocol.
+
+## Proving access
+
+Access is proven by a **cheap, read-only probe that actually exercises the
+authenticated surface** — tool presence on PATH is not access.
+
+- Vendors with an access layer MUST be probed through their `*-access` skill
+  (see the `integration-access-layer` rule): `lisa-atlassian-access`,
+  `lisa-notion-access`, `lisa-linear-access`, `lisa-jam-access`,
+  `lisa-sonarcloud-access`, `lisa-sentry-access`, `lisa-posthog-access`,
+  `lisa-expo:play-store-access`. A loud access-skill failure naming a missing
+  env var IS a failed probe.
+- Vendors without an access layer are probed with the cheapest authenticated
+  read the runtime offers (an MCP tool call, a CLI read, a REST GET).
+
+Example probes:
+
+| Tool | Probe |
+|---|---|
+| AWS CLI | `aws sts get-caller-identity`, plus the service-level read the task needs (e.g. `aws logs describe-log-groups --max-items 1`) |
+| GitHub | a repository-scoped read against the target repo (e.g. `gh api repos/<owner>/<repo> --jq .full_name`, or the exact read the work item needs) — `gh auth status` alone only proves host auth, not access to the repository |
+| Figma | a read call against the linked file via the available Figma MCP/API surface |
+| Sentry / Jam / SonarCloud / PostHog / Atlassian / Linear / Notion | the matching `*-access` skill's resolve/auth check |
+| Database | the project's documented read-only connection check |
+| 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.
+
+Record the enumeration and probe results 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.
+
+### Forbidden workarounds
+
+None of the following ever substitutes for missing access:
+
+- Swapping the verification for a weaker one the agent *can* run (unit tests or
+  code reading instead of the required log capture / UI observation).
+- Mocking, stubbing, or simulating the inaccessible system to make the proof
+  "pass".
+- Marking work done on artifact-only evidence, or asserting success without the
+  runtime evidence the completion condition demands.
+- Guessing at the tool's contents (e.g. implementing a design without reading
+  the linked Figma file, or "fixing" a bug without the Jam/Sentry evidence the
+  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.

package/plugins/lisa-cursor/rules/tool-access-gate.mdc

@@ -0,0 +1,26 @@
+---
+description: "Tool Access Gate (load-bearing)"
+alwaysApply: true
+---
+
+# Tool Access Gate (load-bearing)
+
+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.
+
+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.
+
+Full contract (probe table, comment format, resume path):
+[reference/tool-access-gate.md](tool-access-gate-reference.mdc).

package/plugins/lisa-cursor/skills/lisa-implement/SKILL.md

@@ -138,9 +138,18 @@ This condition is the contract the Verify flow proves and records in the verific
    1. Direct deploy the changes to dev and then Write a simple API client and call the offending API
    2. Start the server on localhost and then Use the Playwright CLI or Chrome DevTools
 
+Using the general-purpose agent in Team Lead session, run the **tool access preflight** per the `tool-access-gate` rule (loaded via the lisa plugin) before any implementation task is created or started:
+
+1. Enumerate every external tool or system this flow will need — for the implementation itself, for the proof command, and for remote verification (AWS CLI/CloudWatch, Figma, Jam, Sentry, SonarCloud, PostHog, device/browser harnesses, databases, deploy targets, trackers, …). Derive the list from the resolved work item (a linked Figma file, Jam capture, or Sentry issue implies that tool), the acceptance criteria, the testing requirements, and the completion condition above.
+2. Prove access to each with its cheapest read-only probe, routing through the matching `*-access` skill where one exists (`integration-access-layer` rule). Tool presence on PATH is not access; a probe failure counts only after exhausting the documented credential sources (project e2e config/fixtures, `.lisa.config.local.json` / env vars, documented work-item credentials).
+3. Record the enumeration and probe results in the plan artifact and in each task's `metadata.required_access`.
+4. If any required tool fails its probe, do NOT start implementation — follow the break-out protocol in the `tool-access-gate` rule: post an "Access Needed" comment on the work item (plain-English summary, the exact credential/role/env var to grant, the probe that must pass), transition the item to the configured blocked state with the `human_needed` marker, write the verification verdict with `status: "blocked"`, and stop. Working around missing access — substituting weaker verification, mocking the inaccessible system, guessing at tool contents, or narrowing scope — is never permitted, for any tool.
+
+The same gate applies **continuously**: if a tool requirement surfaces mid-flow (e.g. verification turns out to need CloudWatch log capture the runtime cannot authenticate to), probe it the moment it is discovered, record the new tool and probe result in the plan artifact and the affected tasks' `metadata.required_access` before continuing, and break out identically on failure.
+
 Using the general-purpose agent in Team Lead session, create tasks needed to complete the request.
 
-Every task MUST include this JSON metadata block. Do NOT omit `skills` (use `[]` if none), `learnings` (use `[]` if none) or `verification`.
+Every task MUST include this JSON metadata block. Do NOT omit `skills` (use `[]` if none), `learnings` (use `[]` if none), `required_access` (use `[]` if the task needs no external tool) or `verification`.
 
 ```json
 {
@@ -151,6 +160,9 @@ Every task MUST include this JSON metadata block. Do NOT omit `skills` (use `[]`
   "testing_requirements": ["..."],
   "skills": ["..."],
   "learnings": ["..."],
+  "required_access": [
+    { "tool": "<external tool/system this task or its verification needs>", "probe": "<the read-only command or *-access check that proves access>", "status": "pass|fail" }
+  ],
   "verification": {
     "type": "ui-recording|api-test|cli-test|database-check|manual-check|documentation",
     "command": "the proof command — must run the actual system and surface its result in the transcript (NOT test/typecheck/lint, those are quality gates). Phrase it so an independent verifier sees the evidence, e.g. `curl -s localhost:3000/health` not `check that health works`",
@@ -177,7 +189,7 @@ Before shutting down the team, execute the Verify flow:
       "plan": "<plan-name>",
       "status": "pass | fail | blocked | in_progress",
       "criteria": [
-        { "task": "<task id or title>", "criterion": "<the completion condition>", "status": "pass | fail", "evidence": "<the proof command run and the observed result>" }
+        { "task": "<task id or title>", "criterion": "<the completion condition>", "status": "pass | fail | blocked", "evidence": "<the proof command run and the observed result; for a blocked criterion, the blocker diagnosis (e.g. the missing access and the probe that must pass)>" }
       ],
       "updated_at": "<ISO8601 UTC>"
     }
@@ -185,10 +197,10 @@ Before shutting down the team, execute the Verify flow:
 
     Set `status: "pass"` only when every criterion is `pass` with real evidence (output from running the system, not a claim). The verdict must be judged by an agent that did NOT implement the change (the `verification-specialist`), never self-certified by the implementer. This is runtime scratch — it is gitignored and MUST NOT be committed (treat it like the secrets exclusion in the commit step).
 
-    On Claude, the `enforce-verification-gate.sh` Stop hook reads this file and **will not let the flow stop** until it shows a terminal, all-`pass` verdict — carrying over the non-bypassable completion gate of the `/goal` primitive, but checked deterministically against real evidence rather than by a transcript-only evaluator model. If you must stop before completion, write the verdict with `status: "blocked"` and the reason — that records the outcome and releases the gate instead of leaving it to spin. But a `blocked` verdict is a last resort, not a shortcut around fillable work: **first resolve every gap you can resolve yourself.** If the work item is thin — missing its Validation Journey, acceptance criteria, or other derivable detail — enrich it: derive the missing detail from the ticket context and the codebase, write it back, and proceed. Do **not** block on a gap you could have filled. Only a blocker that survives that attempt is real, and it is one of two kinds:
+    On Claude, the `enforce-verification-gate.sh` Stop hook reads this file and **will not let the flow stop** until it shows a terminal, all-`pass` verdict — carrying over the non-bypassable completion gate of the `/goal` primitive, but checked deterministically against real evidence rather than by a transcript-only evaluator model. If you must stop before completion, write the verdict with `status: "blocked"` and the reason — marking each criterion whose proof is blocked as `status: "blocked"` with the blocker diagnosis as its `evidence`, while unaffected criteria keep their real `pass`/`fail` result — that records the outcome and releases the gate instead of leaving it to spin. But a `blocked` verdict is a last resort, not a shortcut around fillable work: **first resolve every gap you can resolve yourself.** If the work item is thin — missing its Validation Journey, acceptance criteria, or other derivable detail — enrich it: derive the missing detail from the ticket context and the codebase, write it back, and proceed. Do **not** block on a gap you could have filled. Only a blocker that survives that attempt is real, and it is one of two kinds:
 
     - **Actionable blocker** — an unresolved dependency or fixable technical gap that some team or repository could build (a missing or changed schema field, an unbuilt sibling work item, a required upstream fix), **including cross-repo dependencies**. Before writing the blocked verdict you MUST (1) file a build-ready fix/dependency ticket capturing the diagnosis — in the dependency's own repository/tracker when it is cross-repo (e.g. a `[<repo>] …` ticket in the shared project, or the sibling tracker) — and (2) link the current work item to it as `is blocked by`. Only then write the verdict. This is the same discipline as the regression-spec blocker and the remote-verification-fail exits above, and it is what makes the block machine-recoverable: `repair-intake` re-dispatches a blocked item once its linked `is blocked by` dependency closes, but it cannot act on a prose-only comment. Recommending the ticket "as a human follow-up" without filing and linking it is **not** a permitted exit.
-    - **Human-only blocker** — an input the agent genuinely cannot obtain or produce no matter what it does: credentials or secrets it has no access to, or a product/design decision only a human can make. Record the blocked verdict, mark it `human_needed` (the marker `repair-intake` recognizes, so it won't churn re-dispatching it), and surface or reassign to a human; do **not** fabricate a build-ready ticket, because there is no build-ready work.
+    - **Human-only blocker** — an input the agent genuinely cannot obtain or produce no matter what it does: credentials, secrets, or **tool access** it does not have (AWS/CloudWatch, Figma, Jam, Sentry, SonarCloud, a database, a protected deploy target, …), or a product/design decision only a human can make. For missing tool access, follow the `tool-access-gate` rule's break-out protocol: post the "Access Needed" comment naming the exact credential/role/env var to grant and the probe that must pass — never work around the gap by substituting weaker verification, mocking the inaccessible system, or narrowing scope. Record the blocked verdict, mark it `human_needed` (the marker `repair-intake` recognizes, so it won't churn re-dispatching it), and surface or reassign to a human; do **not** fabricate a build-ready ticket, because there is no build-ready work.
 
     Other harnesses fall back to this prose obligation.
 3. Write the highest-practical-observation regression test encoding the verification. For user-visible bugs or user-visible Build changes with an available browser/device/e2e harness, this means a deterministic spec on the reported surface. Prove the new spec actually executed and passed in PR CI by recording a named spec log/reporter line or equivalent execution record; green CI without that named evidence does not satisfy this step.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.211.2",
+  "version": "2.212.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.211.2",
+  "version": "2.212.0",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.211.2",
+  "version": "2.212.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.211.2",
+  "version": "2.212.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.211.2",
+  "version": "2.212.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.211.2",
+  "version": "2.212.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.211.2",
+  "version": "2.212.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.211.2",
+  "version": "2.212.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.211.2",
+  "version": "2.212.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.211.2",
+  "version": "2.212.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.211.2",
+  "version": "2.212.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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