[antoinetoussaint-byte]

Closes #1293.

The host bound the caller's organisation and user to setting names of its own —
app.current_org_id and app.current_user_id — while the platform's Postgres
library defaults a scoped transaction to codefly.current_tenant_id /
codefly.current_user_id (codefly-dev/service-postgres, libs/go/store.go),
which is what the other platform stores read. With the document store moving to
the library's names in its own repository, the host was the last store on
app.*. This moves it, and changes nothing else: transaction-local,
fail-closed, forced, NOBYPASSRLS roles, app_tenant as the request default,
app_control_plane on its own login.

Classification: a fix, at the place that owns the behaviour. No stopgap.

What moved

• 65_library_scope_settings.up.sql / .down.sql — 75 policies over 70
  relations, 9 function bodies, and the 6 partitions of public.audit_events.
  Generated from pg_policy and pg_proc rather than written by hand: the
  catalog is the only place that knows the whole set, and each expression below
  is the catalog's own rendering under an empty search_path — which is how
  the baseline's text was produced, and what makes the deparser schema-qualify,
  which the ledger requires. Only the two setting names are substituted.
  • The audit partitions carry their own copies of the parent's policies, and
    their names depend on the month, so the migration ends by calling migration
    34's public.audit_events_secure_partition over pg_inherits. That is the
    ledger's own mechanism for exactly this, and the one the runtime partition
    creator already calls — reused, not re-implemented.
  • The nine function bodies are not all the installer's to replace. The
    baseline hands seven of them to an application role (enqueue_job_message
    to app_job_worker, six to app_control_plane), so each is replaced as
    its owner, holding CREATE on the schema for that one statement and
    giving it back — migration 64's idiom, generated here. See What the first
    CI run caught below.
• WithScopeSettings is gone (pkg/infra/postgres.go). The store is built
  through the library, so the override was a second place to keep the two names
  in step; the library's defaults are now what the policies read.
• One constant per setting, infra.TenantScopeSetting /
  infra.UserScopeSetting (pkg/infra/tenant_tx.go), and every hand-written SQL
  site in pkg/infra names them from there: bindRequestScopeSQL, the pool's
  sessionReset, postgres_effect_receipts.go, postgres_org.go (×3),
  postgres_team.go.
• TestNoTenantRebindingOutsidePkgInfra is the scan that stops any package
  outside pkg/infra from binding a scope. Its pattern was app.current_,
  so without this change it would have gone blind on the very day the names
  moved: control_plane_call_sites_test.go now matches codefly.current_, and
  its synthetic fixture moved with it.
• rls-migration-gate.mjs now accepts only the two library settings. This is
  the gate that ships to consumers and holds their own migrations to the host's
  convention, so narrowing it is the point: a consumer policy left on
  app.current_org_id reads something nothing binds.
• Docs in the same PR: module/DATABASE_AUTHORITY.md (including the sentence
  that said accounts supplies the settings — it no longer does),
  AUTHZ.md, MODULE.md, module/JOBS.md,
  module/services/accounts/AUTHZ.md, a new rule in
  module/services/accounts/AGENTS.md, two new sections in
  module/services/store/migrations/README.md (the two settings a policy reads,
  and how to replace a function the baseline reassigned), and two rows in
  CLAIM_INVENTORY.md.
• qualification/managed-database/run.py — the RLS assertions there follow the
  rename.

Why the quiet half needed a test of its own

A missed policy does not fail. Nothing binds the old name any more, so
current_setting(…, true) returns NULL, the predicate is false, and that one
relation reads as empty for every caller — or, with the comparison the other
way round, stops isolating. A suite that sets the new name and reads the renamed
policies stays green straight through it.

