Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0e241-8285-7a63-8c0c-51c9cb824dc3
4.1 KiB
LEARN-0016 — Shared acceptance versus local editing in Zulip
Status: preregistered before new source collection. Date: 2026-09-27. Reviewer: Codex, author-model; no independent human validation. Stream: cross-stream (C/D). Comparison group: CD-acceptance-projection-static-v1.
Question and prior
Does the six-question authority/projection aid distinguish local editable message content, remotely accepted shared content and the subsequent displayed representation in a pinned application? Prior: these are separate boundaries; a locally updated view need not establish remote acceptance. A contrary path that treats tentative local content as shared accepted state, or makes rendering placement determine acceptance, would qualify that aid. A coherent path without such contradiction is corroboration, not proof of the full candidate contracts.
Use Zulip revision 5b06fa3d34f28fa01f459fbf3ba053e3c0858e9c: the existing source
family includes shared messages and local drafts, and lets this study connect client
editing with server validation and rendered updates. Prior navigation evidence is not
new independent support. Affected concepts: authority/projection seeds and possible
partial CAND-0005/0007/0008 support; do not automatically update those contracts.
Method and limits
Inspect at most ten substantive primary source files at the pinned revision. Start with message_edit.ts and server message-edit endpoint/action; follow only callers, rendering/event application and tests needed to trace one content-edit acceptance and projection path. Retain hashes, line locators and failed retrievals. Search and path discovery do not supply substantive evidence. Stop expanding when the cap is reached; unresolved concurrency, response-loss and event-order questions stay unknown.
Answer the six questions from AuthorityProjectionComparison.md with source versus interpretation distinguished. Seek local optimistic updates, validation failures, server normalization and response/event ordering that challenge a naive linear submit-then-display account. No app execution, upstream tests, credentials, new runtime fixture, independent recurrence or production-defect claim. No new drafts expected; any evidence change must preserve the published 0.1 baseline.
Budget: 35 active research minutes plus 5 minutes for checks. After this registration commit, start a monotonic clock. Active session time includes retrieval, reading and recording; separately time verification subprocesses and subtract them. No parallel research allocation. Exclude registration and final snapshot/sync administration. If timing is lost record unknown; tokens/cost unknown. One question, one ledger outcome: corroboration, revision or inconclusive, justified by the review.
Close with a review, source manifest, ledger/effort record and evolution snapshot. Record residuals under WP-0003 T01 (or T04 for recovery tests); preserve M1/M2/M3 and human gates. This static protocol is not comparable to documentary or runtime cycles.
Outcome — completed 2026-09-27
Corroboration; see review and source manifest. Ten files, same Zulip family; conditional client echo, server validation/rendering and event replacement support the existing aid without a new candidate or profile change. Unknown response/ event ordering and edit ownership remain live under WP-0003 T01, with receiver/storage fault validation under T04. No full-contract recurrence, human or milestone pass.
Seventeen repository tests passed; evolution, classification and frozen preview checks passed. Source ranges/hash and link review found one out-of-bounds channel.ts locator, corrected with the failed check retained in the manifest/effort receipt. Initial web retrieval returned no source content; substantive inspection began after registration.
One question and one corroboration outcome; no supersession. Measured effort is in the receipt; tokens/cost unknown. Reviewer: Codex, author-model, not independent human. Final receipt/report refresh and snapshot/ sync administration occur after the recorded cutoff.