@codyswann/lisa 2.155.4 → 2.155.6

package/plugins/lisa-rails-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, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) 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 (unclear purpose or audience, human-facing jargon, contextless extracted data, machine-style labels, raw dates/enums, sparse data with no explanation, wrong control semantics, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) 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
@@ -43,6 +43,9 @@ filed as a tracked work item so it enters the Lisa lifecycle — no static repor
 - Start at the home/landing page with **no prior knowledge of the app**. Do **not** pre-read the
   codebase to learn the intended flows — discover them the way a user would, by looking and clicking.
 - Form a first impression: is it obvious what this app is, what to do first, and where to go next?
+- On each major page, ask what a cold user would think the page is trying to do or tell them. If the
+  page could plausibly be read as several different products or workflows (public browser vs admin
+  workbench vs data-quality dashboard vs review queue), file a clarity/usability ticket.
 
 ### 3. Use It Like a Human
 
@@ -52,17 +55,38 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
 - **Comprehension & labeling:** human-facing copy must sound like something a normal first-time user
   would understand. Flag machine-style or developer labels shown to users (raw IDs, enum keys,
   `snake_case`, `null`/`undefined`, untranslated i18n keys), admin/database terms such as
-  "metadata", implementation identifiers such as slugs, unexplained domain jargon, unclear
-  button/menu names, and icons with no discernible meaning. If a heading, label, or field would make a
-  non-technical user ask "what does that mean?", file a usability/clarity ticket with plainer wording.
+  "metadata", "rows", "bucket", "record", "entity", or "loaded rows", implementation identifiers such
+  as slugs, unexplained domain jargon, unclear button/menu names, and icons with no discernible
+  meaning. Flag all-caps enum/source labels, raw timestamps, and typo-like machine strings. If a
+  heading, label, or field would make a non-technical user ask "what does that mean?", file a
+  usability/clarity ticket with plainer wording.
 - **Data usefulness & context:** extracted facts, metrics, summaries, and structured tables must help
   a person understand the surface. Flag machine residue that only proves extraction happened, such as
   repeated generic fields (`Money Mention`, `Entity`, `Record`) paired with values but no sentence,
   source, category, or explanation of why the value matters. If a user cannot tell what a number,
   fact, or field refers to without rereading the raw source, file a usability/clarity ticket to hide it
   from the default UI or add context such as excerpts, labels, grouping, or provenance.
+- **Data volume and trust:** compare the amount of visible data to what the page promises. A rich
+  explorer, dashboard, or workbench with only a few rows/items can look broken, filtered, still
+  loading, sample-only, or untrusted. File a finding when sparse data is not explicitly explained with
+  result counts, active filters, reset affordances, ingestion/coverage status, or sample/demo labeling.
+- **Dates, numbers, and source metadata:** normal product UI should not expose storage formats unless
+  it is intentionally a technical log. Flag ISO timestamps, inconsistent relative/absolute date
+  styles, unexplained generated/imported/loaded dates, raw score/null states, and source metadata that
+  does not explain what was sourced, when, and why it matters.
+- **Controls and mental model:** controls must match what they do. Sort is not a filter; search is not
+  a facet; finite data domains usually need selects/typeaheads rather than blank text inputs. Flag
+  controls that make users guess exact spelling/casing, hide the available option universe, mix
+  filtering with sorting/view settings, or use the wrong component for the task.
+- **Information hierarchy and panel value:** scan cards, sidebars, workbenches, summaries, and metric
+  tiles for whether they communicate anything useful at a glance. File findings for blank-looking
+  panels, repeated cards with unclear labels, counts without named subjects, decorative summaries that
+  consume more attention than the primary workflow, or duplicated navigation that squeezes the actual
+  task area.
 - **Navigation clarity:** is it obvious how to get somewhere and back? Dead ends, hidden entry points,
