@codyswann/lisa 4.59.1 → 4.59.3

package/expo/create-only/.github/workflows/deploy.yml

@@ -165,15 +165,23 @@ jobs:
     outputs:
       has_eas_setup: ${{ steps.check.outputs.has_eas_setup }}
     steps:
+      - uses: actions/checkout@v6
       - id: check
         run: |
-          if [[ -z "${EXPO_TOKEN}" ]]; then
-            echo "has_eas_setup=false" >> $GITHUB_OUTPUT
-          else
-            echo "has_eas_setup=true" >> $GITHUB_OUTPUT
+          set -eu
+          ready=false
+          if [ -n "$EXPO_TOKEN" ]; then
+            ready=true
+          elif [ -n "$LISA_SECRETS_BOOTSTRAP" ] && [ -f .lisa.config.json ]; then
+            provider=$(jq -r '.secrets.provider // "env"' .lisa.config.json)
+            if [ "$provider" != env ]; then ready=true; fi
           fi
+          # Eligibility is not authentication; each consuming job resolves its own token.
+          echo "has_eas_setup=$ready" >> "$GITHUB_OUTPUT"
         env:
           EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}
+          # Map this to the existing tenant-scoped bootstrap secret if named differently.
+          LISA_SECRETS_BOOTSTRAP: ${{ secrets.BWS_ACCESS_TOKEN }}
 
   # Check if native app config has changed
   check_app_config_changes:
@@ -236,6 +244,7 @@ jobs:
       environment: ${{ needs.determine_environment.outputs.environment }}
     secrets:
       EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}
+      LISA_SECRETS_BOOTSTRAP: ${{ secrets.BWS_ACCESS_TOKEN }}
 
   # EAS Deploy/Publish
   deploy:
@@ -316,15 +325,28 @@ jobs:
         uses: oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6 # v2.2.0
         with:
           bun-version: '1.3.8'
-      - name: Setup EAS
-        uses: expo/expo-github-action@c7b66a9c327a43a8fa7c0158e7f30d6040d2481e # v8.2.1
-        with:
-          eas-version: latest
-          token: ${{ secrets.EXPO_TOKEN }}
       - name: Set Env
         run: echo "PUPPETEER_SKIP_DOWNLOAD=true" >> $GITHUB_ENV
       - name: Install dependencies
         run: bun install
+      - name: Resolve Expo token
+        env:
+          EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}
+          LISA_SECRETS_BOOTSTRAP: ${{ secrets.BWS_ACCESS_TOKEN }}
+        run: |
+          set -eu
+          if [ -n "$EXPO_TOKEN" ] || [ -z "$LISA_SECRETS_BOOTSTRAP" ]; then exit 0; fi
+          resolver=node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-secrets-access/scripts/resolve-expo-token.mjs
+          if [ ! -f "$resolver" ]; then
+            echo "::error::Upgrade the project's @codyswann/lisa dependency before enabling provider-backed Expo authentication."
+            exit 1
+          fi
+          node "$resolver"
+      - name: Setup EAS
+        uses: expo/expo-github-action@c7b66a9c327a43a8fa7c0158e7f30d6040d2481e # v8.2.1
+        with:
+          eas-version: latest
+          token: ${{ secrets.EXPO_TOKEN || env.EXPO_TOKEN }}
       - name: Copy environment file
         uses: canastro/copy-file-action@ae66602ce7d214dbd2e298c1db67a81388755a0a # master (untagged, 2022-10-17)
         with:

package/package.json

@@ -187,7 +187,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.59.1",
+  "version": "4.59.3",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -336,7 +336,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "57d2652ca9c31fce079c238ec4fca388bac0231b",
-  "gitHead": "57d2652ca9c31fce079c238ec4fca388bac0231b",
-  "lisaReleaseTag": "v4.59.1"
+  "lisaReleaseCommit": "f5a23dafc5d3db6f0cea17f755e8536a1229c67c",
+  "gitHead": "f5a23dafc5d3db6f0cea17f755e8536a1229c67c",
+  "lisaReleaseTag": "v4.59.3"
 }

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.59.1",
+  "version": "4.59.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": "4.59.1",
+  "version": "4.59.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

