From a5e32e6cd88bc60a1b0ed96a3fa2aa970db3335f Mon Sep 17 00:00:00 2001 From: axiomlogicnexus Date: Tue, 19 May 2026 21:21:17 +0200 Subject: [PATCH] Add worktree placement policy --- ...D_VALIDATION_ARTIFACT_POLICY_2026-05-19.md | 43 +++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 docs/ops/HYPERTWIST_WORKTREE_PLACEMENT_AND_VALIDATION_ARTIFACT_POLICY_2026-05-19.md diff --git a/docs/ops/HYPERTWIST_WORKTREE_PLACEMENT_AND_VALIDATION_ARTIFACT_POLICY_2026-05-19.md b/docs/ops/HYPERTWIST_WORKTREE_PLACEMENT_AND_VALIDATION_ARTIFACT_POLICY_2026-05-19.md new file mode 100644 index 0000000..d03744f --- /dev/null +++ b/docs/ops/HYPERTWIST_WORKTREE_PLACEMENT_AND_VALIDATION_ARTIFACT_POLICY_2026-05-19.md @@ -0,0 +1,43 @@ +# HyperTwist Worktree Placement And Validation Artifact Policy + +Created on `2026-05-19`. + +Purpose: + +- stop unpermissioned packet worktrees from being created directly under `C:\` +- keep temporary validation logs, automation reports, and packet artifacts out + of ad hoc root-level folders +- make cleanup expectations explicit after bounded implementation packets + +Policy: + +- Do not create new ad hoc packet worktrees directly under `C:\` such as + `C:\HTB*`, `C:\CTW*`, or similar root-level packet folders unless the user + explicitly approves that exact placement. +- Default clean bounded-implementation and validation worktrees to the approved + scratch parent `C:\w\...` when that route is in use. +- If `C:\w` is not appropriate, ask for a replacement parent rather than + inventing a new root-level folder family. + +Validation artifact rule: + +- Keep packet logs, automation reports, exported JSON artifacts, and other + validation byproducts inside the selected clean worktree. +- Do not create ad hoc top-level `C:\` folders for validation byproducts. +- Packet-close reports must name the kept artifacts when they matter and must + state whether they remain inside the worktree or were removed. + +Cleanup rule: + +- After a packet lands and its results are harvested into authority docs, the + implementation instance should remove the clean temporary worktree unless the + user has asked to keep it or a documented blocker requires temporary + retention. +- If a worktree is intentionally retained, the closeout must say why. + +Operational note: + +- Existing historical root-level packet worktrees should be treated as + unauthorized residue unless a later explicit approval exists. +- They are not authority surfaces merely because they exist on disk; landed + commits, packet docs, and approved clean-room notes remain the authority.