@codyswann/lisa 2.293.1 → 2.295.0

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.293.1",
+  "version": "2.295.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.293.1",
+  "version": "2.295.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.293.1",
+  "version": "2.295.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/config-resolution.md

@@ -91,7 +91,8 @@ forward cherry-picked down to the integration branch via a linked follow-up.
 `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.
+a configured done status whose env has no branch is a config error — unless its value is exactly
+the built-in default (a sync-materialized fallback, invisible everywhere: stripped before the
+union, never blocking the alias) — 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

@@ -636,9 +636,21 @@ configured surfaces (`deploy.branches`, the configured done map,
 configured spelling. When both spellings appear they are distinct environments
 and no aliasing occurs. No other alias exists.
 
+**Materialized defaults are fallbacks.** `lisa sync` writes the full default
+done map into config, so a configured done-map entry whose value is EXACTLY
+the default table's value for that env is treated as a materialized fallback,
+not operator intent — and it is invisible for ALL purposes: stripped before
+the env-key union is computed, it never blocks the sole `prod` ↔ `production`
+alias, never raises the done-without-branch error, and leaves the env exactly
+as if it were unconfigured (so `branches.prod` beside a materialized
+`production` entry still aliases to one prod rung). Only a value that DIFFERS
+from the default is deliberate configuration: it participates in the union
+(blocking the alias when it introduces the other spelling) and stays
+protected by the error below.
+
 **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 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.` (custom values only — default-identical entries fall back silently)
 - `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.`

package/rails/create-only/.github/workflows/deploy.yml

@@ -32,6 +32,11 @@ jobs:
     if: ${{ github.event_name != 'push' || !startsWith(github.event.head_commit.message, 'chore(release):') }}
     runs-on: ubuntu-latest
     timeout-minutes: 30
+    # Declaring the environment makes GitHub emit deployment /
+    # deployment_status events for this run — the substrate that
+    # deploy-status-sync listens to. No determine_environment job exists in
+    # this workflow; the ternary mirrors the APP_STAGE branch logic below.
+    environment: ${{ github.ref_name == 'main' && 'production' || github.ref_name }}
     permissions:
       id-token: write # needed to interact with GitHub's OIDC Token endpoint.
       contents: read

package/typescript/copy-overwrite/.github/GITHUB_ACTIONS.md

@@ -149,6 +149,34 @@ an unprovisioned gate blocks nothing. Not yet wired for rails
 (`release-rails.yml` doesn't thread approval inputs) or harper-fabric (no
 release.yml call).
 
+**Your deploy job declares a GitHub environment** (deploy-status-sync
+substrate): the deploy job in this project's `deploy.yml` carries an
+`environment:` declaration so every deploy run emits `deployment` /
+`deployment_status` events — the substrate that deploy-status-sync (and
+GitHub-for-Jira) listens to. Stacks with a `determine_environment` job reuse
+its friendly-name resolution
+(`needs.determine_environment.outputs.approval_environment`; unconfigured
+branches degrade to the branch name, same as the approval gate); stacks
+without one use the branch ternary
+`github.ref_name == 'main' && 'production' || github.ref_name`. CDK projects
+own their deploy job — declare the environment on it per the commented
+snippet in the template `deploy.yml`. Exactly one deploy job per workflow
+declares an environment (the job that mutates the target); release/build
+bookkeeping jobs never do.
+
+GitHub environment approvals are **per-job**. If your deploy job named the same
+protected environment as the `release_approval` gate, an approval-gated run
+would prompt you **twice**. To avoid that, on approval-gated runs
+(`determine_environment` sets `require_approval`) the deploy job routes its
+environment to `<env>-deploy` (`format('{0}-deploy', <env>)`) rather than the
+bare env. Leave `<env>-deploy` **unprotected** (no required reviewers): the gate
+fires once at `release_approval`, and the deploy job proceeds without a second
+prompt. A gated run records two deployments — the gate against `<env>` and the
+deploy job against `<env>-deploy` — and the `-deploy` suffix keeps the
+`dev`/`staging`/`production` substring so GitHub-for-Jira still classifies it.
+Ungated runs use the bare env; stacks without a `determine_environment` job
+(rails, harper-fabric) are never gated and need no suffix.
+
 **Blackout Periods** (configurable):
 - Production: No weekends, no late nights (10 PM - 6 AM)
 - Holiday blackouts: Dec 24 - Jan 2, Jul 3-5, Nov 27-29