@@ -188,6 +188,18 @@ On the GitHub Actions surface the repository secret and the exported environment
 
 There is no map of secret IDs, deliberately. Copying an ID per secret is the same duplication in a smaller costume, and lookup is by name.
 
+### Expo workflow pilot
+
+The reusable Expo build workflow and the Expo deploy template can resolve `EXPO_TOKEN` from the project's configured provider. An explicit `EXPO_TOKEN` repository secret still takes precedence. Projects without a provider bootstrap keep their existing behavior.
+
+For provider-backed Expo authentication, install a Lisa package containing `resolve-expo-token.mjs`, declare the provider and bootstrap in `.lisa.config.json`, and include `EXPO_TOKEN` if `secrets.require` is present. The workflow prepares only that provider's CLI through Lisa's existing installer, which uses checksum-pinned downloads for Bitwarden. Providers requiring manual setup must already be installed on the runner. The resolver respects the provider grant and `secrets.narrow`, masks the selected token, and writes only `EXPO_TOKEN` to the current job's environment. The bootstrap stays inside the resolver subprocess; the vault is not materialized into the job environment.
+
+The build workflow's optional `LISA_SECRETS_BOOTSTRAP` secret input accepts the existing repository bootstrap secret. This input is an alias, not another stored credential: the resolver maps it to `bootstrap.key` inside its process. The Expo caller template forwards `secrets.BWS_ACCESS_TOKEN` by default. If your stored bootstrap has a different name, update its three references: the eligibility check, the reusable build call, and the deploy job's resolution step.
+
+The eligibility check only establishes that an explicit token or a configured provider plus bootstrap is available. Each build or deploy job resolves its own token and must authenticate with Expo. A provider-backed caller using an older Lisa package fails with an upgrade instruction before invoking Expo.
+
+The deploy caller is a **create-only** template. Existing projects must deliberately apply these caller changes after upgrading Lisa; a normal sync does not overwrite their workflow. This pilot does not convert other workflow credentials. `DEPLOY_KEY` remains available before dependency installation for checkout. Do not remove an existing Expo repository secret until a provider-only run has authenticated successfully.
+
 ## The exposure boundary
 
 **The provider's own scoping is the default allowlist.** The machine account's project grants *are* the permitted set; restating that as a list in config would duplicate a boundary the provider already enforces.

package/plugins/lisa/.codex-plugin/skills/lisa-secrets-access/scripts/resolve-expo-token.mjs

