@codyswann/lisa 2.204.8 → 2.205.1

package/package.json

@@ -95,7 +95,7 @@
     "ws": ">=8.20.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.204.8",
+  "version": "2.205.1",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

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

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

package/plugins/lisa/rules/eager/upstream-to-lisa.md

@@ -1,15 +1,20 @@
 # Upstream To Lisa (load-bearing)
 
-When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project — a bug or gap in a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, or a governance pattern worth generalizing back to the templates. Tell-tale signs: the file you want to change is Lisa-managed (carries Lisa governance markers, or lives in a path Lisa owns), and any edit you make here would be **overwritten on the next `lisa apply`**.
+When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project — a bug or gap in a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, or a governance pattern worth generalizing back to the templates. The defining test: **does the root cause live in a Lisa-distributed artifact?** If yes, file upstream, regardless of whether your local fix survives the next `lisa apply`.
+
+Tell-tale signs include:
+
+- The file is Lisa-managed (carries Lisa governance markers, or lives in a path Lisa owns) and any edit you make here would be **overwritten on the next `lisa apply`**.
+- The file was created from a Lisa `create-only` template and carries language such as `Lisa will not overwrite it`. That header is a positive upstream signal: existing repos will keep their local copy, but every newly scaffolded repo still inherits the broken template until Lisa is fixed.
 
 When that happens, you have **two obligations — do both**:
 
-1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. Treat it as temporary: it will be clobbered when the upstream fix ships and Lisa re-applies. Do not wait on the upstream fix.
+1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. For copy-overwrite files, treat the local fix as temporary because it will be clobbered when the upstream fix ships and Lisa re-applies. For create-only files, keep the local fix because Lisa will not overwrite it, but still file upstream so new repos stop inheriting the bug.
 2. **File an upstream issue in the Lisa repository.** Use the `github-write-issue` skill (`lisa-github-write-issue`) to create an issue **in Lisa's source repo `CodySwannGT/lisa`** (pass it as the target repo, e.g. `gh ... --repo CodySwannGT/lisa`) — **not** in this project's own repo. Capture: the root cause, the symptom you hit here, and the proposed durable fix in Lisa's templates/rules/skills.
 
 ## Do not
 
-- Do **not** only fix it locally and move on — the local fix is throwaway; without the upstream issue the root cause is lost and re-breaks on the next apply.
+- Do **not** only fix it locally and move on — even when a create-only local fix survives, the broken template keeps shipping to every new repo until it is fixed upstream.
 - Do **not** try to edit Lisa's templates from inside this project — you are not in the Lisa repo; those edits don't exist upstream and get overwritten.
 - Do **not** file the issue in this project's repo — it must land in `CodySwannGT/lisa`.
 

package/plugins/lisa/rules/reference/upstream-to-lisa.md

@@ -9,14 +9,25 @@ You are working in a downstream/host project (not the Lisa source repo) and you
 - A bug or gap in a Lisa-distributed **template, rule, skill, agent, hook, or CI workflow**.
 - A **governance pattern** discovered here that should be generalized back into Lisa's templates so every project benefits.
 - Anything where the file you want to change is **Lisa-managed** — it carries Lisa governance markers, lives in a path Lisa owns, or any edit would be **overwritten on the next `lisa apply`**.
+- Anything where the root cause is in a Lisa **create-only** template, even if the generated file says Lisa will not overwrite it.
 
-The defining test: *if I fix this only here, does `lisa apply` wipe it out next time?* If yes, the root cause lives in Lisa and must be upstreamed.
+The defining test: **does the root cause live in a Lisa-distributed artifact?** If yes, file upstream. The wipe-out test is a sufficient signal, not the only signal.
+
+| Template class | Local fix survives `lisa apply`? | Why it is still upstream-worthy |
+| --- | --- | --- |
+| **copy-overwrite** (managed) | No — clobbered on next apply | The local fix is throwaway; without the upstream fix it re-breaks. |
+| **create-only** (first setup) | Yes — Lisa never overwrites it | No existing repo self-heals, and every newly scaffolded repo inherits the bug. |
+
+For create-only files, header text such as `Lisa will not overwrite it` is a **positive** upstream signal, not a reason to stay local. Keep the downstream fix because Lisa will not replace it, and still file upstream so future projects receive the corrected template.
 
 ## What to do — both steps, always
 
 ### 1. Fix it locally so you are not blocked
 
