fix(config): stop treating disabled data api as enabled (CLI-2591)

[7ttp]

TL;DR

fixes disabled data api detection in the shared mapping used by config diff, config push and config pull

what's hurting the users?

the v2 project config returns pg_pgrst_no_exposed_schemas when the data api is disabled, but the mapping treated any nonempty value as enabled

config push started hitting this in stable v2.117.0 when it switched from the v1 /postgrest read to the shared v2 mapping

fixed now by:

remoteDataApiDisabled recognizes both "" and the exact marker.
api.enabled now uses that same check as schemas, extra_search_path and max_rows

before/after:

with local api.enabled = false, the remote marker, and no unrelated drift:

invocation	before	now
config diff --exit-code	reports false api drift; exits 2	no differences; exits 0
config push --yes	sends {"db_schema":""} again	api config is up to date
config pull --yes	proposes enabling the api and importing the marker as a schema	proposes no api changes

explicit api.enabled = true now re-enables the api with default schemas
custom schemas still work. schema-only changes with enablement undeclared require an explicit enable request...

rep:

flowchart TD
    off["data api disabled"]
    off --> v1["v1: empty db_schema"]
    off --> v2["v2: platform marker"]

    v1 --> legacy["v2.116.0 push"]
    legacy --> disabled["reads disabled"]

    v2 --> shared["push from stable v2.117.0"]
    shared --> before["before: nonempty means enabled"]
    before --> wrong["reads enabled"]

    shared --> after["now: empty or exact marker means disabled"]
    after --> disabled

Loading

ref:

• closes config diff reports api.enabled = true after config push disables the Data API (pg_pgrst_no_exposed_schemas) #6932
• regression introduced in feat(cli): rebuild config push as diff-first partial updates (CLI-2313) #6454

[github-actions]

🤖 AI Review

Both independent reviews were available. Verified Claude’s two findings: confirmed a minor gap in marker-specific command integration coverage and refuted the constant-extraction nit using trusted testing conventions. The implementation consistently recognizes both disable sentinels; no runtime defect was identified. Tests were not run.

Findings

Severity	Location	Category	Sources	Claim
🟡 MINOR	apps/cli/src/commands/config/push/push.integration.test.ts:563	test-coverage	claude	Marker-specific integration tests cover diff cleanliness and an already-disabled push, but do not cover config pull or pushing api.enabled = true to re-enable a marker-disabled remote.

Refuted findings (kept for transparency, not posted as review comments)

• packages/config/src/project-config/registry.ts:38 (maintainability): The platform marker literal is repeated in the predicate and tests; an exported constant would centralize it and let tests import it.
  Refuted: There is only one production comparison; the other executable occurrences are independent test fixtures. trusted/CLAUDE.md:139 explicitly permits duplication rather than unnecessary test abstractions. The unit fixture at project-config.unit.test.ts:730-736 independently checks recognition of the exact platform string. Exporting the production constant solely for those fixtures is unnecessary under the documented convention.

Stats

Claude findings: 2 · Codex findings: 0 · Confirmed: 1 · Refuted: 1 · Uncertain: 0

---

Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: auto · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.