id(boards): Rules revision numbers are not unique per board — two different revision-1 rule texts coexist in one graph

Bug

Nothing in BoardGraph keeps a board's Rules revision numbers unique. Two different Rules objects for the same board can both claim revision: 1 (different text, different hashes) and both are accepted into the graph, leaving the board with two competing "revision 1" rule texts and no graph-level way to say which one is the board's rules at that revision.

Evidence (verified this run, main @ `e860d3a`)

pkgs/id/src/boards.rs:82-92 — Rules { board, revision, text }, with revision documented as "One-based revision number within this board."
pkgs/id/src/boards.rs:326-329 — validate_shape checks only revision > 0.
pkgs/id/src/boards.rs:482-484 — the BoardObject::Rules arm of validate_links checks only moderator authority (require_moderator); no uniqueness or monotonicity check against existing rules for the board.
Laptop probe ~/git/fleet/probe-2026-11-01-laneB-boards/ (verbatim boards.rs, sha256 bcc08b3e… matching the repo file @ e860d3a): inserting owner-signed Rules revision 1 "Be kind" and then a second, different owner-signed Rules revision 1 "Be kind, and no spam" for the same board → both accepted (graph len 3: board + 2 rules). A moderator holding a grant can likewise shadow the owner's revision text with their own same-revision object.

Why it matters

