@codyswann/lisa 2.332.4 → 2.333.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (77) hide show
  1. package/all/copy-overwrite/scripts/lisa-hooks/block-no-verify.sh +27 -4
  2. package/dist/core/upstream-evidence-manifest.d.ts.map +1 -1
  3. package/dist/core/upstream-evidence-manifest.js +8 -5
  4. package/dist/core/upstream-evidence-manifest.js.map +1 -1
  5. package/package.json +1 -1
  6. package/plugins/lisa/.claude-plugin/plugin.json +1 -1
  7. package/plugins/lisa/.codex-plugin/plugin.json +1 -1
  8. package/plugins/lisa/.codex-plugin/skills/lisa-drive-pr-to-merge/SKILL.md +53 -18
  9. package/plugins/lisa/.codex-plugin/skills/lisa-secrets-access/scripts/aws-bootstrap.mjs +154 -9
  10. package/plugins/lisa/.codex-plugin/skills/lisa-secrets-access/scripts/materialize-secrets.mjs +93 -2
  11. package/plugins/lisa/hooks/block-no-verify.sh +27 -4
  12. package/plugins/lisa/skills/lisa-drive-pr-to-merge/SKILL.md +53 -18
  13. package/plugins/lisa/skills/lisa-secrets-access/scripts/aws-bootstrap.mjs +154 -9
  14. package/plugins/lisa/skills/lisa-secrets-access/scripts/materialize-secrets.mjs +93 -2
  15. package/plugins/lisa-agy/plugin.json +1 -1
  16. package/plugins/lisa-agy/skills/lisa-drive-pr-to-merge/SKILL.md +53 -18
  17. package/plugins/lisa-agy/skills/lisa-secrets-access/scripts/aws-bootstrap.mjs +154 -9
  18. package/plugins/lisa-agy/skills/lisa-secrets-access/scripts/materialize-secrets.mjs +93 -2
  19. package/plugins/lisa-cdk/.claude-plugin/plugin.json +1 -1
  20. package/plugins/lisa-cdk/.codex-plugin/plugin.json +1 -1
  21. package/plugins/lisa-cdk-agy/plugin.json +1 -1
  22. package/plugins/lisa-cdk-copilot/.claude-plugin/plugin.json +1 -1
  23. package/plugins/lisa-cdk-cursor/.claude-plugin/plugin.json +1 -1
  24. package/plugins/lisa-copilot/.claude-plugin/plugin.json +1 -1
  25. package/plugins/lisa-copilot/hooks/block-no-verify.sh +27 -4
  26. package/plugins/lisa-copilot/skills/lisa-drive-pr-to-merge/SKILL.md +53 -18
  27. package/plugins/lisa-copilot/skills/lisa-secrets-access/scripts/aws-bootstrap.mjs +154 -9
  28. package/plugins/lisa-copilot/skills/lisa-secrets-access/scripts/materialize-secrets.mjs +93 -2
  29. package/plugins/lisa-cursor/.claude-plugin/plugin.json +1 -1
  30. package/plugins/lisa-cursor/hooks/block-no-verify.sh +27 -4
  31. package/plugins/lisa-cursor/skills/lisa-drive-pr-to-merge/SKILL.md +53 -18
  32. package/plugins/lisa-cursor/skills/lisa-secrets-access/scripts/aws-bootstrap.mjs +154 -9
  33. package/plugins/lisa-cursor/skills/lisa-secrets-access/scripts/materialize-secrets.mjs +93 -2
  34. package/plugins/lisa-expo/.claude-plugin/plugin.json +1 -1
  35. package/plugins/lisa-expo/.codex-plugin/plugin.json +1 -1
  36. package/plugins/lisa-expo-agy/plugin.json +1 -1
  37. package/plugins/lisa-expo-copilot/.claude-plugin/plugin.json +1 -1
  38. package/plugins/lisa-expo-cursor/.claude-plugin/plugin.json +1 -1
  39. package/plugins/lisa-harper-fabric/.claude-plugin/plugin.json +1 -1
  40. package/plugins/lisa-harper-fabric/.codex-plugin/plugin.json +1 -1
  41. package/plugins/lisa-harper-fabric-agy/plugin.json +1 -1
  42. package/plugins/lisa-harper-fabric-copilot/.claude-plugin/plugin.json +1 -1
  43. package/plugins/lisa-harper-fabric-cursor/.claude-plugin/plugin.json +1 -1
  44. package/plugins/lisa-nestjs/.claude-plugin/plugin.json +1 -1
  45. package/plugins/lisa-nestjs/.codex-plugin/plugin.json +1 -1
  46. package/plugins/lisa-nestjs-agy/plugin.json +1 -1
  47. package/plugins/lisa-nestjs-copilot/.claude-plugin/plugin.json +1 -1
  48. package/plugins/lisa-nestjs-cursor/.claude-plugin/plugin.json +1 -1
  49. package/plugins/lisa-openclaw/.claude-plugin/plugin.json +1 -1
  50. package/plugins/lisa-openclaw/.codex-plugin/plugin.json +1 -1
  51. package/plugins/lisa-openclaw-agy/plugin.json +1 -1
  52. package/plugins/lisa-openclaw-copilot/.claude-plugin/plugin.json +1 -1
  53. package/plugins/lisa-openclaw-cursor/.claude-plugin/plugin.json +1 -1
  54. package/plugins/lisa-phaser/.claude-plugin/plugin.json +1 -1
  55. package/plugins/lisa-phaser/.codex-plugin/plugin.json +1 -1
  56. package/plugins/lisa-phaser-agy/plugin.json +1 -1
  57. package/plugins/lisa-phaser-copilot/.claude-plugin/plugin.json +1 -1
  58. package/plugins/lisa-phaser-cursor/.claude-plugin/plugin.json +1 -1
  59. package/plugins/lisa-rails/.claude-plugin/plugin.json +1 -1
  60. package/plugins/lisa-rails/.codex-plugin/plugin.json +1 -1
  61. package/plugins/lisa-rails-agy/plugin.json +1 -1
  62. package/plugins/lisa-rails-copilot/.claude-plugin/plugin.json +1 -1
  63. package/plugins/lisa-rails-cursor/.claude-plugin/plugin.json +1 -1
  64. package/plugins/lisa-typescript/.claude-plugin/plugin.json +1 -1
  65. package/plugins/lisa-typescript/.codex-plugin/plugin.json +1 -1
  66. package/plugins/lisa-typescript-agy/plugin.json +1 -1
  67. package/plugins/lisa-typescript-copilot/.claude-plugin/plugin.json +1 -1
  68. package/plugins/lisa-typescript-cursor/.claude-plugin/plugin.json +1 -1
  69. package/plugins/lisa-wiki/.claude-plugin/plugin.json +1 -1
  70. package/plugins/lisa-wiki/.codex-plugin/plugin.json +1 -1
  71. package/plugins/lisa-wiki-agy/plugin.json +1 -1
  72. package/plugins/lisa-wiki-copilot/.claude-plugin/plugin.json +1 -1
  73. package/plugins/lisa-wiki-cursor/.claude-plugin/plugin.json +1 -1
  74. package/plugins/src/base/hooks/block-no-verify.sh +27 -4
  75. package/plugins/src/base/skills/lisa-drive-pr-to-merge/SKILL.md +53 -18
  76. package/plugins/src/base/skills/lisa-secrets-access/scripts/aws-bootstrap.mjs +154 -9
  77. package/plugins/src/base/skills/lisa-secrets-access/scripts/materialize-secrets.mjs +93 -2
