@codyswann/lisa 2.205.0 → 2.205.1

package/package.json

@@ -95,7 +95,7 @@
     "ws": ">=8.20.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/rules/eager/upstream-to-lisa.md

@@ -1,15 +1,20 @@
 # Upstream To Lisa (load-bearing)
 
-When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project — a bug or gap in a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, or a governance pattern worth generalizing back to the templates. Tell-tale signs: the file you want to change is Lisa-managed (carries Lisa governance markers, or lives in a path Lisa owns), and any edit you make here would be **overwritten on the next `lisa apply`**.
+When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project — a bug or gap in a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, or a governance pattern worth generalizing back to the templates. The defining test: **does the root cause live in a Lisa-distributed artifact?** If yes, file upstream, regardless of whether your local fix survives the next `lisa apply`.
+
+Tell-tale signs include:
+
+- The file is Lisa-managed (carries Lisa governance markers, or lives in a path Lisa owns) and any edit you make here would be **overwritten on the next `lisa apply`**.
+- The file was created from a Lisa `create-only` template and carries language such as `Lisa will not overwrite it`. That header is a positive upstream signal: existing repos will keep their local copy, but every newly scaffolded repo still inherits the broken template until Lisa is fixed.
 
 When that happens, you have **two obligations — do both**:
 
-1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. Treat it as temporary: it will be clobbered when the upstream fix ships and Lisa re-applies. Do not wait on the upstream fix.
+1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. For copy-overwrite files, treat the local fix as temporary because it will be clobbered when the upstream fix ships and Lisa re-applies. For create-only files, keep the local fix because Lisa will not overwrite it, but still file upstream so new repos stop inheriting the bug.
 2. **File an upstream issue in the Lisa repository.** Use the `github-write-issue` skill (`lisa-github-write-issue`) to create an issue **in Lisa's source repo `CodySwannGT/lisa`** (pass it as the target repo, e.g. `gh ... --repo CodySwannGT/lisa`) — **not** in this project's own repo. Capture: the root cause, the symptom you hit here, and the proposed durable fix in Lisa's templates/rules/skills.
 
 ## Do not
 
-- Do **not** only fix it locally and move on — the local fix is throwaway; without the upstream issue the root cause is lost and re-breaks on the next apply.
+- Do **not** only fix it locally and move on — even when a create-only local fix survives, the broken template keeps shipping to every new repo until it is fixed upstream.
 - Do **not** try to edit Lisa's templates from inside this project — you are not in the Lisa repo; those edits don't exist upstream and get overwritten.
 - Do **not** file the issue in this project's repo — it must land in `CodySwannGT/lisa`.
 

package/plugins/lisa/rules/reference/upstream-to-lisa.md

@@ -9,14 +9,25 @@ You are working in a downstream/host project (not the Lisa source repo) and you
 - A bug or gap in a Lisa-distributed **template, rule, skill, agent, hook, or CI workflow**.
 - A **governance pattern** discovered here that should be generalized back into Lisa's templates so every project benefits.
 - Anything where the file you want to change is **Lisa-managed** — it carries Lisa governance markers, lives in a path Lisa owns, or any edit would be **overwritten on the next `lisa apply`**.
+- Anything where the root cause is in a Lisa **create-only** template, even if the generated file says Lisa will not overwrite it.
 
-The defining test: *if I fix this only here, does `lisa apply` wipe it out next time?* If yes, the root cause lives in Lisa and must be upstreamed.
+The defining test: **does the root cause live in a Lisa-distributed artifact?** If yes, file upstream. The wipe-out test is a sufficient signal, not the only signal.
+
+| Template class | Local fix survives `lisa apply`? | Why it is still upstream-worthy |
+| --- | --- | --- |
+| **copy-overwrite** (managed) | No — clobbered on next apply | The local fix is throwaway; without the upstream fix it re-breaks. |
+| **create-only** (first setup) | Yes — Lisa never overwrites it | No existing repo self-heals, and every newly scaffolded repo inherits the bug. |
+
+For create-only files, header text such as `Lisa will not overwrite it` is a **positive** upstream signal, not a reason to stay local. Keep the downstream fix because Lisa will not replace it, and still file upstream so future projects receive the corrected template.
 
 ## What to do — both steps, always
 
 ### 1. Fix it locally so you are not blocked
 
