Refine recovery guidance and explore navigation and rendering

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
This commit is contained in:
tegwick 2026-09-26 21:22:53 +02:00
parent 21030784b1
commit 642163a1ed
21 changed files with 407 additions and 15 deletions

View file

@ -22,9 +22,9 @@ and agent reference, following the preliminary direction in `INTENT.md`.
## Current state
Research scaffold with an infospace-bench adapter as of 2026-09-25. The adapter
Research scaffold with an infospace-bench adapter as of 2026-09-26. The adapter
has deterministic integration tests, completed bounded live investigations through
llm-connect, and two synthetic architecture walkthroughs. Eight developed research
llm-connect, and three synthetic architecture walkthroughs (VC-03 provisional). Ten developed research
drafts remain hypotheses; none is canonically admitted. No frontend application runtime exists. See `research/bench/README.md`,
`REVIEW.md` (the initial review) and `workplans/` for follow-up work.

View file

@ -248,6 +248,8 @@ research/candidates/LocalCommitBoundary.md
research/candidates/LocalDraftState.md
research/candidates/MutationOutcomeTracking.md
research/candidates/PendingSynchronization.md
research/candidates/ProgressiveEnhancement.md
research/candidates/URLAddressableState.md
research/candidates/VersionCheckedMutation.md
research/cases/CarniatoGrandUnifyingArchitecture.md
research/cases/LocalFirstAuthority.md
@ -359,12 +361,15 @@ research/reviews/LLMConnectPilot.md
research/reviews/LocalFirstAdmissionScreen.json
research/reviews/LocalFirstEvidenceExpansion.md
research/reviews/MatrixRecoveryExperiment.md
research/reviews/NavigationCoverage.md
research/reviews/NavigationRenderingEvidence.md
research/reviews/ObsidianConflictScreen.json
research/reviews/RecoveryReviewMetrics.json
research/reviews/RecoveryWalkthroughReview.md
research/reviews/ResearchOptimization.md
research/reviews/ResearchPipelineRefinement.md
research/reviews/SchemaAndSourcePreparation.md
research/reviews/SharedGuidanceRevision.md
research/reviews/TransactionalEvidenceExpansion.md
research/reviews/TransactionalLiveReview.yaml
research/reviews/TruncationDiagnosis.md
@ -379,6 +384,7 @@ research/reviews/recovery-review-02/receipt.json
research/reviews/recovery-review-02/response.md
research/walkthroughs/VC01-TransactionalAdministration.md
research/walkthroughs/VC02-OfflineFieldNotes.md
research/walkthroughs/VC03-ContentPublication.md
scripts/research_admission.py
scripts/research_bench.py
scripts/research_execution.py

View file

