@codyswann/lisa 2.213.0 → 2.215.0

package/plugins/lisa-cursor/skills/lisa-drive-pr-to-merge/SKILL.md

@@ -36,6 +36,43 @@ merges" loop. Other skills delegate here instead of re-implementing it. Runs
 Resolve `<owner>/<repo>` from `gh repo view --json nameWithOwner` (or the PR URL).
 Use plain `gh` + `git` so Claude and Codex execute identically.
 
+## 0. Take the babysitter lease
+
+This skill is the branch's owner while it runs. Declare that ownership so the
+CI auto-fix workflow (`reusable-claude-ci-auto-fix.yml`) stands down instead of
+pushing competing fixes to the same branch (the single-writer rule):
+
+```bash
+gh label create "lisa:babysitter-on-duty" \
+  --description "A drive-pr-to-merge session is actively driving this PR; CI auto-fix must stand down" \
+  --color FBCA04 || true  # tolerate only already-exists; check the next step
+gh pr edit <pr> --add-label "lisa:babysitter-on-duty"
+gh pr view <pr> --json labels \
+  --jq '[.labels[].name] | contains(["lisa:babysitter-on-duty"])'
+```
+
+Verify the final command prints `true` before driving. If the label could not
+be attached (for example, no label-write permission), retry once; if it still
+fails, surface a warning that the branch is unleased — the CI auto-fix
+workflow may engage in parallel — and watch for its `claude-auto-fix-*` PR
+per section 2f while driving.
+
+The auto-fix workflow reads freshness from the label's most recent `labeled`
+timeline event and treats stamps older than its TTL (default 90 minutes) as
+stale. **Refresh the lease** whenever more than ~30 minutes have passed since
+the last stamp while the watch loop is still running — a refresh is a
+remove + re-add (re-adding an existing label does not create a new timeline
+event):
+
+```bash
+gh pr edit <pr> --remove-label "lisa:babysitter-on-duty"
+gh pr edit <pr> --add-label "lisa:babysitter-on-duty"
+```
+
+**Release the lease** (remove the label) at every terminal state — merged,
+closed, or a hard block handed to a human. A crashed session that never
+releases is why the TTL exists; do not rely on it as the normal release path.
+
 ## 1. Enable auto-merge
 
 Before enabling auto-merge, capture the live PR head and compare it to
@@ -74,7 +111,8 @@ gh pr view <pr> --json state,mergeStateStatus,mergeable,reviewDecision,statusChe
 ```
 
 Handle every blocker class; after any fix, re-poll and continue. Do not stop while
-the PR is still open and progress is possible.
+the PR is still open and progress is possible. On each iteration, refresh the
+babysitter lease if its last stamp is older than ~30 minutes (section 0).
 
 In **`on_blocker=report`** mode, only the mechanical step (a) and auto-merge enabling
 apply; for any of (b)–(e) do not act — classify the blocker and return per the input
@@ -150,6 +188,16 @@ Some org rulesets allow 0 approvals yet a bot `CHANGES_REQUESTED` still blocks
 auto-merge — dismissing the stale review after resolving all threads is what
 unblocks it.
 
+### f. Pending auto-fix PR into this branch
+If an open PR from `claude-auto-fix-<headRefName>` targets this PR's head
+branch (the CI auto-fix workflow engaged before this session took the lease),
+adjudicate it: merge it into the head branch if the fix is correct and still
+needed, otherwise close it and delete the side branch. Never leave it dangling
+— it represents a competing writer's pending work. Merging it mutates the
+driven branch, so treat it like any other push: disarm auto-merge first,
+re-read `headRefOid`, reset `verify_commit` to the merged head, wait for that
+head's checks to start, then re-enable auto-merge (section 1).
+
 ## 3. Merge and verify it actually shipped (ancestry check)
 
 Enabling auto-merge + green checks + resolved threads is **not** proof the merge
@@ -177,3 +225,8 @@ Loop until one of:
   needs design input, or genuine unresolved human objection (not a bot gate). Stop
   and report exactly what is blocking and what was already tried — never force the
   merge or weaken a gate to get past it.
+
+At every terminal state, release the babysitter lease
+(`gh pr edit <pr> --remove-label "lisa:babysitter-on-duty"`) so the CI
+auto-fix workflow can take over as fixer of last resort if the branch goes
+red later with nobody driving it.

package/plugins/lisa-cursor/skills/lisa-github-add-journey/SKILL.md

@@ -58,7 +58,7 @@ Use Explore agents or read the codebase directly to understand which files are a
 
 ### Step 5: Draft the Validation Journey
 
-Compose the journey with `[EVIDENCE: name]` markers at key verification points:
+Compose the journey with typed `[EVIDENCE: <artifact-type>: <name>]` markers at key verification points. The type says HOW the proof is captured (`screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump` — the fixed taxonomy in the `verification` rule); the name says WHAT it proves:
 
 ```markdown
 ## Validation Journey
@@ -69,9 +69,9 @@ Compose the journey with `[EVIDENCE: name]` markers at key verification points:
 ### Steps
 1. Verify current state before changes
 2. Apply the change
-3. Verify expected new state [EVIDENCE: state-name]
-4. Test error/edge cases [EVIDENCE: error-case]
-5. Verify rollback if applicable [EVIDENCE: rollback]
+3. Verify expected new state [EVIDENCE: http-transcript: health-endpoint-200]
+4. Test error/edge cases [EVIDENCE: screenshot: invalid-input-error-state]
+5. Verify rollback if applicable [EVIDENCE: db-query-output: rows-restored-after-rollback]
 
 ### Assertions
 - Describe what must be true after verification
@@ -82,10 +82,10 @@ Compose the journey with `[EVIDENCE: name]` markers at key verification points:
 1. **2–5 evidence markers** — Focus on proving the change works and handles errors.
 2. **Concrete, runnable steps** — `Run \`curl -s localhost:3000/health | jq .status\`` not "Check the endpoint".
 3. **Include environment setup** — Database connection, running services, env vars.
-4. **Evidence names in kebab-case** — `api-response`, `schema-check`, `rate-limit-hit`.
+4. **Markers are typed artifacts, not assertion labels** — `[EVIDENCE: <artifact-type>: <kebab-name>]`. `[EVIDENCE: load-failure-handled-gracefully]` names a claim with nothing to capture; write `[EVIDENCE: screenshot: load-failure-error-state]` or `[EVIDENCE: perf-trace: pipeline-load-tti]`. Names are kebab-case and unique within the ticket.
 5. **Assertions are measurable** — `Returns 200 with {status: ok}` not "API works correctly".
 6. **Cover happy path AND error path** — At minimum, one success and one failure marker.
-7. **On a leaf work unit, the markers are binding** — For a Bug / Task / Sub-task / Improvement, every `[EVIDENCE: name]` here is the issue's evidence manifest: validation gate S14 requires at least one, and the issue cannot be closed until each named artifact is captured and attached (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Name only evidence you intend to capture — and name all of it.
+7. **On a leaf work unit, the markers are binding** — For a Bug / Task / Sub-task / Improvement, every typed `[EVIDENCE: <artifact-type>: <name>]` here is the issue's evidence manifest: validation gate S14 requires at least one, and the issue cannot be closed until each named artifact is captured **in its declared type** and attached (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Name only evidence you intend to capture — and name all of it.
 
 ### Step 6: Present to User for Approval
 

package/plugins/lisa-cursor/skills/lisa-github-journey/SKILL.md

@@ -51,14 +51,25 @@ Execute each step sequentially. Determine the verification approach based on the
 - **Library/utility changes** → Run tests, capture output.
 - **Security fixes** → Reproduce exploit attempt, verify fix, capture output.
 
-At each `[EVIDENCE: name]` marker, capture stdout/stderr to a numbered file:
+At each typed `[EVIDENCE: <artifact-type>: <name>]` marker, capture an artifact **of the declared type** — the type is the contract, not a suggestion:
+
+- `screenshot` / `recording` → an actual image/video file from the driven UI (Playwright, simulator), never a text description of what was seen
+- `http-transcript` → the exact request (curl command or client call) plus the full response
+- `cli-output` → the command plus stdout/stderr and exit code
+- `log-snippet` → the correlated log lines pulled from the running system
+- `db-query-output` → the query plus returned rows
+- `perf-trace` → the benchmark/frame-timing/profiler output with methodology (device profile, dataset size)
+- `test-run-log` → reporter output naming the spec and showing it ran and passed
+- `deploy-log` / `state-dump` → the deployment/health-check output or observed-state JSON
+
+A prose claim ("the error state rendered gracefully") satisfies no marker. Legacy untyped markers: infer the type from the step's action, capture accordingly, and note the inference. Write each artifact to a numbered file:
 
 #### Evidence Naming Convention
 
 `{NN}-{evidence-name}.txt` (or `.json` for structured data):
 
 - `NN`: zero-padded sequential number (01, 02, 03...).
-- `evidence-name`: the value from `[EVIDENCE: <name>]` (kebab-case).
+- `evidence-name`: the `<name>` part of the typed marker (kebab-case).
 
 Example:
 

package/plugins/lisa-cursor/skills/lisa-github-validate-issue/SKILL.md

@@ -196,9 +196,16 @@ An issue with zero links and no documented search: FAIL.
 
 #### S14 — Evidence manifest binding (leaf work units)
 
-When `issue_type ∈ {Bug, Task, Sub-task, Improvement}` AND `runtime_behavior_change = true`, the `## Validation Journey` must declare at least one `[EVIDENCE: name]` marker. Each marker name must be kebab-case and unique within the issue. These markers are the work unit's **evidence manifest** — the exact, enumerated set of artifacts that must be captured and attached before the issue may be closed (see the "Per-Work-Unit Evidence Contract" section of the `verification` rule, the Definition of Done in `verification-lifecycle`, and the evidence-manifest gate in `tracker-evidence`).
+When `issue_type ∈ {Bug, Task, Sub-task, Improvement}` AND `runtime_behavior_change = true`, the `## Validation Journey` must declare at least one **typed** `[EVIDENCE: <artifact-type>: <name>]` marker. These markers are the work unit's **evidence manifest** — the exact, enumerated set of artifacts that must be captured and attached before the issue may be closed (see the "Per-Work-Unit Evidence Contract" section of the `verification` rule, the Definition of Done in `verification-lifecycle`, and the evidence-manifest gate in `tracker-evidence`).
 
