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 `@adapters/postgres/internal/connection/conn_test.go`:
- Around line 65-67: The dbConnect test stub in conn_test.go is calling
require.Equal inside a spawned goroutine, which can trigger unsafe FailNow
behavior. Update the dbConnect replacement used by the test so it only captures
the driverName/dataSourceName values or any error inside the goroutine, then
perform the require.Equal assertions back in the parent test goroutine around
the connTest/connection flow.

In `@adapters/postgres/internal/connection/conn.go`:
- Around line 25-30: `Manager` has unsynchronized mutable fields, so concurrent
calls can race when `getPool()` initializes `m.pool` and when `currDatabase` is
read or updated during database switching. Add synchronization in `Manager` (or
guard these fields with the existing pool locking strategy) so `getPool`, the
database selection path, and any methods that read/write `currDatabase` access
shared state safely; use the `Manager` type and `getPool()` as the main fix
points.
- Around line 164-166: The error handling in the database connection path logs a
sanitized error but still panics with the raw err, which can leak sensitive
details. In the connection logic around the existing slog.Error call in conn.go,
update the panic in the same err != nil block to use the redacted/logsafe
version of the error as well, keeping the panic message consistent with the
sanitized logging.

In `@adapters/postgres/postgres.go`:
- Around line 98-105: The lazy initialization in postgres.getStmts() can race
when multiple requests hit the shared adapter instance at first use. Guard the
p.stmts creation with synchronization (for example, reuse an existing mutex on
postgres or add a dedicated init lock) so only one goroutine can initialize the
Stmt struct. Keep the change localized to getStmts() and the postgres / Stmt
fields involved.
- Around line 179-185: The `...Ctx` transaction/write paths still drop the
request context after selecting the DB, so canceled requests can continue via
non-context calls. Update `GetTransactionCtx` and the other affected `...Ctx`
helpers to pass `ctx` through to `BeginTx`, `ExecContext`, `QueryContext`, and
`QueryRowContext` instead of `db.Begin`, `stmt.Exec`, `stmt.Query`, or helper
methods that use non-context variants. Make the same change in the related
write/transaction entrypoints referenced by the review so all context-aware
paths in `postgres` honor cancellation consistently.
- Around line 904-909: The read-path error logging in postgres still emits raw
connection errors, which can leak DSN credentials. Update the error handling in
QueryCtx and the other affected read paths (including the dbFromCtx/conn.Get
call sites in the postgres adapter) to use the same redacted logging approach as
adapters/postgres/queries.go, replacing direct slog.Error(err) logging with
logsafe.Error(err) or equivalent safe redaction. Keep the existing return
behavior unchanged, but ensure the logged error is sanitized wherever these
connection failures can occur.

In `@app/app.go`:
- Around line 26-31: New currently always creates and connects a new Postgres
adapter, which overwrites any adapter already present on cfg.Adapter. Update New
to first check cfg.Adapter and reuse it when non-nil, only calling postgres.New
and postgres.Connect when no adapter has been injected. Keep the cfg.Adapter
assignment in the connect path so the existing adapter reference is preserved
and the new adapter is only created when needed.
- Around line 70-73: The error handling in app initialization is too broad: in
the db, err := postgres.DB(cfg.Adapter) path, only the sentinel type-assertion
failure should become ErrAdapterNotPostgres. Update the error translation in the
DB() setup logic to detect that specific sentinel and return it, while
preserving and returning any other error from the adapter’s DB() implementation
unchanged.

In `@cmd/prestd/main.go`:
- Around line 19-25: The startup flow in main currently calls app.New(cfg)
before Cobra command selection, which eagerly connects to Postgres and breaks
non-serve subcommands. Move app.New creation out of the top-level startup path
and initialize it only in the serve execution path, while keeping DB-dependent
subcommands like migrate and version working off the parsed cfg after Cobra has
selected the command. Use the existing main, cmd.Execute, and app.New symbols to
relocate the initialization lazily.
- Around line 19-22: The startup error logging in main should not write err
directly because it can expose DSNs or credentials. Update the app
initialization failure path around app.New in main to pass the error through the
internal/logsafe redaction helper before calling slog.Error, and keep the
existing exit behavior unchanged.

In `@config/config.go`:
- Around line 134-149: The Load path still only logs when required directories
cannot be created, so startup can continue with an unusable queries/cache setup.
Update the directory preparation logic in Load to fail fast by returning the
MkdirAll error for the queries directory and the cache storage directory,
instead of just calling slog.Error and continuing; if any directory is meant to
be optional, make that behavior explicit in the cfg handling before setupLogger
is called.
- Around line 130-153: The Load flow still relies on the package-level Viper
singleton, so config paths can leak across repeated calls. Update Load to create
a fresh Viper instance with viper.New(), then pass that instance into Parse and
any helper that reads config so each call is isolated. Keep the existing Load,
viperCfg, and Parse flow intact otherwise, but ensure the new instance is used
for all config resolution instead of the shared global state.

