2 Commits

Include renames

Author	SHA1	Message	Date
Clintchiz	57097c8204	fix(authz): fix prod boot-order (C1), dev HMR staleness (I2), add prod coverage (I4) ... Fix round 2 for Task 14, addressing a critical review finding reproduced on a real built server. C1 (critical): the generated production entry set the authz catalog inside createProductionServer's BODY, but ES modules evaluate every static import (including app middleware, emitted as a static import) before the importing module's body runs. Middleware reading getAuthzCatalog() at module scope — the same eager shape authzMiddleware({ catalog, ... }) itself requires, and the pattern app/middleware/logger.ts's `export default requestLogger({...})` already uses — saw an unset catalog and crashed the whole process at import time, after every other gate (typecheck/lint/tests/a plain `bun run build`) stayed green. Fix: packages/cli/src/build.ts now emits a small side-effecting `.authz-setup.ts` module containing the static imports of every app/authz/*.ts declaration plus a call to the new applyAuthzManifestEarly(entries) (packages/dev-server/src/prod.ts), and imports THAT MODULE FIRST in the generated entry — before pages, api, realtime, middleware, components, and layouts. applyAuthzManifestEarly is deliberately silent (no missing-default-export warnings, though a genuine conflict still throws and fails the boot at import time); createProductionHandlers keeps its own unconditional merge+set as an idempotent, always-warning second pass, so an adapter that bypasses the generated entry and calls it directly still gets a correctly merged, validated catalog, and so the function stays independently testable. I3: corrected packages/authz/src/client.ts's WRN-AUTHZ-SETUP message, which claimed prod always sets the catalog before middleware runs — true again for the generated entry after the C1 fix, but not for a custom entry that calls createProductionHandlers directly. I2: dev HMR editing app/authz/*.ts reloaded the page while the OLD catalog stayed authoritative (watch.ts classifies any non-CSS change as "server"; hotUpdate had no authz/ branch) — a false security signal, since tightening or removing a permission looked like it took effect but didn't until a restart. Added the branch (packages/dev-server/src/index.ts), and gave loadAppAuthzCatalog (authz-boot.ts) an injectable importer: a raw import() would have silently no-op'd on the re-import (Bun caches local TS/JS modules by filesystem path and ignores query strings), so the hot path routes through loadModule (pipeline.ts) instead, which copies the edited file to a versioned sibling specifically to defeat that cache. I4: added direct createProductionHandlers/applyAuthzManifestEarly tests (packages/dev-server/test/authz-prod.test.ts: conflict throws naming both files, missing default export warns and skips, empty array yields an empty catalog, a second call re-validates rather than trusting a stale singleton) and the regression test that matters most (packages/cli/test/authz-prod-coldstart.test.ts): a real `runBuild` + a real `bun dist/server.js` boot, with a middleware module reading getAuthzCatalog() at module scope, asserting it actually serves a request. M5: startServer built its own router once, then loadAppAuthzCatalog built a second one from scratch on every dev boot and every authz/ hot reload. loadAppAuthzCatalog now accepts either an appDir (still used standalone, e.g. by the test suite) or an already-built Router, and both call sites in index.ts now pass the router they already have. Every fix in this round was verified non-vacuous by sabotaging it and confirming the corresponding test fails, then reverting.	2026-08-04 23:16:41 +05:30
Clintchiz	226217ecbf	feat(authz): reach the merged catalog from boot via a process-wide singleton ... Fix round 1 for Task 14 — closes the gap flagged in the last report: loadAppAuthzCatalog existed but nothing called it. - packages/authz/src/client.ts (new): setAuthzCatalog/getAuthzCatalog/ hasAuthzCatalog, mirroring @wrnexus/db's client.ts. App middleware runs at module-eval time and needs the catalog then, so ctx cannot carry it; getAuthzCatalog() throws a setup error naming the fix, like getDb() does. Exported from packages/authz/src/index.ts. - packages/dev-server/src/index.ts: startServer calls loadAppAuthzCatalog + setAuthzCatalog before middleware is resolved (schemasJs precedent), and populates the new RuntimeDeps.authz field. - packages/dev-server/src/runtime.ts: RuntimeDeps gains authz?: AuthzCatalog. - packages/cli/src/build.ts: emits static imports of each app/authz/*.ts file into the generated entry (components/layouts precedent) and passes { source, module } pairs through ProdOptions.authz — the catalog holds policy functions, so it cannot be JSON-baked like schemasJs. - packages/dev-server/src/prod.ts: createProductionHandlers merges those declarations and calls setAuthzCatalog before the server accepts traffic, so a conflict fails the boot instead of surfacing on the first request. Runs for every deployment adapter, not only Bun.serve. The framework never installs authzMiddleware itself; the app still registers it with its own store. Verified end-to-end: added a temporary app/authz declaration to examples/basic-app, ran `bun run build`, inspected the generated entry's static import + authz array, and booted dist/server.js to confirm the merge/setAuthzCatalog call succeeds against real bundled code (reverted before commit).	2026-08-04 22:40:42 +05:30