02 — A2 · Owner Options for the Dirty SSOT Tree

The agent made no change to the tree (no stash/commit/restore/ignore). These are options for the owner to execute out-of-band. All are reversible; backups already exist for most modified files.

Key facts the options rest on

• The dirty tree is S177 sprint-1-round-a WIP + operational backups/staging/data.
• The W7 apply target (dot-apr-execute) and all APR/registrar binaries are CLEAN.
• So the dirty tree is a provenance / hygiene risk, not a collision risk: a high-risk governed apply should ideally land on a clean, committed tree so the apply diff is isolated and rollback is deterministic.

Option A — Clean room (recommended for a high-risk governed apply)

Commit or stash the S177 work so the W7 apply lands on a clean tree.

1. Review + commit the 17 modified files on feat/s177-sprint1-round-a (or git stash them if not ready to commit).
2. Triage untracked: add lark-backups/, data/, tmp/, *.pre-*, *.rp-backup-*, docs/mcp-writes/ to .gitignore (or move out of tree); decide keep/remove for the new dot/bin/* scripts and dot/iu-cutter* staging.
3. Re-run git status --short → expect clean (or only intentionally-ignored).

• Result: A2 passes cleanly; W7 apply diff is isolated; rollback = single revert.
• Cost: owner time to review S177 diff before a governance apply.

Option B — Explicit apply-on-dirty waiver (faster, lower provenance guarantee)

Owner explicitly accepts applying on the dirty tree, on the documented basis that no dirty path is the apply target.

1. Owner records a written waiver (e.g., in the APR evidence) acknowledging the 80-entry dirty tree and that the apply touches only the clean dot-apr-execute + migration + grant-issuer registration.
2. Apply proceeds; patch_ops_code takes its own .bak-{session} of the single target file.

• Result: A2 "passes" by explicit owner risk-acceptance, not agent self-certification.
• Cost: if rollback is ever needed, the C1 change is interleaved with uncommitted S177 work → messier recovery. Not recommended for a high-risk action.

Option C — Branch isolation (cleanest provenance)

1. Owner commits/stashes S177 work, then creates a dedicated branch (e.g., feat/c1-w7-handler) from a clean HEAD.
2. Perform the W7 apply there; merge back after verify.

• Result: maximal isolation + auditability; best rollback story.
• Cost: most owner setup.

Sensitive untracked items — handle BEFORE any commit (do NOT git add blindly)

These were found in the untracked set and should be secured/removed, not committed:

1. claude-mcp/.deploy-secrets.pre-rotate-20260519T042530Z — a pre-rotation secrets backup sitting in the tree. Owner: move to a secret store / delete; never commit.
2. docker/dieu44_v0_5_constmarker_amend_prod_20260518T081501Z/prod-directus-preamend-20260518T081501Z.sql.gz — a production Directus DB dump. Owner: move off-tree to secure storage.
3. tmp/dieu44_v0_4_cred_* (dryrun/prod/stage dirs) — credential staging temp artifacts. Owner: review + delete.

A blanket git add -A would commit these into history. Triage them first.

Recovery / rollback references (already on disk)

• dot/bin/dot-birth-backfill ← dot/bin/dot-birth-backfill.stage0-frozen-2026-06-06
• dot/bin/dot-birth-trigger-setup ← dot/bin/dot-birth-trigger-setup.stage0-frozen-2026-06-06
• docker/docker-compose.yml ← docker/docker-compose.yml.pre-d28-*, .pre-executor-*, .rp-backup-*
• docker/nginx/conf.d/default.conf ← default.conf.pre-*, .rp-backup-*
• all other modified tracked files ← git restore <file> (committed baseline at HEAD bbf9c43).

Recommendation

Option A (or C if isolation is wanted), with the sensitive-file triage done first. Option B only if the owner formally accepts the provenance trade-off for a high-risk apply.