@codyswann/lisa 2.130.0 → 2.130.3

package/package.json

@@ -83,7 +83,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.130.0",
+  "version": "2.130.3",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

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

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

package/plugins/lisa/.codex-plugin/plugin.json

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

package/plugins/lisa/skills/atlassian-access/SKILL.md

@@ -268,7 +268,7 @@ Substrate column meanings:
 | `transition key:<K> to:<S>` | `acli jira workitem transition --key <K> --status "<S>" --yes` | `mcp__plugin_atlassian_atlassian__transitionJiraIssue` | resolve transition id then `POST .../issue/<K>/transitions` |
 | `transitions key:<K>` | (not exposed) | `mcp__plugin_atlassian_atlassian__getTransitionsForJiraIssue` | `GET https://<SITE>/rest/api/3/issue/<K>/transitions` |
 | `comment key:<K> body:<B>` | `acli jira workitem comment add --key <K> --body "<B>"` | `mcp__plugin_atlassian_atlassian__addCommentToJiraIssue` | `POST https://<SITE>/rest/api/3/issue/<K>/comment` |
-| `link from:<K> to:<K2> type:<T>` | `acli jira workitem link create --inward <K> --outward <K2> --type "<T>"` | `mcp__plugin_atlassian_atlassian__createJiraIssueLink` | `POST https://<SITE>/rest/api/3/issueLink` |
+| `link from:<K> to:<K2> type:<T>` | `acli jira workitem link create --in <K> --out <K2> --type "<T>" --yes` (see direction note) | `mcp__plugin_atlassian_atlassian__createJiraIssueLink` | `POST https://<SITE>/rest/api/3/issueLink` |
 | `remote-links key:<K>` | (not exposed) | `mcp__plugin_atlassian_atlassian__getJiraIssueRemoteIssueLinks` | `GET https://<SITE>/rest/api/3/issue/<K>/remotelink` |
 | `search-issues jql:<J>` | `acli jira workitem search --jql "<J>" --json` | `mcp__plugin_atlassian_atlassian__searchJiraIssuesUsingJql` | `POST https://<SITE>/rest/api/3/search/jql` |
 | `list-projects` | `acli jira project list --paginate --json` | `mcp__plugin_atlassian_atlassian__getVisibleJiraProjects` | `GET https://<SITE>/rest/api/3/project/search` |
@@ -291,6 +291,8 @@ Substrate column meanings:
 
 **acli flag note:** acli's `--output` flag does not exist; the correct flag is `--json`. List commands require `--paginate` or `--limit` (no implicit fetch-all). `acli jira workitem view` defaults to a restricted field set (`key,issuetype,summary,status,assignee,description`), so `read-ticket` MUST pass `--fields '*all'` or an explicit equivalent that includes every downstream dependency: parent, subtasks, issue links, components, labels, priority, status, issue type, summary, description, fix versions, affected versions, attachments, comments, estimates, sprint/story-point fields, and project-required custom fields. Never rely on the default view fields; they hide parent/components/labels and corrupt leaf-only, relationship-search, build-ready, and required-custom-field gates. Several documented adapters are nominal — verify against `acli <subcmd> --help` before relying on them. When acli's adapter is broken or missing for a specific op, fall through to MCP (if identity-matched) then curl per the tier ordering.
 
+**acli link-create direction is invertible — flags and verification:** acli has no `--inward`/`--outward` flags; the real flags are `--in` and `--out` (confirm with `acli jira workitem link create --help`). For a `Blocks` link, **`--in` is the blocker and `--out` is the blocked** issue, i.e. `--in <X> --out <Y> --type Blocks` resolves to "X blocks Y" (Y `is blocked by` X). The lisa op `link from:<K> to:<K2> type:<T>` means "K ⟨T⟩ K2", so the blocker `from` maps to `--in` and the blocked `to` maps to `--out` (as in the adapter above). The acli success banner only echoes the `--in`/`--out` values you passed — it does NOT confirm the resolved semantic direction, so a reversed link reports success and looks fine. **After every `link` write, re-read the affected issues via `read-ticket` (which already requests `--fields '*all'`) and confirm `issuelinks[].type` + `inwardIssue`/`outwardIssue` resolve to the intended `blocks` / `is blocked by` direction.** Skipping this can silently reverse an entire epic's dependency graph — e.g. cutover tickets recorded as *blocking* the prerequisites that should block them.
+
 **JIRA terminal-resolution note:** when a caller marks a transition as terminal per `leaf-only-lifecycle`, the substrate must not treat a Done-named status as sufficient by name alone. After `transition key:<K> to:<S>`, re-read the issue and verify `statusCategory = Done`; if the workflow requires a resolution, verify `resolution` is set. If the transition screen requires a resolution value, pass the configured default resolution when available; otherwise return a setup error so the build-intake skill can report the workflow gap instead of silently leaving an unresolved ticket in a Done-looking status.
 
 Operations not in this table are unsupported — add an adapter row before using them. Adapters MUST return a structured response (parse `acli`'s `--json`; jq-process curl's raw JSON).

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

@@ -559,8 +559,19 @@ is no normalized `is blocked by` field. Read the bundle, then extract blockers p
 
 Then classify each blocker:
 
-- **Closed / Done** (its true terminal role) → **cleared**.
-- **Open** in any non-terminal role (`ready` / `claimed` / `review` / unknown) → **still
+- **Closed, or shipped to any environment** → **cleared**. A blocker is cleared at **any**
+  env-staged `done` role — not only the production terminal. The `done` role is configured
+  per-env as a `{dev, staging, production}` map (`config-resolution`), so `On Dev`, `On Stg`,
+  **and** production `Done` all mean the blocker's code is merged and deployed to ≥1 environment.
+  A post-build `review` role (e.g. `Code Review`) is likewise cleared — the change exists and is
+  in flight. An `is blocked by` link is a **development** dependency: it is satisfied once the
+  blocker's code is in trunk; it must NOT wait for the blocker to reach production. (This matches
+  the intake-path dependency-hold gate in `lisa:intake-explain`, which already treats
+  `code-review` / `on-dev` / `on-stg` / `done` as cleared — repair-intake must not be stricter.
+  In an env-staged workflow where `Done` means "in production", a strict production-terminal
+  check strands every dependent forever behind a blocker that is already merged and sitting at
+  `On Stg` / `On Dev`.)
+- **Open** in a pre-merge role (`ready` / `claimed` / unknown — code not yet in trunk) → **still
   blocking**.
 - **Inaccessible** (deleted, cross-org, permission denied) → **still blocking**, unless the item
   body or a newer human comment explicitly states the dependency is resolved.

package/plugins/lisa-agy/plugin.json

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

package/plugins/lisa-agy/skills/atlassian-access/SKILL.md

@@ -268,7 +268,7 @@ Substrate column meanings:
 | `transition key:<K> to:<S>` | `acli jira workitem transition --key <K> --status "<S>" --yes` | `mcp__plugin_atlassian_atlassian__transitionJiraIssue` | resolve transition id then `POST .../issue/<K>/transitions` |
 | `transitions key:<K>` | (not exposed) | `mcp__plugin_atlassian_atlassian__getTransitionsForJiraIssue` | `GET https://<SITE>/rest/api/3/issue/<K>/transitions` |
 | `comment key:<K> body:<B>` | `acli jira workitem comment add --key <K> --body "<B>"` | `mcp__plugin_atlassian_atlassian__addCommentToJiraIssue` | `POST https://<SITE>/rest/api/3/issue/<K>/comment` |
-| `link from:<K> to:<K2> type:<T>` | `acli jira workitem link create --inward <K> --outward <K2> --type "<T>"` | `mcp__plugin_atlassian_atlassian__createJiraIssueLink` | `POST https://<SITE>/rest/api/3/issueLink` |
+| `link from:<K> to:<K2> type:<T>` | `acli jira workitem link create --in <K> --out <K2> --type "<T>" --yes` (see direction note) | `mcp__plugin_atlassian_atlassian__createJiraIssueLink` | `POST https://<SITE>/rest/api/3/issueLink` |
 | `remote-links key:<K>` | (not exposed) | `mcp__plugin_atlassian_atlassian__getJiraIssueRemoteIssueLinks` | `GET https://<SITE>/rest/api/3/issue/<K>/remotelink` |
 | `search-issues jql:<J>` | `acli jira workitem search --jql "<J>" --json` | `mcp__plugin_atlassian_atlassian__searchJiraIssuesUsingJql` | `POST https://<SITE>/rest/api/3/search/jql` |
 | `list-projects` | `acli jira project list --paginate --json` | `mcp__plugin_atlassian_atlassian__getVisibleJiraProjects` | `GET https://<SITE>/rest/api/3/project/search` |
@@ -291,6 +291,8 @@ Substrate column meanings:
 
 **acli flag note:** acli's `--output` flag does not exist; the correct flag is `--json`. List commands require `--paginate` or `--limit` (no implicit fetch-all). `acli jira workitem view` defaults to a restricted field set (`key,issuetype,summary,status,assignee,description`), so `read-ticket` MUST pass `--fields '*all'` or an explicit equivalent that includes every downstream dependency: parent, subtasks, issue links, components, labels, priority, status, issue type, summary, description, fix versions, affected versions, attachments, comments, estimates, sprint/story-point fields, and project-required custom fields. Never rely on the default view fields; they hide parent/components/labels and corrupt leaf-only, relationship-search, build-ready, and required-custom-field gates. Several documented adapters are nominal — verify against `acli <subcmd> --help` before relying on them. When acli's adapter is broken or missing for a specific op, fall through to MCP (if identity-matched) then curl per the tier ordering.
 
+**acli link-create direction is invertible — flags and verification:** acli has no `--inward`/`--outward` flags; the real flags are `--in` and `--out` (confirm with `acli jira workitem link create --help`). For a `Blocks` link, **`--in` is the blocker and `--out` is the blocked** issue, i.e. `--in <X> --out <Y> --type Blocks` resolves to "X blocks Y" (Y `is blocked by` X). The lisa op `link from:<K> to:<K2> type:<T>` means "K ⟨T⟩ K2", so the blocker `from` maps to `--in` and the blocked `to` maps to `--out` (as in the adapter above). The acli success banner only echoes the `--in`/`--out` values you passed — it does NOT confirm the resolved semantic direction, so a reversed link reports success and looks fine. **After every `link` write, re-read the affected issues via `read-ticket` (which already requests `--fields '*all'`) and confirm `issuelinks[].type` + `inwardIssue`/`outwardIssue` resolve to the intended `blocks` / `is blocked by` direction.** Skipping this can silently reverse an entire epic's dependency graph — e.g. cutover tickets recorded as *blocking* the prerequisites that should block them.
+
 **JIRA terminal-resolution note:** when a caller marks a transition as terminal per `leaf-only-lifecycle`, the substrate must not treat a Done-named status as sufficient by name alone. After `transition key:<K> to:<S>`, re-read the issue and verify `statusCategory = Done`; if the workflow requires a resolution, verify `resolution` is set. If the transition screen requires a resolution value, pass the configured default resolution when available; otherwise return a setup error so the build-intake skill can report the workflow gap instead of silently leaving an unresolved ticket in a Done-looking status.
 
 Operations not in this table are unsupported — add an adapter row before using them. Adapters MUST return a structured response (parse `acli`'s `--json`; jq-process curl's raw JSON).

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

@@ -559,8 +559,19 @@ is no normalized `is blocked by` field. Read the bundle, then extract blockers p
 
 Then classify each blocker:
 
-- **Closed / Done** (its true terminal role) → **cleared**.
-- **Open** in any non-terminal role (`ready` / `claimed` / `review` / unknown) → **still
+- **Closed, or shipped to any environment** → **cleared**. A blocker is cleared at **any**
+  env-staged `done` role — not only the production terminal. The `done` role is configured
+  per-env as a `{dev, staging, production}` map (`config-resolution`), so `On Dev`, `On Stg`,
+  **and** production `Done` all mean the blocker's code is merged and deployed to ≥1 environment.
+  A post-build `review` role (e.g. `Code Review`) is likewise cleared — the change exists and is
+  in flight. An `is blocked by` link is a **development** dependency: it is satisfied once the
+  blocker's code is in trunk; it must NOT wait for the blocker to reach production. (This matches
+  the intake-path dependency-hold gate in `lisa:intake-explain`, which already treats
+  `code-review` / `on-dev` / `on-stg` / `done` as cleared — repair-intake must not be stricter.
+  In an env-staged workflow where `Done` means "in production", a strict production-terminal
+  check strands every dependent forever behind a blocker that is already merged and sitting at
+  `On Stg` / `On Dev`.)
+- **Open** in a pre-merge role (`ready` / `claimed` / unknown — code not yet in trunk) → **still
   blocking**.
 - **Inaccessible** (deleted, cross-org, permission denied) → **still blocking**, unless the item
   body or a newer human comment explicitly states the dependency is resolved.

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.130.0",
+  "version": "2.130.3",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.130.0",
+  "version": "2.130.3",
   "description": "AWS CDK-specific Lisa plugin.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.130.0",
+  "version": "2.130.3",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.130.0",
+  "version": "2.130.3",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.130.0",
+  "version": "2.130.3",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

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

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

package/plugins/lisa-copilot/skills/atlassian-access/SKILL.md

@@ -268,7 +268,7 @@ Substrate column meanings:
 | `transition key:<K> to:<S>` | `acli jira workitem transition --key <K> --status "<S>" --yes` | `mcp__plugin_atlassian_atlassian__transitionJiraIssue` | resolve transition id then `POST .../issue/<K>/transitions` |
 | `transitions key:<K>` | (not exposed) | `mcp__plugin_atlassian_atlassian__getTransitionsForJiraIssue` | `GET https://<SITE>/rest/api/3/issue/<K>/transitions` |
 | `comment key:<K> body:<B>` | `acli jira workitem comment add --key <K> --body "<B>"` | `mcp__plugin_atlassian_atlassian__addCommentToJiraIssue` | `POST https://<SITE>/rest/api/3/issue/<K>/comment` |
-| `link from:<K> to:<K2> type:<T>` | `acli jira workitem link create --inward <K> --outward <K2> --type "<T>"` | `mcp__plugin_atlassian_atlassian__createJiraIssueLink` | `POST https://<SITE>/rest/api/3/issueLink` |
+| `link from:<K> to:<K2> type:<T>` | `acli jira workitem link create --in <K> --out <K2> --type "<T>" --yes` (see direction note) | `mcp__plugin_atlassian_atlassian__createJiraIssueLink` | `POST https://<SITE>/rest/api/3/issueLink` |
 | `remote-links key:<K>` | (not exposed) | `mcp__plugin_atlassian_atlassian__getJiraIssueRemoteIssueLinks` | `GET https://<SITE>/rest/api/3/issue/<K>/remotelink` |
 | `search-issues jql:<J>` | `acli jira workitem search --jql "<J>" --json` | `mcp__plugin_atlassian_atlassian__searchJiraIssuesUsingJql` | `POST https://<SITE>/rest/api/3/search/jql` |
 | `list-projects` | `acli jira project list --paginate --json` | `mcp__plugin_atlassian_atlassian__getVisibleJiraProjects` | `GET https://<SITE>/rest/api/3/project/search` |
@@ -291,6 +291,8 @@ Substrate column meanings:
 
 **acli flag note:** acli's `--output` flag does not exist; the correct flag is `--json`. List commands require `--paginate` or `--limit` (no implicit fetch-all). `acli jira workitem view` defaults to a restricted field set (`key,issuetype,summary,status,assignee,description`), so `read-ticket` MUST pass `--fields '*all'` or an explicit equivalent that includes every downstream dependency: parent, subtasks, issue links, components, labels, priority, status, issue type, summary, description, fix versions, affected versions, attachments, comments, estimates, sprint/story-point fields, and project-required custom fields. Never rely on the default view fields; they hide parent/components/labels and corrupt leaf-only, relationship-search, build-ready, and required-custom-field gates. Several documented adapters are nominal — verify against `acli <subcmd> --help` before relying on them. When acli's adapter is broken or missing for a specific op, fall through to MCP (if identity-matched) then curl per the tier ordering.
 
+**acli link-create direction is invertible — flags and verification:** acli has no `--inward`/`--outward` flags; the real flags are `--in` and `--out` (confirm with `acli jira workitem link create --help`). For a `Blocks` link, **`--in` is the blocker and `--out` is the blocked** issue, i.e. `--in <X> --out <Y> --type Blocks` resolves to "X blocks Y" (Y `is blocked by` X). The lisa op `link from:<K> to:<K2> type:<T>` means "K ⟨T⟩ K2", so the blocker `from` maps to `--in` and the blocked `to` maps to `--out` (as in the adapter above). The acli success banner only echoes the `--in`/`--out` values you passed — it does NOT confirm the resolved semantic direction, so a reversed link reports success and looks fine. **After every `link` write, re-read the affected issues via `read-ticket` (which already requests `--fields '*all'`) and confirm `issuelinks[].type` + `inwardIssue`/`outwardIssue` resolve to the intended `blocks` / `is blocked by` direction.** Skipping this can silently reverse an entire epic's dependency graph — e.g. cutover tickets recorded as *blocking* the prerequisites that should block them.
+
 **JIRA terminal-resolution note:** when a caller marks a transition as terminal per `leaf-only-lifecycle`, the substrate must not treat a Done-named status as sufficient by name alone. After `transition key:<K> to:<S>`, re-read the issue and verify `statusCategory = Done`; if the workflow requires a resolution, verify `resolution` is set. If the transition screen requires a resolution value, pass the configured default resolution when available; otherwise return a setup error so the build-intake skill can report the workflow gap instead of silently leaving an unresolved ticket in a Done-looking status.
 
 Operations not in this table are unsupported — add an adapter row before using them. Adapters MUST return a structured response (parse `acli`'s `--json`; jq-process curl's raw JSON).

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

@@ -559,8 +559,19 @@ is no normalized `is blocked by` field. Read the bundle, then extract blockers p
 
 Then classify each blocker:
 
-- **Closed / Done** (its true terminal role) → **cleared**.
-- **Open** in any non-terminal role (`ready` / `claimed` / `review` / unknown) → **still
+- **Closed, or shipped to any environment** → **cleared**. A blocker is cleared at **any**
+  env-staged `done` role — not only the production terminal. The `done` role is configured
+  per-env as a `{dev, staging, production}` map (`config-resolution`), so `On Dev`, `On Stg`,
+  **and** production `Done` all mean the blocker's code is merged and deployed to ≥1 environment.
+  A post-build `review` role (e.g. `Code Review`) is likewise cleared — the change exists and is
+  in flight. An `is blocked by` link is a **development** dependency: it is satisfied once the
+  blocker's code is in trunk; it must NOT wait for the blocker to reach production. (This matches
+  the intake-path dependency-hold gate in `lisa:intake-explain`, which already treats
+  `code-review` / `on-dev` / `on-stg` / `done` as cleared — repair-intake must not be stricter.
+  In an env-staged workflow where `Done` means "in production", a strict production-terminal
+  check strands every dependent forever behind a blocker that is already merged and sitting at
+  `On Stg` / `On Dev`.)
+- **Open** in a pre-merge role (`ready` / `claimed` / unknown — code not yet in trunk) → **still
   blocking**.
 - **Inaccessible** (deleted, cross-org, permission denied) → **still blocking**, unless the item
   body or a newer human comment explicitly states the dependency is resolved.

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

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

package/plugins/lisa-cursor/skills/atlassian-access/SKILL.md

@@ -268,7 +268,7 @@ Substrate column meanings:
 | `transition key:<K> to:<S>` | `acli jira workitem transition --key <K> --status "<S>" --yes` | `mcp__plugin_atlassian_atlassian__transitionJiraIssue` | resolve transition id then `POST .../issue/<K>/transitions` |
 | `transitions key:<K>` | (not exposed) | `mcp__plugin_atlassian_atlassian__getTransitionsForJiraIssue` | `GET https://<SITE>/rest/api/3/issue/<K>/transitions` |
 | `comment key:<K> body:<B>` | `acli jira workitem comment add --key <K> --body "<B>"` | `mcp__plugin_atlassian_atlassian__addCommentToJiraIssue` | `POST https://<SITE>/rest/api/3/issue/<K>/comment` |
-| `link from:<K> to:<K2> type:<T>` | `acli jira workitem link create --inward <K> --outward <K2> --type "<T>"` | `mcp__plugin_atlassian_atlassian__createJiraIssueLink` | `POST https://<SITE>/rest/api/3/issueLink` |
+| `link from:<K> to:<K2> type:<T>` | `acli jira workitem link create --in <K> --out <K2> --type "<T>" --yes` (see direction note) | `mcp__plugin_atlassian_atlassian__createJiraIssueLink` | `POST https://<SITE>/rest/api/3/issueLink` |
 | `remote-links key:<K>` | (not exposed) | `mcp__plugin_atlassian_atlassian__getJiraIssueRemoteIssueLinks` | `GET https://<SITE>/rest/api/3/issue/<K>/remotelink` |
 | `search-issues jql:<J>` | `acli jira workitem search --jql "<J>" --json` | `mcp__plugin_atlassian_atlassian__searchJiraIssuesUsingJql` | `POST https://<SITE>/rest/api/3/search/jql` |
 | `list-projects` | `acli jira project list --paginate --json` | `mcp__plugin_atlassian_atlassian__getVisibleJiraProjects` | `GET https://<SITE>/rest/api/3/project/search` |
@@ -291,6 +291,8 @@ Substrate column meanings:
 
 **acli flag note:** acli's `--output` flag does not exist; the correct flag is `--json`. List commands require `--paginate` or `--limit` (no implicit fetch-all). `acli jira workitem view` defaults to a restricted field set (`key,issuetype,summary,status,assignee,description`), so `read-ticket` MUST pass `--fields '*all'` or an explicit equivalent that includes every downstream dependency: parent, subtasks, issue links, components, labels, priority, status, issue type, summary, description, fix versions, affected versions, attachments, comments, estimates, sprint/story-point fields, and project-required custom fields. Never rely on the default view fields; they hide parent/components/labels and corrupt leaf-only, relationship-search, build-ready, and required-custom-field gates. Several documented adapters are nominal — verify against `acli <subcmd> --help` before relying on them. When acli's adapter is broken or missing for a specific op, fall through to MCP (if identity-matched) then curl per the tier ordering.
 
