@codyswann/lisa 2.290.0 → 2.292.0

package/plugins/src/base/rules/eager/config-resolution.md

@@ -86,4 +86,12 @@ A non-integration environment bug is fixed, merged, and verified on that
 environment branch first, then
 forward cherry-picked down to the integration branch via a linked follow-up.
 
+## Deploy status sync
+
+`deployStatusSync` is an optional machine-written config block (`tier`, `provisioned` ids,
+`linearBinding: labels|states`, `verifiedAt`). The deploy ladder is `deploy.order` (else canonical
+`dev < staging < production`) over `deploy.branches` joined with the tracker's env-keyed done map;
+a configured done status whose env has no branch is a config error, and the sole
+`prod` ↔ `production` alias applies to the join.
+
 Full reference: [reference/config-resolution.md](../reference/config-resolution.md).

package/plugins/src/base/rules/reference/config-resolution.md

@@ -596,6 +596,53 @@ This is the same `deploy.branches` map already used by env-keyed `done` (reverse
 env from PR base branch) and the build flow (forward: base branch from env);
 `deploy.order` only adds the ranking those two directions never needed.
 
+### Deploy status sync (deployStatusSync)
+
+`deployStatusSync` is an **optional, machine-written** section recorded by the
+deploy-status-sync setup flow. Humans never need to author it; unknown fields
+inside it are preserved on round-trip.
+
+| Field | Type | Default | Meaning |
+| --- | --- | --- | --- |
+| `tier` | string | — | Provisioning tier chosen at setup time |
+| `provisioned` | object (string → string) | — | Provisioned tracker artifact ids, keyed by artifact name |
+| `linearBinding` | `"labels"` \| `"states"` | — | Whether Linear deploy statuses are represented as labels or workflow states |
+| `verifiedAt` | string | — | Strict ISO-8601 UTC timestamp (`Z` suffix, e.g. `2026-01-01T00:00:00Z`) of the last successful verification |
+
+**Ladder resolution.** The environment universe is the keys of
+`deploy.branches`. Each env's done status comes from the tracker's env-keyed
+done map — `github.labels.build.done`, `linear.labels.build.done`, or
+`jira.workflow.done` — with configured entries winning over the built-in
+defaults (`status:on-dev` / `status:on-stg` / `status:done` for label trackers;
+`On Dev` / `On Stg` / `Done` for JIRA). Environments are ordered by
+`deploy.order` when present (its env-name set must exactly match the keys of
+`deploy.branches`); otherwise by the canonical `dev < staging < production`
+rank, and an unrankable custom env name with more than one env configured is a
+config error rather than a guess. A string-valued `done` binds only the
+terminal (highest) rung; lower rungs fall back to the default table. An env
+with a branch but no done status anywhere (possible only for custom names
+outside the default tables) is **skipped**, not an error; an explicitly
+configured done status whose env has no branch **is** a config error. A ladder
+is flagged terminal-only when it resolves to exactly one rung **and** that
+rung's env is the highest-ranked environment of the configured universe
+(post-alias) — a sole surviving lower rung after skips is NOT terminal-only,
+so downstream native closure never fires on an intermediate environment.
+Absent or empty `deploy` yields an empty ladder, never an error.
+
+**Alias.** Iff exactly one of `prod` / `production` appears across the
+configured surfaces (`deploy.branches`, the configured done map,
+`deploy.order`), the two spellings join as one environment — so
+`branches.prod` meets the default `done.production` — and rungs report the
+configured spelling. When both spellings appear they are distinct environments
+and no aliasing occurs. No other alias exists.
+
+**Error catalog** (verbatim):
+
+- `Invalid deploy configuration in <source>: a done status ("<status>") is configured for environment "<env>", but deploy.branches has no "<env>" entry. Add deploy.branches.<env> (the git branch that deploys to <env>) or remove "<env>" from the done map.`
+- `Invalid deploy.order in <source>: its environment names must exactly match the keys of deploy.branches. deploy.order has [<order-envs>]; deploy.branches has [<branch-envs>].` (also raised for duplicate `deploy.order` entries)
+- `Invalid deploy.order in <source>: every entry must be an environment name string; found <entry>.`
+- `Invalid deploy configuration in <source>: cannot order environment "<env>". Set deploy.order (environments listed lowest first, e.g. ["dev","staging","production"]) so Lisa knows the promotion order.`
+
 ### What's configurable, what's not
 
 - **Status / label NAMES** are configurable per project — that's the point of the vocabulary maps.

package/plugins/src/base/skills/lisa-parity-safety-net-rules/SKILL.md

@@ -53,11 +53,47 @@ RULES_FILE="${SAFETY_NET_RULES_FILE:-${CLAUDE_PROJECT_DIR:-$PWD}/.claude/safety-
 
 ### Built-in guards (always on)
 
