02 — DIRTY SSOT HANDLING — NOT PERFORMED (held before mutation)

Status: NO MUTATION

No stash, no clean-branch, no working-tree change was made to VPS /opt/incomex.

Why deferred (sequencing decision)

The macro lists dirty-tree handling (Phase A) before quorum (Phase B). However, the production code SSOT carries ~1999 untracked files (S177 WIP + ops backups) and 17 modified tracked files. Stashing/branching those is a real, disruptive mutation of the production SSOT.

The disciplined order is: confirm the blocking gate is passable before touching the SSOT. The Phase B quorum lock (file 04) proves the apply cannot proceed — the agent cannot manufacture the required 1 human-president + 2 ai_council approvals. Disrupting WIP / ops backups to "prepare" for an apply that is structurally blocked downstream is not justified.

Important: the apply surface is already CLEAN

dot/bin/dot-apr-execute    clean
dot/bin/dot-apr-propose     clean
dot/bin/dot-dot-register    clean

So the dirty tree is NOT itself a blocker for the W7 apply surface — the binding blocker is quorum (authority), not the dirty tree (provenance). Had quorum been available, the chosen option would have been Option C (clean branch from HEAD) as the least-destructive path, preceded by sensitive-file quarantine (file 03).

Owner action retained for when quorum is in hand

If/when the owner supplies recorded president + 2 ai_council approvals through the governed channel, the safe sequence is: quarantine sensitive untracked files → create c1-w7-apply branch from HEAD → apply only there. Not done now.