frontend-patterns/research/reviews/AuthorityPilot.md

Authority pilot — first investigation

Date: 2026-09-24. Reviewer: codex, manual self-review. Scope: prepared passages plus the explicitly located original sections in the two source reviews. This is an initial investigation, not the M1 acceptance review.

Initial direct-provider execution record

Both bench workspaces attempted their claims stage with google/gemini-2.5-flash. Each stopped after one adapter call; no generated claims, candidates, relations or critiques were produced. The separate OpenRouter credential probe returned HTTP 401. The original failure receipts record the exception type only, so that probe is separate diagnostic evidence rather than a retroactively fabricated provider receipt.

The existing credential route inspected was for activity-core's llm-connect workload, not generic workstation clients. No production key was retrieved or rotated. No fallback model or hidden retries were used. Completed usage/cost metadata is absent; we do not claim a measured zero charge. Eight planned calls did not take place.

The adapter now records model, structured error code and HTTP status where available without persisting raw provider error details. Tests exercise the 401 path using a synthetic secret sentinel. Existing failure receipts are preserved unchanged.

Reviewed research result

Read Carniato review and local-first review for the source claims. The following are our proposed modeling decisions, not conclusions attributed to both authors or proof that any pattern is established:

1. Scope authority to particular data and decisions. One application's draft, published record and shared reservation can have different authority rules.
2. Separate acknowledgement levels. Interaction feedback, durable local save, and globally accepted mutation should not be interchangeable states.
3. Qualify relations. Server Authority and Local Authority are alternatives only for the same authority scope. They may coexist in one application. Immediate Feedback does not require Server Authority.
4. Make recovery explicit. A projection or optimistic view must explain which durable state reconstructs it and what happens after interruption or rejection.

These proposals need source expansion and scenario testing. Q02 has a useful counterexample to server placement as a universal rule; independent variation of all responsibilities remains unproven. Q03 recurrence and Q04 generativity are open.

Candidate dispositions

Workspace/candidate origin	Repository candidate	Outcome
SRC-0001 C01, manually extracted	Server Authority	Retain candidate; qualify data scope
SRC-0001 C02, manually extracted	Immediate Feedback	Retain candidate; do not attach mandatory server dependency
SRC-0002 C01, manually extracted	Local Authority	Retain candidate; distinguish primary data from a disposable cache
Cross-source review hypothesis	Scoped Authority	Investigate whether this is a context rule rather than another pattern

There are no generated P01 identities to map: the provider runs failed. No canonical FEP IDs, pattern files, known uses or graph edges have been admitted in this pilot.

Next bounded work

• FEP-WP-0002-T02: extend review to durability, rejected writes, synchronization and conflicting edits; verify independent implementations. Source catalog remains extracted, not fully reviewed.
• FEP-WP-0002-T03: test acknowledgement distinctions on VC-01 and VC-02, using the same changed constraint: lose connectivity, restart, then reconnect.
• Live execution now uses llm-connect. See service pilot review for subsequent runs, truncation and admission findings. The earlier failures above remain historical evidence; workstation provider credentials are no longer needed.