So TestMigration65RenamesEveryScopeSettingAndNothingElse
(module/services/store/code, in the replay gate's ^TestMigration scope)
stands a database at version 64, fingerprints every row-security decision in
the catalog — each relation's ENABLE/FORCE state, each policy's kind, verb,
role list and both expressions, each routine body, and every relation's and
routine's owner and ACL — applies 65, and requires the result to equal the old
fingerprint with the two names substituted and no other difference. One
equality carries every claim: a moved USING/WITH CHECK shape, verb, role list or
FORCE state is a differing line, and so is a policy the migration missed. It then
proves the renamed policies isolate (bound to org A it sees A's row and only
A's), that binding the retired name admits nothing rather than everything,
and that down 1 restores version 64's catalog exactly.

Mutation-checked: deleting the teams_tenant pair from the migration makes it
fail with the exact line, naming app.current_org_id against the expected
codefly.current_tenant_id.

TestEveryScopedPolicyReadsTheLibrarySettings (pkg/infra) is the standing
version against the live database: no policy, routine, view, constraint, default,
index or rule may read app.current_*, with floor counts so an empty or
mis-written probe cannot pass vacuously.

What the first CI run caught

The first push went red on Authorization coverage: the managed-database
qualification refused migration 65 with pq: must be owner of function enqueue_job_message (42501).

That is a real defect in the migration, and the reason it reached CI is worth
stating. A developer database is installed by a superuser, which owns
everything and may replace anything, so all 75 policies, all 9 functions and
every local test applied cleanly. The principal a managed install actually gets
is LOGIN NOINHERIT NOSUPERUSER NOBYPASSRLS CREATEROLE owning the database —
and the moment the baseline runs ALTER FUNCTION ... OWNER TO app_job_worker,
that principal no longer owns the function. NOINHERIT is what makes the
ownership check fail even though the role is a member, and CREATE OR REPLACE
also wants CREATE on the schema, which an application role is deliberately
not left holding.

The fix is the ledger's own idiom, which migration 64 established for exactly
this, emitted by the generator for each of the seven functions the baseline
reassigned:

GRANT CREATE ON SCHEMA public TO app_job_worker;
SET LOCAL ROLE app_job_worker;
CREATE OR REPLACE FUNCTION public.enqueue_job_message(...) ...;
RESET ROLE;
REVOKE CREATE ON SCHEMA public FROM app_job_worker;

Nothing was relaxed in the qualification, and no policy statement changed. The
diff against the first push is the seven wrappers and the comments explaining
them. Replacing a function preserves its owner and its grants, so the catalog
the migration produces is unchanged — which is why the fingerprint test below
still holds without being touched. The schema ACL comes back byte-identical:
after 65, app_* roles hold USAGE on public and nothing more, exactly as
at 64.

Two things made the miss possible, and the second is now closed: the local
install is a superuser, and the migrations README said nothing about function
ownership. It now has a section on it, including that the qualification needs
only Docker and Go — which is also the correction below.

Verified

Run locally against real PostgreSQL unless noted.

• node module/tools/migration-reference-gate.mjs origin/main --replay — green,
  including TestMigrationUpgrade (clean-install equivalence) and the new
  migration-65 test.

• All six declared accounts targets: -tags=pure ./..., ./pkg/business,
  ./pkg/infra, ./pkg/auth/pg, ./pkg/billing/pg, ./pkg/redisintegration.
  The host-interface conformance suite's isolation cases are in pkg/adapters
  and pass unchanged in meaning — nothing there names a setting.

• python3 scripts/qualify-scoped-pools.py — 6 declared tests ran and passed,
  0 skipped. This is the direct proof that dropping WithScopeSettings makes the
  production constructor bind the library's names: those fixtures' own policies
  read them.

• node module/tools/rls-migration-gate.mjs check, node --test module/tools/*.test.mjs (239), module/tools Go suites,
  node module/tools/naming-gate.mjs check, scripts/check-boundaries.sh.

• python3 qualification/managed-database/run.py — 141 tests, passed. On the
  first push I wrote that this needed a fixture this machine could not produce.
  That was wrong: it needs only Docker and Go, it is what caught the ownership
  defect, and it is now run. It installs the ledger twice — once as a superuser,
  once as the least-privileged principal a managed install gets — and requires
  one schema, one authority catalog and one seed catalog from both. Its rollback
  leg reversed all 35 migrations above the irreversible frontier, so migration
  65's down half is proved under that principal as well.

  • On an arm64 machine, ci.py cross-builds the migrate binary for
    GOARCH=amd64 while the pinned postgres image resolves to arm64. I built
    golang-migrate for the container's architecture from the same pinned
    service-postgres module and passed it to run.py --migrate; CI's own
    amd64 runners are unaffected, so this is a local-only step and not a change
    to the gate.

Two things left as they were, deliberately

• Five documents keep the old names: RLS_PLAN.md (headed Historical),
  APPROVALS_DESIGN.md, module/docs/adr/0003,
  docs/authorization/2-proposals/0001 and the ltree-record-shares spike. Each
  records a design or decision as it was written, and each already names the
  long-gone app.bypass, so renaming half of each would make it read as current
  state. CLAIM_INVENTORY.md says so in a row of its own — the repo's rule is
  not to "fix" a historical document into the present tense.
• The generator is not committed. Migration 65's content came from a live
  catalog at version 64, which a reviewer cannot re-run; the migration-65 test
  proves the property independently of how the bytes were produced, which is the
  stronger guarantee.

Upstream, for a follow-up

service-postgres does not export its two default setting names as constants, so
this repo names them once itself against the library's documented default; and
WithScopeSettings's doc comment says the defaults are app.current_tenant_id /
app.current_user_id, which contradicts the code two hundred lines below it. Say
the word and I will file both against that repo.

Overlap

Checked #1292 (host-interface conformance in CI): it touches pkg/adapters, CI,
module/tools/modulepackage and the module manifest. This touches migrations,
pkg/infra, the RLS gate and docs. No file in common.

Checked #1298 (central RBAC enforcement, denial counter, provider sign-out,
audit archive), opened after this one. It adds no migration, so migration 65
is uncontested. Five files are common: pkg/business/service.go and
pkg/business/store.go, where each PR adds to a struct and an interface, and
AUTHZ.md, CLAIM_INVENTORY.md and module/JOBS.md, where each adds its own
section. Those are textual conflicts at rebase, not semantic ones — neither PR
changes a line the other depends on. Whichever lands first, the second rebases;
nothing needs to be re-decided. #1298 is currently red on eleven checks and
merge-blocked, so there is nothing to rebase onto yet.

🤖 Generated with Claude Code