-FAIL when the Validation Journey is present but declares zero `[EVIDENCE: name]` markers, or when any marker name is empty, duplicated, or not kebab-case. A behavior-changing work unit SHOULD declare both a success marker and an error/edge marker; a journey with only one marker passes but the remediation should recommend adding the error/edge case.
+Each marker must satisfy ALL of:
+
+- `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
+- `<name>` is kebab-case and unique within the issue.
+
+**A marker names an artifact, not an assertion.** An untyped marker (`[EVIDENCE: load-failure-handled-gracefully]`) is an assertion label with nothing to capture and must FAIL, with a remediation that shows the typed transformation (e.g. → `[EVIDENCE: screenshot: load-failure-error-state]`, `[EVIDENCE: perf-trace: pipeline-load-tti]`).
+
+FAIL when the Validation Journey is present but declares zero markers, when any marker is untyped or uses a type outside the taxonomy, or when any name is empty, duplicated, or not kebab-case. A behavior-changing work unit SHOULD declare both a success marker and an error/edge marker; a journey with only one marker passes but the remediation should recommend adding the error/edge case.
 
 This gate depends on S11. It is `N/A` for containers — an **Epic**, or any item with open child work (coordination containers, not work units) — and for leaf units with `runtime_behavior_change = false` (doc-only / config-only / type-only). If S11 fails because the Validation Journey is absent, S14 also FAILs (there is no manifest to bind) with remediation pointing back to `lisa-github-add-journey`.
 

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

@@ -115,7 +115,7 @@ IF it is a Fix (bug), execute the Reproduce sub-flow FIRST:
    1. Write a simple API client and call the offending API
    2. Start the server on localhost and use the Playwright CLI or Chrome DevTools
 
-For any Fix flow, and for any Build flow that changes user-visible behavior, regression coverage is a required deliverable at the highest practical observation level for the reported surface. If the project has a browser, device, or end-to-end harness for that platform (for example Playwright, Maestro, Detox, Cypress, or an equivalent runtime), the task plan and definition of done MUST include a deterministic regression spec against the reported surface, using mocked or seeded data where needed. This is alongside unit or integration coverage, not a substitute for it.
+For any Fix flow, and for any Build flow that changes user-visible behavior, regression coverage is a required deliverable at the highest practical observation level for the reported surface. If the project has a browser, device, or end-to-end harness for that platform (for example Playwright, Maestro, Detox, Cypress, or an equivalent runtime), the task plan and definition of done MUST include a deterministic regression spec against the reported surface, using mocked or seeded data where needed. This is alongside unit or integration coverage, not a substitute for it. For frontend work this deliverable is **dual-runner** whenever the project supports more than one UI runner: a Playwright spec in the Playwright test runner AND a Maestro flow in the Maestro test runner when the project supports Maestro (`.maestro/` directory, `maestro:test` script, or Maestro CI workflow) — both encoding the same verified journey; neither substitutes for the other (see "Frontend dual-runner codification" in `codify-verification`).
 
 The team lead may not waive, defer, demote, or phrase this regression spec as "optional", "if cheap", "nice to have", or equivalent. The only permitted exits are:
 
@@ -203,7 +203,7 @@ Before shutting down the team, execute the Verify flow:
     - **Human-only blocker** — an input the agent genuinely cannot obtain or produce no matter what it does: credentials, secrets, or **tool access** it does not have (AWS/CloudWatch, Figma, Jam, Sentry, SonarCloud, a database, a protected deploy target, …), or a product/design decision only a human can make. For missing tool access, follow the `tool-access-gate` rule's break-out protocol: post the "Access Needed" comment naming the exact credential/role/env var to grant and the probe that must pass — never work around the gap by substituting weaker verification, mocking the inaccessible system, or narrowing scope. Record the blocked verdict, mark it `human_needed` (the marker `repair-intake` recognizes, so it won't churn re-dispatching it), and surface or reassign to a human; do **not** fabricate a build-ready ticket, because there is no build-ready work.
 
     Other harnesses fall back to this prose obligation.
-3. Write the highest-practical-observation regression test encoding the verification. For user-visible bugs or user-visible Build changes with an available browser/device/e2e harness, this means a deterministic spec on the reported surface. Prove the new spec actually executed and passed in PR CI by recording a named spec log/reporter line or equivalent execution record; green CI without that named evidence does not satisfy this step.
+3. Write the highest-practical-observation regression test encoding the verification. For user-visible bugs or user-visible Build changes with an available browser/device/e2e harness, this means a deterministic spec on the reported surface — and for frontend work, once the validation journey is verified, codification into **every supported UI runner**: a Playwright spec in the Playwright runner AND a Maestro flow when the project supports Maestro, per `codify-verification`. Prove the new spec actually executed and passed in PR CI by recording a named spec log/reporter line or equivalent execution record; green CI without that named evidence does not satisfy this step.
 4. Record Implement usage on the originating work artifact via `lisa-usage-accounting` so the work item (or other implementation-owned artifact) gains a direct `lisa-implement` usage entry in the canonical `## Lisa Usage` section. If the parent / child graph is already known, prefer `record_and_rollup` so ancestor totals refresh in the same write; otherwise still write the direct entry, and if runtime usage is unavailable, use `source: unavailable` with nullable token/cost fields instead of skipping the row.
 5. Commit ALL outstanding changes in logical batches on the branch (minus sensitive data/information) — not just changes made by the agent team. This includes pre-existing uncommitted changes that were on the branch before the plan started. Do NOT filter commits to only "task-related" files. If it shows up in git status, it gets committed (unless it contains secrets).
 6. Push the changes - if any pre-push hook blocks you, create a task for the agent team to fix the error/problem whether it was pre-existing or not

package/plugins/lisa-cursor/skills/lisa-jira-add-journey/SKILL.md

@@ -68,7 +68,7 @@ Based on the change type, generate verification steps using patterns from `verfi
 
 ### Step 5: Draft the Validation Journey
 
-Compose the journey with `[EVIDENCE: name]` markers at key verification points:
+Compose the journey with typed `[EVIDENCE: <artifact-type>: <name>]` markers at key verification points. The type says HOW the proof is captured (`screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump` — the fixed taxonomy in the `verification` rule); the name says WHAT it proves:
 
 ```text
 h2. Validation Journey
@@ -79,9 +79,9 @@ h3. Prerequisites
 h3. Steps
 1. Verify current state before changes
 2. Apply the change
-3. Verify expected new state [EVIDENCE: state-name]
-4. Test error/edge cases [EVIDENCE: error-case]
-5. Verify rollback if applicable [EVIDENCE: rollback]
+3. Verify expected new state [EVIDENCE: http-transcript: health-endpoint-200]
+4. Test error/edge cases [EVIDENCE: screenshot: invalid-input-error-state]
+5. Verify rollback if applicable [EVIDENCE: db-query-output: rows-restored-after-rollback]
 
 h3. Assertions
 - Describe what must be true after verification
@@ -92,10 +92,10 @@ h3. Assertions
 1. **2-5 evidence markers** — Focus on proving the change works and handles errors
 2. **Concrete, runnable steps** — "Run `curl -s localhost:3000/health | jq .status`" not "Check the endpoint"
 3. **Include environment setup** — Database connection, running services, env vars
-4. **Evidence names in kebab-case** — `api-response`, `schema-check`, `rate-limit-hit`
+4. **Markers are typed artifacts, not assertion labels** — `[EVIDENCE: <artifact-type>: <kebab-name>]`. `[EVIDENCE: load-failure-handled-gracefully]` names a claim with nothing to capture; write `[EVIDENCE: screenshot: load-failure-error-state]` or `[EVIDENCE: perf-trace: pipeline-load-tti]`. Names are kebab-case and unique within the ticket.
 5. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly"
 6. **Cover happy path and error path** — At minimum, one success and one failure evidence marker
-7. **On a leaf work unit, the markers are binding** — For a Bug / Task / Sub-task / Improvement, every `[EVIDENCE: name]` here is the ticket's evidence manifest: validation gate S14 requires at least one, and the ticket cannot be closed until each named artifact is captured and attached (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Name only evidence you intend to capture — and name all of it.
+7. **On a leaf work unit, the markers are binding** — For a Bug / Task / Sub-task / Improvement, every typed `[EVIDENCE: <artifact-type>: <name>]` here is the ticket's evidence manifest: validation gate S14 requires at least one, and the ticket cannot be closed until each named artifact is captured **in its declared type** and attached (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Name only evidence you intend to capture — and name all of it.
 
 ### Step 6: Present to User for Approval
 

