@codyswann/lisa 3.46.3 → 3.46.4

package/dist/core/upstream-evidence-manifest.js

@@ -384,7 +384,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/rules/eager/dependency-trust-classes.md": "43a0932a7b8d4fd075b66bfe778025d808a13d9aa61ae793e9eb2fc8a555a381",
     "plugins/src/base/rules/eager/derived-branch-plan.md": "2e4d5a142d7a33da3d01a6a8b3c79cf8b89769b9039c8672f1a14badba30d172",
     "plugins/src/base/rules/eager/design-source-of-truth.md": "d85886aa5832f7952bc0768871a335f33a4899ce598bb1a114feb5f300cbc7f2",
-    "plugins/src/base/rules/eager/design-value-binding.md": "906dbea93d2e5b9f88ce338d00f6fc1ee69a75dd489173c58fcc9f4b6547ad08",
+    "plugins/src/base/rules/eager/design-value-binding.md": "06c28a87f32860ce6fb17fdef90a59b7be0baf99cc28d7cf0299bcd8a5e46c44",
     "plugins/src/base/rules/eager/do-it-now.md": "de0c1565fa7b8a99a7f5d15af1118c3e5eb942a0d893bbb672533149fb82688e",
     "plugins/src/base/rules/eager/documentation-source-paths.md": "3a7c2a6264654a3cc44dd326441ba211a39c1c267033cc189c1c635adb84b52b",
     "plugins/src/base/rules/eager/empirical-inquiry.md": "67aa64ba3ecc4f3cd761111d2562662e0a2acf7892703b14ec83f7f7b073e670",
@@ -515,7 +515,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-debrief-apply/SKILL.md": "7bff86a9e15cb63d58961dd5a47d0fbab44872f9bdcad04328788890f4521190",
     "plugins/src/base/skills/lisa-debrief/SKILL.md": "6a0981107f907d3362ab0001f46412b76a70ec5ecc37ea1cd1def6ce4a38c9ee",
     "plugins/src/base/skills/lisa-delivery-effectiveness/SKILL.md": "21bc55fa0e86a9694bd22269fd089dbfae0c54c199262f46a4955447acea0f35",
-    "plugins/src/base/skills/lisa-design-intake/SKILL.md": "7dcc917be8d382f86247cb8a0169a1f59575a059855f3a75d2a0231e1999c4e4",
+    "plugins/src/base/skills/lisa-design-intake/SKILL.md": "8d0a72248d9d74b15aa31b0a51d13b77069677ea20117ddf93073d38c512ebf1",
     "plugins/src/base/skills/lisa-detect-tooling/SKILL.md": "6ea2b1404d5c27f8a5bec8c90ad35ed0124789b70c091869455f538a2a9debbe",
     "plugins/src/base/skills/lisa-detect-tooling/scripts/commands.mjs": "e28bd61fdde4a336b56ae3395423026943a5816015719d31d04f0d5a0ab50eec",
     "plugins/src/base/skills/lisa-detect-tooling/scripts/detect-tooling.mjs": "d9419814fc04c935bd7e320e85b1977c9bfc9275d9ea5fb557002ad438ee7925",

package/package.json

@@ -136,7 +136,7 @@
     "zod-validation-error": "^4.0.0"
   },
   "name": "@codyswann/lisa",
-  "version": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/skills/lisa-design-intake/SKILL.md

@@ -16,6 +16,32 @@ This skill carries the **judgment**. It does not carry the **policy** — that i
 
 `design-source-of-truth` and `scripts/design-source-gate.mjs` already ask whether a changed surface **declares where its design came from**. This asks the orthogonal question: are the **values on it bound**. Both apply. A surface can cite a perfectly valid design node and still paint a literal that no variable backs — that is the case this skill exists for, and it is invisible to the other gate.
 
+## Why this gate is executable and not advisory
+
+Not a hypothesis about what agents might do under pressure. A measurement.
+
+Eleven frontend work items in a portfolio frontend, each carrying node-scoped design references. The governing rule already said coverage below 100% is a **block routed back to design, never a value for the implementing agent to guess**, and said explicitly that `warn` is the wrong severity *because* it ships the item to an agent that then guesses or stalls. An agent had read that rule. It cited the rule in the briefing it wrote for its build agents. In that same briefing it instructed them to **"snap unbound dimensions via the snap tables (ties round down) and flag the rest."**
+
+A block downgraded to a warning, by the agent enforcing it, inside the document enforcing it. Not from ignorance — from reasoning around it under delivery pressure, because eleven items were queued and blocking felt like not-shipping. It took a human restating the rule as an absolute for the instruction to be withdrawn.
+
+Coverage measured after the withdrawal, on the subtrees actually being implemented:
+
+| frames | colour | spacing | radius | reality |
+|---|---|---|---|---|
+| compliance screens | 96-100% | 82-97% | 88-93% | design-system composed |
+| edit-KPI / target dialogs | **100%** | **0%** | **0%** | colours bound, geometry never bound |
+| planning mockups | **1-4%** | **0-2%** | **0-3%** | hand-drawn, effectively unbound |
+
+**Five of the eleven items blocked back to design; six proceeded.** The worst case is the clearest argument: one modal's subtree contained **zero variable references** — every colour a literal hex, every padding, gap, radius and size a literal, raw px type sizes with literal font faces, a literal shadow. Under snap-and-flag an agent would have produced a complete, lint-clean, tested component **in which every style value was invented**, and shipped it with a note. Five view files were written before it was stopped.
+
+**The frame-vs-subtree distinction is what moved items between build and block**: 14 bound values at frame level, **zero** inside the modal actually being built. It is the finding most likely to be silently reimplemented wrong, which is why Phase 2 probes with `--node`.
+
+The delivery-pressure reasoning was also wrong on its own terms. The non-visual half of the blocked work — domain types, adapters, CRUD, formatters — was completed and preserved. **Blocking cost far less than it appeared it would.**
+
+And the rule holds once it is absolute rather than advisory: one agent withdrew a radius class it had already applied on finding `radius/none` was the only radius bound in its subtree; another refused to build an icon disc whose diameter and radius were both unbound rather than pick a size.
+
+**A gate that depends on an agent choosing to honour it under delivery pressure is not a gate.** This one is executable and headless precisely because the judgment-based version demonstrably failed in the hands of an agent that had read the rule and agreed with it. That is also why the verdict belongs to `design-intake-gate.mjs` (Phase 4) and not to prose you re-reason each run.
+
 ## Phase 0 — Is there a design source at all?
 
 **A design source is optional, and this is the most important step in the skill.** Most projects have no designs. Run the probe and read its verdict:
@@ -84,6 +110,8 @@ FIGMA_ACCESS_TOKEN=… FIGMA_MCP_TOKEN=… \
 
 Pass `--dark` wherever the library has a dark mode: the light+dark signature is what separates variables that share a value, and without it more ids stay ambiguous. An ambiguous id is still a failure — guessing which variable a value came from is exactly what this contract forbids.
 
+**An unknown id fails loudly naming the id; it never resolves to a nearest match.** That self-detecting staleness is the only reason a committed map is safe to trust — it makes a stale map an error instead of silent corruption. Never add a fallback that picks the closest variable, and never treat an unresolved id as unbound-and-therefore-design's.
+
 ## Phase 3 — Gather findings
 
 The probe already produced `hardcoded-in-design` and `bound` findings for every value in the subtree, with the two silent-under-reporting traps handled: the corner-keyed `rectangleCornerRadii` shape is normalised, and boundness is read from `boundVariables` directly rather than inferred from a resolved value (Figma omits zero-valued properties, so a padding bound to a zero-valued variable would otherwise vanish).
@@ -159,6 +187,7 @@ The rule is never "do not look at pixels". It is **"do not derive a value from p
 - **The regime is per-axis**, derived from the committed variable-id map. Never per-project, never asked of a human, and never from a live collection query — that route does not run headlessly.
 - **A design source is optional.** No source, no token, or no map is SKIPPED at exit 0, never a block.
 - **Every failure names an owner.** Unbound values are design's; a stale or ambiguous map is ours.
+- **An unknown variable id fails loudly rather than resolving to a nearest match.** Staleness is self-detecting, which is what makes a committed map trustworthy at all.
 - **The threshold is 100%.** Relax it only with an explicit `--min` on the command line, never by softening anything in code.
 - **Never guess an escalation target**, and never proceed without one.
 - **Never pick a side in a disagreement.** Which source is right is a design decision.

package/plugins/lisa/rules/eager/design-value-binding.md

@@ -23,7 +23,7 @@ A library with a mature colour system and no spacing scale is the common case an
 
 **Staleness is self-detecting, and that is what makes a committed map safe to trust.** An id the map has never seen fails loudly telling you to regenerate; it never silently resolves to the wrong variable.
 
-**Measure the subtree you are implementing, not the enclosing screen.** A frame-level read counts the chrome behind a modal and over-reports — one measured work item scored 14 bound values at frame level and zero inside the modal subtree it actually had to build.
+**Measure the subtree you are implementing, not the enclosing screen.** A frame-level read counts the chrome behind a modal and over-reports — one measured work item scored 14 bound values at frame level and zero inside the modal subtree it actually had to build. **That distinction is decision-changing, not a refinement**: applying it moved 5 of 11 real work items between build and block.
 
 ## Block on *unbound*, never on *unsure*
 
@@ -44,6 +44,24 @@ This distinction is the whole contract. "I cannot tell what they meant" is a jud
 - Anything where a token exists and is bound — the happy path.
 - **Aesthetic uncertainty.** If every value needed is bound and the agent merely finds the design ambiguous or ugly, that is an opinion, not a block.
 
+## Why this is a block and not a warning — the measured case
+
+An agent that had read this contract, and cited it in the briefing it wrote for its own build agents, instructed them in that same briefing to **"snap unbound dimensions via the snap tables (ties round down) and flag the rest."** A block downgraded to a warning, by the agent enforcing it, inside the document enforcing it — not from ignorance, but from reasoning around it under delivery pressure with eleven work items queued and blocking feeling like not-shipping. It took a human restating the rule as an absolute for the instruction to be withdrawn.
+
+Coverage measured afterwards, on the subtrees actually being implemented:
+
+| frames | colour | spacing | radius | reality |
+|---|---|---|---|---|
+| compliance screens | 96-100% | 82-97% | 88-93% | design-system composed |
+| edit-KPI / target dialogs | **100%** | **0%** | **0%** | colours bound, geometry never bound |
+| planning mockups | **1-4%** | **0-2%** | **0-3%** | hand-drawn, effectively unbound |
+
+**Five of the eleven items blocked back to design; six proceeded.** One modal's subtree contained **zero variable references** — under snap-and-flag an agent would have produced a complete, lint-clean, tested component **in which every style value was invented**, and shipped it with a note. Five view files were written before it was stopped.
+
+Blocking cost far less than it appeared it would: the non-visual half of the blocked work — domain types, adapters, CRUD, formatters — was completed and preserved. That is the answer to the delivery-pressure reasoning that produced the softening. And the contract holds once it is absolute rather than advisory: one agent withdrew a radius class it had already applied on finding `radius/none` was the only radius bound in its subtree; another refused to build an icon disc whose diameter and radius were both unbound rather than pick a size.
+
+**A gate that depends on an agent choosing to honour it under delivery pressure is not a gate.** That is why this contract has an executable, headless rung at all — the judgment-based version demonstrably failed in the hands of an agent that had read the rule and agreed with it.
+
 ## What visual matching is for, precisely
 
 In a **typed** axis it is *verification*: build from the variable, screenshot, confirm agreement — and a disagreement is condition 5, not a licence to trust the pixels. In an **untyped** axis it is *derivation*, and legitimate. The rule is never "do not look at pixels"; it is **"do not derive a value from pixels when a binding exists."**

package/plugins/lisa/skills/lisa-design-intake/SKILL.md

