Clarify HyperTwist Model A extraction doctrine
This commit is contained in:
axiomlogicnexus
parent
20a8582918
commit
022a578e79
8 changed files with 376 additions and 8 deletions
|
|
@ -0,0 +1,316 @@
|
|||
# HyperTwist Model A Max-Value Extraction Modus Operandi
|
||||
|
||||
Created on `2026-05-13`
|
||||
|
||||
## Status
|
||||
|
||||
This document is now the canonical `Model A source-evaluation and handoff doctrine` for HyperTwist.
|
||||
|
||||
It clarifies how future `Model A` instances should interpret:
|
||||
|
||||
- `0R` packet source-value extraction
|
||||
- `non-promotion` language
|
||||
- `do not promote` and `do not preserve literally` wording
|
||||
- clean-room handoff scope
|
||||
- the difference between `governance exclusion` and `implementation thinning`
|
||||
|
||||
It is additive authority.
|
||||
|
||||
It does not replace superior repo-specific source findings already recorded in:
|
||||
|
||||
- `0R-A`
|
||||
- `0R-B`
|
||||
- `0R-C`
|
||||
- `0R-D`
|
||||
- `0R-E`
|
||||
- the live-lane preservation audit
|
||||
|
||||
If an older packet already says something more precise, keep that precision.
|
||||
|
||||
Use this document to interpret those packets correctly and to prevent future over-narrowing.
|
||||
|
||||
## Purpose
|
||||
|
||||
HyperTwist wants maximum durable value from retained repos.
|
||||
|
||||
That means future `Model A` work must:
|
||||
|
||||
- read source directly where allowed
|
||||
- extract the deepest durable subsystem value
|
||||
- write richer positive handoffs when a retained repo supports them
|
||||
- omit only the surfaces that genuinely should not survive
|
||||
|
||||
This document exists because `do not promote` language can be misread.
|
||||
|
||||
That wording is not supposed to scare later `Model A` instances into shallow handoffs.
|
||||
|
||||
It is supposed to:
|
||||
|
||||
- protect ownership boundaries
|
||||
- stop host-shell noise from being laundered into core architecture
|
||||
- stop exact-source or exact-API copying
|
||||
- keep later `Model B` work clean
|
||||
|
||||
## Scope boundary
|
||||
|
||||
This doctrine is for:
|
||||
|
||||
- future `Model A` source-reading work
|
||||
- refreshed `0R` packet updates
|
||||
- refreshed `Model A` clean-room handoffs
|
||||
- future boundary-sensitive donor interpretation work
|
||||
|
||||
It is not itself a `Model B` implementation handoff.
|
||||
|
||||
`Model B` still implements only from scrubbed handoff materials and allowed first-party docs.
|
||||
|
||||
## Core doctrine
|
||||
|
||||
### 1. Maximize retained value
|
||||
|
||||
For any retained repo, `Model A` should try to capture the full bounded value of the retained domain.
|
||||
|
||||
Default posture:
|
||||
|
||||
- `full bounded realization of retained value`
|
||||
|
||||
Not default posture:
|
||||
|
||||
- one helper
|
||||
- one convenience function
|
||||
- one tiny token reference just because the repo is legally sensitive
|
||||
|
||||
If the retained domain is rich, the handoff should be rich.
|
||||
|
||||
### 2. Positive scope comes first
|
||||
|
||||
The main output of `Model A` should be the positive scope:
|
||||
|
||||
- what subsystem ideas survive
|
||||
- what first-party target should exist
|
||||
- what acceptance markers define success
|
||||
- what implementation order makes sense
|
||||
|
||||
Negative exclusions matter, but they are secondary.
|
||||
|
||||
Do not let the exclusion list become the center of gravity.
|
||||
|
||||
### 3. Non-promotion language is a filter, not a cap
|
||||
|
||||
When a packet says:
|
||||
|
||||
- `do not promote`
|
||||
- `do not preserve literally`
|
||||
- `host-shell glue`
|
||||
- `off topic`
|
||||
- `superseded by stronger retained donor`
|
||||
|
||||
interpret it narrowly.
|
||||
|
||||
It usually means one of these:
|
||||
|
||||
- do not preserve exact source text, exact type names, exact API signatures, exact query params, exact comments, or exact UI shell
|
||||
- do not let the repo displace an already stronger retained owner outside its proper lane
|
||||
- do not promote demos, packaging, marketing, community chrome, boilerplate scaffolding, or commodity glue as primary donor value
|
||||
- do not widen a narrow donor into a whole-product owner when the retained value is bounded
|
||||
|
||||
It does **not** mean:
|
||||
|
||||
- stop extracting meaningful subsystem value
|
||||
- reduce a rich retained lane to one helper
|
||||
- prevent a future `Model A` from writing a stronger positive clean-room handoff
|
||||
|
||||
### 4. Stronger-owner boundaries still matter
|
||||
|
||||
HyperTwist already made portfolio-level decisions about ownership.
|
||||
|
||||
If a stronger retained owner already exists, keep that boundary.
|
||||
|
||||
Examples of what this means:
|
||||
|
||||
- a viewer donor should not silently become the runtime owner
|
||||
- a compact parser donor should not silently become a whole classic-cubing runtime owner
|
||||
- a strategic support-plane donor should not silently displace a foundation anchor
|
||||
|
||||
But this still does **not** justify shrinking the retained value inside the donor's proper lane.
|
||||
|
||||
Correct reading:
|
||||
|
||||
- preserve the donor richly inside its approved lane
|
||||
- do not let it annex adjacent lanes that already have a stronger owner
|
||||
|
||||
### 5. Literal no-copy rules are separate from subsystem richness
|
||||
|
||||
`Do not preserve literally` means:
|
||||
|
||||
- no exact copied source
|
||||
- no exact copied grammar text
|
||||
- no exact copied API surface
|
||||
- no exact copied comments/docstrings
|
||||
- no exact copied UI shell
|
||||
|
||||
It does not mean:
|
||||
|
||||
- no full re-authored subsystem
|
||||
|
||||
HyperTwist wants full first-party subsystems where the retained value justifies them.
|
||||
|
||||
It does not want exact-source carryover.
|
||||
|
||||
### 6. If the handoff undercaptures value, strengthen the handoff
|
||||
|
||||
If a future `Model A` instance reads a retained repo and finds that the existing handoff is too thin, the correct move is:
|
||||
|
||||
1. strengthen the packet or handoff
|
||||
2. expand the positive scope
|
||||
3. keep the guardrails
|
||||
4. leave `Model B` source isolation intact
|
||||
|
||||
The wrong move is:
|
||||
|
||||
1. let `Model B` improvise from too little guidance
|
||||
2. let `Model B` inspect the restrictive mirror
|
||||
3. silently flatten the subsystem because the handoff was weak
|
||||
|
||||
### 7. Exclusions must be justified, not guessed
|
||||
|
||||
Any exclusion should name the reason clearly.
|
||||
|
||||
Approved exclusion classes:
|
||||
|
||||
- inferior duplicate
|
||||
- superseded by a stronger retained donor
|
||||
- off topic to HyperTwist's retained product scope
|
||||
- host-shell glue with no durable architecture value
|
||||
- commodity scaffolding with no strategic differentiation
|
||||
- legal, asset-term, or subtree surface that cannot safely enter the lane as ordinary donor value
|
||||
|
||||
If `Model A` cannot explain the exclusion concretely, it should not exclude the surface casually.
|
||||
|
||||
### 8. Clean-room richness belongs to Model A, not Model B
|
||||
|
||||
For restrictive rows:
|
||||
|
||||
- `Model A` is supposed to do the rich thinking
|
||||
- `Model A` is supposed to decide the subsystem boundaries
|
||||
- `Model A` is supposed to write the full positive handoff
|
||||
|
||||
`Model B` is not the place to rediscover donor value from source.
|
||||
|
||||
That would defeat the clean-room chain.
|
||||
|
||||
So the right way to stay rich is:
|
||||
|
||||
- richer `Model A`
|
||||
- stronger positive handoff
|
||||
- tighter `Model B` source isolation
|
||||
|
||||
not:
|
||||
|
||||
- weaker `Model A`
|
||||
- more source freedom for `Model B`
|
||||
|
||||
## Required outputs from future Model A passes
|
||||
|
||||
When `Model A` evaluates or refreshes a retained repo, the output should try to include all of these where relevant:
|
||||
|
||||
### Source basis
|
||||
|
||||
- exact files or directories read
|
||||
- enough specificity that later operators know what was actually inspected
|
||||
|
||||
### Preserved subsystem ideas
|
||||
|
||||
- the deep durable value
|
||||
- not just the most obvious exported functions
|
||||
|
||||
### HyperTwist-first target
|
||||
|
||||
- what first-party subsystem HyperTwist should own afterward
|
||||
- stated in HyperTwist terms rather than donor-shell terms
|
||||
|
||||
### Acceptance markers
|
||||
|
||||
- observable signs that the later implementation captured the retained value
|
||||
- structural and behavioral, not donor-name-dependent
|
||||
|
||||
### Recommended implementation order
|
||||
|
||||
- a practical sequence for later first-party realization
|
||||
|
||||
### Exclusion rationale
|
||||
|
||||
- explicit reasons for omitted surfaces
|
||||
- no vague “not needed” language
|
||||
|
||||
### No-copy guardrail
|
||||
|
||||
- when the row is clean-room-sensitive, make the source-access boundary explicit
|
||||
|
||||
## Retroactive interpretation rule for existing packets
|
||||
|
||||
This doctrine applies retroactively to the already closed HyperTwist packets.
|
||||
|
||||
When reading any existing `0R` packet:
|
||||
|
||||
- treat `high-value salvage` and equivalent sections as the positive scope center
|
||||
- treat `subordinate or later value` as demotion, not erasure
|
||||
- treat `non-promotion decisions and rationale` as boundary protection, not automatic minimization
|
||||
- treat `do not preserve literally` as anti-copy guidance, not anti-subsystem guidance
|
||||
|
||||
If an older packet appears too narrow relative to the retained value:
|
||||
|
||||
- update the packet
|
||||
- update the clean-room or boundary-sensitive handoff
|
||||
- preserve the guardrails
|
||||
|
||||
Do not push the ambiguity downstream into `Model B`.
|
||||
|
||||
## Document responsibility split
|
||||
|
||||
Use the HyperTwist docs this way:
|
||||
|
||||
- `0R` packets:
|
||||
- source-value extraction
|
||||
- overlap resolution
|
||||
- exclusion rationale
|
||||
- repo-by-repo retained scope
|
||||
- this document:
|
||||
- interpretation doctrine for future `Model A` work
|
||||
- anti-over-narrowing rule
|
||||
- clean distinction between governance exclusion and subsystem richness
|
||||
- `REPO_LICENSE_TRACKING.md`:
|
||||
- repo-row legal posture
|
||||
- attribution
|
||||
- notice duties
|
||||
- publication duties
|
||||
- provenance exceptions
|
||||
- `*.model-a.md` scrubbed handoffs:
|
||||
- the positive clean-room implementation target for `Model B`
|
||||
- `MODEL_B_SOURCE_ACCESS_BOUNDARY.md`:
|
||||
- clean-room access constraints for `Model B`
|
||||
- `Phase 1R` contract:
|
||||
- routing
|
||||
- class assignment
|
||||
- next phase
|
||||
|
||||
## Practical operator rule
|
||||
|
||||
If you are a future `Model A` instance and a retained repo still looks richer than the current handoff:
|
||||
|
||||
1. keep the existing owner boundaries
|
||||
2. keep the no-copy guardrails
|
||||
3. keep the repo inside its retained lane
|
||||
4. extract more value, not less
|
||||
5. update the positive handoff
|
||||
6. document the rationale for every exclusion
|
||||
|
||||
That is the intended HyperTwist posture.
|
||||
|
||||
## Current closure note
|
||||
|
||||
This doctrine does not reopen `Phase 4R-A`.
|
||||
|
||||
`Phase 4R-A` remains closed.
|
||||
|
||||
This document only clarifies how future `Model A` instances should read and extend the retained-value work that surrounds the closed packet sequence.
|
||||
|
|
@ -19,6 +19,13 @@ This packet applies the same deep-source standard already established by `0R-A`
|
|||
|
||||
For these six repos, this document is now the canonical `integration-facing` authority.
|
||||
|
||||
Interpretation clarification added on `2026-05-13`:
|
||||
|
||||
- future `Model A` instances should treat this packet's `non-promotion` language as a boundary filter, not as an instruction to thin later retained-value extraction
|
||||
- later `Model A` work should still pursue full bounded realization of the retained domain for each row
|
||||
- only exact-source carryover, host-shell glue, inferior duplicate value, off-topic value, or ownership-displacing value should stay excluded
|
||||
- the canonical doctrine for that reading now lives in [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)
|
||||
|
||||
Before a future instance implements any `0R-C` repo, it must read:
|
||||
|
||||
1. this document for source-value extraction, boundary discipline, and exclusion rationale
|
||||
|
|
@ -50,6 +57,7 @@ It answers, repo by repo:
|
|||
To stop future confusion, the storage boundary is explicit:
|
||||
|
||||
- `this packet doc`: source-value extraction, implementation posture, overlap resolution, exclusion rationale, and boundary-use recommendations
|
||||
- [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): canonical interpretation rule for future `Model A` max-value extraction so `non-promotion` wording is not misread as implementation-thinning doctrine
|
||||
- [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1): repo-row license, attribution, copyright, notice, asset-term, publication, subtree, and provenance obligations
|
||||
- [HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md](C:/HyperTwist/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md:1): row state and next-step board
|
||||
- [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): packet sequencing and restart phases
|
||||
|
|
|
|||
|
|
@ -19,6 +19,13 @@ This packet applies the same deep-source standard already established by `0R-A`,
|
|||
|
||||
For these four repos, this document is now the canonical `governance and Model A authority` packet.
|
||||
|
||||
Interpretation clarification added on `2026-05-13`:
|
||||
|
||||
- the `do not promote`, `do not preserve literally`, and `non-promotion` wording in this packet is meant to protect boundaries, not to deter later `Model A` instances from writing richer clean-room handoffs
|
||||
- future `Model A` instances should still extract the maximum durable value inside each retained restrictive lane
|
||||
- if a scrubbed handoff undercaptures the retained domain, strengthen the handoff rather than forcing later `Model B` work to improvise
|
||||
- the canonical doctrine for that reading now lives in [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)
|
||||
|
||||
Before a future instance implements any `0R-D` repo, it must read:
|
||||
|
||||
1. this document for source-value extraction, exclusion rationale, and clean-room lane selection
|
||||
|
|
@ -49,6 +56,7 @@ It answers, repo by repo:
|
|||
To stop future confusion, the storage boundary is explicit:
|
||||
|
||||
- `this packet doc`: source-value extraction, implementation posture, overlap resolution, exclusion rationale, and refreshed Model A scope
|
||||
- [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): canonical interpretation rule for future `Model A` max-value extraction and anti-over-narrowing guidance
|
||||
- [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1): repo-row license, attribution, notice, publication, subtree, and provenance obligations
|
||||
- `C:\Workspaces\HyperTwist\clean-room-specs\*.model-a.md`: the only scrubbed Model B handoff inputs for later clean-room implementation
|
||||
- [HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md](C:/HyperTwist/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md:1): row state and next-step board
|
||||
|
|
@ -59,6 +67,11 @@ This packet is a `governance and Model A` authority doc, not a Model B implement
|
|||
|
||||
Model B must not treat this document as a substitute for the scrubbed clean-room specs.
|
||||
|
||||
Future `Model A` work, however, should treat this packet and the canonical modus-operandi doc together:
|
||||
|
||||
- this packet defines repo-specific retained value and boundary protection
|
||||
- the modus-operandi doc defines how to keep later `Model A` clean-room extraction rich rather than shallow
|
||||
|
||||
## Packet licensing snapshot
|
||||
|
||||
- `cubing/alg.js`: `GPL-3.0-or-later`
|
||||
|
|
|
|||
|
|
@ -51,12 +51,14 @@ Use the documents in this order:
|
|||
1. this document for retained-set class, phase entry, and handoff routing
|
||||
2. [HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md](C:/HyperTwist/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md:1) for row-by-row readable state
|
||||
3. the relevant `0R-*` packet for source-value extraction and exclusion rationale
|
||||
4. [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1) for repo-row legal, attribution, notice, and provenance obligations
|
||||
5. [MODEL_B_SOURCE_ACCESS_BOUNDARY.md](C:/HyperTwist/docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md:1) when a row is clean-room-sensitive or benchmark-only
|
||||
4. [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) for the canonical interpretation rule that keeps future `Model A` work rich inside retained lanes
|
||||
5. [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1) for repo-row legal, attribution, notice, and provenance obligations
|
||||
6. [MODEL_B_SOURCE_ACCESS_BOUNDARY.md](C:/HyperTwist/docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md:1) when a row is clean-room-sensitive or benchmark-only
|
||||
|
||||
Document responsibilities are now strict:
|
||||
|
||||
- `0R` packet docs own source-value extraction and non-promotion rationale
|
||||
- [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) owns the anti-over-narrowing interpretation rule for future `Model A` work
|
||||
- `REPO_LICENSE_TRACKING.md` owns repo-row licensing and attribution detail
|
||||
- this document owns retained-set routing and phase entry
|
||||
- the state board owns the readable row-by-row companion view
|
||||
|
|
@ -77,7 +79,7 @@ Retained split:
|
|||
- non-live active implementation-board rows: `44`
|
||||
- non-live benchmark, oracle, or clean-room-later rows outside the active implementation board: `9`
|
||||
|
||||
The `45` non-live active implementation-board rows break down as:
|
||||
The `44` non-live active implementation-board rows break down as:
|
||||
|
||||
- straight permissive implementation candidates: `35`
|
||||
- boundary-sensitive adapter or sidecar candidates: `5`
|
||||
|
|
@ -100,6 +102,8 @@ The `45` non-live active implementation-board rows break down as:
|
|||
|
||||
- Retained rows default to `full bounded realization of their retained value`, not token helper reuse.
|
||||
- `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.
|
||||
- Benchmark and oracle rows are not implementation-ready just because they remain documented.
|
||||
- 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`.
|
||||
|
|
@ -140,7 +144,7 @@ Contract:
|
|||
|
||||
- preserve as the landed first-party boundary-sensitive classic-cubing adapter lane
|
||||
- preserve the explicit `MPL` notice and publication-duty boundary
|
||||
- read [HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md:1), then [HYPERTWIST_PHASE_4R_PACKET_4R_A_CUBING_JS_ADAPTER_IMPLEMENTATION_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_PHASE_4R_PACKET_4R_A_CUBING_JS_ADAPTER_IMPLEMENTATION_2026-05-13.md:1), before widening this lane
|
||||
- read [HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md:1), then [HYPERTWIST_PHASE_4R_PACKET_4R_A_CUBING_JS_ADAPTER_IMPLEMENTATION_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_PHASE_4R_PACKET_4R_A_CUBING_JS_ADAPTER_IMPLEMENTATION_2026-05-13.md:1), then [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), before widening this lane
|
||||
- do not treat the mirror as a silent private-fork surface
|
||||
|
||||
### Landed restrictive clean-room preserve
|
||||
|
|
@ -151,7 +155,7 @@ Contract:
|
|||
|
||||
- preserve as the only currently verified restrictive lane that was properly clean-roomed and then implemented
|
||||
- keep the Model A / Model B lineage explicit
|
||||
- read [HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md:1) before widening this lane
|
||||
- read [HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md:1) and [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) before widening this lane
|
||||
- never treat the donor mirror itself as implementation-ready source
|
||||
|
||||
## Active implementation-board rows
|
||||
|
|
@ -254,6 +258,7 @@ Contract:
|
|||
Contract:
|
||||
|
||||
- read `Packet 0R-C` before any widening
|
||||
- read [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) so boundary-sensitive `non-promotion` language is not misread as a shallow-extraction rule
|
||||
- do not treat any of these rows as broad donor shells
|
||||
- resolve notice, asset-term, enterprise-slice, commercial, or allowlist questions in `Phase 4R` before implementation starts
|
||||
|
||||
|
|
@ -267,6 +272,7 @@ Contract:
|
|||
Contract:
|
||||
|
||||
- read `Packet 0R-D`
|
||||
- read [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)
|
||||
- then read the scrubbed Model A handoff in `C:\Workspaces\HyperTwist\clean-room-specs\`
|
||||
- implementation may start only in `Phase 5R`
|
||||
- donor source is not an allowed implementation input
|
||||
|
|
@ -312,8 +318,9 @@ Before touching any non-live retained row:
|
|||
|
||||
1. read this `Phase 1R` contract doc
|
||||
2. read the relevant `0R-*` packet
|
||||
3. read `REPO_LICENSE_TRACKING.md`
|
||||
4. if the row is clean-room-sensitive or benchmark-only, obey `MODEL_B_SOURCE_ACCESS_BOUNDARY.md`
|
||||
3. read [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)
|
||||
4. read `REPO_LICENSE_TRACKING.md`
|
||||
5. if the row is clean-room-sensitive or benchmark-only, obey `MODEL_B_SOURCE_ACCESS_BOUNDARY.md`
|
||||
|
||||
Do not:
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,8 @@ For future work on the classic-cubing boundary-sensitive lane, read in this orde
|
|||
2. [HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md](C:/HyperTwist/docs/HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md:1) for live-lane preserve posture
|
||||
3. [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) for retained-set routing
|
||||
4. [HYPERTWIST_PHASE_0R_PACKET_0R_C_EVALUATION_2026-05-12.md](C:/HyperTwist/docs/HYPERTWIST_PHASE_0R_PACKET_0R_C_EVALUATION_2026-05-12.md:1) for source-value extraction and non-promotion rationale
|
||||
5. [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1) for license, notice, and provenance obligations
|
||||
5. [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) for the canonical interpretation rule that keeps future `Model A` boundary-sensitive extraction rich rather than shallow
|
||||
6. [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1) for license, notice, and provenance obligations
|
||||
|
||||
## Packet licensing snapshot
|
||||
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ Purpose:
|
|||
- `C:\HyperTwist\docs\HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md`
|
||||
- `C:\HyperTwist\docs\HYPERTWIST_REPO_EVALUATION_RESET_AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md`
|
||||
- `C:\HyperTwist\docs\HYPERTWIST_PHASE_1R_RETAINED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md`
|
||||
- `C:\HyperTwist\docs\HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md`
|
||||
- `C:\HyperTwist\docs\HYPERTWIST_LIVE_LANES_SOURCE_AND_PRESERVATION_AUDIT_2026-05-13.md`
|
||||
- `C:\HyperTwist\docs\HYPERTWIST_PHASE_2R_PACKET_2R_A_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md`
|
||||
- `C:\HyperTwist\docs\HYPERTWIST_PHASE_2R_PACKET_2R_B_OWNERSHIP_AND_ACCEPTANCE_CONTRACT_2026-05-13.md`
|
||||
|
|
@ -70,6 +71,7 @@ Purpose:
|
|||
## Operational rule
|
||||
|
||||
- if a file exists only because `Model A` inspected a restrictive repo, `Model B` must not read it unless it was explicitly scrubbed into `clean-room-specs`
|
||||
- the `HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md` file is allowed because it is process doctrine only; it does not enlarge `Model B` source access beyond the scrubbed handoffs
|
||||
- benchmark oracles remain source-forbidden to `Model B`
|
||||
- this rule still applies when the upstream repo says `all rights reserved`, has no explicit license, or contains contradictory license notices; those repos may still inform `Model A`, but never become direct `Model B` source input
|
||||
- if a repo mixes permissive and restricted trees, default to forbidding the whole mirrored repo to `Model B` unless a narrower allowlist has been explicitly created in writing
|
||||
|
|
|
|||
|
|
@ -70,6 +70,17 @@ For any HyperTwist repo, the coding model must determine:
|
|||
- whether it should be treated as foundation, strategic donor, reserve, or comparator
|
||||
- whether additional org/index harvesting is still worthwhile
|
||||
|
||||
## Model A extraction doctrine
|
||||
|
||||
For future `Model A` source-reading work:
|
||||
- maximize retained value inside the approved lane
|
||||
- treat `do not promote`, `do not preserve literally`, and similar wording as boundary protection, not as a shallow-extraction rule
|
||||
- exclude only inferior duplicate value, off-topic value, host-shell glue, commodity scaffolding, literal carryover, or ownership-displacing value
|
||||
- if an existing handoff undercaptures retained value, strengthen the handoff rather than pushing ambiguity into later clean-room implementation
|
||||
|
||||
Canonical doctrine doc:
|
||||
- `C:\HyperTwist\docs\HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md`
|
||||
|
||||
## Current implementation truth
|
||||
|
||||
For HyperTwist, keep this explicit:
|
||||
|
|
|
|||
|
|
@ -30,6 +30,16 @@ Current truth:
|
|||
- `Phase 3R-F` is now closed as the landed `mrdoob/three.js`, `pmndrs/react-three-fiber`, and `pmndrs/xr` widening packet
|
||||
- `Phase 4R-A` is now closed as the landed `cubing/cubing.js` classic-cubing adapter widening packet
|
||||
|
||||
## Model A interpretation rule
|
||||
|
||||
For boundary-sensitive and restrictive rows:
|
||||
- future `Model A` work should still pursue full bounded realization of the retained domain
|
||||
- `do not promote` and similar wording in the `0R` packets is a boundary filter, not a cap on later source-value extraction depth
|
||||
- if a retained handoff is too thin, strengthen the packet or scrubbed handoff while preserving the no-copy guardrails
|
||||
|
||||
Canonical doctrine doc:
|
||||
- `C:\HyperTwist\docs\HYPERTWIST_MODEL_A_MAX_VALUE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md`
|
||||
|
||||
Next sequence:
|
||||
|
||||
1. preserve the fifteen landed lanes
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue