04 — Macro-9 Staging-Schema Path: LEGO Fit / Gap for C1

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

Answers macro §3.3: can DOT_R2_B2_STAGING_SCHEMA_SHELL (or equivalent) serve as the C1 staging/sandbox carrier, and if so with what exact adaptation? A new staging path is NOT created here — the Macro-9 path is evaluated first, as required.

1. What was Macro-9B intended to solve?

Macro-9A0's read-only inventory found that no existing DOT can build a run-scoped, disposable staging schema (separate schema, zero prod data, delete-fast, abort-on-drift). The schema-shell build (Macro-9A) was therefore declared NO-GO and held. Macro-9B's job was to AUTHOR + HARDEN that missing DOT path (the staging-schema DOT + its write-guards + a fail-closed validator) so it could later be registered and (separately, Owner-gated) run.

2. Authored only / admitted / registered / wired / runnable?

authored = YES · engineering-admitted = YES · registered = NO · wired = NO · runnable = NO. Verbatim:

Contract: "Status: AUTHORED — NOT REGISTERED, NOT WIRED, NOT RUN. REGISTRATION_HOLD + HOLD_FOR_OWNER_REAL_RUN."
Contract: "Write capability today | NONE."
Admission record (rev9): "Runtime registration: REGISTRATION_HOLD — not in dot_tools, no agent-api contract, no runtime gate. Verified fresh 2026-06-19: 0 matching rows in dot_tools (count unchanged at 309)."
The only thing that exists and runs today is a pure Python reference validator that "Performs NO database I/O of any kind" — it emits plans/verdicts/write-intent as data strings only.

Confirmed still true on 2026-06-22 by this macro's live probes: dot_tools count = 309 (no R2-B2 DOT row), dot_agent_api_contract = 2 (KG only).

3. What Codex caveats remained?

Codex HOLD on the rev1 9B/9B1 package ("overclaimed fail-closed"). Macro-9B2 closed all 7 findings (channel required; actor required; re.fullmatch + control-char reject; gate must be exactly boolean True; Guard 3 made an executable verdict enforced in real_run; Guards 1/4 share a pure _validate_target; matrix expanded to 64 cases framed as bounded engineering evidence). Codex re-review = PASS_WITH_CAVEATS.

Caveats that REMAIN OPEN (verbatim): "(C-1) this is local pure-validator evidence, NOT runtime proof — the DOT remains unregistered/unwired/ungated. (C-2) Guard 3 verifies supplied before/after evidence; it is not a live runtime drift proof … (C-4) runtime hardening GAPS 2/3/4 … remain OPEN and out of scope."

4. What did Macro-9B2 close? What remains under REGISTRATION_HOLD?

Closed (engineering/validator layer): the 7 Codex findings above → "64/64 PASS, 0 fail-open" (bounded).

Remains under REGISTRATION_HOLD / HOLD_FOR_OWNER_REAL_RUN:

Registering the DOT in dot_tools / binding an agent-api contract / opening a runtime gate (all DB writes — "performed none; dot_tools is NOT written by hand").
The first real_run/teardown_real_run (CREATE SCHEMA/DROP SCHEMA … CASCADE) — blocked until explicit Owner authorization + freshly-opened execute gate + fresh read-only preflight + no-prod-touch/delete-fast proof.
Runtime hardening GAPs (preconditions, "this macro implements none"): GAP-2 generic directus role still has db_create=true/public CREATE=true (workflow_admin SUPERUSER); GAP-3 generic Directus collection/schema create not policy-blocked; GAP-4 no dedicated DOT-executor role exists (write sits with directus+workflow_admin).

5. The Macro-9B artifact (modes + guards)

DOT_R2_B2_STAGING_SCHEMA_SHELL — 6 modes: validate_only (no writes) · dry_run_plan (DDL plan strings, no writes) · verify (Guard-3 verdict, read-only) · teardown_plan (DROP plan, no writes) · real_run (gated — write-intent strings only, REAL_RUN_GATE_CLOSED) · teardown_real_run (gated).

