Add worktree placement policy

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.