@codyswann/lisa 2.317.2 → 2.317.3

package/package.json

@@ -115,7 +115,7 @@
     "brace-expansion": ">=5.0.8"
   },
   "name": "@codyswann/lisa",
-  "version": "2.317.2",
+  "version": "2.317.3",
   "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.317.2",
+  "version": "2.317.3",
   "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.317.2",
+  "version": "2.317.3",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

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

@@ -82,6 +82,18 @@ ${XDG_CONFIG_HOME:-$HOME/.config}/<secrets.namespace>/     # dir 0700
 
 **`bootstrap`** — how to obtain the one credential that unlocks the rest. `sources` is ordered, environment first. This is the **only** credential permitted in a keychain; it is a bootstrap, not a cache.
 
+`bootstrap.key` answers exactly one question: **where do we find it** — the environment variable name and keychain service to look under. It is *not* the name the provider CLI reads. That name is fixed by the vendor (`bws` reads `BWS_ACCESS_TOKEN` and nothing else) and lives in `PROVIDER_BOOTSTRAP_ENV` in `providers.mjs`, which translates one into the other before invoking the CLI.
+
+Keeping these separate is what makes **one workstation serve several tenants**. Give each its own name and each project points at its own:
+
+```json
+"bootstrap": { "sources": ["env", "keychain"], "key": "BWS_ACCESS_TOKEN_acme" }
+```
+
+Conflating them worked only while every project used the default, where the two coincide. The first project to slug its key handed the CLI a variable it had never heard of, and every read and rotation failed with `Missing access token`. If you add a provider, add its canonical variable to that table — do not reach for `bootstrap.key`.
+
+On the GitHub Actions surface the repository secret and the exported environment variable both carry the **configured** name, and the generated workflow templates it. Translating to the CLI's own variable stays in `providers.mjs`.
+
 **`require`** — optional. Omit it and every secret the provider grants is available, which is correct when the provider already scopes access per project. Present, it narrows to exactly those names **and asserts them**: a listed name that does not resolve is a startup error, not a late surprise.
 
 **`narrow`** — may only *narrow* the provider's own grant. There is deliberately no way to widen access from config; that boundary belongs to the provider.

package/plugins/lisa/.codex-plugin/skills/lisa-secrets-access/scripts/providers.mjs

@@ -28,6 +28,56 @@ export const ENV_KEY = /^[A-Za-z_][A-Za-z0-9_]*$/;
  */
 export const LEASE_KEY = "LISA_ROTATION_LEASES";
 
