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 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.

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 via Playwright MCP at the matching viewport. 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. "What would help me confirm" (bug) / "How to QA" (feature) section. Concrete actionable retest steps with the exact selection criteria (e.g., "pick a record whose Status column shows —, not Processing or Pending Review").
7. Explicit invitation to be corrected. End with a line like "If any of the steps I listed are different from what you expected / actually did, please tell me explicitly which step I got wrong." Non-optional — small differences (which record, which device, exact tap order, expected behavior) change everything, and naming the door open short-circuits ticket bounce-loops.
8. Workflow transition is the vendor skill's job, not yours — it'll move the ticket per the configured tracker (JIRA: Reassign to reporter for bug repro / move to the configured review status when one exists, otherwise leave it in ; GitHub: direct → configured after a successful build; Linear: equivalent state). You don't transition manually.

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.