@codyswann/lisa 2.178.4 → 2.178.6

package/package.json

@@ -91,7 +91,7 @@
     "ws": ">=8.20.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.178.4",
+  "version": "2.178.6",
   "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.178.4",
+  "version": "2.178.6",
   "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.178.4",
+  "version": "2.178.6",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/skills/analyze-claude-remote/SKILL.md

@@ -78,13 +78,18 @@ Group the findings as:
    git, and coreutils are present; `gh` is available but should be installed explicitly if scripts
    call it. Classify each `REQUIRED` (core path uses it) vs `OPTIONAL` (only a dormant stack/skill
    uses it). Typical finds: `gh`, `jq`, `docker` (ZAP), `aws`, `acli`, `ruby`/`rubocop`,
-   `python3`, `playwright`/chromium, secret scanners.
+   `python3`, `playwright`/chromium, secret scanners. Treat AWS as more than a
+   binary install: if the repo invokes `aws`, imports AWS SDK packages, uses CDK/Serverless/SST,
+   references `AWS_*` env vars, or documents `aws sso login` / `sso_*` profile setup, add the AWS
+   credential findings in group 4b as well as the `aws` CLI tool finding.
 
 4. **Environment variables & secrets** — scan for `process.env.*`, `${VAR}`/`$VAR` in shell,
    `secrets.*`/`env:` in CI, and config-referenced tokens. Group by integration (GitHub, AWS,
    Atlassian/JIRA/Confluence, Notion, Linear, Anthropic, notifications, feature flags, other).
    Cross-reference `.lisa.config.json` `tracker`/`source` to mark which credentials are **active**