+/**
+ * The environment variable each provider's CLI reads its own bootstrap from.
+ *
+ * This is deliberately *not* configurable, and separating it from
+ * `bootstrap.key` is the whole point. Two different questions were previously
+ * answered by one value:
+ *
+ * - **Where do we find the bootstrap?** A keychain service or environment
+ *   variable name. That must be configurable, because one workstation serves
+ *   several tenants and each needs its own token stored under its own name.
+ * - **What does the provider CLI call it?** Fixed by the vendor. `bws` reads
+ *   `BWS_ACCESS_TOKEN` and nothing else.
+ *
+ * Conflating them worked only while every project used the default name, where
+ * the two happen to coincide. The moment a project set
+ * `bootstrap.key: "BWS_ACCESS_TOKEN_<tenant>"` the CLI was handed a variable it
+ * has never heard of and failed with "Missing access token".
+ */
+const PROVIDER_BOOTSTRAP_ENV = {
+  bitwarden: "BWS_ACCESS_TOKEN",
+  doppler: "DOPPLER_TOKEN",
+};
+
+/**
+ * Build the child environment for a provider CLI, injecting the bootstrap under
+ * the name that CLI actually reads.
+ *
+ * Both the read path and the rotation write path need this, and they previously
+ * carried separate copies of the same line — which is how they would eventually
+ * have drifted. One helper, one place to be wrong.
+ * @param {object} cfg Resolved configuration.
+ * @returns {NodeJS.ProcessEnv} Environment for the child process.
+ */
+export function providerEnv(cfg) {
+  const env = { ...process.env };
+  const canonical = PROVIDER_BOOTSTRAP_ENV[cfg.provider];
+  if (!canonical) return env;
+  const token = bootstrapToken(cfg.bootstrap);
+  if (token) env[canonical] = token;
+  // Drop the tenant-scoped name once its value has been placed under the one
+  // the CLI reads. Inheriting it would leave two variables holding the same
+  // bootstrap in the child, which is how a tool that probes for a
+  // similarly-named credential binds to the wrong tenant on a workstation
+  // serving several. The child needs exactly one.
+  if (cfg.bootstrap.key && cfg.bootstrap.key !== canonical) {
+    delete env[cfg.bootstrap.key];
+  }
+  return env;
+}
+
 /**
  * Obtain the one credential that unlocks the provider.
  *
@@ -83,9 +133,7 @@ function fromKeychain(key) {
  * @returns {Array<{key: string, value: string, note: string, projectId: string|null}>} Rows.
  */
 export function fetchRaw(cfg) {
-  const env = { ...process.env };
-  const token = bootstrapToken(cfg.bootstrap);
-  if (cfg.bootstrap.key && token) env[cfg.bootstrap.key] = token;
+  const env = providerEnv(cfg);
 
   if (cfg.provider === "env") {
     return Object.entries(process.env)
@@ -225,9 +273,7 @@ export function rawByKey(cfg, key) {
  * @param {string} value Replacement value.
  */
 export function writeSecret(cfg, id, value) {
-  const env = { ...process.env };
-  const token = bootstrapToken(cfg.bootstrap);
-  if (cfg.bootstrap.key && token) env[cfg.bootstrap.key] = token;
+  const env = providerEnv(cfg);
 
   if (cfg.provider === "bitwarden") {
     run("bws", ["secret", "edit", id, "--value", value], env);

package/plugins/lisa/.codex-plugin/skills/lisa-setup-automations/scripts/generate-workflow.mjs

@@ -44,6 +44,10 @@ export function readAutomation(name, cwd = process.cwd()) {
   return {
     ...loop,
     repository: cfg.remoteEnv?.surfaces?.[loop.executionEnv]?.repository,
+    // Where this project keeps its bootstrap. A workstation serving several
+    // tenants gives each its own name, so the generated workflow must template
+    // it rather than assume the default.
+    bootstrapKey: cfg.secrets?.bootstrap?.key ?? "BWS_ACCESS_TOKEN",
   };
 }
 
@@ -70,6 +74,11 @@ export function readAutomation(name, cwd = process.cwd()) {
  */
 export function renderWorkflow(name, loop) {
   if (!loop.schedule) throw new Error(`automations["${name}"] has no schedule`);
+  // The repository secret and the environment variable carry the same name, so
+  // the value the workflow exports is the one `bootstrap.key` tells the resolver
+  // to look for. Translating it to the provider CLI's own variable is
+  // providers.mjs's job, not this workflow's.
+  const bootstrap = loop.bootstrapKey ?? "BWS_ACCESS_TOKEN";
   if (!loop.repository) {
     throw new Error(
       `automations["${name}"] targets executionEnv "${loop.executionEnv}", ` +
@@ -118,22 +127,22 @@ jobs:
       # seconds rather than after a toolchain download.
       - name: Check the bootstrap credential is configured
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
-          test -n "\${BWS_ACCESS_TOKEN}" || {
-            echo "BWS_ACCESS_TOKEN is not configured for this repository" >&2
+          test -n "\${${bootstrap}}" || {
+            echo "${bootstrap} is not configured for this repository" >&2
             exit 1
           }
 
       - name: Prepare the toolchain and secrets
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: bash scripts/lisa-remote-env/setup.sh
 
       - name: Run one ${name} cycle
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
           node .claude/skills/lisa-remote-dispatch/scripts/dispatch.mjs \\
@@ -145,7 +154,7 @@ jobs:
       - name: Persist any credential rotation
         if: \${{ always() }}
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
           node .claude/skills/lisa-secrets-access/scripts/rotate-secret.mjs leases

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

@@ -82,6 +82,18 @@ ${XDG_CONFIG_HOME:-$HOME/.config}/<secrets.namespace>/     # dir 0700
 
 **`bootstrap`** — how to obtain the one credential that unlocks the rest. `sources` is ordered, environment first. This is the **only** credential permitted in a keychain; it is a bootstrap, not a cache.
 
+`bootstrap.key` answers exactly one question: **where do we find it** — the environment variable name and keychain service to look under. It is *not* the name the provider CLI reads. That name is fixed by the vendor (`bws` reads `BWS_ACCESS_TOKEN` and nothing else) and lives in `PROVIDER_BOOTSTRAP_ENV` in `providers.mjs`, which translates one into the other before invoking the CLI.
+
+Keeping these separate is what makes **one workstation serve several tenants**. Give each its own name and each project points at its own:
+
+```json
+"bootstrap": { "sources": ["env", "keychain"], "key": "BWS_ACCESS_TOKEN_acme" }
+```
+
+Conflating them worked only while every project used the default, where the two coincide. The first project to slug its key handed the CLI a variable it had never heard of, and every read and rotation failed with `Missing access token`. If you add a provider, add its canonical variable to that table — do not reach for `bootstrap.key`.
+
+On the GitHub Actions surface the repository secret and the exported environment variable both carry the **configured** name, and the generated workflow templates it. Translating to the CLI's own variable stays in `providers.mjs`.
+
 **`require`** — optional. Omit it and every secret the provider grants is available, which is correct when the provider already scopes access per project. Present, it narrows to exactly those names **and asserts them**: a listed name that does not resolve is a startup error, not a late surprise.
 
 **`narrow`** — may only *narrow* the provider's own grant. There is deliberately no way to widen access from config; that boundary belongs to the provider.

package/plugins/lisa/skills/lisa-secrets-access/scripts/providers.mjs

@@ -28,6 +28,56 @@ export const ENV_KEY = /^[A-Za-z_][A-Za-z0-9_]*$/;
  */
 export const LEASE_KEY = "LISA_ROTATION_LEASES";
 
+/**
+ * The environment variable each provider's CLI reads its own bootstrap from.
+ *
+ * This is deliberately *not* configurable, and separating it from
+ * `bootstrap.key` is the whole point. Two different questions were previously
+ * answered by one value:
+ *
+ * - **Where do we find the bootstrap?** A keychain service or environment
+ *   variable name. That must be configurable, because one workstation serves
+ *   several tenants and each needs its own token stored under its own name.
+ * - **What does the provider CLI call it?** Fixed by the vendor. `bws` reads
+ *   `BWS_ACCESS_TOKEN` and nothing else.
+ *
+ * Conflating them worked only while every project used the default name, where
+ * the two happen to coincide. The moment a project set
+ * `bootstrap.key: "BWS_ACCESS_TOKEN_<tenant>"` the CLI was handed a variable it
+ * has never heard of and failed with "Missing access token".
+ */
+const PROVIDER_BOOTSTRAP_ENV = {
+  bitwarden: "BWS_ACCESS_TOKEN",
+  doppler: "DOPPLER_TOKEN",
+};
+
+/**
+ * Build the child environment for a provider CLI, injecting the bootstrap under
+ * the name that CLI actually reads.
+ *
+ * Both the read path and the rotation write path need this, and they previously
+ * carried separate copies of the same line — which is how they would eventually
+ * have drifted. One helper, one place to be wrong.
+ * @param {object} cfg Resolved configuration.
+ * @returns {NodeJS.ProcessEnv} Environment for the child process.
+ */
+export function providerEnv(cfg) {
+  const env = { ...process.env };
+  const canonical = PROVIDER_BOOTSTRAP_ENV[cfg.provider];
+  if (!canonical) return env;
+  const token = bootstrapToken(cfg.bootstrap);
+  if (token) env[canonical] = token;
+  // Drop the tenant-scoped name once its value has been placed under the one
+  // the CLI reads. Inheriting it would leave two variables holding the same
+  // bootstrap in the child, which is how a tool that probes for a
+  // similarly-named credential binds to the wrong tenant on a workstation
+  // serving several. The child needs exactly one.
+  if (cfg.bootstrap.key && cfg.bootstrap.key !== canonical) {
+    delete env[cfg.bootstrap.key];
+  }
+  return env;
+}
+
 /**
  * Obtain the one credential that unlocks the provider.
  *
@@ -83,9 +133,7 @@ function fromKeychain(key) {
  * @returns {Array<{key: string, value: string, note: string, projectId: string|null}>} Rows.
  */
 export function fetchRaw(cfg) {
-  const env = { ...process.env };
-  const token = bootstrapToken(cfg.bootstrap);
-  if (cfg.bootstrap.key && token) env[cfg.bootstrap.key] = token;
+  const env = providerEnv(cfg);
 
   if (cfg.provider === "env") {
     return Object.entries(process.env)
@@ -225,9 +273,7 @@ export function rawByKey(cfg, key) {
  * @param {string} value Replacement value.
  */
 export function writeSecret(cfg, id, value) {
-  const env = { ...process.env };
-  const token = bootstrapToken(cfg.bootstrap);
-  if (cfg.bootstrap.key && token) env[cfg.bootstrap.key] = token;
+  const env = providerEnv(cfg);
 
   if (cfg.provider === "bitwarden") {
     run("bws", ["secret", "edit", id, "--value", value], env);

package/plugins/lisa/skills/lisa-setup-automations/scripts/generate-workflow.mjs

@@ -44,6 +44,10 @@ export function readAutomation(name, cwd = process.cwd()) {
   return {
     ...loop,
     repository: cfg.remoteEnv?.surfaces?.[loop.executionEnv]?.repository,
+    // Where this project keeps its bootstrap. A workstation serving several
+    // tenants gives each its own name, so the generated workflow must template
+    // it rather than assume the default.
+    bootstrapKey: cfg.secrets?.bootstrap?.key ?? "BWS_ACCESS_TOKEN",
   };
 }
 
@@ -70,6 +74,11 @@ export function readAutomation(name, cwd = process.cwd()) {
  */
 export function renderWorkflow(name, loop) {
   if (!loop.schedule) throw new Error(`automations["${name}"] has no schedule`);
+  // The repository secret and the environment variable carry the same name, so
+  // the value the workflow exports is the one `bootstrap.key` tells the resolver
+  // to look for. Translating it to the provider CLI's own variable is
+  // providers.mjs's job, not this workflow's.
+  const bootstrap = loop.bootstrapKey ?? "BWS_ACCESS_TOKEN";
   if (!loop.repository) {
     throw new Error(
       `automations["${name}"] targets executionEnv "${loop.executionEnv}", ` +
@@ -118,22 +127,22 @@ jobs:
       # seconds rather than after a toolchain download.
       - name: Check the bootstrap credential is configured
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
-          test -n "\${BWS_ACCESS_TOKEN}" || {
-            echo "BWS_ACCESS_TOKEN is not configured for this repository" >&2
+          test -n "\${${bootstrap}}" || {
+            echo "${bootstrap} is not configured for this repository" >&2
             exit 1
           }
 
       - name: Prepare the toolchain and secrets
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: bash scripts/lisa-remote-env/setup.sh
 
       - name: Run one ${name} cycle
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
           node .claude/skills/lisa-remote-dispatch/scripts/dispatch.mjs \\
@@ -145,7 +154,7 @@ jobs:
       - name: Persist any credential rotation
         if: \${{ always() }}
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
           node .claude/skills/lisa-secrets-access/scripts/rotate-secret.mjs leases

package/plugins/lisa-agy/plugin.json

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

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

@@ -82,6 +82,18 @@ ${XDG_CONFIG_HOME:-$HOME/.config}/<secrets.namespace>/     # dir 0700
 
 **`bootstrap`** — how to obtain the one credential that unlocks the rest. `sources` is ordered, environment first. This is the **only** credential permitted in a keychain; it is a bootstrap, not a cache.
 
+`bootstrap.key` answers exactly one question: **where do we find it** — the environment variable name and keychain service to look under. It is *not* the name the provider CLI reads. That name is fixed by the vendor (`bws` reads `BWS_ACCESS_TOKEN` and nothing else) and lives in `PROVIDER_BOOTSTRAP_ENV` in `providers.mjs`, which translates one into the other before invoking the CLI.
+
+Keeping these separate is what makes **one workstation serve several tenants**. Give each its own name and each project points at its own:
+
+```json
+"bootstrap": { "sources": ["env", "keychain"], "key": "BWS_ACCESS_TOKEN_acme" }
+```
+
+Conflating them worked only while every project used the default, where the two coincide. The first project to slug its key handed the CLI a variable it had never heard of, and every read and rotation failed with `Missing access token`. If you add a provider, add its canonical variable to that table — do not reach for `bootstrap.key`.
+
+On the GitHub Actions surface the repository secret and the exported environment variable both carry the **configured** name, and the generated workflow templates it. Translating to the CLI's own variable stays in `providers.mjs`.
+
 **`require`** — optional. Omit it and every secret the provider grants is available, which is correct when the provider already scopes access per project. Present, it narrows to exactly those names **and asserts them**: a listed name that does not resolve is a startup error, not a late surprise.
 
 **`narrow`** — may only *narrow* the provider's own grant. There is deliberately no way to widen access from config; that boundary belongs to the provider.

package/plugins/lisa-agy/skills/lisa-secrets-access/scripts/providers.mjs

@@ -28,6 +28,56 @@ export const ENV_KEY = /^[A-Za-z_][A-Za-z0-9_]*$/;
  */
 export const LEASE_KEY = "LISA_ROTATION_LEASES";
 
+/**
+ * The environment variable each provider's CLI reads its own bootstrap from.
+ *
+ * This is deliberately *not* configurable, and separating it from
+ * `bootstrap.key` is the whole point. Two different questions were previously
+ * answered by one value:
+ *
+ * - **Where do we find the bootstrap?** A keychain service or environment
+ *   variable name. That must be configurable, because one workstation serves
+ *   several tenants and each needs its own token stored under its own name.
+ * - **What does the provider CLI call it?** Fixed by the vendor. `bws` reads
+ *   `BWS_ACCESS_TOKEN` and nothing else.
+ *
+ * Conflating them worked only while every project used the default name, where
+ * the two happen to coincide. The moment a project set
+ * `bootstrap.key: "BWS_ACCESS_TOKEN_<tenant>"` the CLI was handed a variable it
+ * has never heard of and failed with "Missing access token".
+ */
+const PROVIDER_BOOTSTRAP_ENV = {
+  bitwarden: "BWS_ACCESS_TOKEN",
+  doppler: "DOPPLER_TOKEN",
+};
+
+/**
+ * Build the child environment for a provider CLI, injecting the bootstrap under
+ * the name that CLI actually reads.
+ *
+ * Both the read path and the rotation write path need this, and they previously
+ * carried separate copies of the same line — which is how they would eventually
+ * have drifted. One helper, one place to be wrong.
+ * @param {object} cfg Resolved configuration.
+ * @returns {NodeJS.ProcessEnv} Environment for the child process.
+ */
+export function providerEnv(cfg) {
+  const env = { ...process.env };
+  const canonical = PROVIDER_BOOTSTRAP_ENV[cfg.provider];
+  if (!canonical) return env;
+  const token = bootstrapToken(cfg.bootstrap);
+  if (token) env[canonical] = token;
+  // Drop the tenant-scoped name once its value has been placed under the one
+  // the CLI reads. Inheriting it would leave two variables holding the same
+  // bootstrap in the child, which is how a tool that probes for a
+  // similarly-named credential binds to the wrong tenant on a workstation
+  // serving several. The child needs exactly one.
+  if (cfg.bootstrap.key && cfg.bootstrap.key !== canonical) {
+    delete env[cfg.bootstrap.key];
+  }
+  return env;
+}
+
 /**
  * Obtain the one credential that unlocks the provider.
  *
@@ -83,9 +133,7 @@ function fromKeychain(key) {
  * @returns {Array<{key: string, value: string, note: string, projectId: string|null}>} Rows.
  */
 export function fetchRaw(cfg) {
-  const env = { ...process.env };
-  const token = bootstrapToken(cfg.bootstrap);
-  if (cfg.bootstrap.key && token) env[cfg.bootstrap.key] = token;
+  const env = providerEnv(cfg);
 
   if (cfg.provider === "env") {
     return Object.entries(process.env)
@@ -225,9 +273,7 @@ export function rawByKey(cfg, key) {
  * @param {string} value Replacement value.
  */
 export function writeSecret(cfg, id, value) {
-  const env = { ...process.env };
-  const token = bootstrapToken(cfg.bootstrap);
-  if (cfg.bootstrap.key && token) env[cfg.bootstrap.key] = token;
+  const env = providerEnv(cfg);
 
   if (cfg.provider === "bitwarden") {
     run("bws", ["secret", "edit", id, "--value", value], env);

package/plugins/lisa-agy/skills/lisa-setup-automations/scripts/generate-workflow.mjs

@@ -44,6 +44,10 @@ export function readAutomation(name, cwd = process.cwd()) {
   return {
     ...loop,
     repository: cfg.remoteEnv?.surfaces?.[loop.executionEnv]?.repository,
+    // Where this project keeps its bootstrap. A workstation serving several
+    // tenants gives each its own name, so the generated workflow must template
+    // it rather than assume the default.
+    bootstrapKey: cfg.secrets?.bootstrap?.key ?? "BWS_ACCESS_TOKEN",
   };
 }
 
@@ -70,6 +74,11 @@ export function readAutomation(name, cwd = process.cwd()) {
  */
 export function renderWorkflow(name, loop) {
   if (!loop.schedule) throw new Error(`automations["${name}"] has no schedule`);
+  // The repository secret and the environment variable carry the same name, so
+  // the value the workflow exports is the one `bootstrap.key` tells the resolver
+  // to look for. Translating it to the provider CLI's own variable is
+  // providers.mjs's job, not this workflow's.
+  const bootstrap = loop.bootstrapKey ?? "BWS_ACCESS_TOKEN";
   if (!loop.repository) {
     throw new Error(
       `automations["${name}"] targets executionEnv "${loop.executionEnv}", ` +
@@ -118,22 +127,22 @@ jobs:
       # seconds rather than after a toolchain download.
       - name: Check the bootstrap credential is configured
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
-          test -n "\${BWS_ACCESS_TOKEN}" || {
-            echo "BWS_ACCESS_TOKEN is not configured for this repository" >&2
+          test -n "\${${bootstrap}}" || {
+            echo "${bootstrap} is not configured for this repository" >&2
             exit 1
           }
 
       - name: Prepare the toolchain and secrets
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: bash scripts/lisa-remote-env/setup.sh
 
       - name: Run one ${name} cycle
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
           node .claude/skills/lisa-remote-dispatch/scripts/dispatch.mjs \\
@@ -145,7 +154,7 @@ jobs:
       - name: Persist any credential rotation
         if: \${{ always() }}
         env:
-          BWS_ACCESS_TOKEN: \${{ secrets.BWS_ACCESS_TOKEN }}
+          ${bootstrap}: \${{ secrets.${bootstrap} }}
         run: |
           set -euo pipefail
           node .claude/skills/lisa-secrets-access/scripts/rotate-secret.mjs leases

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

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

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

@@ -82,6 +82,18 @@ ${XDG_CONFIG_HOME:-$HOME/.config}/<secrets.namespace>/     # dir 0700
 
 **`bootstrap`** — how to obtain the one credential that unlocks the rest. `sources` is ordered, environment first. This is the **only** credential permitted in a keychain; it is a bootstrap, not a cache.
 
+`bootstrap.key` answers exactly one question: **where do we find it** — the environment variable name and keychain service to look under. It is *not* the name the provider CLI reads. That name is fixed by the vendor (`bws` reads `BWS_ACCESS_TOKEN` and nothing else) and lives in `PROVIDER_BOOTSTRAP_ENV` in `providers.mjs`, which translates one into the other before invoking the CLI.
+
+Keeping these separate is what makes **one workstation serve several tenants**. Give each its own name and each project points at its own:
+
+```json
+"bootstrap": { "sources": ["env", "keychain"], "key": "BWS_ACCESS_TOKEN_acme" }
+```
+
+Conflating them worked only while every project used the default, where the two coincide. The first project to slug its key handed the CLI a variable it had never heard of, and every read and rotation failed with `Missing access token`. If you add a provider, add its canonical variable to that table — do not reach for `bootstrap.key`.
+
+On the GitHub Actions surface the repository secret and the exported environment variable both carry the **configured** name, and the generated workflow templates it. Translating to the CLI's own variable stays in `providers.mjs`.
+
 **`require`** — optional. Omit it and every secret the provider grants is available, which is correct when the provider already scopes access per project. Present, it narrows to exactly those names **and asserts them**: a listed name that does not resolve is a startup error, not a late surprise.
 
 **`narrow`** — may only *narrow* the provider's own grant. There is deliberately no way to widen access from config; that boundary belongs to the provider.