-Apply the stopgap in this project so you can keep working. Do **not** stall waiting for an upstream fix to land. Treat the local change as temporary — it will be clobbered when the upstream fix ships and Lisa re-applies. That is expected and fine; the upstream issue (step 2) is what makes it durable.
+Apply the stopgap in this project so you can keep working. Do **not** stall waiting for an upstream fix to land.
+
+- For copy-overwrite files, treat the local change as temporary: it will be clobbered when the upstream fix ships and Lisa re-applies.
+- For create-only files, keep the local change: Lisa will not overwrite it. The upstream issue is still mandatory because new projects keep inheriting the broken template until Lisa changes.
 
 ### 2. File an upstream issue in the Lisa repository
 
@@ -27,11 +38,11 @@ The issue should capture, following the skill's three-audience / acceptance-crit
 - **Root cause** — which Lisa template/rule/skill/agent/hook/workflow is wrong or missing, with the path under `plugins/src/...` (or the relevant template source) if known.
 - **Symptom** — what broke or was missing in *this* project, and how it surfaced. Reference this project so the fix can be validated against a real case.
 - **Proposed durable fix** — the change to make in Lisa's source so it propagates to all projects on the next apply.
-- **Local stopgap applied** — note that a temporary local fix is in place here, so the maintainer knows the host project is unblocked and the local change will be superseded.
+- **Local stopgap applied** — note that a local fix is in place here, whether it is temporary copy-overwrite work or a retained create-only patch.
 
 ## Do not
 
-- Do **not** only fix it locally and move on. The local fix is throwaway; without the upstream issue the root cause is lost and re-breaks for every project on the next apply.
+- Do **not** only fix it locally and move on. For copy-overwrite files, the local fix is throwaway and re-breaks on the next apply. For create-only files, the local fix survives, but the broken template still ships to every new project.
 - Do **not** edit Lisa's templates from inside this project. You are not in the Lisa repo; those edits don't exist upstream and get overwritten — they create the illusion of a fix while the real source stays broken.
 - Do **not** file the issue in this project's own repo. The durable fix is tracked in `CodySwannGT/lisa`.
 

package/plugins/lisa-agy/plugin.json

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.204.8",
+  "version": "2.205.1",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"
@@ -13,6 +13,7 @@
   "dependencies": [
     "lisa-typescript"
   ],
