Record first authority investigation and preserve failed live-run evidence

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9

research/cases/CarniatoGrandUnifyingArchitecture.md

@@ -1,79 +1,25 @@
-# Case Study — The Grand Unifying Architecture of Frontend
+# Carniato source review — authority and feedback
 
-Status: initial research stub
+Status: extracted; initial manual review, 2026-09-24, codex (self-review).
+Source: SRC-0001, Ryan Carniato, [original article](https://dev.to/playfulprogramming/the-grand-unifying-architecture-of-frontend-bhk).
+Edition and date uncertainty: see the source catalog. No API-generated findings.
 
-Source:
-Ryan Carniato, "The Grand Unifying Architecture of Frontend".
+| Claim | Original locator | Source statement, paraphrased | Our interpretation |
+| --- | --- | --- | --- |
+| C01 | Core Responsibilities, Content, paragraph 1 | Content authority resides on the server. | Authority placement is an assumption of this model. |
+| C02 | Core Responsibilities, Affordances, paragraph 1 | Interaction feedback should precede a server round trip. | Local feedback need not imply local authority. |
+| C03 | Content: Reactive reads over the wire, final paragraph | The live graph must be reconstructible from durable state. | Projection state and durable authority should be distinguished. |
 
-## Why this source matters
+C03 was checked manually in the original; it is outside the bench excerpt.
 
-The article attempts to unify several modern frontend architectures beneath framework-specific terminology.
+## Limits and counterexample
 
-Its most useful conceptual move is the decomposition:
+The article's universal framing is broader than this review supports. Local-first
+primary data challenges mandatory server authority; it does not refute separating
+responsibilities. Framework implementation claims and examples were not executed.
 
-```text
-Navigation → Content → Affordance
-```
+## Disposition
 
-with a characteristic movement:
-
-```text
-client → server → client
-```
-
-for server-authoritative applications.
-
-## Initial interpretation
-
-### Navigation
-
-Contains aspects of:
-
-- addressability,
-- routing,
-- user intent,
-- mutation initiation.
-
-### Content
-
-Contains aspects of:
-
-- authority,
-- server-side state,
-- projection.
-
-### Affordance
-
-Contains aspects of:
-
-- local interaction state,
-- speculative state,
-- immediate feedback.
-
-## Main qualification
-
-The model strongly fits server-authoritative web applications.
-
-It should not be promoted unchanged into the general canon because:
-
-- local-first systems may treat local data as primary,
-- replicated systems may have multiple authorities,
-- peer-to-peer systems may lack a distinguished server,
-- microfrontend concerns cut across this axis,
-- internal modularity is largely orthogonal to it.
-
-## Research tasks
-
-- extract concrete architecture examples from the article,
-- identify all implicit assumptions,
-- map each example to responsibility dimensions,
-- identify candidate patterns,
-- compare against:
-  - local-first,
-  - HTMX/hypermedia,
-  - SPA,
-  - server components,
-  - islands,
-  - LiveView-style persistent server interaction,
-- identify where the model is descriptive versus normative,
-- determine which concepts should enter the canon.
+Retain Server Authority and Immediate Feedback as candidates. Do not infer a
+requires edge between them. Recurrence and failure behavior need further evidence.
+Broader architecture comparisons remain open under FEP-WP-0002-T02/T03.

research/cases/LocalFirstAuthority.md

@@ -0,0 +1,25 @@
+# Local-first source review — authority placement
+
+Status: extracted; initial manual review, 2026-09-24, codex (self-review).
+Source: SRC-0002, Kleppmann, Wiggins, van Hardenberg and McGranaghan,
+[April 2019 web essay](https://www.inkandswitch.com/essay/local-first/).
+Conference DOI: 10.1145/3359591.3359737. No API-generated findings.
+
+| Claim | Original locator | Source statement, paraphrased | Our interpretation |
+| --- | --- | --- | --- |
+| C01 | Seven ideals, paragraph 3 | The device's data copy becomes primary rather than subordinate to a server. | Local Authority differs from caching. |
+| C02 | Ideal 3, paragraph beginning Since local-first applications | Local reading/writing can continue offline; synchronization follows connectivity. | Commit location and synchronization timing are separate decisions. |
+| C03 | Introduction, paragraph beginning The software we are talking about | The discussion targets documents and personal repositories, excluding several centralized service domains. | Do not generalize the proposal to every transaction. |
+
+C02/C03 were checked manually beyond the bench excerpt.
+
+## Limits and counterexample
+
+A hypothetical shared inventory reservation requires a separate concurrency argument;
+local durability alone does not prove that a reservation is globally valid.
+The excerpt does not establish a merge algorithm or access-revocation semantics.
+
+## Disposition
+
+Retain Local Authority as a hypothesis candidate. Review persistence, synchronization,
+conflict handling and independent implementations before admission or maturity changes.