Backfill closeout taxonomy doctrine

docs/HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md

@@ -283,6 +283,20 @@ When `Model A` evaluates or refreshes a retained repo, the output should try to
 
 - whether the later target is no implementation, reference-only, pattern-only, bounded subsystem realization, broader bounded realization, or full positive realization of the retained lane
 
+### Locked outcome taxonomy
+
+- exact repo-level outcome category:
+  - `implemented now`
+  - `retained for later implementation`
+  - `retained as reference only`
+  - `retained only for pattern extraction`
+  - `excluded`
+- if retained, exact realization class:
+  - `full bounded capability realization`
+  - `narrower bounded slice`
+- if a narrower slice is chosen, the exact kept capability families and exact
+  not-kept capability families
+
 ### Explicit anti-misreading note
 
 - what the repo should never be mistaken for
@@ -338,6 +352,10 @@ Use the HyperTwist docs this way:
   - routing
   - class assignment
   - next phase
+- `docs/ops/HYPERTWIST_CANONICAL_COMPACT_CLOSEOUT_FORMAT_2026-05-19.md`:
+  - canonical closeout section order
+  - mandatory Result taxonomy
+  - compactness-without-information-loss rule
 
 ## Practical operator rule
 

docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md

@@ -256,6 +256,17 @@ Every serious repo evaluation should now try to state all of the following:
 - owner-lane placement
 - recommended implementation phase if retained
 - recommended realization depth if retained
+- exact repo-level outcome category:
+  - `implemented now`
+  - `retained for later implementation`
+  - `retained as reference only`
+  - `retained only for pattern extraction`
+  - `excluded`
+- if retained, exact realization class:
+  - `full bounded capability realization`
+  - `narrower bounded slice`
+- if a narrower bounded slice is chosen, the exact kept capability families
+  and exact not-kept capability families
 - acceptance markers if it later returns
 - explicit statement of what the repo should never be mistaken for
 
@@ -263,6 +274,14 @@ The product-fit verdict must not be implicit.
 
 It must be explicit.
 
+Closeout-shape note:
+
+- emitted packet summaries and chat closeouts must follow
+  [HYPERTWIST_CANONICAL_COMPACT_CLOSEOUT_FORMAT_2026-05-19.md](C:/HyperTwist/docs/ops/HYPERTWIST_CANONICAL_COMPACT_CLOSEOUT_FORMAT_2026-05-19.md:1)
+- compactness may not erase the outcome taxonomy, restrictive posture,
+  clean-room boundary, donor scope, kept-versus-not-kept capability families,
+  validation blockers, omission accounting, or next-sequence naming
+
 ## Approved non-fit or non-integration outcomes
 
 HyperTwist should be able to conclude any of the following without friction:

docs/ops/HYPERTWIST_CANONICAL_COMPACT_CLOSEOUT_FORMAT_2026-05-19.md

@@ -1,19 +1,119 @@
-# HyperTwist Canonical Compact Closeout Format Reference
+# HyperTwist Canonical Compact Closeout Format
 
 Created on `2026-05-19`.
 
-Closeout-shape authority:
+Status:
 
-- Treat `C:\VectorShell\docs\ops\VECTORSHELL_CANONICAL_COMPACT_CLOSEOUT_FORMAT_2026-05-19.md`
-  as the controlling closeout-shape authority.
-- Emit future repo-evaluation closeouts in that section order and compression
-  style, with packet docs as the authority surface, and do not omit lane,
-  validation, custody, push, state, cleanup, or next-pack facts.
+- active HyperTwist closeout doctrine
 
-HyperTwist local usage note:
+Authority note:
 