-Apply the stopgap in this project so you can keep working. Do **not** stall waiting for an upstream fix to land. Treat the local change as temporary — it will be clobbered when the upstream fix ships and Lisa re-applies. That is expected and fine; the upstream issue (step 2) is what makes it durable.
+Apply the stopgap in this project so you can keep working. Do **not** stall waiting for an upstream fix to land.
+
+- For copy-overwrite files, treat the local change as temporary: it will be clobbered when the upstream fix ships and Lisa re-applies.
+- For create-only files, keep the local change: Lisa will not overwrite it. The upstream issue is still mandatory because new projects keep inheriting the broken template until Lisa changes.
 
 ### 2. File an upstream issue in the Lisa repository
 
@@ -27,11 +38,11 @@ The issue should capture, following the skill's three-audience / acceptance-crit
 - **Root cause** — which Lisa template/rule/skill/agent/hook/workflow is wrong or missing, with the path under `plugins/src/...` (or the relevant template source) if known.
 - **Symptom** — what broke or was missing in *this* project, and how it surfaced. Reference this project so the fix can be validated against a real case.
 - **Proposed durable fix** — the change to make in Lisa's source so it propagates to all projects on the next apply.
-- **Local stopgap applied** — note that a temporary local fix is in place here, so the maintainer knows the host project is unblocked and the local change will be superseded.
+- **Local stopgap applied** — note that a local fix is in place here, whether it is temporary copy-overwrite work or a retained create-only patch.
 
 ## Do not
 
-- Do **not** only fix it locally and move on. The local fix is throwaway; without the upstream issue the root cause is lost and re-breaks for every project on the next apply.
+- Do **not** only fix it locally and move on. For copy-overwrite files, the local fix is throwaway and re-breaks on the next apply. For create-only files, the local fix survives, but the broken template still ships to every new project.
 - Do **not** edit Lisa's templates from inside this project. You are not in the Lisa repo; those edits don't exist upstream and get overwritten — they create the illusion of a fix while the real source stays broken.
 - Do **not** file the issue in this project's own repo. The durable fix is tracked in `CodySwannGT/lisa`.
 

package/plugins/lisa-agy/plugin.json

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

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

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

package/plugins/lisa-copilot/rules/eager/upstream-to-lisa.md

@@ -1,15 +1,20 @@
 # Upstream To Lisa (load-bearing)
 
-When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project — a bug or gap in a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, or a governance pattern worth generalizing back to the templates. Tell-tale signs: the file you want to change is Lisa-managed (carries Lisa governance markers, or lives in a path Lisa owns), and any edit you make here would be **overwritten on the next `lisa apply`**.
+When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project — a bug or gap in a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, or a governance pattern worth generalizing back to the templates. The defining test: **does the root cause live in a Lisa-distributed artifact?** If yes, file upstream, regardless of whether your local fix survives the next `lisa apply`.
+
+Tell-tale signs include:
+
+- The file is Lisa-managed (carries Lisa governance markers, or lives in a path Lisa owns) and any edit you make here would be **overwritten on the next `lisa apply`**.
+- The file was created from a Lisa `create-only` template and carries language such as `Lisa will not overwrite it`. That header is a positive upstream signal: existing repos will keep their local copy, but every newly scaffolded repo still inherits the broken template until Lisa is fixed.
 
 When that happens, you have **two obligations — do both**:
 
-1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. Treat it as temporary: it will be clobbered when the upstream fix ships and Lisa re-applies. Do not wait on the upstream fix.
+1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. For copy-overwrite files, treat the local fix as temporary because it will be clobbered when the upstream fix ships and Lisa re-applies. For create-only files, keep the local fix because Lisa will not overwrite it, but still file upstream so new repos stop inheriting the bug.
 2. **File an upstream issue in the Lisa repository.** Use the `github-write-issue` skill (`lisa-github-write-issue`) to create an issue **in Lisa's source repo `CodySwannGT/lisa`** (pass it as the target repo, e.g. `gh ... --repo CodySwannGT/lisa`) — **not** in this project's own repo. Capture: the root cause, the symptom you hit here, and the proposed durable fix in Lisa's templates/rules/skills.
 
 ## Do not
 
-- Do **not** only fix it locally and move on — the local fix is throwaway; without the upstream issue the root cause is lost and re-breaks on the next apply.
+- Do **not** only fix it locally and move on — even when a create-only local fix survives, the broken template keeps shipping to every new repo until it is fixed upstream.
 - Do **not** try to edit Lisa's templates from inside this project — you are not in the Lisa repo; those edits don't exist upstream and get overwritten.
 - Do **not** file the issue in this project's repo — it must land in `CodySwannGT/lisa`.
 

package/plugins/lisa-copilot/rules/reference/upstream-to-lisa.md

@@ -9,14 +9,25 @@ You are working in a downstream/host project (not the Lisa source repo) and you
 - A bug or gap in a Lisa-distributed **template, rule, skill, agent, hook, or CI workflow**.
 - A **governance pattern** discovered here that should be generalized back into Lisa's templates so every project benefits.
 - Anything where the file you want to change is **Lisa-managed** — it carries Lisa governance markers, lives in a path Lisa owns, or any edit would be **overwritten on the next `lisa apply`**.
+- Anything where the root cause is in a Lisa **create-only** template, even if the generated file says Lisa will not overwrite it.
 
-The defining test: *if I fix this only here, does `lisa apply` wipe it out next time?* If yes, the root cause lives in Lisa and must be upstreamed.
+The defining test: **does the root cause live in a Lisa-distributed artifact?** If yes, file upstream. The wipe-out test is a sufficient signal, not the only signal.
+
+| Template class | Local fix survives `lisa apply`? | Why it is still upstream-worthy |
+| --- | --- | --- |
+| **copy-overwrite** (managed) | No — clobbered on next apply | The local fix is throwaway; without the upstream fix it re-breaks. |
+| **create-only** (first setup) | Yes — Lisa never overwrites it | No existing repo self-heals, and every newly scaffolded repo inherits the bug. |
+
+For create-only files, header text such as `Lisa will not overwrite it` is a **positive** upstream signal, not a reason to stay local. Keep the downstream fix because Lisa will not replace it, and still file upstream so future projects receive the corrected template.
 
 ## What to do — both steps, always
 
 ### 1. Fix it locally so you are not blocked
 
-Apply the stopgap in this project so you can keep working. Do **not** stall waiting for an upstream fix to land. Treat the local change as temporary — it will be clobbered when the upstream fix ships and Lisa re-applies. That is expected and fine; the upstream issue (step 2) is what makes it durable.
+Apply the stopgap in this project so you can keep working. Do **not** stall waiting for an upstream fix to land.
+
+- For copy-overwrite files, treat the local change as temporary: it will be clobbered when the upstream fix ships and Lisa re-applies.
+- For create-only files, keep the local change: Lisa will not overwrite it. The upstream issue is still mandatory because new projects keep inheriting the broken template until Lisa changes.
 
 ### 2. File an upstream issue in the Lisa repository
 
@@ -27,11 +38,11 @@ The issue should capture, following the skill's three-audience / acceptance-crit
 - **Root cause** — which Lisa template/rule/skill/agent/hook/workflow is wrong or missing, with the path under `plugins/src/...` (or the relevant template source) if known.
 - **Symptom** — what broke or was missing in *this* project, and how it surfaced. Reference this project so the fix can be validated against a real case.
 - **Proposed durable fix** — the change to make in Lisa's source so it propagates to all projects on the next apply.
-- **Local stopgap applied** — note that a temporary local fix is in place here, so the maintainer knows the host project is unblocked and the local change will be superseded.
+- **Local stopgap applied** — note that a local fix is in place here, whether it is temporary copy-overwrite work or a retained create-only patch.
 
 ## Do not
 
-- Do **not** only fix it locally and move on. The local fix is throwaway; without the upstream issue the root cause is lost and re-breaks for every project on the next apply.
+- Do **not** only fix it locally and move on. For copy-overwrite files, the local fix is throwaway and re-breaks on the next apply. For create-only files, the local fix survives, but the broken template still ships to every new project.
 - Do **not** edit Lisa's templates from inside this project. You are not in the Lisa repo; those edits don't exist upstream and get overwritten — they create the illusion of a fix while the real source stays broken.
 - Do **not** file the issue in this project's own repo. The durable fix is tracked in `CodySwannGT/lisa`.
 

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

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

package/plugins/lisa-cursor/rules/upstream-to-lisa-reference.mdc

