"Shared startup dependencies still couple nominally separate features."
],
"reviewer":{
"name":"Codex",
"role":"author-model",
"independent_human":false
},
"effort":{
"research_minutes":null,
"execution_minutes":null,
"reported_tokens":null,
"cost_usd":null
},
"supersedes":[]
},
{
"id":"LEARN-0009",
"date":"2026-09-26",
"recording":"retrospective",
"stream":"E",
"comparison_group":null,
"question":"Does publication or rollback update every session?",
"previous_belief":"Static source review could not establish loaded/lazy-session behavior.",
"conclusion":"Native-module experiment distinguishes publication, activation and already-bound sessions; artifact retirement breaks old lazy sessions.",
"disposition":"revision",
"affected_patterns":[
"CAND-0017"
],
"evidence":[
"research/reviews/FeatureReleaseExperiment.md"
],
"remaining_uncertainty":[
"No CDN or upstream deployment validation."
],
"reviewer":{
"name":"Codex",
"role":"author-model",
"independent_human":false
},
"effort":{
"research_minutes":null,
"execution_minutes":null,
"reported_tokens":null,
"cost_usd":null
},
"supersedes":[]
},
{
"id":"LEARN-0010",
"date":"2026-09-26",
"recording":"retrospective",
"stream":"E",
"comparison_group":null,
"question":"How do stale activation writers and unfinished drafts constrain updates?",
"previous_belief":"Release experiment left activation conflicts and reload policy unexecuted.",
"conclusion":"Conditional replacement rejects stale writers; explicit reload policies preserve or refuse transition, with schema recheck after navigation.",
"question":"Can a public route preserve selection and complete-document availability across native/enhanced entry, history and HTTP caching?",
"previous_belief":"Native href/GET contracts plus representation-aware routing and cache selection should satisfy this narrow obligation; documentary support lacked runtime checks.",
"conclusion":"Corroborated in pinned htmx fixture: native and history paths work; missing Vary reproduces fragment-as-document reuse in both browsers. Existing obligations stand; no new pattern or promotion.",
"question":"Does enhanced route replacement need explicit continuation and feedback policy that respects changed focus ownership?",
"previous_belief":"Native controls alone do not establish enhanced focus/feedback semantics; delayed responses should respect focus moved to another surviving task. Modal return is not automatically route continuation.",
"conclusion":"Corroborated in 22 cases: raw same-ID link focus survives but this fragment contract leaves stale title and silent failure; authored heading/status policy works and preserves newer search focus. No AT speech or universal heading policy established.",
"question":"Can obsolete history/navigation completions affect newer intent, and does separating completion ownership from focus ownership prevent it?",
"previous_belief":"The single-response continuation policy preserved newer search focus but left competing history/success/error completions unresolved; focus-at-swap alone might not be sufficient.",
"conclusion":"Revise operational guidance: validate navigation ownership before content/URL/title/feedback effects, including stale errors and newer failure, independently of focus permission. Prior policy misses obligations in 12/12 adversarial rows; authored guard meets 12/12. Pause fixture work for independent source contrast.",
"question":"Where does independently developed Zulip scope navigation/search result and focus applicability, and where does our model fail to establish a guarantee?",
"previous_belief":"The authored navigation generation guard protected current-view and focus effects, but independent application recurrence and alternative ownership/cache policies were unverified.",
"conclusion":"Revise guidance toward per-effect applicability: pinned Zulip preserves noncurrent cache data while guarding main selected-view continuations by list identity. Make client-fragment addressability explicit without inferring no-script enhancement. Shared feedback, auxiliary callbacks and deferred focus limit the inference.",
"question":"Do the six authority/projection seeds denote reusable patterns or a mixture of scoped acceptance, projection placement and delivery choices?",
"previous_belief":"Authority is scoped and acknowledgement levels differ, but six seed names lack developed contracts and their projection/delivery relationships are not explicitly compared.",
"conclusion":"Revise the research decision aid to separate scoped acceptance, projection computation and delivery timing with compatibility constraints. Six seed dispositions and two synthetic traces; retain all seeds, zero new drafts or candidate maturity changes.",
"Six living primary documents across four families, not independent full-contract implementations; exact revisions unknown.",
"Synthetic VC-01/02 reasoning is not execution or demonstrated usefulness; authority/merge/storage and phase-specific recovery contracts still need application evidence.",
"Existing candidate profiles unchanged; five prospective groups are not a comparable learning trend."
"question":"Does the six-question authority/projection aid distinguish local editable content, remote shared acceptance and subsequent projection in a pinned application?",
"previous_belief":"Scoped acceptance, projection location and delivery schedule are separate questions with compatibility constraints; a local display need not establish shared acceptance.",
"conclusion":"Corroborated in pinned Zulip content editing: conditional local Markdown echo precedes remote validation; locked optional content checks and server rendering precede save/event scheduling; HTTP and event application are distinct paths. Same displayed object can carry tentative content. No candidate or maturity change.",
"question":"Do Zulip's target-message lookup and anchor-navigation fetch continuation guard against a stale navigation that occurred while the request was in flight, the way the main narrow-fetch continuation (ZN02) does?",
"previous_belief":"ZN07 located both callbacks and noted no visible captured-current-list guard, but did not trace their callers or check test coverage.",
"conclusion":"Traced both continuations to their concrete completion points: process_result calls opts.cont unconditionally, and neither the target-lookup channel.get nor load_messages_around_anchor supplies opts.msg_list, so neither participates in the opt-in list-identity guard that message_fetch.ts implements for other callers. No located test exercises a stale-navigation scenario for either path.",
"Static source trace only; no application, database or upstream test executed, and no race actually reproduced.",
"show() performs its own state reset on entry, so a stale re-entry's externally observable effect is unverified without execution.",
"Second cycle in comparison group B-independent-navigation-source-v1; still short of three comparable cycles, and the workplan's rule against manufacturing cycles to reach that count still applies."
"question":"Which process-recovery obligations can SQLite plus actual Git receive-pack satisfy, and where does object identity fail to supply an operation receipt?",
"previous_belief":"Atomic local intent/outbox updates and stable receiver identity support recovery within explicit transaction, ancestry and retention boundaries.",
"conclusion":"Nine checks corroborate atomic SQLite process recovery, Git replay and server ancestry refusal; split-transaction and fresh-identity negative controls retain the limits. One authored integration, not a full frontend use.",
"question":"Does named organization change constraint/recovery recommendations versus identical guidance under numbered headings on fresh authored variants?",
"previous_belief":"Consumed pilot-01 model adjudication scored 18/24 in each condition; naming benefit and equivalence remain unestablished.",
"conclusion":"The preregistered 12-attempt run produced no retained answers. All six pairs are excluded; no quality comparison or naming conclusion is possible. Endpoint health checks failed inside and outside the sandbox.",
