# 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

Relationship note:

- this document is a subordinate worktree-focused mirror of the broader
  governing cleanup doctrine in
  `C:\HyperTwist\docs\ops\HYPERTWIST_PACKET_CLEANUP_AND_REBUILDABLE_ARTIFACT_HYGIENE_2026-05-20.md`
- if this document conflicts with the broader cleanup doctrine, the broader
  cleanup doctrine wins
- selective retroactive cleanup backfill for older relied-on packet or workflow
  ambiguity is governed by
  `C:\HyperTwist\docs\ops\HYPERTWIST_RETROACTIVE_AUTHORITY_AND_CLEANUP_BACKFILL_2026-05-20.md`
- use the broader doctrine for deep source packet evaluation and other packet
  types that generate rebuildable artifacts outside bounded implementation

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 non-root parent `C:\Workspaces\HyperTwist-worktrees\...`.
- Do not default new HyperTwist packet worktrees to `C:\w\...` anymore unless
  the user explicitly asks for that scratch parent again.
- If `C:\Workspaces\HyperTwist-worktrees` 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.
- If the packet path is a registered git worktree, preferred cleanup is
  `git worktree remove <path>`; if the folder is deleted manually, follow with
  `git worktree prune` so stale worktree metadata does not remain under the
  main repo.
- If an older relied-on packet or workflow doc is cleanup-ambiguous, do
  selective cleanup backfill only where that ambiguity still matters
  operationally; do not bulk-rewrite older closeouts for appearance.

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.