package/plugins/lisa-cursor/skills/lisa-jira-create/SKILL.md

@@ -55,7 +55,7 @@ Skip the Validation Journey for:
 
 ### How to Write
 
-Design the journey based on the **change type**. The agent executing the journey determines how to verify each step using patterns from the project's `verfication.md`. Place `[EVIDENCE: name]` markers at key verification points.
+Design the journey based on the **change type**. The agent executing the journey determines how to verify each step using patterns from the project's `verfication.md`. Place typed `[EVIDENCE: <artifact-type>: <name>]` markers at key verification points (types: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump` — see the `verification` rule).
 
 Add this section to the ticket description:
 
@@ -70,9 +70,9 @@ h3. Prerequisites
 h3. Steps
 1. Verify the current state before changes
 2. Apply the change (run migration, deploy, etc.)
-3. Verify the expected new state [EVIDENCE: state-after-change]
-4. Test error/edge cases [EVIDENCE: error-handling]
-5. Verify rollback or cleanup if applicable [EVIDENCE: rollback-check]
+3. Verify the expected new state [EVIDENCE: http-transcript: state-after-change]
+4. Test error/edge cases [EVIDENCE: screenshot: error-state-rendered]
+5. Verify rollback or cleanup if applicable [EVIDENCE: db-query-output: rows-restored-after-rollback]
 
 h3. Assertions
 - Describe what must be true after verification
@@ -82,7 +82,7 @@ h3. Assertions
 ### Guidelines
 
 1. **Steps must be concrete and verifiable** — "Run `curl -s localhost:3000/health`" not "Check the API"
-2. **Evidence markers at verification points** — Place `[EVIDENCE: name]` at states that prove the change works. Use descriptive kebab-case names (e.g., `api-response`, `schema-check`, `rate-limit-hit`)
+2. **Evidence markers at verification points** — Place typed `[EVIDENCE: <artifact-type>: <name>]` at states that prove the change works. The type names HOW the proof is captured, the kebab-case name WHAT it proves (e.g., `[EVIDENCE: http-transcript: api-response-200]`, `[EVIDENCE: screenshot: error-state-rendered]`). An untyped assertion label like `[EVIDENCE: works-gracefully]` fails validation gate S14
 3. **Include 2-5 evidence markers** — Enough to prove the change works across happy path and error cases
 4. **Assertions are testable statements** — "Health check returns 200 with status ok" not "API works"
 5. **Prerequisites include environment setup** — Database connection, env vars, running services

package/plugins/lisa-cursor/skills/lisa-jira-journey/SKILL.md

@@ -8,7 +8,7 @@ allowed-tools: ["Bash", "Read", "Glob", "Grep", "Skill"]
 
 All Atlassian operations in this skill go through `lisa-atlassian-access`. Do not call MCP tools or `acli` directly. Note: the helper scripts (`scripts/parse-plan.py`, `scripts/jira-evidence/post-evidence.sh`) currently use direct API calls and are pending migration to route through `atlassian-access`.
 
-Parse a JIRA ticket's Validation Journey, execute the verification steps using the appropriate tools for the change type, capture evidence at each `[EVIDENCE: name]` marker, and post to JIRA + GitHub PR.
+Parse a JIRA ticket's Validation Journey, execute the verification steps using the appropriate tools for the change type, capture evidence at each typed `[EVIDENCE: <artifact-type>: <name>]` marker, and post to JIRA + GitHub PR.
 
 ## Arguments
 
@@ -57,14 +57,25 @@ Execute each step sequentially. For each step, determine the verification approa
 - **Library/utility changes** → Run tests, capture output to `evidence/NN-name.txt`
 - **Security fixes** → Reproduce exploit attempt, verify fix, capture output to `evidence/NN-name.txt`
 
-At each `[EVIDENCE: name]` marker, capture stdout/stderr to a numbered file:
+At each typed `[EVIDENCE: <artifact-type>: <name>]` marker, capture an artifact **of the declared type** — the type is the contract, not a suggestion:
+
+- `screenshot` / `recording` → an actual image/video file from the driven UI (Playwright, simulator), never a text description of what was seen
+- `http-transcript` → the exact request (curl command or client call) plus the full response
+- `cli-output` → the command plus stdout/stderr and exit code
+- `log-snippet` → the correlated log lines pulled from the running system
+- `db-query-output` → the query plus returned rows
+- `perf-trace` → the benchmark/frame-timing/profiler output with methodology (device profile, dataset size)
+- `test-run-log` → reporter output naming the spec and showing it ran and passed
+- `deploy-log` / `state-dump` → the deployment/health-check output or observed-state JSON
+
+A prose claim ("the error state rendered gracefully") satisfies no marker. Legacy untyped markers: infer the type from the step's action, capture accordingly, and note the inference. Write each artifact to a numbered file:
 
 #### Evidence Naming Convention
 
-Evidence files are named: `{NN}-{evidence-name}.txt` (or `.json` for structured data)
+Evidence files are named: `{NN}-{evidence-name}.{ext}` — extension matches the declared artifact type (`.png`/`.webm` for screenshot/recording, `.txt` for transcripts/logs/output, `.json` for structured state)
 
 - `NN`: zero-padded sequential number (01, 02, 03...)
-- `evidence-name`: the value from `[EVIDENCE: name]` in the JIRA step
+- `evidence-name`: the `<name>` part of the typed marker in the JIRA step
 
 Example:
 

package/plugins/lisa-cursor/skills/lisa-jira-validate-ticket/SKILL.md

@@ -197,9 +197,16 @@ A ticket with zero links and no documented search: FAIL.
 
 #### S14 — Evidence manifest binding (leaf work units)
 
-When `issue_type ∈ {Bug, Task, Sub-task, Improvement}` AND `runtime_behavior_change = true`, the `h2. Validation Journey` must declare at least one `[EVIDENCE: name]` marker. Each marker name must be kebab-case and unique within the ticket. These markers are the work unit's **evidence manifest** — the exact, enumerated set of artifacts that must be captured and attached before the ticket may be marked complete (see the "Per-Work-Unit Evidence Contract" section of the `verification` rule, the Definition of Done in `verification-lifecycle`, and the evidence-manifest gate in `tracker-evidence`).
+When `issue_type ∈ {Bug, Task, Sub-task, Improvement}` AND `runtime_behavior_change = true`, the `h2. Validation Journey` must declare at least one **typed** `[EVIDENCE: <artifact-type>: <name>]` marker. These markers are the work unit's **evidence manifest** — the exact, enumerated set of artifacts that must be captured and attached before the ticket may be marked complete (see the "Per-Work-Unit Evidence Contract" section of the `verification` rule, the Definition of Done in `verification-lifecycle`, and the evidence-manifest gate in `tracker-evidence`).
 