@@ -0,0 +1,90 @@
+#!/usr/bin/env node
+/** Resolve the Expo pilot's credential inside its GitHub Actions job. */
+import { randomUUID } from "node:crypto";
+import { appendFileSync } from "node:fs";
+
+import { get, readConfig } from "./resolve-secret.mjs";
+import { ENV_KEY } from "./providers.mjs";
+import {
+  BIN_DIR,
+  ensureOnPath,
+  loadPinnedInstaller,
+} from "../../lisa-setup-workstation/scripts/cli.mjs";
+import {
+  installEntry,
+  planProvider,
+  resolveProvider,
+} from "../../lisa-setup-workstation/scripts/workstation.mjs";
+
+/** Provision only the selected provider, using the existing pinned installer. */
+async function prepareProvider(name) {
+  const provider = resolveProvider(name);
+  let plan = planProvider(provider);
+  if (plan.action === "present") return;
+  ensureOnPath(BIN_DIR);
+  plan = planProvider(provider);
+  if (plan.action === "present") return;
+  if (plan.action !== "install") throw new Error("Provider needs setup");
+  const installed = installEntry({ ...provider, name: provider.binary }, plan, {
+    installPinned: await loadPinnedInstaller(),
+  });
+  if (installed.action !== "installed")
+    throw new Error("Provider setup failed");
+}
+
+/** Keep the bootstrap inside this subprocess; export only the selected value. */
+async function resolveToken() {
+  const explicit = process.env.EXPO_TOKEN;
+  const bootstrap = process.env.LISA_SECRETS_BOOTSTRAP;
+  delete process.env.LISA_SECRETS_BOOTSTRAP;
+  if (explicit) return explicit;
+
+  process.env.LISA_SECRETS_SURFACE = "github-actions";
+  const cfg = readConfig();
+  if (cfg.provider === "env") return "";
+  if (
+    bootstrap &&
+    (!ENV_KEY.test(cfg.bootstrap.key ?? "") ||
+      cfg.bootstrap.key === "EXPO_TOKEN")
+  ) {
+    throw new Error("Invalid bootstrap key");
+  }
+  await prepareProvider(cfg.provider);
+  if (bootstrap) process.env[cfg.bootstrap.key] = bootstrap;
+  return get("EXPO_TOKEN", cfg);
+}
+
+if (process.argv.includes("--help")) {
+  // Safe to inspect without preparing a provider or reading/exporting a token.
+  console.log("Environment: EXPO_TOKEN LISA_SECRETS_BOOTSTRAP GITHUB_ENV");
+  console.log(
+    "An explicit EXPO_TOKEN takes precedence; otherwise resolve through the configured provider and export only EXPO_TOKEN to GITHUB_ENV."
+  );
+} else {
+  let failureMessage = "GITHUB_ENV is required to export EXPO_TOKEN.";
+  try {
+    const destination = process.env.GITHUB_ENV;
+    if (!destination) throw new Error("GITHUB_ENV is required");
+    failureMessage =
+      "Unable to resolve EXPO_TOKEN. Check the configured provider, bootstrap input, and secrets.require; ensure the runner can install its provider CLI.";
+    const token = await resolveToken();
+    if (token) {
+      const masked = token
+        .replaceAll("%", "%25")
+        .replaceAll("\r", "%0D")
+        .replaceAll("\n", "%0A");
+      console.log(`::add-mask::${masked}`);
+      const delimiter = randomUUID();
+      failureMessage =
+        "Unable to write EXPO_TOKEN to GITHUB_ENV. Check the runner's environment file.";
+      appendFileSync(
+        destination,
+        `EXPO_TOKEN<<${delimiter}\n${token}\n${delimiter}\n`
+      );
+    }
+  } catch {
+    // Provider errors can contain captured subprocess output. Never echo it.
+    console.error(failureMessage);
+    process.exitCode = 1;
+  }
+}

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

@@ -188,6 +188,18 @@ On the GitHub Actions surface the repository secret and the exported environment
 
 There is no map of secret IDs, deliberately. Copying an ID per secret is the same duplication in a smaller costume, and lookup is by name.
 
+### Expo workflow pilot
+
+The reusable Expo build workflow and the Expo deploy template can resolve `EXPO_TOKEN` from the project's configured provider. An explicit `EXPO_TOKEN` repository secret still takes precedence. Projects without a provider bootstrap keep their existing behavior.
+
+For provider-backed Expo authentication, install a Lisa package containing `resolve-expo-token.mjs`, declare the provider and bootstrap in `.lisa.config.json`, and include `EXPO_TOKEN` if `secrets.require` is present. The workflow prepares only that provider's CLI through Lisa's existing installer, which uses checksum-pinned downloads for Bitwarden. Providers requiring manual setup must already be installed on the runner. The resolver respects the provider grant and `secrets.narrow`, masks the selected token, and writes only `EXPO_TOKEN` to the current job's environment. The bootstrap stays inside the resolver subprocess; the vault is not materialized into the job environment.
+
+The build workflow's optional `LISA_SECRETS_BOOTSTRAP` secret input accepts the existing repository bootstrap secret. This input is an alias, not another stored credential: the resolver maps it to `bootstrap.key` inside its process. The Expo caller template forwards `secrets.BWS_ACCESS_TOKEN` by default. If your stored bootstrap has a different name, update its three references: the eligibility check, the reusable build call, and the deploy job's resolution step.
+
+The eligibility check only establishes that an explicit token or a configured provider plus bootstrap is available. Each build or deploy job resolves its own token and must authenticate with Expo. A provider-backed caller using an older Lisa package fails with an upgrade instruction before invoking Expo.
+
+The deploy caller is a **create-only** template. Existing projects must deliberately apply these caller changes after upgrading Lisa; a normal sync does not overwrite their workflow. This pilot does not convert other workflow credentials. `DEPLOY_KEY` remains available before dependency installation for checkout. Do not remove an existing Expo repository secret until a provider-only run has authenticated successfully.
+
 ## The exposure boundary
 
 **The provider's own scoping is the default allowlist.** The machine account's project grants *are* the permitted set; restating that as a list in config would duplicate a boundary the provider already enforces.

