@codyswann/lisa 2.325.0 → 2.325.1

package/dist/core/upstream-evidence-manifest.js

@@ -424,8 +424,8 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-debrief-apply/SKILL.md": "90c5f01994bb0f8e71947e8a2f765ccf9a6aa3da47b8d7b8e2022150ef89c2b2",
     "plugins/src/base/skills/lisa-debrief/SKILL.md": "47e4cda36b07994ff47ab15fb04a17dd6b0c310ad804f9cae9d69637edaaa72a",
     "plugins/src/base/skills/lisa-delivery-effectiveness/SKILL.md": "21bc55fa0e86a9694bd22269fd089dbfae0c54c199262f46a4955447acea0f35",
-    "plugins/src/base/skills/lisa-detect-tooling/SKILL.md": "e29b3b8ebc256468bb67e5d10e2ae3cb4eda9ba20dfd2e065201b00864134734",
-    "plugins/src/base/skills/lisa-detect-tooling/scripts/detect-tooling.mjs": "043c3f59d6a7a21a3ab4fce8ae8dc88e8650c19c5a57bba40f567c5257684747",
+    "plugins/src/base/skills/lisa-detect-tooling/SKILL.md": "1778a009d06099b3bd2d9a33b37bec34836b295e21fad220ae926491d3557208",
+    "plugins/src/base/skills/lisa-detect-tooling/scripts/detect-tooling.mjs": "90086ca11dafb5250ee930fa78fd3cc7d4bd601ad57f3e3c1a49920f7d7a1493",
     "plugins/src/base/skills/lisa-doctor/SKILL.md": "fb41a1e63c5332d47a46e715aff52551f3df867033b5e4f37dfaeee30019b891",
     "plugins/src/base/skills/lisa-drive-pr-to-merge/SKILL.md": "c78ae2ba32c830d0b2cd7d24de91adf99e2b3cef4c7cab1c417580d86f41351f",
     "plugins/src/base/skills/lisa-epic-triage/SKILL.md": "d02760411249bddbd396f283191fe3e82bb7b95bf9393a19a7025dc5a57c3ab7",

package/package.json

@@ -115,7 +115,7 @@
     "brace-expansion": ">=5.0.9"
   },
   "name": "@codyswann/lisa",
-  "version": "2.325.0",
+  "version": "2.325.1",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

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

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

package/plugins/lisa/.codex-plugin/skills/lisa-detect-tooling/SKILL.md

@@ -13,7 +13,7 @@ Lisa provisions tooling through four unrelated mechanisms, and only one of them
 | playwright, stryker | npm devDependency from a stack template | nothing — a local `node_modules` binary |
 | maestro | npm **scripts** in the Expo template | **nothing** |
 | sonar | `src/sonar/sonar-installer.ts` | nothing |
-| linear | MCP server | nothing, and it needs browser OAuth |
+| linear | MCP server or `LINEAR_API_KEY` | `lisa-linear-access`, not a CLI |
 | bws, gh | `remoteEnv.tools` — pinned and checksummed | this, and only this |
 
 Nothing populates that last row. So a project can ship scripts that invoke `maestro`, wire an MCP server whose CLI it also shells out to, and configure Playwright thresholds, while the manifest that actually provisions binaries stays empty — and every one of those fails at the moment of use rather than at setup.
@@ -25,7 +25,7 @@ That is the same failure this repository has now paid for twice: `gh` was declar
 Reads four signals, subtracts what `remoteEnv.tools` already declares, and prints what is left with the evidence for each:
 
 - **npm scripts** that invoke a binary. The strongest signal there is — a script running `maestro test` is the project stating a dependency in executable form. Matched on the script *body*, not its name, because the name is a label.