-  surprising redirects, broken links, no clear "home".
+  surprising redirects, broken links, no clear "home". Flag duplicated nav regions that compete for
+  space without adding page-specific value, and icon systems that degrade into raw punctuation or mix
+  unrelated visual languages.
 - **Flow completeness & expected counterparts:** a screen that gates access or shows one side of a
   standard paired flow must offer the other side — or a clear path to it. A brand-new user must never
   hit a dead end with no next step. Flag missing companion actions, especially on auth and entry

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.155.4",
+  "version": "2.155.6",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.155.4",
+  "version": "2.155.6",
   "description": "TypeScript-specific hooks for formatting, linting, and ast-grep scanning on edit.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.155.4",
+  "version": "2.155.6",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.155.4",
+  "version": "2.155.6",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.155.4",
+  "version": "2.155.6",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, ast-grep scanning, and error-suppression blocking on edit",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.155.4",
+  "version": "2.155.6",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.155.4",
+  "version": "2.155.6",
   "description": "Distributable LLM Wiki kernel — ingest, query, lint, and maintain a git-native markdown knowledge base across Claude and Codex.",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.155.4",
+  "version": "2.155.6",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.155.4",
+  "version": "2.155.6",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

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

@@ -1,6 +1,6 @@
 {
   "name": "lisa-wiki",
-  "version": "2.155.4",
+  "version": "2.155.6",
   "description": "LLM Wiki — a distributable, git-native markdown knowledge base for Claude Code and Codex",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/skills/intake-explain/SKILL.md

@@ -163,12 +163,12 @@ Apply PRD verdicts in the same order as PRD intake and repair-intake:
 
 1. **Product-owned or verification-owned roles.** A PRD in `draft` returns `PRODUCT_OWNED_STATE`; the next action is manual product clarification or promotion to the configured `ready` role. A PRD in `shipped` returns `PRODUCT_OWNED_STATE` with `/lisa:verify-prd <item-ref>` as the next Lisa workflow because shipped-to-verified acceptance is outside PRD intake. A PRD in `verified` returns `PRODUCT_OWNED_STATE` or a terminal no-op explanation; normal intake and repair must not mutate it.
 2. **Ready PRD.** A PRD in the configured `ready` role returns `ELIGIBLE_FOR_INTAKE` when the source lane and lifecycle namespace resolve cleanly. The `Why:` line should say PRD intake would claim it into the configured `in_review` role and run the source-to-tracker dry-run validate-to-route pipeline.
-3. **In-review PRD.** A PRD in `in_review` is already Lisa-owned. Compare the newest activity signal against the resolved repair `stale_after` threshold (`$ARGUMENTS` override if present, `.lisa.config.json` `intake.repair.staleAfterHours`, then the 24h default). If provider activity, a progress comment, or a source edit is newer than `now - stale_after`, return `WAITING_ON_STALENESS` and name the activity timestamp. If no reliable timestamp exists, return `WAITING_ON_STALENESS` unless the caller explicitly uses the repair flow with `stale_after=0`; intake-explain should not imply automatic recovery from unknown freshness. If the item is stale and no repair-backoff marker suppresses retry, return `ELIGIBLE_FOR_REPAIR`.
+3. **In-review PRD.** A PRD in `in_review` is already Lisa-owned. Compare the newest activity signal against the resolved repair `stale_after` threshold (`$ARGUMENTS` override if present, `.lisa.config.json` `intake.repair.staleAfterHours`, then the 2h default). If provider activity, a progress comment, or a source edit is newer than `now - stale_after`, return `WAITING_ON_STALENESS` and name the activity timestamp. If no reliable timestamp exists, return `WAITING_ON_STALENESS` unless the caller explicitly uses the repair flow with `stale_after=0`; intake-explain should not imply automatic recovery from unknown freshness. If the item is stale and no repair-backoff marker suppresses retry, return `ELIGIBLE_FOR_REPAIR`.
 4. **Blocked PRD.** A PRD in `blocked` is Lisa-owned but repairable only when the next validate-to-route pass can materially differ. Treat new human answers after the blocking comment, body edits after the blocking marker, cleared blockers, changed blocker refs, or changed validator fingerprint as repair-enabling signals. If none are present, return `HELD_BY_BLOCKERS` or `WAITING_ON_STALENESS` depending on whether the decisive fact is an active blocker/unchanged clarification need or a still-fresh blocked marker. If the blocker/answer state changed and repair backoff is clear, return `ELIGIBLE_FOR_REPAIR`.
 5. **Ticketed PRD.** A PRD in `ticketed` is not ready for first intake. Read generated top-level work using the same `prd-lifecycle-rollup` boundary as PRD intake: top-level Epics and top-level Stories count; nested Stories and Sub-tasks do not. If any generated top-level child is non-terminal, return `PRODUCT_OWNED_STATE` or a waiting explanation that downstream build work is still in progress. If all generated top-level work is terminal but the PRD has not rolled up to `shipped`, return `ELIGIBLE_FOR_REPAIR` and recommend `/lisa:repair-intake <queue>` to reconcile rollup drift.
 6. **Repair backoff suppression.** Before returning `ELIGIBLE_FOR_REPAIR` for `in_review`, `blocked`, or `ticketed` PRDs, inspect `[lisa-repair-intake]` markers. If the latest marker's state fingerprint matches the current reader signals and its backoff window has not expired, return `WAITING_ON_STALENESS` with a `Why:` line that says repair-intake would suppress an unchanged retry to avoid a loop. If the fingerprint changed, the backoff expired, or a human uses repair-intake `force=true`, the item may be repair-eligible.
 
-Relevant `Signals:` should include the decisive context, not every field: for example `prd-blocked; new product comment after blocker`, `prd-in-review; last activity 2h ago; stale_after=24h`, `prd-ticketed; generated top-level work #12/#13 terminal`, or `[lisa-repair-intake] fingerprint unchanged; backoff until 2026-05-27T12:00:00Z`.
+Relevant `Signals:` should include the decisive context, not every field: for example `prd-blocked; new product comment after blocker`, `prd-in-review; last activity 2h ago; stale_after=2h`, `prd-ticketed; generated top-level work #12/#13 terminal`, or `[lisa-repair-intake] fingerprint unchanged; backoff until 2026-05-27T12:00:00Z`.
 
 ## Build item gate diagnosis
 

package/plugins/src/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, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) 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 (unclear purpose or audience, human-facing jargon, contextless extracted data, machine-style labels, raw dates/enums, sparse data with no explanation, wrong control semantics, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) 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
@@ -43,6 +43,9 @@ filed as a tracked work item so it enters the Lisa lifecycle — no static repor
 - Start at the home/landing page with **no prior knowledge of the app**. Do **not** pre-read the
   codebase to learn the intended flows — discover them the way a user would, by looking and clicking.
 - Form a first impression: is it obvious what this app is, what to do first, and where to go next?