+**acli link-create direction is invertible — flags and verification:** acli has no `--inward`/`--outward` flags; the real flags are `--in` and `--out` (confirm with `acli jira workitem link create --help`). For a `Blocks` link, **`--in` is the blocker and `--out` is the blocked** issue, i.e. `--in <X> --out <Y> --type Blocks` resolves to "X blocks Y" (Y `is blocked by` X). The lisa op `link from:<K> to:<K2> type:<T>` means "K ⟨T⟩ K2", so the blocker `from` maps to `--in` and the blocked `to` maps to `--out` (as in the adapter above). The acli success banner only echoes the `--in`/`--out` values you passed — it does NOT confirm the resolved semantic direction, so a reversed link reports success and looks fine. **After every `link` write, re-read the affected issues via `read-ticket` (which already requests `--fields '*all'`) and confirm `issuelinks[].type` + `inwardIssue`/`outwardIssue` resolve to the intended `blocks` / `is blocked by` direction.** Skipping this can silently reverse an entire epic's dependency graph — e.g. cutover tickets recorded as *blocking* the prerequisites that should block them.
+
 **JIRA terminal-resolution note:** when a caller marks a transition as terminal per `leaf-only-lifecycle`, the substrate must not treat a Done-named status as sufficient by name alone. After `transition key:<K> to:<S>`, re-read the issue and verify `statusCategory = Done`; if the workflow requires a resolution, verify `resolution` is set. If the transition screen requires a resolution value, pass the configured default resolution when available; otherwise return a setup error so the build-intake skill can report the workflow gap instead of silently leaving an unresolved ticket in a Done-looking status.
 
 Operations not in this table are unsupported — add an adapter row before using them. Adapters MUST return a structured response (parse `acli`'s `--json`; jq-process curl's raw JSON).

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

@@ -559,8 +559,19 @@ is no normalized `is blocked by` field. Read the bundle, then extract blockers p
 
 Then classify each blocker:
 
-- **Closed / Done** (its true terminal role) → **cleared**.
-- **Open** in any non-terminal role (`ready` / `claimed` / `review` / unknown) → **still
+- **Closed, or shipped to any environment** → **cleared**. A blocker is cleared at **any**
+  env-staged `done` role — not only the production terminal. The `done` role is configured
+  per-env as a `{dev, staging, production}` map (`config-resolution`), so `On Dev`, `On Stg`,
+  **and** production `Done` all mean the blocker's code is merged and deployed to ≥1 environment.
+  A post-build `review` role (e.g. `Code Review`) is likewise cleared — the change exists and is
+  in flight. An `is blocked by` link is a **development** dependency: it is satisfied once the
+  blocker's code is in trunk; it must NOT wait for the blocker to reach production. (This matches
+  the intake-path dependency-hold gate in `lisa:intake-explain`, which already treats
+  `code-review` / `on-dev` / `on-stg` / `done` as cleared — repair-intake must not be stricter.
+  In an env-staged workflow where `Done` means "in production", a strict production-terminal
+  check strands every dependent forever behind a blocker that is already merged and sitting at
+  `On Stg` / `On Dev`.)
+- **Open** in a pre-merge role (`ready` / `claimed` / unknown — code not yet in trunk) → **still
   blocking**.
 - **Inaccessible** (deleted, cross-org, permission denied) → **still blocking**, unless the item
   body or a newer human comment explicitly states the dependency is resolved.

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

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

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

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

package/plugins/lisa-expo/commands/exploratory-qa.md

@@ -1,5 +1,5 @@
 ---
-description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user, clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
+description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user, clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
 allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---

package/plugins/lisa-expo/skills/exploratory-qa/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: exploratory-qa
-description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
+description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
 ---
 
 # Exploratory QA
@@ -68,8 +68,12 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
 - **Consistency / standard UX:** components, spacing, button styles, terminology, and interaction
   patterns should be consistent across the app and follow common conventions. Flag anything
   non-standard or that differs screen-to-screen.
-- **Load & responsiveness:** long or unclear load times, blank screens, spinners / `Loading...` /
-  `Connecting...` with no progress, anything that feels slow or janky.
+- **Load & responsiveness:** long or unclear load times, blank screens, skeleton-only shells, spinners
+  / `Loading...` / `Connecting...` with no progress, anything that feels slow or janky. Flag pages
+  where the browser reports `loaded` / `complete` but meaningful content arrives much later, or where
+  the visible shell appears quickly while the real task content remains missing. Capture user-perceived
+  timings: shell visible, first meaningful content, and stable/complete content. If the delay is
+  noticeable, file a usability/performance ticket even if the eventual content is correct.
 - **Scroll behavior:** unexpected scroll position, scroll jumps, nested or locked scroll, sticky
   elements that cover content, content that cannot be reached.
 - **Behavior correctness:** does the obvious action do what a user expects? Confusing errors, silent
@@ -86,10 +90,15 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
 
 ### 5. Watch Load & Latency
 