-- **MCP servers with a CLI equivalent.** An MCP server is not a substitute for the binary: several authenticate by browser OAuth, which a container cannot do, so a project relying on one remotely has *no* integration rather than a degraded one.
+- **MCP servers with a CLI equivalent.** An MCP server is not a substitute for the binary: several authenticate by browser OAuth, which a container cannot do, so a project relying on one remotely has *no* integration rather than a degraded one. Do not infer a CLI for access layers that already define their own headless substrate; Linear is handled by `lisa-linear-access` through `LINEAR_API_KEY` + GraphQL when MCP OAuth is unavailable.
 - **Credential usage notes.** A note explaining what a token is for usually names the program that consumes it. `lisa-secrets-access` already exposes these without touching a value, which makes them a first-class input rather than a trick.
 - **Quality configuration**, where a threshold implies the tool that produces it.
 

package/plugins/lisa/.codex-plugin/skills/lisa-detect-tooling/scripts/detect-tooling.mjs

@@ -98,6 +98,20 @@ export function toolsFromScripts(pkg) {
   return found;
 }
 
+/**
+ * MCP servers that are access substrates rather than evidence for a CLI.
+ *
+ * Linear is the important case: Lisa's `lisa-linear-access` skill owns the
+ * headless path through `LINEAR_API_KEY` + GraphQL. There is no official Linear
+ * CLI to pin, and the unrelated `linear` npm package is not a tracker binary.
+ * Treating the MCP server as CLI evidence would push operators toward an
+ * arbitrary third-party executable instead of the access-layer contract.
+ */
+const MCP_ACCESS_LAYER_SUBSTRATES = Object.freeze({
+  "linear-server":
+    "lisa-linear-access uses LINEAR_API_KEY in headless sessions",
+});
+
 /**
  * Tools implied by MCP servers that also have a CLI.
  *
@@ -114,6 +128,14 @@ export function toolsFromMcp(mcp) {
   for (const [tool, meta] of Object.entries(KNOWN_TOOLS)) {
     if (!meta.mcpFallback) continue;
     const server = servers.find(name => name.includes(meta.mcpFallback));
+    if (
+      server &&
+      Object.keys(MCP_ACCESS_LAYER_SUBSTRATES).some(substrate =>
+        server.includes(substrate)
+      )
+    ) {
+      continue;
+    }
     if (server) {
       found.set(
         tool,

package/plugins/lisa/skills/lisa-detect-tooling/SKILL.md

@@ -13,7 +13,7 @@ Lisa provisions tooling through four unrelated mechanisms, and only one of them
 | playwright, stryker | npm devDependency from a stack template | nothing — a local `node_modules` binary |
 | maestro | npm **scripts** in the Expo template | **nothing** |
 | sonar | `src/sonar/sonar-installer.ts` | nothing |
-| linear | MCP server | nothing, and it needs browser OAuth |
+| linear | MCP server or `LINEAR_API_KEY` | `lisa-linear-access`, not a CLI |
 | bws, gh | `remoteEnv.tools` — pinned and checksummed | this, and only this |
 
 Nothing populates that last row. So a project can ship scripts that invoke `maestro`, wire an MCP server whose CLI it also shells out to, and configure Playwright thresholds, while the manifest that actually provisions binaries stays empty — and every one of those fails at the moment of use rather than at setup.
@@ -25,7 +25,7 @@ That is the same failure this repository has now paid for twice: `gh` was declar
 Reads four signals, subtracts what `remoteEnv.tools` already declares, and prints what is left with the evidence for each:
 
 - **npm scripts** that invoke a binary. The strongest signal there is — a script running `maestro test` is the project stating a dependency in executable form. Matched on the script *body*, not its name, because the name is a label.
-- **MCP servers with a CLI equivalent.** An MCP server is not a substitute for the binary: several authenticate by browser OAuth, which a container cannot do, so a project relying on one remotely has *no* integration rather than a degraded one.
+- **MCP servers with a CLI equivalent.** An MCP server is not a substitute for the binary: several authenticate by browser OAuth, which a container cannot do, so a project relying on one remotely has *no* integration rather than a degraded one. Do not infer a CLI for access layers that already define their own headless substrate; Linear is handled by `lisa-linear-access` through `LINEAR_API_KEY` + GraphQL when MCP OAuth is unavailable.
 - **Credential usage notes.** A note explaining what a token is for usually names the program that consumes it. `lisa-secrets-access` already exposes these without touching a value, which makes them a first-class input rather than a trick.
 - **Quality configuration**, where a threshold implies the tool that produces it.
 

package/plugins/lisa/skills/lisa-detect-tooling/scripts/detect-tooling.mjs

@@ -98,6 +98,20 @@ export function toolsFromScripts(pkg) {
   return found;
 }
 
+/**
+ * MCP servers that are access substrates rather than evidence for a CLI.
+ *
+ * Linear is the important case: Lisa's `lisa-linear-access` skill owns the
+ * headless path through `LINEAR_API_KEY` + GraphQL. There is no official Linear
+ * CLI to pin, and the unrelated `linear` npm package is not a tracker binary.
+ * Treating the MCP server as CLI evidence would push operators toward an
+ * arbitrary third-party executable instead of the access-layer contract.
+ */
+const MCP_ACCESS_LAYER_SUBSTRATES = Object.freeze({
+  "linear-server":
+    "lisa-linear-access uses LINEAR_API_KEY in headless sessions",
+});
+
 /**
  * Tools implied by MCP servers that also have a CLI.
  *
@@ -114,6 +128,14 @@ export function toolsFromMcp(mcp) {
   for (const [tool, meta] of Object.entries(KNOWN_TOOLS)) {
     if (!meta.mcpFallback) continue;
     const server = servers.find(name => name.includes(meta.mcpFallback));
+    if (
+      server &&
+      Object.keys(MCP_ACCESS_LAYER_SUBSTRATES).some(substrate =>
+        server.includes(substrate)
+      )
+    ) {
+      continue;
+    }
     if (server) {
       found.set(
         tool,

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-detect-tooling/SKILL.md

@@ -13,7 +13,7 @@ Lisa provisions tooling through four unrelated mechanisms, and only one of them
 | playwright, stryker | npm devDependency from a stack template | nothing — a local `node_modules` binary |
 | maestro | npm **scripts** in the Expo template | **nothing** |
 | sonar | `src/sonar/sonar-installer.ts` | nothing |
-| linear | MCP server | nothing, and it needs browser OAuth |
+| linear | MCP server or `LINEAR_API_KEY` | `lisa-linear-access`, not a CLI |
 | bws, gh | `remoteEnv.tools` — pinned and checksummed | this, and only this |
 
 Nothing populates that last row. So a project can ship scripts that invoke `maestro`, wire an MCP server whose CLI it also shells out to, and configure Playwright thresholds, while the manifest that actually provisions binaries stays empty — and every one of those fails at the moment of use rather than at setup.
@@ -25,7 +25,7 @@ That is the same failure this repository has now paid for twice: `gh` was declar
 Reads four signals, subtracts what `remoteEnv.tools` already declares, and prints what is left with the evidence for each:
 
 - **npm scripts** that invoke a binary. The strongest signal there is — a script running `maestro test` is the project stating a dependency in executable form. Matched on the script *body*, not its name, because the name is a label.
-- **MCP servers with a CLI equivalent.** An MCP server is not a substitute for the binary: several authenticate by browser OAuth, which a container cannot do, so a project relying on one remotely has *no* integration rather than a degraded one.
+- **MCP servers with a CLI equivalent.** An MCP server is not a substitute for the binary: several authenticate by browser OAuth, which a container cannot do, so a project relying on one remotely has *no* integration rather than a degraded one. Do not infer a CLI for access layers that already define their own headless substrate; Linear is handled by `lisa-linear-access` through `LINEAR_API_KEY` + GraphQL when MCP OAuth is unavailable.
 - **Credential usage notes.** A note explaining what a token is for usually names the program that consumes it. `lisa-secrets-access` already exposes these without touching a value, which makes them a first-class input rather than a trick.
 - **Quality configuration**, where a threshold implies the tool that produces it.
 

package/plugins/lisa-agy/skills/lisa-detect-tooling/scripts/detect-tooling.mjs

@@ -98,6 +98,20 @@ export function toolsFromScripts(pkg) {
   return found;
 }
 
+/**
+ * MCP servers that are access substrates rather than evidence for a CLI.
+ *
+ * Linear is the important case: Lisa's `lisa-linear-access` skill owns the
+ * headless path through `LINEAR_API_KEY` + GraphQL. There is no official Linear
+ * CLI to pin, and the unrelated `linear` npm package is not a tracker binary.
+ * Treating the MCP server as CLI evidence would push operators toward an
+ * arbitrary third-party executable instead of the access-layer contract.
+ */
+const MCP_ACCESS_LAYER_SUBSTRATES = Object.freeze({
+  "linear-server":
+    "lisa-linear-access uses LINEAR_API_KEY in headless sessions",
+});
+
 /**
  * Tools implied by MCP servers that also have a CLI.
  *
@@ -114,6 +128,14 @@ export function toolsFromMcp(mcp) {
   for (const [tool, meta] of Object.entries(KNOWN_TOOLS)) {
     if (!meta.mcpFallback) continue;
     const server = servers.find(name => name.includes(meta.mcpFallback));
+    if (
+      server &&
+      Object.keys(MCP_ACCESS_LAYER_SUBSTRATES).some(substrate =>
+        server.includes(substrate)
+      )
+    ) {
+      continue;
+    }
     if (server) {
       found.set(
         tool,

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

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

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

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

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

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

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

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

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

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

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

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

package/plugins/lisa-copilot/skills/lisa-detect-tooling/SKILL.md

@@ -13,7 +13,7 @@ Lisa provisions tooling through four unrelated mechanisms, and only one of them
 | playwright, stryker | npm devDependency from a stack template | nothing — a local `node_modules` binary |
 | maestro | npm **scripts** in the Expo template | **nothing** |
 | sonar | `src/sonar/sonar-installer.ts` | nothing |
-| linear | MCP server | nothing, and it needs browser OAuth |
+| linear | MCP server or `LINEAR_API_KEY` | `lisa-linear-access`, not a CLI |
 | bws, gh | `remoteEnv.tools` — pinned and checksummed | this, and only this |
 
 Nothing populates that last row. So a project can ship scripts that invoke `maestro`, wire an MCP server whose CLI it also shells out to, and configure Playwright thresholds, while the manifest that actually provisions binaries stays empty — and every one of those fails at the moment of use rather than at setup.
@@ -25,7 +25,7 @@ That is the same failure this repository has now paid for twice: `gh` was declar
 Reads four signals, subtracts what `remoteEnv.tools` already declares, and prints what is left with the evidence for each:
 
 - **npm scripts** that invoke a binary. The strongest signal there is — a script running `maestro test` is the project stating a dependency in executable form. Matched on the script *body*, not its name, because the name is a label.
-- **MCP servers with a CLI equivalent.** An MCP server is not a substitute for the binary: several authenticate by browser OAuth, which a container cannot do, so a project relying on one remotely has *no* integration rather than a degraded one.
+- **MCP servers with a CLI equivalent.** An MCP server is not a substitute for the binary: several authenticate by browser OAuth, which a container cannot do, so a project relying on one remotely has *no* integration rather than a degraded one. Do not infer a CLI for access layers that already define their own headless substrate; Linear is handled by `lisa-linear-access` through `LINEAR_API_KEY` + GraphQL when MCP OAuth is unavailable.
 - **Credential usage notes.** A note explaining what a token is for usually names the program that consumes it. `lisa-secrets-access` already exposes these without touching a value, which makes them a first-class input rather than a trick.
 - **Quality configuration**, where a threshold implies the tool that produces it.
 

package/plugins/lisa-copilot/skills/lisa-detect-tooling/scripts/detect-tooling.mjs

@@ -98,6 +98,20 @@ export function toolsFromScripts(pkg) {
   return found;
 }
 
+/**
+ * MCP servers that are access substrates rather than evidence for a CLI.
+ *
+ * Linear is the important case: Lisa's `lisa-linear-access` skill owns the
+ * headless path through `LINEAR_API_KEY` + GraphQL. There is no official Linear
+ * CLI to pin, and the unrelated `linear` npm package is not a tracker binary.
+ * Treating the MCP server as CLI evidence would push operators toward an
+ * arbitrary third-party executable instead of the access-layer contract.
+ */
+const MCP_ACCESS_LAYER_SUBSTRATES = Object.freeze({
+  "linear-server":
+    "lisa-linear-access uses LINEAR_API_KEY in headless sessions",
+});
+
 /**
  * Tools implied by MCP servers that also have a CLI.
  *
@@ -114,6 +128,14 @@ export function toolsFromMcp(mcp) {
   for (const [tool, meta] of Object.entries(KNOWN_TOOLS)) {
     if (!meta.mcpFallback) continue;
     const server = servers.find(name => name.includes(meta.mcpFallback));
+    if (
+      server &&
+      Object.keys(MCP_ACCESS_LAYER_SUBSTRATES).some(substrate =>
+        server.includes(substrate)
+      )
+    ) {
+      continue;
+    }
     if (server) {
       found.set(
         tool,

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

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

package/plugins/lisa-cursor/skills/lisa-detect-tooling/SKILL.md

@@ -13,7 +13,7 @@ Lisa provisions tooling through four unrelated mechanisms, and only one of them
 | playwright, stryker | npm devDependency from a stack template | nothing — a local `node_modules` binary |
 | maestro | npm **scripts** in the Expo template | **nothing** |
 | sonar | `src/sonar/sonar-installer.ts` | nothing |
-| linear | MCP server | nothing, and it needs browser OAuth |
+| linear | MCP server or `LINEAR_API_KEY` | `lisa-linear-access`, not a CLI |
 | bws, gh | `remoteEnv.tools` — pinned and checksummed | this, and only this |
 
 Nothing populates that last row. So a project can ship scripts that invoke `maestro`, wire an MCP server whose CLI it also shells out to, and configure Playwright thresholds, while the manifest that actually provisions binaries stays empty — and every one of those fails at the moment of use rather than at setup.
@@ -25,7 +25,7 @@ That is the same failure this repository has now paid for twice: `gh` was declar
 Reads four signals, subtracts what `remoteEnv.tools` already declares, and prints what is left with the evidence for each:
 
 - **npm scripts** that invoke a binary. The strongest signal there is — a script running `maestro test` is the project stating a dependency in executable form. Matched on the script *body*, not its name, because the name is a label.
-- **MCP servers with a CLI equivalent.** An MCP server is not a substitute for the binary: several authenticate by browser OAuth, which a container cannot do, so a project relying on one remotely has *no* integration rather than a degraded one.
+- **MCP servers with a CLI equivalent.** An MCP server is not a substitute for the binary: several authenticate by browser OAuth, which a container cannot do, so a project relying on one remotely has *no* integration rather than a degraded one. Do not infer a CLI for access layers that already define their own headless substrate; Linear is handled by `lisa-linear-access` through `LINEAR_API_KEY` + GraphQL when MCP OAuth is unavailable.
 - **Credential usage notes.** A note explaining what a token is for usually names the program that consumes it. `lisa-secrets-access` already exposes these without touching a value, which makes them a first-class input rather than a trick.
 - **Quality configuration**, where a threshold implies the tool that produces it.
 

package/plugins/lisa-cursor/skills/lisa-detect-tooling/scripts/detect-tooling.mjs

@@ -98,6 +98,20 @@ export function toolsFromScripts(pkg) {
   return found;
 }
 
+/**
+ * MCP servers that are access substrates rather than evidence for a CLI.
+ *
+ * Linear is the important case: Lisa's `lisa-linear-access` skill owns the
+ * headless path through `LINEAR_API_KEY` + GraphQL. There is no official Linear
+ * CLI to pin, and the unrelated `linear` npm package is not a tracker binary.
+ * Treating the MCP server as CLI evidence would push operators toward an
+ * arbitrary third-party executable instead of the access-layer contract.
+ */
+const MCP_ACCESS_LAYER_SUBSTRATES = Object.freeze({
+  "linear-server":
+    "lisa-linear-access uses LINEAR_API_KEY in headless sessions",
+});
+
 /**
  * Tools implied by MCP servers that also have a CLI.
  *
@@ -114,6 +128,14 @@ export function toolsFromMcp(mcp) {
   for (const [tool, meta] of Object.entries(KNOWN_TOOLS)) {
     if (!meta.mcpFallback) continue;
     const server = servers.find(name => name.includes(meta.mcpFallback));
+    if (
+      server &&
+      Object.keys(MCP_ACCESS_LAYER_SUBSTRATES).some(substrate =>
+        server.includes(substrate)
+      )
+    ) {
+      continue;
+    }
     if (server) {
       found.set(
         tool,

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "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.325.0",
+  "version": "2.325.1",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

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

package/plugins/src/base/skills/lisa-detect-tooling/SKILL.md

@@ -13,7 +13,7 @@ Lisa provisions tooling through four unrelated mechanisms, and only one of them
 | playwright, stryker | npm devDependency from a stack template | nothing — a local `node_modules` binary |
 | maestro | npm **scripts** in the Expo template | **nothing** |
 | sonar | `src/sonar/sonar-installer.ts` | nothing |
-| linear | MCP server | nothing, and it needs browser OAuth |
+| linear | MCP server or `LINEAR_API_KEY` | `lisa-linear-access`, not a CLI |
 | bws, gh | `remoteEnv.tools` — pinned and checksummed | this, and only this |
 
 Nothing populates that last row. So a project can ship scripts that invoke `maestro`, wire an MCP server whose CLI it also shells out to, and configure Playwright thresholds, while the manifest that actually provisions binaries stays empty — and every one of those fails at the moment of use rather than at setup.
@@ -25,7 +25,7 @@ That is the same failure this repository has now paid for twice: `gh` was declar
 Reads four signals, subtracts what `remoteEnv.tools` already declares, and prints what is left with the evidence for each:
 
 - **npm scripts** that invoke a binary. The strongest signal there is — a script running `maestro test` is the project stating a dependency in executable form. Matched on the script *body*, not its name, because the name is a label.
-- **MCP servers with a CLI equivalent.** An MCP server is not a substitute for the binary: several authenticate by browser OAuth, which a container cannot do, so a project relying on one remotely has *no* integration rather than a degraded one.
+- **MCP servers with a CLI equivalent.** An MCP server is not a substitute for the binary: several authenticate by browser OAuth, which a container cannot do, so a project relying on one remotely has *no* integration rather than a degraded one. Do not infer a CLI for access layers that already define their own headless substrate; Linear is handled by `lisa-linear-access` through `LINEAR_API_KEY` + GraphQL when MCP OAuth is unavailable.
 - **Credential usage notes.** A note explaining what a token is for usually names the program that consumes it. `lisa-secrets-access` already exposes these without touching a value, which makes them a first-class input rather than a trick.
 - **Quality configuration**, where a threshold implies the tool that produces it.
 

package/plugins/src/base/skills/lisa-detect-tooling/scripts/detect-tooling.mjs

@@ -98,6 +98,20 @@ export function toolsFromScripts(pkg) {
   return found;
 }
 
+/**
+ * MCP servers that are access substrates rather than evidence for a CLI.
+ *
+ * Linear is the important case: Lisa's `lisa-linear-access` skill owns the
+ * headless path through `LINEAR_API_KEY` + GraphQL. There is no official Linear
+ * CLI to pin, and the unrelated `linear` npm package is not a tracker binary.
+ * Treating the MCP server as CLI evidence would push operators toward an
+ * arbitrary third-party executable instead of the access-layer contract.
+ */
+const MCP_ACCESS_LAYER_SUBSTRATES = Object.freeze({
+  "linear-server":
+    "lisa-linear-access uses LINEAR_API_KEY in headless sessions",
+});
+
 /**
  * Tools implied by MCP servers that also have a CLI.
  *
@@ -114,6 +128,14 @@ export function toolsFromMcp(mcp) {
   for (const [tool, meta] of Object.entries(KNOWN_TOOLS)) {
     if (!meta.mcpFallback) continue;
     const server = servers.find(name => name.includes(meta.mcpFallback));
+    if (
+      server &&
+      Object.keys(MCP_ACCESS_LAYER_SUBSTRATES).some(substrate =>
+        server.includes(substrate)
+      )
+    ) {
+      continue;
+    }
     if (server) {
       found.set(
         tool,