Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@backend/src/api/routes/config/apply.ts`:
- Around line 38-40: The chained response call is misformatted for Prettier;
replace the multi-line chain with a single properly punctuated statement (e.g.,
return res.status(400).json({ error: 'config_validation', message: err.message,
path: err.path });) so the res.status(...).json(...) call is on one line with
proper semicolon/return to satisfy formatting/lint rules in the apply handler.
- Around line 24-33: The route is currently trusting body.dry_run and body.prune
which can be non-boolean (e.g. "false") and incorrectly enable behaviors; add a
Zod schema to validate/parse req.body (ensuring config?: unknown, dry_run?:
boolean, prune?: boolean) and use schema.parse or safeParse to coerce/validate
values before calling withConfigApplyLock/applyConfig so you always pass actual
booleans (defaulting to false when absent or invalid); reference the request
handler that reads body and the applyConfig call to replace the ad-hoc casting
with the validated result.

In `@backend/src/services/config/apply.test.ts`:
- Around line 33-44: The test title promises applied=true but doesn't assert it;
update the test that calls applyConfig (in
backend/src/services/config/apply.test.ts) to capture the return value from
applyConfig(...) and add an assertion that the returned object's applied
property is true (e.g., expect(result.applied).toBe(true)), keeping the existing
check that setAuthSettings was called with the expected additionalRedirectUrls;
target the applyConfig invocation and the setAuthSettings mock in your change.

In `@backend/src/services/config/apply.ts`:
- Around line 27-48: The current apply logic may persist auth via
setAuthSettings() before bucket changes (upsertBucket/deleteBucket) run, causing
partial updates on failure; modify apply to run all changes inside a single
database transaction (or use an existing transactional API) so setAuthSettings,
upsertBucket and deleteBucket are executed atomically, or if transactions are
unavailable implement compensating rollback that reverses setAuthSettings and
any upsertBucket/deleteBucket effects when a later step fails; update code paths
that call setAuthSettings, upsertBucket, and deleteBucket to accept/participate
in the transaction (or return undo information) and ensure plan.changes
iteration either runs inside that transaction scope or triggers rollback on
error.
- Around line 23-25: The response sets applied: true even when no mutation
happens (e.g., all plan.changes are remove operations with kept === true and
prune is disabled) — update the logic that computes the returned applied flag to
reflect whether any actual mutation occurred: when preparing the result in apply
(use the same scope where input.dry_run, plan.changes and the final applied
value are set) compute a boolean like mutated = plan.changes.some(c => !(c.type
=== 'remove' && c.kept === true)) (and treat dry_run as always false for
mutation detection), then return { plan, applied: mutated } (preserving the
existing early return for input.dry_run or empty changes but ensure
applied=false in those cases).

In `@docs/agent-docs/config-as-code.md`:
- Around line 68-71: The docs overstate concurrency: clarify that taking a
Postgres advisory lock for each `apply` keyed on `(project, "config_apply")`
only enables cross-project parallel `apply` calls in multi-tenant/project-scoped
deployments; in single-tenant OSS installs we serialize all applies on a fixed
project key unless `req.projectId` is present. Update the Concurrency section to
make this conditional (e.g., “in multi-tenant/project-scoped deployments (when
`req.projectId` is set) calls for different projects run in parallel; otherwise
all applies are serialized on a single project key”).

---

Nitpick comments:
In `@backend/src/api/routes/config/apply.ts`:
- Around line 14-16: The getProjectRefFromRequest function currently returns
req.projectId or SINGLE_TENANT_PROJECT_KEY; change it to prefer an env-backed
project by returning req.projectId ?? process.env.PROJECT_ID ??
SINGLE_TENANT_PROJECT_KEY so that process.env.PROJECT_ID is used for self-hosted
deployments and SINGLE_TENANT_PROJECT_KEY ('default') remains only the
last-resort sentinel.

In `@backend/src/services/config/diff.ts`:
- Around line 106-117: deepEqual currently only compares primitives and arrays
and returns false for plain objects; update the deepEqual function to also
handle plain object comparison by: treating null separately, detecting non-array
objects (typeof === "object" && !Array.isArray), comparing their key sets length
and presence, and recursively calling deepEqual on each corresponding property
value (use the existing array handling for arrays and === for primitives as
fallbacks). Ensure the function still short-circuits identical references (a ===
b) and preserves array handling in deepEqual.

In `@backend/src/services/config/schema.ts`:
- Around line 32-51: Replace the hand-rolled validation in validateConfig with a
Zod schema: add imports from z, define BucketConfigSchema, StorageConfigSchema,
AuthConfigSchema and InsforgeConfigSchema using z.object(...).strict() and
optional() for optional fields, derive the InsforgeConfig type with
z.infer<typeof InsforgeConfigSchema>, and update validateConfig to simply return
InsforgeConfigSchema.parse(input); remove the manual checks around
project_id/auth/storage and stop calling validateAuth/validateStorage (instead
embed their schemas or reuse them) so unknown keys are rejected and Zod error
messages are returned.

In `@backend/src/services/storage/buckets.ts`:
- Around line 26-34: The upsertBucket function uses a check-then-act pattern
(bucketExists → createBucket) that is vulnerable to a TOCTOU race; make it
explicit and safe by either adding a short comment above upsertBucket that
callers must hold the withConfigApplyLock when calling it, or make the function
itself resilient by wrapping the createBucket call in a try-catch that treats an
"already exists" error as success and proceeds to update visibility (use the
existing bucketExists, createBucket, updateBucketVisibility symbols for
context); prefer the try-catch approach if you want internal safety, otherwise
document the lock requirement clearly.