-FAIL when the Validation Journey is present but declares zero `[EVIDENCE: name]` markers, or when any marker name is empty, duplicated, or not kebab-case. A behavior-changing work unit SHOULD declare both a success marker and an error/edge marker; a journey with only one marker passes but the remediation should recommend adding the error/edge case.
+Each marker must satisfy ALL of:
+
+- `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
+- `<name>` is kebab-case and unique within the ticket.
+
+**A marker names an artifact, not an assertion.** An untyped marker (`[EVIDENCE: load-failure-handled-gracefully]`) is an assertion label with nothing to capture and must FAIL, with a remediation that shows the typed transformation (e.g. → `[EVIDENCE: screenshot: load-failure-error-state]`, `[EVIDENCE: perf-trace: pipeline-load-tti]`).
+
+FAIL when the Validation Journey is present but declares zero markers, when any marker is untyped or uses a type outside the taxonomy, or when any name is empty, duplicated, or not kebab-case. A behavior-changing work unit SHOULD declare both a success marker and an error/edge marker; a journey with only one marker passes but the remediation should recommend adding the error/edge case.
 
 This gate depends on S11. It is `N/A` for containers — an **Epic**, or any item with open child work (coordination containers, not work units) — and for leaf units with `runtime_behavior_change = false` (doc-only / config-only / type-only). If S11 fails because the Validation Journey is absent, S14 also FAILs (there is no manifest to bind) with remediation pointing back to `lisa-jira-add-journey`.
 

package/plugins/lisa-cursor/skills/lisa-linear-add-journey/SKILL.md

@@ -58,6 +58,8 @@ Use Explore agents or read the codebase to understand which files are affected a
 
 Linear descriptions are markdown. Use `##` and `###` headings — not Jira wiki markup.
 
+Compose the journey with typed `[EVIDENCE: <artifact-type>: <name>]` markers at key verification points. The type says HOW the proof is captured (`screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump` — the fixed taxonomy in the `verification` rule); the name says WHAT it proves.
+
 ```markdown
 ## Validation Journey
 
@@ -67,9 +69,9 @@ Linear descriptions are markdown. Use `##` and `###` headings — not Jira wiki
 ### Steps
 1. Verify current state before changes
 2. Apply the change
-3. Verify expected new state [EVIDENCE: state-name]
-4. Test error/edge cases [EVIDENCE: error-case]
-5. Verify rollback if applicable [EVIDENCE: rollback]
+3. Verify expected new state [EVIDENCE: http-transcript: health-endpoint-200]
+4. Test error/edge cases [EVIDENCE: screenshot: invalid-input-error-state]
+5. Verify rollback if applicable [EVIDENCE: db-query-output: rows-restored-after-rollback]
 
 ### Assertions
 - Describe what must be true after verification
@@ -80,10 +82,10 @@ Linear descriptions are markdown. Use `##` and `###` headings — not Jira wiki
 1. **2–5 evidence markers** — Focus on proving the change works and handles errors.
 2. **Concrete, runnable steps** — `Run \`curl -s localhost:3000/health | jq .status\`` not "Check the endpoint".
 3. **Include environment setup** — Database connection, running services, env vars.
-4. **Evidence names in kebab-case** — `api-response`, `schema-check`, `rate-limit-hit`.
+4. **Markers are typed artifacts, not assertion labels** — `[EVIDENCE: <artifact-type>: <kebab-name>]`. `[EVIDENCE: load-failure-handled-gracefully]` names a claim with nothing to capture; write `[EVIDENCE: screenshot: load-failure-error-state]` or `[EVIDENCE: perf-trace: pipeline-load-tti]`. Names are kebab-case and unique within the ticket.
 5. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly".
 6. **Cover happy path and error path** — At minimum, one success and one failure evidence marker.
-7. **On a leaf work unit, the markers are binding** — For a Bug / Task / Sub-task / Improvement, every `[EVIDENCE: name]` here is the item's evidence manifest: validation gate S14 requires at least one, and the item cannot be closed until each named artifact is captured and attached (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Name only evidence you intend to capture — and name all of it.
+7. **On a leaf work unit, the markers are binding** — For a Bug / Task / Sub-task / Improvement, every typed `[EVIDENCE: <artifact-type>: <name>]` here is the item's evidence manifest: validation gate S14 requires at least one, and the item cannot be closed until each named artifact is captured **in its declared type** and attached (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Name only evidence you intend to capture — and name all of it.
 
 ### Step 6: Present to User for Approval
 

package/plugins/lisa-cursor/skills/lisa-linear-create/SKILL.md

@@ -58,7 +58,7 @@ Items that change runtime behavior should include a `## Validation Journey` sect
 
 ### How to Write
 
