@codyswann/lisa 2.166.2 → 2.166.3

package/package.json

@@ -85,7 +85,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-agy/plugin.json

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-harper-fabric/skills/harper-build-and-deploy/SKILL.md

@@ -27,14 +27,42 @@ The CLI binary is `harper` (v5; older installs use `harperdb`). Key commands:
 In this project, dev typically runs against the component dir, e.g.
 `harper dev harper-app` (use the project's documented run command if it wraps this).
 
-## The build step (TypeScript → generated artifacts)
+## The build step (TypeScript -> generated artifacts)
 
 Harper loads JavaScript (`resources.js`) and serves static files (`web/**`). In this
-project those are **generated**, not authored:
-
-- **TypeScript under `src/` is source.** `bun run build` compiles it into
-  `harper-app/resources.js` and `harper-app/web/**`.
-- **Never edit `resources.js` or `web/**` directly** — change the TypeScript and
+project those are **generated**, not authored.
+
+What the build actually does:
+
+1. Compiles the TypeScript source under `src/` into deployable JavaScript.
+2. Emits `harper-app/resources.js`, the aggregate resource module loaded by the
+   `jsResource` extension.
+3. Emits per-resource modules such as `harper-app/resource-*.js` when the project
+   build splits resources for Harper's runtime loader.
+4. Copies browser/static output into `harper-app/web/**` for the `static`
+   extension to serve.
+5. Mirrors shared library output into `harper-app/lib/**` and rewrites imports
+   such as `../lib/foo.js` to `./lib/foo.js`. Fabric packages the component root
+   as a flat deploy unit, and Node resolves real paths at runtime, so imports must
+   point at files that exist inside the packaged `harper-app/` root.
+6. Adds cache-busting `?v=` query parameters to browser-module imports when the
+   project build owns web asset versioning.
+
+Generated Harper deploy artifacts usually include:
+
+- `harper-app/resources.js`
+- `harper-app/resource-*.js`
+- `harper-app/web/**`
+- `harper-app/lib/**`
+
+Every lint, format, dead-code, search, or generated-artifact guard must ignore
+those generated paths unless it is explicitly validating the build output itself.
+When a new generated path appears, add it to every relevant ignore surface in the
+same change; partial ignores fail later gates in non-obvious ways.
+
+- **TypeScript under `src/` is source.** `bun run build` produces the deployable
+  Harper assets from it.
+- **Never edit generated Harper assets directly** — change the TypeScript and
   rebuild. See [[harper-resources]] and [[harper-component-model]].
 - **Build before symlinking, packaging, or deploying `harper-app/`.** Deploying
   stale artifacts ships code that does not match `src/`.
@@ -86,11 +114,45 @@ harper deploy_component \
 
 - Omitting `package` deploys the current directory.
 - `restart=true` restarts threads after deploy so new code loads.
-- `replicated=true` replicates the deploy across all nodes in a cluster — include it
-  when targeting Fabric/a cluster.
+- `replicated=true` asks Harper/Fabric to apply the component deploy across the
+  cluster rather than only the node receiving the deploy request. Include it when
+  targeting Fabric or any clustered deployment.
 - Credentials can come from `CLI_TARGET_USERNAME` / `CLI_TARGET_PASSWORD` instead of
   inline flags — prefer that so secrets never land in shell history or tracked files.
 
+## Replication and topology
+
+Fabric is a distributed runtime: a project can run on one or more Harper nodes,
+often grouped by region or environment. Your application code is packaged as a
+component, and the data layer is replicated through Harper's database and
+clustering model.
+
+Keep these semantics separate:
+
+- **Component code replication** is controlled by deploy behavior. With
+  `replicated=true`, the deployed component package should reach the cluster nodes
+  that serve the application. Without it, you may update only the target node and
+  leave other nodes running older code.
+- **Data replication** is runtime/database behavior. Deploying code does not by
+  itself prove that existing rows, schema changes, caches, or realtime state are
+  consistent across regions or nodes.
+- **Thread restart** is local process behavior. `restart=true` reloads code after
+  the package lands; it is not a substitute for checking every node or region that
+  receives traffic.
+
+After a replicated deploy, verify from the topology the app actually uses:
+
+1. Confirm the deploy command or workflow used `replicated=true` for Fabric/cluster
+   targets.
+2. Read `harper status` or the project's Fabric status command to see the expected
+   nodes/regions.
+3. Hit the public smoke endpoint through the production route, then hit a direct
+   node or region endpoint when the project exposes one.
+4. For schema or data changes, verify a write/read path that proves the expected
+   data is visible where traffic can land.
+5. If one node serves old assets or resources, treat the deploy as incomplete even
+   when the initial target node passed smoke.
+
 ## Secrets
 
 Keep runtime secrets out of tracked files. Use environment variables, the

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

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

package/plugins/lisa-harper-fabric-agy/skills/harper-build-and-deploy/SKILL.md

@@ -27,14 +27,42 @@ The CLI binary is `harper` (v5; older installs use `harperdb`). Key commands:
 In this project, dev typically runs against the component dir, e.g.
 `harper dev harper-app` (use the project's documented run command if it wraps this).
 
-## The build step (TypeScript → generated artifacts)
+## The build step (TypeScript -> generated artifacts)
 
 Harper loads JavaScript (`resources.js`) and serves static files (`web/**`). In this
-project those are **generated**, not authored:
-
-- **TypeScript under `src/` is source.** `bun run build` compiles it into
-  `harper-app/resources.js` and `harper-app/web/**`.
-- **Never edit `resources.js` or `web/**` directly** — change the TypeScript and
+project those are **generated**, not authored.
+
+What the build actually does:
+
+1. Compiles the TypeScript source under `src/` into deployable JavaScript.
+2. Emits `harper-app/resources.js`, the aggregate resource module loaded by the
+   `jsResource` extension.
+3. Emits per-resource modules such as `harper-app/resource-*.js` when the project
+   build splits resources for Harper's runtime loader.
+4. Copies browser/static output into `harper-app/web/**` for the `static`
+   extension to serve.
+5. Mirrors shared library output into `harper-app/lib/**` and rewrites imports
+   such as `../lib/foo.js` to `./lib/foo.js`. Fabric packages the component root
+   as a flat deploy unit, and Node resolves real paths at runtime, so imports must
+   point at files that exist inside the packaged `harper-app/` root.
+6. Adds cache-busting `?v=` query parameters to browser-module imports when the
+   project build owns web asset versioning.
+
+Generated Harper deploy artifacts usually include:
+
+- `harper-app/resources.js`
+- `harper-app/resource-*.js`
+- `harper-app/web/**`
+- `harper-app/lib/**`
+
+Every lint, format, dead-code, search, or generated-artifact guard must ignore
+those generated paths unless it is explicitly validating the build output itself.
+When a new generated path appears, add it to every relevant ignore surface in the
+same change; partial ignores fail later gates in non-obvious ways.
+
+- **TypeScript under `src/` is source.** `bun run build` produces the deployable
+  Harper assets from it.
+- **Never edit generated Harper assets directly** — change the TypeScript and
   rebuild. See [[harper-resources]] and [[harper-component-model]].
 - **Build before symlinking, packaging, or deploying `harper-app/`.** Deploying
   stale artifacts ships code that does not match `src/`.
@@ -86,11 +114,45 @@ harper deploy_component \
 
 - Omitting `package` deploys the current directory.
 - `restart=true` restarts threads after deploy so new code loads.
-- `replicated=true` replicates the deploy across all nodes in a cluster — include it
-  when targeting Fabric/a cluster.
+- `replicated=true` asks Harper/Fabric to apply the component deploy across the
+  cluster rather than only the node receiving the deploy request. Include it when
+  targeting Fabric or any clustered deployment.
 - Credentials can come from `CLI_TARGET_USERNAME` / `CLI_TARGET_PASSWORD` instead of
   inline flags — prefer that so secrets never land in shell history or tracked files.
 
+## Replication and topology
+
+Fabric is a distributed runtime: a project can run on one or more Harper nodes,
+often grouped by region or environment. Your application code is packaged as a
+component, and the data layer is replicated through Harper's database and
+clustering model.
+
+Keep these semantics separate:
+
+- **Component code replication** is controlled by deploy behavior. With
+  `replicated=true`, the deployed component package should reach the cluster nodes
+  that serve the application. Without it, you may update only the target node and
+  leave other nodes running older code.
+- **Data replication** is runtime/database behavior. Deploying code does not by
+  itself prove that existing rows, schema changes, caches, or realtime state are
+  consistent across regions or nodes.
+- **Thread restart** is local process behavior. `restart=true` reloads code after
+  the package lands; it is not a substitute for checking every node or region that
+  receives traffic.
+
+After a replicated deploy, verify from the topology the app actually uses:
+
+1. Confirm the deploy command or workflow used `replicated=true` for Fabric/cluster
+   targets.
+2. Read `harper status` or the project's Fabric status command to see the expected
+   nodes/regions.
+3. Hit the public smoke endpoint through the production route, then hit a direct
+   node or region endpoint when the project exposes one.
+4. For schema or data changes, verify a write/read path that proves the expected
+   data is visible where traffic can land.
+5. If one node serves old assets or resources, treat the deploy as incomplete even
+   when the initial target node passed smoke.
+
 ## Secrets
 
 Keep runtime secrets out of tracked files. Use environment variables, the

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

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

package/plugins/lisa-harper-fabric-copilot/skills/harper-build-and-deploy/SKILL.md

@@ -27,14 +27,42 @@ The CLI binary is `harper` (v5; older installs use `harperdb`). Key commands:
 In this project, dev typically runs against the component dir, e.g.
 `harper dev harper-app` (use the project's documented run command if it wraps this).
 
-## The build step (TypeScript → generated artifacts)
+## The build step (TypeScript -> generated artifacts)
 
 Harper loads JavaScript (`resources.js`) and serves static files (`web/**`). In this
-project those are **generated**, not authored:
-
-- **TypeScript under `src/` is source.** `bun run build` compiles it into
-  `harper-app/resources.js` and `harper-app/web/**`.
-- **Never edit `resources.js` or `web/**` directly** — change the TypeScript and
+project those are **generated**, not authored.
+
+What the build actually does:
+
+1. Compiles the TypeScript source under `src/` into deployable JavaScript.
+2. Emits `harper-app/resources.js`, the aggregate resource module loaded by the
+   `jsResource` extension.
+3. Emits per-resource modules such as `harper-app/resource-*.js` when the project
+   build splits resources for Harper's runtime loader.
+4. Copies browser/static output into `harper-app/web/**` for the `static`
+   extension to serve.
+5. Mirrors shared library output into `harper-app/lib/**` and rewrites imports
+   such as `../lib/foo.js` to `./lib/foo.js`. Fabric packages the component root
+   as a flat deploy unit, and Node resolves real paths at runtime, so imports must
+   point at files that exist inside the packaged `harper-app/` root.
+6. Adds cache-busting `?v=` query parameters to browser-module imports when the
+   project build owns web asset versioning.
+
+Generated Harper deploy artifacts usually include:
+
+- `harper-app/resources.js`
+- `harper-app/resource-*.js`
+- `harper-app/web/**`
+- `harper-app/lib/**`
+
+Every lint, format, dead-code, search, or generated-artifact guard must ignore
+those generated paths unless it is explicitly validating the build output itself.
+When a new generated path appears, add it to every relevant ignore surface in the
+same change; partial ignores fail later gates in non-obvious ways.
+
+- **TypeScript under `src/` is source.** `bun run build` produces the deployable
+  Harper assets from it.
+- **Never edit generated Harper assets directly** — change the TypeScript and
   rebuild. See [[harper-resources]] and [[harper-component-model]].
 - **Build before symlinking, packaging, or deploying `harper-app/`.** Deploying
   stale artifacts ships code that does not match `src/`.
@@ -86,11 +114,45 @@ harper deploy_component \
 
 - Omitting `package` deploys the current directory.
 - `restart=true` restarts threads after deploy so new code loads.
-- `replicated=true` replicates the deploy across all nodes in a cluster — include it
-  when targeting Fabric/a cluster.
+- `replicated=true` asks Harper/Fabric to apply the component deploy across the
+  cluster rather than only the node receiving the deploy request. Include it when
+  targeting Fabric or any clustered deployment.
 - Credentials can come from `CLI_TARGET_USERNAME` / `CLI_TARGET_PASSWORD` instead of
   inline flags — prefer that so secrets never land in shell history or tracked files.
 
+## Replication and topology
+
+Fabric is a distributed runtime: a project can run on one or more Harper nodes,
+often grouped by region or environment. Your application code is packaged as a
+component, and the data layer is replicated through Harper's database and
+clustering model.
+
+Keep these semantics separate:
+
+- **Component code replication** is controlled by deploy behavior. With
+  `replicated=true`, the deployed component package should reach the cluster nodes
+  that serve the application. Without it, you may update only the target node and
+  leave other nodes running older code.
+- **Data replication** is runtime/database behavior. Deploying code does not by
+  itself prove that existing rows, schema changes, caches, or realtime state are
+  consistent across regions or nodes.
+- **Thread restart** is local process behavior. `restart=true` reloads code after
+  the package lands; it is not a substitute for checking every node or region that
+  receives traffic.
+
+After a replicated deploy, verify from the topology the app actually uses:
+
+1. Confirm the deploy command or workflow used `replicated=true` for Fabric/cluster
+   targets.
+2. Read `harper status` or the project's Fabric status command to see the expected
+   nodes/regions.
+3. Hit the public smoke endpoint through the production route, then hit a direct
+   node or region endpoint when the project exposes one.
+4. For schema or data changes, verify a write/read path that proves the expected
+   data is visible where traffic can land.
+5. If one node serves old assets or resources, treat the deploy as incomplete even
+   when the initial target node passed smoke.
+
 ## Secrets
 
 Keep runtime secrets out of tracked files. Use environment variables, the

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

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

package/plugins/lisa-harper-fabric-cursor/skills/harper-build-and-deploy/SKILL.md

@@ -27,14 +27,42 @@ The CLI binary is `harper` (v5; older installs use `harperdb`). Key commands:
 In this project, dev typically runs against the component dir, e.g.
 `harper dev harper-app` (use the project's documented run command if it wraps this).
 
-## The build step (TypeScript → generated artifacts)
+## The build step (TypeScript -> generated artifacts)
 
 Harper loads JavaScript (`resources.js`) and serves static files (`web/**`). In this
-project those are **generated**, not authored:
-
-- **TypeScript under `src/` is source.** `bun run build` compiles it into
-  `harper-app/resources.js` and `harper-app/web/**`.
-- **Never edit `resources.js` or `web/**` directly** — change the TypeScript and
+project those are **generated**, not authored.
+
+What the build actually does:
+
+1. Compiles the TypeScript source under `src/` into deployable JavaScript.
+2. Emits `harper-app/resources.js`, the aggregate resource module loaded by the
+   `jsResource` extension.
+3. Emits per-resource modules such as `harper-app/resource-*.js` when the project
+   build splits resources for Harper's runtime loader.
+4. Copies browser/static output into `harper-app/web/**` for the `static`
+   extension to serve.
+5. Mirrors shared library output into `harper-app/lib/**` and rewrites imports
+   such as `../lib/foo.js` to `./lib/foo.js`. Fabric packages the component root
+   as a flat deploy unit, and Node resolves real paths at runtime, so imports must
+   point at files that exist inside the packaged `harper-app/` root.
+6. Adds cache-busting `?v=` query parameters to browser-module imports when the
+   project build owns web asset versioning.
+
+Generated Harper deploy artifacts usually include:
+
+- `harper-app/resources.js`
+- `harper-app/resource-*.js`
+- `harper-app/web/**`
+- `harper-app/lib/**`
+
+Every lint, format, dead-code, search, or generated-artifact guard must ignore
+those generated paths unless it is explicitly validating the build output itself.
+When a new generated path appears, add it to every relevant ignore surface in the
+same change; partial ignores fail later gates in non-obvious ways.
+
+- **TypeScript under `src/` is source.** `bun run build` produces the deployable
+  Harper assets from it.
+- **Never edit generated Harper assets directly** — change the TypeScript and
   rebuild. See [[harper-resources]] and [[harper-component-model]].
 - **Build before symlinking, packaging, or deploying `harper-app/`.** Deploying
   stale artifacts ships code that does not match `src/`.
@@ -86,11 +114,45 @@ harper deploy_component \
 
 - Omitting `package` deploys the current directory.
 - `restart=true` restarts threads after deploy so new code loads.
-- `replicated=true` replicates the deploy across all nodes in a cluster — include it
-  when targeting Fabric/a cluster.
+- `replicated=true` asks Harper/Fabric to apply the component deploy across the
+  cluster rather than only the node receiving the deploy request. Include it when
+  targeting Fabric or any clustered deployment.
 - Credentials can come from `CLI_TARGET_USERNAME` / `CLI_TARGET_PASSWORD` instead of
   inline flags — prefer that so secrets never land in shell history or tracked files.
 
+## Replication and topology
+
+Fabric is a distributed runtime: a project can run on one or more Harper nodes,
+often grouped by region or environment. Your application code is packaged as a
+component, and the data layer is replicated through Harper's database and
+clustering model.
+
+Keep these semantics separate:
+
+- **Component code replication** is controlled by deploy behavior. With
+  `replicated=true`, the deployed component package should reach the cluster nodes
+  that serve the application. Without it, you may update only the target node and
+  leave other nodes running older code.
+- **Data replication** is runtime/database behavior. Deploying code does not by
+  itself prove that existing rows, schema changes, caches, or realtime state are
+  consistent across regions or nodes.
+- **Thread restart** is local process behavior. `restart=true` reloads code after
+  the package lands; it is not a substitute for checking every node or region that
+  receives traffic.
+
+After a replicated deploy, verify from the topology the app actually uses:
+
+1. Confirm the deploy command or workflow used `replicated=true` for Fabric/cluster
+   targets.
+2. Read `harper status` or the project's Fabric status command to see the expected
+   nodes/regions.
+3. Hit the public smoke endpoint through the production route, then hit a direct
+   node or region endpoint when the project exposes one.
+4. For schema or data changes, verify a write/read path that proves the expected
+   data is visible where traffic can land.
+5. If one node serves old assets or resources, treat the deploy as incomplete even
+   when the initial target node passed smoke.
+
 ## Secrets
 
 Keep runtime secrets out of tracked files. Use environment variables, the

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "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.166.2",
+  "version": "2.166.3",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/harper-fabric/skills/harper-build-and-deploy/SKILL.md

@@ -27,14 +27,42 @@ The CLI binary is `harper` (v5; older installs use `harperdb`). Key commands:
 In this project, dev typically runs against the component dir, e.g.
 `harper dev harper-app` (use the project's documented run command if it wraps this).
 
-## The build step (TypeScript → generated artifacts)
+## The build step (TypeScript -> generated artifacts)
 
 Harper loads JavaScript (`resources.js`) and serves static files (`web/**`). In this
-project those are **generated**, not authored:
-
-- **TypeScript under `src/` is source.** `bun run build` compiles it into
-  `harper-app/resources.js` and `harper-app/web/**`.
-- **Never edit `resources.js` or `web/**` directly** — change the TypeScript and
+project those are **generated**, not authored.
+
+What the build actually does:
+
+1. Compiles the TypeScript source under `src/` into deployable JavaScript.
+2. Emits `harper-app/resources.js`, the aggregate resource module loaded by the
+   `jsResource` extension.
+3. Emits per-resource modules such as `harper-app/resource-*.js` when the project
+   build splits resources for Harper's runtime loader.
+4. Copies browser/static output into `harper-app/web/**` for the `static`
+   extension to serve.
+5. Mirrors shared library output into `harper-app/lib/**` and rewrites imports
+   such as `../lib/foo.js` to `./lib/foo.js`. Fabric packages the component root
+   as a flat deploy unit, and Node resolves real paths at runtime, so imports must
+   point at files that exist inside the packaged `harper-app/` root.
+6. Adds cache-busting `?v=` query parameters to browser-module imports when the
+   project build owns web asset versioning.
+
+Generated Harper deploy artifacts usually include:
+
+- `harper-app/resources.js`
+- `harper-app/resource-*.js`
+- `harper-app/web/**`
+- `harper-app/lib/**`
+
+Every lint, format, dead-code, search, or generated-artifact guard must ignore
+those generated paths unless it is explicitly validating the build output itself.
+When a new generated path appears, add it to every relevant ignore surface in the
+same change; partial ignores fail later gates in non-obvious ways.
+
+- **TypeScript under `src/` is source.** `bun run build` produces the deployable
+  Harper assets from it.
+- **Never edit generated Harper assets directly** — change the TypeScript and
   rebuild. See [[harper-resources]] and [[harper-component-model]].
 - **Build before symlinking, packaging, or deploying `harper-app/`.** Deploying
   stale artifacts ships code that does not match `src/`.
@@ -86,11 +114,45 @@ harper deploy_component \
 
 - Omitting `package` deploys the current directory.
 - `restart=true` restarts threads after deploy so new code loads.
-- `replicated=true` replicates the deploy across all nodes in a cluster — include it
-  when targeting Fabric/a cluster.
+- `replicated=true` asks Harper/Fabric to apply the component deploy across the
+  cluster rather than only the node receiving the deploy request. Include it when
+  targeting Fabric or any clustered deployment.
 - Credentials can come from `CLI_TARGET_USERNAME` / `CLI_TARGET_PASSWORD` instead of
   inline flags — prefer that so secrets never land in shell history or tracked files.
 
+## Replication and topology
+
+Fabric is a distributed runtime: a project can run on one or more Harper nodes,
+often grouped by region or environment. Your application code is packaged as a
+component, and the data layer is replicated through Harper's database and
+clustering model.
+
+Keep these semantics separate:
+
+- **Component code replication** is controlled by deploy behavior. With
+  `replicated=true`, the deployed component package should reach the cluster nodes
+  that serve the application. Without it, you may update only the target node and
+  leave other nodes running older code.
+- **Data replication** is runtime/database behavior. Deploying code does not by
+  itself prove that existing rows, schema changes, caches, or realtime state are
+  consistent across regions or nodes.
+- **Thread restart** is local process behavior. `restart=true` reloads code after
+  the package lands; it is not a substitute for checking every node or region that
+  receives traffic.
+
+After a replicated deploy, verify from the topology the app actually uses:
+
+1. Confirm the deploy command or workflow used `replicated=true` for Fabric/cluster
+   targets.
+2. Read `harper status` or the project's Fabric status command to see the expected
+   nodes/regions.
+3. Hit the public smoke endpoint through the production route, then hit a direct
+   node or region endpoint when the project exposes one.
+4. For schema or data changes, verify a write/read path that proves the expected
+   data is visible where traffic can land.
+5. If one node serves old assets or resources, treat the deploy as incomplete even
+   when the initial target node passed smoke.
+
 ## Secrets
 
 Keep runtime secrets out of tracked files. Use environment variables, the