In `@controllers/health_db.go`:
- Around line 7-12: The health check setup currently leaves DefaultCheckList
empty, so controllers/deps.go can build a health handler with no DB verification
when NewHandlersFromConfig/NewDepsFromConfig is used outside app.New. Restore
the ping-based DB check by wiring CheckDBHealth(pinger.Ping) into the
dependency/handler construction path, or repopulate DefaultCheckList for
DatabasePinger-backed adapters so every health endpoint includes the DB check.
Use the existing symbols DefaultCheckList, CheckDBHealth, NewHandlersFromConfig,
and NewDepsFromConfig to place the fix.

In `@integration/adapters/postgres/postgres_test.go`:
- Around line 30-44: The shared test config/adapter setup in setupTestDB and
testAdapter is reusing the same mutable *config.Prest and Adapter instance from
helpers.LoadTestConfig(t), which makes the postgres tests order-dependent and
unsafe for parallel execution. Update setupTestDB to clone the loaded config for
each test and construct a fresh adapter instance from that copy instead of
returning testCfg.Adapter directly, so each test gets isolated AccessConf,
cache, and statement-cache state.

In `@integration/helpers/setup.go`:
- Around line 67-98: LoadTestConfig is returning a shared cached *config.Prest
from the package-level loadedCfg, which lets per-test mutations leak across
callers and makes tests order-dependent. Keep the one-time config/database setup
in loadOnce, but have LoadTestConfig create and return a fresh copy of the
initialized config on each call (including the Adapter and Debug settings)
instead of handing out loadedCfg directly. Use the LoadTestConfig function and
the loadedCfg/loadOnce state as the main places to update.

In `@internal/logsafe/logsafe.go`:
- Around line 9-10: The password redaction regex in passwordKV currently stops
matching when the value starts with quotes, so quoted DSN passwords can leak.
Update the pattern and any related masking logic in logsafe.go so values like
password='...' and password="..." are also fully redacted, while preserving the
existing pgURLCreds handling for URL-style credentials. Make sure the change is
applied where the regexes are defined and verified against quoted and unquoted
password forms.

In `@plugins/plugins.go`:
- Around line 67-87: Return an error instead of panicking when plugin symbols
are malformed in plugins.go. In the code path that looks up HTTPVars, URLQuery,
and the handler symbol via p.Lookup and then asserts to func() string / func()
(string, int), switch to the same checked type-assertion pattern used in the
middleware loader so bad plugins flow through the handler error path. Update the
logic around the plugin lookup and the handler selection in the relevant plugin
execution function to validate each symbol before dereferencing or calling it,
and surface a descriptive error when the expected type is not present.
- Around line 43-47: The plugin cache maps in `loadedFunc` and
`loadedMiddlewareFunc` are accessed concurrently by `Handler()` and
`Middleware()` without synchronization, which can trigger concurrent map access
panics. Add a small mutex guard around each cache’s read/write path in the
plugin loading flow, keeping the locking local to the loader logic that consults
and updates these maps.
- Around line 66-87: The request-handling code in the plugin lookup path is
mutating shared plugin globals by assigning mux Vars and URL query data into
HTTPVars and URLQuery, which can be overwritten by concurrent requests. Update
the plugin invocation flow around the Lookup calls in the handler dispatch logic
to avoid writing request-specific data into package-level symbols; instead pass
vars/query into the per-request handler call or protect the entire plugin
invocation with serialization so each request sees isolated data.

---

Outside diff comments:
In `@adapters/postgres/queries.go`:
- Around line 126-145: WriteSQLCtx is ignoring the supplied context after
dbFromCtx(ctx), so prepare/exec won’t honor cancellation or deadlines. Update
WriteSQLCtx (and the similar ExecuteScriptsCtx path referenced in the review) to
use context-aware database/statement operations throughout, keeping the context
from the call all the way through prepare and execution. Use the existing
postgres methods and scanner.PrestScanner error handling, but switch the
non-context calls in WriteSQLCtx to their ctx-aware equivalents so cancellation
propagates correctly.

In `@cmd/root.go`:
- Around line 53-55: RootCmd.Execute currently logs raw errors with slog.Error,
which can leak sensitive DB/bootstrap details. Update the error handling in
RootCmd.Execute’s failure path to pass the error through logsafe.Error before
logging, and keep the existing command-execution context in the message while
using the redacted value for the error field.

In `@integration/adapters/postgres/postgres_test.go`:
- Around line 2456-2481: Reset AccessConf.Users for each test case instead of
appending to the existing slice. In the postgres test setup around the
field-permission cases, clear testCfg.AccessConf.Users alongside
testCfg.AccessConf.Tables before rebuilding the per-case config, so the
UsersConf entries for foo and bar come only from tt.args.userFields and
tt.args.user2Fields and do not carry over stale definitions between cases.

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

