#128 - Pinky JJJJ: the anchor-timestamp alignment — one message, one time (v1.93.0) - OSS-Singularity/zcode-dispatch-observatory - oss-oo

ClaudiuSchuster commented

2026-10-16 16:26:15 +00:00

Owner

Owner finding #31 (the observatory half; the dispatcher half is zcode-dispatch v1.0.54): a delivered steer showed TWO times — the chat row timestamp (the transcript write moment) beside the #33 hovertext reading a different delivered stamp. Since v1.93.0 the row normalizes to the anchor's own delivered token (in-band, no ledger correlation):

exact by construction under the dispatcher's delivered:=transcript-write semantics; in agreement with the hovertext under older dispatchers;
honest fallback both directions (no anchor / unreadable stamp → the row's own time, unchanged);
the dateless HH:MM:SS±ZZZZ token resolves against the nearest calendar day (midnight crossings land correctly);
completes the #33 split for the live anchor shape — the position N of M · turn-state at send: … tail segments are part of the same record line and hide with it.

Rig: tests/test_round_jjjj.py (stamp parser units incl. rollover both directions; split on the live tail shape + AAAA compat; the G1 render rig — both surfaces agree to the second, divergent-leg normalization proven real, fallbacks byte-for-byte). Full canonical suite 1606 OK; Super-Linter green on the final tree (BASH, BASH_EXEC, MARKDOWN, PYTHON_PYLINT, PYTHON_RUFF).

Owner finding #31 (the observatory half; the dispatcher half is zcode-dispatch v1.0.54): a delivered steer showed TWO times — the chat row timestamp (the transcript write moment) beside the #33 hovertext reading a different delivered stamp. Since v1.93.0 the row normalizes to the **anchor's own delivered token** (in-band, no ledger correlation): - exact by construction under the dispatcher's delivered:=transcript-write semantics; in agreement with the hovertext under older dispatchers; - honest fallback both directions (no anchor / unreadable stamp → the row's own time, unchanged); - the dateless `HH:MM:SS±ZZZZ` token resolves against the **nearest calendar day** (midnight crossings land correctly); - completes the #33 split for the live anchor shape — the `position N of M · turn-state at send: …` tail segments are part of the same record line and hide with it. Rig: `tests/test_round_jjjj.py` (stamp parser units incl. rollover both directions; split on the live tail shape + AAAA compat; the G1 render rig — both surfaces agree to the second, divergent-leg normalization proven real, fallbacks byte-for-byte). Full canonical suite 1606 OK; Super-Linter green on the final tree (BASH, BASH_EXEC, MARKDOWN, PYTHON_PYLINT, PYTHON_RUFF).

ClaudiuSchuster added 1 commit

2026-10-16 16:26:15 +00:00

Pinky JJJJ: the anchor-timestamp alignment — one message, one time (v1.93.0)

Checks / Functional checks (pull_request) Successful in 19s

Details Explain this check

bb00d0718d

Owner finding #31: a delivered steer's chat row showed the transcript
write moment while the #33 hovertext showed the anchor's delivered
stamp — two truths for one message. The row's displayed timestamp now
normalizes to the anchor's own delivered token (in-band, no ledger
correlation): exact by construction under the dispatcher's
delivered:=transcript-write semantics (zcode-dispatch v1.0.54+), in
agreement with the hovertext under older dispatchers. No anchor or an
unreadable stamp falls back to the row's own time unchanged. The
stamp parser resolves the dateless HH:MM:SS±ZZZZ token against the
nearest calendar day (midnight crossings land on the correct day).
The same round completes the #33 split for the live anchor shape —
the position/turn-state tail segments after the delivered token are
part of the same record line and hide with it.

ClaudiuSchuster merged commit 49bccfe537 into main

2026-10-16 16:26:54 +00:00

ClaudiuSchuster referenced this pull request from a commit

2026-10-16 16:26:55 +00:00

Pinky JJJJ: the anchor-timestamp alignment — one message, one time (v1.93.0) (#128)

Rows
Columns

Pinky JJJJ: the anchor-timestamp alignment — one message, one time (v1.93.0) #128