-   for this repo vs **dormant** (`OPTIONAL`). Distinguish *where* each var must be set, because the
+   for this repo vs **dormant** (`OPTIONAL`). Separately classify host-project AWS usage in group 4b:
+   AWS can be required even when it is not the tracker or PRD source. Distinguish *where* each var
+   must be set, because the
    answer differs and getting it wrong sends the user to do redundant work:
 
    - **Committed `.claude/settings.json` `env` flags** (e.g. `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`,
@@ -128,6 +133,34 @@ Group the findings as:
    guessed. If a value the table needs (server URL, project key, workspace id, email, team key) is
    missing from `.lisa.config.json`, flag it as a `GAP`/`Action:` to set it, rather than inventing one.
 
+4b. **AWS operations credentials** — scan the host project for AWS usage independent of Lisa's
+   tracker/source config:
+
+   - `aws` CLI invocations in `scripts/`, package scripts, committed skills/agents, or
+     `.github/workflows/`.
+   - AWS SDK imports/packages (`@aws-sdk/*`, `aws-sdk`, `boto3`, CDK, Serverless, SST, Amplify,
+     Terraform providers).
+   - `aws sso login`, `aws:signin:*`, `sso_start_url`, `sso_account_id`, `sso_role_name`, or
+     `sso_session` in docs or config.
+   - `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN`, `AWS_DEFAULT_REGION`,
+     `AWS_PROFILE`, role ARN, external ID, account, or CloudWatch/STS references.
+
+   If AWS is present, emit an AWS credential finding and inventory entry. If the repo's current
+   local path is `aws sso login` or an `aws:signin:*` script, classify that local path as a `GAP`
+   for headless remote routines: it is an interactive browser/device-authorization flow and cannot
+   complete in the cloud. Route to the AWS row in the Credential reference instead of suggesting
+   SSO auth. The finding must name the headless substrate: a dedicated IAM principal (user or role)
+   with only permission to `sts:AssumeRole`, environment credentials in the routine UI, and
+   `~/.aws/config` profiles using `role_arn`, `credential_source = Environment`, optional
+   `external_id`, and `region`.
+
+   When the repository contains concrete non-secret AWS metadata (role ARNs, account aliases,
+   profile names, regions, or ExternalId values), include it in an `awsProfiles` inventory array so
+   `/lisa:generate-claude-remote-build-script` can write matching `~/.aws/config` profiles. Never
+   invent account IDs, ExternalIds, role names, or regions. If AWS is detected but profile metadata
+   is absent, emit the required AWS secret names plus an action to add project-specific profile
+   metadata to the generated artifact or environment notes.
+
 5. **MCP servers** — read every committed `.mcp.json`. For each server report transport and auth.
    Project-scoped HTTP/SSE servers with no interactive auth are `OK`. Flag stdio servers as
    `RISK`/`GAP` (need a local process — only viable if the cloud session can spawn them from the
@@ -234,6 +267,31 @@ unsuffixed `…_TOKEN`/`…_KEY` is the simplest to set in a single-account rout
 - Acquire: `https://linear.app/<workspace>/settings/account/security` → Personal API keys → New API key.
 - Access: the personal API key inherits the user's workspace permissions — the user must be able to read/create/update Issues in the destination team.
 
+### AWS — host-project operations, logs, deploys, CDK/Serverless/SST, or AWS SDK usage
+- Headless substrate: a dedicated IAM principal (user or role) with long-lived bootstrap credentials
+  stored in the routine environment, used only to call `sts:AssumeRole` into per-account operational
+  roles. The routine writes `~/.aws/config` profiles with `role_arn`, `credential_source =
+  Environment`, optional `external_id`, and `region`; agents use `aws --profile <profile> ...`.
+- Env: `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`; optional `AWS_SESSION_TOKEN` for temporary
+  bootstrap credentials; `AWS_DEFAULT_REGION` when no profile region is provided. Role ARNs,
+  ExternalIds, profile names, and regions are non-secret project metadata and belong in generated
+  artifacts or project docs, not in the skill's global guidance.
+- Allowlist: `*.amazonaws.com`, or narrower service hosts such as `sts.amazonaws.com`,
+  `logs.<region>.amazonaws.com`, `cloudwatch.<region>.amazonaws.com`,
+  `xray.<region>.amazonaws.com`, `ssm.<region>.amazonaws.com`, and service-specific endpoints the
+  repo uses.
+- Access: the bootstrap principal should have only `sts:AssumeRole` on the scoped operational role
+  ARNs, preferably guarded by an `ExternalId` condition. The assumed roles carry the real
+  permissions needed by the repo (CloudWatch Logs, deploy, SSM, etc.) as short-lived STS
+  credentials.
+- IAM Identity Center caveat: an IAM Identity Center permission set provisions an `AWSReservedSSO_*`
+  role whose trust allows the SSO service, not an arbitrary IAM principal. A headless IAM principal
+  cannot directly assume that reserved role. Use a separate assumable role that attaches the same
+  policy as the permission set, with the delegated Identity Center admin keeping that policy as the
+  source of truth.
+- Alternative: IAM Roles Anywhere (X.509 to STS) when long-lived bootstrap access keys are
+  unacceptable.
+
 ## Output
 
 Render the report grouped exactly as above. Start with one `Summary:` line, then a `Counts:` line
@@ -296,6 +354,15 @@ so the generator can render acquisition comments into its template:
     { "name": "jam", "transport": "http", "auth": "oauth", "headlessUsable": true, "replacedBy": "jam CLI + JAM_PAT", "dormant": true },
     { "name": "sonarqube", "transport": "stdio", "auth": "local-wrapper", "headlessUsable": true, "replacedBy": "SONAR_TOKEN + SonarCloud Web API", "dormant": true }
   ],
+  "awsProfiles": [
+    {
+      "name": "dev",
+      "roleArn": "arn:aws:iam::<account-id>:role/<role-name>",
+      "credentialSource": "Environment",
+      "externalId": "<project-external-id>",
+      "region": "us-east-1"
+    }
+  ],
   "gaps": [ "auto-memory not synced to cloud", "bun package fetch behind proxy", "OS keychain absent — env-var token form only" ],
   "platform": {
     "githubProxy": {
@@ -346,6 +413,9 @@ so the generator can render acquisition comments into its template:
   to environment editors; never imply the generated script can hide them.
 - A browser-OAuth MCP (or interactively-authed CLI) backing an active integration is a `GAP`; the
   remediation is its token substrate from the table, not "authenticate the MCP".
+- `aws sso login`, `sso_*` profile configuration, and project scripts that wrap AWS SSO are
+  interactive-auth paths. In a headless routine they are a `GAP`, not a setup step. Route AWS access
+  to env-var bootstrap credentials plus assume-role profiles.
 - For non-tracker MCPs, a documented CLI, PAT/API-key, or REST substrate converts the finding from
   a flat `GAP` into an `OPTIONAL` headless recovery path; unknown vendors remain gaps with a
   vendor-substrate follow-up, not invented credentials.

package/plugins/lisa/skills/generate-claude-remote-build-script/SKILL.md

@@ -31,7 +31,7 @@ tracker/source, plus the host project's own package manager and tooling — not
 
 1. **Inventory.** Invoke `/lisa:analyze-claude-remote --json` and parse its machine-readable
    inventory block (`packageManager`, `tools`, `env`, `mcp`, `gaps`, `platform`,
-   `networkAccess`, `allowlistDomains`). If the analysis cannot run, stop and report why — never
+   `networkAccess`, `allowlistDomains`, `awsProfiles`). If the analysis cannot run, stop and report why — never
    emit a script from guesses.
 
 2. **Compose the setup script** from the inventory. The script must be:
@@ -71,6 +71,9 @@ tracker/source, plus the host project's own package manager and tooling — not
    include `JAM_PAT`, `SONAR_TOKEN`, or similar documented substrate env vars
    only as optional secrets, with their acquire/scope comments when the analysis
    supplied them. Never invent values or promote dormant substrates to required.
+   When AWS entries are present, list `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, optional
+   `AWS_SESSION_TOKEN`, and `AWS_DEFAULT_REGION` exactly as the analysis reported. State that these
+   bootstrap credentials are for STS assume-role only; do not emit or recommend `aws sso login`.
 
 3a. **Emit substrate setup snippets.** When the inventory marks an MCP
    `headlessUsable: true` through a documented substrate, render the matching
@@ -88,6 +91,19 @@ tracker/source, plus the host project's own package manager and tooling — not
      transport supports static-token auth. Do not print a Jam `.mcp.json` header snippet because
      Jam's preferred headless substrate is its PAT-authenticated CLI.
 
+3b. **Emit AWS assume-role profile setup.** When the inventory includes `awsProfiles`, write an
+   idempotent `~/.aws/config` block gated on `[ -n "${AWS_ACCESS_KEY_ID:-}" ]`. The generated block
+   must:
+   - `mkdir -p "$HOME/.aws"` and create or append profile stanzas without writing secrets.
+   - Emit one `[profile <name>]` stanza per inventory profile with `role_arn`,
+     `credential_source = Environment`, `region` when present, and `external_id` when present.
+   - Keep regions and ExternalIds as non-secret project metadata from the inventory; never invent
+     account IDs, role names, profile names, regions, or ExternalIds.
+   - Warn and skip profile writing when AWS profile metadata is absent, while still listing the
+     required `AWS_*` env var names in the secret template.
+   - Include a comment that agents should use `aws --profile <name> ...` and must not run
+     `aws sso login` in headless routines.
+
 4. **Emit the allowlist + gaps notice.** List any custom domains the setup or runtime reaches
    (from `networkAccess.allowlistDomains`, falling back to legacy `allowlistDomains`) that the user
    must add when the environment needs Custom network access. Do not include default Trusted domains
@@ -123,6 +139,9 @@ shape, not a fixed payload):
 #   # Note: GH_TOKEN is for gh CLI only. Raw git uses Claude's connected-GitHub proxy/identity;
 #   # sibling repos reached only by raw git do not need to be in this token scope.
 #   - GH_TOKEN=<token>                          # REQUIRED, github is the active tracker+source
+#   - AWS_ACCESS_KEY_ID=<access-key-id>          # REQUIRED when AWS inventory is active
+#   - AWS_SECRET_ACCESS_KEY=<secret-access-key>  # REQUIRED when AWS inventory is active
+#   - AWS_SESSION_TOKEN=<session-token>          # OPTIONAL for temporary bootstrap creds
 # NETWORK: set the environment to Custom and allowlist these non-default domains if not on Full:
 #   - <networkAccess.allowlistDomains, if any>
 set -uo pipefail
@@ -165,6 +184,14 @@ need gh || (sudo apt-get update -y && sudo apt-get install -y gh)
 need jq || sudo apt-get install -y jq
 require gh; require jq
 
+# --- AWS assume-role profiles, when inventory includes awsProfiles ---
+if [ -n "${AWS_ACCESS_KEY_ID:-}" ]; then
+  mkdir -p "$HOME/.aws"
+  # Generated stanzas use credential_source=Environment and contain no secrets.
+  # Agents should run: aws --profile <profile> ...
+  # Do not run aws sso login in headless routines; SSO requires an interactive browser/device flow.
+fi
+
 # --- optional, only with --include-optional ---
 # (docker / ruby / chromium / etc., guarded)
 ```
@@ -186,6 +213,8 @@ to stop are: the analysis could not run, or the `--out` path is not writable.
   raw git/cross-repo clone guidance must not expand the token scope to sibling repositories.
 - Never emit an install for a tool the analysis did not surface, and never install `OPTIONAL` tools
   unless `--include-optional` is set.
+- When AWS is in the inventory, generate environment-backed assume-role profile stanzas from
+  `awsProfiles`; never emit `aws sso login` as a remote setup step.
 - Prefer `networkAccess.allowlistDomains` over legacy top-level `allowlistDomains`; never emit
   domains already covered by the routine environment's default Trusted list.
 - Keep the script idempotent and detect-before-install so it is safe to re-run and cache.

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/analyze-claude-remote/SKILL.md

@@ -78,13 +78,18 @@ Group the findings as:
    git, and coreutils are present; `gh` is available but should be installed explicitly if scripts
    call it. Classify each `REQUIRED` (core path uses it) vs `OPTIONAL` (only a dormant stack/skill
    uses it). Typical finds: `gh`, `jq`, `docker` (ZAP), `aws`, `acli`, `ruby`/`rubocop`,
-   `python3`, `playwright`/chromium, secret scanners.
+   `python3`, `playwright`/chromium, secret scanners. Treat AWS as more than a
+   binary install: if the repo invokes `aws`, imports AWS SDK packages, uses CDK/Serverless/SST,
+   references `AWS_*` env vars, or documents `aws sso login` / `sso_*` profile setup, add the AWS
+   credential findings in group 4b as well as the `aws` CLI tool finding.
 
 4. **Environment variables & secrets** — scan for `process.env.*`, `${VAR}`/`$VAR` in shell,
    `secrets.*`/`env:` in CI, and config-referenced tokens. Group by integration (GitHub, AWS,
    Atlassian/JIRA/Confluence, Notion, Linear, Anthropic, notifications, feature flags, other).
    Cross-reference `.lisa.config.json` `tracker`/`source` to mark which credentials are **active**
-   for this repo vs **dormant** (`OPTIONAL`). Distinguish *where* each var must be set, because the
+   for this repo vs **dormant** (`OPTIONAL`). Separately classify host-project AWS usage in group 4b:
+   AWS can be required even when it is not the tracker or PRD source. Distinguish *where* each var
+   must be set, because the
    answer differs and getting it wrong sends the user to do redundant work:
 
    - **Committed `.claude/settings.json` `env` flags** (e.g. `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`,
@@ -128,6 +133,34 @@ Group the findings as:
    guessed. If a value the table needs (server URL, project key, workspace id, email, team key) is
    missing from `.lisa.config.json`, flag it as a `GAP`/`Action:` to set it, rather than inventing one.
 
+4b. **AWS operations credentials** — scan the host project for AWS usage independent of Lisa's
+   tracker/source config:
+
+   - `aws` CLI invocations in `scripts/`, package scripts, committed skills/agents, or
+     `.github/workflows/`.
+   - AWS SDK imports/packages (`@aws-sdk/*`, `aws-sdk`, `boto3`, CDK, Serverless, SST, Amplify,
+     Terraform providers).
+   - `aws sso login`, `aws:signin:*`, `sso_start_url`, `sso_account_id`, `sso_role_name`, or
+     `sso_session` in docs or config.
+   - `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN`, `AWS_DEFAULT_REGION`,
+     `AWS_PROFILE`, role ARN, external ID, account, or CloudWatch/STS references.
+
+   If AWS is present, emit an AWS credential finding and inventory entry. If the repo's current
+   local path is `aws sso login` or an `aws:signin:*` script, classify that local path as a `GAP`
+   for headless remote routines: it is an interactive browser/device-authorization flow and cannot
+   complete in the cloud. Route to the AWS row in the Credential reference instead of suggesting
+   SSO auth. The finding must name the headless substrate: a dedicated IAM principal (user or role)
+   with only permission to `sts:AssumeRole`, environment credentials in the routine UI, and
+   `~/.aws/config` profiles using `role_arn`, `credential_source = Environment`, optional
+   `external_id`, and `region`.
+
+   When the repository contains concrete non-secret AWS metadata (role ARNs, account aliases,
+   profile names, regions, or ExternalId values), include it in an `awsProfiles` inventory array so
+   `/lisa:generate-claude-remote-build-script` can write matching `~/.aws/config` profiles. Never
+   invent account IDs, ExternalIds, role names, or regions. If AWS is detected but profile metadata
+   is absent, emit the required AWS secret names plus an action to add project-specific profile
+   metadata to the generated artifact or environment notes.
+
 5. **MCP servers** — read every committed `.mcp.json`. For each server report transport and auth.
    Project-scoped HTTP/SSE servers with no interactive auth are `OK`. Flag stdio servers as
    `RISK`/`GAP` (need a local process — only viable if the cloud session can spawn them from the
@@ -234,6 +267,31 @@ unsuffixed `…_TOKEN`/`…_KEY` is the simplest to set in a single-account rout
 - Acquire: `https://linear.app/<workspace>/settings/account/security` → Personal API keys → New API key.
 - Access: the personal API key inherits the user's workspace permissions — the user must be able to read/create/update Issues in the destination team.
 
+### AWS — host-project operations, logs, deploys, CDK/Serverless/SST, or AWS SDK usage
+- Headless substrate: a dedicated IAM principal (user or role) with long-lived bootstrap credentials
+  stored in the routine environment, used only to call `sts:AssumeRole` into per-account operational
+  roles. The routine writes `~/.aws/config` profiles with `role_arn`, `credential_source =
+  Environment`, optional `external_id`, and `region`; agents use `aws --profile <profile> ...`.
+- Env: `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`; optional `AWS_SESSION_TOKEN` for temporary
+  bootstrap credentials; `AWS_DEFAULT_REGION` when no profile region is provided. Role ARNs,
+  ExternalIds, profile names, and regions are non-secret project metadata and belong in generated
+  artifacts or project docs, not in the skill's global guidance.
+- Allowlist: `*.amazonaws.com`, or narrower service hosts such as `sts.amazonaws.com`,
+  `logs.<region>.amazonaws.com`, `cloudwatch.<region>.amazonaws.com`,
+  `xray.<region>.amazonaws.com`, `ssm.<region>.amazonaws.com`, and service-specific endpoints the
+  repo uses.
+- Access: the bootstrap principal should have only `sts:AssumeRole` on the scoped operational role
+  ARNs, preferably guarded by an `ExternalId` condition. The assumed roles carry the real
+  permissions needed by the repo (CloudWatch Logs, deploy, SSM, etc.) as short-lived STS
+  credentials.
+- IAM Identity Center caveat: an IAM Identity Center permission set provisions an `AWSReservedSSO_*`
+  role whose trust allows the SSO service, not an arbitrary IAM principal. A headless IAM principal
+  cannot directly assume that reserved role. Use a separate assumable role that attaches the same
+  policy as the permission set, with the delegated Identity Center admin keeping that policy as the
+  source of truth.
+- Alternative: IAM Roles Anywhere (X.509 to STS) when long-lived bootstrap access keys are
+  unacceptable.
+
 ## Output
 
 Render the report grouped exactly as above. Start with one `Summary:` line, then a `Counts:` line
@@ -296,6 +354,15 @@ so the generator can render acquisition comments into its template:
     { "name": "jam", "transport": "http", "auth": "oauth", "headlessUsable": true, "replacedBy": "jam CLI + JAM_PAT", "dormant": true },
     { "name": "sonarqube", "transport": "stdio", "auth": "local-wrapper", "headlessUsable": true, "replacedBy": "SONAR_TOKEN + SonarCloud Web API", "dormant": true }
   ],
+  "awsProfiles": [
+    {
+      "name": "dev",
+      "roleArn": "arn:aws:iam::<account-id>:role/<role-name>",
+      "credentialSource": "Environment",
+      "externalId": "<project-external-id>",
+      "region": "us-east-1"
+    }
+  ],
   "gaps": [ "auto-memory not synced to cloud", "bun package fetch behind proxy", "OS keychain absent — env-var token form only" ],
   "platform": {
     "githubProxy": {
@@ -346,6 +413,9 @@ so the generator can render acquisition comments into its template:
   to environment editors; never imply the generated script can hide them.
 - A browser-OAuth MCP (or interactively-authed CLI) backing an active integration is a `GAP`; the
   remediation is its token substrate from the table, not "authenticate the MCP".
+- `aws sso login`, `sso_*` profile configuration, and project scripts that wrap AWS SSO are
+  interactive-auth paths. In a headless routine they are a `GAP`, not a setup step. Route AWS access
+  to env-var bootstrap credentials plus assume-role profiles.
 - For non-tracker MCPs, a documented CLI, PAT/API-key, or REST substrate converts the finding from
   a flat `GAP` into an `OPTIONAL` headless recovery path; unknown vendors remain gaps with a
   vendor-substrate follow-up, not invented credentials.

package/plugins/lisa-agy/skills/generate-claude-remote-build-script/SKILL.md

@@ -31,7 +31,7 @@ tracker/source, plus the host project's own package manager and tooling — not
 
 1. **Inventory.** Invoke `/lisa:analyze-claude-remote --json` and parse its machine-readable
    inventory block (`packageManager`, `tools`, `env`, `mcp`, `gaps`, `platform`,
-   `networkAccess`, `allowlistDomains`). If the analysis cannot run, stop and report why — never
+   `networkAccess`, `allowlistDomains`, `awsProfiles`). If the analysis cannot run, stop and report why — never
    emit a script from guesses.
 
 2. **Compose the setup script** from the inventory. The script must be:
@@ -71,6 +71,9 @@ tracker/source, plus the host project's own package manager and tooling — not
    include `JAM_PAT`, `SONAR_TOKEN`, or similar documented substrate env vars
    only as optional secrets, with their acquire/scope comments when the analysis
    supplied them. Never invent values or promote dormant substrates to required.
+   When AWS entries are present, list `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, optional
+   `AWS_SESSION_TOKEN`, and `AWS_DEFAULT_REGION` exactly as the analysis reported. State that these
+   bootstrap credentials are for STS assume-role only; do not emit or recommend `aws sso login`.
 
 3a. **Emit substrate setup snippets.** When the inventory marks an MCP
    `headlessUsable: true` through a documented substrate, render the matching
@@ -88,6 +91,19 @@ tracker/source, plus the host project's own package manager and tooling — not
      transport supports static-token auth. Do not print a Jam `.mcp.json` header snippet because
      Jam's preferred headless substrate is its PAT-authenticated CLI.
 
+3b. **Emit AWS assume-role profile setup.** When the inventory includes `awsProfiles`, write an
+   idempotent `~/.aws/config` block gated on `[ -n "${AWS_ACCESS_KEY_ID:-}" ]`. The generated block
+   must:
+   - `mkdir -p "$HOME/.aws"` and create or append profile stanzas without writing secrets.
+   - Emit one `[profile <name>]` stanza per inventory profile with `role_arn`,
+     `credential_source = Environment`, `region` when present, and `external_id` when present.
+   - Keep regions and ExternalIds as non-secret project metadata from the inventory; never invent
+     account IDs, role names, profile names, regions, or ExternalIds.
+   - Warn and skip profile writing when AWS profile metadata is absent, while still listing the
+     required `AWS_*` env var names in the secret template.
+   - Include a comment that agents should use `aws --profile <name> ...` and must not run
+     `aws sso login` in headless routines.
+
 4. **Emit the allowlist + gaps notice.** List any custom domains the setup or runtime reaches
    (from `networkAccess.allowlistDomains`, falling back to legacy `allowlistDomains`) that the user
    must add when the environment needs Custom network access. Do not include default Trusted domains
@@ -123,6 +139,9 @@ shape, not a fixed payload):
 #   # Note: GH_TOKEN is for gh CLI only. Raw git uses Claude's connected-GitHub proxy/identity;
 #   # sibling repos reached only by raw git do not need to be in this token scope.
 #   - GH_TOKEN=<token>                          # REQUIRED, github is the active tracker+source
+#   - AWS_ACCESS_KEY_ID=<access-key-id>          # REQUIRED when AWS inventory is active
+#   - AWS_SECRET_ACCESS_KEY=<secret-access-key>  # REQUIRED when AWS inventory is active
+#   - AWS_SESSION_TOKEN=<session-token>          # OPTIONAL for temporary bootstrap creds
 # NETWORK: set the environment to Custom and allowlist these non-default domains if not on Full:
 #   - <networkAccess.allowlistDomains, if any>
 set -uo pipefail
@@ -165,6 +184,14 @@ need gh || (sudo apt-get update -y && sudo apt-get install -y gh)
 need jq || sudo apt-get install -y jq
 require gh; require jq
 
+# --- AWS assume-role profiles, when inventory includes awsProfiles ---
+if [ -n "${AWS_ACCESS_KEY_ID:-}" ]; then
+  mkdir -p "$HOME/.aws"
+  # Generated stanzas use credential_source=Environment and contain no secrets.
+  # Agents should run: aws --profile <profile> ...
+  # Do not run aws sso login in headless routines; SSO requires an interactive browser/device flow.
+fi
+
 # --- optional, only with --include-optional ---
 # (docker / ruby / chromium / etc., guarded)
 ```
@@ -186,6 +213,8 @@ to stop are: the analysis could not run, or the `--out` path is not writable.
   raw git/cross-repo clone guidance must not expand the token scope to sibling repositories.
 - Never emit an install for a tool the analysis did not surface, and never install `OPTIONAL` tools
   unless `--include-optional` is set.
+- When AWS is in the inventory, generate environment-backed assume-role profile stanzas from
+  `awsProfiles`; never emit `aws sso login` as a remote setup step.
 - Prefer `networkAccess.allowlistDomains` over legacy top-level `allowlistDomains`; never emit
   domains already covered by the routine environment's default Trusted list.
 - Keep the script idempotent and detect-before-install so it is safe to re-run and cache.

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

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

package/plugins/lisa-copilot/skills/analyze-claude-remote/SKILL.md

@@ -78,13 +78,18 @@ Group the findings as:
    git, and coreutils are present; `gh` is available but should be installed explicitly if scripts
    call it. Classify each `REQUIRED` (core path uses it) vs `OPTIONAL` (only a dormant stack/skill
    uses it). Typical finds: `gh`, `jq`, `docker` (ZAP), `aws`, `acli`, `ruby`/`rubocop`,
-   `python3`, `playwright`/chromium, secret scanners.
+   `python3`, `playwright`/chromium, secret scanners. Treat AWS as more than a
+   binary install: if the repo invokes `aws`, imports AWS SDK packages, uses CDK/Serverless/SST,
+   references `AWS_*` env vars, or documents `aws sso login` / `sso_*` profile setup, add the AWS
+   credential findings in group 4b as well as the `aws` CLI tool finding.
 
 4. **Environment variables & secrets** — scan for `process.env.*`, `${VAR}`/`$VAR` in shell,
    `secrets.*`/`env:` in CI, and config-referenced tokens. Group by integration (GitHub, AWS,
    Atlassian/JIRA/Confluence, Notion, Linear, Anthropic, notifications, feature flags, other).
    Cross-reference `.lisa.config.json` `tracker`/`source` to mark which credentials are **active**
-   for this repo vs **dormant** (`OPTIONAL`). Distinguish *where* each var must be set, because the
+   for this repo vs **dormant** (`OPTIONAL`). Separately classify host-project AWS usage in group 4b:
+   AWS can be required even when it is not the tracker or PRD source. Distinguish *where* each var
+   must be set, because the
    answer differs and getting it wrong sends the user to do redundant work:
 
    - **Committed `.claude/settings.json` `env` flags** (e.g. `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS`,
@@ -128,6 +133,34 @@ Group the findings as:
    guessed. If a value the table needs (server URL, project key, workspace id, email, team key) is
    missing from `.lisa.config.json`, flag it as a `GAP`/`Action:` to set it, rather than inventing one.
 
+4b. **AWS operations credentials** — scan the host project for AWS usage independent of Lisa's
+   tracker/source config:
+
+   - `aws` CLI invocations in `scripts/`, package scripts, committed skills/agents, or
+     `.github/workflows/`.
+   - AWS SDK imports/packages (`@aws-sdk/*`, `aws-sdk`, `boto3`, CDK, Serverless, SST, Amplify,
+     Terraform providers).
+   - `aws sso login`, `aws:signin:*`, `sso_start_url`, `sso_account_id`, `sso_role_name`, or
+     `sso_session` in docs or config.
+   - `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN`, `AWS_DEFAULT_REGION`,
+     `AWS_PROFILE`, role ARN, external ID, account, or CloudWatch/STS references.
+
+   If AWS is present, emit an AWS credential finding and inventory entry. If the repo's current
+   local path is `aws sso login` or an `aws:signin:*` script, classify that local path as a `GAP`
+   for headless remote routines: it is an interactive browser/device-authorization flow and cannot
+   complete in the cloud. Route to the AWS row in the Credential reference instead of suggesting
+   SSO auth. The finding must name the headless substrate: a dedicated IAM principal (user or role)
+   with only permission to `sts:AssumeRole`, environment credentials in the routine UI, and
+   `~/.aws/config` profiles using `role_arn`, `credential_source = Environment`, optional
+   `external_id`, and `region`.
+
+   When the repository contains concrete non-secret AWS metadata (role ARNs, account aliases,
+   profile names, regions, or ExternalId values), include it in an `awsProfiles` inventory array so
+   `/lisa:generate-claude-remote-build-script` can write matching `~/.aws/config` profiles. Never
+   invent account IDs, ExternalIds, role names, or regions. If AWS is detected but profile metadata
+   is absent, emit the required AWS secret names plus an action to add project-specific profile
+   metadata to the generated artifact or environment notes.
+
 5. **MCP servers** — read every committed `.mcp.json`. For each server report transport and auth.
    Project-scoped HTTP/SSE servers with no interactive auth are `OK`. Flag stdio servers as
    `RISK`/`GAP` (need a local process — only viable if the cloud session can spawn them from the
@@ -234,6 +267,31 @@ unsuffixed `…_TOKEN`/`…_KEY` is the simplest to set in a single-account rout
 - Acquire: `https://linear.app/<workspace>/settings/account/security` → Personal API keys → New API key.
 - Access: the personal API key inherits the user's workspace permissions — the user must be able to read/create/update Issues in the destination team.
 
+### AWS — host-project operations, logs, deploys, CDK/Serverless/SST, or AWS SDK usage
+- Headless substrate: a dedicated IAM principal (user or role) with long-lived bootstrap credentials
+  stored in the routine environment, used only to call `sts:AssumeRole` into per-account operational
+  roles. The routine writes `~/.aws/config` profiles with `role_arn`, `credential_source =
+  Environment`, optional `external_id`, and `region`; agents use `aws --profile <profile> ...`.
+- Env: `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`; optional `AWS_SESSION_TOKEN` for temporary
+  bootstrap credentials; `AWS_DEFAULT_REGION` when no profile region is provided. Role ARNs,
+  ExternalIds, profile names, and regions are non-secret project metadata and belong in generated
+  artifacts or project docs, not in the skill's global guidance.
+- Allowlist: `*.amazonaws.com`, or narrower service hosts such as `sts.amazonaws.com`,
+  `logs.<region>.amazonaws.com`, `cloudwatch.<region>.amazonaws.com`,
+  `xray.<region>.amazonaws.com`, `ssm.<region>.amazonaws.com`, and service-specific endpoints the
+  repo uses.
+- Access: the bootstrap principal should have only `sts:AssumeRole` on the scoped operational role
+  ARNs, preferably guarded by an `ExternalId` condition. The assumed roles carry the real
+  permissions needed by the repo (CloudWatch Logs, deploy, SSM, etc.) as short-lived STS
+  credentials.
+- IAM Identity Center caveat: an IAM Identity Center permission set provisions an `AWSReservedSSO_*`
+  role whose trust allows the SSO service, not an arbitrary IAM principal. A headless IAM principal
+  cannot directly assume that reserved role. Use a separate assumable role that attaches the same
+  policy as the permission set, with the delegated Identity Center admin keeping that policy as the
+  source of truth.
+- Alternative: IAM Roles Anywhere (X.509 to STS) when long-lived bootstrap access keys are
+  unacceptable.
+
 ## Output
 
 Render the report grouped exactly as above. Start with one `Summary:` line, then a `Counts:` line
@@ -296,6 +354,15 @@ so the generator can render acquisition comments into its template:
     { "name": "jam", "transport": "http", "auth": "oauth", "headlessUsable": true, "replacedBy": "jam CLI + JAM_PAT", "dormant": true },
     { "name": "sonarqube", "transport": "stdio", "auth": "local-wrapper", "headlessUsable": true, "replacedBy": "SONAR_TOKEN + SonarCloud Web API", "dormant": true }
   ],
+  "awsProfiles": [
+    {
+      "name": "dev",
+      "roleArn": "arn:aws:iam::<account-id>:role/<role-name>",
+      "credentialSource": "Environment",
+      "externalId": "<project-external-id>",
+      "region": "us-east-1"
+    }
+  ],
   "gaps": [ "auto-memory not synced to cloud", "bun package fetch behind proxy", "OS keychain absent — env-var token form only" ],
   "platform": {
     "githubProxy": {
@@ -346,6 +413,9 @@ so the generator can render acquisition comments into its template:
   to environment editors; never imply the generated script can hide them.
 - A browser-OAuth MCP (or interactively-authed CLI) backing an active integration is a `GAP`; the
   remediation is its token substrate from the table, not "authenticate the MCP".
+- `aws sso login`, `sso_*` profile configuration, and project scripts that wrap AWS SSO are
+  interactive-auth paths. In a headless routine they are a `GAP`, not a setup step. Route AWS access
+  to env-var bootstrap credentials plus assume-role profiles.
 - For non-tracker MCPs, a documented CLI, PAT/API-key, or REST substrate converts the finding from
   a flat `GAP` into an `OPTIONAL` headless recovery path; unknown vendors remain gaps with a
   vendor-substrate follow-up, not invented credentials.