+- On each major page, ask what a cold user would think the page is trying to do or tell them. If the
+  page could plausibly be read as several different products or workflows (public browser vs admin
+  workbench vs data-quality dashboard vs review queue), file a clarity/usability ticket.
 
 ### 3. Use It Like a Human
 
@@ -52,17 +55,38 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
 - **Comprehension & labeling:** human-facing copy must sound like something a normal first-time user
   would understand. Flag machine-style or developer labels shown to users (raw IDs, enum keys,
   `snake_case`, `null`/`undefined`, untranslated i18n keys), admin/database terms such as
-  "metadata", implementation identifiers such as slugs, unexplained domain jargon, unclear
-  button/menu names, and icons with no discernible meaning. If a heading, label, or field would make a
-  non-technical user ask "what does that mean?", file a usability/clarity ticket with plainer wording.
+  "metadata", "rows", "bucket", "record", "entity", or "loaded rows", implementation identifiers such
+  as slugs, unexplained domain jargon, unclear button/menu names, and icons with no discernible
+  meaning. Flag all-caps enum/source labels, raw timestamps, and typo-like machine strings. If a
+  heading, label, or field would make a non-technical user ask "what does that mean?", file a
+  usability/clarity ticket with plainer wording.
 - **Data usefulness & context:** extracted facts, metrics, summaries, and structured tables must help
   a person understand the surface. Flag machine residue that only proves extraction happened, such as
   repeated generic fields (`Money Mention`, `Entity`, `Record`) paired with values but no sentence,
   source, category, or explanation of why the value matters. If a user cannot tell what a number,
   fact, or field refers to without rereading the raw source, file a usability/clarity ticket to hide it
   from the default UI or add context such as excerpts, labels, grouping, or provenance.
+- **Data volume and trust:** compare the amount of visible data to what the page promises. A rich
+  explorer, dashboard, or workbench with only a few rows/items can look broken, filtered, still
+  loading, sample-only, or untrusted. File a finding when sparse data is not explicitly explained with
+  result counts, active filters, reset affordances, ingestion/coverage status, or sample/demo labeling.
+- **Dates, numbers, and source metadata:** normal product UI should not expose storage formats unless
+  it is intentionally a technical log. Flag ISO timestamps, inconsistent relative/absolute date
+  styles, unexplained generated/imported/loaded dates, raw score/null states, and source metadata that
+  does not explain what was sourced, when, and why it matters.
+- **Controls and mental model:** controls must match what they do. Sort is not a filter; search is not
+  a facet; finite data domains usually need selects/typeaheads rather than blank text inputs. Flag
+  controls that make users guess exact spelling/casing, hide the available option universe, mix
+  filtering with sorting/view settings, or use the wrong component for the task.
+- **Information hierarchy and panel value:** scan cards, sidebars, workbenches, summaries, and metric
+  tiles for whether they communicate anything useful at a glance. File findings for blank-looking
+  panels, repeated cards with unclear labels, counts without named subjects, decorative summaries that
+  consume more attention than the primary workflow, or duplicated navigation that squeezes the actual
+  task area.
 - **Navigation clarity:** is it obvious how to get somewhere and back? Dead ends, hidden entry points,
-  surprising redirects, broken links, no clear "home".
+  surprising redirects, broken links, no clear "home". Flag duplicated nav regions that compete for
+  space without adding page-specific value, and icon systems that degrade into raw punctuation or mix
+  unrelated visual languages.
 - **Flow completeness & expected counterparts:** a screen that gates access or shows one side of a
   standard paired flow must offer the other side — or a clear path to it. A brand-new user must never
   hit a dead end with no next step. Flag missing companion actions, especially on auth and entry

package/plugins/src/harper-fabric/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, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) 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 (unclear purpose or audience, human-facing jargon, contextless extracted data, machine-style labels, raw dates/enums, sparse data with no explanation, wrong control semantics, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) 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
@@ -43,6 +43,9 @@ filed as a tracked work item so it enters the Lisa lifecycle — no static repor
 - Start at the home/landing page with **no prior knowledge of the app**. Do **not** pre-read the
   codebase to learn the intended flows — discover them the way a user would, by looking and clicking.
 - Form a first impression: is it obvious what this app is, what to do first, and where to go next?
+- On each major page, ask what a cold user would think the page is trying to do or tell them. If the
+  page could plausibly be read as several different products or workflows (public browser vs admin
+  workbench vs data-quality dashboard vs review queue), file a clarity/usability ticket.
 
 ### 3. Use It Like a Human
 
@@ -52,17 +55,38 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
 - **Comprehension & labeling:** human-facing copy must sound like something a normal first-time user
   would understand. Flag machine-style or developer labels shown to users (raw IDs, enum keys,
   `snake_case`, `null`/`undefined`, untranslated i18n keys), admin/database terms such as