@@ -14,14 +14,25 @@ You are working in a downstream/host project (not the Lisa source repo) and you
 - A bug or gap in a Lisa-distributed **template, rule, skill, agent, hook, or CI workflow**.
 - A **governance pattern** discovered here that should be generalized back into Lisa's templates so every project benefits.
 - Anything where the file you want to change is **Lisa-managed** — it carries Lisa governance markers, lives in a path Lisa owns, or any edit would be **overwritten on the next `lisa apply`**.
+- Anything where the root cause is in a Lisa **create-only** template, even if the generated file says Lisa will not overwrite it.
 
-The defining test: *if I fix this only here, does `lisa apply` wipe it out next time?* If yes, the root cause lives in Lisa and must be upstreamed.
+The defining test: **does the root cause live in a Lisa-distributed artifact?** If yes, file upstream. The wipe-out test is a sufficient signal, not the only signal.
+
+| Template class | Local fix survives `lisa apply`? | Why it is still upstream-worthy |
+| --- | --- | --- |
+| **copy-overwrite** (managed) | No — clobbered on next apply | The local fix is throwaway; without the upstream fix it re-breaks. |
+| **create-only** (first setup) | Yes — Lisa never overwrites it | No existing repo self-heals, and every newly scaffolded repo inherits the bug. |
+
+For create-only files, header text such as `Lisa will not overwrite it` is a **positive** upstream signal, not a reason to stay local. Keep the downstream fix because Lisa will not replace it, and still file upstream so future projects receive the corrected template.
 
 ## What to do — both steps, always
 
 ### 1. Fix it locally so you are not blocked
 
-Apply the stopgap in this project so you can keep working. Do **not** stall waiting for an upstream fix to land. Treat the local change as temporary — it will be clobbered when the upstream fix ships and Lisa re-applies. That is expected and fine; the upstream issue (step 2) is what makes it durable.
+Apply the stopgap in this project so you can keep working. Do **not** stall waiting for an upstream fix to land.
+
+- For copy-overwrite files, treat the local change as temporary: it will be clobbered when the upstream fix ships and Lisa re-applies.
+- For create-only files, keep the local change: Lisa will not overwrite it. The upstream issue is still mandatory because new projects keep inheriting the broken template until Lisa changes.
 
 ### 2. File an upstream issue in the Lisa repository
 
@@ -32,11 +43,11 @@ The issue should capture, following the skill's three-audience / acceptance-crit
 - **Root cause** — which Lisa template/rule/skill/agent/hook/workflow is wrong or missing, with the path under `plugins/src/...` (or the relevant template source) if known.
 - **Symptom** — what broke or was missing in *this* project, and how it surfaced. Reference this project so the fix can be validated against a real case.
 - **Proposed durable fix** — the change to make in Lisa's source so it propagates to all projects on the next apply.
-- **Local stopgap applied** — note that a temporary local fix is in place here, so the maintainer knows the host project is unblocked and the local change will be superseded.
+- **Local stopgap applied** — note that a local fix is in place here, whether it is temporary copy-overwrite work or a retained create-only patch.
 
 ## Do not
 
-- Do **not** only fix it locally and move on. The local fix is throwaway; without the upstream issue the root cause is lost and re-breaks for every project on the next apply.
+- Do **not** only fix it locally and move on. For copy-overwrite files, the local fix is throwaway and re-breaks on the next apply. For create-only files, the local fix survives, but the broken template still ships to every new project.
 - Do **not** edit Lisa's templates from inside this project. You are not in the Lisa repo; those edits don't exist upstream and get overwritten — they create the illusion of a fix while the real source stays broken.
 - Do **not** file the issue in this project's own repo. The durable fix is tracked in `CodySwannGT/lisa`.
 

package/plugins/lisa-cursor/rules/upstream-to-lisa.mdc

@@ -5,16 +5,21 @@ alwaysApply: true
 
 # Upstream To Lisa (load-bearing)
 
