rivet next-id allocates from the local working tree only — hands out IDs already claimed by open PRs/branches (logical collision, distinct from #422)

[avrabe]

Friction (hit while dogfooding the hourly loop)

rivet next-id allocates the next ID by scanning only the current working tree, so in any multi-branch / parallel-PR workflow it silently hands out IDs that are already claimed by in-flight branches — producing two different artifacts with the same ID.

Reproduced just now (verified)

This loop has three open PRs that each added a requirement: #474 (REQ-201), #475 (REQ-202), #477 (REQ-203) — none merged yet, so none are on main. A fresh agent branching off main asks for the next ID:

$ git checkout main      # main's requirements.yaml ends at REQ-200
$ rivet next-id --type requirement
REQ-201                  # ← already live in open PR #474

So the agent files its REQ-201, and now two PRs define different REQ-201s. They don't even textually conflict if they land in different files — validate would later flag a duplicate ID, or worse, one silently shadows the other after a merge. I only avoided it this iteration by manually tracking that 201–203 were taken and jumping to REQ-204.

Why this is distinct from #422

#422 is about textual merge conflicts (same EOF lines in CHANGELOG.md / requirements.yaml). This is about ID allocation: next-id confidently returns a colliding ID with no warning, even when there would be no textual conflict (e.g. the two artifacts live in different files). Fixing #422 (per-artifact files, a merge driver) would not fix this — next-id would still hand out REQ-201 to a second branch.

Related: #447 (next-id must scan all files) fixed the intra-tree half; this is the cross-branch half.

Suggested fixes (pick per appetite)

1. Warn loudly: rivet next-id and rivet add could check unmerged refs — e.g. git log --all -G'id: <PREFIX>-' or the IDs present on origin/* PR branches — and print note: REQ-201 is also claimed on branch fix/...; next free across all refs is REQ-205.
2. --across-refs flag (opt-in, git-aware): compute the max ID across git for-each-ref blobs, not just the working tree.
3. Reservation ledger: a tiny append-only .rivet/reserved-ids (or a rivet reserve REQ) that agents bump atomically; cheap and merge-friendly (append-only with union merge).
4. Documentation stopgap: AGENTS.md could tell parallel agents to allocate disjoint ID ranges per worktree.

Option 1 (a warning) is the cheapest high-value step — it turns a silent collision into a visible one. Reported from the hourly dogfooding loop; verified against rivet next-id at 970cea1.

[avrabe]

Triage pass — premise confirmed against main:

• rivet next-id (and rivet add, which uses the same allocator) currently scans the working tree only. Cross-checking unmerged refs / open-PR branches isn't part of the lookup. So the reproduction in the body is exact: with main's requirements.yaml ending at REQ-200 and fix(export): node-budget the single-page graph render so it can't hang (REQ-201) #474/docs(agents): "Before You Push (Rust)" guidance + REQ-202 (minimal build) — issues #438, #456 #475/feat(add): rivet add stamps AI provenance at creation (REQ-203, closes #476) #477 claiming REQ-201/202/203 only on their branches, rivet next-id --type requirement confidently returns REQ-201 — a guaranteed logical collision against fix(export): node-budget the single-page graph render so it can't hang (REQ-201) #474. This is genuinely distinct from Parallel PRs serially conflict in CHANGELOG.md + artifacts/requirements.yaml (every REQ/changelog addition collides) #422 (Parallel PRs serially conflict in CHANGELOG.md + artifacts/requirements.yaml (every REQ/changelog addition collides) #422 is the textual-merge half; this is the ID-allocation half — fixable independently). Related: Hard to find the next free artifact ID — IDs span many files, so a single-file scan collides #447 (next-id must scan all files) closed the intra-tree half; this is the cross-branch half.
• The body offers four separable fixes (loud-warning via git log --all, an opt-in --across-refs flag, a .rivet/reserved-ids ledger, docs-only ID-range partitioning) at very different blast radii — option 1 is a one-shot diagnostic, option 3 is a new on-disk state file with merge semantics, option 4 is docs. The "one PR per issue, keep PRs focused" rule means picking which lands first is a maintainer call.

Could you lift the chosen slice into an explicit ## Acceptance Criteria block so this is autonomously pickup-able? Sketch for what looks like the cheapest high-value start (option 1, the loud warning — your own body's "cheapest high-value step"); replace if you'd rather start elsewhere:

## Acceptance Criteria — first slice (option 1: loud warning)
- [ ] `rivet next-id` (and `rivet add` when no explicit `--id` is given) computes the max claimed ID by scanning both (a) the working tree (existing behavior) AND (b) IDs present on local refs reachable from `refs/remotes/origin/*` (e.g. via `git log --all --pretty=format: -G '^id: <prefix>-'` on the artifact files, or `git for-each-ref` walking blobs of `artifacts/<type>s.yaml`). The cross-ref pass is best-effort: if the project isn't a git repo, or the git invocation fails, fall back to working-tree-only with a single one-line note (no hard error)
- [ ] When the working-tree next-id is *also* claimed on an unmerged ref, the command prints (to stderr, not the captured stdout ID) `note: REQ-NNN is also claimed on branch <ref>; next free across all refs is REQ-MMM` and *returns the cross-ref-free ID* (REQ-MMM) — i.e. the warning is the side-effect, the returned ID is collision-free. `rivet add` (with no explicit `--id`) uses the cross-ref-free ID by default; stdout for `rivet next-id` is the cross-ref-free ID, byte-for-byte parseable by scripts
- [ ] Opt-out flag `--no-cross-refs` restores the current working-tree-only behavior (escape hatch for CI / offline / huge histories where the git walk is too slow)
- [ ] Regression test: fixture project with a working-tree REQ count of N and a stubbed git env exposing a branch with REQ-(N+1) → `next-id` returns REQ-(N+2) and the stderr warning fires; with `--no-cross-refs` returns REQ-(N+1) and no warning
- [ ] Performance: cross-ref scan caps at the artifact YAML files (not the whole repo history); on the rivet repo itself the added latency is < 200 ms (recorded in the PR description)
- [ ] **Explicitly out of scope (file separately if wanted):** option 2 (`--across-refs` as opt-in only, leaving the default unchanged), option 3 (`.rivet/reserved-ids` ledger — different on-disk shape + merge semantics), option 4 (docs-only ID-range partitioning); the intra-tree half remains covered by #447
- [ ] Commit trailers: `Implements: REQ-NNN` (file a new REQ for cross-ref ID allocation) + `Refs: #422, #447, REQ-204`
- [ ] `rivet validate` PASS unchanged; `cargo test -p rivet-core -p rivet-cli` green; `cargo fmt --check` / `clippy --all-targets -- -D warnings` clean

If you'd rather start with option 3 (the ledger), the AC shape is different — .rivet/reserved-ids needs an append-only file format, a rivet reserve <type> command, union-merge in .gitattributes, and the loader logic to consult the ledger as the source of truth instead of (or in addition to) the artifact files. Say which and I'll re-shape.

Process side-rail (same as the other open triage threads this week): https://pulseengine.eu/blog/ is still HTTP 503 — same expired-TLS symptom flagged on #420 and noted in earlier triage comments on #468 / #436 / #431 / #422 / #408. The binding workflow guidance can't be consulted, so no PR will land from this triage run regardless. Comment is the AC ask only.

Not implemented this run.

---

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

---

Generated by Claude Code

[avrabe]

Concrete new instance of this from the dogfooding loop — and it extends the root cause beyond open PRs/branches to reverted ids that survive in git history.

This iteration I needed a new requirement id. The state on main:

• Max real artifact id was REQ-208.
• REQ-209 had been used then reverted (fix(cli): --project/--schemas global so they work in any position (REQ-209, closes #500) #501 implemented it, fix(cli): revert --project/--schemas global (broke main; clap + positional subcommands) #502 reverted it) — so it's absent from artifacts/ but still referenced in merged commit trailers (c6b57d6, d688bc3, e94ac95).

rivet next-id requirement computes max(current artifact ids) + 1, so on main it would have returned REQ-209 — re-handing-out the burned id and silently colliding with the reverted artifact's commit history. I had to manually skip to REQ-210 because I happened to know 209 was burned.

(Credit where due: next-id already correctly ignores prose mentions like the REQ-99999 fixture in mythos-silent-failure-findings.yaml — it only counts real id: fields. So the naive grep -roE 'REQ-[0-9]+' approach is actually worse than the tool here. The gap is purely the history dimension.)

Suggested fix refinement (on top of the PR/branch scan already proposed here): next-id should treat an id as "claimed" if it appears as an artifact id or in any commit-trailer in git log (Implements/Fixes/Verifies/Satisfies/Refs), so a reverted id is never reissued. Cheap approximation: git log --format=%B | grep -oE '(REQ|FEAT|DD|...)-[0-9]+' unioned with the working-tree ids, then max+1. Keeps allocation monotonic across the project history, not just the current tree.