-  "metadata", implementation identifiers such as slugs, unexplained domain jargon, unclear
-  button/menu names, and icons with no discernible meaning. If a heading, label, or field would make a
-  non-technical user ask "what does that mean?", file a usability/clarity ticket with plainer wording.
+  "metadata", "rows", "bucket", "record", "entity", or "loaded rows", implementation identifiers such
+  as slugs, unexplained domain jargon, unclear button/menu names, and icons with no discernible
+  meaning. Flag all-caps enum/source labels, raw timestamps, and typo-like machine strings. If a
+  heading, label, or field would make a non-technical user ask "what does that mean?", file a
+  usability/clarity ticket with plainer wording.
 - **Data usefulness & context:** extracted facts, metrics, summaries, and structured tables must help
   a person understand the surface. Flag machine residue that only proves extraction happened, such as
   repeated generic fields (`Money Mention`, `Entity`, `Record`) paired with values but no sentence,
   source, category, or explanation of why the value matters. If a user cannot tell what a number,
   fact, or field refers to without rereading the raw source, file a usability/clarity ticket to hide it
   from the default UI or add context such as excerpts, labels, grouping, or provenance.
+- **Data volume and trust:** compare the amount of visible data to what the page promises. A rich
+  explorer, dashboard, or workbench with only a few rows/items can look broken, filtered, still
+  loading, sample-only, or untrusted. File a finding when sparse data is not explicitly explained with
+  result counts, active filters, reset affordances, ingestion/coverage status, or sample/demo labeling.
+- **Dates, numbers, and source metadata:** normal product UI should not expose storage formats unless
+  it is intentionally a technical log. Flag ISO timestamps, inconsistent relative/absolute date
+  styles, unexplained generated/imported/loaded dates, raw score/null states, and source metadata that
+  does not explain what was sourced, when, and why it matters.
+- **Controls and mental model:** controls must match what they do. Sort is not a filter; search is not
+  a facet; finite data domains usually need selects/typeaheads rather than blank text inputs. Flag
+  controls that make users guess exact spelling/casing, hide the available option universe, mix
+  filtering with sorting/view settings, or use the wrong component for the task.
+- **Information hierarchy and panel value:** scan cards, sidebars, workbenches, summaries, and metric
+  tiles for whether they communicate anything useful at a glance. File findings for blank-looking
+  panels, repeated cards with unclear labels, counts without named subjects, decorative summaries that
+  consume more attention than the primary workflow, or duplicated navigation that squeezes the actual
+  task area.
 - **Navigation clarity:** is it obvious how to get somewhere and back? Dead ends, hidden entry points,
-  surprising redirects, broken links, no clear "home".
+  surprising redirects, broken links, no clear "home". Flag duplicated nav regions that compete for
+  space without adding page-specific value, and icon systems that degrade into raw punctuation or mix
+  unrelated visual languages.
 - **Flow completeness & expected counterparts:** a screen that gates access or shows one side of a
   standard paired flow must offer the other side — or a clear path to it. A brand-new user must never
   hit a dead end with no next step. Flag missing companion actions, especially on auth and entry

package/plugins/src/rails/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, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) 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 (unclear purpose or audience, human-facing jargon, contextless extracted data, machine-style labels, raw dates/enums, sparse data with no explanation, wrong control semantics, slow or unclear loads, late meaningful content, cramped or cut-off UI, inconsistent/non-standard UX, awkward scroll behavior, unclear affordances, dead-end flows that strand a user — e.g. a login page with no way to register or recover a password, or a primary action that drops the user into an incomplete/unsatisfiable state with no way to finish) 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
@@ -43,6 +43,9 @@ filed as a tracked work item so it enters the Lisa lifecycle — no static repor
 - Start at the home/landing page with **no prior knowledge of the app**. Do **not** pre-read the
   codebase to learn the intended flows — discover them the way a user would, by looking and clicking.
 - Form a first impression: is it obvious what this app is, what to do first, and where to go next?
+- On each major page, ask what a cold user would think the page is trying to do or tell them. If the
+  page could plausibly be read as several different products or workflows (public browser vs admin
+  workbench vs data-quality dashboard vs review queue), file a clarity/usability ticket.
 
 ### 3. Use It Like a Human
 
@@ -52,17 +55,38 @@ mistakes, and tries the obvious thing. Cover at least these dimensions unless th
 - **Comprehension & labeling:** human-facing copy must sound like something a normal first-time user
   would understand. Flag machine-style or developer labels shown to users (raw IDs, enum keys,
   `snake_case`, `null`/`undefined`, untranslated i18n keys), admin/database terms such as
-  "metadata", implementation identifiers such as slugs, unexplained domain jargon, unclear
-  button/menu names, and icons with no discernible meaning. If a heading, label, or field would make a
-  non-technical user ask "what does that mean?", file a usability/clarity ticket with plainer wording.
+  "metadata", "rows", "bucket", "record", "entity", or "loaded rows", implementation identifiers such
+  as slugs, unexplained domain jargon, unclear button/menu names, and icons with no discernible
+  meaning. Flag all-caps enum/source labels, raw timestamps, and typo-like machine strings. If a
+  heading, label, or field would make a non-technical user ask "what does that mean?", file a
+  usability/clarity ticket with plainer wording.
 - **Data usefulness & context:** extracted facts, metrics, summaries, and structured tables must help
   a person understand the surface. Flag machine residue that only proves extraction happened, such as
   repeated generic fields (`Money Mention`, `Entity`, `Record`) paired with values but no sentence,
   source, category, or explanation of why the value matters. If a user cannot tell what a number,
   fact, or field refers to without rereading the raw source, file a usability/clarity ticket to hide it
   from the default UI or add context such as excerpts, labels, grouping, or provenance.
+- **Data volume and trust:** compare the amount of visible data to what the page promises. A rich
+  explorer, dashboard, or workbench with only a few rows/items can look broken, filtered, still
+  loading, sample-only, or untrusted. File a finding when sparse data is not explicitly explained with
+  result counts, active filters, reset affordances, ingestion/coverage status, or sample/demo labeling.
+- **Dates, numbers, and source metadata:** normal product UI should not expose storage formats unless
+  it is intentionally a technical log. Flag ISO timestamps, inconsistent relative/absolute date
+  styles, unexplained generated/imported/loaded dates, raw score/null states, and source metadata that
+  does not explain what was sourced, when, and why it matters.
+- **Controls and mental model:** controls must match what they do. Sort is not a filter; search is not
+  a facet; finite data domains usually need selects/typeaheads rather than blank text inputs. Flag
+  controls that make users guess exact spelling/casing, hide the available option universe, mix
+  filtering with sorting/view settings, or use the wrong component for the task.
+- **Information hierarchy and panel value:** scan cards, sidebars, workbenches, summaries, and metric
+  tiles for whether they communicate anything useful at a glance. File findings for blank-looking
+  panels, repeated cards with unclear labels, counts without named subjects, decorative summaries that
+  consume more attention than the primary workflow, or duplicated navigation that squeezes the actual
+  task area.
 - **Navigation clarity:** is it obvious how to get somewhere and back? Dead ends, hidden entry points,
-  surprising redirects, broken links, no clear "home".
+  surprising redirects, broken links, no clear "home". Flag duplicated nav regions that compete for
+  space without adding page-specific value, and icon systems that degrade into raw punctuation or mix
+  unrelated visual languages.
 - **Flow completeness & expected counterparts:** a screen that gates access or shows one side of a
   standard paired flow must offer the other side — or a clear path to it. A brand-new user must never
   hit a dead end with no next step. Flag missing companion actions, especially on auth and entry