erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

docs: close #314 in the issue log (fixed by daef7c98)

Browse source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Erik 2026-08-04 16:49:31 +02:00
parent daef7c9835
commit b260bcd12c
1 changed files with 18 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

22
docs/ISSUES.md
View file

@ -26,9 +26,12 @@ What does NOT go here:
## C4 route 6 — drops and split-recovery closure — 2026-08-04
#313 and #314 filed from the route 6 closure session (zero production lines;
evidence + coverage tests only). #315 filed from the same session, carried
over from the route 4b-3 round-2 reviews. Evidence:
#313 filed from the route 6 closure session (zero production lines; evidence +
coverage tests only). #314 was filed from the same session and CLOSED the same
day by `daef7c98` — it was found by those coverage tests, in the exact
mechanism route 6's scoping cited as evidence that drops already converge, and
was split out into its own commit rather than carried. #315 also filed there,
carried over from the route 4b-3 round-2 reviews. Evidence:
[`2026-08-04-c4-route-6-contract.md`](research/2026-08-04-c4-route-6-contract.md),
[`2026-08-04-c4-routes-6-7-scoping.md`](research/2026-08-04-c4-routes-6-7-scoping.md).
@ -74,7 +77,18 @@ makes the landing un-reviewable (per the route 6 contract).
## #314 — Split recovery throws instead of recovering when the source's retained Movement/ServerControlledMove timestamps are nonzero
**Status:** OPEN
**Status:** CLOSED 2026-08-04 by `daef7c98` — `BuildSpawn`'s `Timestamps`
`with` block now resets `Movement` / `ServerControlledMove` to 0 alongside the
top-level `MovementSequence` / `ServerControlSequence` zeroing that was already
there. Zero is the honest value (a fresh split GUID has no movement history by
construction), NOT a loosening of
`HasConsistentCreateIdentityAndParent` — the predicate was correct and the
producer was wrong. The repro test is renamed
`SplitSourceWithRetainedMovementTimestamps_StillRecovers` and asserts the
channels are zero in BOTH projections, so it cannot pass against a
lenient-predicate workaround. Sabotage-verified in both directions.
**Status when filed:** OPEN
**Severity:** MEDIUM (can turn a normal split-to-ground into a client
exception instead of a placed item)
**Filed:** 2026-08-04