03 — G2: Targeted C1 registration is DOT-approved, NOT a manual Directus POST

The macro's hard test (§3.2): "If 'targeted POST' is only a direct Directus POST into dot_tools, final verdict must be GOVERNED_C1_DRYRUN_REJECT_DOT_BYPASS."

1. The prior plan WAS a bypass under this standard — corrected

Prior package report 12, W2 read: "governed POST /items/dot_tools … scoped to the 6–7 codes." Issued by the agent ad-hoc, that is a manual Directus POST — exactly the bypass this macro rejects. This hardening replaces it. (Recording the correction, not hiding it.)

2. Reuse-first search — what legitimately writes dot_tools

Local grep -rl "items/dot_tools" dot/bin → 4 scripts:

Script	Role	Creates rows?
dot-dot-register	the governed registrar (Cấp B, on-deploy)	YES — canonical creator
dot-fill-tool-descriptions	back-fills description	no (updates)
dot-update-tool-categories-vn	sets category	no (updates)
dot-registry-diff	read/diff report	no

⇒ The only governed creator of dot_tools rows is dot-dot-register. There is no second registration DOT to reuse and no need to invent one.

3. The DOT-approved targeted path

Registration DOT path = the patched governed registrar dot-dot-register-c1-hardened run with --only-prefix dot-c1- (report 02). Why this is DOT-approved and not a manual POST:

Criterion	Manual Directus POST (rejected)	Patched governed registrar (this plan)
Who issues the write	a human/agent typing curl/directus_create	the registered Cấp-B DOT dot-dot-register, executing its own primitive
Auth	ad-hoc admin token	dot-auth inside the DOT (its governed mechanism)
In dot_tools/CAT-006 as a DOT	n/a	yes — dot-dot-register is itself a registered DOT
Idempotent	no	yes (basename + code, report 02)
Scope control	none	--only-prefix dot-c1- + --max-new abort
Reject behavior	none	bulk-insert abort (exit 3); backup denylist
Rollback/retire	manual	dot-entity-retire/status-flip on the named codes

The curl POST /items/dot_tools inside dot-dot-register is the registrar's internal primitive — the same mechanism the system uses for all tool registration. A write performed by the governed registrar DOT is governed registration; a write performed by hand is the bypass. This plan uses the former exclusively.

4. Payload / write target / idempotency / reject (per macro §3.2)

• script/path: dot/bin/dot-dot-register (patched to v1.1.0-c1-hardened via patch_ops_code).
• DOT code: DOT-REGISTER (the registrar's own DOT identity), producing rows DOT_C1_*.
• registry/admission source: existing registered DOT (no new admission for the registrar; the C1 tool rows get their own ledger rows, report 07).
• payload: per-file derived {code, name, file_path, tier, domain, status:active, paired_dot} — the registrar's existing payload shape.
• auth: dot-auth (DOT-internal).
• write target: dot_tools (then dot-catalog-sync → CAT-006).
• idempotency: basename + derived-code guards (report 02 Run B/C).
• reject behavior: --only-prefix filters non-C1; backup denylist; --max-new abort (exit 3) on unexpected bulk.
• dry-run output: Run C2 → exactly the 7 DOT_C1_* rows, exit 0 (report 02 §5).
• why not manual POST: §3 table.
• rollback/retire: dot-entity-retire / status-flip retired on the named C1 codes (never hard-delete).

5. Verdict

G2 = DOT-approved targeted registration PROVEN. No manual/direct Directus POST is used anywhere in the C1 registration path. GOVERNED_C1_DRYRUN_REJECT_DOT_BYPASS does NOT fire.