failed test to extend with link to pr artifact or remote issues.

[avrabe]

Tests should be extendable to add in links to the tool to track the issue.

[avrabe]

Triage from the issue-fixing routine: clear intent (failed tests should carry links to a tracker — PR / remote issue / etc.) but no explicit "fixed when …" line the routine can verify before opening a PR, so it's deferred until one is added.

The format I look for matches #532's kill-criterion. For this one a useful shape might enumerate (a) where the link lives on the artifact, (b) which kinds of trackers are first-class, and (c) what the rendered surface (test failure output / dashboard / report) does with it. Sketch — feel free to revise:

## Acceptance Criteria
- [ ] `*-verification` (and/or `*-test`) artifacts gain an optional `tracker:` field — list of `{kind, ref, url}` entries (kinds at least: `pr` for `pulseengine/<repo>#NNN`, `issue` for the same, `url` for an opaque link). Schema change in `common.yaml` (or the relevant verification schema).
- [ ] `rivet validate` accepts the new field and round-trips it (no undeclared-field warnings); a known-bad ref (e.g. `pulseengine/rivet#nope`) is allowed but a `warning:` diagnostic flags it for surfacing.
- [ ] When a verification reports failure (in CLI output / dashboard / static export), the linked tracker entries render as clickable links next to the failure. Verified by a golden-file test on a fixture with one failing verification carrying both a `pr` and an `issue` tracker.
- [ ] `rivet list` / `rivet trace` show tracker links inline on relevant artifacts (or at least under `--verbose`).
- [ ] `cargo test`, `cargo fmt --check`, `clippy --all-targets -- -D warnings` clean; `rivet validate` PASS on the rivet repo unchanged.
- [ ] Commit trailer: `Implements: REQ-NNN` (file a new REQ for "failed-verification tracker links") + `Refs: #548`.
- [ ] **Explicitly out of scope (file separately):** auto-creating a remote issue/PR when a verification fails (that's an orchestration posture, not a metadata shape); auto-closing the tracker entry when the verification flips to pass (lifecycle automation — separate UX call).

Process side-rail (carried from every recent triage thread): https://pulseengine.eu/blog/ is still HTTP 503 (the long-standing site-infra symptom flagged on #420, #468, #456, #436, #431, #422, #479, #482, #488, #490, #500, #508, #509, #516, #522, #523, #530, #532, #538, #543 — re-verified at the start of this run). The binding workflow guidance can't be consulted, so no PR will land from this triage regardless. Comment is the AC ask only.

Not implemented this run.

---

Generated by Claude Code — issue-triage agent run 2026-06-19.

---

Generated by Claude Code

[avrabe]

Triage (scheduled run): one-line body, no acceptance criteria — not implementable as written. Holding.

The current ticket is ambiguous on at least three axes; please pick a shape and add an ## Acceptance Criteria block:

1. Which artifact gets the link? A *-verification artifact, or the test-result/runtime-evidence import (rivet import-results)?
2. What does "link" mean? A free-form URL field, a typed link (refs to a defect-against/ai-found-defect), or a structured pointer ({tracker: github, id: 548})?
3. Who writes it? The test runner via a CI hook, the human triaging the failure, or both?

Example AC:

## Acceptance Criteria
- [ ] `sw-verification` / `unit-verification` schemas declare a `tracker-refs:` list-of-{tracker, url, id} field (drift-checked like `cited-source`)
- [ ] `rivet validate` flags `failed` status without at least one `tracker-refs` entry (severity: warning)
- [ ] CLI: `rivet modify <FV-ID> --add-tracker-ref github://pulseengine/rivet/548` round-trips through YAML cleanly
- [ ] Dashboard renders tracker refs as clickable links in the verification artifact view

— rivet triage (Claude Code, scheduled)

---

Generated by Claude Code