← ClaudeAtlas

frontend-architecturelisted

Use at :architect — Next.js App Router structure as Kintwadi (Best Design) built it, protection as the default rather than a per-page opt-in, and where the data-access layer sits.
rogerjeasy/win-hackathon · ★ 0 · Web & Frontend · score 60
Install: claude install-skill rogerjeasy/win-hackathon
# The layout runs the guard, not the page Kintwadi's `AGENTS.md` states the routing invariant in one sentence: every authenticated page lives under `src/app/(app)/`, and that route group's `layout.tsx` runs `requireSession()` on the server, redirecting unauthenticated users to `/sign-in`. Nothing inside the group has to remember to check auth — the layout already ran before any page component executes. That is protection as the default, not an opt-in — a new screen only has to land in the right folder to be secured; there is no separate opt-in step to remember. Public routes (marketing, `/sign-in`, `/sign-up`, `/forgot-password`, `/reset-password`, `/pricing`, `/how-it-works`, `/invite/*`, `/style-guide`) live *outside* the group, deliberately — the group's boundary is the security boundary, not a naming convention layered on top of one. Route a new screen wrong — inside the public tree because it "just needs one quick check" — and it ships unauthenticated. Route it right and it inherits the guard for free. There is no third option, no per-page `if (!session) redirect()` to remember or forget. ## `proxy.ts` is the second layer, not the first Kintwadi also runs a fail-closed edge allowlist in `proxy.ts`: every route is gated unless explicitly listed as public. If a route isn't on the allowlist, it stays protected, even if nobody remembered to add it — the safe failure mode is "blocked," not "open." But `AGENTS.md` is explicit that this is *only* the optimistic edge layer,