package/plugins/lisa/skills/lisa-secrets-access/scripts/resolve-expo-token.mjs

@@ -0,0 +1,90 @@
+#!/usr/bin/env node
+/** Resolve the Expo pilot's credential inside its GitHub Actions job. */
+import { randomUUID } from "node:crypto";
+import { appendFileSync } from "node:fs";
+
+import { get, readConfig } from "./resolve-secret.mjs";
+import { ENV_KEY } from "./providers.mjs";
+import {
+  BIN_DIR,
+  ensureOnPath,
+  loadPinnedInstaller,
+} from "../../lisa-setup-workstation/scripts/cli.mjs";
+import {
+  installEntry,
+  planProvider,
+  resolveProvider,
+} from "../../lisa-setup-workstation/scripts/workstation.mjs";
+
+/** Provision only the selected provider, using the existing pinned installer. */
+async function prepareProvider(name) {
+  const provider = resolveProvider(name);
+  let plan = planProvider(provider);
+  if (plan.action === "present") return;
+  ensureOnPath(BIN_DIR);
+  plan = planProvider(provider);
+  if (plan.action === "present") return;
+  if (plan.action !== "install") throw new Error("Provider needs setup");
+  const installed = installEntry({ ...provider, name: provider.binary }, plan, {
+    installPinned: await loadPinnedInstaller(),
+  });
+  if (installed.action !== "installed")
+    throw new Error("Provider setup failed");
+}
+
+/** Keep the bootstrap inside this subprocess; export only the selected value. */
+async function resolveToken() {
+  const explicit = process.env.EXPO_TOKEN;
+  const bootstrap = process.env.LISA_SECRETS_BOOTSTRAP;
+  delete process.env.LISA_SECRETS_BOOTSTRAP;
+  if (explicit) return explicit;
+
+  process.env.LISA_SECRETS_SURFACE = "github-actions";
+  const cfg = readConfig();
+  if (cfg.provider === "env") return "";
+  if (
+    bootstrap &&
+    (!ENV_KEY.test(cfg.bootstrap.key ?? "") ||
+      cfg.bootstrap.key === "EXPO_TOKEN")
+  ) {
+    throw new Error("Invalid bootstrap key");
+  }
+  await prepareProvider(cfg.provider);
+  if (bootstrap) process.env[cfg.bootstrap.key] = bootstrap;
+  return get("EXPO_TOKEN", cfg);
+}
+
+if (process.argv.includes("--help")) {
+  // Safe to inspect without preparing a provider or reading/exporting a token.
+  console.log("Environment: EXPO_TOKEN LISA_SECRETS_BOOTSTRAP GITHUB_ENV");
+  console.log(
+    "An explicit EXPO_TOKEN takes precedence; otherwise resolve through the configured provider and export only EXPO_TOKEN to GITHUB_ENV."
+  );
+} else {
+  let failureMessage = "GITHUB_ENV is required to export EXPO_TOKEN.";
+  try {
+    const destination = process.env.GITHUB_ENV;
+    if (!destination) throw new Error("GITHUB_ENV is required");
+    failureMessage =
+      "Unable to resolve EXPO_TOKEN. Check the configured provider, bootstrap input, and secrets.require; ensure the runner can install its provider CLI.";
+    const token = await resolveToken();
+    if (token) {
+      const masked = token
+        .replaceAll("%", "%25")
+        .replaceAll("\r", "%0D")
+        .replaceAll("\n", "%0A");
+      console.log(`::add-mask::${masked}`);
+      const delimiter = randomUUID();
+      failureMessage =
+        "Unable to write EXPO_TOKEN to GITHUB_ENV. Check the runner's environment file.";
+      appendFileSync(
+        destination,
+        `EXPO_TOKEN<<${delimiter}\n${token}\n${delimiter}\n`
+      );
+    }
+  } catch {
+    // Provider errors can contain captured subprocess output. Never echo it.
+    console.error(failureMessage);
+    process.exitCode = 1;
+  }
+}

