Context
PR #146 bumps SEAMLESS_TEMPLATES_REF to v0.7.0, which adds a Fastify API starter alongside Express. seamless init now offers it as "Fastify (beta)".
The conformance harness does not exercise it. verify/adapter-app is an Express app (server.mjs imports createSeamlessAuthServer from @seamless-auth/express), and the compose adapter service builds only that. So a green seamless verify currently says nothing about whether a Fastify-scaffolded project actually works.
What backs Fastify today is the parity suite in seamless-auth-server, which runs the same requests through both adapters against the same mocked auth API and asserts the status, body, and every Set-Cookie header match, including the console proxy. That is real coverage, but it tests the adapters in isolation, not a scaffolded project against a live auth API through this repo's flow matrix.
Proposal
Add a Fastify layer so the adapter column is exercised for both frameworks.
- Add
verify/adapter-fastify-app (or parameterize verify/adapter-app), registering seamlessAuth from @seamless-auth/fastify with the same capture transport the Express app uses, so the harness can read OTP and magic-link codes the adapter would otherwise strip.
- Add a compose service beside
adapter in verify/docker-compose.verify.yml on its own port, mirroring the existing env block (AUTH_SERVER_URL, API_SERVICE_TOKEN, COOKIE_SIGNING_KEY, JWKS_KID, WEB_ORIGIN) and healthcheck.
- Add a Playwright project in
verify/harness/playwright.config.ts beside { name: 'adapter', testDir: './adapter' }. Ideally the existing adapter specs run against both base URLs rather than being duplicated.
- Surface it as its own column in the matrix grid (
verify/harness/lib/matrixReporter.ts) so a Fastify-only regression is visible.
- Decide whether it runs by default or behind a flag. The adapter layer is fast, so default-on seems reasonable, but
--api-only and --no-react should keep working.
Notes
- The Fastify starter serves the same surface on an identical env contract, including the admin console at
/console behind SERVE_ADMIN_CONSOLE. Console proxy support arrived in @seamless-auth/fastify 0.2.0 as seamlessConsoleProxy, so pin 0.2.0 or later.
- Watch the per-IP OTP limiter noted in AGENTS.md. Adding a second adapter funnelling OTP through one client IP could push the api and adapter layers into the API's 10 per 15 minutes ceiling. Prefer magic-link login over a second email-OTP round trip in the new specs.
verify/adapter-app/package.json pins the adapter SDK explicitly, so the new app needs the same treatment when versions bump.
Acceptance
seamless verify stands up both adapters, runs the flow matrix against each, and prints a grid where a failure in either is attributable to the framework.
Context
PR #146 bumps
SEAMLESS_TEMPLATES_REFto v0.7.0, which adds a Fastify API starter alongside Express.seamless initnow offers it as "Fastify (beta)".The conformance harness does not exercise it.
verify/adapter-appis an Express app (server.mjsimportscreateSeamlessAuthServerfrom@seamless-auth/express), and the composeadapterservice builds only that. So a greenseamless verifycurrently says nothing about whether a Fastify-scaffolded project actually works.What backs Fastify today is the parity suite in
seamless-auth-server, which runs the same requests through both adapters against the same mocked auth API and asserts the status, body, and everySet-Cookieheader match, including the console proxy. That is real coverage, but it tests the adapters in isolation, not a scaffolded project against a live auth API through this repo's flow matrix.Proposal
Add a Fastify layer so the adapter column is exercised for both frameworks.
verify/adapter-fastify-app(or parameterizeverify/adapter-app), registeringseamlessAuthfrom@seamless-auth/fastifywith the same capture transport the Express app uses, so the harness can read OTP and magic-link codes the adapter would otherwise strip.adapterinverify/docker-compose.verify.ymlon its own port, mirroring the existing env block (AUTH_SERVER_URL,API_SERVICE_TOKEN,COOKIE_SIGNING_KEY,JWKS_KID,WEB_ORIGIN) and healthcheck.verify/harness/playwright.config.tsbeside{ name: 'adapter', testDir: './adapter' }. Ideally the existing adapter specs run against both base URLs rather than being duplicated.verify/harness/lib/matrixReporter.ts) so a Fastify-only regression is visible.--api-onlyand--no-reactshould keep working.Notes
/consolebehindSERVE_ADMIN_CONSOLE. Console proxy support arrived in@seamless-auth/fastify0.2.0 asseamlessConsoleProxy, so pin 0.2.0 or later.verify/adapter-app/package.jsonpins the adapter SDK explicitly, so the new app needs the same treatment when versions bump.Acceptance
seamless verifystands up both adapters, runs the flow matrix against each, and prints a grid where a failure in either is attributable to the framework.