Nitpick comments:
In `@config/config.go`:
- Around line 163-246: The config path is still stored in the package-level
configFile global inside viperCfg(), which leaves mutable shared state and can
race with Parse() reading it later. Stop assigning to the package var in
viperCfg(); instead return the resolved config file path from viperCfg() (or
attach it to the Prest/config object being built) and pass that value into
Parse() explicitly so Load(), viperCfg(), and Parse() no longer depend on
unsynchronized global state.

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 `@adapters/postgres/postgres.go`:
- Around line 158-180: The prepared-statement cache in Stmt.PrepareContext is
keyed only by SQL, so statements can be reused across different selected
databases. Update the cache to be DB-scoped (for example by changing PrepareMap
to use a per-DB key or per-DB nested map) and keep the lookup/insert logic
inside PrepareContext aligned with that key. Also re-check the cache after
preparing under lock, and if another goroutine already stored a statement, close
the duplicate prepared statement before returning the cached one to avoid leaks.

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 `@config/config.go`:
- Line 128: Load() is swallowing config read/parse failures by calling Parse(v,
cfg, configPath) and then continuing, which lets malformed or unreadable config
files fall back to defaults. Update Load() in config/config.go to detect and
return an error for any config read/parse failure, while still allowing only the
missing-config case to proceed with defaults; use the Parse call site and the
Load() flow to locate where to thread the error back to the caller instead of
logging and continuing.

---

Outside diff comments:
In `@config/config.go`:
- Around line 129-142: Handle non-ENOENT failures from the os.Stat checks in
Load so inaccessible queries/cache paths do not get ignored. In the
cfg.QueriesPath and cfg.Cache.StoragePath existence checks, only create the
directory when os.IsNotExist(err) is true; if Stat returns any other error,
return it immediately instead of continuing. Keep the existing setupLogger flow
unchanged, and apply the fix in the Load path around the os.Stat/MkdirAll logic.
- Around line 237-242: The homedir lookup in the config initialization leaves
queries.location unset on failure, which can later make cfg.QueriesPath empty.
Update the logic around homedir.Dir() in the config setup to always set a
fallback default for queries.location when the home directory cannot be
resolved, while still logging the lookup failure with slog.Error. Use the
existing configuration flow that sets v.SetDefault("queries.location", ...) so
startup has a usable path even without a resolvable home directory.

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

Nitpick comments:
In `@adapters/postgres/postgres_exec_test.go`:
- Around line 267-288: The per-database cache test in
TestQuery_WithStatementCachePerDatabase only checks routing to defaultMock and
ctxMock once each, so it does not verify statement reuse. Update the test to
call adapter.Query("SELECT 1") twice for the same database with only one
ExpectPrepare on defaultMock, and similarly ensure QueryCtx against
contextMockDB can reuse the prepared statement on a repeated call. Keep the
existing Query and QueryCtx paths, but make the expectations prove the cache hit
occurs by not allowing a second prepare on the same mock.

In `@config/config_test.go`:
- Around line 56-89: The permission-denial assertions in TestLoadStatErrors are
platform-dependent because inaccessiblePath uses os.Chmod to simulate
os.ErrPermission. Update the test setup so the subtests are skipped or gated
when running as root on Unix (using os.Geteuid() == 0) and when the runtime is
Windows, and keep the Load-based error checks only for environments where
permission bits are enforced. Use the existing TestLoadStatErrors and
inaccessiblePath helpers to place the guard cleanly around both subtests.

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

Outside diff comments:
In `@adapters/postgres/postgres.go`:
- Around line 1167-1219: BatchInsertCopyCtx and the other write helpers are
still preparing statements without honoring cancellation from the passed
context. Update BatchInsertCopyCtx to use the context-aware prepare path on the
tx, and make InsertCtx, DeleteCtx, UpdateCtx, and the shared fullInsert/Prepare
flow use PrepareContext instead of Prepare so ctx cancellation can propagate
before execution. Use the existing symbols BatchInsertCopyCtx, fullInsert, and
the Prepare calls to locate and adjust the write paths consistently.

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 `@adapters/postgres/testmain_test.go`:
- Around line 10-22: The TestMain timeout in testmain_test.go is duplicating the
same 30s limit already enforced by go test -timeout, causing a race between the
two shutdown paths. Update TestMain’s testSuiteTimeout to leave clear headroom
below the CLI timeout, or remove the custom timeout entirely, so the native go
test timeout remains the primary failure mechanism. Keep the change localized to
TestMain and the testSuiteTimeout constant.

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

Nitpick comments:
In `@cmd/auth.go`:
- Around line 18-27: The auth command is calling app.EnsureAdapter(cfg) twice
because app.PostgresDB(cfg) already performs that check internally. Remove the
explicit EnsureAdapter call in cmd/auth.go and keep the adapter setup handled by
PostgresDB, using configFrom(cmd), app.PostgresDB, and the subsequent db.Exec
flow as the single path.

In `@cmd/root.go`:
- Line 63: Update Execute in RootCmd so it accepts a caller-provided ctx instead
of always creating a fresh context.Background(), then pass that ctx into
withConfig before SetContext. This lets main.go or other callers propagate
cancellation for future graceful shutdown support while keeping the RootCmd
setup flow unchanged.