lisa-tracker-evidence

name	lisa-tracker-evidence
description	Vendor-neutral wrapper for posting verification evidence. Reads the required `tracker` from .lisa.config.json and dispatches to lisa-jira-evidence, lisa-github-evidence, or lisa-linear-evidence. Uploads evidence to the GitHub `pr-assets` release, updates the PR description, posts a comment on the originating ticket/issue, and leaves workflow transitions to the tracker-specific lifecycle owner.
allowed-tools	["Skill","Bash","Read"]

Tracker Evidence: $ARGUMENTS

Thin dispatcher. Resolves the configured destination tracker and delegates to the matching vendor evidence skill.

See the config-resolution rule for configuration and dispatch table.

Workflow

1. Resolve tracker config (same logic as lisa-tracker-write).
2. Missing / empty → stop and report "No tracker configured in .lisa.config.json. Run /lisa:setup:jira, /lisa:setup:github, or /lisa:setup:linear first."
3. Before dispatching, update the generated evidence artifact through lisa-usage-accounting so the comment body / PR evidence section carries a direct lisa-verify usage entry in the canonical ## Lisa Usage section. If the originating work item's parentage or child refs are already known, prefer record_and_rollup so ancestor totals refresh in the same write; otherwise still write the direct entry, and if trustworthy runtime usage is unavailable, write source: unavailable with nullable token/cost fields instead of skipping the row.
4. Dispatch:
   • jira → invoke lisa-jira-evidence with $ARGUMENTS verbatim. Arg shape: <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>.
   • github → invoke lisa-github-evidence with $ARGUMENTS verbatim. Arg shape: <ISSUE_REF> <EVIDENCE_DIR> <PR_NUMBER> where ISSUE_REF is org/repo#<number> or a GitHub issue URL.
   • linear → invoke lisa-linear-evidence with $ARGUMENTS verbatim. Arg shape: <IDENTIFIER> <EVIDENCE_DIR> where IDENTIFIER is a Linear Issue identifier (e.g., ENG-123).
   • Anything else → stop and report "Unknown tracker '<value>' in .lisa.config.json. Expected 'jira', 'github', or 'linear'."
5. Pass through the vendor skill's output.

Rules

• 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 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.
• Claim↔boundary binding (S14 upgrade). Satisfying the manifest by type is not enough: each [EVIDENCE: <artifact-type>: <name>] marker is also cited for a claim, and the marker's artifact type must reach the boundary that claim declares per the claim-evidence-mapping rule's taxonomy. A browser claim (user-visible UI behavior) is reached by screenshot / recording and never by a unit test-run-log; an http-api claim needs an http-transcript; a deploy-health claim needs a deploy-log and no pre-deploy artifact. On a mismatch, report the offending marker by name together with the claim, its boundary, and the required evidence kinds for that boundary — e.g. [EVIDENCE: test-run-log: unit-suite] cited for claim AC-2 [boundary browser] — required evidence kinds: screenshot, recording. Swapping in a marker of a reaching kind with a real captured artifact satisfies the gate. until is in (the same ratchet flag the Stop-hook gate reads, default ), a boundary mismatch is reported to the operator but does not block the post; once ratcheted on it refuses the post exactly like a missing or wrong-type artifact. Missing/empty/wrong-type artifacts keep refusing the post regardless of the flag.

UI Evidence Checklist (when work is UI-visible)

Apply this when authoring evidence/comment.md (and evidence/comment.txt for JIRA wiki markup) for any ticket whose work touches a user-facing surface — bug fix, new component, new flow, UX polish, design implementation. Skip the checklist for non-UI work (API, infra, migrations, etc.); the plain-text evidence path is fine there.

The checklist is tracker-agnostic — the same shape works on JIRA, GitHub Issues, and Linear. Vendor skills only own the post/transition mechanics; the comment body is your responsibility.

1. AI disclosure at the top. Lead with "Update from Claude (AI agent, not a human)" and address the reporter / QA / PM by name.
2. Own any prior mistake explicitly. If an earlier triage or build pass got something wrong, say so up front. Don't bury it.
3. Numbered step-by-step walk of what you actually did in the browser/app, in plain language a non-engineer can follow:
   • Exact env (URL, viewport size — e.g. 402×874 for an iOS-sized mobile flow)
   • Login creds shape — e.g. [phone] + OTP 555555
   • Exact record/player name, exact button labels as they appear on screen
   • Full happy-path and any non-obvious edge state worth showing (empty state, loading, post-completion)
4. One screenshot per step, captured live through the interactive browser controller at the matching viewport. The controller may be an in-app Browser/Chrome tool, interactive Playwright control, CDP, computer use, or an equivalent; do not require one named backend. Upload via gh release upload pr-assets <files> --clobber and reference each one as a plain URL in the comment body — not ![alt](url) markdown embeds. Plain URLs render as smartlinks/auto-embeds across all three trackers and stay individually viewable; markdown embeds collapse on JIRA when there are ≥2.
5. "What this shows" section. Tailor to ticket type:
   • Bug repro: state plainly whether the bug reproduces or not, and the most likely 1–2 reasons their retest still failed (different env, native app vs. web, stuck backend row, etc.).
   • Feature/UX completion: state plainly which acceptance criteria each screenshot covers, and call out any deferred or out-of-scope surface explicitly so QA/PM doesn't have to infer.
6. "Artifact identity" and "Not established" sections (both required). Right after "What this shows":
   • ## Artifact identity — what the evidence was collected against, as values, not placeholders: the repository, the head_sha the verification observed, the environment, and per artifact its sha256 digest and captured_at. A heading rendered with <unknown> in place of a SHA is not identity.
   • ## Not established — never omitted, never blank. List in plain language what this verification did prove: boundaries not exercised (e.g. "the persisted order row was never queried"), environments not tested (e.g. "checked on desktop Chrome only — not mobile Safari"), and behavior consciously out of scope (e.g. "refunds were not touched or tested"). Name the specific thing, not a category. With nothing outstanding, the heading still renders a single line: . Never state a quality check as proof of behavior — "unit tests pass" belongs here as a limit, not above as evidence.

Why this format: It (a) gives the reporter a frame-by-frame they can compare against, (b) avoids the JIRA image-collapse failure mode while still working everywhere else, (c) names the most plausible discrepancies up front so the loop short-circuits, (d) explicitly opens the door to being corrected so tickets don't bounce on assumed alignment. The same mechanics that resolve a stuck bug ticket also give QA an unambiguous handoff for a freshly-built feature.