05 — Bypass Resistance Audit (read-only)

Test: "cố ý làm nhầm cũng không có cơ hội" — can an actor (mistakenly or deliberately) create an object that escapes birth/orphan/onboarding?

1. Privilege layer

table owners: dot_tools=directus, pivot_definitions=directus, birth_registry=directus
explicit grants (role_table_grants): only context_pack_readonly = SELECT (the audit role)
audit session role: context_pack_readonly

• Finding BP-1 (G7): the application connects as directus, which OWNS all three tables. A table owner has implicit full DML and DDL on its tables — it can INSERT directly, ALTER TABLE … DISABLE TRIGGER (turn birth off), and SET app.bypass_birth_gate='true'. workflow_admin is superuser (per established channel). So at the privilege layer there is no bypass resistance against the very roles that perform writes.

2. Birth gate is not a hard stop

• fn_birth_gate defaults to warning (non-blocking) and honors the kill-switch GUC app.bypass_birth_gate, and returns early when code is NULL/empty. So three independent ways to pass a non-compliant row: (a) rely on the default warning mode; (b) set the bypass GUC; (c) insert with an empty code (the AFTER trigger still synthesizes a birth row, but the gate's quality checks are skipped). (G1)

3. Channel-by-channel bypass map

Channel	Creates an object that escapes birth?	Why
Direct SQL INSERT into a triggered table (as directus/admin)	Birth ROW auto-created (good), but quality gate is advisory → a non-compliant row still lands.	gate=warning
Direct INSERT into an UNregistered table (e.g. a new table, or dot_iu_command_catalog)	YES — fully escapes	no trigger, not in collection_registry
Directus API write	Same as direct INSERT (Directus → role directus = owner)	gate advisory; no app-side birth check
ALTER TABLE … DISABLE TRIGGER / SET app.bypass_birth_gate	YES	owner/superuser privilege
ssh file creation in /opt/incomex/dot/bin	YES — fully escapes	birth is DB-row-triggered; files create no row; no scheduled FS reconciler
DOT script creation (a .ts/bash file)	YES — fully escapes until/unless registered in dot_tools	same as above; this is exactly dot-pivot-update
Manual INSERT blocked by constraint?	No hard constraint — birth_registry has UNIQUE(entity_code) but the source tables have no NOT-VALID-without-birth FK/CHECK; the only guard is the advisory BEFORE trigger	—

4. Is manual insert blocked by trigger/constraint or only policy?

Only policy. There is no FK or CHECK on source tables forcing a prior birth row; the BEFORE gate is advisory and bypassable; the AFTER trigger creates birth after the fact and only on triggered tables. So the enforcement is policy-grade, not constraint-grade (G1/G7).

5. Rollback-proof safety

• A write-rollback proof (BEGIN; INSERT; observe; ROLLBACK) would require the directus/workflow_admin write channel (ssh docker exec psql), which was available but was deliberately not used — default-no-mutation + the read-only evidence is decisive and the forbidden list bars manual INSERT to the relevant tables. See doc 06.

6. Verdict

Bypass resistance is weak: the only standing guard is an advisory, owner-bypassable BEFORE trigger on ~16 of ~100+ governed tables; unregistered tables and all filesystem artifacts have no guard at all. A deliberate mistake has ample opportunity. Target NOT met.