[Anmol1696]

Configured per-API origins now participate in CORS decisions, and OPTIONS requests finish before authentication, uploads, or GraphQL execution.

flowchart LR
  A[Resolve API metadata] --> B[CORS decision]
  A -->|Unknown or failed| E[404 or 500 without CORS grant]
  B -->|OPTIONS| C[End response]
  B -->|Actual request| D[Authentication and CSRF before execution]

Loading

Trigger	Before	After
Scoped API origin	Metadata unavailable to CORS	Resolved origins participate
Denied OPTIONS	Could reach authentication and GraphQL	Empty 200 without CORS grants
Unknown host or metadata failure	Matching fallback could approve preflight	404 or 500 without CORS grants
Actual request	Authentication and CSRF enforced	Same rules; explicit fallback and localhost matching preserved

Validation applies to aeb59b74e440f20d743ebadf7c10d9ca46a8260b.

Check	Result	Evidence
Local server suite	284 tests across 26 suites passed	pnpm --filter @constructive-io/graphql-server test --runInBand
Local HTTP regression	57 tests passed	pnpm --filter graphql-server-test test --runInBand --runTestsByPath __tests__/cors.integration.test.ts
Local build and static checks	Passed	Server build, ESLint on changed TypeScript files, and diff whitespace checks
Hosted CI for this HEAD	Skipped for draft PR	CI tests; workflow build requires a non-draft PR
Installed/deployed/live acceptance	Unrun	No installation or deployment performed

The HTTP regression exercises the production Server, metadata loaders, authentication, CSRF, and PostGraphile using disposable PostgreSQL fixtures. It does not validate production database policy, Cloud ingress, browser enforcement, or the broader integration suite.

Related: planning #2422, Cloud #285, and separate Cloud PR #287. Origin policy selection and activation remain outstanding. Explicit wildcard fallback still reflects arbitrary origins for resolved APIs; this runtime prerequisite does not complete #2422.