-When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project — a bug or gap in a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, or a governance pattern worth generalizing back to the templates. Tell-tale signs: the file you want to change is Lisa-managed (carries Lisa governance markers, or lives in a path Lisa owns), and any edit you make here would be **overwritten on the next `lisa apply`**.
+When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project — a bug or gap in a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, or a governance pattern worth generalizing back to the templates. The defining test: **does the root cause live in a Lisa-distributed artifact?** If yes, file upstream, regardless of whether your local fix survives the next `lisa apply`.
+
+Tell-tale signs include:
+
+- The file is Lisa-managed (carries Lisa governance markers, or lives in a path Lisa owns) and any edit you make here would be **overwritten on the next `lisa apply`**.
+- The file was created from a Lisa `create-only` template and carries language such as `Lisa will not overwrite it`. That header is a positive upstream signal: existing repos will keep their local copy, but every newly scaffolded repo still inherits the broken template until Lisa is fixed.
 
 When that happens, you have **two obligations — do both**:
 
-1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. Treat it as temporary: it will be clobbered when the upstream fix ships and Lisa re-applies. Do not wait on the upstream fix.
+1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. For copy-overwrite files, treat the local fix as temporary because it will be clobbered when the upstream fix ships and Lisa re-applies. For create-only files, keep the local fix because Lisa will not overwrite it, but still file upstream so new repos stop inheriting the bug.
 2. **File an upstream issue in the Lisa repository.** Use the `github-write-issue` skill (`lisa-github-write-issue`) to create an issue **in Lisa's source repo `CodySwannGT/lisa`** (pass it as the target repo, e.g. `gh ... --repo CodySwannGT/lisa`) — **not** in this project's own repo. Capture: the root cause, the symptom you hit here, and the proposed durable fix in Lisa's templates/rules/skills.
 
 ## Do not
 
-- Do **not** only fix it locally and move on — the local fix is throwaway; without the upstream issue the root cause is lost and re-breaks on the next apply.
+- Do **not** only fix it locally and move on — even when a create-only local fix survives, the broken template keeps shipping to every new repo until it is fixed upstream.
 - Do **not** try to edit Lisa's templates from inside this project — you are not in the Lisa repo; those edits don't exist upstream and get overwritten.
 - Do **not** file the issue in this project's repo — it must land in `CodySwannGT/lisa`.
 

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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.205.0",
+  "version": "2.205.1",
   "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/upstream-to-lisa.md

@@ -1,15 +1,20 @@
 # Upstream To Lisa (load-bearing)
 
-When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project — a bug or gap in a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, or a governance pattern worth generalizing back to the templates. Tell-tale signs: the file you want to change is Lisa-managed (carries Lisa governance markers, or lives in a path Lisa owns), and any edit you make here would be **overwritten on the next `lisa apply`**.
+When working in a project that has Lisa installed, you will sometimes find that the **real fix belongs upstream in Lisa**, not in this project — a bug or gap in a Lisa-distributed template, rule, skill, agent, hook, or CI workflow, or a governance pattern worth generalizing back to the templates. The defining test: **does the root cause live in a Lisa-distributed artifact?** If yes, file upstream, regardless of whether your local fix survives the next `lisa apply`.
+
+Tell-tale signs include:
+
+- The file is Lisa-managed (carries Lisa governance markers, or lives in a path Lisa owns) and any edit you make here would be **overwritten on the next `lisa apply`**.
+- The file was created from a Lisa `create-only` template and carries language such as `Lisa will not overwrite it`. That header is a positive upstream signal: existing repos will keep their local copy, but every newly scaffolded repo still inherits the broken template until Lisa is fixed.
 
 When that happens, you have **two obligations — do both**:
 
-1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. Treat it as temporary: it will be clobbered when the upstream fix ships and Lisa re-applies. Do not wait on the upstream fix.
+1. **Fix it locally so you are not blocked.** Apply the stopgap in this project so you can keep working. For copy-overwrite files, treat the local fix as temporary because it will be clobbered when the upstream fix ships and Lisa re-applies. For create-only files, keep the local fix because Lisa will not overwrite it, but still file upstream so new repos stop inheriting the bug.
 2. **File an upstream issue in the Lisa repository.** Use the `github-write-issue` skill (`lisa-github-write-issue`) to create an issue **in Lisa's source repo `CodySwannGT/lisa`** (pass it as the target repo, e.g. `gh ... --repo CodySwannGT/lisa`) — **not** in this project's own repo. Capture: the root cause, the symptom you hit here, and the proposed durable fix in Lisa's templates/rules/skills.
 
 ## Do not
 
