@captain_z/zsk-skills 1.8.10 → 1.8.11

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@captain_z/zsk-skills",
-  "version": "1.8.10",
+  "version": "1.8.11",
   "description": "ZNorth Standard Kit — core harness-first skill content package",
   "license": "MIT",
   "files": [

package/zsk-coding/SKILL.md

@@ -63,11 +63,16 @@ Use this stage when tasks are approved for implementation. Coding owns small beh
    - refactor only while GREEN, then rerun the affected focused test.
 7. Add or update tests at the same risk level as the change; do not write all
    tests first and then all implementation.
-8. For issue-driven `fix` work, update the issue with changed files, root cause, evidence commands, documentation feedback target or no-update rationale, and next verification route.
-9. Run or cite fresh lint/typecheck/static diagnostics for the touched stack and confirm zero ESLint or TypeScript error/warning-level Problems before ready-for-smoke.
-10. Produce a validation packet for meaningful behavior changes. Map every acceptance criterion to evidence, classify each evidence item as unit, integration, smoke, manual, static, or review, record mock boundaries, and mark contract tiers as intrinsic engineering, contextual spec/design/task, or workflow governance.
-11. When an anchor packet is available, compare current implementation facts against intent, scope, acceptance criteria, design decisions, validation expectations, resource versions, and assumptions. Report local drift signals with class, severity, recommended workflow action, and confidence impact.
-12. Record commands, evidence, blockers, changed files, per-behavior TDD cycles, validation packet status, drift signals, and any dynamic best-practice sources for `smoke`/`review`.
+8. When changed behavior maps to a scenario catalog or task scenario strategy,
+   create or update the smallest source-aligned test, integration check, API
+   check, or draft scenario needed by that layer. Do not promote browser drafts
+   or claim UI regression coverage without demo observation and locator
+   refinement.
+9. For issue-driven `fix` work, update the issue with changed files, root cause, evidence commands, documentation feedback target or no-update rationale, and next verification route.
+10. Run or cite fresh lint/typecheck/static diagnostics for the touched stack and confirm zero ESLint or TypeScript error/warning-level Problems before ready-for-smoke.
+11. Produce a validation packet for meaningful behavior changes. Map every acceptance criterion to evidence, classify each evidence item as unit, integration, smoke, manual, static, or review, record mock boundaries, and mark contract tiers as intrinsic engineering, contextual spec/design/task, or workflow governance.
+12. When an anchor packet is available, compare current implementation facts against intent, scope, acceptance criteria, design decisions, validation expectations, resource versions, and assumptions. Report local drift signals with class, severity, recommended workflow action, and confidence impact.
+13. Record commands, evidence, blockers, changed files, per-behavior TDD cycles, validation packet status, drift signals, and any dynamic best-practice sources for `smoke`/`review`.
 
 ## Constraints
 
@@ -78,6 +83,8 @@ Use this stage when tasks are approved for implementation. Coding owns small beh
   not replace per-behavior RED/GREEN evidence with one final large test result
   set.
 - No treating green unit tests as completion by themselves. If critical wiring is mocked, include integration, smoke, manual, or review evidence, or explicitly report the validation gap.
+- No treating generated browser draft specs as regression evidence until demo
+  preflight supplies observation handoff and the draft is refined/promoted.
 - No hiding placeholder code, hacks, broad refactors, style/type diagnostics, error-handling gaps, scope violations, or contract violations behind passing tests.
 - No mutating workflow state from local drift findings. Report drift, blocker,
   and issue-update payloads; the workflow or human decides sequencing and

package/zsk-demo/SKILL.md

@@ -58,16 +58,22 @@ negativeExamples:
 
 # Demo
 
-Development demo before formal testing. Build a module-grouped, audience-ready demo outline, generate Playwright cases from formal raw testing inputs through `test-plan.json`, run rehearsed Playwright demonstration steps, record demo-only issues, preserve evidence, and leave reusable Playwright scenarios when possible.
+Development demo before formal testing. Build a module-grouped, audience-ready
+demo outline, generate a scenario catalog and test strategy from source inputs,
+run browser preflight to capture low-token UI observation handoffs, rehearse
+visible flows, record demo-only issues, preserve evidence, and promote reusable
+Playwright scenarios only after locator refinement.
 
 Default `/demo` execution follows the optimized SOP:
 
 ```text
-tests.raw_cases / sources.testing, normally .zsk/raws/testing
+tests.raw_cases / sources.testing / spec / issue / manual notes / existing tests
+  -> scenario-catalog.json with sourceRefs, steps, expected results, and gaps
+  -> test-plan.json with automationStrategy by verification layer
   -> UI observation handoff for current-page state and locator hints
-  -> zsk/agent-written test-plan.json in tests.derived_cases
-  -> Playwright generator/CLI/Skills-written .spec.ts in tests.automated.e2e
-  -> Playwright Test/UI/debug execution and evidence under `.zsk/modules/{module}/_playwright` and `.zsk/modules/{module}/_evidence`
+  -> Playwright draft specs under `_playwright/drafts/*.pw-draft.ts`
+  -> refined promoted specs under `_playwright/specs/*.spec.ts`
+  -> Playwright Test/UI/debug execution and demo evidence
 ```
 
 Use Playwright `storageState`, persistent context, CDP, or fixture login to reuse credentials before relying on live UI tools. For authenticated products, demo must solve login first: perform first-time login once, save module-local storageState under `.zsk/modules/{module}/_playwright/.auth/`, and make all generated specs fail fast with a clear auth bootstrap instruction instead of letting every business scenario fail on the login page. The project may declare `automation.demo.auth.envFiles` such as `~/.zshrc` and `automation.demo.auth.env` key names such as `username: DEMO_USERNAME`; never write credential values into `.zsk/config.yaml` or generated artifacts. Computer Use is the preferred current-page or visual observation lane when it is available and authorized. If Computer Use is unavailable, such as in runtimes that do not expose it, fall back to Playwright MCP/ARIA/CDP snapshots, deterministic Playwright inspection, documented manual evidence, or Browser Use only where the runtime explicitly supports it and permissions are available. Any UI observation tool is observation-only in this path: it may describe URL, page title, visible targets, role/label hints, auth/session notes, and privacy concerns, but it must not write repo artifacts, `test-plan.json`, or final `.spec.ts` files. Optimized `/demo` must not silently fall back to Playwright MCP or the legacy hybrid bridge.
@@ -101,7 +107,11 @@ Every demo step must have complete source alignment:
 
 Do not include orphan demo steps that cannot be traced to those sources. Do not omit required function points from the PRD/SRS unless the omission is called out as a known gap with owner and reason.
 
-If a formal test case and UI observation handoff are available, demo should generate or refresh a Playwright case before running it. Prefer `raw test case + Computer Use or Playwright observation + test-plan.json + Playwright locator generation` over screenshot-only generation. Use the legacy hybrid lane explicitly when MCP or non-default UI observation is required.
+If a formal test case and UI observation handoff are available, demo should
+generate or refresh a draft Playwright case before running it. Prefer
+`scenario catalog + UI observation handoff + test-plan.json + Playwright draft`
+over screenshot-only generation. Use the legacy hybrid lane explicitly when MCP
+or non-default UI observation is required.
 
 ## Operating Constraints
 
@@ -130,7 +140,7 @@ demo run computer-use   -> zsk demo run --computer-use
 demo run hybrid         -> zsk demo run --hybrid
 demo auth               -> zsk demo auth -m <module> --url <login-or-app-url>
 demo capture            -> zsk demo capture
-demo scenario generate  -> zsk demo scenario generate --test-case <path> --snapshot <path>
+demo scenario generate  -> zsk demo scenario generate --case-id <id> --observation <path>
 demo complete           -> zsk demo complete
 ```
 
@@ -150,7 +160,13 @@ Computer Use, Browser Use, or manual evidence outside optimized mode must record
 The optimized lane exchanges structured artifacts:
 
 - `test-plan.json`: source-aligned test intent, preconditions, UI observation summary, locator hints, steps, assertions, auth handoff, risks, and generated spec target.
-- `.spec.ts`: final executable Playwright test generated from `test-plan.json`, following Playwright locator and assertion best practices.
+- `scenario-catalog.json`: normalized scenarios from QA tables, markdown,
+  spec, issue notes, manual notes, and existing tests.
+- `uiObservationHandoff`: tool-neutral observation payload from Agent Browser,
+  Browser Use, Computer Use, Playwright ARIA/CDP, or manual evidence.
+- `.pw-draft.ts`: draft Playwright test with source alignment and locator hints.
+- `.spec.ts`: promoted executable Playwright test after observation evidence and
+  locator refinement.
 
 The legacy hybrid lane exchanges structured artifacts:
 
@@ -165,9 +181,13 @@ Demo has two sub-phases:
    - Create a flow-first demo outline from PRD/SRS, spec/design, task, and test evidence before writing or running cases.
    - Order function points by user/business journey, not by file order or resource order.
    - Add a coverage alignment table that proves each demo step maps to the original requirement, design/spec contract, task scope, and expected test result.
-   - Computer Use captures current page, human goal, visible controls, and candidate locators when Playwright cannot infer intent by itself; if unavailable, use Playwright MCP/ARIA/CDP, documented manual evidence, or compatible Browser Use.
+   - Agent Browser, Browser Use, Computer Use, Playwright ARIA/CDP, or manual
+     evidence captures current page, human goal, visible controls, and candidate
+     locators when deterministic scripts cannot infer intent by themselves.
    - The agent combines UI observation state with SRS/spec/design rows, formal QA cases, automation/e2e cases, and unit-test assertions/fixtures that define expected behavior.
-   - Playwright pre-write cases are drafted under `.zsk/modules/{module}/_playwright/specs/` with explicit auth bootstrap, module-local storageState reuse, and candidate locator fallbacks.
+   - Playwright pre-write cases are drafted under `.zsk/modules/{module}/_playwright/drafts/` with explicit auth bootstrap, module-local storageState reuse, and candidate locator fallbacks.
+   - Promotion to `.zsk/modules/{module}/_playwright/specs/` requires a
+     `uiObservationHandoff`, refined locators, and `zsk check` compatibility.
    - Playwright dry-runs or UI-runs the cases, recording trace/report/screenshots and pausing on selector/auth drift.
 2. Demo Show:
    - Use only the pre-written, already dry-run Playwright cases for external demonstration.
@@ -179,8 +199,11 @@ The handoff loop is:
 1. Identify: Computer Use identifies the human goal, current page state, likely control to click/type, and candidate locators when Playwright cannot know which visible element matches the user's intent. If unavailable, use Playwright MCP/ARIA/CDP, manual evidence, or compatible Browser Use.
 2. Persist state: zsk or the agent generator persists UI observations into `test-plan.json` or a separate handoff note before spec generation, including URL, candidate locator text, storage/session hint, profile source, visible login state, and privacy note. The observation tool itself is not the repo writer.
 3. Pre-write: zsk or the agent generator converts source evidence plus UI observations into `test-plan.json` and then Playwright specs, preferring role-based locators and including any auth handoff that Playwright can reproduce.
-4. Rehearse: Playwright runs the pre-written cases with `storageState`, persistent context, CDP, or fixture login when available, then records trace/UI/report evidence.
-5. Perform: Demo Show uses the rehearsed Playwright cases; successful runs are promoted to reusable verify/regression scenarios.
+4. Rehearse: Playwright runs the draft or promoted cases with `storageState`,
+   persistent context, CDP, or fixture login when available, then records
+   trace/UI/report evidence.
+5. Perform: Demo Show uses rehearsed cases; only refined drafts with observation
+   evidence are promoted to reusable verify/regression scenarios.
 
 Repeat the loop until the demo function point is passed, paused, or converted into a Demo Issue.
 
@@ -190,10 +213,18 @@ The agent should synthesize Playwright cases before the external demo from raw t
 
 1. Load SRS/spec/design rows, formal QA cases, existing automation/e2e cases, and relevant unit-test assertions/fixtures.
 2. Read Computer Use observation when current-page visual state or human-intent locator mapping is needed and available; otherwise use Playwright MCP/ARIA/CDP, documented manual evidence, or compatible Browser Use. Map auth to Playwright `storageState`, persistent context, CDP, or documented manual setup.
-3. Generate `test-plan.json` under `tests.derived_cases` with source links, step intent, locator hints, assertions, auth handoff, risks, and generated spec target.
-4. Generate a Playwright spec under `tests.automated.e2e` using role-first locators, explicit auth bootstrap, persisted storageState reuse, and assertions derived from source evidence.
-5. Rehearse it with Playwright UI/trace/report evidence and preserve trace/screenshots/video under `.zsk/modules/{module}/_playwright` or `.zsk/modules/{module}/_evidence`.
-6. Use the rehearsed case for Demo Show; do not improvise new clicks during the external demo unless the prepared case is blocked and the blocker is recorded.
+3. Generate `scenario-catalog.json` and `test-plan.json` under
+   `_playwright/test-plans/` with source links, automation strategy, step intent,
+   locator hints, assertions, auth handoff, risks, and draft/promoted targets.
+4. Generate a draft Playwright spec under `_playwright/drafts/` using role-first
+   locators, explicit auth bootstrap, persisted storageState reuse, and
+   assertions derived from source evidence.
+5. Rehearse it with Playwright UI/trace/report evidence and preserve
+   trace/screenshots/video under `.zsk/modules/{module}/_playwright` or
+   `.zsk/modules/{module}/_evidence`.
+6. Promote only after observation evidence and locator refinement; use the
+   rehearsed case for Demo Show and do not improvise new clicks during the
+   external demo unless the prepared case is blocked and recorded.
 
 Playwright MCP and Browser Use are compatibility lanes, not assumptions. Computer Use is preferred for visual/current-page observation when available; all observation lanes remain observation-only in optimized mode.
 
@@ -204,6 +235,11 @@ zsk demo scenario generate \
   -m checkout \
   --test-case .zsk/raws/testing/checkout-happy-path.md \
   --name "Checkout happy path"
+
+zsk demo scenario generate \
+  -m checkout \
+  --case-id checkout-001 \
+  --observation .zsk/modules/checkout/_playwright/observations/checkout.agent-browser.json
 ```
 
 ## Session Lifecycle
@@ -270,15 +306,20 @@ Direct mode starts from the user's explicit target. Workflow-only artifacts, app
 - tasks
 - deployment
 - test-cases
+- scenario-catalog
 - ui-observation-handoff
-- playwright-cases
+- draft-playwright-specs
 
 **Required outputs**
 
 - demo-outline
 - demo-report
 - demo-issues
-- demo-scenarios
+- scenario-catalog
+- test-plan
+- ui-observation-handoff
+- draft-playwright-specs
+- promoted-playwright-specs
 - playwright-execution
 
 ### Quality Rubric

package/zsk-demo/harness/THIS_SKILL.md

@@ -24,15 +24,20 @@ This full contract is generated for workflow or strict-profile runs. Direct sing
 - `tasks`
 - `deployment`
 - `test-cases`
+- `scenario-catalog`
 - `ui-observation-handoff`
-- `playwright-cases`
+- `draft-playwright-specs`
 
 ## Required Outputs
 
 - `demo-outline`
 - `demo-report`
 - `demo-issues`
-- `demo-scenarios`
+- `scenario-catalog`
+- `test-plan`
+- `ui-observation-handoff`
+- `draft-playwright-specs`
+- `promoted-playwright-specs`
 - `playwright-execution`
 
 ## Required Output Enforcement
@@ -43,8 +48,8 @@ This full contract is generated for workflow or strict-profile runs. Direct sing
 
 ## Allowed Tools And Capabilities
 
-- Tools: `playwright-cli`, `playwright-test`, `computer-use`, `playwright-mcp`, `browser-use`, `issue-create`
-- Capabilities: `flow-first-demo`, `scenario-generation`, `visible-rehearsal`
+- Tools: `playwright-cli`, `playwright-test`, `computer-use`, `playwright-mcp`, `browser-use`, `agent-browser`, `issue-create`
+- Capabilities: `flow-first-demo`, `scenario-catalog-extraction`, `browser-preflight`, `scenario-generation`, `visible-rehearsal`, `scenario-promotion`
 - Script policy: `recommended`
 - Browser Use policy: `conditional`
 
@@ -103,8 +108,8 @@ This full contract is generated for workflow or strict-profile runs. Direct sing
 
 - `output_goal`: Rehearse user-visible flows from source-backed scenarios and capture demo evidence.
 - `downstream_consumer`: Next legal ZSK stage or reviewer.
-- `required_inputs`: spec, design, tasks, deployment, test-cases, ui-observation-handoff, playwright-cases
-- `required_outputs`: demo-outline, demo-report, demo-issues, demo-scenarios, playwright-execution
+- `required_inputs`: spec, design, tasks, deployment, test-cases, scenario-catalog, ui-observation-handoff, draft-playwright-specs
+- `required_outputs`: demo-outline, demo-report, demo-issues, scenario-catalog, test-plan, ui-observation-handoff, draft-playwright-specs, promoted-playwright-specs, playwright-execution
 - `must_answer_questions`: Which scenario, account/state, route, and expected observable result were exercised? / What was visible to the user, and what evidence was captured? / Which demo gaps become defects or task/spec/design feedback?
 - `quality_checks`: Consumes spec scenarios and task case skeletons instead of inventing flows during demo. / Records storageState path, first-login/bootstrap path, and explicit public-flow waiver when auth is not required. / Records screenshots/traces/logs where they materially prove visible behavior.
 - `anti_patterns`: Manual click-through notes with no scenario linkage. / Treating login/setup failure as an app defect without classification.

package/zsk-demo/harness/workflow/skill-io-contract.yaml

@@ -201,13 +201,18 @@ skills:
       - tasks
       - deployment
       - test-cases
+      - scenario-catalog
       - ui-observation-handoff
-      - playwright-cases
+      - draft-playwright-specs
     outputs:
       - demo-outline
       - demo-report
       - demo-issues
-      - demo-scenarios
+      - scenario-catalog
+      - test-plan
+      - ui-observation-handoff
+      - draft-playwright-specs
+      - promoted-playwright-specs
       - playwright-execution
     tools:
       - playwright-cli
@@ -215,10 +220,14 @@ skills:
       - computer-use
       - playwright-mcp
       - browser-use
+      - agent-browser
       - issue-create
     capabilities:
       - flow-first-demo
+      - scenario-catalog-extraction
+      - browser-preflight
       - scenario-generation
       - visible-rehearsal
+      - scenario-promotion
     script: recommended
     browserUse: conditional

package/zsk-smoke/SKILL.md

@@ -49,6 +49,9 @@ implementation, review, release, or acceptance work.
 
 Smoke is the developer-owned proof that changed behavior works well enough to be
 inspected further when a workflow or human chooses to do so.
+Smoke runs targeted checks for changed behavior. It does not require a full E2E
+suite unless the changed behavior itself can only be credibly smoke-proved
+through a focused browser/API/integration path.
 
 ## Inputs
 
@@ -61,11 +64,15 @@ inspected further when a workflow or human chooses to do so.
 ## Procedure
 
 1. Confirm each targeted test or scenario maps to the intended requirement, function point, and expected behavior.
-2. Run targeted tests for changed behavior first.
-3. Run lint/typecheck/build/smoke checks when relevant to the touched surface.
-4. Capture exact commands, environment, results, source alignment, and evidence links.
-5. Convert failures into coding fixes or smoke issues with repro command, actual/expected behavior, severity, root-cause hypothesis, and regression guard.
-6. For `fix` routes, record whether the smoke command exercises the original issue reproduction, the regression guard, or both.
+2. Use the scenario catalog or task strategy when present to select the narrowest
+   credible layer: unit, integration, api-e2e, browser-e2e, visual-observation,
+   or manual-blocker.
+3. Run targeted tests for changed behavior first.
+4. Run lint/typecheck/build/smoke checks when relevant to the touched surface.
+5. Capture exact commands, environment, results, source alignment, and evidence links.
+6. Classify passed, failed, skipped, flaky, unrun, and N/A checks explicitly.
+7. Convert failures into coding fixes or smoke issues with repro command, actual/expected behavior, severity, root-cause hypothesis, and regression guard.
+8. For `fix` routes, record whether the smoke command exercises the original issue reproduction, the regression guard, or both.
 
 ## Constraints
 

package/zsk-spec/SKILL.md

@@ -101,18 +101,23 @@ Conditional hard requirements: when the behavior touches auth, permissions, role
 
 Advisory guidance: keep IDs stable, keep implementation choices out unless they are product contract, and write `未指定` for unsupplied thresholds.
 
-## Playwright Scenario Contract
+## Observable Scenario Contract
 
-For UI-visible behavior, spec should define scenario contracts before implementation:
+For important behavior, spec should define observable scenario contracts before
+implementation. These contracts are the source for a later scenario catalog;
+they are not executable selector plans.
 
 - user-visible goal
 - route/page entry
 - role/account/data preconditions
 - observable success/failure states
 - AC/FR linkage
-- whether the scenario must become a Playwright case
+- preferred verification layer when known: browser-e2e, api-e2e, integration,
+  unit, visual-observation, or manual-blocker
+- whether the scenario is a smoke/demo/verify/regression candidate
 
-Do not write brittle selectors in spec. Save locator strategy for design.
+Do not write brittle selectors in spec. Save locator strategy, runtime evidence,
+and browser observation details for design/task/demo.
 
 ## Outputs
 

package/zsk-task/SKILL.md

@@ -144,15 +144,20 @@ hierarchy syncs as `parent-child` links. Multica, Jira, GitHub Issues, GitLab,
 Linear, or future providers remain adapter outputs of `zsk work sync --dry-run`.
 Task does not assign or start agents.
 
-## Playwright Task Output
+## Scenario Strategy Output
 
-Task planning should create or update Playwright case skeletons before demo:
+Task planning should map important scenarios to verification layers and evidence
+hooks before demo:
 
-- map each P0/P1 scenario contract to a case file
+- map each P0/P1 scenario contract to browser-e2e, api-e2e, integration, unit,
+  visual-observation, or manual-blocker
 - define fixture/auth/bootstrap needs
-- mark which cases are smoke/demo, verify, or regression
+- mark which scenarios are smoke/demo, verify, or regression candidates
+- point demo candidates at `.zsk/modules/{module}/_playwright/drafts/` for
+  draft Playwright generation, not promoted specs
 - include implementation tasks for missing labels/test ids needed by stable locators
-- ensure demo consumes existing case skeletons instead of inventing flows during the meeting
+- ensure demo consumes scenario contracts, test-plan strategy, and observation
+  handoffs instead of inventing flows during the meeting
 
 ## Scenario Synthesis
 
@@ -163,7 +168,9 @@ When structured page information is available from Playwright MCP, Accessibility
 - design locator/state strategy
 - structured page information
 
-The result should be a reviewable Playwright spec skeleton, not an unreviewed final test. Demo executes and calibrates it later.
+The result should be a reviewable draft Playwright spec or scenario plan, not an
+unreviewed promoted test. Demo executes, observes, rehearses, and calibrates it
+later; promotion requires refined locators and observation evidence.
 
 ## Outputs
 
@@ -175,7 +182,7 @@ The result should be a reviewable Playwright spec skeleton, not an unreviewed fi
   qa-case-pack claims, mapped tasks, evidence route, and blocker/N/A rationale.
 - Control-row task coverage matrix when triggered.
 - FR/AC coverage matrix.
-- Playwright case skeletons or documented non-UI reason.
+- Scenario strategy matrix and draft Playwright targets or documented non-UI reason.
 - Work-event preview for every provider-syncable task group and subtask,
   including expected `work.item.upserted` and `work.item.linked` records, or a
   `work-task-emit` evidence plan explaining blocked or unchanged task items.

package/zsk-verify/SKILL.md

@@ -45,6 +45,8 @@ workflow route.
 - Ready-for-verify handoff.
 - Linked issues, reproduction steps, expected outcomes, and evidence.
 - Deployment/version information and reusable scenarios.
+- Scenario catalog, promoted Playwright specs, API/integration evidence, demo
+  evidence, defect packs, and ready handoff when present.
 - `qa-case-pack`, `defect-pack`, and issue-source records when reviewed
   readiness packs exist.
 - For issue-driven `fix` routes: issue path/id, root-cause note, changed files, regression guard, and smoke/review evidence.
@@ -52,25 +54,31 @@ workflow route.
 ## Procedure
 
 1. Restate the claim being verified and the smallest proof needed.
-2. Re-run reproduction or acceptance checks independently.
-3. When `qa-case-pack` or `defect-pack` exists, compare actual behavior to its
+2. Load applicable replay sources: scenario catalog, promoted browser specs,
+   API/integration evidence, qa-case-pack, defect-pack, demo report, and ready
+   handoff. Record which were consumed or why none applied.
+3. Re-run reproduction or acceptance checks independently.
+4. When `qa-case-pack` or `defect-pack` exists, compare actual behavior to its
    reviewed expected/actual/test-basis facts and sourceRefs before considering
    provider status, tracker labels, or implementation claims.
-4. Compare actual behavior to spec/issue expectations.
-5. Record pass/fail evidence with commands, screenshots, traces, or manual notes.
-6. Classify failures by likely owner and recommended action based on root cause.
-7. When verification fails, return an issue-update payload with repro,
+5. Compare actual behavior to spec/issue expectations.
+6. Record pass/fail evidence with commands, screenshots, traces, or manual notes.
+7. Classify failures by likely owner and recommended action based on root cause.
+8. When verification fails, return an issue-update payload with repro,
    actual/expected, severity, root cause, and documentation feedback target.
-8. When verification passes, return a verified issue-update payload with
+9. When verification passes, return a verified issue-update payload with
    evidence, while leaving spec/design feedback pending until the user/product
    owner confirms the fix is acceptable.
-9. For `fix` routes, confirm that the issue record contains a documentation feedback target or no-update rationale before recommending closure.
+10. For `fix` routes, confirm that the issue record contains a documentation feedback target or no-update rationale before recommending closure.
 
 ## Constraints
 
 - Do not accept developer evidence without independent checking when independence is required.
 - Do not verify against an unversioned or unknown environment.
 - Do not broaden the scope beyond linked claims.
+- Do not invent new test scope, new scenarios, or locator strategy during
+  verify. If coverage is missing, record a blocker/gap and route it back to
+  task/demo/coding.
 - Do not mark pass with missing evidence.
 - Do not verify from provider status alone when reviewed qa-case-pack or
   defect-pack facts are available.
@@ -83,6 +91,8 @@ workflow route.
 - Pass/fail decision per issue/AC.
 - QA/defect pack consumption result when applicable: sourceRefs checked,
   expected/actual basis, assumptions, blockers, and replay evidence.
+- Scenario catalog / promoted spec / demo evidence consumption result when
+  applicable, or a recorded reason none applied.
 - Acceptance readiness or failure classification.
 - Issue-update payload and documentation feedback target.
 
@@ -153,6 +163,9 @@ Direct mode starts from the user's explicit target. Workflow-only artifacts, app
 - ready-handoff
 - fixed-issues
 - test-cases
+- scenario-catalog
+- promoted-playwright-specs
+- api-integration-evidence
 - qa-case-pack
 - defect-pack
 - issue-source
@@ -162,6 +175,7 @@ Direct mode starts from the user's explicit target. Workflow-only artifacts, app
 
 - verify-report
 - pass-fail-decision
+- consumed-scenario-evidence
 - control-verification-result-when-triggered
 - updated-issues
 

package/zsk-verify/harness/THIS_SKILL.md

@@ -22,6 +22,9 @@ This full contract is generated for workflow or strict-profile runs. Direct sing
 - `ready-handoff`
 - `fixed-issues`
 - `test-cases`
+- `scenario-catalog`
+- `promoted-playwright-specs`
+- `api-integration-evidence`
 - `qa-case-pack`
 - `defect-pack`
 - `issue-source`
@@ -31,6 +34,7 @@ This full contract is generated for workflow or strict-profile runs. Direct sing
 
 - `verify-report`
 - `pass-fail-decision`
+- `consumed-scenario-evidence`
 - `control-verification-result-when-triggered`
 - `updated-issues`
 
@@ -102,8 +106,8 @@ This full contract is generated for workflow or strict-profile runs. Direct sing
 
 - `output_goal`: Independently confirm or reject the ready claim with replayable evidence.
 - `downstream_consumer`: Next legal ZSK stage or reviewer.
-- `required_inputs`: ready-handoff, fixed-issues, test-cases, qa-case-pack, defect-pack, issue-source, runtime-version
-- `required_outputs`: verify-report, pass-fail-decision, control-verification-result-when-triggered, updated-issues
+- `required_inputs`: ready-handoff, fixed-issues, test-cases, scenario-catalog, promoted-playwright-specs, api-integration-evidence, qa-case-pack, defect-pack, issue-source, runtime-version
+- `required_outputs`: verify-report, pass-fail-decision, consumed-scenario-evidence, control-verification-result-when-triggered, updated-issues
 - `must_answer_questions`: What exact claim was tested independently, and did it pass? / What commands/scenarios/artifacts prove the result? / Which issues are closed, reopened, or newly found?
 - `quality_checks`: Names consumed qa-case-pack/defect-pack facts or records why no reviewed pack applies. / Uses fresh evidence and reads command/scenario output before deciding. / Separates pass/fail decision from recommendations or follow-up improvements.
 - `anti_patterns`: Verifying by trusting the implementer's smoke report. / Closing issues without linking replay evidence.

package/zsk-verify/harness/workflow/skill-io-contract.yaml

@@ -199,6 +199,9 @@ skills:
       - ready-handoff
       - fixed-issues
       - test-cases
+      - scenario-catalog
+      - promoted-playwright-specs
+      - api-integration-evidence
       - qa-case-pack
       - defect-pack
       - issue-source
@@ -206,6 +209,7 @@ skills:
     outputs:
       - verify-report
       - pass-fail-decision
+      - consumed-scenario-evidence
       - control-verification-result-when-triggered
       - updated-issues
     tools: