02 — P0 Capability Unlock & DOT-Only Guardrail Proof — 2026-06-22

The decisive question

Does retrieving Directus/PG admin credentials from Secret Manager unlock a lawful capability to make C1 governed dry-run ready? Answer: NO. Credentials are present, but the lawful path requires an execution channel that does not exist in this environment, and the only thing the credentials could do here is forbidden manual mutation.

E1 — Secret Manager / credentials: PRESENT

gcloud secrets list succeeds; DIRECTUS_ADMIN_TOKEN, DIRECTUS_TAC_ADMIN_TOKEN, PG_PASSWORD, POSTGRES_PASSWORD, etc. exist (file 01). So the prior-run premise "creds ABSENT ⇒ staged" is now resolved: creds are NOT absent.

E2 — The lawful registrar is an ON-DEPLOY CLI (no reachable execution channel)

From dot_tools (live):

code	file_path	trigger_type	last_executed
DOT-REGISTER (dot-dot-register)	bin/dot/dot-dot-register.ts	on-deploy	NULL
DOT_COLLECTION_REGISTER	opt/incomex/dot/bin/dot-collection-register	—	NULL
DOT_COLLECTION_CREATE	opt/incomex/dot/bin/dot-collection-create	—	NULL
DOT_SCHEMA_TABLE_REGISTRY_ENSURE	opt/incomex/dot/bin/dot-schema-table-registry-ensure	—	NULL
DOT_SCHEMA_ENSURE	opt/incomex/dot/bin/dot-schema-ensure	—	NULL

These are scripts/binaries invoked by the deployment pipeline. The tools available here cannot execute them: query_pg is read-only SQL; read_file is read-only (allowlisted); write_file writes docs only (/opt/incomex/docs/mcp-writes); directus_read is read-only; list_docker/docker_logs are read-only (socket mounted RO); there is no command-execution / migration-runner / docker exec tool. So even with the Directus admin token or PG password, there is no governed channel to run the registrar.

E3 — The DB dispatcher cannot execute / register

fn_process_agent_api_dispatch (full source read) returns, verbatim: "PLAN_ONLY/VERIFY_ONLY validation only; dispatcher cannot execute a DOT and never writes DRY_RUN/REAL_RUN." It validates a contract and at most writes an audit observation; it does not create collections, tables, registry rows, or contracts. REAL_RUN is always refused.

E4 — No governed self-service registrar FUNCTION exists

Scan of all public functions for INSERT INTO dot_agent_api_contract → 0. For INSERT INTO dot_tools → only auto_apply_approval (an approval-flag writer, not a contract/DOT registrar). Conclusion: DOT contracts are registered by operator/migration (the 2 existing rows carry source_macro=DOT_AGENT_API_CONTRACT_DISPATCHER_2026_06_04), not by any callable governed path.

E5 — No registrar Directus Flow

100 flows listed. The [DOT-REG] … -> AD flows are change-data-capture syncs (they react to table_registry/meta_catalog/dot_tools changes and push to Agent Data); none creates governed surface or registers a contract/endpoint. No "create collection" / "register DOT" operation flow exists that an admin token could trigger.

E6 — The DB enforces DOT-only (manual writes blocked by design)

dot_config: iu_create.gateway.direct_insert_policy=block_after_guard, iu_create.gateway.mode=enforced, canonical-writer marker app.canonical_writer=fn_iu_create. fn_assert_safe_for_dot_action() aborts on any preflight BLOCK (incl. fs_snapshot_present=0). fn_birth_gate() runs 5 pre-birth checks. Manual bypass writes are rejected at the trigger level — so even a PG-superuser manual INSERT is both forbidden (macro) and guard-blocked (runtime).

DOT-only guardrail proof (what this macro did NOT do)

• ❌ No manual psql CREATE/INSERT/UPDATE against governed runtime.
• ❌ No manual Directus collection/field/function creation.
• ❌ No manual registry-row insertion.
• ❌ No use of the Directus admin key / PG password outside a DOT-approved path (values never accessed).
• ✅ Only read-only probes + non-mutating dispatcher validation calls (p_write_observation=false) were performed.

Verdict for P0

Capability discovery = success; capability unlock into a lawful path = LOCKED. The gap is an operator/deploy-only execution channel for the registrar, not a missing credential. ⇒ contributes C1_DRYRUN_CAPABILITY_LOCKED_OPERATOR_ACTION_REQUIRED.