@codyswann/lisa 4.79.1 → 4.80.0

package/package.json

@@ -189,7 +189,7 @@
     "qs": "^6.16.0"
   },
   "name": "@codyswann/lisa",
-  "version": "4.79.1",
+  "version": "4.80.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {
@@ -345,7 +345,7 @@
     "test": "tests"
   },
   "types": "./dist/index.d.ts",
-  "lisaReleaseCommit": "36103c6bcb22e823470252e4021988daa96ccbe8",
-  "gitHead": "36103c6bcb22e823470252e4021988daa96ccbe8",
-  "lisaReleaseTag": "v4.79.1"
+  "lisaReleaseCommit": "756a01cb990889569814d47c5f250926622abdce",
+  "gitHead": "756a01cb990889569814d47c5f250926622abdce",
+  "lisaReleaseTag": "v4.80.0"
 }

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

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

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

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

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

@@ -55,8 +55,13 @@ two bundles declaring the same stages overwrite each other in the shared
 malformed. The name is the only place the owner can be recorded.
 
 `default` cannot be namespaced. The script claims it only when nothing else
-owns it, and otherwise stops and names the current owner;
-`LISA_AWS_CLAIM_DEFAULT_PROFILE=1` takes it over deliberately.
+owns it. Otherwise it still writes every named profile and verifies them as a
+normal run would (the default stage, or every stage under
+`LISA_AWS_VERIFY_ALL_PROFILES=1`), leaves `[default]` untouched, and exits
+non-zero naming the current owner and the named profiles to use instead (for example `AWS_PROFILE=<project>-agent-dev`);
+`LISA_AWS_CLAIM_DEFAULT_PROFILE=1` takes `[default]` over deliberately. When the
+owner is long-lived keys under `[default]` in `~/.aws/credentials`, the message
+also says that claiming would not remove them.
 
 Readiness is an account check, not a liveness check. `sts:GetCallerIdentity`
 succeeding proves the credentials work, not that they reached the intended

package/plugins/lisa/scripts/install-remote-agent-aws.mjs