package/plugins/lisa-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "4.59.1",
+  "version": "4.59.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

@@ -188,6 +188,18 @@ On the GitHub Actions surface the repository secret and the exported environment
 
 There is no map of secret IDs, deliberately. Copying an ID per secret is the same duplication in a smaller costume, and lookup is by name.
 
+### Expo workflow pilot
+
+The reusable Expo build workflow and the Expo deploy template can resolve `EXPO_TOKEN` from the project's configured provider. An explicit `EXPO_TOKEN` repository secret still takes precedence. Projects without a provider bootstrap keep their existing behavior.
+
+For provider-backed Expo authentication, install a Lisa package containing `resolve-expo-token.mjs`, declare the provider and bootstrap in `.lisa.config.json`, and include `EXPO_TOKEN` if `secrets.require` is present. The workflow prepares only that provider's CLI through Lisa's existing installer, which uses checksum-pinned downloads for Bitwarden. Providers requiring manual setup must already be installed on the runner. The resolver respects the provider grant and `secrets.narrow`, masks the selected token, and writes only `EXPO_TOKEN` to the current job's environment. The bootstrap stays inside the resolver subprocess; the vault is not materialized into the job environment.
+
+The build workflow's optional `LISA_SECRETS_BOOTSTRAP` secret input accepts the existing repository bootstrap secret. This input is an alias, not another stored credential: the resolver maps it to `bootstrap.key` inside its process. The Expo caller template forwards `secrets.BWS_ACCESS_TOKEN` by default. If your stored bootstrap has a different name, update its three references: the eligibility check, the reusable build call, and the deploy job's resolution step.
+
+The eligibility check only establishes that an explicit token or a configured provider plus bootstrap is available. Each build or deploy job resolves its own token and must authenticate with Expo. A provider-backed caller using an older Lisa package fails with an upgrade instruction before invoking Expo.
+
+The deploy caller is a **create-only** template. Existing projects must deliberately apply these caller changes after upgrading Lisa; a normal sync does not overwrite their workflow. This pilot does not convert other workflow credentials. `DEPLOY_KEY` remains available before dependency installation for checkout. Do not remove an existing Expo repository secret until a provider-only run has authenticated successfully.
+
 ## The exposure boundary
 
 **The provider's own scoping is the default allowlist.** The machine account's project grants *are* the permitted set; restating that as a list in config would duplicate a boundary the provider already enforces.

package/plugins/lisa-agy/skills/lisa-secrets-access/scripts/resolve-expo-token.mjs