-- Notice time to first meaningful content and time spent in blank/loading/spinner/connecting states.
-- A page can be technically interactive but still visually incomplete — note that.
-- Treat long waits without clear progress, error, retry, or cancellation as findings. Use practical
-  labels (noticeable, slow, unacceptable) and include observed durations when available.
+- Measure separate milestones: visible app shell, `document.readyState`, first meaningful
+  route-specific content, and visually stable/full route content.
+- Do not treat a visible shell, completed document, or technically clickable page as loaded if the
+  route is still blank, skeleton-only, placeholder-only, or waiting for primary data.
+- Treat skeleton-only/placeholder-only screens as loading states. If they persist for a noticeable
+  delay, they need clear progress/loading messaging that explains what is happening.
+- Treat long waits to meaningful content or stable/full content without clear progress, error, retry,
+  or cancellation as findings. Use practical labels (noticeable, slow, unacceptable) and include
+  observed durations when available.
 
 ## Mutation Discipline
 

package/plugins/lisa-expo-agy/commands/exploratory-qa.md

@@ -1,5 +1,5 @@
 ---
-description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user, clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
+description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user, clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
 allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---

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

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

package/plugins/lisa-expo-agy/skills/exploratory-qa/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: exploratory-qa
-description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
+description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
 ---
 
 # Exploratory QA
@@ -68,8 +68,12 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
 - **Consistency / standard UX:** components, spacing, button styles, terminology, and interaction
   patterns should be consistent across the app and follow common conventions. Flag anything
   non-standard or that differs screen-to-screen.
-- **Load & responsiveness:** long or unclear load times, blank screens, spinners / `Loading...` /
-  `Connecting...` with no progress, anything that feels slow or janky.
+- **Load & responsiveness:** long or unclear load times, blank screens, skeleton-only shells, spinners
+  / `Loading...` / `Connecting...` with no progress, anything that feels slow or janky. Flag pages
+  where the browser reports `loaded` / `complete` but meaningful content arrives much later, or where
+  the visible shell appears quickly while the real task content remains missing. Capture user-perceived
+  timings: shell visible, first meaningful content, and stable/complete content. If the delay is
+  noticeable, file a usability/performance ticket even if the eventual content is correct.
 - **Scroll behavior:** unexpected scroll position, scroll jumps, nested or locked scroll, sticky
   elements that cover content, content that cannot be reached.
 - **Behavior correctness:** does the obvious action do what a user expects? Confusing errors, silent
@@ -86,10 +90,15 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
 
 ### 5. Watch Load & Latency
 
-- Notice time to first meaningful content and time spent in blank/loading/spinner/connecting states.
-- A page can be technically interactive but still visually incomplete — note that.
-- Treat long waits without clear progress, error, retry, or cancellation as findings. Use practical
-  labels (noticeable, slow, unacceptable) and include observed durations when available.
+- Measure separate milestones: visible app shell, `document.readyState`, first meaningful
+  route-specific content, and visually stable/full route content.
+- Do not treat a visible shell, completed document, or technically clickable page as loaded if the
+  route is still blank, skeleton-only, placeholder-only, or waiting for primary data.
+- Treat skeleton-only/placeholder-only screens as loading states. If they persist for a noticeable
+  delay, they need clear progress/loading messaging that explains what is happening.
+- Treat long waits to meaningful content or stable/full content without clear progress, error, retry,
+  or cancellation as findings. Use practical labels (noticeable, slow, unacceptable) and include
+  observed durations when available.
 
 ## Mutation Discipline
 

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

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

package/plugins/lisa-expo-copilot/commands/exploratory-qa.md

@@ -1,5 +1,5 @@
 ---
-description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user, clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
+description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user, clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
 allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---

package/plugins/lisa-expo-copilot/skills/exploratory-qa/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: exploratory-qa
-description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
+description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
 ---
 
 # Exploratory QA
@@ -68,8 +68,12 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
 - **Consistency / standard UX:** components, spacing, button styles, terminology, and interaction
   patterns should be consistent across the app and follow common conventions. Flag anything
   non-standard or that differs screen-to-screen.
-- **Load & responsiveness:** long or unclear load times, blank screens, spinners / `Loading...` /
-  `Connecting...` with no progress, anything that feels slow or janky.
+- **Load & responsiveness:** long or unclear load times, blank screens, skeleton-only shells, spinners
+  / `Loading...` / `Connecting...` with no progress, anything that feels slow or janky. Flag pages
+  where the browser reports `loaded` / `complete` but meaningful content arrives much later, or where
+  the visible shell appears quickly while the real task content remains missing. Capture user-perceived
+  timings: shell visible, first meaningful content, and stable/complete content. If the delay is
+  noticeable, file a usability/performance ticket even if the eventual content is correct.
 - **Scroll behavior:** unexpected scroll position, scroll jumps, nested or locked scroll, sticky
   elements that cover content, content that cannot be reached.
 - **Behavior correctness:** does the obvious action do what a user expects? Confusing errors, silent
@@ -86,10 +90,15 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
 
 ### 5. Watch Load & Latency
 