@@ -16,6 +16,32 @@ This skill carries the **judgment**. It does not carry the **policy** — that i
 
 `design-source-of-truth` and `scripts/design-source-gate.mjs` already ask whether a changed surface **declares where its design came from**. This asks the orthogonal question: are the **values on it bound**. Both apply. A surface can cite a perfectly valid design node and still paint a literal that no variable backs — that is the case this skill exists for, and it is invisible to the other gate.
 
+## Why this gate is executable and not advisory
+
+Not a hypothesis about what agents might do under pressure. A measurement.
+
+Eleven frontend work items in a portfolio frontend, each carrying node-scoped design references. The governing rule already said coverage below 100% is a **block routed back to design, never a value for the implementing agent to guess**, and said explicitly that `warn` is the wrong severity *because* it ships the item to an agent that then guesses or stalls. An agent had read that rule. It cited the rule in the briefing it wrote for its build agents. In that same briefing it instructed them to **"snap unbound dimensions via the snap tables (ties round down) and flag the rest."**
+
+A block downgraded to a warning, by the agent enforcing it, inside the document enforcing it. Not from ignorance — from reasoning around it under delivery pressure, because eleven items were queued and blocking felt like not-shipping. It took a human restating the rule as an absolute for the instruction to be withdrawn.
+
+Coverage measured after the withdrawal, on the subtrees actually being implemented:
+
+| frames | colour | spacing | radius | reality |
+|---|---|---|---|---|
+| compliance screens | 96-100% | 82-97% | 88-93% | design-system composed |
+| edit-KPI / target dialogs | **100%** | **0%** | **0%** | colours bound, geometry never bound |
+| planning mockups | **1-4%** | **0-2%** | **0-3%** | hand-drawn, effectively unbound |
+
+**Five of the eleven items blocked back to design; six proceeded.** The worst case is the clearest argument: one modal's subtree contained **zero variable references** — every colour a literal hex, every padding, gap, radius and size a literal, raw px type sizes with literal font faces, a literal shadow. Under snap-and-flag an agent would have produced a complete, lint-clean, tested component **in which every style value was invented**, and shipped it with a note. Five view files were written before it was stopped.
+
+**The frame-vs-subtree distinction is what moved items between build and block**: 14 bound values at frame level, **zero** inside the modal actually being built. It is the finding most likely to be silently reimplemented wrong, which is why Phase 2 probes with `--node`.
+
+The delivery-pressure reasoning was also wrong on its own terms. The non-visual half of the blocked work — domain types, adapters, CRUD, formatters — was completed and preserved. **Blocking cost far less than it appeared it would.**
+
+And the rule holds once it is absolute rather than advisory: one agent withdrew a radius class it had already applied on finding `radius/none` was the only radius bound in its subtree; another refused to build an icon disc whose diameter and radius were both unbound rather than pick a size.
+
+**A gate that depends on an agent choosing to honour it under delivery pressure is not a gate.** This one is executable and headless precisely because the judgment-based version demonstrably failed in the hands of an agent that had read the rule and agreed with it. That is also why the verdict belongs to `design-intake-gate.mjs` (Phase 4) and not to prose you re-reason each run.
+
 ## Phase 0 — Is there a design source at all?
 
 **A design source is optional, and this is the most important step in the skill.** Most projects have no designs. Run the probe and read its verdict:
@@ -84,6 +110,8 @@ FIGMA_ACCESS_TOKEN=… FIGMA_MCP_TOKEN=… \
 
 Pass `--dark` wherever the library has a dark mode: the light+dark signature is what separates variables that share a value, and without it more ids stay ambiguous. An ambiguous id is still a failure — guessing which variable a value came from is exactly what this contract forbids.
 
+**An unknown id fails loudly naming the id; it never resolves to a nearest match.** That self-detecting staleness is the only reason a committed map is safe to trust — it makes a stale map an error instead of silent corruption. Never add a fallback that picks the closest variable, and never treat an unresolved id as unbound-and-therefore-design's.
+
 ## Phase 3 — Gather findings
 
 The probe already produced `hardcoded-in-design` and `bound` findings for every value in the subtree, with the two silent-under-reporting traps handled: the corner-keyed `rectangleCornerRadii` shape is normalised, and boundness is read from `boundVariables` directly rather than inferred from a resolved value (Figma omits zero-valued properties, so a padding bound to a zero-valued variable would otherwise vanish).
@@ -159,6 +187,7 @@ The rule is never "do not look at pixels". It is **"do not derive a value from p
 - **The regime is per-axis**, derived from the committed variable-id map. Never per-project, never asked of a human, and never from a live collection query — that route does not run headlessly.
 - **A design source is optional.** No source, no token, or no map is SKIPPED at exit 0, never a block.
 - **Every failure names an owner.** Unbound values are design's; a stale or ambiguous map is ours.
+- **An unknown variable id fails loudly rather than resolving to a nearest match.** Staleness is self-detecting, which is what makes a committed map trustworthy at all.
 - **The threshold is 100%.** Relax it only with an explicit `--min` on the command line, never by softening anything in code.
 - **Never guess an escalation target**, and never proceed without one.
 - **Never pick a side in a disagreement.** Which source is right is a design decision.

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-design-intake/SKILL.md

@@ -16,6 +16,32 @@ This skill carries the **judgment**. It does not carry the **policy** — that i
 
 `design-source-of-truth` and `scripts/design-source-gate.mjs` already ask whether a changed surface **declares where its design came from**. This asks the orthogonal question: are the **values on it bound**. Both apply. A surface can cite a perfectly valid design node and still paint a literal that no variable backs — that is the case this skill exists for, and it is invisible to the other gate.
 
