Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
4.2 KiB
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, 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, 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, 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, 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, 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 refines “URL as Application State” to explicitly scoped, shareable view selection; and Progressive Enhancement 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 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.