Threads pin rules by object hash (Thread.rules_ref), so pinned references stay exact — but any "current rules" or "rules at revision N" projection (the board-view layer, #2813) has no deterministic answer when two objects claim the same revision: the result depends on which object the projection happens to pick, i.e. on arrival/iteration order. That is exactly the arrival-order nondeterminism this module already rejects for role acceptance (see the has_role design note in boards.rs): peers holding the same signed set must reach the same verdict. Duplicate revisions break that property for the board's most-read object.

Acceptance criteria

One of the following is implemented and documented in the module:
- (a) BoardGraph::insert rejects a Rules object whose (board, revision) is already claimed by a different object in the graph; or
- (b) duplicate revisions are explicitly documented as legal, together with the deterministic rule projections must use to resolve them (and the resolution does not depend on arrival order).
A regression test pins the chosen behavior: a second distinct revision-1 Rules object for the same board is rejected (option a) or resolves deterministically regardless of insertion order (option b).
All existing boards tests still pass.

🤖 Agent note · filed

Agent: new-issue-creator-code-b
Session / ID: cron job new-issue-creator-code-b, run 2026-11-01 14:20 CST
Found via: filed this run
Task: Make a board's Rules revision numbers unambiguous in BoardGraph — either reject a second distinct Rules object claiming an already-used (board, revision), or document duplicate revisions with a deterministic, arrival-order-independent projection rule — and pin the chosen behavior with a regression test.
Expectation: effort/s — done when the acceptance criteria on this issue pass.
Links: evidence in the issue body; laptop probe at ~/git/fleet/probe-2026-11-01-laneB-boards/ (verbatim boards.rs, sha256-matched @e860d3a9; two different revision-1 rules texts both accepted for one board).

🤖 Agent note · adopted as Phase 2 of design #4113 — open ruling decided

Agent: design architect (repo-design-architect-code), pass 35
Task: This issue is Phase 2 (with id(boards): compose_view applies supersedes edges from superseded attestations — a nullified revocation still revokes #4003) of design Design: one signed set, one meaning — BoardGraph's gates hold at insert, projection and replication (pkgs/id) #4113 (one signed set, one meaning — BoardGraph's gates). Triage: do NOT re-file, re-scope or split it; record the phase structure instead.
Ruling recorded on Design: one signed set, one meaning — BoardGraph's gates hold at insert, projection and replication (pkgs/id) #4113 (this issue's option (b)): duplicate (board, revision) Rules objects are legal signed history — insert rejection (option (a)) is NOT the design. Reason, recorded on Design: one signed set, one meaning — BoardGraph's gates hold at insert, projection and replication (pkgs/id) #4113: Rules has no supersedes chain and plural authorised signers (owner + moderators via require_moderator), so first-arriver-wins rejection makes acceptance depend on arrival order — the property the module's has_role note rejects — and a graph holding both would stall replication. Instead this phase documents the rule in the module and exposes one graph resolution helper: for a given revision the greater content hash wins (the latest_listings signed-fork tie-break); "current rules" is the highest revision resolved the same way; pinned by an insertion-order-independence test. Threads' hash-pinned rules_ref is unaffected. Note the contrast with id(boards): a second 'first' BoardListing (v1, supersedes=None) is accepted for the same host — publication state falls to the content-hash tie-break #4109 (Phase 1): listings ARE rejected at insert because their single-author chain makes "first" structural.
Outcome: Linked as a sub-issue of Design: one signed set, one meaning — BoardGraph's gates hold at insert, projection and replication (pkgs/id) #4113; labelled source/design-architect. Existing queued triage packet stands.
Links: Design: one signed set, one meaning — BoardGraph's gates hold at insert, projection and replication (pkgs/id) #4113, id(boards): compose_view applies supersedes edges from superseded attestations — a nullified revocation still revokes #4003, id(boards): a second 'first' BoardListing (v1, supersedes=None) is accepted for the same host — publication state falls to the content-hash tie-break #4109, Phase 4 (audit) of #4113 — closing kind-by-gate inventory for pkgs/id boards #4114

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane L shift
Session / ID: task 8831
Found via: queue claim
Task: task 8831 (small_fix implementing id(boards): Rules revision numbers are not unique per board — two different revision-1 rule texts coexist in one graph #3964, deterministic BoardGraph Rules revision resolution) is assigned to the opencode execution lane; handing off to the laptop opencode claimant.
Expectation: claimant launches the bound opencode session, which drives task 8831 to its terminal state.
Links: issue id(boards): Rules revision numbers are not unique per board — two different revision-1 rule texts coexist in one graph #3964

🤖 Agent note · handed off

Agent: fleet monitor (repo-fleet-monitor)
Session / ID: task 8831
Found via: monitor reconciliation
Task: claim-evaporated repair — the queue claim on task 8831 ended without complete/park/block, its lease expired, and the task returned to queued unclaimed while this issue still carried claimed labels. Labels reset to the truth: queue/queued + status/needs-triage. Checkpoint stage at evaporation: handed_off.
Expectation: the next lane to claim task 8831 posts a fresh pickup note.

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-j
Session / ID: task 8831
Found via: queue claim
Task: Implement id(boards): Rules revision numbers are not unique per board — two different revision-1 rule texts coexist in one graph #3964: deterministic BoardGraph Rules revision resolution handed off to the opencode execution lane per task 8831 lane assignment (assigned_lane=opencode, session_id null)
Expectation: claimant launches the bound opencode session; that session drives task 8831 to its terminal state

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-a
Session / ID: task 8831, repo-queue-worker-shift 2026-11-04 06:40 CST
Found via: queue claim
Task: Implement id(boards): Rules revision numbers are not unique per board — two different revision-1 rule texts coexist in one graph #3964 deterministic BoardGraph Rules revision resolution — assigned execution lane opencode, handing off to the laptop claimant
Expectation: effort/s; claimant launches the bound opencode session, which drives task 8831 to a terminal state
Links: issue id(boards): Rules revision numbers are not unique per board — two different revision-1 rule texts coexist in one graph #3964

Navigation Menu

Repository navigation

id(boards): Rules revision numbers are not unique per board — two different revision-1 rule texts coexist in one graph #3964

Bug

Evidence (verified this run, main @ `e860d3a`)

Why it matters

Acceptance criteria

45 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

id(boards): Rules revision numbers are not unique per board — two different revision-1 rule texts coexist in one graph #3964

Description

Bug

Evidence (verified this run, main @ e860d3a)

Why it matters

Acceptance criteria

Activity

dezren39 commented on Nov 1, 2026

dezren39 commented on Nov 2, 2026

45 remaining items

dezren39 commented on Nov 4, 2026

dezren39 commented on Nov 4, 2026

dezren39 commented on Nov 4, 2026

dezren39 commented on Nov 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Evidence (verified this run, main @ `e860d3a`)