-- this document is a local reference hook so future HyperTwist operator,
-  clean-room, evaluation, and bounded-implementation docs can point at the
-  established closeout doctrine without restating the full format here
-- where HyperTwist packet or clean-room docs specify closeout behavior, they
-  should remain consistent with that controlling VectorShell closeout authority
+- treat `C:\VectorShell\docs\ops\VECTORSHELL_CANONICAL_COMPACT_CLOSEOUT_FORMAT_2026-05-19.md`
+  as the controlling shape authority
+- use this HyperTwist document to lock the same section order and compression
+  discipline into HyperTwist-local evaluation, clean-room, and bounded
+  implementation workflow surfaces
+- packet docs remain authority; chat closeouts are presentation only
+
+## Required section order
+
+Use this order unless a section is genuinely not applicable:
+
+1. `Main packet`
+2. `Restrictive-lane handoff` when applicable
+3. `Result`
+4. `Why that call`
+5. `Windows validation` or host-validation equivalent
+6. `Authority surfaces updated`
+7. `Pushed` when applicable
+8. `State`
+9. `Next live repo` or `Next live batch`
+10. `Task-summary omission report`
+
+If a section did not happen, say so explicitly instead of silently omitting it.
+
+## Result taxonomy rule
+
+`Result` must explicitly state the repo-level outcome category:
+
+- `implemented now`
+- `retained for later implementation`
+- `retained as reference only`
+- `retained only for pattern extraction`
+- `excluded`
+
+If the repo or retained lane remains retained, `Result` must also state the
+realization class explicitly:
+
+- `full bounded capability realization`
+- `narrower bounded slice`
+
+When a narrower bounded slice is chosen:
+
+- say that directly
+- name the exact kept capability families
+- name the exact deferred, donor-only, reference-only, pattern-only,
+  non-promoted, or excluded capability families
+
+Do not leave that taxonomy implicit in general prose.
+
+## Compactness rule
+
+Compactness is allowed. Information loss is not.
+
+You may compress by:
+
+- grouping same-type facts into paragraphs
+- using short grouped bullets
+- combining same-class evidence, file names, validation facts, or state facts
+  on one line with commas or semicolons
+
+You may not compress away:
+
+- repo-level outcome category
+- retained-versus-reference-versus-pattern-versus-excluded taxonomy
+- full-bounded-versus-narrower-slice realization taxonomy
+- restrictive posture
+- clean-room boundary
+- exact donor scope
+- exact kept versus not-kept capability families
+- validation blockers
+- omission accounting
+- next-sequence naming
+- lane, validation, custody, push, state, cleanup, or next-pack facts
+
+## HyperTwist local usage rule
+
+HyperTwist packet and workflow docs that govern evaluation or bounded
+implementation closeouts must point here rather than treating closeout shape as
+optional.
+
+In particular:
+
+- evaluation doctrine must require the outcome taxonomy
+- clean-room model-output rules must require the section order and omission
+  accounting
+- bounded implementation prompts must require explicit `Result` taxonomy even
+  when the packet realizes only one bounded slice
+
+## Relationship to broader doctrine
+
+This closeout doctrine is the HyperTwist-local reference target for:
+
+- `C:\HyperTwist\docs\HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md`
+- `C:\HyperTwist\docs\HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md`
+- `C:\Workspaces\HyperTwist\clean-room-specs\MODEL_OUTPUT_RULES.md`
+- `C:\Workspaces\HyperTwist\clean-room-specs\README.md`
+- repo-specific clean-room prompt-sequence and bounded-implementation prompt
+  surfaces
+
+## Retroactive note
+
+Older HyperTwist packets and summaries that predate this doctrine may still be
+useful but may not encode the exact `Result` taxonomy now required.
+
+If a current routing or retention decision depends on that missing taxonomy:
+
+- do targeted backfill
+- say explicitly that the older packet was taxonomy-ambiguous
+- do not invent certainty that the packet itself did not record

docs/ops/HYPERTWIST_WORKTREE_PLACEMENT_AND_VALIDATION_ARTIFACT_POLICY_2026-05-19.md

@@ -34,6 +34,10 @@ Cleanup rule:
   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.
 
 Operational note: