10 — dot-pivot-update Final Classification

Classification (from live reconciler evidence)

STAGED_FILE_ONLY / UNBORN / NOT_VALID_DOT — unchanged, now backed by the live filesystem snapshot.

Property	Value (live 2026-06-03)
on_disk	true
path	/opt/incomex/dot/bin/dot-pivot-update
sha256	3313c057caaf1c72e30465354ee9cff0866e0dc3e7205a2c84c3c849284effc5
size	14441 bytes
owner:group	root:root
executable	yes
mtime	2026-06-03 05:19:02 UTC
in dot_tools	false (0 rows by name/code/path)
born in birth_registry	false
v_dot_fs_reconciliation	FILE_NO_REGISTRY
v_dot_pivot_update_status	STAGED_FILE_ONLY / UNBORN / NOT_VALID_DOT
fn_preflight_guard dimension	dot_pivot_update_not_governed = 1 → BLOCK

Why it is NOT a valid DOT

1. No dot_tools registry row → not a governed tool.
2. No birth_registry row → unborn.
3. It is one of the 16 FILE_NO_REGISTRY files on disk.
4. The guard explicitly BLOCKs RP/DOT actions while it remains in this state.

Actions taken

None. Per the forbidden list, dot-pivot-update was not registered, not executed, and is not called a valid DOT. The sha256 matches the artifact recorded in prior macros (3313c057…effc5), confirming the staged file is unchanged.

Lawful route to make it valid (future, gated)

1. Resolve the guard BLOCKs (doc 08).
2. Register via the governed registrar (dot-dot-register, Directus-API; needs admin creds that are absent) — never a manual dot_tools INSERT.
3. Birth follows registration (trigger or DOT path).
4. Only then does it leave STAGED_FILE_ONLY and the guard dimension clears.

Until all of the above, RP cleanup that depends on dot-pivot-update stays NO-GO.