coulomb/frontend-patterns
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Preregister pinned Zulip acceptance and projection study

Browse source 
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0e241-8285-7a63-8c0c-51c9cb824dc3
This commit is contained in:
tegwick 2026-09-27 11:52:05 +02:00
parent 2e9e546dd1
commit ff0c1d4d35
1 changed files with 48 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

48
research/evolution/cycles/2026-09-27-zulip-acceptance.md Normal file
View file

@ -0,0 +1,48 @@
# 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.