@@ -0,0 +1,90 @@
+#!/usr/bin/env node
+/** Resolve the Expo pilot's credential inside its GitHub Actions job. */
+import { randomUUID } from "node:crypto";
+import { appendFileSync } from "node:fs";
+
+import { get, readConfig } from "./resolve-secret.mjs";
+import { ENV_KEY } from "./providers.mjs";
+import {
+  BIN_DIR,
+  ensureOnPath,
+  loadPinnedInstaller,
+} from "../../lisa-setup-workstation/scripts/cli.mjs";
+import {
+  installEntry,
+  planProvider,
+  resolveProvider,
+} from "../../lisa-setup-workstation/scripts/workstation.mjs";
+
+/** Provision only the selected provider, using the existing pinned installer. */
+async function prepareProvider(name) {
+  const provider = resolveProvider(name);
+  let plan = planProvider(provider);
+  if (plan.action === "present") return;
+  ensureOnPath(BIN_DIR);
+  plan = planProvider(provider);
+  if (plan.action === "present") return;
+  if (plan.action !== "install") throw new Error("Provider needs setup");
+  const installed = installEntry({ ...provider, name: provider.binary }, plan, {
+    installPinned: await loadPinnedInstaller(),
+  });
+  if (installed.action !== "installed")
+    throw new Error("Provider setup failed");
+}
+
+/** Keep the bootstrap inside this subprocess; export only the selected value. */
+async function resolveToken() {
+  const explicit = process.env.EXPO_TOKEN;
+  const bootstrap = process.env.LISA_SECRETS_BOOTSTRAP;
+  delete process.env.LISA_SECRETS_BOOTSTRAP;
+  if (explicit) return explicit;
+
+  process.env.LISA_SECRETS_SURFACE = "github-actions";
+  const cfg = readConfig();
+  if (cfg.provider === "env") return "";
+  if (
+    bootstrap &&
+    (!ENV_KEY.test(cfg.bootstrap.key ?? "") ||
+      cfg.bootstrap.key === "EXPO_TOKEN")
+  ) {
+    throw new Error("Invalid bootstrap key");
+  }
+  await prepareProvider(cfg.provider);
+  if (bootstrap) process.env[cfg.bootstrap.key] = bootstrap;
+  return get("EXPO_TOKEN", cfg);
+}
+
+if (process.argv.includes("--help")) {
+  // Safe to inspect without preparing a provider or reading/exporting a token.
+  console.log("Environment: EXPO_TOKEN LISA_SECRETS_BOOTSTRAP GITHUB_ENV");
+  console.log(
+    "An explicit EXPO_TOKEN takes precedence; otherwise resolve through the configured provider and export only EXPO_TOKEN to GITHUB_ENV."
+  );
+} else {
+  let failureMessage = "GITHUB_ENV is required to export EXPO_TOKEN.";
+  try {
+    const destination = process.env.GITHUB_ENV;
+    if (!destination) throw new Error("GITHUB_ENV is required");
+    failureMessage =
+      "Unable to resolve EXPO_TOKEN. Check the configured provider, bootstrap input, and secrets.require; ensure the runner can install its provider CLI.";
+    const token = await resolveToken();
+    if (token) {
+      const masked = token
+        .replaceAll("%", "%25")
+        .replaceAll("\r", "%0D")
+        .replaceAll("\n", "%0A");
+      console.log(`::add-mask::${masked}`);
+      const delimiter = randomUUID();
+      failureMessage =
+        "Unable to write EXPO_TOKEN to GITHUB_ENV. Check the runner's environment file.";
+      appendFileSync(
+        destination,
+        `EXPO_TOKEN<<${delimiter}\n${token}\n${delimiter}\n`
+      );
+    }
+  } catch {
+    // Provider errors can contain captured subprocess output. Never echo it.
+    console.error(failureMessage);
+    process.exitCode = 1;
+  }
+}

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.59.1",
+  "version": "4.59.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": "4.59.1",
+  "version": "4.59.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": "4.59.1",
+  "version": "4.59.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": "4.59.1",
+  "version": "4.59.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": "4.59.1",
+  "version": "4.59.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": "4.59.1",
+  "version": "4.59.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

@@ -188,6 +188,18 @@ On the GitHub Actions surface the repository secret and the exported environment
 
 There is no map of secret IDs, deliberately. Copying an ID per secret is the same duplication in a smaller costume, and lookup is by name.
 
