@codyswann/lisa 2.226.1 → 2.227.0

package/package.json

@@ -102,7 +102,7 @@
     "form-data": ">=4.0.6"
   },
   "name": "@codyswann/lisa",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "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.226.1",
+  "version": "2.227.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": "2.226.1",
+  "version": "2.227.0",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/rules/eager/history-audit.md

@@ -0,0 +1,27 @@
+# History Audit — Before Removing or Changing Existing Behavior (load-bearing)
+
+When a proposed change would **remove, gate, skip, consolidate, weaken, or relax existing behavior** — and the motivation is your own assessment that the code looks redundant, wasteful, slow, or wrong (rather than a ticket, bug report, or spec) — audit the history **before presenting the change as safe or implementing it**.
+
+## How to apply
+
+1. `git log --follow` the affected files and `git log --grep` for related keywords.
+2. Read **full commit bodies** (never just subjects), code comments, and covering tests — the defense usually lives there, often naming the exact incident the behavior prevents.
+3. Deliver every such recommendation with an explicit verdict:
+   - **Defended by \<commit/comment/test\>** — adapt the proposal to preserve that reason.
+   - **No defense found** — genuinely accidental; safe to change, and say so.
+
+## Scope
+
+- **Diagnosis doesn't need the audit; prescriptions do.** Analyzing what is slow or broken is free; recommending that existing behavior stop happening is what triggers the audit. If presenting unaudited ideas, label them as such.
+- Changes driven by an external requirement may cite that requirement as their defense and move on.
+- "Nothing was deleted" is not an exemption — a change that weakens a guarantee (e.g. adding a cache/stamp that skips a self-healing pass) alters existing behavior and needs the same audit.
+
+## Forbidden
+
+- Recommending removal or weakening of existing behavior as "safe" without the verdict.
+- Auditing subjects only (`--oneline` skims miss the evidence).
+- Treating redundant-looking behavior as accidental by default — defended is the norm, not the exception.
+
+This rule compounds with commit discipline: documenting the **why** in commit bodies is what makes future audits cheap.
+
+Full prose: [reference/history-audit.md](../reference/history-audit.md).

package/plugins/lisa/rules/reference/history-audit.md

@@ -0,0 +1,42 @@
+# History Audit — Before Removing or Changing Existing Behavior
+
+When a proposed change would remove, gate, skip, consolidate, weaken, or relax existing behavior — and the motivation is your own assessment that the code looks redundant, wasteful, slow, or wrong, rather than a ticket, bug report, or spec — **audit the history before presenting the change as safe or implementing it**. This is Chesterton's fence made operational: the fence's reason is usually written down; go read it.
+
+This is the historical counterpart to the `empirical-inquiry` rule: `empirical-inquiry` establishes facts about how the system behaves *now* by probing it; this rule establishes *why the system behaves that way* by reading the record. Both reject confident-sounding reasoning as a substitute for evidence.
+
+## Why this rule exists
+
+Optimization and cleanup recommendations fail in a characteristic way: the code genuinely *is* doing redundant-looking work, the diagnosis is correct, and the proposed fix would still ship a regression — because the redundancy is load-bearing and its reason lives in a commit body, a code comment, or a test the recommender never read. In a real Lisa incident, a performance audit of the postinstall pipeline produced five recommendations; the history audit walked back two of them (a "redundant" apply pass existed to fix a bootstrap chicken-and-egg; a "wasteful" detached re-run existed because the package manager clobbers `package.json` after lifecycle scripts finish) and confirmed the rest were genuinely accidental. Without the audit, the confident-sounding fixes would have re-shipped bugs that earlier commits had explicitly fixed.
+
+## When this rule applies
+
+- A recommendation proposes that existing behavior stop happening: deleting a code path, gating an unconditional step, deduplicating repeated work, relaxing a guard or retry, skipping a pass "when nothing changed."
+- The motivation is internal — the code *looks* redundant, wasteful, slow, dead, or overcautious — rather than an external requirement.
+- **Nothing needs to be deleted to trigger it.** A change that weakens a guarantee alters existing behavior just as much: adding a cache or version-stamp that skips a self-healing pass, narrowing a matcher, batching what was deliberately serialized.
+
+## When it does not apply
+
+- **Diagnosis is free.** Measuring, profiling, and explaining what is slow or broken needs no audit. The audit gates *prescriptions* — the moment an observation is about to become "so we should remove/skip/gate X."
+- **Requirement-driven changes may cite the requirement.** Implementing a ticket, fixing a reproduced bug, or following a spec supplies external evidence; cite it as the defense and move on. Normal verification discipline covers those.
+- **Spitballing is fine when labeled.** Presenting early ideas before the audit is acceptable if they are explicitly marked as not yet history-audited. What is forbidden is presenting them as safe.
+
+## How to apply it
+
+1. **Trace the artifact history.** `git log --follow` on each affected file; `git log --grep` for related keywords (feature names, flag names, error strings). Find the commits that introduced and last modified the behavior.
+2. **Read the full commit bodies.** Subjects rarely carry the defense; bodies do — often naming the exact incident, the affected projects, and the failure mode the behavior prevents. `--oneline` skims are how the evidence gets missed. Extend the same reading to code comments around the behavior and to tests whose names encode a philosophy (a test called `*-guard` or `*-preserves-*` is a defense).
+3. **Check for a prior removal.** Search for commits that removed the same behavior before — if it was removed and later restored, the restoration commit is the strongest defense on record, and your proposal must answer it specifically.
+4. **Issue a per-recommendation verdict.** Every prescription ships in one of two states:
+   - **Defended by \<commit/comment/test\>** — the behavior has a recorded reason. Adapt the proposal so that reason keeps holding (gate instead of delete, preserve the invariant, keep the escape hatch), and say what the defense was.
+   - **No defense found** — you searched and no commit, comment, or test justifies it. That absence is itself a finding: state it, and proceed.
+
+   The verdict is the enforcement mechanism — it cannot be filled in without doing the audit.
+
+## What this rule forbids
+
+- Presenting the removal or weakening of existing behavior as safe without a verdict.
+- Auditing by subject line only.
+- Treating redundant-looking behavior as accidental by default. In a codebase with disciplined commit messages, *defended* is the norm; genuine accidents are the exception, and the audit is how you tell them apart.
+
+## The compounding loop
+
+This rule only works in a repository whose commit messages record the **why** — which the commit-discipline rules already mandate. The two form a loop: writing down why a behavior exists makes the future audit a five-minute read instead of an archaeology project, and the audit is what makes writing it down pay off. When your own change survives an audit and ships, document its why with the same care — the next agent's audit depends on it.

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