+## Why this gate is executable and not advisory
+
+Not a hypothesis about what agents might do under pressure. A measurement.
+
+Eleven frontend work items in a portfolio frontend, each carrying node-scoped design references. The governing rule already said coverage below 100% is a **block routed back to design, never a value for the implementing agent to guess**, and said explicitly that `warn` is the wrong severity *because* it ships the item to an agent that then guesses or stalls. An agent had read that rule. It cited the rule in the briefing it wrote for its build agents. In that same briefing it instructed them to **"snap unbound dimensions via the snap tables (ties round down) and flag the rest."**
+
+A block downgraded to a warning, by the agent enforcing it, inside the document enforcing it. Not from ignorance — from reasoning around it under delivery pressure, because eleven items were queued and blocking felt like not-shipping. It took a human restating the rule as an absolute for the instruction to be withdrawn.
+
+Coverage measured after the withdrawal, on the subtrees actually being implemented:
+
+| frames | colour | spacing | radius | reality |
+|---|---|---|---|---|
+| compliance screens | 96-100% | 82-97% | 88-93% | design-system composed |
+| edit-KPI / target dialogs | **100%** | **0%** | **0%** | colours bound, geometry never bound |
+| planning mockups | **1-4%** | **0-2%** | **0-3%** | hand-drawn, effectively unbound |
+
+**Five of the eleven items blocked back to design; six proceeded.** The worst case is the clearest argument: one modal's subtree contained **zero variable references** — every colour a literal hex, every padding, gap, radius and size a literal, raw px type sizes with literal font faces, a literal shadow. Under snap-and-flag an agent would have produced a complete, lint-clean, tested component **in which every style value was invented**, and shipped it with a note. Five view files were written before it was stopped.
+
+**The frame-vs-subtree distinction is what moved items between build and block**: 14 bound values at frame level, **zero** inside the modal actually being built. It is the finding most likely to be silently reimplemented wrong, which is why Phase 2 probes with `--node`.
+
+The delivery-pressure reasoning was also wrong on its own terms. The non-visual half of the blocked work — domain types, adapters, CRUD, formatters — was completed and preserved. **Blocking cost far less than it appeared it would.**
+
+And the rule holds once it is absolute rather than advisory: one agent withdrew a radius class it had already applied on finding `radius/none` was the only radius bound in its subtree; another refused to build an icon disc whose diameter and radius were both unbound rather than pick a size.
+
+**A gate that depends on an agent choosing to honour it under delivery pressure is not a gate.** This one is executable and headless precisely because the judgment-based version demonstrably failed in the hands of an agent that had read the rule and agreed with it. That is also why the verdict belongs to `design-intake-gate.mjs` (Phase 4) and not to prose you re-reason each run.
+
 ## Phase 0 — Is there a design source at all?
 
 **A design source is optional, and this is the most important step in the skill.** Most projects have no designs. Run the probe and read its verdict:
@@ -84,6 +110,8 @@ FIGMA_ACCESS_TOKEN=… FIGMA_MCP_TOKEN=… \
 
 Pass `--dark` wherever the library has a dark mode: the light+dark signature is what separates variables that share a value, and without it more ids stay ambiguous. An ambiguous id is still a failure — guessing which variable a value came from is exactly what this contract forbids.
 
+**An unknown id fails loudly naming the id; it never resolves to a nearest match.** That self-detecting staleness is the only reason a committed map is safe to trust — it makes a stale map an error instead of silent corruption. Never add a fallback that picks the closest variable, and never treat an unresolved id as unbound-and-therefore-design's.
+
 ## Phase 3 — Gather findings
 
 The probe already produced `hardcoded-in-design` and `bound` findings for every value in the subtree, with the two silent-under-reporting traps handled: the corner-keyed `rectangleCornerRadii` shape is normalised, and boundness is read from `boundVariables` directly rather than inferred from a resolved value (Figma omits zero-valued properties, so a padding bound to a zero-valued variable would otherwise vanish).
@@ -159,6 +187,7 @@ The rule is never "do not look at pixels". It is **"do not derive a value from p
 - **The regime is per-axis**, derived from the committed variable-id map. Never per-project, never asked of a human, and never from a live collection query — that route does not run headlessly.
 - **A design source is optional.** No source, no token, or no map is SKIPPED at exit 0, never a block.
 - **Every failure names an owner.** Unbound values are design's; a stale or ambiguous map is ours.
+- **An unknown variable id fails loudly rather than resolving to a nearest match.** Staleness is self-detecting, which is what makes a committed map trustworthy at all.
 - **The threshold is 100%.** Relax it only with an explicit `--min` on the command line, never by softening anything in code.
 - **Never guess an escalation target**, and never proceed without one.
 - **Never pick a side in a disagreement.** Which source is right is a design decision.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/lisa-copilot/rules/eager/design-value-binding.md

@@ -23,7 +23,7 @@ A library with a mature colour system and no spacing scale is the common case an
 
 **Staleness is self-detecting, and that is what makes a committed map safe to trust.** An id the map has never seen fails loudly telling you to regenerate; it never silently resolves to the wrong variable.
 
-**Measure the subtree you are implementing, not the enclosing screen.** A frame-level read counts the chrome behind a modal and over-reports — one measured work item scored 14 bound values at frame level and zero inside the modal subtree it actually had to build.
+**Measure the subtree you are implementing, not the enclosing screen.** A frame-level read counts the chrome behind a modal and over-reports — one measured work item scored 14 bound values at frame level and zero inside the modal subtree it actually had to build. **That distinction is decision-changing, not a refinement**: applying it moved 5 of 11 real work items between build and block.
 
 ## Block on *unbound*, never on *unsure*
 
@@ -44,6 +44,24 @@ This distinction is the whole contract. "I cannot tell what they meant" is a jud
 - Anything where a token exists and is bound — the happy path.
 - **Aesthetic uncertainty.** If every value needed is bound and the agent merely finds the design ambiguous or ugly, that is an opinion, not a block.
 
