A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:06:01Z by majordomus 0.29.0. Nothing on this page is read again. See it live
I2124
An event reloaded from disk meets the trust policy in force, and no stamp outruns the clock
Where it stands
devtask.issue- Readiness
- complete completion is recorded and every required evidence token is present
- Status
- DONE
- Can start
- not now
- Milestone
- Milestone status
- ACTIVE
- Wave
0- Waiting on
- none
- Holds back
- none
- Behind it in all
0- Evidence
1of1
Moves
plan.transitionWhat it is
- Objective
- Apply the same trust predicate to events reloaded from the journal file as to events arriving over a link, and refuse an event whose Lamport stamp is further ahead of the receiver's clock than a declared bound.
- Why
- The runtime pack's baseline audit (2026-10-09, at 1fb8d6be44) found journal.rs:1419 reloading the persisted journal with an accept-everything trust closure beside a comment saying reloaded events pass the same checks as received ones. A key withdrawn from trust.allow had its events, claims and handovers return on the next restart. The same audit found journal.rs:1952 accepting any Lamport stamp, so one trusted key could advance every runtime's clock to u64::MAX.
- Now
- Reload trusts every origin; ingest accepts any stamp.
- Wanted
- Cooperation::new opens the journal through Journal::open_trusting with the trust definition the live path uses (key_trust, one function); refused reloads are counted in Journal::reload_report and logged. An event more than MAX_LAMPORT_LEAD (2^32) ahead of the receiver's clock is refused as clock_ahead, live or reloaded. A backdated claim, which can still outrank a claim already admitted, is recorded as a limitation in docs/MESH.md and left to the milestone's fencing work.
- Done when
- unknown: the record declares no `completion`
- Risk
- unknown: the record declares no `risk`
Acceptance
- A key withdrawn from the allowlist has none of its events believed from the journal file after a restart, and they are believed again when the key is allowed again
- An event whose stamp is more than MAX_LAMPORT_LEAD ahead of the receiver's clock is refused as clock_ahead, and one within the bound is accepted
- The live path and the reload decide trust through one function
- Validation
cargo test --test mesh_trust_reload --test mesh_cooperation --test mesh_compaction- Evidence required
mesh_trust_reload_red_then_green- Evidence present
mesh_trust_reload_red_then_green
Scope
- Touches
apps/majordomus-cli/src/mesh/journal.rsapps/majordomus-cli/src/mesh/cooperation.rsapps/majordomus-cli/tests/mesh_trust_reload.rsdocs/MESH.md- Not
- unknown: the record declares no `non_scope`
- Depends on
- unknown: the record declares no `depends_on`
- Priority
- p0
- Profile
- implementation
- Parallel safe
- true
- Owner
- unknown: the record declares no `owner`
The work so far
- Branches
- none
- Merged
- none
- Commits
0- Trunk
- master
- Sessions
- none
- Created
- 2026-10-09
- Updated
- 2026-10-15T07:44:18Z
- Started
- 2026-10-15T07:44:00Z
- Verified
- 2026-10-15T07:44:07Z
- Completed
- 2026-10-15T07:44:18Z
Synchronisation
- Adapter
scripts/github-sync- Repository
- unknown: the derived plan's header carries no repository
- External issue
- unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
- State there
- unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
Findings
Nothing is wrong with these records.