RS3B-02 — Dual-Writer Boundary: dot-dot-register vs dot-catalog-sync — 2026-06-21

Macro: RS3B-REGISTRAR-HARDENING-DESIGN (read-only / KB-design) Deliverable: 02 of 10 · Dual-writer boundary (Mục tiêu B) Date: 2026-06-21 · 0 mutations · NO_CODEX_LIVE_READ Deliverable status: DUAL_WRITER_BOUNDARY_PARTIAL_SOURCE_NOT_READ — boundary derived from runtime metadata + registry only; neither writer's source was readable (RS3B-01), so write/clobber semantics are designed as criteria, not proven from code.

---

1. The two writers (live, 2026-06-21)

Field	DOT-REGISTER (registrar)	DOT-015 (catalog sync)
name	dot-dot-register	dot-catalog-sync
operation	register	NULL
file_path	bin/dot/dot-dot-register.ts	bin/dot/dot-catalog-sync
script_path	NULL	dot/bin/dot-catalog-sync
status	active	active
domain	monitoring.dot	sync
paired_dot	DOT-HEALTH-DOT (has a verifier)	NULL (unpaired, no verifier)
tier	B	B
trigger_type	on-deploy	NULL
coverage_status	complete	partial

Registry corroboration: meta_catalog/CAT-006 describes dot-catalog-sync as Sync Frequency: on-deploy, Source: File:dot/bin/, Record Count 309 (= current dot_tools count). Both are distinct DOTs in distinct domains.

2. The ten boundary questions (Mục tiêu B answers)

1. Who is registrar? DOT-REGISTER / dot-dot-register (operation=register, paired verifier DOT-HEALTH-DOT).
2. Who is catalog sync? DOT-015 / dot-catalog-sync (operation=NULL, domain=sync, unpaired).
3. Shared surface? Both name a file under bin/dot/; the registry Record Count 309 equals live dot_tools count, so catalog-sync's frame of reference is dot_tools. Shared surface = dot_tools (candidate). Whether catalog-sync writes dot_tools or only reads/reconciles it is SOURCE_NOT_READ.
4. Both write dot_tools? UNPROVEN. operation=register (DOT-REGISTER) is a write verb; operation=NULL + domain=sync (DOT-015) is consistent with read/reconcile or write. registry_changelog attributes dot_tools.items.create to directus_flow (not a per-DOT actor), so the changelog cannot disambiguate which DOT wrote. Fail-closed assumption: treat catalog-sync as a potential second writer until source proves otherwise.
5. When does sync run? Sync Frequency: on-deploy (CAT-006) and trigger_type NULL on the row; registrar is on-deploy too. Both fire around deploy → temporal overlap window exists → race is possible.
6. Does sync clobber/overwrite metadata? SOURCE_NOT_READ. Cannot confirm. Boundary rule must forbid clobber (see §4).
7. Does sync auto-detect new files and register them? Source: File:dot/bin/ + coverage_status=partial is consistent with a filesystem scanner that discovers and upserts rows — i.e. mass/auto registration, the exact anti-pattern RS3B must reject. UNPROVEN but must be fenced.
8. Does it race the registrar? Same on-deploy trigger → yes, a race is structurally possible; no advisory lock / serialization evidence is observable from metadata.
9. Meaning of catalog-sync operation=NULL / paired_dot=NULL? operation=NULL = no governed write verb declared → it must not be treated as an authorized registration writer; paired_dot=NULL = no paired verifier → any write it performs is unverified by construction. Both NULLs are fail-closed signals.
10. What must the boundary be? Single authorized registration writer (registrar) writing candidate/closed rows; catalog-sync constrained to read-only reconciliation reporting (no clobber, no activation). See §3–§4.

3. Dual-writer state machine (design / criteria)

                    ┌─────────────────────────────────────────────┐
                    │  SINGLE AUTHORIZED REGISTRATION WRITER        │
                    │  = registrar (DOT-REGISTER), one artifact     │
                    └─────────────────────────────────────────────┘
   registrar:  [idle] --admit one artifact--> [write candidate row] --paired verify--> [closed/candidate]
                                                     │
                                                     │  (NO activation; status NOT set to a value
                                                     │   that trips context-pack notify — see RS3B-08)
                                                     ▼
                                              dot_tools row = governed, closed-at-registration

   catalog-sync: [idle] --on-deploy scan--> [READ dot_tools + FS] --diff--> [emit RECONCILIATION REPORT only]
                                                     │
                                                     ├─ if drift found  -> RAISE drift signal to registrar/owner (no write)
                                                     └─ MUST NOT: insert/update/activate/clobber dot_tools rows

Required boundary states:

• WRITER_AUTHORITY = registrar_only — only the registrar may INSERT/UPDATE governance-bearing columns of a dot_tools registration row.
• CATALOG_SYNC = reconcile_read_only — catalog-sync reads dot_tools + the filesystem and emits a reconciliation report / drift signal; it does not write registration rows and never sets status=active.
• CONFLICT(register_vs_sync) — if both attempt to write the same code within the deploy window → reject the lower-authority writer (sync) and HOLD; registrar write wins, sync downgrades to report-only.
• DRIFT(row≠artifact) — if a dot_tools row's metadata diverges from the admitted artifact → DOT_TOOLS_ROW_DRIFT → registrar reject/HOLD, never silent sync overwrite.

4. Boundary table

Writer	Surface	Operation	Timing	Conflict risk	Boundary rule	Reject / HOLD
registrar DOT-REGISTER	dot_tools	register (write candidate/closed row)	on-deploy, per one admitted artifact	races catalog-sync in deploy window	sole authorized registration writer; one artifact per invocation; no activation	MASS_REGISTRATION_ATTEMPTED, CATALOG_SYNC_CONFLICT, DOT_TOOLS_ROW_DRIFT
catalog-sync DOT-015	dot_tools (+ FS scan File:dot/bin/)	NULL (sync)	on-deploy	may auto-insert / clobber if it writes	read-only reconciliation: read + diff + report/raise; no insert/update/activate/clobber	CATALOG_SYNC_WROTE_REGISTRATION_ROW (fail-open if observed), CATALOG_SYNC_CLOBBER
(either)	dot_tools.status	set active	any	trips trg_context_pack_dot_register notify (RS3B-08)	activation is separate, Owner-gated, never at registration	ACTIVATION_AT_REGISTRATION

5. Why this stays PARTIAL

The boundary rules above are derivable and fail-closed. What is not provable without source (RS3B-01): whether catalog-sync actually writes dot_tools, whether it clobbers, whether it auto-registers discovered files, and whether any lock serializes it against the registrar. Therefore:

• Boundary status: DUAL_WRITER_BOUNDARY_PARTIAL_SOURCE_NOT_READ.
• No PASS for Mục tiêu B until both sources (registrar + catalog-sync) are read and the write/clobber/lock behavior is confirmed against the boundary rules.
• Reuse-first preserved: no new registry/table is proposed; the boundary is enforced as a contract over the existing dot_tools surface plus a reconciliation-report output for catalog-sync.

6. Status block

• Deliverable status: DUAL_WRITER_BOUNDARY_PARTIAL_SOURCE_NOT_READ
• Feeds: RS3B-03 (single-artifact contract), RS3B-08 (trigger side-effects), RS3B-09 (adversarial cases C-RACE/C-CLOBBER/C-MASS)
• Registration gate: REGISTRATION_HOLD · REGISTRATION_CAN_PROCEED = NO · 0 mutations