@codyswann/lisa 2.299.4 → 2.300.0

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

@@ -428,7 +428,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-github-write-issue/SKILL.md": "ee54b3d14cc5dd3a68a8c36590102dd02f49334c9493ad52fa8c7f35157073b1",
     "plugins/src/base/skills/lisa-github-write-prd/SKILL.md": "bc919c52e2f42129d41a3f40279d2def99486ec58bed2dab51ca7166b427a947",
     "plugins/src/base/skills/lisa-health/SKILL.md": "dfdb08a863e78bff42671793dcec29cfae0654db18ebf66a4aa77aeb56ddb775",
-    "plugins/src/base/skills/lisa-implement/SKILL.md": "cb3a0587907321301e6662480af0d333aee4a3e0d29e9bdc851c225be2c220d7",
+    "plugins/src/base/skills/lisa-implement/SKILL.md": "d01ce8e1af7f4e857810b0c9039481b717ea013bca18e2dc75102a47076d89a0",
     "plugins/src/base/skills/lisa-improve-code-complexity/SKILL.md": "24ab5b193b409db6ee6bee981a1c0a48d08991782d7846116ad01658c8bc1ae8",
     "plugins/src/base/skills/lisa-improve-harness/SKILL.md": "bafda5d2f9b86c48cd16bf0015528fdf5891675221d662fdc533aaad66aad669",
     "plugins/src/base/skills/lisa-improve-max-lines-per-function/SKILL.md": "95c875950c9848fdaf520a18b9bbb264e33d7347be10170add768e01d9cd8e52",
@@ -555,7 +555,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/base/skills/lisa-usage-accounting/SKILL.md": "74ef854c172c74f3c1b916c547ed6945abd9852d453146268e276a8ebc35be4e",
     "plugins/src/base/skills/lisa-use-the-product/SKILL.md": "ab3f3ab475b7c97c3409f502b80d688816b1ff4b8e3dfeec7715d93ca41e3fa0",
     "plugins/src/base/skills/lisa-validate-tracker-mapping/SKILL.md": "ab45fdc00294c4ca9698093cb294a2aaf39a73d714fe1aa6ad686c6c34e157ba",
-    "plugins/src/base/skills/lisa-verification-lifecycle/SKILL.md": "6302896b70d8211e2f412deea8be3e42e68cf36d566759af3c937ccf5287b91c",
+    "plugins/src/base/skills/lisa-verification-lifecycle/SKILL.md": "93c5a31e51a7eb7924a2e019660f94d0de60c88247846bb545f291e5d48f5a72",
     "plugins/src/base/skills/lisa-verify-prd/SKILL.md": "a9deea13d2c201e9b265ee3d36f6dd17358fc35e82ae801e72dd1a3145e6fef8",
     "plugins/src/base/skills/lisa-verify-workflow-change/SKILL.md": "d89740a4dc350a9ac0d26b1b955bf74f009775b60ee0275df3f9a50fe8be3048",
     "plugins/src/base/skills/lisa-verify/SKILL.md": "bd97bd5965c05eafff25fcfeabe0fa7e763f96d5dcab8bf959a78679696c33f1",
@@ -672,7 +672,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "plugins/src/expo/skills/owasp-zap/SKILL.md": "8b78e25e8885d87c799835a7a2733b739e1c971df95cb24ff449710e873983cf",
     "plugins/src/expo/skills/play-store-access/SKILL.md": "ef5f628dfe99b11b3c7216f541c2c0b297a7038730603020accd5c08b798094c",
     "plugins/src/expo/skills/playwright-ci-debugging/SKILL.md": "5160df3f83df8ff469fa51e384564e5264f493ec90a85e75eff5839bb0bd7157",
-    "plugins/src/expo/skills/playwright-selectors/SKILL.md": "705e555a00ebaf8217bce874bb3383cff18663c5478be3b7598ef4ca041aef79",
+    "plugins/src/expo/skills/playwright-selectors/SKILL.md": "2fbc6b2d0b5765a60dad30dfdbd88abaa6916ff442e32ff638fec9508a8c29d8",
     "plugins/src/expo/skills/reduce-complexity/SKILL.md": "301a43335f398507652b1c37198d76f693b180519c90f379d6e53121a695a38e",
     "plugins/src/expo/skills/reduce-complexity/references/extraction-strategies.md": "64cd766bca8623536be7d7c5e5184a9df089bf4bdc5f2b35f8af01feac0a2f49",
     "plugins/src/expo/skills/reduce-complexity/references/refactoring-patterns.md": "fb90a31054bf7760b3865dac8fd058deeaaa681124123173d703794eb7b08468",