@@ -335,9 +335,11 @@ a name carrying the owner prevents it.
 
 \`default\` is the one name that cannot be namespaced. The setup script writes
 it for this project only when nothing else already owns it; if another Lisa
-project or the operator's own configuration holds it, the script stops and says
-so rather than repointing every unqualified \`aws\` command. Pass
-\`LISA_AWS_CLAIM_DEFAULT_PROFILE=1\` to take it over deliberately.
+project or the operator's own configuration holds it, the script still writes
+every named profile and verifies them as a normal run would, leaves
+\`[default]\` untouched, and exits non-zero saying so rather than repointing
+every unqualified \`aws\` command. Use the named profiles it lists, or pass
+\`LISA_AWS_CLAIM_DEFAULT_PROFILE=1\` to take \`[default]\` over deliberately.
 
 Production and shared profiles are observer-only. Production repair remains a
 human-driven local-workstation operation.

package/plugins/lisa/scripts/remote-agent-aws-setup.sh

@@ -598,12 +598,22 @@ if [ -n "$legacy_sections" ]; then
   fi
 fi
 
+# Decided here, enforced at the end. Refusing `[default]` must not also refuse
+# the named profiles: they are namespaced, carry no collision risk, and are the
+# remedy the refusal points the operator at. Refusing before writing them told
+# the operator to use profiles that did not exist, leaving the takeover override
+# as the only real path — the outcome this guard exists to discourage. So every
+# named profile is written and verified first, `[default]` alone is left
+# untouched, and the run still exits non-zero: what the operator asked for
+# (a ready workstation with this project's default) did not happen, and a
+# caller that continued on success would run unqualified `aws` commands in the
+# operator's account believing they reached this project's.
 default_owner="$(default_profile_owner)"
+claim_default=1
 case "$default_owner" in
   ours | legacy | unclaimed) ;;
   *)
-    [ "${LISA_AWS_CLAIM_DEFAULT_PROFILE:-0}" = "1" ] || fail \
-      "refusing to overwrite the [default] AWS profile in ${config_file}: it belongs to ${default_owner}, not to ${PROFILE_NAMESPACE}. Overwriting it would silently repoint every unqualified aws command at this project's accounts. Use the named profiles instead (${profile_names}), or set LISA_AWS_CLAIM_DEFAULT_PROFILE=1 to take it over deliberately."
+    [ "${LISA_AWS_CLAIM_DEFAULT_PROFILE:-0}" = "1" ] || claim_default=0
     ;;
 esac
 
@@ -629,11 +639,13 @@ while IFS="$(printf '\t')" read -r stage role_arn region; do
 done < <(printf '%s' "$profiles_json" | jq -r 'to_entries[] | [.key, .value.roleArn, .value.region] | @tsv')
 
 default_profile="${PROFILE_NAMESPACE}-agent-${default_stage}"
-aws configure set role_arn "$default_role_arn" --profile default
-aws configure set source_profile "$BOOTSTRAP_PROFILE" --profile default
-aws configure set external_id "$external_id" --profile default
-aws configure set role_session_name "$session_name" --profile default
-aws configure set region "$default_region" --profile default
+if [ "$claim_default" = "1" ]; then
+  aws configure set role_arn "$default_role_arn" --profile default
+  aws configure set source_profile "$BOOTSTRAP_PROFILE" --profile default
+  aws configure set external_id "$external_id" --profile default
+  aws configure set role_session_name "$session_name" --profile default
+  aws configure set region "$default_region" --profile default
+fi
 
 chmod 600 "$credentials_file" "$config_file"
 
@@ -674,4 +686,26 @@ if [ -n "$legacy_names" ]; then
   fi
 fi
 
+if [ "$claim_default" = "0" ]; then
+  if [ "${LISA_AWS_SKIP_VERIFY:-0}" = "1" ]; then
+    named_state="were written but not verified (LISA_AWS_SKIP_VERIFY=1)"
+  elif [ "${LISA_AWS_VERIFY_ALL_PROFILES:-0}" = "1" ]; then
+    named_state="were written and verified"
+  else
+    # Only the default stage's account is proved without VERIFY_ALL, so the
+    # message names exactly that one rather than vouching for all of them.
+    named_state="were written; ${default_profile} was verified (set LISA_AWS_VERIFY_ALL_PROFILES=1 to verify every one)"
+  fi
+  # The trap the override walks into when `[default]` is static keys rather
+  # than a config-side profile: claiming rewrites only the config file, so the
+  # keys stay, and `[default]` ends up holding a role and an unrelated account's
+  # keys at once. Which wins depends on each tool's credential precedence. The
+  # key material itself is never echoed.
+  static_keys_note=""
+  if [ -n "$(profile_setting_value "$credentials_file" "default" "aws_access_key_id")" ]; then
+    static_keys_note=" Note: ${credentials_file} holds long-lived access keys under [default]. Claiming rewrites only ${config_file} and does not remove them, so [default] would carry both this project's role and those keys, and which one a tool uses depends on its credential precedence."
+  fi
+  fail "refusing to overwrite the [default] AWS profile in ${config_file}: it belongs to ${default_owner}, not to ${PROFILE_NAMESPACE}. Overwriting it would silently repoint every unqualified aws command at this project's accounts. [default] was left untouched; this project's named profiles ${named_state} (${profile_names}). Use them instead, for example AWS_PROFILE=${default_profile} or --profile ${default_profile}, or set LISA_AWS_CLAIM_DEFAULT_PROFILE=1 to take [default] over deliberately.${static_keys_note}"
+fi
+
 echo "remote-agent-aws-setup: ready (${session_name}; namespace=${PROFILE_NAMESPACE} via ${namespace_source}; default=${default_profile} in account ${default_expected_account}; profiles=${profile_names})"

package/plugins/lisa/skills/lisa-setup-remote-aws/SKILL.md

@@ -53,8 +53,13 @@ two bundles declaring the same stages overwrite each other in the shared
 malformed. The name is the only place the owner can be recorded.
 
 `default` cannot be namespaced. The script claims it only when nothing else
-owns it, and otherwise stops and names the current owner;
-`LISA_AWS_CLAIM_DEFAULT_PROFILE=1` takes it over deliberately.
+owns it. Otherwise it still writes every named profile and verifies them as a
+normal run would (the default stage, or every stage under
+`LISA_AWS_VERIFY_ALL_PROFILES=1`), leaves `[default]` untouched, and exits
+non-zero naming the current owner and the named profiles to use instead (for example `AWS_PROFILE=<project>-agent-dev`);
+`LISA_AWS_CLAIM_DEFAULT_PROFILE=1` takes `[default]` over deliberately. When the
+owner is long-lived keys under `[default]` in `~/.aws/credentials`, the message
+also says that claiming would not remove them.
 
 Readiness is an account check, not a liveness check. `sts:GetCallerIdentity`
 succeeding proves the credentials work, not that they reached the intended

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/scripts/install-remote-agent-aws.mjs

@@ -335,9 +335,11 @@ a name carrying the owner prevents it.
 
 \`default\` is the one name that cannot be namespaced. The setup script writes
 it for this project only when nothing else already owns it; if another Lisa
-project or the operator's own configuration holds it, the script stops and says
-so rather than repointing every unqualified \`aws\` command. Pass
-\`LISA_AWS_CLAIM_DEFAULT_PROFILE=1\` to take it over deliberately.
+project or the operator's own configuration holds it, the script still writes
+every named profile and verifies them as a normal run would, leaves
+\`[default]\` untouched, and exits non-zero saying so rather than repointing
+every unqualified \`aws\` command. Use the named profiles it lists, or pass
+\`LISA_AWS_CLAIM_DEFAULT_PROFILE=1\` to take \`[default]\` over deliberately.
 
 Production and shared profiles are observer-only. Production repair remains a
 human-driven local-workstation operation.

package/plugins/lisa-agy/scripts/remote-agent-aws-setup.sh

@@ -598,12 +598,22 @@ if [ -n "$legacy_sections" ]; then
   fi
 fi
 
+# Decided here, enforced at the end. Refusing `[default]` must not also refuse
+# the named profiles: they are namespaced, carry no collision risk, and are the
+# remedy the refusal points the operator at. Refusing before writing them told
+# the operator to use profiles that did not exist, leaving the takeover override
+# as the only real path — the outcome this guard exists to discourage. So every
+# named profile is written and verified first, `[default]` alone is left
+# untouched, and the run still exits non-zero: what the operator asked for
+# (a ready workstation with this project's default) did not happen, and a
+# caller that continued on success would run unqualified `aws` commands in the
+# operator's account believing they reached this project's.
 default_owner="$(default_profile_owner)"
+claim_default=1
 case "$default_owner" in
   ours | legacy | unclaimed) ;;
   *)
-    [ "${LISA_AWS_CLAIM_DEFAULT_PROFILE:-0}" = "1" ] || fail \
-      "refusing to overwrite the [default] AWS profile in ${config_file}: it belongs to ${default_owner}, not to ${PROFILE_NAMESPACE}. Overwriting it would silently repoint every unqualified aws command at this project's accounts. Use the named profiles instead (${profile_names}), or set LISA_AWS_CLAIM_DEFAULT_PROFILE=1 to take it over deliberately."
+    [ "${LISA_AWS_CLAIM_DEFAULT_PROFILE:-0}" = "1" ] || claim_default=0
     ;;
 esac
 
@@ -629,11 +639,13 @@ while IFS="$(printf '\t')" read -r stage role_arn region; do
 done < <(printf '%s' "$profiles_json" | jq -r 'to_entries[] | [.key, .value.roleArn, .value.region] | @tsv')
 
 default_profile="${PROFILE_NAMESPACE}-agent-${default_stage}"
-aws configure set role_arn "$default_role_arn" --profile default
-aws configure set source_profile "$BOOTSTRAP_PROFILE" --profile default
-aws configure set external_id "$external_id" --profile default
-aws configure set role_session_name "$session_name" --profile default
-aws configure set region "$default_region" --profile default
+if [ "$claim_default" = "1" ]; then
+  aws configure set role_arn "$default_role_arn" --profile default
+  aws configure set source_profile "$BOOTSTRAP_PROFILE" --profile default
+  aws configure set external_id "$external_id" --profile default
+  aws configure set role_session_name "$session_name" --profile default
+  aws configure set region "$default_region" --profile default
+fi
 
 chmod 600 "$credentials_file" "$config_file"
 
@@ -674,4 +686,26 @@ if [ -n "$legacy_names" ]; then
   fi
 fi
 
+if [ "$claim_default" = "0" ]; then
+  if [ "${LISA_AWS_SKIP_VERIFY:-0}" = "1" ]; then
+    named_state="were written but not verified (LISA_AWS_SKIP_VERIFY=1)"
+  elif [ "${LISA_AWS_VERIFY_ALL_PROFILES:-0}" = "1" ]; then
+    named_state="were written and verified"
+  else
+    # Only the default stage's account is proved without VERIFY_ALL, so the
+    # message names exactly that one rather than vouching for all of them.
+    named_state="were written; ${default_profile} was verified (set LISA_AWS_VERIFY_ALL_PROFILES=1 to verify every one)"
+  fi
+  # The trap the override walks into when `[default]` is static keys rather
+  # than a config-side profile: claiming rewrites only the config file, so the
+  # keys stay, and `[default]` ends up holding a role and an unrelated account's
+  # keys at once. Which wins depends on each tool's credential precedence. The
+  # key material itself is never echoed.
+  static_keys_note=""
+  if [ -n "$(profile_setting_value "$credentials_file" "default" "aws_access_key_id")" ]; then
+    static_keys_note=" Note: ${credentials_file} holds long-lived access keys under [default]. Claiming rewrites only ${config_file} and does not remove them, so [default] would carry both this project's role and those keys, and which one a tool uses depends on its credential precedence."
+  fi
+  fail "refusing to overwrite the [default] AWS profile in ${config_file}: it belongs to ${default_owner}, not to ${PROFILE_NAMESPACE}. Overwriting it would silently repoint every unqualified aws command at this project's accounts. [default] was left untouched; this project's named profiles ${named_state} (${profile_names}). Use them instead, for example AWS_PROFILE=${default_profile} or --profile ${default_profile}, or set LISA_AWS_CLAIM_DEFAULT_PROFILE=1 to take [default] over deliberately.${static_keys_note}"
+fi
+
 echo "remote-agent-aws-setup: ready (${session_name}; namespace=${PROFILE_NAMESPACE} via ${namespace_source}; default=${default_profile} in account ${default_expected_account}; profiles=${profile_names})"

package/plugins/lisa-agy/skills/lisa-setup-remote-aws/SKILL.md

@@ -53,8 +53,13 @@ two bundles declaring the same stages overwrite each other in the shared
 malformed. The name is the only place the owner can be recorded.
 
 `default` cannot be namespaced. The script claims it only when nothing else
-owns it, and otherwise stops and names the current owner;
-`LISA_AWS_CLAIM_DEFAULT_PROFILE=1` takes it over deliberately.
+owns it. Otherwise it still writes every named profile and verifies them as a
+normal run would (the default stage, or every stage under
+`LISA_AWS_VERIFY_ALL_PROFILES=1`), leaves `[default]` untouched, and exits
+non-zero naming the current owner and the named profiles to use instead (for example `AWS_PROFILE=<project>-agent-dev`);
+`LISA_AWS_CLAIM_DEFAULT_PROFILE=1` takes `[default]` over deliberately. When the
+owner is long-lived keys under `[default]` in `~/.aws/credentials`, the message
+also says that claiming would not remove them.
 
 Readiness is an account check, not a liveness check. `sts:GetCallerIdentity`
 succeeding proves the credentials work, not that they reached the intended

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "4.79.1",
+  "version": "4.80.0",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

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

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

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

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

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

package/plugins/lisa-copilot/scripts/install-remote-agent-aws.mjs

@@ -335,9 +335,11 @@ a name carrying the owner prevents it.
 
 \`default\` is the one name that cannot be namespaced. The setup script writes
 it for this project only when nothing else already owns it; if another Lisa
-project or the operator's own configuration holds it, the script stops and says
-so rather than repointing every unqualified \`aws\` command. Pass
-\`LISA_AWS_CLAIM_DEFAULT_PROFILE=1\` to take it over deliberately.
+project or the operator's own configuration holds it, the script still writes
+every named profile and verifies them as a normal run would, leaves
+\`[default]\` untouched, and exits non-zero saying so rather than repointing
+every unqualified \`aws\` command. Use the named profiles it lists, or pass
+\`LISA_AWS_CLAIM_DEFAULT_PROFILE=1\` to take \`[default]\` over deliberately.
 
 Production and shared profiles are observer-only. Production repair remains a
 human-driven local-workstation operation.

package/plugins/lisa-copilot/scripts/remote-agent-aws-setup.sh

@@ -598,12 +598,22 @@ if [ -n "$legacy_sections" ]; then
   fi
 fi
 
+# Decided here, enforced at the end. Refusing `[default]` must not also refuse
+# the named profiles: they are namespaced, carry no collision risk, and are the
+# remedy the refusal points the operator at. Refusing before writing them told
+# the operator to use profiles that did not exist, leaving the takeover override
+# as the only real path — the outcome this guard exists to discourage. So every
+# named profile is written and verified first, `[default]` alone is left
+# untouched, and the run still exits non-zero: what the operator asked for
+# (a ready workstation with this project's default) did not happen, and a
+# caller that continued on success would run unqualified `aws` commands in the
+# operator's account believing they reached this project's.
 default_owner="$(default_profile_owner)"
+claim_default=1
 case "$default_owner" in
   ours | legacy | unclaimed) ;;
   *)
-    [ "${LISA_AWS_CLAIM_DEFAULT_PROFILE:-0}" = "1" ] || fail \
-      "refusing to overwrite the [default] AWS profile in ${config_file}: it belongs to ${default_owner}, not to ${PROFILE_NAMESPACE}. Overwriting it would silently repoint every unqualified aws command at this project's accounts. Use the named profiles instead (${profile_names}), or set LISA_AWS_CLAIM_DEFAULT_PROFILE=1 to take it over deliberately."
+    [ "${LISA_AWS_CLAIM_DEFAULT_PROFILE:-0}" = "1" ] || claim_default=0
     ;;
 esac
 
@@ -629,11 +639,13 @@ while IFS="$(printf '\t')" read -r stage role_arn region; do
 done < <(printf '%s' "$profiles_json" | jq -r 'to_entries[] | [.key, .value.roleArn, .value.region] | @tsv')
 
 default_profile="${PROFILE_NAMESPACE}-agent-${default_stage}"
-aws configure set role_arn "$default_role_arn" --profile default
-aws configure set source_profile "$BOOTSTRAP_PROFILE" --profile default
-aws configure set external_id "$external_id" --profile default
-aws configure set role_session_name "$session_name" --profile default
-aws configure set region "$default_region" --profile default
+if [ "$claim_default" = "1" ]; then
+  aws configure set role_arn "$default_role_arn" --profile default
+  aws configure set source_profile "$BOOTSTRAP_PROFILE" --profile default
+  aws configure set external_id "$external_id" --profile default
+  aws configure set role_session_name "$session_name" --profile default
+  aws configure set region "$default_region" --profile default
+fi
 
 chmod 600 "$credentials_file" "$config_file"
 
@@ -674,4 +686,26 @@ if [ -n "$legacy_names" ]; then
   fi
 fi
 
+if [ "$claim_default" = "0" ]; then
+  if [ "${LISA_AWS_SKIP_VERIFY:-0}" = "1" ]; then
+    named_state="were written but not verified (LISA_AWS_SKIP_VERIFY=1)"
+  elif [ "${LISA_AWS_VERIFY_ALL_PROFILES:-0}" = "1" ]; then
+    named_state="were written and verified"
+  else
+    # Only the default stage's account is proved without VERIFY_ALL, so the
+    # message names exactly that one rather than vouching for all of them.
+    named_state="were written; ${default_profile} was verified (set LISA_AWS_VERIFY_ALL_PROFILES=1 to verify every one)"
+  fi
+  # The trap the override walks into when `[default]` is static keys rather
+  # than a config-side profile: claiming rewrites only the config file, so the
+  # keys stay, and `[default]` ends up holding a role and an unrelated account's
+  # keys at once. Which wins depends on each tool's credential precedence. The
+  # key material itself is never echoed.
+  static_keys_note=""
+  if [ -n "$(profile_setting_value "$credentials_file" "default" "aws_access_key_id")" ]; then
+    static_keys_note=" Note: ${credentials_file} holds long-lived access keys under [default]. Claiming rewrites only ${config_file} and does not remove them, so [default] would carry both this project's role and those keys, and which one a tool uses depends on its credential precedence."
+  fi
+  fail "refusing to overwrite the [default] AWS profile in ${config_file}: it belongs to ${default_owner}, not to ${PROFILE_NAMESPACE}. Overwriting it would silently repoint every unqualified aws command at this project's accounts. [default] was left untouched; this project's named profiles ${named_state} (${profile_names}). Use them instead, for example AWS_PROFILE=${default_profile} or --profile ${default_profile}, or set LISA_AWS_CLAIM_DEFAULT_PROFILE=1 to take [default] over deliberately.${static_keys_note}"
+fi
+
 echo "remote-agent-aws-setup: ready (${session_name}; namespace=${PROFILE_NAMESPACE} via ${namespace_source}; default=${default_profile} in account ${default_expected_account}; profiles=${profile_names})"

package/plugins/lisa-copilot/skills/lisa-setup-remote-aws/SKILL.md

@@ -53,8 +53,13 @@ two bundles declaring the same stages overwrite each other in the shared
 malformed. The name is the only place the owner can be recorded.
 
 `default` cannot be namespaced. The script claims it only when nothing else
-owns it, and otherwise stops and names the current owner;
-`LISA_AWS_CLAIM_DEFAULT_PROFILE=1` takes it over deliberately.
+owns it. Otherwise it still writes every named profile and verifies them as a
+normal run would (the default stage, or every stage under
+`LISA_AWS_VERIFY_ALL_PROFILES=1`), leaves `[default]` untouched, and exits
+non-zero naming the current owner and the named profiles to use instead (for example `AWS_PROFILE=<project>-agent-dev`);
+`LISA_AWS_CLAIM_DEFAULT_PROFILE=1` takes `[default]` over deliberately. When the
+owner is long-lived keys under `[default]` in `~/.aws/credentials`, the message
+also says that claiming would not remove them.
 
 Readiness is an account check, not a liveness check. `sts:GetCallerIdentity`
 succeeding proves the credentials work, not that they reached the intended

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

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

package/plugins/lisa-cursor/scripts/install-remote-agent-aws.mjs

@@ -335,9 +335,11 @@ a name carrying the owner prevents it.
 
 \`default\` is the one name that cannot be namespaced. The setup script writes
 it for this project only when nothing else already owns it; if another Lisa
-project or the operator's own configuration holds it, the script stops and says
-so rather than repointing every unqualified \`aws\` command. Pass
-\`LISA_AWS_CLAIM_DEFAULT_PROFILE=1\` to take it over deliberately.
+project or the operator's own configuration holds it, the script still writes
+every named profile and verifies them as a normal run would, leaves
+\`[default]\` untouched, and exits non-zero saying so rather than repointing
+every unqualified \`aws\` command. Use the named profiles it lists, or pass
+\`LISA_AWS_CLAIM_DEFAULT_PROFILE=1\` to take \`[default]\` over deliberately.
 
 Production and shared profiles are observer-only. Production repair remains a
 human-driven local-workstation operation.

package/plugins/lisa-cursor/scripts/remote-agent-aws-setup.sh

@@ -598,12 +598,22 @@ if [ -n "$legacy_sections" ]; then
   fi
 fi
 
+# Decided here, enforced at the end. Refusing `[default]` must not also refuse
+# the named profiles: they are namespaced, carry no collision risk, and are the
+# remedy the refusal points the operator at. Refusing before writing them told
+# the operator to use profiles that did not exist, leaving the takeover override
+# as the only real path — the outcome this guard exists to discourage. So every
+# named profile is written and verified first, `[default]` alone is left
+# untouched, and the run still exits non-zero: what the operator asked for
+# (a ready workstation with this project's default) did not happen, and a
+# caller that continued on success would run unqualified `aws` commands in the
+# operator's account believing they reached this project's.
 default_owner="$(default_profile_owner)"
+claim_default=1
 case "$default_owner" in
   ours | legacy | unclaimed) ;;
   *)
-    [ "${LISA_AWS_CLAIM_DEFAULT_PROFILE:-0}" = "1" ] || fail \
-      "refusing to overwrite the [default] AWS profile in ${config_file}: it belongs to ${default_owner}, not to ${PROFILE_NAMESPACE}. Overwriting it would silently repoint every unqualified aws command at this project's accounts. Use the named profiles instead (${profile_names}), or set LISA_AWS_CLAIM_DEFAULT_PROFILE=1 to take it over deliberately."
+    [ "${LISA_AWS_CLAIM_DEFAULT_PROFILE:-0}" = "1" ] || claim_default=0
     ;;
 esac
 
@@ -629,11 +639,13 @@ while IFS="$(printf '\t')" read -r stage role_arn region; do
 done < <(printf '%s' "$profiles_json" | jq -r 'to_entries[] | [.key, .value.roleArn, .value.region] | @tsv')
 
 default_profile="${PROFILE_NAMESPACE}-agent-${default_stage}"
-aws configure set role_arn "$default_role_arn" --profile default
-aws configure set source_profile "$BOOTSTRAP_PROFILE" --profile default
-aws configure set external_id "$external_id" --profile default
-aws configure set role_session_name "$session_name" --profile default
-aws configure set region "$default_region" --profile default
+if [ "$claim_default" = "1" ]; then
+  aws configure set role_arn "$default_role_arn" --profile default
+  aws configure set source_profile "$BOOTSTRAP_PROFILE" --profile default
+  aws configure set external_id "$external_id" --profile default
+  aws configure set role_session_name "$session_name" --profile default
+  aws configure set region "$default_region" --profile default
+fi
 
 chmod 600 "$credentials_file" "$config_file"
 
@@ -674,4 +686,26 @@ if [ -n "$legacy_names" ]; then
   fi
 fi
 
+if [ "$claim_default" = "0" ]; then
+  if [ "${LISA_AWS_SKIP_VERIFY:-0}" = "1" ]; then
+    named_state="were written but not verified (LISA_AWS_SKIP_VERIFY=1)"
+  elif [ "${LISA_AWS_VERIFY_ALL_PROFILES:-0}" = "1" ]; then
+    named_state="were written and verified"
+  else
+    # Only the default stage's account is proved without VERIFY_ALL, so the
+    # message names exactly that one rather than vouching for all of them.
+    named_state="were written; ${default_profile} was verified (set LISA_AWS_VERIFY_ALL_PROFILES=1 to verify every one)"
+  fi
+  # The trap the override walks into when `[default]` is static keys rather
+  # than a config-side profile: claiming rewrites only the config file, so the
+  # keys stay, and `[default]` ends up holding a role and an unrelated account's
+  # keys at once. Which wins depends on each tool's credential precedence. The
+  # key material itself is never echoed.
+  static_keys_note=""
+  if [ -n "$(profile_setting_value "$credentials_file" "default" "aws_access_key_id")" ]; then
+    static_keys_note=" Note: ${credentials_file} holds long-lived access keys under [default]. Claiming rewrites only ${config_file} and does not remove them, so [default] would carry both this project's role and those keys, and which one a tool uses depends on its credential precedence."
+  fi
+  fail "refusing to overwrite the [default] AWS profile in ${config_file}: it belongs to ${default_owner}, not to ${PROFILE_NAMESPACE}. Overwriting it would silently repoint every unqualified aws command at this project's accounts. [default] was left untouched; this project's named profiles ${named_state} (${profile_names}). Use them instead, for example AWS_PROFILE=${default_profile} or --profile ${default_profile}, or set LISA_AWS_CLAIM_DEFAULT_PROFILE=1 to take [default] over deliberately.${static_keys_note}"
+fi
+
 echo "remote-agent-aws-setup: ready (${session_name}; namespace=${PROFILE_NAMESPACE} via ${namespace_source}; default=${default_profile} in account ${default_expected_account}; profiles=${profile_names})"

package/plugins/lisa-cursor/skills/lisa-setup-remote-aws/SKILL.md

@@ -53,8 +53,13 @@ two bundles declaring the same stages overwrite each other in the shared
 malformed. The name is the only place the owner can be recorded.
 
 `default` cannot be namespaced. The script claims it only when nothing else
-owns it, and otherwise stops and names the current owner;
-`LISA_AWS_CLAIM_DEFAULT_PROFILE=1` takes it over deliberately.
+owns it. Otherwise it still writes every named profile and verifies them as a
+normal run would (the default stage, or every stage under
+`LISA_AWS_VERIFY_ALL_PROFILES=1`), leaves `[default]` untouched, and exits
+non-zero naming the current owner and the named profiles to use instead (for example `AWS_PROFILE=<project>-agent-dev`);
+`LISA_AWS_CLAIM_DEFAULT_PROFILE=1` takes `[default]` over deliberately. When the
+owner is long-lived keys under `[default]` in `~/.aws/credentials`, the message
+also says that claiming would not remove them.
 
 Readiness is an account check, not a liveness check. `sts:GetCallerIdentity`
 succeeding proves the credentials work, not that they reached the intended

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

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

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

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

package/plugins/lisa-devin/scripts/install-remote-agent-aws.mjs

@@ -335,9 +335,11 @@ a name carrying the owner prevents it.
 
 \`default\` is the one name that cannot be namespaced. The setup script writes
 it for this project only when nothing else already owns it; if another Lisa
-project or the operator's own configuration holds it, the script stops and says
-so rather than repointing every unqualified \`aws\` command. Pass
-\`LISA_AWS_CLAIM_DEFAULT_PROFILE=1\` to take it over deliberately.
+project or the operator's own configuration holds it, the script still writes
+every named profile and verifies them as a normal run would, leaves
+\`[default]\` untouched, and exits non-zero saying so rather than repointing
+every unqualified \`aws\` command. Use the named profiles it lists, or pass
+\`LISA_AWS_CLAIM_DEFAULT_PROFILE=1\` to take \`[default]\` over deliberately.
 
 Production and shared profiles are observer-only. Production repair remains a
 human-driven local-workstation operation.