-- Do **not** only fix it locally and move on — the local fix is throwaway; without the upstream issue the root cause is lost and re-breaks on the next apply.
+- Do **not** only fix it locally and move on — even when a create-only local fix survives, the broken template keeps shipping to every new repo until it is fixed upstream.
 - Do **not** try to edit Lisa's templates from inside this project — you are not in the Lisa repo; those edits don't exist upstream and get overwritten.
 - Do **not** file the issue in this project's repo — it must land in `CodySwannGT/lisa`.
 

package/plugins/src/base/rules/reference/upstream-to-lisa.md

@@ -9,14 +9,25 @@ You are working in a downstream/host project (not the Lisa source repo) and you
 - A bug or gap in a Lisa-distributed **template, rule, skill, agent, hook, or CI workflow**.
 - A **governance pattern** discovered here that should be generalized back into Lisa's templates so every project benefits.
 - Anything where the file you want to change is **Lisa-managed** — it carries Lisa governance markers, lives in a path Lisa owns, or any edit would be **overwritten on the next `lisa apply`**.
+- Anything where the root cause is in a Lisa **create-only** template, even if the generated file says Lisa will not overwrite it.
 
-The defining test: *if I fix this only here, does `lisa apply` wipe it out next time?* If yes, the root cause lives in Lisa and must be upstreamed.
+The defining test: **does the root cause live in a Lisa-distributed artifact?** If yes, file upstream. The wipe-out test is a sufficient signal, not the only signal.
+
+| Template class | Local fix survives `lisa apply`? | Why it is still upstream-worthy |
+| --- | --- | --- |
+| **copy-overwrite** (managed) | No — clobbered on next apply | The local fix is throwaway; without the upstream fix it re-breaks. |
+| **create-only** (first setup) | Yes — Lisa never overwrites it | No existing repo self-heals, and every newly scaffolded repo inherits the bug. |
+
+For create-only files, header text such as `Lisa will not overwrite it` is a **positive** upstream signal, not a reason to stay local. Keep the downstream fix because Lisa will not replace it, and still file upstream so future projects receive the corrected template.
 
 ## What to do — both steps, always
 
 ### 1. Fix it locally so you are not blocked
 
-Apply the stopgap in this project so you can keep working. Do **not** stall waiting for an upstream fix to land. Treat the local change as temporary — it will be clobbered when the upstream fix ships and Lisa re-applies. That is expected and fine; the upstream issue (step 2) is what makes it durable.
+Apply the stopgap in this project so you can keep working. Do **not** stall waiting for an upstream fix to land.
+
+- For copy-overwrite files, treat the local change as temporary: it will be clobbered when the upstream fix ships and Lisa re-applies.
+- For create-only files, keep the local change: Lisa will not overwrite it. The upstream issue is still mandatory because new projects keep inheriting the broken template until Lisa changes.
 
 ### 2. File an upstream issue in the Lisa repository
 
@@ -27,11 +38,11 @@ The issue should capture, following the skill's three-audience / acceptance-crit
 - **Root cause** — which Lisa template/rule/skill/agent/hook/workflow is wrong or missing, with the path under `plugins/src/...` (or the relevant template source) if known.
 - **Symptom** — what broke or was missing in *this* project, and how it surfaced. Reference this project so the fix can be validated against a real case.
 - **Proposed durable fix** — the change to make in Lisa's source so it propagates to all projects on the next apply.
-- **Local stopgap applied** — note that a temporary local fix is in place here, so the maintainer knows the host project is unblocked and the local change will be superseded.
+- **Local stopgap applied** — note that a local fix is in place here, whether it is temporary copy-overwrite work or a retained create-only patch.
 
 ## Do not
 
-- Do **not** only fix it locally and move on. The local fix is throwaway; without the upstream issue the root cause is lost and re-breaks for every project on the next apply.
+- Do **not** only fix it locally and move on. For copy-overwrite files, the local fix is throwaway and re-breaks on the next apply. For create-only files, the local fix survives, but the broken template still ships to every new project.
 - Do **not** edit Lisa's templates from inside this project. You are not in the Lisa repo; those edits don't exist upstream and get overwritten — they create the illusion of a fix while the real source stays broken.
 - Do **not** file the issue in this project's own repo. The durable fix is tracked in `CodySwannGT/lisa`.