Repository navigation
Description
Summary
A signed BoardFork record (BoardObject::BoardFork, pkgs/id/src/boards.rs:232-238) belongs to no board's replication set, so fork provenance can never replicate: export_board / replicate_board_from never transfer it, and replica_status_against still reports the replica Complete — the exact silent-lag failure the federation design (#3806) says must never happen.
Evidence (verified this run, main @ 74a872a)
BoardObject::board_ref()returnsNoneforBoardFork(boards.rs:389, grouped withBoardandTheme).board_object_set()(boards.rs:899-935) seeds the set with objects whose hash is the board root or whoseboard_ref() == Some(board), then expands onlyBoard::{forked_from, theme_ref}andTheme::forked_fromdependencies. ABoardForkmatches neither seed rule for its source board nor for its fork board, and no closure step adds it.- Laptop probe (verbatim
boards.rs@ 74a872a, md5e142727a25d638136a27ac9ecfb7c3f9, in~/git/fleet/probe-2026-11-01-laneB-boardsfork/on the laptop): source board + one frontier thread + forked board + a valid signedBoardForkrecord citing the thread as its frontier (graph len = 4). Results:board_object_set(source)contains fork record: falseboard_object_set(fork)contains fork record: falseexport_board(source)len = 2,export_board(fork)len = 2 (of 4 graph objects)replicate_board_from(fork)into a fresh graph: stateComplete, transferred = 2, replica has no fork record;replica_status_againstreports expected=2 / present=2 / missing=0.
- No test in boards.rs constructs a
BoardForkobject at all (the replication tests cover themes, ancestor roots, and listings only), so the gap is untested as well as unfixed.
Secondary, same fix area: the fork's cited source_frontier objects are scoped to the source board, so even the fork board's set omits the frontier content the fork record says it starts from.
Why it matters
The BoardFork record is the only signed statement of a fork's provenance and cited starting frontier. A replica that reports Complete without it presents an incomplete fork history as fully converged — silently, which the module docs explicitly promise not to do ("a lagging replica is never silently presented as current", boards.rs:1012-1023 area / module header).
Acceptance criteria
- A
BoardForkrecord is included in a well-defined board replication set (its fork board's, its source board's, or both — the choice is stated in the module docs), andboard_object_set's dependency closure pulls in everythingvalidate_linksneeds to accept it on a fresh graph (both roots, and the cited frontier objects if the record travels with the fork board). replicate_board_fromtransfers the fork record; a replica of a forked board holds it afterwards.replica_status_againstcan no longer reportCompletefor a graph missing an in-set fork record.- New tests construct a real
BoardFork(none exist today), assert it is in the chosen set(s), and assert end-to-end replication of a forked board including its fork record and cited frontier. - Existing boards tests still pass.
Activity
dezren39 commentedon Nov 1, 2026
🤖 Agent note · filed
BoardObject::board_ref()returnsNoneforBoardFork(pkgs/id/src/boards.rs:389), so a signed fork record matches neither seed rule ofboard_object_set(boards.rs:899-935) for its source or fork board and no dependency-closure step adds it — fork provenance never replicates, yetreplica_status_againstreports the replica Complete. Verified on the laptop with the verbatim boards.rs @ 74a872a (md5 e142727a25d638136a27ac9ecfb7c3f9; probe~/git/fleet/probe-2026-11-01-laneB-boardsfork/): 4-object graph, both exports len 2, fork record in neither set, replica Complete with no fork record. No existing test constructs a BoardFork object.dezren39 commentedon Nov 2, 2026
🤖 Agent note · adopted as Phase 3 of design #4113 — open ruling decided
BoardForkrecord belongs to its fork board's replication set only — not the source board's, not both. Reason, recorded on Design: one signed set, one meaning — BoardGraph's gates hold at insert, projection and replication (pkgs/id) #4113: a source replica does not need to learn it was forked to serve the source, and adding the record to the source's set would flip every source replica toIncompleteover an object about a different board. The closure pulls in the source root and everysource_frontierobject (the record'svalidate_linksarm requires both roots and the frontier's source scope), with frontier objects' own dependencies through the existing closure expansion.replica_status_againstneeds no special case once the record is in the set. Source-side membership is revisited only if a consumer that queries a source for its forks is ever filed (open question on Design: one signed set, one meaning — BoardGraph's gates hold at insert, projection and replication (pkgs/id) #4113).source/design-architect. Existing queued triage packet stands.44 remaining items
dezren39 commentedon Nov 2, 2026
agent-note:v1
event: picked_up
task: 6286 (repo-health-code-pilot, repo-worker-code; OpenChamber scheduled lane ec118cad-0fd3-4652-91c4-27432f2f2efd)
state: claimed via atomic queue claim; first checkpoint records origin=openchamber-scheduled-lane.
fresh_evidence: #4081 OPEN; bound PR #4545 OPEN, branch queue/6286-4081-boardfork-replication, authored by dezren39 (Drew); basic OpenCode metered-provider guard PASS, CodeRabbit skipping. No PR diff/files inspected, worktree untouched.
next: escalate — merge decision is Drew-only on a Drew-owned PR.
agent-note:v1
event: blocked (escalated-to-user)
task: 6286 (repo-health-code-pilot, repo-worker-code; OpenChamber scheduled lane ec118cad-0fd3-4652-91c4-27432f2f2efd)
state: blocked; claim released. PR #4545 is Drew-authored so the worker must never touch or merge it (runbook non-negotiable). Work itself is ready: CI green on the PR head.
fresh_evidence: gh pr checks 4545 — basic guard PASS 15s; PR still OPEN, still Drew-authored.
resume: Drew merges #4545 (fixes #4081); a later lane then completes 6286 as fixed_merged with fresh verification.
labels: queue/blocked, status/blocked, user/escalated; removed queue/parked, status/parked, work/assigned.
dezren39 commentedon Nov 3, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 3, 2026
🤖 Agent note · correction + blocked (escalated-to-user)
user/escalated; its canonical PR fix(id): replicate board fork provenance #4545 is OPEN, authored by dezren39 (Drew), branchqueue/6286-4081-boardfork-replication; checks: basic OpenCode metered-provider guard PASS, CodeRabbit skipping. The work on PR fix(id): replicate board fork provenance #4545 appears ready; the merge decision is Drew's because the PR is Drew-owned — workers must never touch or merge a Drew-owned PR.escalated-to-user. Resume only after Drew merges PR fix(id): replicate board fork provenance #4545 (then a later lane completes task 6286 as fixed_merged with fresh verification) or reassigns ownership.