B-J14M-headless-server-upstream
SDF gained a headless server in #2546: a second
binary, sdf-serve, that runs the generated API with no desktop window, serves the built front
end, and requires the platform token on every /api/* request. Nothing in it is specific to SDF.
Every app built from the Tauri and Nuxt template on ontogen-generated transports could use the
same thing.
What is wanted
Section titled “What is wanted”The owner’s suggestion (2026-10-03) is to backport it. A likely split, to be settled when the work is picked up:
- The Tauri template (template-tauri-nuxt)
owns the app shell, so it would carry the
servebinary: shared state construction for the desktop and headless entries, static files with the fallback to the app page, the bind address setting and its startup warning. - rust-ontogen generates the HTTP router and the client, so it would carry what belongs to the contract: the token guard on the generated routes and token handling in the generated client (B-L4QF-sdf-rejected-token-handling).
SDF then takes both back through a template sync and a pin bump, and its own copy goes.
SDF’s forward of the remaining /api/* routes to the sdlc dashboard server is specific to SDF
and stays here until the dashboard’s data moves onto the generated transports.