audit_config answers a PostgreSQL target with its own settings: the CONFIG_PG_* facts projected into the same recommendations shape, engine in place of edition, and the two checkpointing knobs marked not applicable on Aurora (#3691 line 70)

[erikdarlingdata]

What a PostgreSQL operator now learns

audit_config on a PostgreSQL target used to answer an honest refusal: this tool evaluates SQL Server settings, go call get_analysis_facts with source pg_config. True, and useless — the caller had already asked the right question of the right server, and was sent to a different tool to ask it again. This lane projects the analysis pass's CONFIG_PG_* facts into the same recommendations shape the SQL Server arm returns, so one call answers "how is this server configured, and what about it is worth looking at."

PARTIAL for #3691 — do not close. The checklist line completed, verbatim:

audit_config for a PostgreSQL target answers the honest not_collected envelope (plumbing); a CONFIG_PG_* projection into the same tool is a description-contract change — decide.

Erik's ruling (2026-09-22 02:23Z): YES, with two riders, both landed here:

1. The projection inherits the calibrated Aurora honesty. CONFIG_PG_CHECKPOINT_TIMEOUT and CONFIG_PG_MAX_WAL_SIZE render status = not_applicable on aurora-postgres, counted on their own summary line and excluded from settings_checked — a knob the engine does not consult was not checked, and folding it into that count would have the audit overstate what it looked at. Neither is ever a finding.
2. The residual edition-awareness drift is fixed in the same lane, so the description contract changes ONCE. The Brains-review campaign: deferred structural residue (from #3538 / #3539 / #3540 / #3541) #3653 description fix had already landed; what remained were three doc comments still claiming edition-awareness (PgFactCollector.Resources.cs, Lite's DuckDbFactCollector.Resources.cs, AnalysisSchema.cs v2) — all three now say resource-based / the server-metadata columns the config audit reads, which is what those facts and columns actually enable.

The description, before and after

The first four sentences are unchanged (including "NO check branches on it"). Only the trailing sentence moved:

Before: SQL Server only: for a PostgreSQL target this tool refuses with status not_collected and points at get_pg_server_config, get_pg_logging_audit and the CONFIG_PG_* facts instead of pretending the collector failed.

After: For a PostgreSQL target it projects the analysis pass's CONFIG_PG_* setting facts into the same recommendations shape (setting, current_value with unit, status, recommendation; no suggested_value - the recommendation sentence carries the evidence), reports engine in place of edition, and renders checkpoint_timeout / max_wal_size as not_applicable on Aurora, where the engine manages checkpointing. get_analysis_facts has each setting's full investigation; get_pg_server_config has the raw snapshot.

The instruction table row (DarlingMcpInstructions.cs:99) and the step-7 mention (:340) were updated to match in one sentence each.

What the payload says, and why each difference from the SQL Server arm exists

Every difference is a difference of the engine, and each is stated in the description so the contract changes once:

• engine in place of edition — PostgreSQL ships no editions. The token is the registry's (postgres / aurora-postgres), resolved per call off servers.engine_kind through MonitoredEngineKind, never inferred from a column's presence (PostgreSQL targets have no UI on either SKU, and both UIs render SQL Server tabs at them #2530). edition is absent, not null: a PostgreSQL payload carrying "edition": null would be the same false edition-awareness Brains-review campaign: deferred structural residue (from #3538 / #3539 / #3540 / #3541) #3653 took out of the description.
• current_value is a STRING with its unit — the SQL Server arm's int cannot carry random_page_cost 1.1, shared_buffers 128 MB, checkpoint_timeout 5 min or track_io_timing on. Formatted off the FACT KEY, never sniffed from the magnitude (4 could be a cost ratio or four megabytes; 300 could be seconds or connections), in the same shapes PgTargetAdvice's private Knob* formatters render inside an advice sentence — so one value does not read two ways across two surfaces.
• No suggested_value, at any depth — the right value for a PostgreSQL knob is host- and workload-specific. The advice's remediation sentence carries the evidence and the counter-objective a bare number would strip, which is precisely what the evidence-first discipline forbids shipping. recommendation is the advice headline + remediation; investigation stays in get_analysis_facts, and the description says so.
• threshold_lineage is null, not 0 — the config family stamps no lineage because its bars ARE PostgreSQL's own shipped defaults; there is no chosen number to disclose (PgTargetScorer.Config says exactly this in its class summary). 0 would claim a bar had been chosen unmeasured.
• object_name is OMITTED on a server-level row, present only where the fact carries one (CONFIG_PG_AUTOVACUUM_DISABLED is a per-table reloption). A null table name on a shared_buffers row invites a reader to wonder which table it meant.

The tool grades nothing: severity is the pass's, read off the fact, and this arm only spells it ok / review / warning / not_applicable. Facts are filtered by KEY PREFIX rather than source — the family lives on pg_config, pg_memory (CONFIG_PG_MEMORY_OVERCOMMIT) and pg_vacuum (CONFIG_PG_AUTOVACUUM_DISABLED), so a source filter would silently drop the two checks that are not settings snapshots — and iterated as an ordered LIST, because the reloption check repeats its key per table. Zero facts keeps its own no_config_data envelope naming the health read: no facts is not a refusal.

PgTargetFactKeys.ConfigPgSettingName maps every declared CONFIG_PG_* key to the pg_settings row an operator would go set, beside the constants so a renamed key fails to compile in both places at once. The three that are not one setting are spelled so a reader cannot mistake them for a row they could go read: shared_preload_libraries (pg_stat_statements), shared_buffers + work_mem × max_connections (composite), autovacuum_enabled (table reloption). A bare autovacuum on the reloption row would send an operator to ALTER SYSTEM for something only ALTER TABLE can reach.

Rider 1's second knob

The calibration stamped not_applicable on CONFIG_PG_MAX_WAL_SIZE (lane 15, #3728 §A4) but not on CONFIG_PG_CHECKPOINT_TIMEOUT — correctly, because that fact is base-0 context there and nothing was grading it. It is graded by nothing here either, but this tool renders it as a setting with a recommendation, and the composed context sentence says tune it with max_wal_size, which on Aurora points an operator at a knob the storage layer ignores. Rider 1 names both keys for exactly that reason, so the engine-side arm lives in this tool with the reason written down. Stamping the fact itself (so get_analysis_facts said it too) is the collector's change and lane 15's file — reported, not folded.

Byte-identity

• The SQL Server arm is untouched. Its int current_value, its suggested_value, its edition = editionName echo and every check are byte-identical; the projection row is a separate PgConfigRecommendation record rather than a widening of ConfigRecommendation, so nothing about the new shape can reach it. DarlingMcpToolsTests's existing audit_config body-scan assertions (the only edition reads are the fact lookup and the payload echo) run unchanged.
• Lite is untouched — its audit_config is SQL Server-only by product (no PostgreSQL targets). Worth stating precisely: Lite's description never carried the trailing refusal sentence at all, so there was nothing there to leave in place. Its body and description are unmodified; only the two doc comments under rider 2 changed in that tree.

Tests

Class	What it holds	Executed
PgTargetAuditConfigTests (new, 2 tests)	LIVE, both arms. Planted pg_server_config snapshot → AuditConfig → JSON read: engine present / edition absent, one row per fact, unit-carrying string values (128 MB, 1 GB, 8 GB, 1.1, on, 5 min), statuses off the pass's severities, no suggested_value anywhere in the payload text, threshold_lineage null, object_name omitted, summary arithmetic. Aurora arm: both checkpointing knobs not_applicable with lane 15's verbatim sentence and the engine-side sentence, out of settings_checked, shared_buffers still graded	✅ live, green
PgTargetSharedSwitchRoutingTests (+1 test)	Setting-name census, reflected off the constants: every declared CONFIG_PG_* returns non-null, lower-case, and the three composites say what they are; unknown key and null → null	✅ 74 green
PgTargetMcpSurfaceTests (reworked)	The arm's STRUCTURE: engine read → fact read → StartsWith(PgTargetFactKeys.ConfigPrefix (the CONSTANT, not the literal), no source filter, and not_collected / get_pg_logging_audit gone from the whole tool body	✅ green
DarlingMcpToolsTests (renamed)	…_AndNamesThePostgresProjection: the four stated differences in the tool's own words, plus the refusal no longer promised; "NO check branches" and the body-scan edition assertions unchanged	✅ 16 green
McpPayloadContractCensusTests	not_applicable added to audit_config's status-vocabulary roster line with its reason	✅ 67 green
TsqlConventionGuardTests	The projection row's expression-bodied ToPayload registered in KnownTruncatedRanges with what falls outside the range and why no census reads it there	✅ 14 green
DocCommentHygieneTests / RepoFileAdoptionTests / ServerPageTabsTests / ViewTemplatesTests / PgTargetKnobsTests	Pre-checked, unmoved	✅ 77 / 2 / 19 / 7 / green

Harness: net10.0, AssemblyName=Darling.Tests, inside the worktree, against a throwaway timescale/timescaledb:2.28.1-pg18 (Docker context desktop-linux); torn down, harness deleted before commit. The full Darling.Tests project builds with EnableWindowsTargeting=true (no new warnings).

Self-review — three riskiest hunks

1. The engine-side not_applicable arm (DarlingMcpTools.cs) — it makes this tool say something the FACT does not, which is the shape of an inconsistency between two surfaces. Held by the live Aurora arm asserting the appended sentence's exact text and the stock arm asserting checkpoint_timeout reads ok there; the comment states that the fact-side stamp is lane 15's file, not a fold-in.
2. FormatConfigPgValue's two inversions — CONFIG_PG_AUTOVACUUM_OFF is a finding FLAG (value 1 = the setting is off), and CONFIG_PG_AUTOVACUUM_DISABLED's value is the table's backlog ratio, not its reloption. Both are documented at the method and the shapes a reader would get backwards are pinned by the live stock arm's six rendered values.
3. The ToPayload ternary — the only place a key can silently go missing (two anonymous initializers, one per arm). The live pins read both arms' keys from serialized JSON, and the member-scan roster entry names exactly what falls outside the walker's range.

Reviewer checklist

• The SQL Server arm's payload is byte-identical (separate record; ConfigRecommendation untouched).
• settings_checked excludes not_applicable; not_applicable is its own summary line.
• threshold_lineage is null (absent bar), never 0, on config rows.
• No suggested_value reaches the wire on the PostgreSQL arm.
• Every CONFIG_PG_* constant names a setting (census fails on a new key).

What it does not do

No change to which CONFIG_PG_* facts exist or to any bar; no migration rung; no get_pg_server_config change; Lite's audit_config body untouched; no Viewer change; CHANGELOG buffered, not edited.

Out-of-lane (issue-class, reported not folded)

• CONFIG_PG_CHECKPOINT_TIMEOUT is not stamped not_applicable on Aurora at the COLLECTOR, so get_analysis_facts still shows it unqualified there. Crossing into lane 15's collector file + its calibration pins is a cross-lane edit; this lane made the operator-facing surface true and left the fact where it is.