@ -38,3 +38,8 @@ Executable evidence: [Matrix SDK recovery experiment](experiments/matrix-recover
Evaluation: [matched presentation pilot](evaluations/language-pilot-01/README.md) completed twelve llm-connect sessions; results inconclusive, human review pending.
Pilot follow-up: [submitted review adjudication](evaluations/language-pilot-01/submitted-review-01/adjudication.md) gives 18/24 obligations in both conditions; model-assisted review, not independent human validation.
Current follow-up: [shared guidance corrections](reviews/SharedGuidanceRevision.md)
and [navigation/rendering evidence](reviews/NavigationRenderingEvidence.md), with
[provisional VC-03](walkthroughs/VC03-ContentPublication.md). Ten developed hypotheses;
M1 remains open and the broader M2 evidence gate is not satisfied.

View file

@ -33,7 +33,8 @@ the working version as semantic resolution?
## Proposed solution and dynamics
On a detected conflict, preserve the alternate content under a distinct identity
Where access and retention policy permits, on a detected conflict preserve the
alternate content under a distinct identity
and associate it with the working item. Select a working version according to an
explicit policy. Keep resolution pending until a person or separately justified
merge mechanism decides what to retain. In the two documented uses, the preserved
@ -90,3 +91,11 @@ reconnect. Trace local-save acknowledgement, working-version selection, conflict
notification, resolution and separate backup recovery. Compare with a plain
architecture narrative and with immediate manual merge. A first [synthetic walkthrough](../walkthroughs/VC02-OfflineFieldNotes.md) now
traces this sequence. No runtime execution or proven generativity benefit is claimed.
## Policy boundary — 2026-09-26
Define who may inspect, retain, export and delete each version, including after
access changes. A conflict does not grant permission to preserve restricted data.
If policy requires deletion, explain the resulting recovery limit without exposing
the removed content. Retention and export are decisions, not unconditional safety
requirements. See [shared guidance revision](../reviews/SharedGuidanceRevision.md).

View file

@ -15,7 +15,9 @@ and `recoverability` compete with `cognitive-load` and `continuity-of-interactio
Proposed solution: expose the unresolved versions and provenance, let the user compare
and choose or combine them, then save the decision as a new revision referencing both
inputs. Do not remove recovery copies before that decision has committed. Announce
inputs. Where retention remains authorized, do not remove recovery copies before
that decision has committed; access revocation can require earlier deletion and
limit comparison. Announce
conflicts without relying on color; support keyboard comparison and recoverable focus.
Result: semantic resolution is an explicit action which may itself need synchronization.

View file

@ -32,3 +32,14 @@ this exact boundary: unknown. Recurrence: unknown. Hypothesis only.
Proposed connection: enables [Pending Synchronization](PendingSynchronization.md)
when the transaction records the pending revision. This is a research relation,
not an admitted canonical edge. Test: [VC-02](../walkthroughs/VC02-OfflineFieldNotes.md).
## Recovery evidence boundary — 2026-09-26
Name the storage transaction and acknowledgement assumptions, then test ordinary
restart, interrupted commit and any claimed power-loss/flush behavior separately.
An untested guarantee is unknown, not demonstrated impossible. Synchronization or
a second copy on the same device does not establish independent backup protection.
Define a separate backup retention/failure scope and test restoration to a clean
store, including pending operations and their reconciliation, before promising
recovery from device loss or replicated deletion. Respect access and retention
policy during backup and restore. See [shared guidance revision](../reviews/SharedGuidanceRevision.md).

View file

@ -14,8 +14,10 @@ write can destroy unfinished intent. Responsiveness and recoverability compete w
state complexity and privacy.
Proposed solution: keep base observation, editable proposal and current server
observation distinct. Rejection preserves the proposal; refreshed data prompts
comparison instead of replacing input. Explicit discard clears the draft. Define
observation distinct. Where access and retention policy permits, rejection preserves
the proposal; refreshed data prompts comparison instead of replacing input. Access
revocation may instead require clearing content. Export is a separate permission,
not an automatic recovery fallback. Explicit discard clears the draft. Define
whether navigation or restart persistence is required rather than implying it.
Consequences: review is possible after rejection, but stale drafts and sensitive data

View file

@ -56,3 +56,19 @@ from domain evidence. Cancelling a local pending record does not revoke a remote
accepted operation; issuing a new identity afterward can duplicate logical intent.
This is one partial implementation observation in the Element/Matrix family, not
independent recurrence or proof of real-server deduplication.
## Recovery contract — 2026-09-26
Before retrying, record how to recover the original operation identity, look up its
outcome, and determine the receiver's deduplication scope and retention window.
Outside that window, replay may create a second effect; lookup or reconciliation
must resolve the original outcome before fresh submission of the same logical
intent. If neither can resolve it, keep uncertainty visible and escalate the domain
decision rather than describing a fresh identity as safe.
Distinguish stopping a local wait, cancelling a pending remote action, and reversing
an accepted effect. State the authority's cancellation preconditions and race behavior;
if acceptance wins, only a separately authorized reversal/compensation can undo its
domain effect, and some effects have no reversal. Track that operation's outcome too.
These are design requirements prompted by the [submitted review](../evaluations/language-pilot-01/submitted-review-01/adjudication.md),
not new observations of provider guarantees.

View file

@ -32,3 +32,14 @@ offline operation; untracked best-effort upload, which lacks restart recovery.
Proposed connections: [Local Commit Boundary](LocalCommitBoundary.md) provides a
persistent origin; detected divergence may create context for [Conflict Copy](ConflictCopy.md).
Neither relation implies every sync needs a conflict copy. See the VC-02 walkthrough.
## Supersession contract — 2026-09-26
If reconciliation replaces pending operation P with revision c and operation Q,
commit c, Q and P's superseded/non-retryable status in one recoverable transaction.
After a restart, the queue must not retry P as active work. An already transmitted
P cannot be recalled by this local transaction: the receiver still needs appropriate
version/ancestry preconditions or reconciliation. A late receipt for P updates P's
history, never clears Q or overwrites c. Trace both crash boundaries and in-flight
races before asserting this contract. This is proposed guidance, not an executed
storage test; see [shared guidance revision](../reviews/SharedGuidanceRevision.md).

View file

@ -0,0 +1,43 @@
---
title: Progressive Enhancement
status: draft
maturity: hypothesis
families: [quality, execution, affordance]
scales: [L3, L6]
admission: research-candidate-only
---
# Progressive Enhancement
Context: essential reading/navigation or submission should work before optional
scripts arrive. Problem: delayed or failed client execution can block a usable
server-delivered interface. Resilience competes with interaction richness and the
cost of maintaining equivalent behavior across paths.
Proposed solution: give the essential task a usable HTML/link/form contract first;
add client behavior that preserves its meaning and authoritative validation.
Define which controls are essential and what enhanced behavior adds. Test absent,
late and partially failing scripts separately. Server-rendered text alone does not
establish a functional no-script task.
For enhanced navigation, preserve route, history, loading/error feedback and focus
semantics. For writes, avoid duplicate submission when falling back after an
uncertain response: reconcile the original operation before resubmitting it.
Keyboard operation, labels, status announcements and recovery focus need explicit
verification in both paths. Native elements help but are not an accessibility proof.
Consequences: initial tasks depend on fewer client capabilities, while parity and
failure recovery add design work. No-script support is not offline support. A
client-only rich editor may deliberately require scripts; name that requirement
instead of promising a fallback that cannot perform the task.
Evidence: [navigation review](../reviews/NavigationRenderingEvidence.md) N03–N05
locates htmx and SvelteKit mechanisms with specific link/form/action prerequisites.
These are two documentation families, not two verified deployments of this complete
contract. Full-pattern recurrence and decision benefit remain unknown. This develops
an existing seed; hypothesis only, no canonical identity or admitted relations.
Proposed connections: [URL-addressable State](URLAddressableState.md) supports shared
view selection; [Mutation Outcome Tracking](MutationOutcomeTracking.md) matters when
an enhanced write becomes uncertain. Neither is a universal dependency.
[VC-03](../walkthroughs/VC03-ContentPublication.md) explores a read-only core.

View file

@ -0,0 +1,40 @@
---
title: URL-addressable State
status: draft
maturity: hypothesis
families: [address, projection]
scales: [L3]
admission: research-candidate-only
---
# URL-addressable State
Context: readers need to share, bookmark and revisit a resource or selected view.
Problem: an address change can conceal state that only exists in the current tab.
Addressability competes with private/transient state and URL/schema stability.
Proposed solution: encode the public, stable resource identity and relevant view
selection in path/query parameters. Define parameter validation, defaults and route
resolution so direct entry and reload reconstruct that selection under current
authorization. A URL identifies a view, not necessarily immutable bytes or guaranteed
future availability. Use an explicit version if a stable historical snapshot matters.
Do not place secrets, private draft content, focus or every transient interaction
in the address. An identifier confers no authorization. Server-visible query/path
state and fragment-only state have different resolution contracts. If history is
enhanced, back/forward, cache misses and direct loads must resolve coherently;
pushState success alone is insufficient.
Consequences: views become independently reachable, but parameter compatibility,
invalid/deleted resources and full-versus-fragment cache behavior need contracts.
Alternatives: ephemeral in-tab selection when sharing is unnecessary; authenticated
saved-view identifiers when the selection is too large or private for the URL.
Evidence: [navigation review](../reviews/NavigationRenderingEvidence.md) N01/N02/N06
locates documentation mechanisms, not verified deployments of this whole proposal.
Full-pattern known uses and recurrence remain unknown. Refines the existing URL as
Application State seed; no canonical identity or admitted relations.
Proposed connection: [Progressive Enhancement](ProgressiveEnhancement.md) can preserve
native navigation while adding faster transitions; it is optional, not required by
addressability. [VC-03](../walkthroughs/VC03-ContentPublication.md) is a synthetic trace.

View file

@ -92,3 +92,14 @@ presentation difference for proof of recurrence or improved architecture decisio
rating corrections; both presentations now meet 18/24 obligations. The original
21/24 versus 19/24 figures above are historical. [Adjudication](../evaluations/language-pilot-01/submitted-review-01/adjudication.md)
retains all eight hypotheses and the unfulfilled independent-human evidence gate.
## Navigation/rendering expansion — 2026-09-26
[URL-addressable State](../candidates/URLAddressableState.md) develops the URL as
Application State seed; [Progressive Enhancement](../candidates/ProgressiveEnhancement.md)
develops its existing seed. Ten developed hypothesis drafts now exist, none admitted.
[VC-03](../walkthroughs/VC03-ContentPublication.md) adds a provisional synthetic case;
documentation mechanisms do not establish full-pattern recurrence or decision benefit.
Six existing drafts received [shared guidance corrections](../reviews/SharedGuidanceRevision.md)
outside the frozen pilot. Stop adding drafts for this slice; next gather implementation
evidence and challenge the proposed contracts.

View file

@ -80,3 +80,16 @@ SRC-0017: published matrix-js-sdk 42.3.0; npm archive and integrity recorded in
executed under controlled synthetic transport. Four cases pass; server guarantees
remain assumptions. This is the SRC-0014/0015 implementation family, not another
independent application. [Review](../reviews/MatrixRecoveryExperiment.md).
## Navigation/rendering documents — 2026-09-26
| ID | Primary source | Scope / state |
| --- | --- | --- |
| SRC-0018 | [htmx documentation](https://htmx.org/docs/) | History and representation caching; bounded documentary review |
| SRC-0019 | [htmx hx-boost](https://htmx.org/attributes/hx-boost/) | Native link/form enhancement; same publisher family as SRC-0018 |
| SRC-0020 | [SvelteKit form actions](https://svelte.dev/docs/kit/form-actions) | Native forms and scoped use:enhance contract |
| SRC-0021 | [SvelteKit page options](https://svelte.dev/docs/kit/page-options) | Initial HTML and optional client execution; same family as SRC-0020 |
| SRC-0022 | [MDN History.pushState](https://developer.mozilla.org/en-US/docs/Web/API/History/pushState) | Browser history API; not an application known use |
Living pages accessed 2026-09-26, exact revisions unknown; no runtime checks.
[Claim locators, dispositions and limits](../reviews/NavigationRenderingEvidence.md).

View file

@ -332,8 +332,8 @@ Workplan files own execution status. This table defines intended outcomes.
| Phase | Work record | Deliverable and exit criterion |
| --- | --- | --- |
| M0 — Scaffold | FEP-WP-0001, finished | Intent, repository structure and State Hub integration exist. |
| M1 — Seed investigation | [FEP-WP-0002](../../workplans/FEP-WP-0002-seed-language-validation.md), ready | Reconciled schema; first source case and local-first contrast; 6–10 connected draft patterns; two completed case walkthroughs with evidence and counterexamples. |
| M2 — Broaden and challenge | [FEP-WP-0003](../../workplans/FEP-WP-0003-contrasting-schools.md), proposed | Evidence from all six streams; coverage matrix for all ten application types; revise, merge or reject candidates; complete at least four further contrasting cases. |
| M1 — Seed investigation | [FEP-WP-0002](../../workplans/FEP-WP-0002-seed-language-validation.md), active | Reconciled schema; first source case and local-first contrast; 6–10 connected draft patterns; two completed case walkthroughs with evidence and counterexamples. |
| M2 — Broaden and challenge | [FEP-WP-0003](../../workplans/FEP-WP-0003-contrasting-schools.md), active (bounded exploration; M1 open) | Evidence from all six streams; coverage matrix for all ten application types; revise, merge or reject candidates; complete at least four further contrasting cases. |
| M3 — Retrieval and empirical use | [FEP-WP-0004](../../workplans/FEP-WP-0004-reference-surface.md), proposed | Validated metadata and graph export; held-out retrieval cases; at least two real repository studies tied to revisions; publish limitations. |
M1 does not require a large catalog. Six to ten patterns is a working scope cap,

View file

@ -1,6 +1,6 @@
# Validation cases
Status: synthetic briefs · VC-01 and VC-02 have drafts/self-reviews; other cases remain planned.
Status: synthetic briefs · VC-01 and VC-02 have drafts/self-reviews; VC-03 has a provisional exploratory draft; other cases remain planned.
[VC-01 draft](../walkthroughs/VC01-TransactionalAdministration.md) and [VC-02 draft](../walkthroughs/VC02-OfflineFieldNotes.md) are reasoning exercises,
not runtime validation or M1 acceptance.
@ -49,3 +49,6 @@ out-of-scope problem. Record expected acceptable patterns, prohibited claims and
when to ask for context or abstain. Compare retrieval with manual navigation;
report unsupported recommendations, missed constraints and unresolved references.
Keep development examples separate from the held-out set.
2026-09-26: [provisional VC-03](../walkthroughs/VC03-ContentPublication.md) explores
navigation/rendering before M1 completion. It does not satisfy the M2 case gate.

View file

@ -0,0 +1,16 @@
# Research stream coverage — 2026-09-26
WP-0003 T01 working matrix. Entries mark located evidence, not completed streams.
| Stream | Current evidence | Key gap / disagreement |
| --- | --- | --- |
| A — GUI architecture | No dedicated primary-source comparison yet | Presentation/domain separation and competing historical models |
| B — Navigation/hypermedia | [N01–N04/N06](NavigationRenderingEvidence.md): htmx, SvelteKit and browser history | Framework examples versus pinned application behavior; direct entry versus transient state |
| C — Rendering/execution | [N05](NavigationRenderingEvidence.md): SvelteKit HTML/client options; existing SRC-0001 interpretation | Pre-rendering, hydration, islands and streaming lack comparable implementation coverage |
| D — Authority/synchronization | [Transactional evidence](TransactionalEvidenceExpansion.md), [frontend recovery](FrontendRecoveryImplementations.md), [Matrix experiment](MatrixRecoveryExperiment.md) | Synthetic receiver cannot prove production durability/deduplication; canonical admission remains open |
| E — Composition/organization | Seed catalog only | Independent feature/deployment boundaries and their operational cost |
| F — Quality | Retention/recovery guidance; navigation resilience requirements | No accessibility/performance validation; no-script support is narrower than resilience |
Next slice is implementation evidence for B/C, not expansion of the candidate count.
VC-01/02 are synthetic reviewed drafts; VC-03 is provisional; VC-04–10 remain planned.
No source count is used as a recurrence score or evidence-gate substitute.

View file

@ -0,0 +1,47 @@
# Navigation and rendering evidence — 2026-09-26
Status: bounded primary-document review by Codex; exploratory WP-0003 T01 work.
Streams B (navigation) and C (rendering), with a narrow resilience connection to F.
All pages accessed 2026-09-26; living documentation, exact revisions/publication dates
unknown. The htmx main documentation inspected describes its 2.x line. These are
mechanism examples, not pinned deployment observations or runtime tests. No bench
inference was run; future live inference continues to use llm-connect.
| Claim | Primary source and locator | Observation | Editorial consequence / limit |
| --- | --- | --- | --- |
| N01 | SRC-0018 [htmx documentation](https://htmx.org/docs/), History support | Pushed addresses must support full-page navigation; history misses can require fetching a full page | A URL must survive direct entry, not merely change the address bar |
| N02 | SRC-0018, Caching; History support | Header-dependent full/fragment responses require appropriate Vary and representation-specific ETags; history snapshots can be disabled for sensitive content | Representation selection and cache policy are part of navigation correctness; Vary alone is no authorization or privacy guarantee |
| N03 | SRC-0019 [hx-boost](https://htmx.org/attributes/hx-boost/), introductory paragraphs | Existing links and forms can retain native behavior without JavaScript while receiving Ajax enhancement | This depends on usable native href/action contracts; arbitrary script-only controls gain no fallback automatically |
| N04 | SRC-0020 [SvelteKit form actions](https://svelte.dev/docs/kit/form-actions), Progressive enhancement / use:enhance | Documented forms work without client JavaScript; use:enhance is scoped to POST forms targeting +page.server.js actions | Enhancement has a specific transport/action contract; do not generalize it to GET forms or +server.js endpoints |
| N05 | SRC-0021 [SvelteKit page options](https://svelte.dev/docs/kit/page-options), ssr / csr | Default rendering produces server HTML then hydrates; disabling SSR produces a shell, while disabling CSR removes client scripting | Initial HTML and client execution are separable decisions; useful HTML does not alone establish usable controls or accessibility |
| N06 | SRC-0022 [MDN History.pushState](https://developer.mozilla.org/en-US/docs/Web/API/History/pushState), Parameters / url | pushState does not immediately load the supplied URL; the browser may load it later; the URL must have the same origin | Successful history mutation alone does not verify a usable route |
## Candidate dispositions
Develop two existing seeds as hypotheses:
[URL-addressable State](../candidates/URLAddressableState.md) refines “URL as
Application State” to explicitly scoped, shareable view selection; and
[Progressive Enhancement](../candidates/ProgressiveEnhancement.md) separates the
native contract from optional enhancement. Neither is an invention claim, canonical
admission or a new mandatory dependency. Keep Server Projection as a seed/context:
server-rendered and pre-rendered content can both serve the synthetic brief.
htmx and SvelteKit supply two independently maintained framework documentation
families, not verified independent applications of either whole candidate. Two
SvelteKit pages count as one family. MDN explains browser behavior, not another
application. Full-pattern recurrence and decision usefulness remain unknown.
## Counterexamples and next observation
A successful pushState call can expose a URL that fails on reload. A fragment-only
response can leave a new tab without the surrounding document. A cache that ignores
representation selection can serve a fragment as a full page. HTML rendered before
scripts can still contain nonfunctional script-only controls. Native navigation can
still fail offline, and neither native HTML nor Ajax establishes accessible focus
behavior by itself.
[VC-03](../walkthroughs/VC03-ContentPublication.md) traces these as design failures,
not reproduced bugs in either framework. Next, select one pinned implementation
and exercise direct entry, no-script navigation, history restoration and full/partial
response caching. Keep observed results separate from proposed contracts. No broad
framework comparison or M2 completion follows from this review.

View file

@ -0,0 +1,32 @@
# Shared guidance revision — 2026-09-26
Status: editorial revision after the [user-submitted model-assisted review](../evaluations/language-pilot-01/submitted-review-01/adjudication.md).
This changes the current research corpus, not the frozen pilot. No additional
inference sessions, new ratings, human validation or admission are claimed.
| Review gap | Current guidance change | Remaining evidence |
| --- | --- | --- |
| S02: expired idempotency and lost identity | [Mutation Outcome Tracking](../candidates/MutationOutcomeTracking.md): recover identity, lookup outcome, respect retention; unresolved intent stays uncertain | Actual receiver retention and lookup contracts |
| S03: retention/export assumed after access changes | [Local Draft State](../candidates/LocalDraftState.md), [Conflict Copy](../candidates/ConflictCopy.md), [Explicit Reconciliation](../candidates/ExplicitReconciliation.md): preservation conditional on policy, export separately authorized | Application policy and revocation tests |
| S04: local cancellation confused with remote recovery | Mutation Outcome Tracking: cancellation races, authorized reversal and its own uncertain outcome | Domain cancellation/compensation contract |
| S05: obsolete operation can survive restart | [Pending Synchronization](../candidates/PendingSynchronization.md): atomically save replacement and retire old pending work; in-flight old requests remain a separate problem | Storage crash and receiver-precondition tests |
| S06: local save/sync overstated as protection | [Local Commit Boundary](../candidates/LocalCommitBoundary.md): separate flush claims, independent backup scope and restore test | Executed durability and restore evidence |
S01's request-generation rule remains separate from server freshness: discarding a
superseded response does not prove that the retained result is current. Existing
VC-01 guidance already distinguishes these obligations. No new pattern is needed
for these corrections; the six affected records remain hypotheses.
## Evaluation integrity
The pilot's corpus commit remains `78bd95156832c9c48c0e17947a406396c7660088`;
preregistration remains `6acbe6d`. Packs, prompts, assignments, raw receipts, original
scores and submitted adjudication are unchanged. Frozen input hashes must now be
checked against those historical Git objects, not substituted with current drafts.
The old runner's current-tree validation is expected to reject revised corpus files.
Reproduce the old study from its frozen checkout; do not refresh its manifest.
The six scenarios are consumed development examples. A later evaluation must freeze
the revised corpus, use new scenarios and score atomic obligations. Its purpose
would be to test improvement, which these editorial repairs alone cannot establish.
WP-0002 T03 retains the independent-human evidence gate.

View file

@ -0,0 +1,100 @@
# VC-03 — Content publication
Status: drafted, editorial self-review only. Author: Codex, 2026-09-26.
Synthetic brief; exploratory preparation for WP-0003 T02, not M1/M2 acceptance.
Corpus: two navigation drafts introduced with this document; eight earlier hypotheses
retained, with [shared guidance corrections](../reviews/SharedGuidanceRevision.md).
## Fixed brief and assumptions
Mostly read-only content, shareable URLs, useful content before scripts and slow
networks are fixed VC-03 requirements. For this exercise, assume a public article
catalog with GET topic/page filtering and links to article identifiers. Publishing
happens elsewhere; no reader writes or concurrent editing are in scope. The publisher
is authoritative. Content may change between visits; immutable editions, numerical
latency budgets and live update deadlines are unspecified. Offline access is not
initially required. Native keyboard navigation, labels, meaningful document structure
and usable error pages are required design constraints; accessibility is not yet tested.
No personal data is needed in URLs. Administrative/authenticated responses must not
inherit the public catalog's cache policy. Public content still needs normal output
escaping and validated parameters.
## Baseline narrative without the pattern catalog
Serve complete article/list documents for every public route. A filter form uses
GET, and links carry the selected topic/page. Deliver text and native controls before
optional scripts. Server rendering or pre-rendering can supply this; choose according
to publication freshness and build/runtime constraints, which the brief leaves open.
Optionally replace a region during navigation, preserving history, errors and focus.
Keep full-page and fragment response caching distinct. Skip optional enhancement
when it cannot justify its extra failure cases. This baseline already expresses all
essential decisions; naming patterns adds no demonstrated benefit.
## Decisions
| Order | Context and forces | Pattern references | Alternatives and rejection reasons | Resulting context | Evidence |
| --- | --- | --- | --- | --- | --- |
| 1 | Public, shareable view selection | [URL-addressable State](../candidates/URLAddressableState.md) | In-memory-only filters cannot reconstruct shared selection | `/articles?topic=architecture&page=2` resolves without prior tab state | N01/N06 |
| 2 | Useful reading before scripts; slow delivery | Server Projection seed; [Progressive Enhancement](../candidates/ProgressiveEnhancement.md) | Script-only shell conflicts with brief; static generation remains viable | Initial HTML contains useful text, links and GET controls | N03/N05 |
| 3 | Optional smoother transitions versus complexity | Progressive Enhancement, conditional | Native full navigation remains acceptable; no requirement forces Ajax or hydration | If added, enhancement must preserve URL/content/history coherence | N01/N03 |
| 4 | Full and partial representations share a route | Context/cache requirement, no new pattern | Mixing cache entries can break direct entry | Explicit representation selection and cache keys; or use full documents only | N02 |
N01–N06 refer to the [primary-source review](../reviews/NavigationRenderingEvidence.md).
Framework examples demonstrate available mechanisms; these decisions are synthesis.
SvelteKit's enhanced POST actions do not implement this exercise's native GET filter;
N04 is a contrasting example of why enhancement prerequisites matter.
## Trace and failure recovery
1. Open the filtered URL in a new tab with scripts blocked. The server validates
parameters and returns a complete document for that selection. Invalid parameters
have a declared normalize-or-error policy; deleted articles produce useful errors.
2. Change the filter through native GET submission. The next URL and document agree.
Back/reload/direct entry preserve the selection, not a promise of identical bytes.
3. If enhancement is enabled, keep the previous committed URL/content coherent while
fetching. On success, commit the selected view and its history entry together at
the interaction level. Ignore superseded responses; that ordering alone does not
prove server freshness. Restore meaningful focus and announce changed content.
4. On failure before commit, preserve the old view with an accessible retry or native
navigation link. If a design changes the URL earlier, it must restore it or perform
full navigation on failure; a new URL over old unlabeled content is unacceptable.
5. History restoration must recover the selected route even after a snapshot miss.
Direct navigation always obtains full HTML. If request headers select fragments,
configure Vary and representation-specific validators consistently across caches;
test actual intermediary behavior. Public caching policy does not authorize caching
personal content. This case has no uncertain write to replay.
## Change one constraint
Add **offline reading of previously visited articles**; keep the public read-only
scope and all other requirements unchanged. Native links and useful initial HTML
alone no longer satisfy the brief. A local cache must identify available article
versions, state freshness/offline limits, handle eviction and distinguish unvisited
articles from failed delivery. Define whether ordinary cache eviction is acceptable
before promising availability. Reconnection refresh needs a policy for replacing
readable content without disrupting the current task.
This does not automatically require local write authority, a pending mutation queue
or Conflict Copy: the client has no edits to reconcile. Retain addressability and
native contracts, add a separately researched cache/availability contract. The
current corpus cannot yet supply a supported offline-reading pattern; do not stretch
Pending Synchronization to fill that gap.
## Review
| Criterion | Pass / revise / unknown | Evidence and reason |
| --- | --- | --- |
| Traceability | pass (editorial) | Each proposed decision cites documented mechanisms and declared assumptions |
| Coherence of configuration | pass (editorial) | Native path satisfies initial brief; enhancement remains conditional |
| Decision usefulness beyond baseline | unknown | Same author wrote both; baseline already contains the obligations |
| Quality constraints | revise | Focus, keyboard, slow-network behavior and cache isolation need runtime tests |
| Changed-constraint branch | revise | Identifies a real cache/availability gap; implementation/evidence not supplied |
## Gaps and follow-up
[WP-0003 T01/T02](../../workplans/FEP-WP-0003-contrasting-schools.md) owns pinned
implementation selection and direct-entry, disabled-script, history-miss and
representation-cache checks. Test interrupted enhancement separately from entirely
absent scripts. Establish a measurable content-delivery budget before performance
claims. Keep offline cache research bounded; do not add another draft merely to
make the diagram complete. Independent decision-usefulness review remains open.

View file

@ -324,3 +324,13 @@ validation is still unfulfilled under the frozen protocol, and later studies nee
atomic criteria and fresh scenarios. Target shared guidance at policy-dependent
recovery, cancellation/reversal contracts, atomic supersession and backup/restore.
See research/evaluations/language-pilot-01/submitted-review-01/adjudication.md.
## Shared guidance corrected — 2026-09-26
T02/T03 remain progress. Applied submitted-review lessons to six current hypothesis
records: policy-dependent retention/export, cancellation/reversal and identity lookup,
atomic supersession, backup/restore and the difference between unknown and impossible.
See research/reviews/SharedGuidanceRevision.md. Frozen pilot files and scores remain
unchanged; historical corpus hashes remain reproducible. No new evaluation or M1
completion. WP-0003 T01 now owns a bounded exploratory navigation/rendering expansion;
independent-human validation and a fresh-scenario replication remain open here.

View file

@ -4,25 +4,26 @@ type: workplan
title: "Challenge the language across architectural schools"
domain: infotech
repo: frontend-patterns
status: proposed
status: active
owner: codex
topic_slug: canon
created: "2026-09-24"
updated: "2026-09-24"
updated: "2026-09-26"
state_hub_workstream_id: "13c123f1-a470-560e-ab8e-b270c387930a"
---
# Challenge the language across architectural schools
Part of `research/plan/ResearchProgram.md`. Phase prerequisite: FEP-WP-0002's evidence
gate. This is planned follow-up, not an active background execution request.
Individual task descriptions identify any work that can start earlier.
Part of `research/plan/ResearchProgram.md`. Full phase completion still requires
FEP-WP-0002's evidence gate. Under the user's instruction to continue, a bounded
exploratory slice of T01 and provisional case preparation starts before that gate;
this is not M1 acceptance or authorization to declare M2 complete.
## Compare the six research streams
```task
id: FEP-WP-0003-T01
status: todo
status: progress
priority: high
state_hub_task_id: "f7a7eea5-5055-545b-a957-55ee4d17a256"
```
@ -50,3 +51,17 @@ state_hub_task_id: "2b7252c1-c453-5050-96fb-d86a3f3df0f0"
```
Record retain/merge/split/reject decisions, revised relations, quality constraints and counterexamples. Write research/reviews/M2-CoverageReview.md against the M2 gate; hand unresolved questions into live work records before closing.
## Bounded navigation/rendering slice — 2026-09-26
T01 active: SRC-0018–0022 reviewed across navigation/rendering and a narrow resilience
concern. Two existing seeds developed, bringing the corpus to ten hypotheses. See
research/reviews/NavigationRenderingEvidence.md and NavigationCoverage.md. No runtime
observation, new model calls, canonical admission or complete stream coverage.
T02 remains todo for the post-M1 case gate. VC03-ContentPublication.md is provisional
preparation with a baseline, failure trace and offline-reading constraint branch.
Next bounded action under T01: select and pin one implementation, test direct loads,
no-script navigation, history misses and full/fragment cache behavior. Under T02,
independently review the trace and resolve the offline availability gap before
calling it complete. T03 remains todo; keep M1 human validation in WP-0002 T03.