+### Expo workflow pilot
+
+The reusable Expo build workflow and the Expo deploy template can resolve `EXPO_TOKEN` from the project's configured provider. An explicit `EXPO_TOKEN` repository secret still takes precedence. Projects without a provider bootstrap keep their existing behavior.
+
+For provider-backed Expo authentication, install a Lisa package containing `resolve-expo-token.mjs`, declare the provider and bootstrap in `.lisa.config.json`, and include `EXPO_TOKEN` if `secrets.require` is present. The workflow prepares only that provider's CLI through Lisa's existing installer, which uses checksum-pinned downloads for Bitwarden. Providers requiring manual setup must already be installed on the runner. The resolver respects the provider grant and `secrets.narrow`, masks the selected token, and writes only `EXPO_TOKEN` to the current job's environment. The bootstrap stays inside the resolver subprocess; the vault is not materialized into the job environment.
+
+The build workflow's optional `LISA_SECRETS_BOOTSTRAP` secret input accepts the existing repository bootstrap secret. This input is an alias, not another stored credential: the resolver maps it to `bootstrap.key` inside its process. The Expo caller template forwards `secrets.BWS_ACCESS_TOKEN` by default. If your stored bootstrap has a different name, update its three references: the eligibility check, the reusable build call, and the deploy job's resolution step.
+
+The eligibility check only establishes that an explicit token or a configured provider plus bootstrap is available. Each build or deploy job resolves its own token and must authenticate with Expo. A provider-backed caller using an older Lisa package fails with an upgrade instruction before invoking Expo.
+
+The deploy caller is a **create-only** template. Existing projects must deliberately apply these caller changes after upgrading Lisa; a normal sync does not overwrite their workflow. This pilot does not convert other workflow credentials. `DEPLOY_KEY` remains available before dependency installation for checkout. Do not remove an existing Expo repository secret until a provider-only run has authenticated successfully.
+
 ## The exposure boundary
 
 **The provider's own scoping is the default allowlist.** The machine account's project grants *are* the permitted set; restating that as a list in config would duplicate a boundary the provider already enforces.

package/plugins/lisa-copilot/skills/lisa-secrets-access/scripts/resolve-expo-token.mjs

@@ -0,0 +1,90 @@
+#!/usr/bin/env node
+/** Resolve the Expo pilot's credential inside its GitHub Actions job. */
+import { randomUUID } from "node:crypto";
+import { appendFileSync } from "node:fs";
+
+import { get, readConfig } from "./resolve-secret.mjs";
+import { ENV_KEY } from "./providers.mjs";
+import {
+  BIN_DIR,
+  ensureOnPath,
+  loadPinnedInstaller,
+} from "../../lisa-setup-workstation/scripts/cli.mjs";
+import {
+  installEntry,
+  planProvider,
+  resolveProvider,
+} from "../../lisa-setup-workstation/scripts/workstation.mjs";
+
+/** Provision only the selected provider, using the existing pinned installer. */
+async function prepareProvider(name) {
+  const provider = resolveProvider(name);
+  let plan = planProvider(provider);
+  if (plan.action === "present") return;
+  ensureOnPath(BIN_DIR);
+  plan = planProvider(provider);
+  if (plan.action === "present") return;
+  if (plan.action !== "install") throw new Error("Provider needs setup");
+  const installed = installEntry({ ...provider, name: provider.binary }, plan, {
+    installPinned: await loadPinnedInstaller(),
+  });
+  if (installed.action !== "installed")
+    throw new Error("Provider setup failed");
+}
+
+/** Keep the bootstrap inside this subprocess; export only the selected value. */
+async function resolveToken() {
+  const explicit = process.env.EXPO_TOKEN;
+  const bootstrap = process.env.LISA_SECRETS_BOOTSTRAP;
+  delete process.env.LISA_SECRETS_BOOTSTRAP;
+  if (explicit) return explicit;
+
+  process.env.LISA_SECRETS_SURFACE = "github-actions";
+  const cfg = readConfig();
+  if (cfg.provider === "env") return "";
+  if (
+    bootstrap &&
+    (!ENV_KEY.test(cfg.bootstrap.key ?? "") ||
+      cfg.bootstrap.key === "EXPO_TOKEN")
+  ) {
+    throw new Error("Invalid bootstrap key");
+  }
+  await prepareProvider(cfg.provider);
+  if (bootstrap) process.env[cfg.bootstrap.key] = bootstrap;
+  return get("EXPO_TOKEN", cfg);
+}
+
+if (process.argv.includes("--help")) {
+  // Safe to inspect without preparing a provider or reading/exporting a token.
+  console.log("Environment: EXPO_TOKEN LISA_SECRETS_BOOTSTRAP GITHUB_ENV");
+  console.log(
+    "An explicit EXPO_TOKEN takes precedence; otherwise resolve through the configured provider and export only EXPO_TOKEN to GITHUB_ENV."
+  );
+} else {
+  let failureMessage = "GITHUB_ENV is required to export EXPO_TOKEN.";
+  try {
+    const destination = process.env.GITHUB_ENV;
+    if (!destination) throw new Error("GITHUB_ENV is required");
+    failureMessage =
+      "Unable to resolve EXPO_TOKEN. Check the configured provider, bootstrap input, and secrets.require; ensure the runner can install its provider CLI.";
+    const token = await resolveToken();
+    if (token) {
+      const masked = token
+        .replaceAll("%", "%25")
+        .replaceAll("\r", "%0D")
+        .replaceAll("\n", "%0A");
+      console.log(`::add-mask::${masked}`);
+      const delimiter = randomUUID();
+      failureMessage =
+        "Unable to write EXPO_TOKEN to GITHUB_ENV. Check the runner's environment file.";
+      appendFileSync(
+        destination,
+        `EXPO_TOKEN<<${delimiter}\n${token}\n${delimiter}\n`
+      );
+    }
+  } catch {
+    // Provider errors can contain captured subprocess output. Never echo it.
+    console.error(failureMessage);
+    process.exitCode = 1;
+  }
+}

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

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

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

