F3-Nation/f3-nation

For everyone When someone opens a member's Edit User window in the Admin app, the browser's developer console prints "A component is changing an uncontrolled input to be controlled", and in development a red "1 Issue" badge appears in the corner. Nothing visibly breaks and saving works, but the badge hides real problems from people debugging. This is the same problem as #1185 (which covers the Region/Area/AO edit window), in a second window that #1185 doesn't mention: the user editor. Found during a local test of PR #1150; also happens on main (the PR doesn't touch this file). For the coding agent Root cause. apps/admin/src/app/_components/modal/admin-users-modal.tsx renders the read-only ID field as <Input placeholder="ID" disabled {...field} /> (around line 269). The modal first renders before user.byId resolves, with defaultValues.id: user?.id ?? undefined, so field.value is undefined; once the user loads, the form gets the real id and the input flips from uncontrolled to controlled

For everyone When an admin opens the edit window for a Region (and the same window is used for Areas, Territories, Sectors and AOs) in the Admin app, the browser's developer console prints a warning: "A component is changing an uncontrolled input to be controlled." Nothing visibly breaks, and saving still works, but in development the warning also shows up as a red "1 Issue" badge in the corner of the screen, which hides real problems and confuses people who are debugging. It happens because the read-only "ID" box in that window starts out empty-and-unset while the organization's details are still loading, then gets a value once they arrive. The fix is a one-line change that gives the box an empty value until the ID is known. Found while testing a different change locally, and it also happens on main. For the coding agent Root cause. apps/admin/src/app/_components/modal/admin-org-edit-modal.tsx renders the ID field as <Input placeholder="ID" disabled {...field} />. For an existing org

For everyone When a new user finishes the "Welcome" step during sign-in (for example, signing in to the Admin app for the first time), the browser console shows a CORS error and a "Failed to fetch RSC payload … Falling back to browser navigation" message. Sign-in still completes, so nobody is blocked. But the error adds noise to the console and to error reports, and it costs an extra round trip on every first sign-in. Found during a local test of PR #1169; also happens on main. For the coding agent Root cause: apps/auth/src/app/onboarding/page.tsx finishes onboarding with router.push(callbackUrl) (line 103; the 401 path near line 43 does the same with a same-origin URL). callbackUrl is /api/oauth/authorize?..., an API route that answers with a 302 to the client app's own origin (e.g. http://localhost:3002/api/auth/callback). router.push makes Next do a client-side RSC fetch, which follows the redirect cross-origin and fails CORS preflight. Next then falls back to a full navigation. F

For everyone Why this exists While fixing the cross-org write leaks from #1156, a code review spotted two patterns copied across many API files. They aren't bugs, and they were left out of that fix on purpose to keep the security change small and easy to review. "Does the caller have this role on any of these orgs?" is written out by hand in several places as the same loop. One copy is in user.crupdate, and others are in user.byId, user.byOrgs and the PII-access helper. Each copy is a chance for one of them to drift from the others. "Find the Nation org" is a separate hand-written query in about six places. They don't all agree on how to find it: some take the first nation row, some match by name, and one uses a hard-coded id. The test database has more than one nation org, and that already caused one bug during the #1156 work. What success looks like There is one shared helper for each pattern. Every existing call site uses it, and behaviour doesn't change. For the coding agent Pur

Summary Follow-up to the packages/db env split (PR #1148). That PR gives the @acme/db CLI (migrate, seed, reset, drizzle-kit, reset-test-db) its own packages/db/.env, following Turborepo's convention that anything run directly owns its env file while library code only reads process.env. This issue tracks the remaining work, which was intentionally kept out of scope of #1148 to keep that PR focused on the DB package. Accurate consumer (correction) apps/api already loads its own apps/api/.env (which defines DATABASE_URL/TEST_DATABASE_URL) and does not read packages/env/.env. The actual remaining reader of the shared packages/env/.env is packages/api (the @acme/api package), whose with-env is dotenv -e ../env/.env -- and drives its test/script commands. Problem After #1148 there are two sources of truth for the test database address: pnpm -C packages/db reset-test-db reads TEST_DATABASE_URL from packages/db/.env the @acme/api (packages/api) test suite reads TEST_DATABASE_URL from package