@@ -114,6 +114,27 @@ AWS_CLI_PUBLIC_KEY
   trap - EXIT
 }
 
+remove_profile_setting() {
+  local credentials_file profile setting temporary_file
+  credentials_file="$1"
+  profile="$2"
+  setting="$3"
+  [ -f "$credentials_file" ] || return 0
+
+  temporary_file="$(mktemp "${credentials_file}.XXXXXX")"
+  awk -v profile="$profile" -v setting="$setting" '
+    /^\[[^]]+\][[:space:]]*$/ {
+      section = $0
+      sub(/^\[/, "", section)
+      sub(/\][[:space:]]*$/, "", section)
+      in_profile = section == profile
+    }
+    !(in_profile && $0 ~ "^[[:space:]]*" setting "[[:space:]]*=") { print }
+  ' "$credentials_file" >"$temporary_file"
+  chmod 600 "$temporary_file"
+  mv "$temporary_file" "$credentials_file"
+}
+
 sanitize_session_name() {
   local candidate
   candidate="$(printf '%s' "${LISA_REMOTE_AGENT:-remote-agent}" \
@@ -154,22 +175,30 @@ profiles_json="$(printf '%s' "$bootstrap_json" | jq -c '
   end
 ')"
 
-printf '%s' "$profiles_json" | jq -e '
+printf '%s' "$profiles_json" | jq -e --arg bootstrap_profile "$BOOTSTRAP_PROFILE" '
   type == "object" and length > 0 and
   all(to_entries[];
+    (.key != $bootstrap_profile) and
     (.key | test("^[A-Za-z0-9_-]+$")) and
     (.value.roleArn | type == "string" and startswith("arn:aws:iam::")) and
     (.value.region | type == "string" and length > 0)
   )
 ' >/dev/null || fail "bootstrap profiles must map safe names to roleArn and region"
 
-mkdir -p "$HOME/.aws"
+credentials_file="${AWS_SHARED_CREDENTIALS_FILE:-$HOME/.aws/credentials}"
+config_file="${AWS_CONFIG_FILE:-$HOME/.aws/config}"
+mkdir -p "$HOME/.aws" "$(dirname "$credentials_file")" "$(dirname "$config_file")"
 chmod 700 "$HOME/.aws"
 
 aws configure set aws_access_key_id "$access_key_id" --profile "$BOOTSTRAP_PROFILE"
 aws configure set aws_secret_access_key "$secret_access_key" --profile "$BOOTSTRAP_PROFILE"
 if [ -n "$session_token" ]; then
   aws configure set aws_session_token "$session_token" --profile "$BOOTSTRAP_PROFILE"
+else
+  remove_profile_setting \
+    "$credentials_file" \
+    "$BOOTSTRAP_PROFILE" \
+    "aws_session_token"
 fi
 
 session_name="$(sanitize_session_name)"
@@ -194,7 +223,7 @@ 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
 
-chmod 600 "$HOME/.aws/credentials" "$HOME/.aws/config"
+chmod 600 "$credentials_file" "$config_file"
 
 if [ "${LISA_AWS_SKIP_VERIFY:-0}" != "1" ]; then
   AWS_PAGER="" aws sts get-caller-identity --profile "$default_profile" >/dev/null

package/plugins/lisa-agy/plugin.json

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

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

@@ -114,6 +114,27 @@ AWS_CLI_PUBLIC_KEY
   trap - EXIT
 }
 
+remove_profile_setting() {
+  local credentials_file profile setting temporary_file
+  credentials_file="$1"
+  profile="$2"
+  setting="$3"
+  [ -f "$credentials_file" ] || return 0
+
+  temporary_file="$(mktemp "${credentials_file}.XXXXXX")"
+  awk -v profile="$profile" -v setting="$setting" '
+    /^\[[^]]+\][[:space:]]*$/ {
+      section = $0
+      sub(/^\[/, "", section)
+      sub(/\][[:space:]]*$/, "", section)
+      in_profile = section == profile
+    }
+    !(in_profile && $0 ~ "^[[:space:]]*" setting "[[:space:]]*=") { print }
+  ' "$credentials_file" >"$temporary_file"
+  chmod 600 "$temporary_file"
+  mv "$temporary_file" "$credentials_file"
+}
+
 sanitize_session_name() {
   local candidate
   candidate="$(printf '%s' "${LISA_REMOTE_AGENT:-remote-agent}" \
@@ -154,22 +175,30 @@ profiles_json="$(printf '%s' "$bootstrap_json" | jq -c '
   end
 ')"
 
-printf '%s' "$profiles_json" | jq -e '
+printf '%s' "$profiles_json" | jq -e --arg bootstrap_profile "$BOOTSTRAP_PROFILE" '
   type == "object" and length > 0 and
   all(to_entries[];
+    (.key != $bootstrap_profile) and
     (.key | test("^[A-Za-z0-9_-]+$")) and
     (.value.roleArn | type == "string" and startswith("arn:aws:iam::")) and
     (.value.region | type == "string" and length > 0)
   )
 ' >/dev/null || fail "bootstrap profiles must map safe names to roleArn and region"
 
-mkdir -p "$HOME/.aws"
+credentials_file="${AWS_SHARED_CREDENTIALS_FILE:-$HOME/.aws/credentials}"
+config_file="${AWS_CONFIG_FILE:-$HOME/.aws/config}"
+mkdir -p "$HOME/.aws" "$(dirname "$credentials_file")" "$(dirname "$config_file")"
 chmod 700 "$HOME/.aws"
 
 aws configure set aws_access_key_id "$access_key_id" --profile "$BOOTSTRAP_PROFILE"
 aws configure set aws_secret_access_key "$secret_access_key" --profile "$BOOTSTRAP_PROFILE"
 if [ -n "$session_token" ]; then
   aws configure set aws_session_token "$session_token" --profile "$BOOTSTRAP_PROFILE"
+else
+  remove_profile_setting \
+    "$credentials_file" \
+    "$BOOTSTRAP_PROFILE" \
+    "aws_session_token"
 fi
 
 session_name="$(sanitize_session_name)"
@@ -194,7 +223,7 @@ 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
 
-chmod 600 "$HOME/.aws/credentials" "$HOME/.aws/config"
+chmod 600 "$credentials_file" "$config_file"
 
 if [ "${LISA_AWS_SKIP_VERIFY:-0}" != "1" ]; then
   AWS_PAGER="" aws sts get-caller-identity --profile "$default_profile" >/dev/null

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

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

package/plugins/lisa-copilot/rules/eager/history-audit.md

@@ -0,0 +1,27 @@
+# History Audit — Before Removing or Changing Existing Behavior (load-bearing)
+
+When a proposed change would **remove, gate, skip, consolidate, weaken, or relax existing behavior** — and the motivation is your own assessment that the code looks redundant, wasteful, slow, or wrong (rather than a ticket, bug report, or spec) — audit the history **before presenting the change as safe or implementing it**.
+
+## How to apply
+
+1. `git log --follow` the affected files and `git log --grep` for related keywords.
+2. Read **full commit bodies** (never just subjects), code comments, and covering tests — the defense usually lives there, often naming the exact incident the behavior prevents.
+3. Deliver every such recommendation with an explicit verdict:
+   - **Defended by \<commit/comment/test\>** — adapt the proposal to preserve that reason.
+   - **No defense found** — genuinely accidental; safe to change, and say so.
+
+## Scope
+
+- **Diagnosis doesn't need the audit; prescriptions do.** Analyzing what is slow or broken is free; recommending that existing behavior stop happening is what triggers the audit. If presenting unaudited ideas, label them as such.
+- Changes driven by an external requirement may cite that requirement as their defense and move on.
+- "Nothing was deleted" is not an exemption — a change that weakens a guarantee (e.g. adding a cache/stamp that skips a self-healing pass) alters existing behavior and needs the same audit.
+
+## Forbidden
+
+- Recommending removal or weakening of existing behavior as "safe" without the verdict.
+- Auditing subjects only (`--oneline` skims miss the evidence).
+- Treating redundant-looking behavior as accidental by default — defended is the norm, not the exception.
+
+This rule compounds with commit discipline: documenting the **why** in commit bodies is what makes future audits cheap.
+
+Full prose: [reference/history-audit.md](../reference/history-audit.md).

package/plugins/lisa-copilot/rules/reference/history-audit.md

@@ -0,0 +1,42 @@
+# History Audit — Before Removing or Changing Existing Behavior
+
+When a proposed change would remove, gate, skip, consolidate, weaken, or relax existing behavior — and the motivation is your own assessment that the code looks redundant, wasteful, slow, or wrong, rather than a ticket, bug report, or spec — **audit the history before presenting the change as safe or implementing it**. This is Chesterton's fence made operational: the fence's reason is usually written down; go read it.
+
+This is the historical counterpart to the `empirical-inquiry` rule: `empirical-inquiry` establishes facts about how the system behaves *now* by probing it; this rule establishes *why the system behaves that way* by reading the record. Both reject confident-sounding reasoning as a substitute for evidence.
+
+## Why this rule exists
+
+Optimization and cleanup recommendations fail in a characteristic way: the code genuinely *is* doing redundant-looking work, the diagnosis is correct, and the proposed fix would still ship a regression — because the redundancy is load-bearing and its reason lives in a commit body, a code comment, or a test the recommender never read. In a real Lisa incident, a performance audit of the postinstall pipeline produced five recommendations; the history audit walked back two of them (a "redundant" apply pass existed to fix a bootstrap chicken-and-egg; a "wasteful" detached re-run existed because the package manager clobbers `package.json` after lifecycle scripts finish) and confirmed the rest were genuinely accidental. Without the audit, the confident-sounding fixes would have re-shipped bugs that earlier commits had explicitly fixed.
+
+## When this rule applies
+
+- A recommendation proposes that existing behavior stop happening: deleting a code path, gating an unconditional step, deduplicating repeated work, relaxing a guard or retry, skipping a pass "when nothing changed."
+- The motivation is internal — the code *looks* redundant, wasteful, slow, dead, or overcautious — rather than an external requirement.
+- **Nothing needs to be deleted to trigger it.** A change that weakens a guarantee alters existing behavior just as much: adding a cache or version-stamp that skips a self-healing pass, narrowing a matcher, batching what was deliberately serialized.
+
+## When it does not apply
+
+- **Diagnosis is free.** Measuring, profiling, and explaining what is slow or broken needs no audit. The audit gates *prescriptions* — the moment an observation is about to become "so we should remove/skip/gate X."
+- **Requirement-driven changes may cite the requirement.** Implementing a ticket, fixing a reproduced bug, or following a spec supplies external evidence; cite it as the defense and move on. Normal verification discipline covers those.
+- **Spitballing is fine when labeled.** Presenting early ideas before the audit is acceptable if they are explicitly marked as not yet history-audited. What is forbidden is presenting them as safe.
+
+## How to apply it
+
+1. **Trace the artifact history.** `git log --follow` on each affected file; `git log --grep` for related keywords (feature names, flag names, error strings). Find the commits that introduced and last modified the behavior.
+2. **Read the full commit bodies.** Subjects rarely carry the defense; bodies do — often naming the exact incident, the affected projects, and the failure mode the behavior prevents. `--oneline` skims are how the evidence gets missed. Extend the same reading to code comments around the behavior and to tests whose names encode a philosophy (a test called `*-guard` or `*-preserves-*` is a defense).
+3. **Check for a prior removal.** Search for commits that removed the same behavior before — if it was removed and later restored, the restoration commit is the strongest defense on record, and your proposal must answer it specifically.
+4. **Issue a per-recommendation verdict.** Every prescription ships in one of two states:
+   - **Defended by \<commit/comment/test\>** — the behavior has a recorded reason. Adapt the proposal so that reason keeps holding (gate instead of delete, preserve the invariant, keep the escape hatch), and say what the defense was.
+   - **No defense found** — you searched and no commit, comment, or test justifies it. That absence is itself a finding: state it, and proceed.
+
+   The verdict is the enforcement mechanism — it cannot be filled in without doing the audit.
+
+## What this rule forbids
+
+- Presenting the removal or weakening of existing behavior as safe without a verdict.
+- Auditing by subject line only.
+- Treating redundant-looking behavior as accidental by default. In a codebase with disciplined commit messages, *defended* is the norm; genuine accidents are the exception, and the audit is how you tell them apart.
+
+## The compounding loop
+
+This rule only works in a repository whose commit messages record the **why** — which the commit-discipline rules already mandate. The two form a loop: writing down why a behavior exists makes the future audit a five-minute read instead of an archaeology project, and the audit is what makes writing it down pay off. When your own change survives an audit and ships, document its why with the same care — the next agent's audit depends on it.

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

@@ -114,6 +114,27 @@ AWS_CLI_PUBLIC_KEY
   trap - EXIT
 }
 
+remove_profile_setting() {
+  local credentials_file profile setting temporary_file
+  credentials_file="$1"
+  profile="$2"
+  setting="$3"
+  [ -f "$credentials_file" ] || return 0
+
+  temporary_file="$(mktemp "${credentials_file}.XXXXXX")"
+  awk -v profile="$profile" -v setting="$setting" '
+    /^\[[^]]+\][[:space:]]*$/ {
+      section = $0
+      sub(/^\[/, "", section)
+      sub(/\][[:space:]]*$/, "", section)
+      in_profile = section == profile
+    }
+    !(in_profile && $0 ~ "^[[:space:]]*" setting "[[:space:]]*=") { print }
+  ' "$credentials_file" >"$temporary_file"
+  chmod 600 "$temporary_file"
+  mv "$temporary_file" "$credentials_file"
+}
+
 sanitize_session_name() {
   local candidate
   candidate="$(printf '%s' "${LISA_REMOTE_AGENT:-remote-agent}" \
@@ -154,22 +175,30 @@ profiles_json="$(printf '%s' "$bootstrap_json" | jq -c '
   end
 ')"
 
-printf '%s' "$profiles_json" | jq -e '
+printf '%s' "$profiles_json" | jq -e --arg bootstrap_profile "$BOOTSTRAP_PROFILE" '
   type == "object" and length > 0 and
   all(to_entries[];
+    (.key != $bootstrap_profile) and
     (.key | test("^[A-Za-z0-9_-]+$")) and
     (.value.roleArn | type == "string" and startswith("arn:aws:iam::")) and
     (.value.region | type == "string" and length > 0)
   )
 ' >/dev/null || fail "bootstrap profiles must map safe names to roleArn and region"
 
-mkdir -p "$HOME/.aws"
+credentials_file="${AWS_SHARED_CREDENTIALS_FILE:-$HOME/.aws/credentials}"
+config_file="${AWS_CONFIG_FILE:-$HOME/.aws/config}"
+mkdir -p "$HOME/.aws" "$(dirname "$credentials_file")" "$(dirname "$config_file")"
 chmod 700 "$HOME/.aws"
 
 aws configure set aws_access_key_id "$access_key_id" --profile "$BOOTSTRAP_PROFILE"
 aws configure set aws_secret_access_key "$secret_access_key" --profile "$BOOTSTRAP_PROFILE"
 if [ -n "$session_token" ]; then
   aws configure set aws_session_token "$session_token" --profile "$BOOTSTRAP_PROFILE"
+else
+  remove_profile_setting \
+    "$credentials_file" \
+    "$BOOTSTRAP_PROFILE" \
+    "aws_session_token"
 fi
 
 session_name="$(sanitize_session_name)"
@@ -194,7 +223,7 @@ 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
 
-chmod 600 "$HOME/.aws/credentials" "$HOME/.aws/config"
+chmod 600 "$credentials_file" "$config_file"
 
 if [ "${LISA_AWS_SKIP_VERIFY:-0}" != "1" ]; then
   AWS_PAGER="" aws sts get-caller-identity --profile "$default_profile" >/dev/null

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

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

package/plugins/lisa-cursor/rules/history-audit-reference.mdc

@@ -0,0 +1,47 @@
+---
+description: "History Audit — Before Removing or Changing Existing Behavior"
+alwaysApply: false
+---
+
+# History Audit — Before Removing or Changing Existing Behavior
+
+When a proposed change would remove, gate, skip, consolidate, weaken, or relax existing behavior — and the motivation is your own assessment that the code looks redundant, wasteful, slow, or wrong, rather than a ticket, bug report, or spec — **audit the history before presenting the change as safe or implementing it**. This is Chesterton's fence made operational: the fence's reason is usually written down; go read it.
+
+This is the historical counterpart to the `empirical-inquiry` rule: `empirical-inquiry` establishes facts about how the system behaves *now* by probing it; this rule establishes *why the system behaves that way* by reading the record. Both reject confident-sounding reasoning as a substitute for evidence.
+
+## Why this rule exists
+
+Optimization and cleanup recommendations fail in a characteristic way: the code genuinely *is* doing redundant-looking work, the diagnosis is correct, and the proposed fix would still ship a regression — because the redundancy is load-bearing and its reason lives in a commit body, a code comment, or a test the recommender never read. In a real Lisa incident, a performance audit of the postinstall pipeline produced five recommendations; the history audit walked back two of them (a "redundant" apply pass existed to fix a bootstrap chicken-and-egg; a "wasteful" detached re-run existed because the package manager clobbers `package.json` after lifecycle scripts finish) and confirmed the rest were genuinely accidental. Without the audit, the confident-sounding fixes would have re-shipped bugs that earlier commits had explicitly fixed.
+
+## When this rule applies
+
+- A recommendation proposes that existing behavior stop happening: deleting a code path, gating an unconditional step, deduplicating repeated work, relaxing a guard or retry, skipping a pass "when nothing changed."
+- The motivation is internal — the code *looks* redundant, wasteful, slow, dead, or overcautious — rather than an external requirement.
+- **Nothing needs to be deleted to trigger it.** A change that weakens a guarantee alters existing behavior just as much: adding a cache or version-stamp that skips a self-healing pass, narrowing a matcher, batching what was deliberately serialized.
+
+## When it does not apply
+
+- **Diagnosis is free.** Measuring, profiling, and explaining what is slow or broken needs no audit. The audit gates *prescriptions* — the moment an observation is about to become "so we should remove/skip/gate X."
+- **Requirement-driven changes may cite the requirement.** Implementing a ticket, fixing a reproduced bug, or following a spec supplies external evidence; cite it as the defense and move on. Normal verification discipline covers those.
+- **Spitballing is fine when labeled.** Presenting early ideas before the audit is acceptable if they are explicitly marked as not yet history-audited. What is forbidden is presenting them as safe.
+
+## How to apply it
+
+1. **Trace the artifact history.** `git log --follow` on each affected file; `git log --grep` for related keywords (feature names, flag names, error strings). Find the commits that introduced and last modified the behavior.
+2. **Read the full commit bodies.** Subjects rarely carry the defense; bodies do — often naming the exact incident, the affected projects, and the failure mode the behavior prevents. `--oneline` skims are how the evidence gets missed. Extend the same reading to code comments around the behavior and to tests whose names encode a philosophy (a test called `*-guard` or `*-preserves-*` is a defense).
+3. **Check for a prior removal.** Search for commits that removed the same behavior before — if it was removed and later restored, the restoration commit is the strongest defense on record, and your proposal must answer it specifically.
+4. **Issue a per-recommendation verdict.** Every prescription ships in one of two states:
+   - **Defended by \<commit/comment/test\>** — the behavior has a recorded reason. Adapt the proposal so that reason keeps holding (gate instead of delete, preserve the invariant, keep the escape hatch), and say what the defense was.
+   - **No defense found** — you searched and no commit, comment, or test justifies it. That absence is itself a finding: state it, and proceed.
+
+   The verdict is the enforcement mechanism — it cannot be filled in without doing the audit.
+
+## What this rule forbids
+
+- Presenting the removal or weakening of existing behavior as safe without a verdict.
+- Auditing by subject line only.
+- Treating redundant-looking behavior as accidental by default. In a codebase with disciplined commit messages, *defended* is the norm; genuine accidents are the exception, and the audit is how you tell them apart.
+
+## The compounding loop
+
+This rule only works in a repository whose commit messages record the **why** — which the commit-discipline rules already mandate. The two form a loop: writing down why a behavior exists makes the future audit a five-minute read instead of an archaeology project, and the audit is what makes writing it down pay off. When your own change survives an audit and ships, document its why with the same care — the next agent's audit depends on it.

package/plugins/lisa-cursor/rules/history-audit.mdc

@@ -0,0 +1,32 @@
+---
+description: "History Audit — Before Removing or Changing Existing Behavior (load-bearing)"
+alwaysApply: true
+---
+
+# History Audit — Before Removing or Changing Existing Behavior (load-bearing)
+
+When a proposed change would **remove, gate, skip, consolidate, weaken, or relax existing behavior** — and the motivation is your own assessment that the code looks redundant, wasteful, slow, or wrong (rather than a ticket, bug report, or spec) — audit the history **before presenting the change as safe or implementing it**.
+
+## How to apply
+
+1. `git log --follow` the affected files and `git log --grep` for related keywords.
+2. Read **full commit bodies** (never just subjects), code comments, and covering tests — the defense usually lives there, often naming the exact incident the behavior prevents.
+3. Deliver every such recommendation with an explicit verdict:
+   - **Defended by \<commit/comment/test\>** — adapt the proposal to preserve that reason.
+   - **No defense found** — genuinely accidental; safe to change, and say so.
+
+## Scope
+
+- **Diagnosis doesn't need the audit; prescriptions do.** Analyzing what is slow or broken is free; recommending that existing behavior stop happening is what triggers the audit. If presenting unaudited ideas, label them as such.
+- Changes driven by an external requirement may cite that requirement as their defense and move on.
+- "Nothing was deleted" is not an exemption — a change that weakens a guarantee (e.g. adding a cache/stamp that skips a self-healing pass) alters existing behavior and needs the same audit.
+
+## Forbidden
+
+- Recommending removal or weakening of existing behavior as "safe" without the verdict.
+- Auditing subjects only (`--oneline` skims miss the evidence).
+- Treating redundant-looking behavior as accidental by default — defended is the norm, not the exception.
+
+This rule compounds with commit discipline: documenting the **why** in commit bodies is what makes future audits cheap.
+
+Full prose: [reference/history-audit.md](history-audit-reference.mdc).

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

@@ -114,6 +114,27 @@ AWS_CLI_PUBLIC_KEY
   trap - EXIT
 }
 
+remove_profile_setting() {
+  local credentials_file profile setting temporary_file
+  credentials_file="$1"
+  profile="$2"
+  setting="$3"
+  [ -f "$credentials_file" ] || return 0
+
+  temporary_file="$(mktemp "${credentials_file}.XXXXXX")"
+  awk -v profile="$profile" -v setting="$setting" '
+    /^\[[^]]+\][[:space:]]*$/ {
+      section = $0
+      sub(/^\[/, "", section)
+      sub(/\][[:space:]]*$/, "", section)
+      in_profile = section == profile
+    }
+    !(in_profile && $0 ~ "^[[:space:]]*" setting "[[:space:]]*=") { print }
+  ' "$credentials_file" >"$temporary_file"
+  chmod 600 "$temporary_file"
+  mv "$temporary_file" "$credentials_file"
+}
+
 sanitize_session_name() {
   local candidate
   candidate="$(printf '%s' "${LISA_REMOTE_AGENT:-remote-agent}" \
@@ -154,22 +175,30 @@ profiles_json="$(printf '%s' "$bootstrap_json" | jq -c '
   end
 ')"
 
-printf '%s' "$profiles_json" | jq -e '
+printf '%s' "$profiles_json" | jq -e --arg bootstrap_profile "$BOOTSTRAP_PROFILE" '
   type == "object" and length > 0 and
   all(to_entries[];
+    (.key != $bootstrap_profile) and
     (.key | test("^[A-Za-z0-9_-]+$")) and
     (.value.roleArn | type == "string" and startswith("arn:aws:iam::")) and
     (.value.region | type == "string" and length > 0)
   )
 ' >/dev/null || fail "bootstrap profiles must map safe names to roleArn and region"
 
-mkdir -p "$HOME/.aws"
+credentials_file="${AWS_SHARED_CREDENTIALS_FILE:-$HOME/.aws/credentials}"
+config_file="${AWS_CONFIG_FILE:-$HOME/.aws/config}"
+mkdir -p "$HOME/.aws" "$(dirname "$credentials_file")" "$(dirname "$config_file")"
 chmod 700 "$HOME/.aws"
 
 aws configure set aws_access_key_id "$access_key_id" --profile "$BOOTSTRAP_PROFILE"
 aws configure set aws_secret_access_key "$secret_access_key" --profile "$BOOTSTRAP_PROFILE"
 if [ -n "$session_token" ]; then
   aws configure set aws_session_token "$session_token" --profile "$BOOTSTRAP_PROFILE"
+else
+  remove_profile_setting \
+    "$credentials_file" \
+    "$BOOTSTRAP_PROFILE" \
+    "aws_session_token"
 fi
 
 session_name="$(sanitize_session_name)"
@@ -194,7 +223,7 @@ 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
 
-chmod 600 "$HOME/.aws/credentials" "$HOME/.aws/config"
+chmod 600 "$credentials_file" "$config_file"
 
 if [ "${LISA_AWS_SKIP_VERIFY:-0}" != "1" ]; then
   AWS_PAGER="" aws sts get-caller-identity --profile "$default_profile" >/dev/null

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric-agy/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Harper/Fabric-specific rules for TypeScript component apps",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "NestJS-specific skills and migration write-protection hooks.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-openclaw",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Connect staff roles to Telegram or Slack via OpenClaw — facilitator/specialist hub-and-spoke routing and repo-coding topics, for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-phaser",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Phaser 4 game-development rules for TypeScript projects",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Ruby on Rails-specific skills and hooks for RuboCop and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.226.1",
+  "version": "2.227.0",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/rules/eager/history-audit.md

@@ -0,0 +1,27 @@
+# History Audit — Before Removing or Changing Existing Behavior (load-bearing)
+
+When a proposed change would **remove, gate, skip, consolidate, weaken, or relax existing behavior** — and the motivation is your own assessment that the code looks redundant, wasteful, slow, or wrong (rather than a ticket, bug report, or spec) — audit the history **before presenting the change as safe or implementing it**.
+
+## How to apply
+
+1. `git log --follow` the affected files and `git log --grep` for related keywords.
+2. Read **full commit bodies** (never just subjects), code comments, and covering tests — the defense usually lives there, often naming the exact incident the behavior prevents.
+3. Deliver every such recommendation with an explicit verdict:
+   - **Defended by \<commit/comment/test\>** — adapt the proposal to preserve that reason.
+   - **No defense found** — genuinely accidental; safe to change, and say so.
+
+## Scope
+
+- **Diagnosis doesn't need the audit; prescriptions do.** Analyzing what is slow or broken is free; recommending that existing behavior stop happening is what triggers the audit. If presenting unaudited ideas, label them as such.
+- Changes driven by an external requirement may cite that requirement as their defense and move on.
+- "Nothing was deleted" is not an exemption — a change that weakens a guarantee (e.g. adding a cache/stamp that skips a self-healing pass) alters existing behavior and needs the same audit.
+
+## Forbidden
+
+- Recommending removal or weakening of existing behavior as "safe" without the verdict.
+- Auditing subjects only (`--oneline` skims miss the evidence).
+- Treating redundant-looking behavior as accidental by default — defended is the norm, not the exception.
+
+This rule compounds with commit discipline: documenting the **why** in commit bodies is what makes future audits cheap.
+
+Full prose: [reference/history-audit.md](../reference/history-audit.md).

package/plugins/src/base/rules/reference/history-audit.md

@@ -0,0 +1,42 @@
+# History Audit — Before Removing or Changing Existing Behavior
+
+When a proposed change would remove, gate, skip, consolidate, weaken, or relax existing behavior — and the motivation is your own assessment that the code looks redundant, wasteful, slow, or wrong, rather than a ticket, bug report, or spec — **audit the history before presenting the change as safe or implementing it**. This is Chesterton's fence made operational: the fence's reason is usually written down; go read it.
+
+This is the historical counterpart to the `empirical-inquiry` rule: `empirical-inquiry` establishes facts about how the system behaves *now* by probing it; this rule establishes *why the system behaves that way* by reading the record. Both reject confident-sounding reasoning as a substitute for evidence.
+
+## Why this rule exists
+
+Optimization and cleanup recommendations fail in a characteristic way: the code genuinely *is* doing redundant-looking work, the diagnosis is correct, and the proposed fix would still ship a regression — because the redundancy is load-bearing and its reason lives in a commit body, a code comment, or a test the recommender never read. In a real Lisa incident, a performance audit of the postinstall pipeline produced five recommendations; the history audit walked back two of them (a "redundant" apply pass existed to fix a bootstrap chicken-and-egg; a "wasteful" detached re-run existed because the package manager clobbers `package.json` after lifecycle scripts finish) and confirmed the rest were genuinely accidental. Without the audit, the confident-sounding fixes would have re-shipped bugs that earlier commits had explicitly fixed.
+
+## When this rule applies
+
+- A recommendation proposes that existing behavior stop happening: deleting a code path, gating an unconditional step, deduplicating repeated work, relaxing a guard or retry, skipping a pass "when nothing changed."
+- The motivation is internal — the code *looks* redundant, wasteful, slow, dead, or overcautious — rather than an external requirement.
+- **Nothing needs to be deleted to trigger it.** A change that weakens a guarantee alters existing behavior just as much: adding a cache or version-stamp that skips a self-healing pass, narrowing a matcher, batching what was deliberately serialized.
+
+## When it does not apply
+
+- **Diagnosis is free.** Measuring, profiling, and explaining what is slow or broken needs no audit. The audit gates *prescriptions* — the moment an observation is about to become "so we should remove/skip/gate X."
+- **Requirement-driven changes may cite the requirement.** Implementing a ticket, fixing a reproduced bug, or following a spec supplies external evidence; cite it as the defense and move on. Normal verification discipline covers those.
+- **Spitballing is fine when labeled.** Presenting early ideas before the audit is acceptable if they are explicitly marked as not yet history-audited. What is forbidden is presenting them as safe.
+
+## How to apply it
+
+1. **Trace the artifact history.** `git log --follow` on each affected file; `git log --grep` for related keywords (feature names, flag names, error strings). Find the commits that introduced and last modified the behavior.
+2. **Read the full commit bodies.** Subjects rarely carry the defense; bodies do — often naming the exact incident, the affected projects, and the failure mode the behavior prevents. `--oneline` skims are how the evidence gets missed. Extend the same reading to code comments around the behavior and to tests whose names encode a philosophy (a test called `*-guard` or `*-preserves-*` is a defense).
+3. **Check for a prior removal.** Search for commits that removed the same behavior before — if it was removed and later restored, the restoration commit is the strongest defense on record, and your proposal must answer it specifically.
+4. **Issue a per-recommendation verdict.** Every prescription ships in one of two states:
+   - **Defended by \<commit/comment/test\>** — the behavior has a recorded reason. Adapt the proposal so that reason keeps holding (gate instead of delete, preserve the invariant, keep the escape hatch), and say what the defense was.
+   - **No defense found** — you searched and no commit, comment, or test justifies it. That absence is itself a finding: state it, and proceed.
+
+   The verdict is the enforcement mechanism — it cannot be filled in without doing the audit.
+
+## What this rule forbids
+
+- Presenting the removal or weakening of existing behavior as safe without a verdict.
+- Auditing by subject line only.
+- Treating redundant-looking behavior as accidental by default. In a codebase with disciplined commit messages, *defended* is the norm; genuine accidents are the exception, and the audit is how you tell them apart.
+
+## The compounding loop
+
+This rule only works in a repository whose commit messages record the **why** — which the commit-discipline rules already mandate. The two form a loop: writing down why a behavior exists makes the future audit a five-minute read instead of an archaeology project, and the audit is what makes writing it down pay off. When your own change survives an audit and ships, document its why with the same care — the next agent's audit depends on it.

package/plugins/src/base/scripts/remote-agent-aws-setup.sh

@@ -114,6 +114,27 @@ AWS_CLI_PUBLIC_KEY
   trap - EXIT
 }
 
+remove_profile_setting() {
+  local credentials_file profile setting temporary_file
+  credentials_file="$1"
+  profile="$2"
+  setting="$3"
+  [ -f "$credentials_file" ] || return 0
+
+  temporary_file="$(mktemp "${credentials_file}.XXXXXX")"
+  awk -v profile="$profile" -v setting="$setting" '
+    /^\[[^]]+\][[:space:]]*$/ {
+      section = $0
+      sub(/^\[/, "", section)
+      sub(/\][[:space:]]*$/, "", section)
+      in_profile = section == profile
+    }
+    !(in_profile && $0 ~ "^[[:space:]]*" setting "[[:space:]]*=") { print }
+  ' "$credentials_file" >"$temporary_file"
+  chmod 600 "$temporary_file"
+  mv "$temporary_file" "$credentials_file"
+}
+
 sanitize_session_name() {
   local candidate
   candidate="$(printf '%s' "${LISA_REMOTE_AGENT:-remote-agent}" \
@@ -154,22 +175,30 @@ profiles_json="$(printf '%s' "$bootstrap_json" | jq -c '
   end
 ')"
 
-printf '%s' "$profiles_json" | jq -e '
+printf '%s' "$profiles_json" | jq -e --arg bootstrap_profile "$BOOTSTRAP_PROFILE" '
   type == "object" and length > 0 and
   all(to_entries[];
+    (.key != $bootstrap_profile) and
     (.key | test("^[A-Za-z0-9_-]+$")) and
     (.value.roleArn | type == "string" and startswith("arn:aws:iam::")) and
     (.value.region | type == "string" and length > 0)
   )
 ' >/dev/null || fail "bootstrap profiles must map safe names to roleArn and region"
 
-mkdir -p "$HOME/.aws"
+credentials_file="${AWS_SHARED_CREDENTIALS_FILE:-$HOME/.aws/credentials}"
+config_file="${AWS_CONFIG_FILE:-$HOME/.aws/config}"
+mkdir -p "$HOME/.aws" "$(dirname "$credentials_file")" "$(dirname "$config_file")"
 chmod 700 "$HOME/.aws"
 
 aws configure set aws_access_key_id "$access_key_id" --profile "$BOOTSTRAP_PROFILE"
 aws configure set aws_secret_access_key "$secret_access_key" --profile "$BOOTSTRAP_PROFILE"
 if [ -n "$session_token" ]; then
   aws configure set aws_session_token "$session_token" --profile "$BOOTSTRAP_PROFILE"
+else
+  remove_profile_setting \
+    "$credentials_file" \
+    "$BOOTSTRAP_PROFILE" \
+    "aws_session_token"
 fi
 
 session_name="$(sanitize_session_name)"
@@ -194,7 +223,7 @@ 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
 
-chmod 600 "$HOME/.aws/credentials" "$HOME/.aws/config"
+chmod 600 "$credentials_file" "$config_file"
 
 if [ "${LISA_AWS_SKIP_VERIFY:-0}" != "1" ]; then
   AWS_PAGER="" aws sts get-caller-identity --profile "$default_profile" >/dev/null