@@ -31,7 +31,12 @@ import {
31
31
  import { homedir } from "node:os";
32
32
  import { join } from "node:path";
33
33
 
34
- import { deriveAwsEnvironment } from "./aws-bootstrap.mjs";
34
+ import {
35
+ BOOTSTRAP_KEY,
36
+ deriveAwsEnvironment,
37
+ parseBootstrap,
38
+ renderAwsProfiles,
39
+ } from "./aws-bootstrap.mjs";
35
40
  import { renderEnv, renderNotes } from "./envfile.mjs";
36
41
  import { fetchAll } from "./providers.mjs";
37
42
  import { materializedPaths, readConfig } from "./surfaces.mjs";
@@ -68,6 +73,15 @@ const PROFILE_MARKER = "# >>> lisa secrets (managed) >>>";
68
73
  /** Closes the managed block. */
69
74
  const PROFILE_END = "# <<< lisa secrets (managed) <<<";
70
75
 
76
+ /**
77
+ * Identifies an `~/.aws` file as one this wrote, and may therefore replace.
78
+ *
79
+ * `#` is a comment in the AWS shared-config format, so this is inert to every
80
+ * consumer while still being the thing that distinguishes "our file, refresh
81
+ * it" from "someone else's file, leave it alone".
82
+ */
83
+ const MANAGED_MARKER = "# managed by lisa-secrets-access";
84
+
71
85
  /**
72
86
  * Make every shell in this container load the materialized secrets.
73
87
  *
@@ -95,6 +109,14 @@ export function installProfileSourcing(valuesFile, options = {}) {
95
109
 
96
110
  const block = [
97
111
  PROFILE_MARKER,
112
+ // Unset BEFORE sourcing. A cloud container injects its own AWS key pair,
113
+ // and environment credentials outrank both ~/.aws profiles and AWS_PROFILE
114
+ // — so leaving them set means the session ignores whichever environment it
115
+ // selected and runs as whatever the host injected. That is how a perfectly
116
+ // valid credential produced InvalidClientTokenId for a day. Removing the
117
+ // poison beats out-shouting it, and it is what lets `--profile agent-dev`
118
+ // behave here exactly as it does on a developer's machine.
119
+ `unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN`,
98
120
  `if [ -f "${valuesFile}" ]; then`,
99
121
  ` set -a`,
100
122
  ` . "${valuesFile}"`,
@@ -126,6 +148,61 @@ export function installProfileSourcing(valuesFile, options = {}) {
126
148
  return updated;
127
149
  }
128
150
 
151
+ /**
152
+ * Write `~/.aws/credentials` and `~/.aws/config` from the bootstrap bundle.
153
+ *
154
+ * Both at 0600 inside a 0700 directory, matching how the materialized secrets
155
+ * themselves are protected — the credentials file holds the source key pair.
156
+ * @param {object|null} bundle Parsed bootstrap bundle.
157
+ * @param {object} [options] Home directory and file seams, for tests.
158
+ * @returns {string[]} The profile names written.
159
+ */
160
+ export function installAwsProfiles(bundle, options = {}) {
161
+ const {
162
+ home = process.env.HOME || homedir(),
163
+ mkdir = mkdirSync,
164
+ write = writeFileSync,
165
+ read = readFileSync,
166
+ exists = existsSync,
167
+ chmod = chmodSync,
168
+ } = options;
169
+
170
+ const rendered = renderAwsProfiles(bundle);
171
+ if (!rendered) return [];
172
+
173
+ const dir = join(home, ".aws");
174
+
175
+ // Never overwrite an ~/.aws this did not write.
176
+ //
177
+ // These are whole-file writes, so a pre-existing credentials file — a
178
+ // developer's own profiles, or something another tool set up — would be
179
+ // destroyed rather than merged. This only runs on a surface allowed to write
180
+ // secrets to disk (a disposable container), but "usually disposable" is not a
181
+ // reason to be able to delete someone's credentials. The marker makes our own
182
+ // file re-writable while anything else is left alone and reported.
183
+ for (const name of ["credentials", "config"]) {
184
+ const file = join(dir, name);
185
+ if (exists(file) && !String(read(file, "utf8")).includes(MANAGED_MARKER)) {
186
+ return [];
187
+ }
188
+ }
189
+
190
+ mkdir(dir, { recursive: true, mode: 0o700 });
191
+ chmod(dir, 0o700);
192
+ write(
193
+ join(dir, "credentials"),
194
+ `${MANAGED_MARKER}\n${rendered.credentials}`,
195
+ {
196
+ mode: 0o600,
197
+ }
198
+ );
199
+ write(join(dir, "config"), `${MANAGED_MARKER}\n${rendered.config}`, {
200
+ mode: 0o600,
201
+ });
202
+
203
+ return rendered.profiles;
204
+ }
205
+
129
206
  export function materialize(cfg = readConfig()) {
130
207
  if (!cfg.capabilities.mayWriteValues) {
131
208
  throw new Error(
@@ -170,7 +247,21 @@ export function materialize(cfg = readConfig()) {
170
247
  // materialized" and "the credential is usable" the same statement.
171
248
  const sourced = installProfileSourcing(valuesFile);
172
249
 
173
- return { count: selected.size, derived: derived.size, dir, sourced };
250
+ // The environments live in separate AWS accounts, reached by assuming a role
251
+ // per environment. Without these files `--profile agent-dev` fails with
252
+ // "profile not found" and everything silently falls back to the bootstrap
253
+ // identity, which can assume roles and do nothing else.
254
+ const profiles = installAwsProfiles(
255
+ parseBootstrap(selected.get(BOOTSTRAP_KEY)?.value)
256
+ );
257
+
258
+ return {
259
+ count: selected.size,
260
+ derived: derived.size,
261
+ dir,
262
+ sourced,
263
+ profiles,
264
+ };
174
265
  }
175
266
 
176
267
  function main() {
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-cdk",
3
- "version": "2.332.4",
3
+ "version": "2.333.0",
4
4
  "description": "AWS CDK-specific plugin",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-cdk",
3
- "version": "2.332.4",
3
+ "version": "2.333.0",
4
4
  "description": "AWS CDK-specific Lisa plugin.",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-cdk",
3
- "version": "2.332.4",
3
+ "version": "2.333.0",
4
4
  "description": "AWS CDK-specific plugin",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-cdk",
3
- "version": "2.332.4",
3
+ "version": "2.333.0",
4
4
  "description": "AWS CDK-specific plugin",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa-cdk",
3
- "version": "2.332.4",
3
+ "version": "2.333.0",
4
4
  "description": "AWS CDK-specific plugin",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa",
3
- "version": "2.332.4",
3
+ "version": "2.333.0",
4
4
  "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
5
5
  "author": {
6
6
  "name": "Cody Swann"
@@ -20,18 +20,41 @@ set -euo pipefail
20
20
 
21
21
  input="$(cat)"
22
22
 
23
- tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty')"
23
+ # Both interpreters must be probed BEFORE they are used, and a missing one must
24
+ # be announced rather than swallowed.
25
+ #
26
+ # `jq` used to be called unguarded here while `python3` two lines below was
27
+ # guarded. Under `set -e` an absent jq aborted the script with 127, and Claude
28
+ # Code treats any non-2 exit as a NON-BLOCKING hook error — so the hook that
29
+ # enforces "never --no-verify" silently permitted the very thing it exists to
30
+ # stop. It was not hypothetical: agent containers routinely ship no jq (that is
31
+ # why jq is now a pinned toolchain entry). The Codex variant of this script has
32
+ # always had the guard, so this was a parity gap rather than a design choice.
33
+ #
34
+ # Degrading to "allow" is still the right behaviour — a hook that cannot parse
35
+ # its input cannot tell a bypass from an ordinary command, and failing closed
36
+ # would block every Bash call on a machine missing an interpreter. What is NOT
37
+ # right is doing it quietly, so the operator gets one line on stderr saying the
38
+ # protection is off. A guard that is silently absent reads exactly like a guard
39
+ # that is passing.
40
+ for required in jq python3; do
41
+ if ! command -v "$required" >/dev/null 2>&1; then
42
+ printf 'block-no-verify: %s not found; --no-verify protection is NOT active\n' \
43
+ "$required" >&2
44
+ exit 0
45
+ fi
46
+ done
47
+
48
+ tool_name="$(printf '%s' "$input" | jq -r '.tool_name // empty' 2>/dev/null || true)"
24
49
  if [ "$tool_name" != "Bash" ]; then
25
50
  exit 0
26
51
  fi
27
52
 
28
- command_str="$(printf '%s' "$input" | jq -r '.tool_input.command // empty')"
53
+ command_str="$(printf '%s' "$input" | jq -r '.tool_input.command // empty' 2>/dev/null || true)"
29
54
  if [ -z "$command_str" ]; then
30
55
  exit 0
31
56
  fi
32
57
 
33
- command -v python3 >/dev/null 2>&1 || exit 0
34
-
35
58
  if ! BLOCK_NO_VERIFY_COMMAND="$command_str" python3 - <<'PY'
36
59
  import os
37
60
  import re
@@ -126,13 +126,50 @@ auto-merge against a stale head you have not verified.
126
126
  `gh pr merge <pr> --auto --<merge_method>`. Enabling auto-merge is **not terminal**
127
127
  — continue the loop below until the PR is actually `MERGED` or `CLOSED`.
128
128
 
129
- If any later step will push commits, temporarily remove the auto-merge latch
130
- before the push when GitHub exposes that mutation (`disablePullRequestAutoMerge`),
131
- or otherwise treat the push as a merge race: immediately re-read `headRefOid`,
132
- reset `verify_commit` to the pushed head, wait until that head's checks have
133
- started, then re-enable auto-merge. Do not leave auto-merge armed while a
134
- required fix, CodeRabbit follow-up, generated artifact update, or CI auto-fix is
135
- still in flight.
129
+ **With `auto_merge=true`, leave the latch ARMED never disable auto-merge.**
130
+ (Under `auto_merge=false` the deliberate disarm above still applies: that mode
131
+ must leave the PR open for a human, so a pre-existing latch is removed on
132
+ purpose. Everything below is the `auto_merge=true` path.)
133
+
134
+ Once a fix is PUSHED the latch is safe: GitHub evaluates required checks against
135
+ the PR's current head, so a new commit whose checks have not reported leaves the
136
+ PR blocked. Auto-merge cannot ship a commit nothing has verified.
137
+
138
+ The only window a disarm ever protected is the gap between deciding to fix
139
+ something and that fix landing — during which the PR is genuinely green and
140
+ genuinely mergeable, and auto-merge firing is GitHub behaving correctly. Two
141
+ merges in this repo's history are attributed to that window (#1392, and the
142
+ release that shipped the `./hooks/` Cursor bug). Both were fixed forward within
143
+ minutes; one was a one-line docs inconsistency.
144
+
145
+ That evidence is also weaker than it looks: **auto-merge attributes the merge to
146
+ whoever enabled it**, so an auto-merge and a human pressing Merge are
147
+ indistinguishable in the timeline. The record cannot tell us those PRs were not
148
+ simply merged by hand while the latch happened to be armed.
149
+
150
+ Against that, disarming costs something certain. Disabling is a durable state
151
+ change on GitHub; re-enabling is one more step the run has to reach. When a run
152
+ ends in between — turns exhausted, job timeout, or you concluding the work while
153
+ checks are still pending — the latch stays off and nothing restores it. The PR is
154
+ left WORSE OFF THAN IF THIS SKILL HAD NEVER RUN: it has lost the mechanism that
155
+ merges it while no agent is watching, and the run reports success. Measured on
156
+ `gunnertech/frontend#282`, the latch went off 14s before the fix commit and the
157
+ PR sat 26 minutes after going green, against ~3 minutes for PRs this skill never
158
+ touched.
159
+
160
+ So the trade is a rare, unproven miss that costs a fix-forward PR, against a
161
+ frequent, silent stall on every PR this skill repairs. Take the rare one.
162
+
163
+ What still applies on a push: immediately re-read `headRefOid` and reset
164
+ `verify_commit` to the pushed head, so the shipped-verification in step 3 checks
165
+ what you actually pushed rather than the commit you replaced. That ancestry check
166
+ is what CATCHES a raced merge — it fails loudly when the fix SHA is not an
167
+ ancestor of the base branch — so the rare miss is detected rather than silent.
168
+
169
+ **Invariant:** never terminate having left auto-merge OFF on an open PR when
170
+ `auto_merge=true`. If some future path does disable it, restoring it is a
171
+ terminal obligation on EVERY exit — including give-up, budget-exhausted and error
172
+ paths — not a later step in a sequence.
136
173
 
137
174
  - **Capability fallback** (`auto_merge=true` only): if the repo disallows
138
175
  auto-merge, do not fail. Keep watching; once checks are green, the review gate
@@ -215,10 +252,9 @@ registered you will instead see real conflict markers — run
215
252
  ### c. Failing CI / deploy checks (`statusCheckRollup` has FAILURE)
216
253
  Inspect the failing check's logs (`gh pr checks <pr>`, `gh run view <run> --log-failed`).
217
254
  Fix the underlying code inline — **never lower thresholds, skip tests, or disable
218
- checks** to force green. Before pushing the fix, disarm auto-merge or classify the
219
- run as race-prone, then after the push re-read the PR head, update `verify_commit`
220
- to that exact SHA, wait for checks on that head to start, and only then resume
221
- auto-merge. When the root cause is an upstream Lisa template/postinstall bug
255
+ checks** to force green. Leave auto-merge armed across the push (section 1);
256
+ after it, re-read the PR head and update `verify_commit` to that exact SHA so the
257
+ shipped-verification checks what you pushed. When the root cause is an upstream Lisa template/postinstall bug
222
258
  rather than this project's code, fix it upstream and propagate down rather than
223
259
  patching only here.
224
260
 
@@ -227,10 +263,9 @@ Delegate to the `pull-request-review` skill with the PR number. It owns the whol
227
263
  comment cycle: fetch every unresolved human + bot thread (with resolution state via
228
264
  GraphQL), implement valid feedback (commit + push), reply to invalid feedback, and
229
265
  resolve every thread via `resolveReviewThread` so the branch-protection
230
- thread-resolution gate clears. If that skill needs to push a commit, auto-merge
231
- must be disabled first when possible; when it returns, re-read `headRefOid`, reset
232
- `verify_commit` to the returned/pushed head, wait for that head's checks to start,
233
- then re-enable auto-merge and continue. Do not re-implement review handling here
266
+ thread-resolution gate clears. If that skill needs to push a commit, leave
267
+ auto-merge armed (section 1); when it returns, re-read `headRefOid` and reset
268
+ `verify_commit` to the returned/pushed head, then continue. Do not re-implement review handling here
234
269
  — it is the single source of truth for review-thread handling.
235
270
 
236
271
  ### e. Review gate stall (`reviewDecision == CHANGES_REQUESTED`)
@@ -252,9 +287,9 @@ branch (the CI auto-fix workflow engaged before this session took the lease),
252
287
  adjudicate it: merge it into the head branch if the fix is correct and still
253
288
  needed, otherwise close it and delete the side branch. Never leave it dangling
254
289
  — it represents a competing writer's pending work. Merging it mutates the
255
- driven branch, so treat it like any other push: disarm auto-merge first,
256
- re-read `headRefOid`, reset `verify_commit` to the merged head, wait for that
257
- head's checks to start, then re-enable auto-merge (section 1). In
290
+ driven branch, so treat it like any other push: leave auto-merge armed
291
+ (section 1), then re-read `headRefOid` and reset `verify_commit` to the merged
292
+ head. In
258
293
  `on_blocker=report` mode this whole step is off-limits (diagnose-only): do not
259
294
  merge, close, or delete anything — return `blocked:pending-auto-fix`.
260
295
 
@@ -33,9 +33,106 @@ const ACCESS_KEY = "AWS_ACCESS_KEY_ID";
33
33
  const SECRET_KEY = "AWS_SECRET_ACCESS_KEY";
34
34
  const REGION = "AWS_DEFAULT_REGION";
35
35
 
36
+ /** Selects which environment's role a session assumes. */
37
+ const PROFILE = "AWS_PROFILE";
38
+
36
39
  /** The bundle that carries the agent's identity. */
37
40
  export const BOOTSTRAP_KEY = "LISA_AWS_BOOTSTRAP_JSON";
38
41
 
42
+ /**
43
+ * The profile that holds the bootstrap key pair and is assumed FROM.
44
+ *
45
+ * Named rather than `default` so it can never be picked up by accident: this
46
+ * identity can assume roles and do nothing else, so a call that silently ran as
47
+ * it would fail with a permissions error far from its cause.
48
+ */
49
+ export const SOURCE_PROFILE = "lisa-bootstrap";
50
+
51
+ /**
52
+ * Read the bundle's `profiles`, which may be an object OR a JSON string.
53
+ *
54
+ * The real bundle stores it double-encoded — a string containing JSON — so a
55
+ * plain `typeof === "object"` check silently yields zero profiles and every
56
+ * environment quietly disappears. Failing that way is worse than throwing:
57
+ * everything still "works", as the assume-only identity, with no permissions.
58
+ * @param {object|null} bundle Parsed bootstrap bundle.
59
+ * @returns {Record<string, {roleArn?: string, region?: string}>} Profiles by name.
60
+ */
61
+ export function readProfiles(bundle) {
62
+ const raw = bundle?.profiles;
63
+ if (!raw) return {};
64
+ if (typeof raw === "object") return raw;
65
+ if (typeof raw !== "string") return {};
66
+ try {
67
+ const parsed = JSON.parse(raw);
68
+ return parsed && typeof parsed === "object" ? parsed : {};
69
+ } catch {
70
+ return {};
71
+ }
72
+ }
73
+
74
+ /**
75
+ * Render `~/.aws/credentials` and `~/.aws/config` from the bundle.
76
+ *
77
+ * The bundle carries a `profiles` map — one entry per environment, each a
78
+ * `roleArn` in a DIFFERENT account — plus the `externalId` those roles require.
79
+ * Nothing consumed any of it, so `--profile agent-dev` failed with "profile not
80
+ * found" and every call fell back to the bootstrap identity in the shared
81
+ * account. That identity can assume roles and nothing else, which is why
82
+ * `aws sts get-caller-identity` could succeed while real work had no
83
+ * permissions anywhere: a green check that proved only the first link.
84
+ *
85
+ * Writing the pair here rather than exporting it is deliberate. Exported
86
+ * environment credentials OUTRANK `AWS_PROFILE`, so a session that exports them
87
+ * ignores whichever profile it selects — the profiles would exist and never be
88
+ * used.
89
+ * @param {object} bundle Parsed bootstrap bundle.
90
+ * @returns {{credentials: string, config: string, profiles: string[]}|null}
91
+ * Rendered file contents and the profile names, or null when unusable.
92
+ */
93
+ export function renderAwsProfiles(bundle) {
94
+ if (!bundle) return null;
95
+
96
+ const accessKeyId = bundle.accessKeyId ?? bundle.aws_access_key_id;
97
+ const secretAccessKey =
98
+ bundle.secretAccessKey ?? bundle.aws_secret_access_key;
99
+ if (!accessKeyId || !secretAccessKey) return null;
100
+
101
+ const profiles = readProfiles(bundle);
102
+
103
+ const credentials = [
104
+ `[${SOURCE_PROFILE}]`,
105
+ `aws_access_key_id = ${accessKeyId}`,
106
+ `aws_secret_access_key = ${secretAccessKey}`,
107
+ "",
108
+ ].join("\n");
109
+
110
+ const sections = [];
111
+ const names = [];
112
+ for (const [name, entry] of Object.entries(profiles)) {
113
+ const roleArn = entry?.roleArn ?? entry?.role_arn;
114
+ if (!roleArn) continue;
115
+
116
+ // A name is only usable if it can be written as an ini section header and
117
+ // read back as the same string. Anything with a bracket or newline would
118
+ // either truncate or inject extra lines into ~/.aws/config, and a config
119
+ // file this corrupts is worse than one it never wrote.
120
+ if (!/^[\w.@-]+$/.test(name)) continue;
121
+
122
+ const lines = [`[profile ${name}]`, `role_arn = ${roleArn}`];
123
+ lines.push(`source_profile = ${SOURCE_PROFILE}`);
124
+ if (bundle.externalId) lines.push(`external_id = ${bundle.externalId}`);
125
+ if (entry.region) lines.push(`region = ${entry.region}`);
126
+ sections.push(`${lines.join("\n")}\n`);
127
+ // Collected here, where the name is already in scope. Recovering it by
128
+ // re-parsing the rendered text made the header format load-bearing: a
129
+ // change to it would silently corrupt every returned name.
130
+ names.push(name);
131
+ }
132
+
133
+ return { credentials, config: sections.join("\n"), profiles: names };
134
+ }
135
+
39
136
  /**
40
137
  * Read the bootstrap bundle, treating anything malformed as absent.
41
138
  *
@@ -80,16 +177,64 @@ export function deriveAwsEnvironment(selected) {
80
177
  // explicit. Overriding that would be this module guessing against an operator.
81
178
  if (selected.has(ACCESS_KEY) || selected.has(SECRET_KEY)) return derived;
82
179
 
83
- const note =
84
- `Derived from ${BOOTSTRAP_KEY} by lisa-secrets-access. Exported ` +
85
- `deliberately so it overrides any ambient ${ACCESS_KEY} the host injects ` +
86
- `environment variables outrank profile files in the AWS credential chain, ` +
87
- `so without this a stale host value wins and every call fails with ` +
88
- `InvalidClientTokenId. This is the assume-only bootstrap identity; real ` +
89
- `work assumes a role from it.`;
180
+ // The key pair is deliberately NOT exported.
181
+ //
182
+ // It used to be, to out-shout the ambient pair a cloud container injects. That
183
+ // worked and cost more than it bought: exported environment credentials
184
+ // outrank `AWS_PROFILE`, so every call ran as the bootstrap identity which
185
+ // can assume roles and do nothing else. `aws sts get-caller-identity`
186
+ // succeeded while real work had no permissions in any environment account,
187
+ // because each environment is a SEPARATE account reached by assuming a role.
188
+ //
189
+ // The pair now lives in ~/.aws/credentials as the source profile, and the
190
+ // session selects an environment instead. The ambient pair is unset by the
191
+ // shell profile rather than overridden — removing the poison beats out-
192
+ // shouting it, and it is what makes `--profile agent-staging` behave exactly
193
+ // as it does on a developer's machine.
194
+ // Only profiles that actually get WRITTEN are candidates. Selecting a name
195
+ // that ~/.aws/config never contains — an entry with no roleArn, or a name too
196
+ // exotic to be an ini header — fails with "profile not found", which is the
197
+ // exact failure this whole change removes.
198
+ const names = renderAwsProfiles(bundle)?.profiles ?? [];
90
199
 
91
- derived.set(ACCESS_KEY, { value: String(accessKeyId), note });
92
- derived.set(SECRET_KEY, { value: String(secretAccessKey), note });
200
+ // No usable profiles is not a reason to hand back a session with NOTHING.
201
+ //
202
+ // The pair stops being exported only because a profile supersedes it. With no
203
+ // profile to select, exporting it is the difference between a degraded
204
+ // session (the assume-only identity, which at least authenticates) and a dead
205
+ // one — and the managed shell block unsets the ambient pair, so nothing would
206
+ // fill the gap.
207
+ if (names.length === 0) {
208
+ const note =
209
+ `Derived from ${BOOTSTRAP_KEY} by lisa-secrets-access. The bundle ` +
210
+ `declares no usable per-environment profile, so this falls back to the ` +
211
+ `bootstrap identity. It can assume roles and little else — if AWS calls ` +
212
+ `fail with permission errors, the bundle's "profiles" map is the thing ` +
213
+ `to check.`;
214
+ derived.set(ACCESS_KEY, { value: String(accessKeyId), note });
215
+ derived.set(SECRET_KEY, { value: String(secretAccessKey), note });
216
+ }
217
+
218
+ if (names.length > 0 && !selected.has(PROFILE)) {
219
+ // Never production by default. An implicit production profile is one
220
+ // careless command away from a bad afternoon; that one must be typed.
221
+ const preferred =
222
+ names.find(name => /dev/i.test(name)) ??
223
+ names.find(name => !/prod/i.test(name)) ??
224
+ names[0];
225
+
226
+ derived.set(PROFILE, {
227
+ value: preferred,
228
+ note:
229
+ `Derived from ${BOOTSTRAP_KEY} by lisa-secrets-access. Selects the ` +
230
+ `environment whose role this session assumes, via ~/.aws/config. ` +
231
+ `Defaults to a non-production profile deliberately — reach production ` +
232
+ `by naming it (\`--profile ${names.find(n => /prod/i.test(n)) ?? "…"}\`). ` +
233
+ `The bootstrap key pair is NOT exported: environment credentials ` +
234
+ `outrank AWS_PROFILE, so exporting them would ignore this selection ` +
235
+ `and run everything as the assume-only identity.`,
236
+ });
237
+ }
93
238
 
94
239
  const region = bundle.region ?? bundle.defaultRegion;
95
240
  if (region && !selected.has(REGION)) {
@@ -31,7 +31,12 @@ import {
31
31
  import { homedir } from "node:os";
32
32
  import { join } from "node:path";
33
33
 
34
- import { deriveAwsEnvironment } from "./aws-bootstrap.mjs";
34
+ import {
35
+ BOOTSTRAP_KEY,
36
+ deriveAwsEnvironment,
37
+ parseBootstrap,
38
+ renderAwsProfiles,
39
+ } from "./aws-bootstrap.mjs";
35
40
  import { renderEnv, renderNotes } from "./envfile.mjs";
36
41
  import { fetchAll } from "./providers.mjs";
37
42
  import { materializedPaths, readConfig } from "./surfaces.mjs";
@@ -68,6 +73,15 @@ const PROFILE_MARKER = "# >>> lisa secrets (managed) >>>";
68
73
  /** Closes the managed block. */
69
74
  const PROFILE_END = "# <<< lisa secrets (managed) <<<";
70
75
 
76
+ /**
77
+ * Identifies an `~/.aws` file as one this wrote, and may therefore replace.
78
+ *
79
+ * `#` is a comment in the AWS shared-config format, so this is inert to every
80
+ * consumer while still being the thing that distinguishes "our file, refresh
81
+ * it" from "someone else's file, leave it alone".
82
+ */
83
+ const MANAGED_MARKER = "# managed by lisa-secrets-access";
84
+
71
85
  /**
72
86
  * Make every shell in this container load the materialized secrets.
73
87
  *
@@ -95,6 +109,14 @@ export function installProfileSourcing(valuesFile, options = {}) {
95
109
 
96
110
  const block = [
97
111
  PROFILE_MARKER,
112
+ // Unset BEFORE sourcing. A cloud container injects its own AWS key pair,
113
+ // and environment credentials outrank both ~/.aws profiles and AWS_PROFILE
114
+ // — so leaving them set means the session ignores whichever environment it
115
+ // selected and runs as whatever the host injected. That is how a perfectly
116
+ // valid credential produced InvalidClientTokenId for a day. Removing the
117
+ // poison beats out-shouting it, and it is what lets `--profile agent-dev`
118
+ // behave here exactly as it does on a developer's machine.
119
+ `unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN`,
98
120
  `if [ -f "${valuesFile}" ]; then`,
99
121
  ` set -a`,
100
122
  ` . "${valuesFile}"`,
@@ -126,6 +148,61 @@ export function installProfileSourcing(valuesFile, options = {}) {
126
148
  return updated;
127
149
  }
128
150
 
151
+ /**
152
+ * Write `~/.aws/credentials` and `~/.aws/config` from the bootstrap bundle.
153
+ *
154
+ * Both at 0600 inside a 0700 directory, matching how the materialized secrets
155
+ * themselves are protected — the credentials file holds the source key pair.
156
+ * @param {object|null} bundle Parsed bootstrap bundle.
157
+ * @param {object} [options] Home directory and file seams, for tests.
158
+ * @returns {string[]} The profile names written.
159
+ */
160
+ export function installAwsProfiles(bundle, options = {}) {
161
+ const {
162
+ home = process.env.HOME || homedir(),
163
+ mkdir = mkdirSync,
164
+ write = writeFileSync,
165
+ read = readFileSync,
166
+ exists = existsSync,
167
+ chmod = chmodSync,
168
+ } = options;
169
+
170
+ const rendered = renderAwsProfiles(bundle);
171
+ if (!rendered) return [];
172
+
173
+ const dir = join(home, ".aws");
174
+
175
+ // Never overwrite an ~/.aws this did not write.
176
+ //
177
+ // These are whole-file writes, so a pre-existing credentials file — a
178
+ // developer's own profiles, or something another tool set up — would be
179
+ // destroyed rather than merged. This only runs on a surface allowed to write
180
+ // secrets to disk (a disposable container), but "usually disposable" is not a
181
+ // reason to be able to delete someone's credentials. The marker makes our own
182
+ // file re-writable while anything else is left alone and reported.
183
+ for (const name of ["credentials", "config"]) {
184
+ const file = join(dir, name);
185
+ if (exists(file) && !String(read(file, "utf8")).includes(MANAGED_MARKER)) {
186
+ return [];
187
+ }
188
+ }
189
+
190
+ mkdir(dir, { recursive: true, mode: 0o700 });
191
+ chmod(dir, 0o700);
192
+ write(
193
+ join(dir, "credentials"),
194
+ `${MANAGED_MARKER}\n${rendered.credentials}`,
195
+ {
196
+ mode: 0o600,
197
+ }
198
+ );
199
+ write(join(dir, "config"), `${MANAGED_MARKER}\n${rendered.config}`, {
200
+ mode: 0o600,
201
+ });
202
+
203
+ return rendered.profiles;
204
+ }
205
+
129
206
  export function materialize(cfg = readConfig()) {
130
207
  if (!cfg.capabilities.mayWriteValues) {
131
208
  throw new Error(
@@ -170,7 +247,21 @@ export function materialize(cfg = readConfig()) {
170
247
  // materialized" and "the credential is usable" the same statement.
171
248
  const sourced = installProfileSourcing(valuesFile);
172
249
 
173
- return { count: selected.size, derived: derived.size, dir, sourced };
250
+ // The environments live in separate AWS accounts, reached by assuming a role
251
+ // per environment. Without these files `--profile agent-dev` fails with
252
+ // "profile not found" and everything silently falls back to the bootstrap
253
+ // identity, which can assume roles and do nothing else.
254
+ const profiles = installAwsProfiles(
255
+ parseBootstrap(selected.get(BOOTSTRAP_KEY)?.value)
256
+ );
257
+
258
+ return {
259
+ count: selected.size,
260
+ derived: derived.size,
261
+ dir,
262
+ sourced,
263
+ profiles,
264
+ };
174
265
  }
175
266
 
176
267
  function main() {
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "lisa",
3
- "version": "2.332.4",
3
+ "version": "2.333.0",
4
4
  "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
5
5
  "author": {
6
6
  "name": "Cody Swann"