Consumer evidence
NetScript managed forms render with client navigation enabled by default. In an application whose <body> also opts into Fresh client navigation, a successful withForm mutation that redirects to a new full-document URL is revived as a partial response and fails during Fresh client-side revival.
EIS-Chat must currently put this raw literal on each redirecting managed form:
<Form state={state} {...{ 'f-client-nav': 'false' }}>
A boolean false is not sufficient for the inherited-body case because the Fresh reviver checks the literal attribute value. The workaround leaks Fresh transport details through NetScript's otherwise managed form abstraction and is easy to omit on new mutations.
Consumer PR: https://github.com/rickylabs/eis-chat/pull/188
Evidence: apps/dashboard/routes/channels/new/(_components)/create-channel-form.tsx, apps/dashboard/routes/project/[project]/channel/[channel]/(_components)/create-session-form.tsx, and .llm/runs/agent-netscript-0.0.5-contract-first-182--g3routes/drift.md.
Requested behavior
A redirecting withForm / Form flow should support an explicit, typed navigation strategy and produce a correct full-document transition without requiring raw f-client-nav=false attributes.
Acceptance
- The public form API exposes a documented typed strategy for successful redirects (
document, client, or equivalent).
- The document strategy overrides inherited
<body f-client-nav> behavior reliably.
- The default strategy remains backwards compatible.
- POST validation errors continue to render through the managed form state without document reload.
- A browser test covers successful POST + redirect under an ancestor/body client-nav opt-in and asserts no reviver/runtime error.
- The form documentation shows when a redirect should use client navigation versus a full-document transition.
Consumer evidence
NetScript managed forms render with client navigation enabled by default. In an application whose
<body>also opts into Fresh client navigation, a successfulwithFormmutation that redirects to a new full-document URL is revived as a partial response and fails during Fresh client-side revival.EIS-Chat must currently put this raw literal on each redirecting managed form:
A boolean
falseis not sufficient for the inherited-body case because the Fresh reviver checks the literal attribute value. The workaround leaks Fresh transport details through NetScript's otherwise managed form abstraction and is easy to omit on new mutations.Consumer PR: https://github.com/rickylabs/eis-chat/pull/188
Evidence:
apps/dashboard/routes/channels/new/(_components)/create-channel-form.tsx,apps/dashboard/routes/project/[project]/channel/[channel]/(_components)/create-session-form.tsx, and.llm/runs/agent-netscript-0.0.5-contract-first-182--g3routes/drift.md.Requested behavior
A redirecting
withForm/Formflow should support an explicit, typed navigation strategy and produce a correct full-document transition without requiring rawf-client-nav=falseattributes.Acceptance
document,client, or equivalent).<body f-client-nav>behavior reliably.