4 separable guards: Guard 1 DOT_SCHEMA_WRITE_ALLOWLIST_GUARD (pre-write, fail-closed; allowlist r2_b2_wb_[a-z0-9]+(_[a-z0-9]+)* via re.fullmatch; rejects protected/shared/prod, control chars; requires name to embed run_id) · Guard 2 DOT_SCHEMA_WRITE_AUDIT_PROOF (audit envelope on EVERY decision) · Guard 3 DOT_PRODUCTION_UNTOUCHED_VERIFY (executable PASS/FAIL/UNKNOWN over 11 protected surfaces; real_run requires PASS) · Guard 4 DOT_STAGING_SCHEMA_DELETE_FAST (allowlist-guarded DROP SCHEMA … CASCADE of the run-scoped workbench only). Hard-reject targets: public, iu_core, cutter_governance, sandbox_tac, information_schema, pg_catalog, pg_toast, pg_temp.

6. Can it be reused for the C1 dry-run?

As-is: NO. Grounds: (i) it is unregistered/unwired/ungated; (ii) the runnable artifact is a pure validator with no DB I/O — it cannot materialize anything; (iii) it is R2-B2-name-scoped — dot_code must equal DOT_R2_B2_STAGING_SCHEMA_SHELL, the allowlist is r2_b2_wb_*, and the 7 shell tables are KG-staging scratch (wb_manifest/wb_object/…), so a C1 request rejects with WRONG_DOT_CODE / NON_ALLOWLIST_SCHEMA.

As a design precedent: YES, strongly. It is the most directly applicable existing asset for a disposable staging carrier (run-scoped, zero prod data, delete-fast, abort-on-drift, fail-closed, DOT-only, audit-on-every-decision), Codex-vetted at the engineering layer.

7. If reused with adaptation — the exact adaptation

To turn the Macro-9 path into a C1 dry-run staging carrier requires, at minimum:

A C1 variant DOT (e.g. DOT_C1_STAGING_SCHEMA_SHELL) — change dot_code, the allowlist prefix (r2_b2_wb_ → a C1 prefix), the shell tables (C1 vocab carrier shape, not KG scratch), and Guard-3's required-surfaces list.
A write-enabled implementation body — the executable that issues real CREATE/DROP (the KB has only the contract + the no-I/O validator; the runtime body is "not authored here").
Registration (lifts REGISTRATION_HOLD) — register the DOT + guards in dot_tools + bind an agent-api contract through the lawful registrar, never by hand.
Close hardening GAPs 2/3/4 — revoke schema-create from generic directus, create an isolated minimal-privilege DOT-executor role, policy-block generic Directus create (role/grant/policy writes — out of every Macro-9 doc so far).
Open execute gate + Owner authorization (lifts HOLD_FOR_OWNER_REAL_RUN) — only for REAL_RUN; a dry-run can run under dry_run_only.
A C1 admission record — anti-orphan requirement for any new C1 DOT/variant.

8. Is a staging schema even required for the C1 dry-run? (scoping note)

Two distinct uses of "staging/sandbox" must not be conflated:

The Macro-9 path builds a disposable separate SCHEMA for KG-staging scratch. C1's dry-run does not strictly require building a separate schema — the C1 producer/verifier dispatch in DRY_RUN mode "never writes" (the dispatcher raises on REAL_RUN). The C1 governed dry-run needs the C1 collection + DOT_C1_ contracts registered* so the dispatcher has something to dry-run against; it does not need a CREATE SCHEMA.
Therefore the Macro-9 staging-schema DOT is best treated as the precedent/template for the future C1 REAL_RUN sandbox lane and for the DOT_SCHEMA_*_ENSURE discipline, not as a prerequisite the operator must build before a C1 dry-run. (See 07 surface map: the C1 dry-run critical path is collection-ensure + contract-register + grant, not schema-shell.)

Verdict: DOT_R2_B2_STAGING_SCHEMA_SHELL is REUSE_WITH_LEGO_ADAPTER as a design template, not a runnable carrier. Authored + engineering-admitted ≠ registered + runnable. It cannot be the C1 carrier today; a C1 dry-run does not depend on it, but the future C1 REAL_RUN sandbox should fork its contract/guards/validator pattern and inherit its open hardening GAPs 2/3/4 as preconditions.