@@ -1040,7 +1040,7 @@ export const UPSTREAM_EVIDENCE_MANIFEST = Object.freeze({
     "typescript/merge/.oxlintrc.json": "4debc093acfd263eb81ae15894073ebf098513204f45f40b83fb8fa5353fa1f8",
     "typescript/package-lisa/package.lisa.json": "e661329de6f19550953e3522c0dfbc643397ca9a27e975f23437b64bd50b475c",
     "ui/README.md": "deeb35e767ea5dd2883268835ea3ad21cbad9fa63ec8d8ff5e200f0e2a7d2751",
-    "ui/index.html": "a66598558cb95873aa674055d3bc3335654f7c615013bae0fa8effa35f64c351",
+    "ui/index.html": "1ba31656cacc1382128ec8ca5996e1dc2c5470533f88efed981ae7ba9dd9a088",
 });
 /** Exact paths tracked by the public Lisa repository at generation time. */
 export const UPSTREAM_SURFACE_MANIFEST = Object.freeze({

package/package.json

@@ -115,7 +115,7 @@
     "brace-expansion": ">=5.0.6"
   },
   "name": "@codyswann/lisa",
-  "version": "2.299.4",
+  "version": "2.300.0",
   "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.299.4",
+  "version": "2.300.0",
   "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.299.4",
+  "version": "2.300.0",
   "description": "Universal governance: agents, skills, commands, hooks, and rules for all projects.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/.codex-plugin/skills/lisa-implement/SKILL.md

@@ -139,6 +139,15 @@ The team lead may not waive, defer, demote, or phrase this regression spec as "o
 
 Completion evidence for the regression spec must prove execution, not mere existence. A green CI run is insufficient unless the PR evidence includes a CI log line, reporter output, or equivalent record naming the new spec and showing that it ran and passed. Guard explicitly against `test.skip`, suite-level environment gates, shard filters, and "0 tests" passes.
 
+**Observe the new spec green at least once BEFORE you ship it — ordering matters.** A spec that has never been seen passing anywhere is not regression coverage; it is an untested artifact, and shipping it can break a gate that the current branch does not even run (a spec skipped on the integration branch may be a required gate on the release branch, where it fails for the next author instead of for you). Run it locally first. Only fall back to CI execution proof when local execution is genuinely impossible, and treat that impossibility as a finding to record, not a step to skip.
+
+Two traps make a local run lie, so check both before trusting or blaming a local result:
+
+- **The run may not be testing your code.** Browser harnesses commonly point at a deployed environment unless a CI-only flag is set (for example a Playwright config that defines `webServer` only when `process.env.CI` is set, so a local run silently exercises the deployed app rather than the working tree). A "local pass" obtained this way is a statement about deployed code, and a local failure may be the deployed code failing, not your change. Confirm which artifact is under test before drawing any conclusion.
+- **A red local run may not be your spec.** Before concluding that a new spec is broken, run a **known-good sibling spec, unmodified, in the same mode as a control**. If the control also fails, the surface is not exercisable in that environment and the result says nothing about your spec. If the control passes and yours fails, the defect is yours. Running the control is cheap and is the only reliable way to separate "my spec is wrong" from "this harness cannot run here" — asserting either without it produces confident, wrong conclusions in both directions.
+
+When the control shows the surface is not locally exercisable, that is exit 2 below (a genuine technical blocker): ship the spec only with a linked follow-up that names it as unproven and carries the obligation to confirm it, and say plainly in the PR that the spec has never been observed green. Do not describe an unproven spec as regression coverage.
+
 If the required regression spec is still in flight on an auto-merge-enabled PR, pause auto-merge or use an equivalent merge gate until the spec commit is pushed and its execution proof is available. The flow must not allow the PR to merge before this non-demotable deliverable is satisfied or formally blocked through the linked follow-up path above.
 
 Using the general-purpose agent in Team Lead session, determine how you will know that the task is fully complete. Write this as an **effective completion condition** — one an independent verifier could confirm from observed output alone, not from your assertion that it works. A strong condition has:

package/plugins/lisa/.codex-plugin/skills/lisa-verification-lifecycle/SKILL.md

@@ -76,6 +76,15 @@ Evidence output must explicitly label each verification result as either `verifi
 
 For a required user-visible regression spec, evidence must prove execution, not only existence. Record a CI log line, reporter output, or equivalent artifact that names the new spec and shows it ran and passed in the PR. A green CI run without named execution proof is not enough; explicitly check for `test.skip`, suite-level environment gates, shard filters, and "0 tests" passes.
 
+Prefer observing the new spec green **locally, before it ships**; CI execution proof is the fallback, not the first resort. A spec never seen passing anywhere is an untested artifact rather than coverage, and it can fail later on a branch whose gates differ from this one.
+
+Before trusting or blaming any local run of a browser/device spec, establish two things:
+
+- **Which artifact is under test.** Harnesses often target a deployed environment unless a CI-only flag is set (e.g. a Playwright config defining `webServer` only when `process.env.CI` is set). A pass obtained that way describes deployed code, not the working tree.
+- **Whether the surface is exercisable at all**, by running a **known-good sibling spec unmodified as a control** in the same mode. Control fails too → the environment cannot exercise that surface and the run carries no information about the new spec. Control passes and the new spec fails → the defect is in the new spec.
+
+Record the control result alongside the verdict. A browser-boundary claim marked `not-established` for environmental reasons is only credible with that control; without it the claim is an assumption. When a verdict is later found to rest on one of these traps, state the retraction explicitly in the verdict rather than silently revising it.
+
 If auto-merge is enabled while the regression spec is still in flight, disable auto-merge or apply an equivalent merge gate until the spec commit is pushed and its CI execution proof is available. Do not let the PR merge before the required regression deliverable is satisfied or formally blocked through the linked follow-up path.
 
 ### 7. Codify

package/plugins/lisa/skills/lisa-implement/SKILL.md

@@ -139,6 +139,15 @@ The team lead may not waive, defer, demote, or phrase this regression spec as "o
 
 Completion evidence for the regression spec must prove execution, not mere existence. A green CI run is insufficient unless the PR evidence includes a CI log line, reporter output, or equivalent record naming the new spec and showing that it ran and passed. Guard explicitly against `test.skip`, suite-level environment gates, shard filters, and "0 tests" passes.
 
+**Observe the new spec green at least once BEFORE you ship it — ordering matters.** A spec that has never been seen passing anywhere is not regression coverage; it is an untested artifact, and shipping it can break a gate that the current branch does not even run (a spec skipped on the integration branch may be a required gate on the release branch, where it fails for the next author instead of for you). Run it locally first. Only fall back to CI execution proof when local execution is genuinely impossible, and treat that impossibility as a finding to record, not a step to skip.
+
+Two traps make a local run lie, so check both before trusting or blaming a local result:
+
+- **The run may not be testing your code.** Browser harnesses commonly point at a deployed environment unless a CI-only flag is set (for example a Playwright config that defines `webServer` only when `process.env.CI` is set, so a local run silently exercises the deployed app rather than the working tree). A "local pass" obtained this way is a statement about deployed code, and a local failure may be the deployed code failing, not your change. Confirm which artifact is under test before drawing any conclusion.
+- **A red local run may not be your spec.** Before concluding that a new spec is broken, run a **known-good sibling spec, unmodified, in the same mode as a control**. If the control also fails, the surface is not exercisable in that environment and the result says nothing about your spec. If the control passes and yours fails, the defect is yours. Running the control is cheap and is the only reliable way to separate "my spec is wrong" from "this harness cannot run here" — asserting either without it produces confident, wrong conclusions in both directions.
+
+When the control shows the surface is not locally exercisable, that is exit 2 below (a genuine technical blocker): ship the spec only with a linked follow-up that names it as unproven and carries the obligation to confirm it, and say plainly in the PR that the spec has never been observed green. Do not describe an unproven spec as regression coverage.
+
 If the required regression spec is still in flight on an auto-merge-enabled PR, pause auto-merge or use an equivalent merge gate until the spec commit is pushed and its execution proof is available. The flow must not allow the PR to merge before this non-demotable deliverable is satisfied or formally blocked through the linked follow-up path above.
 
 Using the general-purpose agent in Team Lead session, determine how you will know that the task is fully complete. Write this as an **effective completion condition** — one an independent verifier could confirm from observed output alone, not from your assertion that it works. A strong condition has:

package/plugins/lisa/skills/lisa-verification-lifecycle/SKILL.md

@@ -76,6 +76,15 @@ Evidence output must explicitly label each verification result as either `verifi
 
 For a required user-visible regression spec, evidence must prove execution, not only existence. Record a CI log line, reporter output, or equivalent artifact that names the new spec and shows it ran and passed in the PR. A green CI run without named execution proof is not enough; explicitly check for `test.skip`, suite-level environment gates, shard filters, and "0 tests" passes.
 
+Prefer observing the new spec green **locally, before it ships**; CI execution proof is the fallback, not the first resort. A spec never seen passing anywhere is an untested artifact rather than coverage, and it can fail later on a branch whose gates differ from this one.
+
+Before trusting or blaming any local run of a browser/device spec, establish two things:
+
+- **Which artifact is under test.** Harnesses often target a deployed environment unless a CI-only flag is set (e.g. a Playwright config defining `webServer` only when `process.env.CI` is set). A pass obtained that way describes deployed code, not the working tree.
+- **Whether the surface is exercisable at all**, by running a **known-good sibling spec unmodified as a control** in the same mode. Control fails too → the environment cannot exercise that surface and the run carries no information about the new spec. Control passes and the new spec fails → the defect is in the new spec.
+
+Record the control result alongside the verdict. A browser-boundary claim marked `not-established` for environmental reasons is only credible with that control; without it the claim is an assumption. When a verdict is later found to rest on one of these traps, state the retraction explicitly in the verdict rather than silently revising it.
+
 If auto-merge is enabled while the regression spec is still in flight, disable auto-merge or apply an equivalent merge gate until the spec commit is pushed and its CI execution proof is available. Do not let the PR merge before the required regression deliverable is satisfied or formally blocked through the linked follow-up path.
 
 ### 7. Codify

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/lisa-implement/SKILL.md

@@ -139,6 +139,15 @@ The team lead may not waive, defer, demote, or phrase this regression spec as "o
 
 Completion evidence for the regression spec must prove execution, not mere existence. A green CI run is insufficient unless the PR evidence includes a CI log line, reporter output, or equivalent record naming the new spec and showing that it ran and passed. Guard explicitly against `test.skip`, suite-level environment gates, shard filters, and "0 tests" passes.
 
+**Observe the new spec green at least once BEFORE you ship it — ordering matters.** A spec that has never been seen passing anywhere is not regression coverage; it is an untested artifact, and shipping it can break a gate that the current branch does not even run (a spec skipped on the integration branch may be a required gate on the release branch, where it fails for the next author instead of for you). Run it locally first. Only fall back to CI execution proof when local execution is genuinely impossible, and treat that impossibility as a finding to record, not a step to skip.
+
+Two traps make a local run lie, so check both before trusting or blaming a local result:
+
+- **The run may not be testing your code.** Browser harnesses commonly point at a deployed environment unless a CI-only flag is set (for example a Playwright config that defines `webServer` only when `process.env.CI` is set, so a local run silently exercises the deployed app rather than the working tree). A "local pass" obtained this way is a statement about deployed code, and a local failure may be the deployed code failing, not your change. Confirm which artifact is under test before drawing any conclusion.
+- **A red local run may not be your spec.** Before concluding that a new spec is broken, run a **known-good sibling spec, unmodified, in the same mode as a control**. If the control also fails, the surface is not exercisable in that environment and the result says nothing about your spec. If the control passes and yours fails, the defect is yours. Running the control is cheap and is the only reliable way to separate "my spec is wrong" from "this harness cannot run here" — asserting either without it produces confident, wrong conclusions in both directions.
+
+When the control shows the surface is not locally exercisable, that is exit 2 below (a genuine technical blocker): ship the spec only with a linked follow-up that names it as unproven and carries the obligation to confirm it, and say plainly in the PR that the spec has never been observed green. Do not describe an unproven spec as regression coverage.
+
 If the required regression spec is still in flight on an auto-merge-enabled PR, pause auto-merge or use an equivalent merge gate until the spec commit is pushed and its execution proof is available. The flow must not allow the PR to merge before this non-demotable deliverable is satisfied or formally blocked through the linked follow-up path above.
 
 Using the general-purpose agent in Team Lead session, determine how you will know that the task is fully complete. Write this as an **effective completion condition** — one an independent verifier could confirm from observed output alone, not from your assertion that it works. A strong condition has:

package/plugins/lisa-agy/skills/lisa-verification-lifecycle/SKILL.md

@@ -76,6 +76,15 @@ Evidence output must explicitly label each verification result as either `verifi
 
 For a required user-visible regression spec, evidence must prove execution, not only existence. Record a CI log line, reporter output, or equivalent artifact that names the new spec and shows it ran and passed in the PR. A green CI run without named execution proof is not enough; explicitly check for `test.skip`, suite-level environment gates, shard filters, and "0 tests" passes.
 
+Prefer observing the new spec green **locally, before it ships**; CI execution proof is the fallback, not the first resort. A spec never seen passing anywhere is an untested artifact rather than coverage, and it can fail later on a branch whose gates differ from this one.
+
+Before trusting or blaming any local run of a browser/device spec, establish two things:
+
+- **Which artifact is under test.** Harnesses often target a deployed environment unless a CI-only flag is set (e.g. a Playwright config defining `webServer` only when `process.env.CI` is set). A pass obtained that way describes deployed code, not the working tree.
+- **Whether the surface is exercisable at all**, by running a **known-good sibling spec unmodified as a control** in the same mode. Control fails too → the environment cannot exercise that surface and the run carries no information about the new spec. Control passes and the new spec fails → the defect is in the new spec.
+
+Record the control result alongside the verdict. A browser-boundary claim marked `not-established` for environmental reasons is only credible with that control; without it the claim is an assumption. When a verdict is later found to rest on one of these traps, state the retraction explicitly in the verdict rather than silently revising it.
+
 If auto-merge is enabled while the regression spec is still in flight, disable auto-merge or apply an equivalent merge gate until the spec commit is pushed and its CI execution proof is available. Do not let the PR merge before the required regression deliverable is satisfied or formally blocked through the linked follow-up path.
 
 ### 7. Codify

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

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

package/plugins/lisa-copilot/skills/lisa-implement/SKILL.md

@@ -139,6 +139,15 @@ The team lead may not waive, defer, demote, or phrase this regression spec as "o
 
 Completion evidence for the regression spec must prove execution, not mere existence. A green CI run is insufficient unless the PR evidence includes a CI log line, reporter output, or equivalent record naming the new spec and showing that it ran and passed. Guard explicitly against `test.skip`, suite-level environment gates, shard filters, and "0 tests" passes.
 
+**Observe the new spec green at least once BEFORE you ship it — ordering matters.** A spec that has never been seen passing anywhere is not regression coverage; it is an untested artifact, and shipping it can break a gate that the current branch does not even run (a spec skipped on the integration branch may be a required gate on the release branch, where it fails for the next author instead of for you). Run it locally first. Only fall back to CI execution proof when local execution is genuinely impossible, and treat that impossibility as a finding to record, not a step to skip.
+
+Two traps make a local run lie, so check both before trusting or blaming a local result:
+
+- **The run may not be testing your code.** Browser harnesses commonly point at a deployed environment unless a CI-only flag is set (for example a Playwright config that defines `webServer` only when `process.env.CI` is set, so a local run silently exercises the deployed app rather than the working tree). A "local pass" obtained this way is a statement about deployed code, and a local failure may be the deployed code failing, not your change. Confirm which artifact is under test before drawing any conclusion.
+- **A red local run may not be your spec.** Before concluding that a new spec is broken, run a **known-good sibling spec, unmodified, in the same mode as a control**. If the control also fails, the surface is not exercisable in that environment and the result says nothing about your spec. If the control passes and yours fails, the defect is yours. Running the control is cheap and is the only reliable way to separate "my spec is wrong" from "this harness cannot run here" — asserting either without it produces confident, wrong conclusions in both directions.
+
+When the control shows the surface is not locally exercisable, that is exit 2 below (a genuine technical blocker): ship the spec only with a linked follow-up that names it as unproven and carries the obligation to confirm it, and say plainly in the PR that the spec has never been observed green. Do not describe an unproven spec as regression coverage.
+
 If the required regression spec is still in flight on an auto-merge-enabled PR, pause auto-merge or use an equivalent merge gate until the spec commit is pushed and its execution proof is available. The flow must not allow the PR to merge before this non-demotable deliverable is satisfied or formally blocked through the linked follow-up path above.
 
 Using the general-purpose agent in Team Lead session, determine how you will know that the task is fully complete. Write this as an **effective completion condition** — one an independent verifier could confirm from observed output alone, not from your assertion that it works. A strong condition has:

package/plugins/lisa-copilot/skills/lisa-verification-lifecycle/SKILL.md

@@ -76,6 +76,15 @@ Evidence output must explicitly label each verification result as either `verifi
 
 For a required user-visible regression spec, evidence must prove execution, not only existence. Record a CI log line, reporter output, or equivalent artifact that names the new spec and shows it ran and passed in the PR. A green CI run without named execution proof is not enough; explicitly check for `test.skip`, suite-level environment gates, shard filters, and "0 tests" passes.
 
+Prefer observing the new spec green **locally, before it ships**; CI execution proof is the fallback, not the first resort. A spec never seen passing anywhere is an untested artifact rather than coverage, and it can fail later on a branch whose gates differ from this one.
+
+Before trusting or blaming any local run of a browser/device spec, establish two things:
+
+- **Which artifact is under test.** Harnesses often target a deployed environment unless a CI-only flag is set (e.g. a Playwright config defining `webServer` only when `process.env.CI` is set). A pass obtained that way describes deployed code, not the working tree.
+- **Whether the surface is exercisable at all**, by running a **known-good sibling spec unmodified as a control** in the same mode. Control fails too → the environment cannot exercise that surface and the run carries no information about the new spec. Control passes and the new spec fails → the defect is in the new spec.
+
+Record the control result alongside the verdict. A browser-boundary claim marked `not-established` for environmental reasons is only credible with that control; without it the claim is an assumption. When a verdict is later found to rest on one of these traps, state the retraction explicitly in the verdict rather than silently revising it.
+
 If auto-merge is enabled while the regression spec is still in flight, disable auto-merge or apply an equivalent merge gate until the spec commit is pushed and its CI execution proof is available. Do not let the PR merge before the required regression deliverable is satisfied or formally blocked through the linked follow-up path.
 
 ### 7. Codify

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

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

package/plugins/lisa-cursor/skills/lisa-implement/SKILL.md

@@ -139,6 +139,15 @@ The team lead may not waive, defer, demote, or phrase this regression spec as "o
 
 Completion evidence for the regression spec must prove execution, not mere existence. A green CI run is insufficient unless the PR evidence includes a CI log line, reporter output, or equivalent record naming the new spec and showing that it ran and passed. Guard explicitly against `test.skip`, suite-level environment gates, shard filters, and "0 tests" passes.
 
+**Observe the new spec green at least once BEFORE you ship it — ordering matters.** A spec that has never been seen passing anywhere is not regression coverage; it is an untested artifact, and shipping it can break a gate that the current branch does not even run (a spec skipped on the integration branch may be a required gate on the release branch, where it fails for the next author instead of for you). Run it locally first. Only fall back to CI execution proof when local execution is genuinely impossible, and treat that impossibility as a finding to record, not a step to skip.
+
+Two traps make a local run lie, so check both before trusting or blaming a local result:
+
+- **The run may not be testing your code.** Browser harnesses commonly point at a deployed environment unless a CI-only flag is set (for example a Playwright config that defines `webServer` only when `process.env.CI` is set, so a local run silently exercises the deployed app rather than the working tree). A "local pass" obtained this way is a statement about deployed code, and a local failure may be the deployed code failing, not your change. Confirm which artifact is under test before drawing any conclusion.
+- **A red local run may not be your spec.** Before concluding that a new spec is broken, run a **known-good sibling spec, unmodified, in the same mode as a control**. If the control also fails, the surface is not exercisable in that environment and the result says nothing about your spec. If the control passes and yours fails, the defect is yours. Running the control is cheap and is the only reliable way to separate "my spec is wrong" from "this harness cannot run here" — asserting either without it produces confident, wrong conclusions in both directions.
+
+When the control shows the surface is not locally exercisable, that is exit 2 below (a genuine technical blocker): ship the spec only with a linked follow-up that names it as unproven and carries the obligation to confirm it, and say plainly in the PR that the spec has never been observed green. Do not describe an unproven spec as regression coverage.
+
 If the required regression spec is still in flight on an auto-merge-enabled PR, pause auto-merge or use an equivalent merge gate until the spec commit is pushed and its execution proof is available. The flow must not allow the PR to merge before this non-demotable deliverable is satisfied or formally blocked through the linked follow-up path above.
 
 Using the general-purpose agent in Team Lead session, determine how you will know that the task is fully complete. Write this as an **effective completion condition** — one an independent verifier could confirm from observed output alone, not from your assertion that it works. A strong condition has:

package/plugins/lisa-cursor/skills/lisa-verification-lifecycle/SKILL.md

@@ -76,6 +76,15 @@ Evidence output must explicitly label each verification result as either `verifi
 
 For a required user-visible regression spec, evidence must prove execution, not only existence. Record a CI log line, reporter output, or equivalent artifact that names the new spec and shows it ran and passed in the PR. A green CI run without named execution proof is not enough; explicitly check for `test.skip`, suite-level environment gates, shard filters, and "0 tests" passes.
 
+Prefer observing the new spec green **locally, before it ships**; CI execution proof is the fallback, not the first resort. A spec never seen passing anywhere is an untested artifact rather than coverage, and it can fail later on a branch whose gates differ from this one.
+
+Before trusting or blaming any local run of a browser/device spec, establish two things:
+
+- **Which artifact is under test.** Harnesses often target a deployed environment unless a CI-only flag is set (e.g. a Playwright config defining `webServer` only when `process.env.CI` is set). A pass obtained that way describes deployed code, not the working tree.
+- **Whether the surface is exercisable at all**, by running a **known-good sibling spec unmodified as a control** in the same mode. Control fails too → the environment cannot exercise that surface and the run carries no information about the new spec. Control passes and the new spec fails → the defect is in the new spec.
+
+Record the control result alongside the verdict. A browser-boundary claim marked `not-established` for environmental reasons is only credible with that control; without it the claim is an assumption. When a verdict is later found to rest on one of these traps, state the retraction explicitly in the verdict rather than silently revising it.
+
 If auto-merge is enabled while the regression spec is still in flight, disable auto-merge or apply an equivalent merge gate until the spec commit is pushed and its CI execution proof is available. Do not let the PR merge before the required regression deliverable is satisfied or formally blocked through the linked follow-up path.
 
 ### 7. Codify

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.299.4",
+  "version": "2.300.0",
   "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.299.4",
+  "version": "2.300.0",
   "description": "Expo and React Native-specific skills, agents, rules, and MCP servers.",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.codex-plugin/skills/playwright-selectors/SKILL.md

@@ -271,6 +271,22 @@ export default defineConfig({
 });
 ```
 
+> **Run local verification with `CI=1`.** In a config shaped like the one above,
+> `webServer` exists only when `CI` is set and `baseURL` otherwise points at the
+> **deployed** environment. So a plain `npx playwright test <spec>` does not test your
+> working tree at all — it tests whatever is deployed. A pass proves nothing about your
+> change, and a failure may be the deployed app failing rather than your code. Use
+> `CI=1 npx playwright test <spec>` whenever you are verifying uncommitted work.
+>
+> **Use a control spec before concluding anything from a red run.** If a spec fails
+> locally, re-run a **known-good sibling spec, unmodified, in the same mode**. If the
+> control fails too, that surface is not exercisable in your environment and the run
+> says nothing about your spec — don't "fix" a spec that was never broken. If the
+> control passes, the defect is genuinely yours.
+>
+> Also read reporter totals carefully: `setup` / auth projects count as passing tests.
+> "2 passed" can mean two auth setups and zero assertions.
+
 ---
 
 ## Writing Robust Tests

package/plugins/lisa-expo/skills/playwright-selectors/SKILL.md

@@ -271,6 +271,22 @@ export default defineConfig({
 });
 ```
 
+> **Run local verification with `CI=1`.** In a config shaped like the one above,
+> `webServer` exists only when `CI` is set and `baseURL` otherwise points at the
+> **deployed** environment. So a plain `npx playwright test <spec>` does not test your
+> working tree at all — it tests whatever is deployed. A pass proves nothing about your
+> change, and a failure may be the deployed app failing rather than your code. Use
+> `CI=1 npx playwright test <spec>` whenever you are verifying uncommitted work.
+>
+> **Use a control spec before concluding anything from a red run.** If a spec fails
+> locally, re-run a **known-good sibling spec, unmodified, in the same mode**. If the
+> control fails too, that surface is not exercisable in your environment and the run
+> says nothing about your spec — don't "fix" a spec that was never broken. If the
+> control passes, the defect is genuinely yours.
+>
+> Also read reporter totals carefully: `setup` / auth projects count as passing tests.
+> "2 passed" can mean two auth setups and zero assertions.
+
 ---
 
 ## Writing Robust Tests

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.299.4",
+  "version": "2.300.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-agy/skills/playwright-selectors/SKILL.md

@@ -271,6 +271,22 @@ export default defineConfig({
 });
 ```
 
+> **Run local verification with `CI=1`.** In a config shaped like the one above,
+> `webServer` exists only when `CI` is set and `baseURL` otherwise points at the
+> **deployed** environment. So a plain `npx playwright test <spec>` does not test your
+> working tree at all — it tests whatever is deployed. A pass proves nothing about your
+> change, and a failure may be the deployed app failing rather than your code. Use
+> `CI=1 npx playwright test <spec>` whenever you are verifying uncommitted work.
+>
+> **Use a control spec before concluding anything from a red run.** If a spec fails
+> locally, re-run a **known-good sibling spec, unmodified, in the same mode**. If the
+> control fails too, that surface is not exercisable in your environment and the run
+> says nothing about your spec — don't "fix" a spec that was never broken. If the
+> control passes, the defect is genuinely yours.
+>
+> Also read reporter totals carefully: `setup` / auth projects count as passing tests.
+> "2 passed" can mean two auth setups and zero assertions.
+
 ---
 
 ## Writing Robust Tests

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.299.4",
+  "version": "2.300.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-copilot/skills/playwright-selectors/SKILL.md

@@ -271,6 +271,22 @@ export default defineConfig({
 });
 ```
 
+> **Run local verification with `CI=1`.** In a config shaped like the one above,
+> `webServer` exists only when `CI` is set and `baseURL` otherwise points at the
+> **deployed** environment. So a plain `npx playwright test <spec>` does not test your
+> working tree at all — it tests whatever is deployed. A pass proves nothing about your
+> change, and a failure may be the deployed app failing rather than your code. Use
+> `CI=1 npx playwright test <spec>` whenever you are verifying uncommitted work.
+>
+> **Use a control spec before concluding anything from a red run.** If a spec fails
+> locally, re-run a **known-good sibling spec, unmodified, in the same mode**. If the
+> control fails too, that surface is not exercisable in your environment and the run
+> says nothing about your spec — don't "fix" a spec that was never broken. If the
+> control passes, the defect is genuinely yours.
+>
+> Also read reporter totals carefully: `setup` / auth projects count as passing tests.
+> "2 passed" can mean two auth setups and zero assertions.
+
 ---
 
 ## Writing Robust Tests

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.299.4",
+  "version": "2.300.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo-cursor/skills/playwright-selectors/SKILL.md

@@ -271,6 +271,22 @@ export default defineConfig({
 });
 ```
 
+> **Run local verification with `CI=1`.** In a config shaped like the one above,
+> `webServer` exists only when `CI` is set and `baseURL` otherwise points at the
+> **deployed** environment. So a plain `npx playwright test <spec>` does not test your
+> working tree at all — it tests whatever is deployed. A pass proves nothing about your
+> change, and a failure may be the deployed app failing rather than your code. Use
+> `CI=1 npx playwright test <spec>` whenever you are verifying uncommitted work.
+>
+> **Use a control spec before concluding anything from a red run.** If a spec fails
+> locally, re-run a **known-good sibling spec, unmodified, in the same mode**. If the
+> control fails too, that surface is not exercisable in your environment and the run
+> says nothing about your spec — don't "fix" a spec that was never broken. If the
+> control passes, the defect is genuinely yours.
+>
+> Also read reporter totals carefully: `setup` / auth projects count as passing tests.
+> "2 passed" can mean two auth setups and zero assertions.
+
 ---
 
 ## Writing Robust Tests

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-harper-fabric",
-  "version": "2.299.4",
+  "version": "2.300.0",
   "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.299.4",
+  "version": "2.300.0",
   "description": "Harper/Fabric-specific Lisa rules for TypeScript component apps.",
   "author": {
     "name": "Cody Swann"

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

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

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

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

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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.299.4",
+  "version": "2.300.0",
   "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.299.4",
+  "version": "2.300.0",
   "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.299.4",
+  "version": "2.300.0",
   "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.299.4",
+  "version": "2.300.0",
   "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.299.4",
+  "version": "2.300.0",
   "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.299.4",
+  "version": "2.300.0",
   "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"