frontend-patterns/research/evolution/cycles/2026-09-27-zulip-acceptance.md

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.