rivet verify: default marker scan misses crates in a cargo workspace layout (only ./src + ./tests)

[avrabe]

Friction (found dogfooding REQ-228 with the new rivet verify, #559)

From a cargo workspace root, rivet verify <ID> refuses even when a valid
// rivet: verifies <ID> marker exists, because its default scan only looks in
./src and ./tests — which don't exist at a workspace root (crates live in
rivet-core/src/, rivet-cli/src/, …).

Repro (in this repo):

$ rivet verify REQ-228
error: refusing to verify 'REQ-228': no verifying evidence ...
$ rivet verify REQ-228 --scan rivet-core/src --scan rivet-cli/src
  evidence: 1 source `verifies` marker(s) (e.g. rivet-core/src/coverage.rs:906)
modified REQ-228   # works

So the command is correct but its default is wrong for the most common Rust
project shape (a workspace) — including rivet's own. --scan is the workaround.

Suggested fix

Default scan should discover crate source roots in a workspace (e.g. walk
workspace members' src/+tests/, or fall back to a recursive scan rooted at
the project dir) instead of assuming a single-crate ./src+./tests. Keep
--scan as the explicit override.

Low-risk, self-contained; improves the #559 command (REQ-226). Refs REQ-226.

[avrabe]

Triage from the issue-fixing routine (first pass on this issue).

Confirmed against the code. cmd_verify at rivet-cli/src/main.rs:7089 resolves its default scan paths at lines 7116–7128:

let paths: Vec<std::path::PathBuf> = if scan.is_empty() {
    let mut p: Vec<std::path::PathBuf> = ["src", "tests"]
        .iter()
        .map(|d| cli.project.join(d))
        .filter(|c| c.is_dir())
        .collect();
    if p.is_empty() {
        p.push(cli.project.clone());
    }
    p
} else {
    scan.to_vec()
};

So at a workspace root with no top-level ./src or ./tests, the filter(|c| c.is_dir()) strips both candidates, the fallback pushes the project root itself, and scan_source_files then walks the project — but the issue's repro shows that fallback still misses the marker at rivet-core/src/coverage.rs:906. Worth confirming whether scan_source_files/the default ignore set is honouring .gitignore/target/ exclusions in a way that drops the workspace-member paths under the project-root walk. Either way the user-visible behaviour is broken and the fix (workspace-aware default) is right.

There's no ## Acceptance Criteria block on the body, and the routine looks for one matching the kill-criterion shape (#532) before opening a branch. Sketch — feel free to revise / re-scope:

## Acceptance Criteria
- [ ] `rivet verify <ID>` (no `--scan`) succeeds at a cargo **workspace** root when a valid `// rivet: verifies <ID>` marker exists in any workspace member's `src/` or `tests/`. Body's repro (`rivet verify REQ-228` at the rivet workspace root, marker at `rivet-core/src/coverage.rs:906`) succeeds without `--scan rivet-core/src --scan rivet-cli/src`.
- [ ] Default scan resolution at `rivet-cli/src/main.rs:7116` is workspace-aware: when `cli.project` contains a `Cargo.toml` with `[workspace]`, the default `paths` is built from each workspace member's `src/` + `tests/` (resolved via the `members`/`default-members` glob, or by parsing the workspace `Cargo.toml`). When there is no `[workspace]`, behaviour is unchanged (`./src` + `./tests`, then project-root fallback). `--scan` continues to be an explicit override that bypasses both branches.
- [ ] When the project isn't a cargo project at all (no `Cargo.toml`), the current project-root fallback still applies — language-agnostic projects keep working.
- [ ] Regression test in `rivet-cli/tests/` (or wherever `cmd_verify` is tested today) covers the three shapes: (i) single-crate `./src` (today's happy path — no regression), (ii) workspace with members in subdirs (the body's repro — new pass), (iii) no-Cargo.toml project (root-walk fallback — no regression).
- [ ] `cargo test -p rivet-cli` green; `cargo fmt --check` / `clippy --all-targets -- -D warnings` clean; `rivet validate` PASS.
- [ ] Commit trailers: `Fixes: REQ-226` (or a new REQ for the workspace-default behaviour) + `Refs: #574, #559`.
- [ ] **Explicitly out of scope (file separately):** parallel scan across workspace members for speed; respecting custom `[workspace] members = [...]` glob patterns that point outside the conventional `src/`+`tests/` layout (e.g. `examples/`, `benches/`); changing `--scan`'s semantics or the source-marker pattern itself.

The fix is genuinely low-risk and self-contained (parse [workspace], expand members → src+tests, fall back to today's behaviour). Suggest landing as fix/issue-574-workspace-default-scan with the AC checklist above driving the regression tests.

Process side-rail (carried from every recent triage thread): https://pulseengine.eu/blog/ is still down — re-verified at the start of this run: curl -v reports SSL certificate problem: certificate has expired, WebFetch returns HTTP 503. This is the same TLS-expiry symptom that has now gated 30+ consecutive triage routine runs (#350, #420, #422, #431, #436, #456, #468, #479, #482, #488, #490, #500, #508, #509, #516, #522, #523, #530, #532, #538, #543, #546, #547, #548, #549, #550, #552, #554, #555, #556, #557, #567, #573). Until the blog cert is renewed the routine can't read the binding workflow guidance, so any PR opened from this triage would land as a draft pending blog access — consistent with the draft-PR posture on PRs #525, #537, #539, #541 against the same outage. Worth fixing the cert at this point: the routine has spent 30+ cycles producing AC sketches without ever being able to land an implementation.

Not implemented this run.

---

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

---

Generated by Claude Code