-Design the journey based on the **change type**. Place `[EVIDENCE: name]` markers at key verification points.
+Design the journey based on the **change type**. Place typed `[EVIDENCE: <artifact-type>: <name>]` markers at key verification points (types: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump` — see the `verification` rule).
 
 ```markdown
 ## Validation Journey
@@ -71,9 +71,9 @@ Design the journey based on the **change type**. Place `[EVIDENCE: name]` marker
 ### Steps
 1. Verify the current state before changes
 2. Apply the change (run migration, deploy, etc.)
-3. Verify the expected new state [EVIDENCE: state-after-change]
-4. Test error/edge cases [EVIDENCE: error-handling]
-5. Verify rollback or cleanup if applicable [EVIDENCE: rollback-check]
+3. Verify the expected new state [EVIDENCE: http-transcript: state-after-change]
+4. Test error/edge cases [EVIDENCE: screenshot: error-state-rendered]
+5. Verify rollback or cleanup if applicable [EVIDENCE: db-query-output: rows-restored-after-rollback]
 
 ### Assertions
 - Describe what must be true after verification

package/plugins/lisa-cursor/skills/lisa-linear-journey/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: lisa-linear-journey
-description: "Parse a Linear Issue's Validation Journey section, execute the verification steps using appropriate tools (curl, test commands, database queries, Playwright), capture evidence at each [EVIDENCE: name] marker, and post to Linear + GitHub PR using the linear-evidence skill. Linear counterpart of lisa-jira-journey."
+description: "Parse a Linear Issue's Validation Journey section, execute the verification steps using appropriate tools (curl, test commands, database queries, Playwright), capture evidence at each typed [EVIDENCE: <artifact-type>: <name>] marker, and post to Linear + GitHub PR using the linear-evidence skill. Linear counterpart of lisa-jira-journey."
 allowed-tools: ["Bash", "Read", "Glob", "Grep", "Skill"]
 ---
 
 # Linear Validation Journey
 
-Parse a Linear Issue's Validation Journey, execute the verification steps using the appropriate tools for the change type, capture evidence at each `[EVIDENCE: name]` marker, and post to Linear + GitHub PR.
+Parse a Linear Issue's Validation Journey, execute the verification steps using the appropriate tools for the change type, capture evidence at each typed `[EVIDENCE: <artifact-type>: <name>]` marker, and post to Linear + GitHub PR.
 
 This skill is the destination of the `lisa-tracker-journey` shim when `tracker = "linear"`.
 
@@ -34,7 +34,7 @@ Reads `linear.workspace`, `linear.teamKey` from `.lisa.config.json` (with `.loca
 Fetch the Issue via `lisa-linear-access operation: get-issue` and extract the `## Validation Journey` section from the markdown description. Parse:
 
 - `### Prerequisites` — list of required services / env / setup
-- `### Steps` — numbered steps, each potentially containing `[EVIDENCE: name]` markers
+- `### Steps` — numbered steps, each potentially containing typed `[EVIDENCE: <artifact-type>: <name>]` markers
 - `### Assertions` — what must be true after verification
 
 If the section is missing or has no steps, report `"No Validation Journey on <IDENTIFIER>. Run /linear-add-journey first."` and stop.
@@ -61,14 +61,25 @@ Execute each step sequentially. Determine the verification approach based on the
 - **Security fixes** → Reproduce exploit attempt, verify fix
 - **UI / frontend** → Playwright browser flow, capture screenshots / DOM state
 
-At each `[EVIDENCE: name]` marker, capture stdout / stderr to a numbered file:
+At each typed `[EVIDENCE: <artifact-type>: <name>]` marker, capture an artifact **of the declared type** — the type is the contract, not a suggestion:
+
+- `screenshot` / `recording` → an actual image/video file from the driven UI (Playwright, simulator), never a text description of what was seen
+- `http-transcript` → the exact request (curl command or client call) plus the full response
+- `cli-output` → the command plus stdout/stderr and exit code
+- `log-snippet` → the correlated log lines pulled from the running system
+- `db-query-output` → the query plus returned rows
+- `perf-trace` → the benchmark/frame-timing/profiler output with methodology (device profile, dataset size)
+- `test-run-log` → reporter output naming the spec and showing it ran and passed
+- `deploy-log` / `state-dump` → the deployment/health-check output or observed-state JSON
+
+A prose claim ("the error state rendered gracefully") satisfies no marker. Legacy untyped markers: infer the type from the step's action, capture accordingly, and note the inference. Write each artifact to a numbered file:
 
 #### Evidence Naming Convention
 
 `{NN}-{evidence-name}.{ext}`
 
 - `NN`: zero-padded sequential number (`01`, `02`, `03`...)
-- `evidence-name`: the value from `[EVIDENCE: name]`
+- `evidence-name`: the `<name>` part of the typed marker
 - `ext`: `.txt` for plain output, `.json` for structured data
 
 Example:

package/plugins/lisa-cursor/skills/lisa-linear-validate-issue/SKILL.md

@@ -200,9 +200,16 @@ An item with zero relations and no documented search: FAIL.
 
 #### S14 — Evidence manifest binding (leaf work units)
 
-When `issue_type ∈ {Bug, Task, Sub-task, Improvement}` AND `runtime_behavior_change = true`, the `## Validation Journey` must declare at least one `[EVIDENCE: name]` marker. Each marker name must be kebab-case and unique within the item. These markers are the work unit's **evidence manifest** — the exact, enumerated set of artifacts that must be captured and attached before the item may be closed (see the "Per-Work-Unit Evidence Contract" section of the `verification` rule, the Definition of Done in `verification-lifecycle`, and the evidence-manifest gate in `tracker-evidence`).
+When `issue_type ∈ {Bug, Task, Sub-task, Improvement}` AND `runtime_behavior_change = true`, the `## Validation Journey` must declare at least one **typed** `[EVIDENCE: <artifact-type>: <name>]` marker. These markers are the work unit's **evidence manifest** — the exact, enumerated set of artifacts that must be captured and attached before the item may be closed (see the "Per-Work-Unit Evidence Contract" section of the `verification` rule, the Definition of Done in `verification-lifecycle`, and the evidence-manifest gate in `tracker-evidence`).
 
-FAIL when the Validation Journey is present but declares zero `[EVIDENCE: name]` markers, or when any marker name is empty, duplicated, or not kebab-case. A behavior-changing work unit SHOULD declare both a success marker and an error/edge marker; a journey with only one marker passes but the remediation should recommend adding the error/edge case.
+Each marker must satisfy ALL of:
+
+- `<artifact-type>` is one of the fixed taxonomy: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump`. (The legacy `[SCREENSHOT: name]` form is accepted as `screenshot`.)
+- `<name>` is kebab-case and unique within the item.
+
+**A marker names an artifact, not an assertion.** An untyped marker (`[EVIDENCE: load-failure-handled-gracefully]`) is an assertion label with nothing to capture and must FAIL, with a remediation that shows the typed transformation (e.g. → `[EVIDENCE: screenshot: load-failure-error-state]`, `[EVIDENCE: perf-trace: pipeline-load-tti]`).
+
+FAIL when the Validation Journey is present but declares zero markers, when any marker is untyped or uses a type outside the taxonomy, or when any name is empty, duplicated, or not kebab-case. A behavior-changing work unit SHOULD declare both a success marker and an error/edge marker; a journey with only one marker passes but the remediation should recommend adding the error/edge case.
 
 This gate depends on S11. It is `N/A` for containers — a **Project** (the Epic equivalent), or any item with open child work (coordination containers, not work units) — and for leaf units with `runtime_behavior_change = false` (doc-only / config-only / type-only). If S11 fails because the Validation Journey is absent, S14 also FAILs (there is no manifest to bind) with remediation pointing back to `lisa-linear-add-journey`.
 

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

@@ -59,7 +59,7 @@ The **Rails** ops-specialist composes a different subset (`ops-run-local`, `ops-
 After report, file what was found — **only when run standalone**, never under `--report-only`/`--dry-run` and never when nested inside `lisa-verify` (which passes `--report-only`):
 
 - **Anomalies** (live signals over the conservative bar) → `Bug` leaves. **Gaps** (in-scope MISSING rubric dimensions) → `Task`/`Improvement` leaves.
-- Every ticket is filed via the vendor-neutral `lisa-tracker-write` shim with `build_ready: true` (never a vendor write skill directly), as a **single-repo leaf** stamped `repo:<current>`, with a real three-audience description, Gherkin AC, Target Backend Environment, and a Validation Journey + `EVIDENCE:` marker so it passes the `tracker-validate` gates.
+- Every ticket is filed via the vendor-neutral `lisa-tracker-write` shim with `build_ready: true` (never a vendor write skill directly), as a **single-repo leaf** stamped `repo:<current>`, with a real three-audience description, Gherkin AC, Target Backend Environment, and a Validation Journey + typed `[EVIDENCE: <artifact-type>: <name>]` marker (e.g. `[EVIDENCE: log-snippet: alert-cleared]`) so it passes the `tracker-validate` gates.
 - **Idempotent:** embed the `<!-- lisa:monitor-finding: <fingerprint> -->` sentinel and search-before-create; never duplicate a live or just-resolved finding.
 - **Capped** at `max_candidates` (default 20), `core`/high-severity first; report how many were filed vs dropped.
 - **`--dry-run`** previews would-file tickets and creates nothing. **`--all-gaps`** widens gap filing to `recommended` tiers.

package/plugins/lisa-cursor/skills/lisa-project-ideation/examples/idempotency-verification-harness.md

@@ -50,8 +50,8 @@ The harness performs the acceptance check in three phases:
 
 Capture the harness JSON output as:
 
-- `[EVIDENCE: marker-count-one]` from the first and second marker-count checks.
-- `[EVIDENCE: memory-recreated-after-rerun]` from the missing-memory variant.
+- `[EVIDENCE: cli-output: marker-count-one]` from the first and second marker-count checks.
+- `[EVIDENCE: cli-output: memory-recreated-after-rerun]` from the missing-memory variant.
 
 The run passes only when all reported counts are `1`, the issue URL is the same across phases, and
 `memoryRecreated` and `memoryFieldsRecorded` are `true` when `--memory-file` is supplied.

package/plugins/lisa-cursor/skills/lisa-tracker-add-journey/SKILL.md

@@ -23,5 +23,5 @@ See the `config-resolution` rule for configuration and dispatch table.
 
 ## Rules
 
-- The Validation Journey content format is identical across all vendors (markdown sections with `[EVIDENCE: name]` markers). The only difference is how the section is appended — JIRA via `editJiraIssue` (Jira wiki markup), GitHub via `gh issue edit --body-file` (markdown), Linear via `save_issue` (markdown).
+- The Validation Journey content format is identical across all vendors (markdown sections with typed `[EVIDENCE: <artifact-type>: <name>]` markers per the `verification` rule taxonomy). The only difference is how the section is appended — JIRA via `editJiraIssue` (Jira wiki markup), GitHub via `gh issue edit --body-file` (markdown), Linear via `save_issue` (markdown).
 - If the ticket already has a Validation Journey, the vendor skill reports it and stops. This shim does not retry.

package/plugins/lisa-cursor/skills/lisa-tracker-evidence/SKILL.md

@@ -27,7 +27,7 @@ See the `config-resolution` rule for configuration and dispatch table.
 - The GitHub `pr-assets` release lives on the implementation repo (the one with the PR), regardless of which tracker hosts the ticket/issue. All vendor skills upload there.
 - Never post evidence to a different ticket than the one named — `$ARGUMENTS` is the source of truth.
 - Never invent a verify-specific usage footer. Evidence artifact usage must flow through `lisa-usage-accounting`, preserve the canonical `## Lisa Usage` section, and surface `source: unavailable` explicitly when the runtime cannot provide trustworthy numbers.
-- **Evidence-manifest gate (leaf work units).** Before dispatching to a vendor skill that transitions the ticket, confirm `EVIDENCE_DIR` contains a non-empty artifact for every `[EVIDENCE: name]` marker declared in the ticket's Validation Journey. If any declared marker has no captured artifact (or only an empty one), stop and report the missing markers by name instead of posting — a leaf work unit (Bug / Task / Sub-task / Improvement) may not advance to its review/Done state with an unsatisfied manifest (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Epics / Stories / Spikes, and leaf units without a Validation Journey, are exempt.
+- **Evidence-manifest gate (leaf work units).** Before dispatching to a vendor skill that transitions the ticket, confirm `EVIDENCE_DIR` contains a non-empty artifact **of the declared type** for every typed `[EVIDENCE: <artifact-type>: <name>]` marker declared in the ticket's Validation Journey — a `screenshot` marker needs an actual image, an `http-transcript` marker needs the request + response text, a `perf-trace` marker needs measured numbers; a prose claim satisfies nothing. If any declared marker has no captured artifact, an empty one, or one whose content/extension does not match its declared type, stop and report the offending markers by name instead of posting — a leaf work unit (Bug / Task / Sub-task / Improvement) may not advance to its review/Done state with an unsatisfied manifest (see the "Per-Work-Unit Evidence Contract" in the `verification` rule). Epics / Stories / Spikes, and leaf units without a Validation Journey, are exempt.
 
 ## UI Evidence Checklist (when work is UI-visible)
 

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

@@ -76,7 +76,7 @@ If auto-merge is enabled while the regression spec is still in flight, disable a
 
 After each empirical verification produces PASS evidence, invoke the `codify-verification` skill to encode the verification as an automated regression test. The manual proof becomes a repeatable check that catches future regressions.
 
-The `codify-verification` skill maps the verification type to the appropriate framework (Playwright for browser/UI, integration test for API/DB/auth, benchmark for performance, etc.), generates a deterministic test that asserts the same observable outcome the verification just confirmed, runs it in isolation to confirm PASS, and commits it in the same PR as the change.
+The `codify-verification` skill maps the verification type to the appropriate framework (Playwright for browser/UI, integration test for API/DB/auth, benchmark for performance, etc.), generates a deterministic test that asserts the same observable outcome the verification just confirmed, runs it in isolation to confirm PASS, and commits it in the same PR as the change. For **frontend work**, codification is dual-runner: a Playwright spec in the project's Playwright test runner AND a Maestro flow in the Maestro test runner whenever the project supports Maestro (`.maestro/` directory, `maestro:test` script, or Maestro CI workflow) — both encoding the same verified journey, neither a substitute for the other.
 
 Codification is mandatory for every empirical verification type with one exception set: PR, Documentation, Deploy, and Investigate-Only spikes — those have inherently non-behavioral proof. For every other type, skipping codification is not allowed; if codification is genuinely impossible (e.g., the test framework does not exist and cannot be installed in scope), escalate via the Escalation Protocol rather than silently skipping.
 
@@ -236,7 +236,7 @@ Agents must follow this sequence unless explicitly instructed otherwise:
 8. Implement the change.
 9. Execute verification plan — run the actual system and observe results.
 10. Collect proof artifacts.
-11. Codify — for each passing empirical verification, invoke `codify-verification` to encode it as a regression test (Playwright for UI, integration test for API/DB/auth, benchmark for performance, etc.) and commit the test in the same PR.
+11. Codify — for each passing empirical verification, invoke `codify-verification` to encode it as a regression test (Playwright for UI, integration test for API/DB/auth, benchmark for performance, etc.) and commit the test in the same PR. Frontend work codifies into every supported UI runner: Playwright spec + Maestro flow when the project supports Maestro (see the dual-runner section of `codify-verification`).
 12. Run spec conformance — build coverage matrix against the spec source (plan/ticket/issue), flag scope creep and untraceable changes, produce verdict.
 13. Summarize what changed, what was verified, what was codified, conformance verdict, and remaining risk.
 14. Label the result with a verification level.
@@ -250,7 +250,7 @@ Agents must follow this sequence unless explicitly instructed otherwise:
 3. **If verification fails**: Fix and re-run, don't mark complete
 4. **If verification blocked** (missing tools, services, etc.): Mark as blocked, not complete
 5. **Must not be dependent on CI/CD** if necessary, you may use local deploy methods found in the project manifest, but the verification methods must be listed in the pull request and therefore cannot be dependent on CI/CD completing
-6. **Evidence manifest satisfied (leaf work units)**: For a leaf work unit (Bug / Task / Sub-task / Improvement) whose ticket carries a Validation Journey, do not mark the ticket complete or transition it out of in-progress until every `[EVIDENCE: name]` marker declared on the ticket has a corresponding captured, non-empty artifact attached to the ticket. A missing or empty artifact for any declared marker blocks completion exactly like a failed verification — fix and re-capture, or escalate; never close with an unsatisfied manifest. Epics / Stories / Spikes are exempt (coordination containers, not work units).
+6. **Evidence manifest satisfied (leaf work units)**: For a leaf work unit (Bug / Task / Sub-task / Improvement) whose ticket carries a Validation Journey, do not mark the ticket complete or transition it out of in-progress until every typed `[EVIDENCE: <artifact-type>: <name>]` marker declared on the ticket has a corresponding captured, non-empty artifact **of the declared type** attached to the ticket (an image for `screenshot`, request + response for `http-transcript`, measured output for `perf-trace`, …). A missing, empty, or wrong-type artifact for any declared marker blocks completion exactly like a failed verification — fix and re-capture, or escalate; never close with an unsatisfied manifest. Epics / Stories / Spikes are exempt (coordination containers, not work units).
 7. **No artifact-only completion for required runtime verification**: If empirical verification is required and cannot run because credentials are missing, do not mark the item done on artifact-only evidence. Exhaust the credential lookup order first; if still blocked, post the blocker comment, move the item to the configured blocked state, and apply the configured `needs-human` / `human-review` label.
 
 ---
@@ -357,7 +357,7 @@ A task is done only when:
 - Required verification surfaces and tooling surfaces are used or explicitly unavailable
 - Proof artifacts are captured
 - Every passing empirical verification is codified as a regression test (or has an explicit, documented skip reason from the allowed set)
-- For a leaf work unit, every `[EVIDENCE: name]` marker declared in its Validation Journey has a captured, non-empty artifact attached to the ticket (the evidence manifest is fully satisfied)
+- For a leaf work unit, every typed `[EVIDENCE: <artifact-type>: <name>]` marker declared in its Validation Journey has a captured, non-empty artifact of the declared type attached to the ticket (the evidence manifest is fully satisfied)
 - Spec conformance verdict is `CONFORMS` (not `PARTIAL`, not `DIVERGES`)
 - Verification level is declared
 - Risks and gaps are documented

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

@@ -35,7 +35,7 @@ Treat the first successful lead-spawn request (or, on the Codex fallback, the fi
 
 Execute the **Verify** flow as defined in the `intent-routing` rule (loaded via the lisa plugin). The flow includes:
 
-1. **Pre-flight: codification gate** — confirm that every passing local empirical verification on this branch was codified as a regression test (the Implement flow's codify step). If any verification has no committed test and no allowed skip reason (PR / Documentation / Deploy / Investigate-Only), invoke `codify-verification` now and amend the PR before shipping. A change cannot ship until its verifications are guarded.
+1. **Pre-flight: codification gate** — confirm that every passing local empirical verification on this branch was codified as a regression test (the Implement flow's codify step). If any verification has no committed test and no allowed skip reason (PR / Documentation / Deploy / Investigate-Only), invoke `codify-verification` now and amend the PR before shipping. For frontend work the gate is dual-runner: a Playwright spec AND, when the project supports Maestro (`.maestro/`, `maestro:test` script, or Maestro CI workflow), a Maestro flow for the same journey — a missing runner needs a recorded absence or a linked build-ready follow-up ticket, never a silent skip. A change cannot ship until its verifications are guarded.
 2. **Commit** any pending changes via `lisa-git-commit`
 3. **Push and PR** via `lisa-git-submit-pr`
 4. **Review loop** — handle CodeRabbit / human review comments via `lisa-pull-request-review`

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

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

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

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

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

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

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

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