Repository navigation
[Low] Review snapshot defaults inside the candidate when reviewing a standalone clone #297
Description
Reproduced workflow conflict
During independent code and security reviews of #296, both reviewers invoked python scripts/getzilla_cleanup.py snapshot 4bcfeeffe850b4f56cdd6608d78d141983c16149 --json from the clean standalone candidate clone. The helper chose that clone as the main Git worktree and created the snapshot under its own .getzilla/runtime/snapshots/.
AGENTS.md requires mutation probes outside the reviewed candidate worktree. In a standalone clone, the helper's default placement therefore conflicts with that requirement. This is a placement/workflow limitation; no source corruption or permission bypass was observed.
Reproduction
- Use a normal standalone clone as the reviewed candidate (the only entry in
git worktree list). - Commit the candidate and run
getzilla cleanup snapshot <exact-full-HEAD> --json. - Observe the returned path is a descendant of the reviewed candidate itself.
- The reviewer cannot use this snapshot while obeying the outside-candidate rule.
Both reviewers invoked the standard cleanup command before tests or mutation; it returned removed. They then created separate private controller clones outside the candidate, verified identical HEAD/tree and private directory modes, used the same snapshot command there, completed their probes, and invoked cleanup. This workaround needs an extra clone and coordination.
A later read-only check found the code reviewer's initial snapshot and external controller/snapshot present again, despite the helper's successful removal output and an immediate exists: False observation after private-parent removal. The initial snapshot was unregistered, with a dangling Git metadata reference and its original ready marker. The security reviewer's external controller was absent when checked. The cause of the reappearing paths is not established; these observations do not distinguish recreation/environment synchronization from a cleanup defect. No test or mutation ran in the initial candidate-contained snapshot. Do not treat the cleanup observation as proof of a specific Getzilla bug.
Expected outcome
Provide a supported safe placement for review of a standalone/main worktree, or refuse before creating an incompatible snapshot with a precise recovery instruction. Preserve full commit identity, owner markers, private mode0700/non-sticky parents, containment validation, and guarded cleanup. Do not loosen mutation or deletion boundaries.
Acceptance
- A deterministic standalone-clone test establishes an outside-candidate probe workspace, or an early explicit unsupported-layout refusal with a supported workflow.
- Linked-worktree behavior remains valid.
- Exact commit, private permissions, marker ownership and cleanup refusal controls remain tested.
- Reviewer instructions and CLI behavior agree.
Related: #183 and the snapshot observations in #252. This does not block the six-file continuity consumer repair in #296.
Activity
Dimkox commentedon Nov 2, 2026
Follow-up from PR296 reviews on 7736d98.
The private-controller workaround kept critical probes outside the reviewed candidate. Both independent reviewers nevertheless observed a cleanup inconsistency: native snapshot removal reported success, then a later filesystem observation found source remnants again; the registered worktree list did not contain that snapshot. One reviewer also observed an owned parent reappear after a same-process removal/absence check.
The coordinator removed only the exact known reviewer parents under the task runtime root. A separate later observation found both parents absent. This is an observation, not a guarantee of permanent absence. Candidate HEAD/tree/fingerprint stayed clean and unchanged throughout; no broad cleanup was used.
The cause of remnant reappearance is unresolved and is not attributed to Git layout or the native cleanup implementation without further evidence. Keep this Low workflow follow-up open; the complete review reports distinguish test results, native removal results and later filesystem observations.
Dimkox commentedon Nov 2, 2026
Additional bounded observation from PR #298 reviews
On exact reviewed HEAD
a1eb5fa01fb27f1e88fbf9d8aedcfaf47a3b7886, the code reviewer used its own private controller and the native snapshot API. Native removal reported success; the exact snapshot, marker and private fixture root were observed absent. A later observation nevertheless found the source-only controller directory present again without.git. Its cause is still unknown; this is not evidence that the candidate or its Git layout recreated it.The coordinator performed one separate, bounded cleanup of that exact owned controller remnant. A later read-only check observed it absent. The security reviewers' exact native snapshots and controller were also observed absent after their bounded cleanup. Raw logs and reports remain retained outside those source copies. No broad or repeated cleanup was used, and point-in-time absence is not a permanence claim.
PR #298 does not modify cleanup behavior and does not close this issue. These observations extend the existing defect record; the offline admission source itself passed its separate qualification and was merged.