+  "skills": "./.codex-plugin/skills/",
   "interface": {
     "displayName": "Lisa CDK",
     "shortDescription": "AWS CDK workflows",

package/plugins/lisa-cdk/.codex-plugin/skills/lisa-setup-aws/SKILL.md

@@ -0,0 +1,13 @@
+---
+name: lisa-setup-aws
+description: "Provision the dev/staging/produc…"
+---
+## Lisa Command Compatibility
+
+- Original Claude command: `/lisa:setup:aws`
+- Codex invocation: `$lisa-setup-aws` or a plain-English request that matches this skill.
+- Treat the user's surrounding request as the command arguments.
+- Claude argument hint: `[management-profile] [region] [dry-run]`
+- Claude allowed tools: `Skill`. Codex tool access is governed by the active Codex runtime and project policy.
+
+Use the setup-aws-accounts skill (/lisa-cdk:setup-aws-accounts on harnesses with plugin commands; $setup-aws-accounts on Codex) to assess the AWS organization, run the aws-soc2-setup foundation and account vending, write the SSO profiles, cdk-bootstrap every account with cross-account trust, and wire the resulting account IDs into config/environments.ts, GitHub secrets, and .lisa.config.json. Use the user's surrounding request as this command's arguments.

package/plugins/lisa-cdk/.codex-plugin/skills/lisa-setup-aws/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Setup AWS"
+short_description: "Provision the dev/staging/produc…"
+default_prompt:
+  - "Use $lisa-setup-aws: Provision the dev/staging/produc…."

package/plugins/lisa-cdk/.codex-plugin/skills/setup-aws-accounts/SKILL.md

@@ -0,0 +1,292 @@
+---
+name: setup-aws-accounts
+description: "Provision the multi-account AWS…"
+allowed-tools: ["Bash", "Read", "Edit", "Write", "AskUserQuestion"]
+---
+
+# Setup AWS Accounts (SOC 2 Landing Zone)
+
+Provision and wire the AWS accounts a CDK project deploys into. The account
+supply side runs through the [`@codyswann/aws-soc2-setup`](https://www.npmjs.com/package/@codyswann/aws-soc2-setup)
+CLI (AWS Organizations, Control Tower, IAM Identity Center, security services,
+SOC 2 controls); the demand side — profiles, `cdk bootstrap`, config files, CI
+secrets — is wired by this skill so the project goes from `PLACEHOLDER` account
+IDs to deployable in one flow.
+
+## When to use
+
+- A CDK project's `config/environments.ts` still has `accountId: "PLACEHOLDER"`
+  entries, so `cdk deploy` silently skips those environments.
+- The user asks to "create the AWS accounts", "set up dev/staging/production
+  accounts", "bootstrap AWS for this project", or similar.
+- `scripts/pre-deployment-checklist.sh` fails because `<prefix>-<env>` AWS
+  profiles don't exist or don't authenticate.
+- A fresh organization needs the SOC 2 foundation (Control Tower, guardrails,
+  security services) before workload accounts are vended.
+
+Not for: deploying stacks (that's `cdk deploy` / CI), or GitHub repo governance
+(that's `lisa-setup-github-repo`).
+
+## How the CLI behaves (read before scripting it)
+
+- Invoke as `npx -y @codyswann/aws-soc2-setup@1 <command>`. Pin at least the
+  major version — an unpinned `npx` pull is a supply-chain risk for a tool that
+  runs with management-account credentials. Always set `NO_COLOR=1` so output
+  parses cleanly.
+- It is an **actuator, not an API** — no `--json` output. Drive it for side
+  effects, then read authoritative state back with the plain `aws` CLI
+  (`aws organizations list-accounts`, `aws sts get-caller-identity`). Never
+  trust scraped text alone for account IDs.
+- It is idempotent per resource (ensure-semantics against live AWS), so
+  re-running `setup` is safe — **except** `controltower provision-account`,
+  which is not deduped by name. Always check `aws organizations list-accounts`
+  before provisioning and skip accounts that already exist.
+- `--dry-run` previews every mutating command; `status` and `whoami` are
+  read-only.
+- `controltower provision-account -o` takes the OU **name** (e.g. `Workloads`);
+  `register-ou` and `enable-controls` take the OU **id/ARN**. Don't mix them up.
+
+## Step 1 — Assess the environment (read-only)
+
+```bash
+NO_COLOR=1 npx -y @codyswann/aws-soc2-setup@1 whoami -p <management-profile> -r <region>
+NO_COLOR=1 npx -y @codyswann/aws-soc2-setup@1 status -p <management-profile> -r <region>
+```
+
+`status` reports five independent checks: credentials, Organizations,
+recommended OUs, IAM Identity Center, member accounts.
+
+**The human gate.** Three prerequisites are console-only and must never be
+automated. If `status` shows Identity Center or the landing zone missing, stop
+and present this checklist in plain language a non-technical operator can
+follow, then end the run:
+
+1. Sign in to the AWS console as the account **root** user and enable MFA on
+   the root account.
+2. In the console, enable **IAM Identity Center** (in your home region).
+3. In the console, create the **AWS Control Tower landing zone** (this creates
+   the Audit and Log Archive accounts; takes ~30–60 minutes).
+4. Configure a management-account admin profile locally:
+   `aws configure sso` (interactive).
+
+Re-run this skill after those are done — Step 1 will pass and the flow
+continues from wherever it left off.
+
+## Step 2 — Gather inputs
+
+Collect (via arguments if provided, `AskUserQuestion` otherwise; use stated
+defaults when running unattended):
+
+| Input | Default | Notes |
+| --- | --- | --- |
+| Management profile | `AWS_PROFILE` | Must be the org management account |
+| Region | `us-east-1` | Match the project's `config/environments.ts` |
+| Profile prefix | project name from `package.json` | Matches `AWS_PROFILE_PREFIX` used by `scripts/pre-deployment-checklist.sh` |
+| Environments | `dev`, `staging`, `production`, `shared` | `shared` hosts the pipeline and gets cross-account trust |
+| Root email pattern | ask — no safe default | Each account needs a **unique** root email; suggest plus-addressing: `aws+<prefix>-<env>@<domain>` |
+| Identity Center username | ask — no safe default | The Identity Store user that gets `AWSAdministratorAccess` on each new account in Step 5; verify it exists (create with `sso create-user` if not) |
+| Identity Center start URL | from `status` output or the console | The **full** `sso_start_url` for the `sso-session` block in Step 5 (default form `https://<domain>.awsapps.com/start`, but custom domains differ — never reconstruct it from parts) |
+
+## Step 3 — Foundation (org, OUs, controls, security services)
+
+Show the plan, get explicit approval, then apply:
+
+```bash
+NO_COLOR=1 npx -y @codyswann/aws-soc2-setup@1 setup --dry-run -p <mgmt> -r <region>
+```
+
+Present the dry-run output and **stop for confirmation** before mutating the
+organization — `AskUserQuestion` when interactive, or an unambiguous
+apply/confirm argument from the caller when running unattended. Silence is not
+approval. Only then:
+
+```bash
+NO_COLOR=1 npx -y @codyswann/aws-soc2-setup@1 setup -p <mgmt> -r <region> \
+  [--ou <workloads-ou-id>] [--central-account <id>] [--admin-account <id>] [--audit-account <id>]
+```
+
+This ensures the organization, creates the Infrastructure/Workloads/Sandbox
+OUs, enables the security services (GuardDuty, Security Hub, Config, …),
+conformance packs, and — when `--ou` is passed — registers the OU with Control
+Tower and enables the SOC 2 control baseline. Safe to re-run.
+
+## Step 4 — Vend the workload accounts
+
+For each environment, **first** check it doesn't already exist:
+
+```bash
+aws organizations list-accounts --profile <mgmt> \
+  --query "Accounts[?Name=='<prefix>-<env>'].{Id:Id,Name:Name,State:State}" --output table
+```
+
+(Use `State`, not `Status` — AWS is retiring the `Status` field in favor of
+`State`.)
+
+Then provision the missing ones, one at a time, each with a unique root email.
+Stage accounts go into the `Workloads` OU:
+
+```bash
+NO_COLOR=1 npx -y @codyswann/aws-soc2-setup@1 controltower provision-account \
+  -p <mgmt> -r <region> \
+  -n <prefix>-<env> -e aws+<prefix>-<env>@<domain> -o Workloads --wait
+```
+
+The `shared` (pipeline) account goes into `Infrastructure` instead:
+
+```bash
+NO_COLOR=1 npx -y @codyswann/aws-soc2-setup@1 controltower provision-account \
+  -p <mgmt> -r <region> \
+  -n <prefix>-shared -e aws+<prefix>-shared@<domain> -o Infrastructure --wait
+```
+
+`--wait` polls Account Factory (~minutes per account) and prints
+`New account ID: <id>`. After all accounts finish, harvest the authoritative
+env → account-ID map from `aws organizations list-accounts` — that map drives
+every later step.
+
+## Step 5 — Identity Center access + local AWS profiles
+
+Grant the operator admin on each new account, using the Identity Center
+username collected in Step 2:
+
+```bash
+NO_COLOR=1 npx -y @codyswann/aws-soc2-setup@1 sso assign \
+  -p <mgmt> -u <username> -a <account-id> -r AWSAdministratorAccess
+```
+
+(or `sso group -g <prefix>-admins --all-users -a <account-id> -r AWSAdministratorAccess`
+for group-based access. If the user doesn't exist yet, create it first with
+`sso create-user`.)
+
+The CLI does **not** generate AWS CLI profiles — write them yourself. Append to
+`~/.aws/config` (never overwrite existing sections; skip blocks that already
+exist):
+
+```ini
+[sso-session <prefix>]
+sso_start_url = <start-url>
+sso_region = <region>
+sso_registration_scopes = sso:account:access
+
+[profile <prefix>-dev]
+sso_session = <prefix>
+sso_account_id = <dev-account-id>
+sso_role_name = AWSAdministratorAccess
+region = <region>
+```
+
+`<start-url>` is the full Identity Center start URL collected in Step 2 —
+paste it verbatim, never rebuild it from a domain fragment. One
+`[profile <prefix>-<env>]` block per environment — this exact naming is
+what `scripts/pre-deployment-checklist.sh` and the db-connect scripts resolve.
+Then authenticate and verify every profile maps to the expected account:
+
+```bash
+aws sso login --sso-session <prefix>
+for env in dev staging production shared; do
+  aws sts get-caller-identity --profile <prefix>-$env --query Account --output text
+done
+```
+
+## Step 6 — CDK bootstrap with pipeline trust
+
+Bootstrap the shared (pipeline) account first, then each stage account with
+trust back to shared. Honor the project's `CDK_BOOTSTRAP_QUALIFIER` and
+`CDK_BOOTSTRAP_EXECUTION_POLICY_ARN` env vars rather than hardcoding their
+defaults (`config/env.ts` defaults: `hnb659fds` /
+`arn:aws:iam::aws:policy/AdministratorAccess`):
+
+```bash
+qualifier="${CDK_BOOTSTRAP_QUALIFIER:-hnb659fds}"
+exec_policy="${CDK_BOOTSTRAP_EXECUTION_POLICY_ARN:-arn:aws:iam::aws:policy/AdministratorAccess}"
+
+npx cdk bootstrap aws://<shared-id>/<region> --profile <prefix>-shared \
+  --qualifier "$qualifier"
+
+for env in dev staging production; do
+  npx cdk bootstrap aws://<env-id>/<region> --profile <prefix>-$env \
+    --qualifier "$qualifier" \
+    --trust <shared-id> \
+    --cloudformation-execution-policies "$exec_policy"
+done
+```
+
+The `--trust` flag is the manual chicken-and-egg step the project's
+`trust-policy-stack` documents as CfnOutputs — this skill is where it actually
+runs.
+
+## Step 7 — Wire the project
+
+1. **`config/environments.ts`** (when the project has it): replace each
+   environment's `accountId: "PLACEHOLDER"` with the real 12-digit ID from the
+   Step 4 map, and confirm `region` matches. This single edit is what flips
+   each environment from synth-only to deployable. If the project uses a
+   different layout, skip with a note — the `.lisa.config.json` record below
+   still applies.
+2. **GitHub secrets** — only when `.github/workflows/ci.yml` references them:
+   ```bash
+   gh secret set AWS_ACCOUNT_ID_DEV --body "<dev-id>"
+   gh secret set AWS_ACCOUNT_ID_STAGING --body "<staging-id>"
+   gh secret set AWS_ACCOUNT_ID_PRODUCTION --body "<production-id>"
+   gh secret set AWS_INFRA_ACCOUNT_ID --body "<shared-id>"
+   ```
+3. **`.lisa.config.json`** — record the machine-readable account map (merge
+   with `jq`, preserving every other key):
+   ```json
+   {
+     "aws": {
+       "region": "<region>",
+       "profilePrefix": "<prefix>",
+       "accounts": {
+         "dev": "<dev-id>",
+         "staging": "<staging-id>",
+         "production": "<production-id>",
+         "shared": "<shared-id>"
+       }
+     }
+   }
+   ```
+
+## Step 8 — Verify and report
+
+- Every `<prefix>-<env>` profile authenticates to its expected account ID
+  (`aws sts get-caller-identity`).
+- `scripts/pre-deployment-checklist.sh` passes when the project ships it.
+- `npx cdk synth` succeeds and no environment is skipped as non-deployable.
+- Report a table: environment → account ID → profile → bootstrapped (yes/no).
+- Name what remains manual, in operator-readable language — e.g. the GitHub
+  CodeConnections handshake for pipeline mode (`config/github.ts`
+  `codeConnectionArn`) is an interactive console step outside this skill's
+  scope, and hardening extras (`root remove-access`, `scp deny-iam-users`,
+  `scp alert-management`) are offered but require explicit confirmation since
+  they are org-wide and destructive.
+
+## Cross-agent invocation
+
+The same SKILL.md ships to every supported runtime via the plugin build; all
+logic lives here, never in the command shim.
+
+- Claude Code / OpenCode / Cursor: `/lisa-cdk:setup:aws` command, or invoke the
+  skill directly.
+- Codex (no slash commands): `$setup-aws-accounts` (the command shim also
+  installs as `$lisa-setup-aws`).
+- agy / Copilot: the skill is delivered through the generated plugin variants;
+  invoke it by name.
+
+## Rules
+
+- **Never automate the console-only steps** (root MFA, enabling Identity
+  Center, landing zone creation). Present the checklist, stop, and let a human
+  do them. Every blocked reason must be readable by a non-technical operator.
+- Always `--dry-run` (or `status`) first and show the plan before mutating an
+  organization. `root` and `scp` subcommands are destructive org-wide — never
+  run them without explicit user confirmation in this session.
+- Check before create: `list-accounts` before `provision-account`; read
+  `~/.aws/config` before appending profile blocks; never clobber existing
+  profiles or config keys.
+- Harvest account IDs from `aws organizations list-accounts`, not from scraped
+  CLI text.
+- Never write credentials or secrets into the repository. Account IDs are not
+  secret and belong in config; keys and tokens never do.
+- Do not stage or modify unrelated working-tree files; the only repo edits are
+  `config/environments.ts` and `.lisa.config.json`.

package/plugins/lisa-cdk/.codex-plugin/skills/setup-aws-accounts/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Setup AWS Accounts"
+short_description: "Provision the multi-account AWS…"
+default_prompt:
+  - "Use $setup-aws-accounts: Provision the multi-account AWS…."

package/plugins/lisa-cdk/commands/setup/aws.md

@@ -0,0 +1,7 @@
+---
+description: "Provision the dev/staging/production/shared AWS accounts this CDK project deploys into via the @codyswann/aws-soc2-setup CLI (Organizations, Control Tower, IAM Identity Center, SOC 2 controls), then wire them in end-to-end: SSO profiles, cdk bootstrap with pipeline trust, PLACEHOLDER account IDs in config/environments.ts, AWS_ACCOUNT_ID_* GitHub secrets, and the .lisa.config.json account map. Idempotent; console-only prerequisites (root MFA, Identity Center, landing zone) surface as a human checklist instead of being automated."
+allowed-tools: ["Skill"]
+argument-hint: "[management-profile] [region] [dry-run]"
+---
+
+Use the setup-aws-accounts skill (/lisa-cdk:setup-aws-accounts on harnesses with plugin commands; $setup-aws-accounts on Codex) to assess the AWS organization, run the aws-soc2-setup foundation and account vending, write the SSO profiles, cdk-bootstrap every account with cross-account trust, and wire the resulting account IDs into config/environments.ts, GitHub secrets, and .lisa.config.json. $ARGUMENTS