rivet verify: default scan misses member-crate markers when the repo root has its own src/ or tests/ (mixed workspace)

[avrabe]

Follow-up to #574 (the workspace-scan fix) — the edge case noted on that PR, now hit in practice.

rivet verify's default marker scan falls back to a recursive project-root scan only when neither ./src nor ./tests exists at the root (the pure-workspace case #574 fixed). But rivet's own repo root has a tests/ directory, so the fallback does not trigger — the default scan looks only at root ./src+./tests and never recurses into rivet-cli/tests/, rivet-core/tests/, etc.

Hit while dogfooding REQ-232: rivet verify REQ-232 refused ("no verifying evidence") despite a // rivet: verifies REQ-232 marker in rivet-cli/tests/cli_commands.rs. rivet verify REQ-232 --scan rivet-cli/tests found it immediately and advanced the artifact.

Fix direction: when the project is a cargo workspace (root Cargo.toml has [workspace]), the default scan should discover member-crate src/+tests/ (or just always recurse from the project root, deduped with the root ./src/./tests), not stop at the root dirs. Keep --scan as the explicit override.

Low-risk, self-contained; affects every workspace-with-a-root-tests-dir project, including rivet itself. Refs #574, REQ-226.

[avrabe]

Triage from the issue-fixing routine (first pass — issue created today).

The body already has a clear repro (rivet verify REQ-232 in this repo, root tests/ blocks the #574 fallback, rivet-cli/tests/cli_commands.rs carries the marker), a clear root-cause (fallback only fires when neither ./src nor ./tests exists at the root), and a clear fix direction ("when the root is a cargo workspace, the default scan should discover member-crate src/+tests/, deduped with the root dirs"). Implementation-ready — just missing the ## Acceptance Criteria bullets the routine looks for before opening a branch.

Suggested shape (matching the #574 / #532 kill-criterion pattern — drop in or revise):

## Acceptance Criteria
- [ ] When the project root's `Cargo.toml` declares `[workspace]`, `rivet verify <REQ>` (no `--scan`) walks each member crate's `src/` and `tests/` (deduped with the root `./src` + `./tests` if present) before reporting "no verifying evidence". The pure-workspace fallback from #574 keeps working unchanged.
- [ ] Regression repro from the body: in this repo (rivet — workspace root with `tests/`), `rivet verify REQ-232` *without* `--scan` finds the `// rivet: verifies REQ-232` marker in `rivet-cli/tests/cli_commands.rs` and advances the artifact, matching the behavior of `rivet verify REQ-232 --scan rivet-cli/tests`.
- [ ] `--scan <path>` is unchanged as an explicit override (still wins over the auto-discovered set).
- [ ] Non-workspace projects (no `[workspace]` table in root `Cargo.toml`) keep the existing root-only default — no behavior change there.
- [ ] Member-crate enumeration honors `[workspace].members` (incl. glob entries like `crates/*`); members excluded via `[workspace].exclude` are skipped.
- [ ] `cargo test -p rivet-cli` green for the new fixture; `cargo fmt --check` + `cargo clippy --all-targets -- -D warnings` clean; `rivet validate` on this repo's own artifacts PASS unchanged.
- [ ] Commit trailer: `Fixes: REQ-226` (the workspace-scan requirement per the body) + `Refs: #603, #574`. (REQ-232 is the verification requirement that *surfaced* the gap — swap the primary trailer if the right anchor is elsewhere.)
- [ ] **Explicitly out of scope (file separately):** recursing into non-workspace nested manifests; auto-discovering test sources outside `src/` and `tests/` (e.g. `benches/`, `examples/`); changing the marker-comment grammar itself.

This is a self-contained, low-risk fix once AC lands — single-direction code change in the marker-scan path, plus a fixture mirroring the rivet-repo structure (workspace root with a top-level tests/ directory plus member-crate test files).

Process side-rail (carried from every recent triage thread): https://pulseengine.eu/blog/ is still HTTP 503 — re-verified twice in this run (initial fetch and a post-audit re-check, both returned HTTP 503 from WebFetch / agent-proxy). Same long-standing site-infra symptom flagged across 30+ consecutive routine runs (rolling enumerated set as of last pass: #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, #577). The binding pre-PR workflow guidance can't be consulted, so any rivet-side PR for #603 would land as a draft pending blog access — consistent with the posture on PRs #525, #537, #539, #541 and the still-open #599 (drafted with the same blog-down rationale).

Not implemented this run.

---

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

---

Generated by Claude Code