-- Notice time to first meaningful content and time spent in blank/loading/spinner/connecting states.
-- A page can be technically interactive but still visually incomplete — note that.
-- Treat long waits without clear progress, error, retry, or cancellation as findings. Use practical
-  labels (noticeable, slow, unacceptable) and include observed durations when available.
+- Measure separate milestones: visible app shell, `document.readyState`, first meaningful
+  route-specific content, and visually stable/full route content.
+- Do not treat a visible shell, completed document, or technically clickable page as loaded if the
+  route is still blank, skeleton-only, placeholder-only, or waiting for primary data.
+- Treat skeleton-only/placeholder-only screens as loading states. If they persist for a noticeable
+  delay, they need clear progress/loading messaging that explains what is happening.
+- Treat long waits to meaningful content or stable/full content without clear progress, error, retry,
+  or cancellation as findings. Use practical labels (noticeable, slow, unacceptable) and include
+  observed durations when available.
 
 ## Mutation Discipline
 

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

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

package/plugins/lisa-expo-cursor/commands/exploratory-qa.md

@@ -1,5 +1,5 @@
 ---
-description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user, clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
+description: "Run a first-time-user exploratory QA walkthrough: experience the app like a brand-new human user, clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent UX, awkward scroll behavior) across all breakpoints, and file each finding (bug or usability issue) as a tracked work item via lisa:tracker-write. The optional ready flag marks tickets build-ready (auto-picked-up by lisa:intake) or leaves them in the backlog for human triage (default). For gaps in the automated Playwright suite, use e2e-coverage-gaps instead."
 allowed-tools: ["Skill"]
 argument-hint: "[target-url | env] [ready=true|false]"
 ---

package/plugins/lisa-expo-cursor/skills/exploratory-qa/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: exploratory-qa
-description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
+description: First-time-user exploratory QA walkthrough for web apps that FEEDS THE LIFECYCLE. Use when asked to experience an app the way a brand-new human user would — landing cold on the home page and clicking through to find anything confusing, broken, or hard to understand (human-facing jargon, contextless extracted data, machine-style labels, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances) across all breakpoints. Instead of writing a report file, it files every finding as a tracked work item via lisa:tracker-write (bugs and usability/UX issues). A `ready` parameter controls whether those tickets are created build-ready (auto-picked-up by lisa:intake) or left in the backlog for human triage (default). For gaps in the automated Playwright test suite, use the e2e-coverage-gaps skill instead.
 ---
 
 # Exploratory QA
@@ -68,8 +68,12 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
 - **Consistency / standard UX:** components, spacing, button styles, terminology, and interaction
   patterns should be consistent across the app and follow common conventions. Flag anything
   non-standard or that differs screen-to-screen.
-- **Load & responsiveness:** long or unclear load times, blank screens, spinners / `Loading...` /
-  `Connecting...` with no progress, anything that feels slow or janky.
+- **Load & responsiveness:** long or unclear load times, blank screens, skeleton-only shells, spinners
+  / `Loading...` / `Connecting...` with no progress, anything that feels slow or janky. Flag pages
+  where the browser reports `loaded` / `complete` but meaningful content arrives much later, or where
+  the visible shell appears quickly while the real task content remains missing. Capture user-perceived
+  timings: shell visible, first meaningful content, and stable/complete content. If the delay is
+  noticeable, file a usability/performance ticket even if the eventual content is correct.
 - **Scroll behavior:** unexpected scroll position, scroll jumps, nested or locked scroll, sticky
   elements that cover content, content that cannot be reached.
 - **Behavior correctness:** does the obvious action do what a user expects? Confusing errors, silent
@@ -86,10 +90,15 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
 
 ### 5. Watch Load & Latency
 
-- Notice time to first meaningful content and time spent in blank/loading/spinner/connecting states.
-- A page can be technically interactive but still visually incomplete — note that.
-- Treat long waits without clear progress, error, retry, or cancellation as findings. Use practical
-  labels (noticeable, slow, unacceptable) and include observed durations when available.
+- Measure separate milestones: visible app shell, `document.readyState`, first meaningful
+  route-specific content, and visually stable/full route content.
+- Do not treat a visible shell, completed document, or technically clickable page as loaded if the
+  route is still blank, skeleton-only, placeholder-only, or waiting for primary data.
+- Treat skeleton-only/placeholder-only screens as loading states. If they persist for a noticeable
+  delay, they need clear progress/loading messaging that explains what is happening.
+- Treat long waits to meaningful content or stable/full content without clear progress, error, retry,
+  or cancellation as findings. Use practical labels (noticeable, slow, unacceptable) and include
+  observed durations when available.
 
 ## Mutation Discipline
 

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

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

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

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