@@ -188,6 +188,18 @@ On the GitHub Actions surface the repository secret and the exported environment
 
 There is no map of secret IDs, deliberately. Copying an ID per secret is the same duplication in a smaller costume, and lookup is by name.
 
+### Expo workflow pilot
+
+The reusable Expo build workflow and the Expo deploy template can resolve `EXPO_TOKEN` from the project's configured provider. An explicit `EXPO_TOKEN` repository secret still takes precedence. Projects without a provider bootstrap keep their existing behavior.
+
+For provider-backed Expo authentication, install a Lisa package containing `resolve-expo-token.mjs`, declare the provider and bootstrap in `.lisa.config.json`, and include `EXPO_TOKEN` if `secrets.require` is present. The workflow prepares only that provider's CLI through Lisa's existing installer, which uses checksum-pinned downloads for Bitwarden. Providers requiring manual setup must already be installed on the runner. The resolver respects the provider grant and `secrets.narrow`, masks the selected token, and writes only `EXPO_TOKEN` to the current job's environment. The bootstrap stays inside the resolver subprocess; the vault is not materialized into the job environment.
+
+The build workflow's optional `LISA_SECRETS_BOOTSTRAP` secret input accepts the existing repository bootstrap secret. This input is an alias, not another stored credential: the resolver maps it to `bootstrap.key` inside its process. The Expo caller template forwards `secrets.BWS_ACCESS_TOKEN` by default. If your stored bootstrap has a different name, update its three references: the eligibility check, the reusable build call, and the deploy job's resolution step.
+
+The eligibility check only establishes that an explicit token or a configured provider plus bootstrap is available. Each build or deploy job resolves its own token and must authenticate with Expo. A provider-backed caller using an older Lisa package fails with an upgrade instruction before invoking Expo.
+
+The deploy caller is a **create-only** template. Existing projects must deliberately apply these caller changes after upgrading Lisa; a normal sync does not overwrite their workflow. This pilot does not convert other workflow credentials. `DEPLOY_KEY` remains available before dependency installation for checkout. Do not remove an existing Expo repository secret until a provider-only run has authenticated successfully.
+
 ## The exposure boundary
 
 **The provider's own scoping is the default allowlist.** The machine account's project grants *are* the permitted set; restating that as a list in config would duplicate a boundary the provider already enforces.