02 — DOT Manage Current-State Inventory

Macro: DOT_MANAGE_LEGO_TRANSITION_SURVEY_FOR_C1_DRYRUN · Date: 2026-06-22 · Read-only.

Answers macro §3.1 directly. Every number is from the live read-only probes in 01 (db=directus, 2026-06-22) or from the named KB doc.

1. How many DOTs exist? Where are they registered?

dot_tools = 309 rows (live count(*)). This is the SSOT registry for DOT tools.
Catalogued in meta_catalog as CAT-006 ("DOT Tools", entity_type=dot_tool, registry_collection=dot_tools, layer 5, status=active), kept in sync by dot-catalog-sync at frequency on-deploy (filesystem scan of dot/bin/).
Handbook §5.3 mirrors all 309 rows (one row per DOT) as read-only KB evidence.
Known by-surface divergence (by design, pre-existing): registry 309 ↔ FS 289 ↔ recon 287 ↔ enforcement 272 ↔ runnable 104 ↔ IU catalog 54 ↔ agent-api contracts 2 ↔ runtime leases 0. CAT-006 also carries actual_count=163 (its own scan field) vs record_count=309 — a pre-existing catalog drift, NOT a C1 artifact, but worth a future reconcile.

2. What is CAT-006? `tbl_registry_dot_tools`? `dot_tools`? `dot_agent_api_contract`?

object	what it is	live state
`dot_tools`	the canonical Directus collection / PG table holding one row per DOT tool	309 rows; 28 columns (code, name, domain, operation, status, classification, tier, file_path, coverage_status, extra_metadata, …)
`CAT-006`	the meta_catalog REGISTRY RECORD that points at `dot_tools` (not a pipeline step)	active; record_count 309; sync `dot-catalog-sync` on-deploy
`tbl_registry_dot_tools`	the table_registry entry naming `dot_tools` as a governed registry-class table	present within `table_registry` (21 rows total); no C1 entry
`dot_agent_api_contract`	the dispatch contract registry — which DOTs are bound for agent-API dispatch (producer/verifier, mode, no-mutation assertion)	2 rows only: `DOT_KG_EXPLAIN` (producer, endpoint_bound) + `DOT_KG_EXPLAIN_VERIFY` (verifier, contract_ready)

3. Which DOTs relate to schema / table / registry / directus / create_collection?

75 dot_tools rows match (ILIKE schema/table_registry/directus/create_collection/ensure), all status=active. Load-bearing members for C1:

Schema-ensure family — DOT_SCHEMA_ENSURE (generic), DOT_SCHEMA_TABLE_REGISTRY_ENSURE, DOT_SCHEMA_REGISTRY_COLLECTIONS_ENSURE, DOT_SCHEMA_BIRTH_REGISTRY_ENSURE, the kebab dot-schema-*-ensure set (DOT-063…DOT-081, DOT-105/107/127–144), plus DOT-TAC-SCHEMA-ENSURE / -VERIFY.
Collection-register primitive — DOT-120 / DOT_COLLECTION_REGISTER (domain=collection) and DOT-TAC-COLLECTION-REGISTER. (There is no DOT named dot_iu_create_collection in dot_tools; the IU collection-create primitive writes iu_piece_collection records and is NOT a Directus-DDL/canonical-vocab creator — a misidentification Codex flagged in the C1 PATCH1 review.)
Catalog sync — DOT-015 / dot-catalog-sync.

4. Which DOTs relate to DOT birth / admission / registration / catalog sync?

28 dot_tools rows match (ILIKE birth/admit/register/catalog/rollback/retire/supersede), all active/published. Key:

Registrar: DOT-REGISTER (dot-dot-register, domain=monitoring.dot, op=register) — the ONLY governed registrar of new DOTs into dot_tools (via Directus REST API).
Catalog sync: DOT-015 / dot-catalog-sync.
Birth (object) DOTs: DOT-118 / DOT_BIRTH_BACKFILL, DOT-119 / DOT_BIRTH_TRIGGER_SETUP, DOT-133 / DOT_SCHEMA_BIRTH_REGISTRY_ENSURE, TAC birth gates (DOT-TAC-BIRTH-GATE, -BIRTH-VERIFY).
Register helpers: dot-apr-types-register (+ audit), DOT-146 / dot-species-register, DOT-120 / DOT_COLLECTION_REGISTER, DOT-TAC-COLLECTION-REGISTER.
Rollback/retire: DOT-062 / dot-rollback, DOT-112 / dot-entity-retire, DOT-314 / dot-matrix-retire, DOT_NRM_RETIRE.

5. Which DOTs are frozen / forbidden / restricted?

KB-documented (handbook §13 + Macro-9A0 supplement): 4 frozen + 2 monitored:

dot-birth-trigger-setup — DANGEROUS_CAN_REDEFINE_GATEWAY, CRITICAL / FROZEN (embeds CREATE OR REPLACE fn_birth_registry_auto with old logic).
dot-birth-backfill — DANGEROUS_CAN_BACKFILL_BROKEN, HIGH / FROZEN (direct INSERT INTO birth_registry via docker exec psql).
dot-schema-birth-registry-ensure — MEDIUM / MONITORED_NOT_FROZEN (redefines fn_birth_auto_certify).
Plus the manual lanes themselves (raw SQL / psql / docker exec psql / Directus generic create / manual INSERT INTO dot_tools / token-minting) — forbidden by README + handbook §3 + RP-03.

⚠ LIVE DIVERGENCE (material transition gap): in live dot_tools these three DOTs are status=active with extra_metadata={} — there is no frozen/forbidden/dangerous column or flag enforced at the registry level. The prohibition exists ONLY as KB-handbook prose. A future agent reading the live registry alone would see them as ordinary active DOTs. → carried into 06 (gap map) as REPAIR_BEFORE_REUSE for the registry, and into 08 as a required DOT-manage/operator update.

6. Which DOTs are safe / reusable (for C1)?

Safe-to-reuse PATTERNS (read-only or governed-dry-run-gated, no forbidden lane): the schema-ensure family (esp. DOT_SCHEMA_TABLE_REGISTRY_ENSURE as the registration-step pattern, DOT_COLLECTION_REGISTER as the collection-create primitive), the producer/verifier pairing precedent (DOT_KG_EXPLAIN / _VERIFY + its preflight view), dot-catalog-sync for catalog update, and DOT-062 / dot-rollback (extend, not clone) for the rollback step. Detail + evidence in 05.

7. Which DOTs are legacy and require LEGO adaptation?

The Macro-9 staging-schema DOT DOT_R2_B2_STAGING_SCHEMA_SHELL (+ 4 guards): authored/engineering-admitted, R2-B2-name-scoped, pure-validator only → needs a C1 variant + write-enabled body + registration (see 04).
The birth/admission path (dot-birth-admit author-mode spec; dot-dot-register creds-absent; advisory-only birth gate; OSPA=0) → the governed registration path is staged but not runnable here (see 03).
The three KB-frozen birth DOTs whose live registry rows lack the freeze flag → registry must be made to reflect the handbook before LEGO reuse decisions are trusted (see 06/08).

Inventory bottom line

DOT manage is a real, intact, mostly-read-only/dry-run-gated system: 309 DOTs in dot_tools (CAT-006), a working dispatcher, rich schema-ensure (75) and birth/register/rollback (28) families — but only 2 dispatch contracts bound, all execution gates closed, 0 build-authorizations, 0 ownership grants, and zero C1 artifacts anywhere. The single notable integrity gap surfaced here is that the handbook's frozen/forbidden classification is not enforced in the live registry.