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

Refine recovery guidance and explore navigation and rendering

Browse source 
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
Download patch file Download diff file Expand all files Collapse all files

100
research/walkthroughs/VC03-ContentPublication.md Normal file
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.