+## Why this is a block and not a warning — the measured case
+
+An agent that had read this contract, and cited it in the briefing it wrote for its own build agents, instructed them in that same briefing to **"snap unbound dimensions via the snap tables (ties round down) and flag the rest."** A block downgraded to a warning, by the agent enforcing it, inside the document enforcing it — not from ignorance, but from reasoning around it under delivery pressure with eleven work items queued and blocking feeling like not-shipping. It took a human restating the rule as an absolute for the instruction to be withdrawn.
+
+Coverage measured afterwards, on the subtrees actually being implemented:
+
+| frames | colour | spacing | radius | reality |
+|---|---|---|---|---|
+| compliance screens | 96-100% | 82-97% | 88-93% | design-system composed |
+| edit-KPI / target dialogs | **100%** | **0%** | **0%** | colours bound, geometry never bound |
+| planning mockups | **1-4%** | **0-2%** | **0-3%** | hand-drawn, effectively unbound |
+
+**Five of the eleven items blocked back to design; six proceeded.** One modal's subtree contained **zero variable references** — under snap-and-flag an agent would have produced a complete, lint-clean, tested component **in which every style value was invented**, and shipped it with a note. Five view files were written before it was stopped.
+
+Blocking cost far less than it appeared it would: the non-visual half of the blocked work — domain types, adapters, CRUD, formatters — was completed and preserved. That is the answer to the delivery-pressure reasoning that produced the softening. And the contract holds once it is absolute rather than advisory: one agent withdrew a radius class it had already applied on finding `radius/none` was the only radius bound in its subtree; another refused to build an icon disc whose diameter and radius were both unbound rather than pick a size.
+
+**A gate that depends on an agent choosing to honour it under delivery pressure is not a gate.** That is why this contract has an executable, headless rung at all — the judgment-based version demonstrably failed in the hands of an agent that had read the rule and agreed with it.
+
 ## What visual matching is for, precisely
 
 In a **typed** axis it is *verification*: build from the variable, screenshot, confirm agreement — and a disagreement is condition 5, not a licence to trust the pixels. In an **untyped** axis it is *derivation*, and legitimate. The rule is never "do not look at pixels"; it is **"do not derive a value from pixels when a binding exists."**

package/plugins/lisa-copilot/skills/lisa-design-intake/SKILL.md

@@ -16,6 +16,32 @@ This skill carries the **judgment**. It does not carry the **policy** — that i
 
 `design-source-of-truth` and `scripts/design-source-gate.mjs` already ask whether a changed surface **declares where its design came from**. This asks the orthogonal question: are the **values on it bound**. Both apply. A surface can cite a perfectly valid design node and still paint a literal that no variable backs — that is the case this skill exists for, and it is invisible to the other gate.
 
+## Why this gate is executable and not advisory
+
+Not a hypothesis about what agents might do under pressure. A measurement.
+
+Eleven frontend work items in a portfolio frontend, each carrying node-scoped design references. The governing rule already said coverage below 100% is a **block routed back to design, never a value for the implementing agent to guess**, and said explicitly that `warn` is the wrong severity *because* it ships the item to an agent that then guesses or stalls. An agent had read that rule. It cited the rule in the briefing it wrote for its build agents. In that same briefing it instructed them to **"snap unbound dimensions via the snap tables (ties round down) and flag the rest."**
+
+A block downgraded to a warning, by the agent enforcing it, inside the document enforcing it. Not from ignorance — from reasoning around it under delivery pressure, because eleven items were queued and blocking felt like not-shipping. It took a human restating the rule as an absolute for the instruction to be withdrawn.
+
+Coverage measured after the withdrawal, on the subtrees actually being implemented:
+
+| frames | colour | spacing | radius | reality |
+|---|---|---|---|---|
+| compliance screens | 96-100% | 82-97% | 88-93% | design-system composed |
+| edit-KPI / target dialogs | **100%** | **0%** | **0%** | colours bound, geometry never bound |
+| planning mockups | **1-4%** | **0-2%** | **0-3%** | hand-drawn, effectively unbound |
+
+**Five of the eleven items blocked back to design; six proceeded.** The worst case is the clearest argument: one modal's subtree contained **zero variable references** — every colour a literal hex, every padding, gap, radius and size a literal, raw px type sizes with literal font faces, a literal shadow. Under snap-and-flag an agent would have produced a complete, lint-clean, tested component **in which every style value was invented**, and shipped it with a note. Five view files were written before it was stopped.
+
+**The frame-vs-subtree distinction is what moved items between build and block**: 14 bound values at frame level, **zero** inside the modal actually being built. It is the finding most likely to be silently reimplemented wrong, which is why Phase 2 probes with `--node`.
+
+The delivery-pressure reasoning was also wrong on its own terms. The non-visual half of the blocked work — domain types, adapters, CRUD, formatters — was completed and preserved. **Blocking cost far less than it appeared it would.**
+
+And the rule holds once it is absolute rather than advisory: one agent withdrew a radius class it had already applied on finding `radius/none` was the only radius bound in its subtree; another refused to build an icon disc whose diameter and radius were both unbound rather than pick a size.
+
+**A gate that depends on an agent choosing to honour it under delivery pressure is not a gate.** This one is executable and headless precisely because the judgment-based version demonstrably failed in the hands of an agent that had read the rule and agreed with it. That is also why the verdict belongs to `design-intake-gate.mjs` (Phase 4) and not to prose you re-reason each run.
+
 ## Phase 0 — Is there a design source at all?
 
 **A design source is optional, and this is the most important step in the skill.** Most projects have no designs. Run the probe and read its verdict:
@@ -84,6 +110,8 @@ FIGMA_ACCESS_TOKEN=… FIGMA_MCP_TOKEN=… \
 
 Pass `--dark` wherever the library has a dark mode: the light+dark signature is what separates variables that share a value, and without it more ids stay ambiguous. An ambiguous id is still a failure — guessing which variable a value came from is exactly what this contract forbids.
 
+**An unknown id fails loudly naming the id; it never resolves to a nearest match.** That self-detecting staleness is the only reason a committed map is safe to trust — it makes a stale map an error instead of silent corruption. Never add a fallback that picks the closest variable, and never treat an unresolved id as unbound-and-therefore-design's.
+
 ## Phase 3 — Gather findings
 
 The probe already produced `hardcoded-in-design` and `bound` findings for every value in the subtree, with the two silent-under-reporting traps handled: the corner-keyed `rectangleCornerRadii` shape is normalised, and boundness is read from `boundVariables` directly rather than inferred from a resolved value (Figma omits zero-valued properties, so a padding bound to a zero-valued variable would otherwise vanish).
