The last open item of #2944 (item 3), and the first entry on #2945's additions-only list.

ActionRunner dispatched a seventh action type, navigation, that
@objectstack/spec's ActionType does not contain. The issue asked for a
decision: promote it upstream, or delete the case. Neither, as stated.

Why not promote

The spec already names this operation. type: 'url' is "go to a location", with
openIn: 'self' | 'new-tab' for the tab choice. Adding navigation upstream
would put a second spec name on one operation — which is the failure this audit
exists to describe, committed one level up:

the recurring failure is not "renderer forgot a name", it is "a second
definition exists and the renderer is faithful to the wrong one."

Why not delete

Deleting does not surface an error. { type: 'navigation', to: … } is authored
today — element:button CTAs use it — and without the case the action falls
through to executeActionSchema, which returns { success: true }. The user gets
a green success toast and no navigation. That is #2960's trap, reached by way of a
cleanup.

The actual finding: it had already drifted

Two implementations of one concept, and executeNavigation was quietly the
weaker one:

So { type: 'navigation', to: '/x?p=${param.p}' } shipped the literal
${param.p}, while the identical url action resolved it.

What this does

ObjectUiLocalActionType / OBJECTUI_LOCAL_ACTION_TYPES declare navigation as
objectui's own alias of url — the treatment #2985 gave the page-visualization
names — and both names now route through one navigateTo. url gains replace
pass-through, the one modifier only the alias carried.

Additive. replace is omitted from the NavigationHandler options object when
unset, so hosts see the shape they already saw.

The guard is structural, not another assertion

Built-in dispatch is now a table typed Record<RunnableActionType, …> instead of
a switch. An ActionType the spec adds stops compiling until an executor
exists for it — #2942's "validates at save, renders nothing at run time" class,
converted into a build error for actions. Verified it bites by deleting one entry:

ActionRunner.ts(372,20): error TS2741: Property 'form' is missing in type
'{ script: …; url: …; modal: …; flow: …; api: …; navigation: … }' but required in
type 'Record<RunnableActionType, (action: ActionDef) => Promise<ActionResult>>'.

spec-derived-unions.test.ts additionally asserts navigation is absent from
the spec enum — the inverse tripwire, so the day it is adopted upstream the test
fails and names the alias to retire.

Coverage for two branches that had none

The /api/ full-page short-circuit and apiBase promotion were untested while
executeUrl was their only caller. They are what the better-auth social-login
redirect dance depends on — pushing /api/… into the SPA router matches no route
and lands on the home page, so the OAuth flow never starts — and they now have
two callers. (They had no coverage because this project runs in a node
environment with no window at all; the new tests stub the minimum and restore
it.)

Also

Corrects the audit doc's Direction B row, which still told readers to promote
navigation, and adds Correction 4 explaining the general point: a
"renderer-local dialect" row needs a third option next to promote and delete —
alias to the spec name it duplicates — and choosing starts with asking
whether the spec really lacks the concept or just spells it differently.

Verification

Two test files (basic-renderers, page-variables) hit a beforeAll timeout
on await import('../renderers') during the full run — the machine was loaded and
the run took 1050s against a normal ~285s. Both pass standalone in 11s (33/33),
with that import taking 2.7s rather than >30s. Not a logic failure.

🤖 Generated with Claude Code