diff --git a/docs/HT_REPO_INCORPORATION_AUDIT_2026-05-11.md b/docs/HT_REPO_INCORPORATION_AUDIT_2026-05-11.md index 3c80123..fb8fa8e 100644 --- a/docs/HT_REPO_INCORPORATION_AUDIT_2026-05-11.md +++ b/docs/HT_REPO_INCORPORATION_AUDIT_2026-05-11.md @@ -78,6 +78,21 @@ Important correction added on `2026-05-13`: - absence from this report's live-evidence bucket does not prove that no human ever looked at a donor repo while writing first-party code. - it does prove that this pass did not find exact repo-tagged incorporation evidence inside the checked live Unreal project surfaces. +## 2026-05-14 interpretation update + +This audit is now explicitly an implementation-state artifact, not a default evaluation step. + +Future instances must not use bookmark presence, queue presence, planning artifacts, or doc metadata as proof of implementation. + +Future instances must also not treat this audit as something every ordinary repo evaluation needs to rerun. + +Default rule: + +- assume a repo is not implemented unless explicit implementation authority or an implementation-state-dependent task requires proof otherwise +- verify live or product-surface incorporation only when the active task actually depends on current implementation state + +Use [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) and [HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md:1) as the canonical rule for that distinction. + ## Evidence anchors - Live training source attributions in code: diff --git a/docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md b/docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md index 39d2082..0281014 100644 --- a/docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md +++ b/docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md @@ -17,6 +17,18 @@ It exists to prevent future sessions from mixing: - clean-room workflow precedent - actual live implementation truth +It now also exists to prevent future sessions from collapsing: + +- bookmarked +- queued +- source-read +- retained +- product-fit +- implementation-authorized +- implemented + +into one vague repo judgment. + ## Scope of this reconciliation This pass parsed the canonical docs, ledgers, prompts, clean-room notes, and workspace manifest that future sessions are most likely to treat as authority. @@ -59,12 +71,14 @@ The thirteen currently verified live permissive lanes are: - `poliva/cubedex` - `newyork-anthonyng/rubiks-cross-trainer` -The four currently verified live boundary-sensitive lanes are: +The six currently verified live boundary-sensitive lanes are: - `cubing/cubing.js` - `cutelyaware/magiccube4d` - `google/model-viewer/packages/shared-assets` - `PostHog/posthog` +- `screenpipe/screenpipe` +- `remotion-dev/remotion` The one currently verified live restrictive lane is: @@ -77,7 +91,7 @@ That restrictive lane must be treated as: - preserved as the current clean-room precedent - not to be reopened as an unresolved direct-donor contamination event -The remaining `54` rows are not to be treated as already implemented. +The remaining `51` rows are not to be treated as already implemented. `Phase 0R` is now closed for that non-live set. @@ -89,6 +103,30 @@ Those rows now resolve into: - retained benchmark, oracle, and clean-room-later rows - discarded active-set rows +## 2026-05-14 intake and product-fit doctrine update + +HyperTwist now treats the following as mandatory doctrine: + +- a bookmarked repo is only intake +- a queued repo is only sequencing +- a source-read repo is only evidence gained +- a retained repo is only a repo that survived evaluation in some posture +- product-fit is a separate judgment from retention +- implementation-authorized is a separate judgment from product-fit +- implemented means landed in first-party product surfaces under explicit implementation authority + +Canonical doctrine docs: + +- `docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md` +- `docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md` + +Operational implication: + +- do not let bookmark presence, queue position, frequent mention, planning artifacts, or docs metadata masquerade as product intent or proof of implementation +- routine live or product-surface scanning is no longer the default evaluation step +- assume a repo is not implemented unless explicit implementation authority says otherwise +- verify current implementation state only when the active task depends on that fact + ## Canonical-location findings ### `C:\HyperTwist\docs` @@ -133,24 +171,26 @@ It needed correction because: For restart and future widening decisions, use this order: 1. `docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md` -2. `docs/HT_REPO_INCORPORATION_AUDIT_2026-05-11.md` -3. `docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md` -4. packet-level deep-source authority docs for any repo being implemented: +2. `docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md` +3. `docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md` +4. `docs/HT_REPO_INCORPORATION_AUDIT_2026-05-11.md` +5. `docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md` +6. packet-level deep-source authority docs for any repo being implemented: - `docs/HYPERTWIST_PHASE_0R_PACKET_0R_A_EVALUATION_2026-05-12.md` - later `Phase 0R` packet docs as they are upgraded to the same standard -5. `docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md` -6. `docs/REPO_LICENSE_TRACKING.md` -7. `docs/v6_5_deep_manual_pack/README.md` -8. `docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md` -9. `docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md` -10. safe parse/workbook governance docs: +7. `docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md` +8. `docs/REPO_LICENSE_TRACKING.md` +9. `docs/v6_5_deep_manual_pack/README.md` +10. `docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md` +11. `docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md` +12. safe parse/workbook governance docs: - `06-project-agnostic-repo-evaluation-modus-operandi.md` - `07-benchmark-oracle-vs-clean-room-implementation.md` - `88-roadmap-implementation-workbook.md` - `89-phase-0-and-phase-1-bootstrap-packet.md` - `90-clean-room-safe-project-context.md` - `122-hypertwist-phase-0r-restart-authority-and-sequencing.md` -11. the current v6.3 CSV boards and prompts +13. the current v6.3 CSV boards and prompts Use the following only as lineage or historical context unless a restart doc explicitly points back to them: @@ -162,14 +202,15 @@ Use the following only as lineage or historical context unless a restart doc exp The restart is not a mass revert. -It is a provenance and planning reset around the remaining `53` current non-live rows while preserving the eighteen already-landed lanes. +It is a provenance and planning reset around the remaining `51` current non-live rows while preserving the twenty already-landed lanes. Required standing rules: -- preserve the eighteen landed lanes +- preserve the twenty landed lanes - preserve `onionhoney/roux-trainers` as the only currently verified landed restrictive clean-room lane +- do not collapse `bookmarked`, `queued`, `source-read`, `retained`, `product-fit`, `implementation-authorized`, and `implemented` - do not collapse `selected`, `retained`, `integrate`, `repurpose`, or `donor bench` into `already implemented` -- do not widen new donor-shaped implementation from the remaining `54` current non-live rows until the closed packet sequence routes it +- do not widen new donor-shaped implementation from the remaining `51` current non-live rows until the closed packet sequence routes it - before implementing any retained repo, read the packet-level deep-source authority doc for that repo class if one exists ## 2026-05-12 packet-depth correction @@ -206,7 +247,7 @@ Practical implication: Goal: -- deeply evaluate the remaining `54` rows repo by repo +- deeply evaluate the remaining `51` rows repo by repo Required output per retained row: diff --git a/docs/HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md b/docs/HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md index 1dfbd9d..abc974b 100644 --- a/docs/HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md +++ b/docs/HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md @@ -23,6 +23,25 @@ Use this document to answer the live-lane questions that the `0R-*` packets do n - what should not be promoted from each lane - what legal or provenance nuance must remain visible during future widening +## 2026-05-14 implementation-state clarification + +This audit is for lanes already proven live. + +It must not be used to weaken the broader doctrine that: + +- bookmarked is only intake +- queued is only sequencing +- source-read is only evidence +- retained is not automatically product-fit +- product-fit is not automatically implementation-authorized +- implementation-authorized is not automatically implemented + +This audit is the exception-based place to verify live first-party incorporation when a task actually depends on implementation state. + +It is not a standing requirement for ordinary evaluation of non-live rows. + +Use [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) and [HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md:1) as the canonical authority for those distinctions. + ## Safe-use boundary This document intentionally separates permissive, boundary-sensitive, and restrictive handling: diff --git a/docs/HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md b/docs/HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md index af482bc..c319f4d 100644 --- a/docs/HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md +++ b/docs/HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md @@ -64,6 +64,29 @@ It is not itself a `Model B` implementation handoff. `Model B` still implements only from scrubbed handoff materials and allowed first-party docs. +## Intake and product-fit clarification + +This doctrine does not treat bookmark presence as a reason to extract value. + +HyperTwist now treats: + +- bookmarked = intake only +- queued = sequencing only +- source-read = evidence gained +- retained = survives evaluation in some posture +- product-fit = separate judgment + +That means: + +- a repo is not entitled to rich extraction merely because it was bookmarked +- a repo is not entitled to a donor lane merely because it was source-read +- a repo may have real donor value and still fail the HyperTwist product-fit test +- a repo may be retained only as reference-only, pattern-only, or donor-only for later + +The canonical anti-conflation doctrine now also lives in: + +- [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) + ## Core doctrine ### 1. Maximize retained value @@ -219,6 +242,11 @@ When `Model A` evaluates or refreshes a retained repo, the output should try to - exact files or directories read - enough specificity that later operators know what was actually inspected +### Product-fit verdict + +- explicit statement of whether the durable value actually belongs in HyperTwist's real product direction +- no hiding product fit inside a generic repo summary + ### Preserved subsystem ideas - the deep durable value @@ -243,6 +271,20 @@ When `Model A` evaluates or refreshes a retained repo, the output should try to - explicit reasons for omitted surfaces - no vague “not needed” language +### Retention posture and owner-lane placement + +- whether the repo is worth later bounded integration, donor-only for later, reference-only, pattern-only, or not worth integrating +- which owner lane it belongs to if retained + +### Realization depth + +- 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 + +### Explicit anti-misreading note + +- what the repo should never be mistaken for +- especially when the repo is technically strong but not a product fit, or retained only in a narrow posture + ### No-copy guardrail - when the row is clean-room-sensitive, make the source-access boundary explicit diff --git a/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md b/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md new file mode 100644 index 0000000..c80e643 --- /dev/null +++ b/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md @@ -0,0 +1,141 @@ +# HyperTwist Model A / Model B Coordinator Doctrine + +Created on `2026-05-14` + +## Status + +This document is now the coordinator-facing doctrine for HyperTwist repo +evaluation, clean-room routing, and implementation-state discipline. + +It is the HyperTwist-local coordinator counterpart to: + +- [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) +- [HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md:1) +- [MODEL_B_SOURCE_ACCESS_BOUNDARY.md](C:/HyperTwist/docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md:1) + +## Purpose + +The coordinating HyperTwist instance must not let intake metadata, queue +position, frequent mention, or packet presence impersonate product truth. + +Coordinator work must keep these states separate: + +- bookmarked +- queued +- source-read +- retained +- product-fit +- implementation-authorized +- implemented + +## Core coordinator rules + +### 1. Intake is not intent + +A bookmarked repo is only intake. + +It is not: + +- an integration commitment +- a retained-donor decision +- a product-fit decision +- an implementation authorization +- proof of current implementation + +### 2. Queue is not merit + +If a repo appears in a queue, packet, sequence doc, or prompt pack, that means +sequencing only. + +It does not make the repo: + +- preferred +- stronger than an existing owner +- more product-fit than a non-queued alternative +- already implementation-authorized +- already implemented + +### 3. Source-read is evidence, not approval + +Source reading can justify stronger judgment. + +It does not, by itself, mean: + +- keep +- fit +- retain +- implement + +### 4. Retained is not automatically active build scope + +A retained repo may still be: + +- donor-only for later +- reference-only +- pattern-only +- later-horizon only +- outside current implementation scope + +### 5. Implementation requires explicit authority + +Treat a repo as implementation-authorized only when a bounded implementation +lane has been explicitly approved in the active authority path. + +Treat a repo as implemented only when first-party product surfaces actually +landed through explicit implementation authority. + +### 6. Live-surface scanning is exception-based + +Routine live or product-surface scanning is no longer the default evaluation +step. + +Assume a repo is not implemented unless explicit implementation authority says +otherwise. + +Only verify current implementation state when the active task actually depends +on it. + +## Coordinator routing order + +When coordinating repo judgment or widening, use this order: + +1. [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) +2. [HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md](C:/HyperTwist/docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md:1) +3. [HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md](C:/HyperTwist/docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md:1) +4. [HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md](C:/HyperTwist/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md:1) +5. repo-specific packet authority docs +6. [HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md:1) +7. [HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md:1) +8. [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1) +9. [MODEL_B_SOURCE_ACCESS_BOUNDARY.md](C:/HyperTwist/docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md:1) when clean-room-sensitive work is involved + +## Model A / Model B split + +Coordinator rule: + +- `Model A` may read allowed donor source where appropriate +- `Model B` must not read forbidden donor source +- if the handoff is too thin, strengthen `Model A` +- do not quietly move discovery burden into `Model B` + +## Current Phase 5R clarification + +For the current clean-room sequence: + +- repo presence in the `Phase 5R` prompt pack means active clean-room routing +- it does not mean those repos are already implemented +- it does not mean queue presence is proof of merit beyond the already-closed retained-set and packet decisions +- the prompt pack is routing authority, not product-surface proof + +## Closing rule + +The coordinating HyperTwist instance must preserve the right to say: + +- worth bookmarking, not worth integrating +- worth reading, not worth retaining +- retained, but not active build scope +- product-fit, but later-horizon only +- implementation-authorized, but not yet implemented + +If the coordinator cannot say those things cleanly, the authority docs have +drifted and must be corrected. diff --git a/docs/HYPERTWIST_PHASE_0R_PACKET_0R_A_EVALUATION_2026-05-12.md b/docs/HYPERTWIST_PHASE_0R_PACKET_0R_A_EVALUATION_2026-05-12.md index 27261b0..3ffbbf8 100644 --- a/docs/HYPERTWIST_PHASE_0R_PACKET_0R_A_EVALUATION_2026-05-12.md +++ b/docs/HYPERTWIST_PHASE_0R_PACKET_0R_A_EVALUATION_2026-05-12.md @@ -46,6 +46,44 @@ It answers, repo by repo: - which repo should own a domain when two repos overlap - how the repo should enter `Phase 2R`, `Phase 3R`, or `Phase 6R` +## 2026-05-14 intake and product-fit clarification + +This packet is source evidence plus evaluation judgment. + +It must not be read as proof that any row here was automatically: + +- favored merely because it was bookmarked earlier +- favored merely because it was queued earlier +- retained without further judgment +- a product fit by default +- implementation-authorized by default +- already implemented in first-party surfaces + +Future instances must keep the evaluation states separate: + +- bookmarked = intake only +- queued = sequencing only +- source-read = evidence gathered +- retained = survived evaluation with preserved value +- product-fit = separate judgment about HyperTwist direction +- implementation-authorized = separate bounded build approval +- implemented = landed in first-party product surfaces + +Every future evaluation refresh or reuse of this packet should keep explicit: + +- exact source basis read +- licensing posture +- preserved subsystem ideas +- subordinate or later value +- explicit product-fit verdict +- explicit non-promotion decisions with rationale +- retention posture +- owner-lane placement +- recommended implementation phase and realization depth if retained +- what the repo should never be mistaken for + +Use [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) as the canonical anti-conflation doctrine and [HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md:1) as the coordinator-facing routing rule. + ## Storage boundary To stop future confusion, the storage boundary is now explicit: diff --git a/docs/HYPERTWIST_PHASE_0R_PACKET_0R_B_EVALUATION_2026-05-12.md b/docs/HYPERTWIST_PHASE_0R_PACKET_0R_B_EVALUATION_2026-05-12.md index 7045dc1..8ac9bf1 100644 --- a/docs/HYPERTWIST_PHASE_0R_PACKET_0R_B_EVALUATION_2026-05-12.md +++ b/docs/HYPERTWIST_PHASE_0R_PACKET_0R_B_EVALUATION_2026-05-12.md @@ -75,6 +75,44 @@ It answers, repo by repo: - which repo should own a domain when multiple permissive repos overlap - how the repo should enter `Phase 2R`, `Phase 3R`, or `Phase 6R` +## 2026-05-14 intake and product-fit clarification + +This packet is source evidence plus evaluation judgment. + +It must not be read as proof that any row here was automatically: + +- favored merely because it was bookmarked earlier +- favored merely because it was queued earlier +- retained without further judgment +- a product fit by default +- implementation-authorized by default +- already implemented in first-party surfaces + +Future instances must keep the evaluation states separate: + +- bookmarked = intake only +- queued = sequencing only +- source-read = evidence gathered +- retained = survived evaluation with preserved value +- product-fit = separate judgment about HyperTwist direction +- implementation-authorized = separate bounded build approval +- implemented = landed in first-party product surfaces + +Every future evaluation refresh or reuse of this packet should keep explicit: + +- exact source basis read +- licensing posture +- preserved subsystem ideas +- subordinate or later value +- explicit product-fit verdict +- explicit non-promotion decisions with rationale +- retention posture +- owner-lane placement +- recommended implementation phase and realization depth if retained +- what the repo should never be mistaken for + +Use [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) as the canonical anti-conflation doctrine and [HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md:1) as the coordinator-facing routing rule. + ## Storage boundary To stop future confusion, the storage boundary is explicit: diff --git a/docs/HYPERTWIST_PHASE_0R_PACKET_0R_C_EVALUATION_2026-05-12.md b/docs/HYPERTWIST_PHASE_0R_PACKET_0R_C_EVALUATION_2026-05-12.md index a295b11..49775ba 100644 --- a/docs/HYPERTWIST_PHASE_0R_PACKET_0R_C_EVALUATION_2026-05-12.md +++ b/docs/HYPERTWIST_PHASE_0R_PACKET_0R_C_EVALUATION_2026-05-12.md @@ -32,6 +32,49 @@ Before a future instance implements any `0R-C` repo, it must read: 2. [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1) for license, attribution, notice, asset-term, publication, subtree, and provenance obligations 3. [HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md](C:/HyperTwist/docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md:1) for sequencing +## 2026-05-14 intake and product-fit clarification + +This packet is packet-grade source evidence. + +It is not a bookmark list. + +It is not an automatic implementation approval. + +It is not proof that every repo here belongs in HyperTwist equally. + +Future instances should read every repo section as answering, or helping answer: + +- exact source basis read +- licensing posture +- preserved subsystem ideas +- subordinate or later value +- explicit product-fit verdict +- non-promotion decisions with rationale +- retention posture +- owner-lane placement +- recommended implementation phase +- recommended realization depth +- acceptance markers if the repo later returns +- what the repo should never be mistaken for + +Evaluation-state rule: + +- bookmarked = intake only +- source-read = evidence gained +- retained = survives evaluation +- product-fit = separate judgment +- implementation-authorized = separate later judgment +- implemented = explicit landed first-party work only + +Canonical doctrine: + +- [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) + +Operational note: + +- routine live or product-surface scanning is no longer the default evaluation step +- assume a repo is not implemented unless explicit implementation authority says otherwise + ## Purpose This packet redoes `Phase 0R-C` as a true deep source parsing packet for: diff --git a/docs/HYPERTWIST_PHASE_0R_PACKET_0R_D_EVALUATION_2026-05-13.md b/docs/HYPERTWIST_PHASE_0R_PACKET_0R_D_EVALUATION_2026-05-13.md index 8e87cbd..28900ba 100644 --- a/docs/HYPERTWIST_PHASE_0R_PACKET_0R_D_EVALUATION_2026-05-13.md +++ b/docs/HYPERTWIST_PHASE_0R_PACKET_0R_D_EVALUATION_2026-05-13.md @@ -51,6 +51,48 @@ It answers, repo by repo: - which repo should own a domain when restrictive rows overlap with already-retained permissive or boundary-sensitive lanes - how the repo should enter `Phase 2R` and later `Phase 5R` clean-room implementation work +## 2026-05-14 intake, product-fit, and clean-room routing clarification + +This packet is source evidence plus retained-lane judgment. + +It must not be read as proof that any row here was automatically: + +- favored merely because it was bookmarked earlier +- favored merely because it was queued earlier +- entitled to maximum realization merely because it is restrictive +- a product fit by default +- implementation-authorized by default +- already implemented in first-party product surfaces + +Future instances must keep the state vocabulary separate: + +- bookmarked = intake only +- queued = sequencing only +- source-read = evidence gathered +- retained = survived evaluation with preserved value +- product-fit = separate judgment about HyperTwist direction +- implementation-authorized = explicit approval for a bounded clean-room build lane +- implemented = landed in first-party product surfaces under explicit implementation authority + +For these restrictive rows, clean-room prompt packs, handoff files, or queue position are routing evidence only. + +They are not proof of current implementation. + +Future refreshes of this packet and its handoffs should keep explicit: + +- exact source basis read +- licensing posture +- preserved subsystem ideas +- subordinate or later value +- explicit product-fit verdict +- explicit non-promotion decisions with rationale +- retention posture +- owner-lane placement +- recommended clean-room phase and realization depth if retained +- what the repo should never be mistaken for + +Use [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) as the canonical anti-conflation doctrine and [HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md:1) as the clean-room routing and implementation-state rule. + ## Storage boundary To stop future confusion, the storage boundary is explicit: diff --git a/docs/HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md b/docs/HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md index aa53e59..25146df 100644 --- a/docs/HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md +++ b/docs/HYPERTWIST_PHASE_0R_PACKET_0R_E_EVALUATION_2026-05-13.md @@ -51,6 +51,33 @@ It answers, repo by repo: - which repo should own a domain when these rows overlap with stronger retained donors - whether the row survives as benchmark, oracle, clean-room-later reservation, or discard +## 2026-05-14 intake and non-promotion clarification + +This packet is source evidence plus evaluation judgment. + +It must not be read as proof that any row here was automatically: + +- favored merely because it was bookmarked earlier +- favored merely because it was queued earlier +- entitled to implementation merely because it remained documented +- a product fit by default +- implementation-authorized by default +- already implemented in first-party product surfaces + +Future instances must keep the evaluation states separate: + +- bookmarked = intake only +- queued = sequencing only +- source-read = evidence gathered +- retained = survived evaluation with preserved value +- product-fit = separate judgment about HyperTwist direction +- implementation-authorized = separate bounded build approval +- implemented = landed in first-party product surfaces + +Rows that survive here as benchmark-only, reference-only, oracle-only, or clean-room-later reservations remain non-authorized until later doctrine says otherwise. + +Use [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) as the canonical anti-conflation doctrine and [HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md:1) as the routing and implementation-state rule. + ## Storage boundary To stop future confusion, the storage boundary is explicit: diff --git a/docs/HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md b/docs/HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md index 30b5cbb..a3a424c 100644 --- a/docs/HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md +++ b/docs/HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md @@ -27,6 +27,39 @@ This document answers the next question instead: - which documents must be read before that row is widened - which rows are out of the active implementation set entirely +## 2026-05-14 state-separation doctrine + +This document starts after the intake and source-evaluation stages. + +That means a row appearing here is not merely: + +- bookmarked +- queued +- source-read + +It already passed into retained-set discussion. + +But this document still must not collapse: + +- retained +- product-fit +- implementation-authorized +- implemented + +Retained-set rule: + +- a retained row here survived evaluation in some posture +- that does not automatically mean the row is a preferred donor +- that does not automatically mean maximum realization is required +- that does not automatically mean the row is currently implementation-authorized +- that does not automatically mean the row is already implemented + +Use: + +- [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) + +for the canonical definitions and anti-conflation rules. + ## Purpose `Phase 0R` closed the source-evaluation backlog. @@ -101,6 +134,7 @@ The `39` non-live active implementation-board rows break down as: ## Core doctrine - Retained rows default to `full bounded realization of their retained value`, not token helper reuse. +- Bookmark presence or queue position never grants a row ownership weight or implementation momentum by itself. - `Not foundation owner` does not mean `take one helper and forget the rest`. - For boundary-sensitive and clean-room-sensitive rows, `do not promote` and similar packet wording is a boundary filter, not a cap on later `Model A` extraction depth. - If a future `Model A` instance finds that a retained row's positive handoff is too thin, the right move is to strengthen the packet or scrubbed handoff while preserving the existing guardrails. @@ -108,6 +142,7 @@ The `39` non-live active implementation-board rows break down as: - Discarded rows are not soft-retained. They are out of the active set unless new evidence reopens them explicitly. - `Permissive` does not automatically mean `high priority`. - `MIT` or `Apache-2.0` status never outranks stronger retained anchors, domain fit, or already-set ownership boundaries. +- implementation truth is exception-based: assume a row is not implemented unless explicit landed packet authority or the live-lane audit says otherwise. ## Landed preserve lanes diff --git a/docs/HYPERTWIST_PHASE_2R_PACKET_2R_A_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md b/docs/HYPERTWIST_PHASE_2R_PACKET_2R_A_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md index 9465c9b..02814e7 100644 --- a/docs/HYPERTWIST_PHASE_2R_PACKET_2R_A_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md +++ b/docs/HYPERTWIST_PHASE_2R_PACKET_2R_A_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md @@ -43,6 +43,30 @@ These five rows define the critical entry points for: Without this packet, future instances would still be able to widen the right repos for the wrong reasons. +## 2026-05-14 ownership-routing clarification + +This packet records ownership and acceptance boundaries for retained rows. + +It does not retroactively collapse the earlier evaluation states. + +For every row in this packet, future instances must still keep separate: + +- bookmarked = intake only +- queued = sequencing only +- source-read = evidence gathered +- retained = survived evaluation +- product-fit = separate judgment that the retained value belongs in HyperTwist direction +- implementation-authorized = explicit bounded phase entry approval +- implemented = actually landed in first-party product surfaces + +Therefore: + +- appearance in this packet is not a claim that earlier bookmark or queue position had merit value +- retained status here is not proof of broad product ownership beyond the bounded lane described here +- phase entry permission here is not proof that implementation has already happened + +Use [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) for the state vocabulary and [HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md:1) for the authority-path reading rule. + ## Authority boundary Use the documents in this order for these five rows: diff --git a/docs/HYPERTWIST_PHASE_2R_PACKET_2R_B_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md b/docs/HYPERTWIST_PHASE_2R_PACKET_2R_B_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md index 5a03208..8ca381b 100644 --- a/docs/HYPERTWIST_PHASE_2R_PACKET_2R_B_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md +++ b/docs/HYPERTWIST_PHASE_2R_PACKET_2R_B_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md @@ -37,6 +37,30 @@ This packet answers the next question instead: Without this packet, future instances would still be able to widen the right support repos for the wrong reasons. +## 2026-05-14 ownership-routing clarification + +This packet records ownership and acceptance boundaries for retained support-plane rows. + +It does not collapse the earlier evaluation states into one vague approval signal. + +For every row in this packet, future instances must still keep separate: + +- bookmarked = intake only +- queued = sequencing only +- source-read = evidence gathered +- retained = survived evaluation +- product-fit = separate judgment that the retained value belongs in HyperTwist direction +- implementation-authorized = explicit bounded phase entry approval +- implemented = actually landed in first-party product surfaces + +Therefore: + +- appearance in this packet is not a claim that earlier bookmark or queue position had merit value +- retained status here is not proof of broad product ownership beyond the bounded lane described here +- phase entry permission here is not proof that implementation has already happened + +Use [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) for the state vocabulary and [HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md:1) for the authority-path reading rule. + ## Scope This packet closes ownership and acceptance for these retained `0R-B` rows: diff --git a/docs/HYPERTWIST_PHASE_2R_PACKET_2R_C_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md b/docs/HYPERTWIST_PHASE_2R_PACKET_2R_C_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md index 3269659..efb5733 100644 --- a/docs/HYPERTWIST_PHASE_2R_PACKET_2R_C_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md +++ b/docs/HYPERTWIST_PHASE_2R_PACKET_2R_C_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md @@ -37,6 +37,30 @@ This packet answers the next question instead: Without this packet, the final `0R-B` rows would still sit on inherited routing without explicit ownership and acceptance boundaries. +## 2026-05-14 ownership-routing clarification + +This packet records ownership and acceptance boundaries for retained residual rows. + +It does not collapse the earlier evaluation states into blanket approval. + +For every row in this packet, future instances must still keep separate: + +- bookmarked = intake only +- queued = sequencing only +- source-read = evidence gathered +- retained = survived evaluation +- product-fit = separate judgment that the retained value belongs in HyperTwist direction +- implementation-authorized = explicit bounded phase entry approval +- implemented = actually landed in first-party product surfaces + +Therefore: + +- appearance in this packet is not a claim that earlier bookmark or queue position had merit value +- retained status here is not proof of broad product ownership beyond the bounded lane described here +- phase entry permission here is not proof that implementation has already happened + +Use [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) for the state vocabulary and [HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md:1) for the authority-path reading rule. + ## Scope This packet closes ownership and acceptance for: diff --git a/docs/HYPERTWIST_PHASE_5R_CLEAN_ROOM_PROMPT_AND_HANDOFF_PACKET_2026-05-14.md b/docs/HYPERTWIST_PHASE_5R_CLEAN_ROOM_PROMPT_AND_HANDOFF_PACKET_2026-05-14.md index c9aafa9..554a45a 100644 --- a/docs/HYPERTWIST_PHASE_5R_CLEAN_ROOM_PROMPT_AND_HANDOFF_PACKET_2026-05-14.md +++ b/docs/HYPERTWIST_PHASE_5R_CLEAN_ROOM_PROMPT_AND_HANDOFF_PACKET_2026-05-14.md @@ -20,6 +20,8 @@ This packet does not reopen broad repo evaluation. It operationalizes the already-closed evaluation and routing work. +It also must not be misread as product-surface proof. + ## Current project state Current truth: @@ -44,6 +46,41 @@ It does not mean: - run a single source-exposed thread across all four raw restrictive repos - run one giant multi-repo bounded implementation pass +It also does not mean: + +- bookmark presence equals retained status +- queue presence equals merit +- sequence-file presence equals implementation +- prompt-pack presence equals landed product truth + +## 2026-05-14 coordinator doctrine note + +For this packet, keep the following states separate: + +- bookmarked +- queued +- source-read +- retained +- product-fit +- implementation-authorized +- implemented + +This packet means: + +- the four restrictive rows are already selected retained clean-room candidates with active routing +- the four rows are queued for explicit `Model A` and `Model B` clean-room work + +This packet does not mean: + +- those rows are already implemented +- those rows outrank stronger owners outside their approved lanes +- those rows became product truth merely by being listed here + +Canonical doctrine docs: + +- [HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md:1) +- [HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md](C:/HyperTwist/docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md:1) + ## Restrictive repos in current scope The active four-repo restrictive queue is: @@ -277,8 +314,10 @@ Current project truth: Your first operating references are: 1. C:\HyperTwist\docs\HYPERTWIST_PHASE_5R_CLEAN_ROOM_PROMPT_AND_HANDOFF_PACKET_2026-05-14.md -2. C:\HyperTwist\docs\MODEL_B_SOURCE_ACCESS_BOUNDARY.md -3. C:\Workspaces\HyperTwist\clean-room-specs\0600-phase5r-clean-room-operator-sequence-and-handoff.md +2. C:\HyperTwist\docs\HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md +3. C:\HyperTwist\docs\HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md +4. C:\HyperTwist\docs\MODEL_B_SOURCE_ACCESS_BOUNDARY.md +5. C:\Workspaces\HyperTwist\clean-room-specs\0600-phase5r-clean-room-operator-sequence-and-handoff.md Then load the current repo-specific sequence file as needed: diff --git a/docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md b/docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md index 89103b5..ac58969 100644 --- a/docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md +++ b/docs/HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md @@ -34,6 +34,52 @@ The current restart authority addendum is: Use that document when a future session needs the cross-location restart authority order, the stale-doc demotions, and the explicit post-`Phase 1R` sequence. +## 2026-05-14 intake, retention, and product-fit doctrine + +HyperTwist now treats the following as explicit evaluation doctrine: + +- `docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md` +- `docs/HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md` + +Strong rule: + +- a bookmarked repo is only intake +- a queued repo is only sequencing +- a source-read repo is only evidence gained +- a retained repo is only a repo that survived evaluation in some posture +- product-fit is a separate judgment from retention +- implementation-authorized is a separate judgment from product-fit +- implemented means landed in first-party product surfaces under explicit implementation authority + +Schedule implication: + +- do not let bookmark presence, queue position, planning artifacts, or docs metadata masquerade as product intent +- do not treat a source-read repo as automatically approved +- do not treat a retained repo as automatically implementation-authorized +- do not treat a discussed repo as already implemented + +Future serious repo evaluations should now explicitly try to state: + +- exact source basis read +- licensing posture +- preserved subsystem ideas +- subordinate or later value +- explicit product-fit verdict +- explicit non-promotion decisions +- rationale for exclusion, demotion, or non-fit +- retention posture +- owner-lane placement +- recommended implementation phase if retained +- recommended realization depth if retained +- acceptance markers if the repo later returns +- explicit statement of what the repo should never be mistaken for + +Operational scanning rule: + +- routine live or product-surface scanning is no longer the default evaluation step +- assume a repo is not implemented unless explicit implementation authority says otherwise +- only verify current implementation state when the active task specifically depends on that fact + ## 2026-05-12 Packet 0R-A status The first `Phase 0R` packet is now closed as an evaluation packet: diff --git a/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md b/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md new file mode 100644 index 0000000..798757a --- /dev/null +++ b/docs/HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md @@ -0,0 +1,442 @@ +# HyperTwist Repo Intake, Retention, And Product-Fit Doctrine + +Created on `2026-05-14` + +## Status + +This document is now the canonical HyperTwist doctrine for keeping the +following states separate: + +- bookmarked +- queued +- source-read +- retained +- product-fit +- implementation-authorized +- implemented + +It is operating doctrine. + +It is not a casual note. + +It is not packet-local wording. + +It is not a temporary preference. + +## Core rule + +A bookmarked repo is only intake. + +That means: + +- a bookmarked repo is a candidate for later review +- a bookmarked repo is not an integration commitment +- a bookmarked repo is not a retained-donor decision +- a bookmarked repo is not a product-fit decision +- a bookmarked repo is not an implementation authorization +- a bookmarked repo is not proof of ownership in any product lane +- a bookmarked repo is not proof that it should survive evaluation +- a bookmarked repo is not proof that it should receive maximum realization later +- a bookmarked repo is not proof that it belongs in HyperTwist at all + +HyperTwist must preserve the right to stop cleanly at any later stage. + +## Anti-conflation rule + +Future HyperTwist instances must not collapse the following into one vague +“good repo” judgment: + +- bookmarked != retained +- retained != product-fit +- product-fit != implementation-authorized +- implementation-authorized != implemented +- source-read != approved +- queued != preferred +- compared != selected +- legally usable != strategically correct +- feature-rich != product-relevant +- technically elegant != worth integrating + +These distinctions are mandatory. + +They belong in the authority path, not only in one packet summary. + +## Multi-stage decision model + +Every serious repo evaluation should keep the following questions separate. + +### 1. Intake question + +Was the repo worth bookmarking, parking, or capturing for later review? + +This is the weakest statement. + +It means only: + +- worth remembering +- worth revisiting +- possibly relevant later + +It means nothing stronger. + +### 2. Source-evidence question + +Has the repo actually been read deeply enough to justify a real judgment? + +Possible evidence levels include: + +- no real source read yet +- shallow metadata only +- README-level read only +- selective source read +- full packet-grade source evaluation + +Bookmark presence must never masquerade as evidence. + +### 3. Donor-value question + +Does the repo contain durable value at all? + +Possible value classes include: + +- architecture +- domain models +- contracts +- runtime patterns +- orchestration logic +- protocol seams +- persistence models +- UX patterns +- workflow patterns +- tests or fixtures +- observability patterns +- tooling structure +- adapter patterns +- clean-room-worthy subsystem ideas + +A repo may contain no meaningful donor value. + +That is an allowed conclusion. + +### 4. Product-fit question + +Even if a repo has donor value, does that value fit HyperTwist’s actual +product direction? + +This verdict must be explicit. + +A repo can be: + +- impressive +- legally usable +- feature-rich +- technically strong +- architecturally interesting +- worth studying + +and still not fit HyperTwist. + +That is a valid result. + +Donor value is not the same as product fit. + +### 5. Retention question + +If the repo has real value and meaningful fit, what is its retained posture? + +Allowed outcomes include: + +- worth later bounded integration +- donor-only for later +- reference-only +- pattern-only +- not worth integrating + +These outcomes are materially different and must not be blurred. + +### 6. Ownership question + +If retained, what exact lane does the repo belong to? + +Examples: + +- primary owner of a bounded subsystem +- secondary owner inside a narrower lane +- subordinate donor under a stronger owner +- adjacent donor beside a stronger owner +- reference-only and not an owner at all + +Bookmark presence must not give a repo artificial ownership weight. + +### 7. Realization-depth question + +If the repo later returns, what is the intended depth? + +Possible outcomes: + +- no implementation +- reference-only +- pattern-only +- bounded subsystem realization +- broader but still bounded realization +- full positive realization of the retained lane + +Do not jump from bookmark to “must fully integrate.” + +### 8. Implementation question + +If retained, what exact bounded lane should it enter, at what phase, and at +what depth? + +Implementation authorization must be explicit. + +Planning artifacts alone are not authorization. + +## Required evaluation output standard + +Every serious repo evaluation should now try to state all of the following: + +- exact source basis read +- licensing posture +- preserved subsystem ideas +- subordinate or later value +- explicit product-fit verdict +- explicit non-promotion decisions +- rationale for exclusion, demotion, or non-fit +- retention posture +- owner-lane placement +- recommended implementation phase if retained +- recommended realization depth if retained +- acceptance markers if it later returns +- explicit statement of what the repo should never be mistaken for + +The product-fit verdict must not be implicit. + +It must be explicit. + +## Approved non-fit or non-integration outcomes + +HyperTwist should be able to conclude any of the following without friction: + +- worth bookmarking, not worth integrating +- worth reading, not worth retaining +- technically valuable, not a product fit +- product-adjacent, but not within current scope +- weaker overlap under a stronger owner +- donor-only for later +- reference-only +- pattern-only +- interesting but strategically distracting +- valuable in theory, not worth the implementation burden +- not worth integrating at all + +These are valid outcomes. + +Do not force every bookmarked repo toward implementation. + +## Approved rationale classes + +If a bookmarked repo is later judged non-fit, non-retained, or non-integrated, +record a concrete reason. + +Approved rationale classes include: + +- off-topic to HyperTwist product scope +- inferior duplicate +- superseded by stronger retained owner +- weaker overlapping implementation +- host-shell glue +- commodity scaffolding +- boundary-sensitive value better kept as reference +- architecture mismatch +- workflow mismatch +- strategic non-fit +- later-horizon only +- useful pattern, but not a real donor lane +- not worth the integration cost relative to likely product gain + +No vague dismissal language. + +No hand-waving. + +No silent downgrade. + +No drift from bookmark to exclusion without rationale. + +## Owner-boundary rule + +A bookmarked repo must not receive special authority merely because it was +captured. + +It must not displace: + +- stronger retained owners +- first-party product architecture +- already-closed packet outcomes +- established subsystem boundaries +- stronger-fitting donors +- more coherent product direction + +If a bookmarked repo loses an ownership comparison, record why. + +If it still has residual value in a narrower lane, preserve that value there. + +If it has no durable lane, say so. + +## Failure cases to prevent + +This doctrine exists to block the following failure modes: + +### 1. Bookmark inflation + +A repo gets bookmarked and later instances start speaking about it as if it is +already favored. + +### 2. Queue inflation + +A repo appears in a sequence doc and later instances start treating queue +position as a merit signal. + +### 3. Evaluation inflation + +A repo gets source-read and later instances assume that source-read means it +belongs in the product. + +### 4. Retention inflation + +A repo is retained for some bounded value and later instances start speaking as +if the full product should be integrated. + +### 5. Implementation inflation + +A repo is discussed often enough that later instances casually describe it as +if it already exists in product surfaces. + +All of these are doctrine failures. + +## Operational vocabulary + +Use these definitions. + +### Bookmarked + +Captured for later review only. + +### Queued + +Placed into an evaluation or execution sequence only. + +### Source-read + +Evidence has been gathered from actual source materials. + +### Retained + +The repo survived evaluation as having some meaningful preserved value. + +### Product-fit + +The retained value actually belongs in HyperTwist’s real product direction. + +### Implementation-authorized + +A bounded implementation lane has been explicitly approved. + +### Implemented + +The bounded work has actually landed in first-party product surfaces under +explicit implementation authority. + +### Reference-only + +Useful to study, not intended for direct donor realization. + +### Pattern-only + +Useful as inspiration or recurring design pattern, not as a retained donor +lane. + +### Donor-only for later + +Potentially useful later, but not active implementation scope now. + +### Not worth integrating + +No later bounded implementation should be assumed from the current evaluation. + +## Max-value extraction still applies + +This doctrine must not make evaluation timid. + +Do not interpret “bookmark is only intake” as permission to do shallow review. + +If a repo is actually relevant: + +- read it properly +- extract value richly +- say clearly if it deserves a bounded retained lane +- say clearly if it deserves maximum realization inside that lane + +The point of this doctrine is not: + +- to weaken extraction +- to flatten donors +- to become fear-driven +- to avoid hard judgments + +The point is: + +- to stop intake metadata from masquerading as product intent +- to preserve honest product-fit decisions +- to prevent false momentum toward implementation + +## Live or product-surface scanning rule + +Routine live or product-surface scanning is no longer the default evaluation +step. + +Assume a repo is not implemented unless explicit implementation authority says +otherwise. + +Only verify live or product-surface incorporation when the active task +specifically depends on current implementation state. + +Bookmarks, queues, planning artifacts, and docs metadata are not proof of +implementation. + +## Authority use + +Use HyperTwist docs this way: + +- this document: + - intake doctrine + - anti-conflation rules + - product-fit doctrine + - evaluation-state vocabulary +- packet docs: + - repo-specific source evidence + - donor-value extraction + - product-fit verdicts + - retention posture + - owner-lane placement +- retained-set and routing docs: + - next-phase entry + - implementation authorization routing +- landed implementation packets and live-lane audit: + - proof of implementation + +## Closing rule + +Future HyperTwist instances must be able to answer, for any repo: + +- Was it only bookmarked? +- Was it actually source-evaluated? +- Does it contain durable donor value? +- Does that value fit the product? +- Is it retained? +- In what posture is it retained? +- Is it implementation-authorized? +- Has it actually been implemented? + +If those answers are not easy to recover from the authority docs, the docs are +too weak and should be strengthened. diff --git a/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md b/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md index 0344f04..d87a8e5 100644 --- a/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md +++ b/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md @@ -121,6 +121,35 @@ Packet overlay result: - `3` discarded active-set rows - the next bounded move is `Phase 5R-A` +## 2026-05-14 state-vocabulary and anti-inflation rule + +This board is not allowed to collapse the following states: + +- bookmarked +- queued +- source-read +- retained +- product-fit +- implementation-authorized +- implemented + +Board-reading rule: + +- bookmarked = intake only +- queued = sequencing only +- source-read = evidence gained +- retained = survives evaluation in some posture +- product-fit = belongs in HyperTwist's actual product direction +- implementation-authorized = explicitly approved for bounded build work +- implemented = actually landed in first-party product surfaces by explicit implementation authority + +This board is not proof of bookmark merit by itself. + +This board is not proof of implementation by itself. + +Use explicit `Current live state`, landed packet authority, and the live-lane +audit when implementation truth matters. + ## Count by live-state class - `implemented_live_permissive`: `13` @@ -137,6 +166,10 @@ Packet overlay result: - `Current live state` is the corrected 2026-05-11 implementation truth. - `Reset lane` is the required post-audit scheduling lane. - `Next step` is the immediate repo-specific action after the reset. +- `Prior bucket`, `Prior action`, `Reset lane`, and `Next step` are not merit signals by themselves. +- queue position or row presence does not prove product fit. +- row presence does not prove implementation. +- routine live-surface scanning is no longer the default evaluation step; when implementation truth matters, verify it from explicit implementation authority rather than from queue or board metadata alone. ## Landed Permissive Lanes diff --git a/docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md b/docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md index 4119335..2b3ccff 100644 --- a/docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md +++ b/docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md @@ -24,6 +24,8 @@ Purpose: - `C:\HyperTwist\docs\HYPERTWIST_PHASE_2R_PACKET_2R_B_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md` - `C:\HyperTwist\docs\HYPERTWIST_PHASE_2R_PACKET_2R_C_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md` - `C:\HyperTwist\docs\HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md` + - `C:\HyperTwist\docs\HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md` + - `C:\HyperTwist\docs\HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md` - `C:\HyperTwist\docs\HYPERTWIST_PHASE_5R_CLEAN_ROOM_PROMPT_AND_HANDOFF_PACKET_2026-05-14.md` - `C:\HyperTwist\docs\REPO_LICENSE_TRACKING.md` - `C:\HyperTwist\docs\arch\HYPERTWIST_IMPORTED_GENERATED_MODE_EXECUTOR_PACKET_2026-05-05.md` diff --git a/docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md b/docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md index 9d726c1..bc6d881 100644 --- a/docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md +++ b/docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md @@ -13,6 +13,19 @@ HyperTwist should be developed as a serious native product: Do not reopen broad donor-driven widening as if the whole retained portfolio were already settled. +State-separation rule: + +- bookmarked = intake only +- queued = sequencing only +- source-read = evidence gained +- retained = survives evaluation in some posture +- product-fit = separate judgment +- implementation-authorized = explicitly approved bounded build work +- implemented = actually landed in first-party product surfaces + +Do not let bookmark presence, queue position, or frequent mention masquerade as +product intent or proof of implementation. + Current truth: - `20` repos are currently verified live in checked Unreal surfaces @@ -44,6 +57,14 @@ For boundary-sensitive and restrictive rows: Canonical doctrine doc: - `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:\HyperTwist\docs\HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md` + +Implementation-state scanning note: + +- routine live or product-surface scanning is no longer the default evaluation step +- assume a repo is not implemented unless explicit implementation authority says otherwise +- only verify current implementation state when the active task depends on that fact Next sequence: diff --git a/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md b/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md index b774fe5..aa401dd 100644 --- a/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md +++ b/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md @@ -4,6 +4,19 @@ Before widening new HyperTwist donor-driven implementation beyond the already landed lanes, preserve this current truth: +State-separation rule: + +- bookmarked = intake only +- queued = sequencing only +- source-read = evidence gained +- retained = survives evaluation in some posture +- product-fit = separate judgment +- implementation-authorized = explicitly approved bounded build work +- implemented = actually landed in first-party product surfaces + +Do not let bookmark presence, queue position, planning artifacts, or docs +metadata masquerade as product intent or proof of implementation. + - current shallow-eval set: `71` repos - currently verified live/implemented in checked Unreal surfaces: `20` - permissive live lanes: `13` @@ -35,6 +48,17 @@ Current routing truth: The next bounded move is `Phase 5R-A`, with the optional `Phase 3R-G` browser comparison lane deferred unless the landed primary browser spatial stack exposes a real gap. +Canonical doctrine docs: + +- `C:\HyperTwist\docs\HYPERTWIST_REPO_INTAKE_RETENTION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md` +- `C:\HyperTwist\docs\HYPERTWIST_MODEL_A_MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md` + +Operational scanning note: + +- routine live or product-surface scanning is no longer the default evaluation step +- assume a repo is not implemented unless explicit implementation authority says otherwise +- only verify current implementation state when the active task depends on that fact + ## Reset phases ### Phase `0R` — remaining repo deep evaluation