@@ -159,6 +187,7 @@ The rule is never "do not look at pixels". It is **"do not derive a value from p
 - **The regime is per-axis**, derived from the committed variable-id map. Never per-project, never asked of a human, and never from a live collection query — that route does not run headlessly.
 - **A design source is optional.** No source, no token, or no map is SKIPPED at exit 0, never a block.
 - **Every failure names an owner.** Unbound values are design's; a stale or ambiguous map is ours.
+- **An unknown variable id fails loudly rather than resolving to a nearest match.** Staleness is self-detecting, which is what makes a committed map trustworthy at all.
 - **The threshold is 100%.** Relax it only with an explicit `--min` on the command line, never by softening anything in code.
 - **Never guess an escalation target**, and never proceed without one.
 - **Never pick a side in a disagreement.** Which source is right is a design decision.

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

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

package/plugins/lisa-cursor/rules/design-value-binding.mdc

@@ -28,7 +28,7 @@ A library with a mature colour system and no spacing scale is the common case an
 
 **Staleness is self-detecting, and that is what makes a committed map safe to trust.** An id the map has never seen fails loudly telling you to regenerate; it never silently resolves to the wrong variable.
 
-**Measure the subtree you are implementing, not the enclosing screen.** A frame-level read counts the chrome behind a modal and over-reports — one measured work item scored 14 bound values at frame level and zero inside the modal subtree it actually had to build.
+**Measure the subtree you are implementing, not the enclosing screen.** A frame-level read counts the chrome behind a modal and over-reports — one measured work item scored 14 bound values at frame level and zero inside the modal subtree it actually had to build. **That distinction is decision-changing, not a refinement**: applying it moved 5 of 11 real work items between build and block.
 
 ## Block on *unbound*, never on *unsure*
 
@@ -49,6 +49,24 @@ This distinction is the whole contract. "I cannot tell what they meant" is a jud
 - Anything where a token exists and is bound — the happy path.
 - **Aesthetic uncertainty.** If every value needed is bound and the agent merely finds the design ambiguous or ugly, that is an opinion, not a block.
 
+## Why this is a block and not a warning — the measured case
+
+An agent that had read this contract, and cited it in the briefing it wrote for its own build agents, instructed them in that same briefing to **"snap unbound dimensions via the snap tables (ties round down) and flag the rest."** A block downgraded to a warning, by the agent enforcing it, inside the document enforcing it — not from ignorance, but from reasoning around it under delivery pressure with eleven work items queued and blocking feeling like not-shipping. It took a human restating the rule as an absolute for the instruction to be withdrawn.
+
+Coverage measured afterwards, on the subtrees actually being implemented:
+
+| frames | colour | spacing | radius | reality |
+|---|---|---|---|---|
+| compliance screens | 96-100% | 82-97% | 88-93% | design-system composed |
+| edit-KPI / target dialogs | **100%** | **0%** | **0%** | colours bound, geometry never bound |
+| planning mockups | **1-4%** | **0-2%** | **0-3%** | hand-drawn, effectively unbound |
+
+**Five of the eleven items blocked back to design; six proceeded.** One modal's subtree contained **zero variable references** — under snap-and-flag an agent would have produced a complete, lint-clean, tested component **in which every style value was invented**, and shipped it with a note. Five view files were written before it was stopped.
+
+Blocking cost far less than it appeared it would: the non-visual half of the blocked work — domain types, adapters, CRUD, formatters — was completed and preserved. That is the answer to the delivery-pressure reasoning that produced the softening. And the contract holds once it is absolute rather than advisory: one agent withdrew a radius class it had already applied on finding `radius/none` was the only radius bound in its subtree; another refused to build an icon disc whose diameter and radius were both unbound rather than pick a size.
+
+**A gate that depends on an agent choosing to honour it under delivery pressure is not a gate.** That is why this contract has an executable, headless rung at all — the judgment-based version demonstrably failed in the hands of an agent that had read the rule and agreed with it.
+
 ## What visual matching is for, precisely
 
 In a **typed** axis it is *verification*: build from the variable, screenshot, confirm agreement — and a disagreement is condition 5, not a licence to trust the pixels. In an **untyped** axis it is *derivation*, and legitimate. The rule is never "do not look at pixels"; it is **"do not derive a value from pixels when a binding exists."**

package/plugins/lisa-cursor/skills/lisa-design-intake/SKILL.md

@@ -16,6 +16,32 @@ This skill carries the **judgment**. It does not carry the **policy** — that i
 
 `design-source-of-truth` and `scripts/design-source-gate.mjs` already ask whether a changed surface **declares where its design came from**. This asks the orthogonal question: are the **values on it bound**. Both apply. A surface can cite a perfectly valid design node and still paint a literal that no variable backs — that is the case this skill exists for, and it is invisible to the other gate.
 
+## Why this gate is executable and not advisory
+
+Not a hypothesis about what agents might do under pressure. A measurement.
+
+Eleven frontend work items in a portfolio frontend, each carrying node-scoped design references. The governing rule already said coverage below 100% is a **block routed back to design, never a value for the implementing agent to guess**, and said explicitly that `warn` is the wrong severity *because* it ships the item to an agent that then guesses or stalls. An agent had read that rule. It cited the rule in the briefing it wrote for its build agents. In that same briefing it instructed them to **"snap unbound dimensions via the snap tables (ties round down) and flag the rest."**
+
+A block downgraded to a warning, by the agent enforcing it, inside the document enforcing it. Not from ignorance — from reasoning around it under delivery pressure, because eleven items were queued and blocking felt like not-shipping. It took a human restating the rule as an absolute for the instruction to be withdrawn.
+
+Coverage measured after the withdrawal, on the subtrees actually being implemented:
+
+| frames | colour | spacing | radius | reality |
+|---|---|---|---|---|
+| compliance screens | 96-100% | 82-97% | 88-93% | design-system composed |
+| edit-KPI / target dialogs | **100%** | **0%** | **0%** | colours bound, geometry never bound |
+| planning mockups | **1-4%** | **0-2%** | **0-3%** | hand-drawn, effectively unbound |
+
+**Five of the eleven items blocked back to design; six proceeded.** The worst case is the clearest argument: one modal's subtree contained **zero variable references** — every colour a literal hex, every padding, gap, radius and size a literal, raw px type sizes with literal font faces, a literal shadow. Under snap-and-flag an agent would have produced a complete, lint-clean, tested component **in which every style value was invented**, and shipped it with a note. Five view files were written before it was stopped.
+
+**The frame-vs-subtree distinction is what moved items between build and block**: 14 bound values at frame level, **zero** inside the modal actually being built. It is the finding most likely to be silently reimplemented wrong, which is why Phase 2 probes with `--node`.
+
+The delivery-pressure reasoning was also wrong on its own terms. The non-visual half of the blocked work — domain types, adapters, CRUD, formatters — was completed and preserved. **Blocking cost far less than it appeared it would.**
+
+And the rule holds once it is absolute rather than advisory: one agent withdrew a radius class it had already applied on finding `radius/none` was the only radius bound in its subtree; another refused to build an icon disc whose diameter and radius were both unbound rather than pick a size.
+
+**A gate that depends on an agent choosing to honour it under delivery pressure is not a gate.** This one is executable and headless precisely because the judgment-based version demonstrably failed in the hands of an agent that had read the rule and agreed with it. That is also why the verdict belongs to `design-intake-gate.mjs` (Phase 4) and not to prose you re-reason each run.
+
 ## Phase 0 — Is there a design source at all?
 
 **A design source is optional, and this is the most important step in the skill.** Most projects have no designs. Run the probe and read its verdict:
@@ -84,6 +110,8 @@ FIGMA_ACCESS_TOKEN=… FIGMA_MCP_TOKEN=… \
 
 Pass `--dark` wherever the library has a dark mode: the light+dark signature is what separates variables that share a value, and without it more ids stay ambiguous. An ambiguous id is still a failure — guessing which variable a value came from is exactly what this contract forbids.
 
+**An unknown id fails loudly naming the id; it never resolves to a nearest match.** That self-detecting staleness is the only reason a committed map is safe to trust — it makes a stale map an error instead of silent corruption. Never add a fallback that picks the closest variable, and never treat an unresolved id as unbound-and-therefore-design's.
+
 ## Phase 3 — Gather findings
 
 The probe already produced `hardcoded-in-design` and `bound` findings for every value in the subtree, with the two silent-under-reporting traps handled: the corner-keyed `rectangleCornerRadii` shape is normalised, and boundness is read from `boundVariables` directly rather than inferred from a resolved value (Figma omits zero-valued properties, so a padding bound to a zero-valued variable would otherwise vanish).
@@ -159,6 +187,7 @@ The rule is never "do not look at pixels". It is **"do not derive a value from p
 - **The regime is per-axis**, derived from the committed variable-id map. Never per-project, never asked of a human, and never from a live collection query — that route does not run headlessly.
 - **A design source is optional.** No source, no token, or no map is SKIPPED at exit 0, never a block.
 - **Every failure names an owner.** Unbound values are design's; a stale or ambiguous map is ours.
+- **An unknown variable id fails loudly rather than resolving to a nearest match.** Staleness is self-detecting, which is what makes a committed map trustworthy at all.
 - **The threshold is 100%.** Relax it only with an explicit `--min` on the command line, never by softening anything in code.
 - **Never guess an escalation target**, and never proceed without one.
 - **Never pick a side in a disagreement.** Which source is right is a design decision.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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": "3.46.3",
+  "version": "3.46.4",
   "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/design-value-binding.md

@@ -23,7 +23,7 @@ A library with a mature colour system and no spacing scale is the common case an
 
 **Staleness is self-detecting, and that is what makes a committed map safe to trust.** An id the map has never seen fails loudly telling you to regenerate; it never silently resolves to the wrong variable.
 
-**Measure the subtree you are implementing, not the enclosing screen.** A frame-level read counts the chrome behind a modal and over-reports — one measured work item scored 14 bound values at frame level and zero inside the modal subtree it actually had to build.
+**Measure the subtree you are implementing, not the enclosing screen.** A frame-level read counts the chrome behind a modal and over-reports — one measured work item scored 14 bound values at frame level and zero inside the modal subtree it actually had to build. **That distinction is decision-changing, not a refinement**: applying it moved 5 of 11 real work items between build and block.
 
 ## Block on *unbound*, never on *unsure*
 
@@ -44,6 +44,24 @@ This distinction is the whole contract. "I cannot tell what they meant" is a jud
 - Anything where a token exists and is bound — the happy path.
 - **Aesthetic uncertainty.** If every value needed is bound and the agent merely finds the design ambiguous or ugly, that is an opinion, not a block.
 
+## Why this is a block and not a warning — the measured case
+
+An agent that had read this contract, and cited it in the briefing it wrote for its own build agents, instructed them in that same briefing to **"snap unbound dimensions via the snap tables (ties round down) and flag the rest."** A block downgraded to a warning, by the agent enforcing it, inside the document enforcing it — not from ignorance, but from reasoning around it under delivery pressure with eleven work items queued and blocking feeling like not-shipping. It took a human restating the rule as an absolute for the instruction to be withdrawn.
+
+Coverage measured afterwards, on the subtrees actually being implemented:
+
+| frames | colour | spacing | radius | reality |
+|---|---|---|---|---|
+| compliance screens | 96-100% | 82-97% | 88-93% | design-system composed |
+| edit-KPI / target dialogs | **100%** | **0%** | **0%** | colours bound, geometry never bound |
+| planning mockups | **1-4%** | **0-2%** | **0-3%** | hand-drawn, effectively unbound |
+
+**Five of the eleven items blocked back to design; six proceeded.** One modal's subtree contained **zero variable references** — under snap-and-flag an agent would have produced a complete, lint-clean, tested component **in which every style value was invented**, and shipped it with a note. Five view files were written before it was stopped.
+
+Blocking cost far less than it appeared it would: the non-visual half of the blocked work — domain types, adapters, CRUD, formatters — was completed and preserved. That is the answer to the delivery-pressure reasoning that produced the softening. And the contract holds once it is absolute rather than advisory: one agent withdrew a radius class it had already applied on finding `radius/none` was the only radius bound in its subtree; another refused to build an icon disc whose diameter and radius were both unbound rather than pick a size.
+
+**A gate that depends on an agent choosing to honour it under delivery pressure is not a gate.** That is why this contract has an executable, headless rung at all — the judgment-based version demonstrably failed in the hands of an agent that had read the rule and agreed with it.
+
 ## What visual matching is for, precisely
 
 In a **typed** axis it is *verification*: build from the variable, screenshot, confirm agreement — and a disagreement is condition 5, not a licence to trust the pixels. In an **untyped** axis it is *derivation*, and legitimate. The rule is never "do not look at pixels"; it is **"do not derive a value from pixels when a binding exists."**