-1. `rm -rf` of a filesystem root, `$HOME`/`~`, or a top-level wildcard.
-2. Force-pushing a protected branch (`main`/`master`/`production`/`release`).
-   `--force-with-lease` is intentionally allowed.
-3. `git reset --hard` while the working tree is **dirty** (would discard work).
-4. Destructive SQL — `DROP DATABASE/SCHEMA/TABLE`, `TRUNCATE TABLE`.
+1. `rm -rf` of a filesystem root, `$HOME`/`~`, or a top-level wildcard — with
+   quote-aware boundaries, so wrapper/interpreter forms like
+   `bash -c "rm -rf /"` and `python -c "… os.system('rm -rf /')"` match too.
+   Path-prefixed spellings (`/bin/rm`, `./rm`) count as `rm` for every rm
+   guard.
+2. `rm -rf` target hardening: the cwd itself (`.`/`./`), `..`-traversal paths,
+   home-anchored `~/…` paths, absolute paths outside the project (`/tmp`,
+   `/var/tmp`, and `$TMPDIR` are allowed), `$VAR` targets other than `$TMPDIR`,
+   and **any** recursive forced delete while the working directory is `$HOME`.
+3. Force-pushing a protected branch
+   (`main`/`master`/`production`/`prod`/`release`). `--force-with-lease` is
+   intentionally allowed, and so is force-pushing a feature branch (sanctioned
+   rebase workflow). Acceptable parity divergence: a refspec force-push
+   (`git push origin +main`) is not blocked — upstream 1.0.6 allows it too.
+4. `git reset --hard` / `git reset --merge` while the working tree is **dirty**
+   (would discard work). Clean-tree resets are intentionally allowed.
+5. `git checkout` discards: the `--` pathspec form (with or without a ref),
+   `-f`/`--force`, `--pathspec-from-file`, and bare `git checkout .`.
+   Branch switching and `-b`/`-B` creation stay allowed.
+6. `git switch --discard-changes` / `-f`/`--force`.
+7. `git restore` touching the worktree — only `git restore --staged <path>`
+   without `--worktree` is allowed (unstaging is safe).
+8. `git stash drop` / `git stash clear` (push/pop/list/apply stay allowed).
+9. `git clean` with a force flag and no dry-run — `-n`/`--dry-run` anywhere
+   makes it a safe preview.
+10. `git branch -D` (or `-d` combined with `-f`, clustered or split);
+    safe `-d` and rename `-m` stay allowed.
+11. `git tag -d`, `git reflog delete`, `git worktree remove --force`.
+12. Deletion via `find … -delete`, `find … -exec rm -rf`, and `xargs … rm -rf`
+    (plain non-recursive `rm` on find/xargs output stays allowed).
+13. Disk destroyers: `dd of=/dev/…`, `mkfs … /dev/…`, `shred`.
+14. Destructive SQL — `DROP DATABASE/SCHEMA/TABLE`, `TRUNCATE TABLE`.
+
+Every git guard sees through leading git **global options** (`-C <path>`,
+`-c <k>=<v>`, `--git-dir[=…]`, `--no-pager`, …), so `git -C /path <destructive>`
+is screened the same as `git <destructive>`.
+
+Malformed hook input fails **closed** (exit 2 denies the command). A text-scan
+hook cannot exempt display commands, so prose like
+`echo "docs about rm -rf /"` can false-positive — quote-break the string or use
+the gh-writer heredoc form (payload is stripped before the guards run).
 
 ## View the current rules
 

package/rails/merge/.claude/settings.json

@@ -5,7 +5,7 @@
   },
   "enabledPlugins": {
     "ruby-lsp@claude-plugins-official": true,
-    "safety-net@cc-marketplace": true,
+    "safety-net@cc-marketplace": false,
     "code-simplifier@claude-plugins-official": true,
     "code-review@claude-plugins-official": true,
     "coderabbit@claude-plugins-official": true,

package/scripts/install-claude-plugins.sh

@@ -526,19 +526,22 @@ for plugin in \
   "code-review@claude-plugins-official" \
   "coderabbit@claude-plugins-official" \
   "skill-creator@claude-plugins-official" \
-  "atlassian@claude-plugins-official" \
-  "safety-net@cc-marketplace"; do
+  "atlassian@claude-plugins-official"; do
   install_plugin_if_missing "$plugin"
 done
 
 # Retire third-party plugins Lisa no longer curates. The base lisa plugin
 # bundles the Sentry MCP server (plugins/src/base/.mcp.json) for every agent
 # runtime, so the upstream sentry plugin registered the same server twice in
-# each Claude session (issue #1955). The merge settings templates flip its
-# enabledPlugins entry to false; this removes the install itself. Version-gated
-# like the other one-time heals so same-version runs don't spawn the CLI.
+# each Claude session (issue #1955). Likewise, the Lisa-native
+# parity-safety-net.sh hook screens every Bash command, so the upstream
+# safety-net plugin double-screened each command; its material guards were
+# absorbed into the Lisa hook (issue #1960). The merge settings templates flip
+# both enabledPlugins entries to false; this removes the installs themselves.
+# Version-gated like the other one-time heals so same-version runs don't spawn
+# the CLI.
 if [ "$FORCE_PLUGIN_SYNC" = "true" ]; then
-  for retired_plugin in "sentry@claude-plugins-official"; do
+  for retired_plugin in "sentry@claude-plugins-official" "safety-net@cc-marketplace"; do
     claude plugin uninstall "$retired_plugin" --scope project </dev/null >/dev/null 2>&1 || true
   done
 fi

package/typescript/merge/.claude/settings.json

@@ -6,7 +6,7 @@
   "enabledPlugins": {
     "lisa-typescript@lisa": true,
     "typescript-lsp@claude-plugins-official": true,
-    "safety-net@cc-marketplace": true,
+    "safety-net@cc-marketplace": false,
     "code-simplifier@claude-plugins-official": true,
     "code-review@claude-plugins-official": true,
     "coderabbit@claude-plugins-official": true,