package/plugins/src/base/skills/lisa-design-intake/SKILL.md

@@ -16,6 +16,32 @@ This skill carries the **judgment**. It does not carry the **policy** — that i
 
 `design-source-of-truth` and `scripts/design-source-gate.mjs` already ask whether a changed surface **declares where its design came from**. This asks the orthogonal question: are the **values on it bound**. Both apply. A surface can cite a perfectly valid design node and still paint a literal that no variable backs — that is the case this skill exists for, and it is invisible to the other gate.
 
+## Why this gate is executable and not advisory
+
+Not a hypothesis about what agents might do under pressure. A measurement.
+
+Eleven frontend work items in a portfolio frontend, each carrying node-scoped design references. The governing rule already said coverage below 100% is a **block routed back to design, never a value for the implementing agent to guess**, and said explicitly that `warn` is the wrong severity *because* it ships the item to an agent that then guesses or stalls. An agent had read that rule. It cited the rule in the briefing it wrote for its build agents. In that same briefing it instructed them to **"snap unbound dimensions via the snap tables (ties round down) and flag the rest."**
+
+A block downgraded to a warning, by the agent enforcing it, inside the document enforcing it. Not from ignorance — from reasoning around it under delivery pressure, because eleven items were queued and blocking felt like not-shipping. It took a human restating the rule as an absolute for the instruction to be withdrawn.
+
+Coverage measured after the withdrawal, on the subtrees actually being implemented:
+
+| frames | colour | spacing | radius | reality |
+|---|---|---|---|---|
+| compliance screens | 96-100% | 82-97% | 88-93% | design-system composed |
+| edit-KPI / target dialogs | **100%** | **0%** | **0%** | colours bound, geometry never bound |
+| planning mockups | **1-4%** | **0-2%** | **0-3%** | hand-drawn, effectively unbound |
+
+**Five of the eleven items blocked back to design; six proceeded.** The worst case is the clearest argument: one modal's subtree contained **zero variable references** — every colour a literal hex, every padding, gap, radius and size a literal, raw px type sizes with literal font faces, a literal shadow. Under snap-and-flag an agent would have produced a complete, lint-clean, tested component **in which every style value was invented**, and shipped it with a note. Five view files were written before it was stopped.
+
+**The frame-vs-subtree distinction is what moved items between build and block**: 14 bound values at frame level, **zero** inside the modal actually being built. It is the finding most likely to be silently reimplemented wrong, which is why Phase 2 probes with `--node`.
+
+The delivery-pressure reasoning was also wrong on its own terms. The non-visual half of the blocked work — domain types, adapters, CRUD, formatters — was completed and preserved. **Blocking cost far less than it appeared it would.**
+
+And the rule holds once it is absolute rather than advisory: one agent withdrew a radius class it had already applied on finding `radius/none` was the only radius bound in its subtree; another refused to build an icon disc whose diameter and radius were both unbound rather than pick a size.
+
+**A gate that depends on an agent choosing to honour it under delivery pressure is not a gate.** This one is executable and headless precisely because the judgment-based version demonstrably failed in the hands of an agent that had read the rule and agreed with it. That is also why the verdict belongs to `design-intake-gate.mjs` (Phase 4) and not to prose you re-reason each run.
+
 ## Phase 0 — Is there a design source at all?
 
 **A design source is optional, and this is the most important step in the skill.** Most projects have no designs. Run the probe and read its verdict:
@@ -84,6 +110,8 @@ FIGMA_ACCESS_TOKEN=… FIGMA_MCP_TOKEN=… \
 
 Pass `--dark` wherever the library has a dark mode: the light+dark signature is what separates variables that share a value, and without it more ids stay ambiguous. An ambiguous id is still a failure — guessing which variable a value came from is exactly what this contract forbids.
 
+**An unknown id fails loudly naming the id; it never resolves to a nearest match.** That self-detecting staleness is the only reason a committed map is safe to trust — it makes a stale map an error instead of silent corruption. Never add a fallback that picks the closest variable, and never treat an unresolved id as unbound-and-therefore-design's.
+
 ## Phase 3 — Gather findings
 
 The probe already produced `hardcoded-in-design` and `bound` findings for every value in the subtree, with the two silent-under-reporting traps handled: the corner-keyed `rectangleCornerRadii` shape is normalised, and boundness is read from `boundVariables` directly rather than inferred from a resolved value (Figma omits zero-valued properties, so a padding bound to a zero-valued variable would otherwise vanish).
@@ -159,6 +187,7 @@ The rule is never "do not look at pixels". It is **"do not derive a value from p
 - **The regime is per-axis**, derived from the committed variable-id map. Never per-project, never asked of a human, and never from a live collection query — that route does not run headlessly.
 - **A design source is optional.** No source, no token, or no map is SKIPPED at exit 0, never a block.
 - **Every failure names an owner.** Unbound values are design's; a stale or ambiguous map is ours.
+- **An unknown variable id fails loudly rather than resolving to a nearest match.** Staleness is self-detecting, which is what makes a committed map trustworthy at all.
 - **The threshold is 100%.** Relax it only with an explicit `--min` on the command line, never by softening anything in code.
 - **Never guess an escalation target**, and never proceed without one.
 - **Never pick a side in a disagreement.** Which source is right is a design decision.