From 06150912e7f817ea558dfc29a3f8cf47029969f4 Mon Sep 17 00:00:00 2001 From: axiomlogicnexus Date: Thu, 14 May 2026 20:22:18 +0200 Subject: [PATCH] Separate donor strength from integration route --- ...NICAL_RESTART_RECONCILIATION_2026-05-12.md | 4 + ...UE_EXTRACTION_MODUS_OPERANDI_2026-05-13.md | 3 + ...MODEL_B_COORDINATOR_DOCTRINE_2026-05-14.md | 24 ++- ...SE_0R_PACKET_0R_C_EVALUATION_2026-05-12.md | 7 + ...SE_0R_PACKET_0R_D_EVALUATION_2026-05-13.md | 8 + ...NED_SET_CONTRACT_AND_HANDOFF_2026-05-13.md | 4 + ...OM_PROMPT_AND_HANDOFF_PACKET_2026-05-14.md | 7 + ..._AND_IMPLEMENTATION_SCHEDULE_2026-05-11.md | 9 ++ ...ION_AND_PRODUCT_FIT_DOCTRINE_2026-05-14.md | 139 ++++++++++++++++++ .../HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md | 8 + docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md | 2 + docs/REPO_LICENSE_TRACKING.md | 27 +++- .../HyperTwist/DEVELOPMENT.md | 6 + .../HyperTwist/LICENSETRACKING.md | 10 +- .../HyperTwist/ROADMAP.md | 6 + 15 files changed, 257 insertions(+), 7 deletions(-) diff --git a/docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md b/docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md index 0281014..df1456b 100644 --- a/docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md +++ b/docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md @@ -123,6 +123,10 @@ Canonical doctrine docs: Operational implication: - do not let bookmark presence, queue position, frequent mention, planning artifacts, or docs metadata masquerade as product intent or proof of implementation +- donor strength and legal posture are separate axes +- permissive status does not automatically win a lane +- restrictive or boundary-sensitive status does not automatically lose a lane +- harder route does not mean weaker donor - 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 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 c319f4d..f5d25de 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 @@ -82,6 +82,9 @@ That means: - 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 +- restrictive, copyleft, mixed-license, or boundary-sensitive status does not automatically demote a repo beneath a permissive alternative +- if a retained restrictive or boundary-sensitive row is the stronger owner inside its approved lane, `Model A` should say that directly +- clean-room or boundary-first handling changes the route, not the donor-strength verdict The canonical anti-conflation doctrine now also lives in: 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 index c80e643..fdc2a97 100644 --- 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 @@ -76,7 +76,23 @@ A retained repo may still be: - later-horizon only - outside current implementation scope -### 5. Implementation requires explicit authority +### 5. Ownership and route are separate judgments + +Coordinator rule: + +- donor strength and legal posture are separate axes +- technical ownership is not decided by permissive status alone +- a restrictive, mixed-license, or boundary-sensitive repo may still be the stronger owner for a lane +- if it wins technically, preserve that ownership verdict and then choose the correct route + +Decide in this order: + +1. technical and product-fit ownership +2. legal and compliance route + +Harder route does not mean weaker donor. + +### 6. 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. @@ -84,7 +100,7 @@ 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 +### 7. Live-surface scanning is exception-based Routine live or product-surface scanning is no longer the default evaluation step. @@ -117,6 +133,9 @@ Coordinator rule: - `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` +- if a restrictive or boundary-sensitive repo wins technically, preserve that + owner verdict in the `Model A` handoff and use `Model B` only as the clean + route, not as a technical demotion ## Current Phase 5R clarification @@ -135,6 +154,7 @@ The coordinating HyperTwist instance must preserve the right to say: - worth reading, not worth retaining - retained, but not active build scope - product-fit, but later-horizon only +- technically strongest, but route-constrained - implementation-authorized, but not yet implemented If the coordinator cannot say those things cleanly, the authority docs have 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 49775ba..5922788 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 @@ -66,6 +66,13 @@ Evaluation-state rule: - implementation-authorized = separate later judgment - implemented = explicit landed first-party work only +Ownership-versus-route rule: + +- boundary-sensitive, mixed-term, or subtree-constrained status does not automatically demote a repo beneath a permissive alternative +- decide technical and product-fit ownership first +- decide adapter, sidecar, allowlist, publication, subtree, or other boundary route second +- harder route does not mean weaker donor + 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) 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 28900ba..29f55e7 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 @@ -74,6 +74,14 @@ Future instances must keep the state vocabulary separate: - implementation-authorized = explicit approval for a bounded clean-room build lane - implemented = landed in first-party product surfaces under explicit implementation authority +Ownership-versus-route rule: + +- restrictive status does not automatically demote a repo beneath a permissive or boundary-sensitive alternative +- decide technical and product-fit ownership first +- decide clean-room and compliance routing second +- if a restrictive row wins technically, preserve that win and then route it through the correct clean-room discipline +- harder route does not mean weaker donor + For these restrictive rows, clean-room prompt packs, handoff files, or queue position are routing evidence only. They are not proof of current implementation. 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 a3a424c..0c83584 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 @@ -142,6 +142,10 @@ 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. +- donor strength and legal posture are separate axes. +- a restrictive or boundary-sensitive row may still be the stronger technical owner for its bounded lane. +- if such a row wins technically, preserve that owner verdict and then route it through clean-room, sidecar, adapter, allowlist, or other required boundary discipline. +- easier route never decides the ownership comparison by itself. - 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_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 554a45a..fa8e3dd 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 @@ -69,6 +69,7 @@ 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 +- clean-room routing is the required route discipline, not a statement that these lanes are technically weaker than permissive alternatives This packet does not mean: @@ -76,6 +77,12 @@ This packet does not mean: - those rows outrank stronger owners outside their approved lanes - those rows became product truth merely by being listed here +If one of these rows is the strongest owner inside its bounded lane, the correct result is: + +- preserve that owner verdict +- keep raw restrictive source away from clean `Model B` +- route realization through the clean-room stack + 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) 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 ac58969..e220d55 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 @@ -50,6 +50,9 @@ Strong rule: - 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 +- donor strength and legal posture are separate axes +- permissive status does not automatically win a lane +- restrictive or boundary-sensitive status does not automatically lose a lane Schedule implication: @@ -57,11 +60,17 @@ Schedule implication: - 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 +- decide technical ownership first and integration route second +- do not let route convenience answer an ownership comparison by itself Future serious repo evaluations should now explicitly try to state: - exact source basis read - licensing posture +- technical donor-strength verdict +- ownership verdict +- explicit displacement or non-displacement rationale +- integration-route verdict - preserved subsystem ideas - subordinate or later value - explicit product-fit verdict 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 index 798757a..b7370e9 100644 --- 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 @@ -56,6 +56,9 @@ Future HyperTwist instances must not collapse the following into one vague - legally usable != strategically correct - feature-rich != product-relevant - technically elegant != worth integrating +- permissive != stronger donor +- restrictive != weaker donor +- harder route != weaker donor These distinctions are mandatory. @@ -192,12 +195,58 @@ Implementation authorization must be explicit. Planning artifacts alone are not authorization. +## Donor strength and legal posture are separate axes + +HyperTwist must explicitly separate: + +1. technical and product-fit ownership judgment +2. legal, compliance, and integration-route judgment + +These are different axes. + +A restrictive, copyleft, mixed-license, or boundary-sensitive repo can still +be: + +- the technically stronger donor +- the better product fit +- the rightful owner of a bounded subsystem lane +- the repo that should displace a permissive alternative on technical grounds + +Permissive status does not automatically win the ownership comparison. + +Restrictive status does not automatically lose it. + +What legal posture changes is the allowed route, for example: + +- direct permissive incorporation +- bounded adapter +- sidecar or service boundary +- protocol boundary +- clean-room handoff +- reference-only +- pattern-only +- donor-only for later +- no integration despite technical strength + +HyperTwist therefore evaluates overlapping repos in two passes: + +1. decide which repo is stronger on technical, product-fit, and ownership grounds +2. decide what route the winner may use given license posture and compliance constraints + +Harder route does not mean weaker donor. + +It means harder route. + ## Required evaluation output standard Every serious repo evaluation should now try to state all of the following: - exact source basis read - licensing posture +- technical donor-strength verdict +- ownership verdict +- explicit displacement or non-displacement rationale +- integration-route verdict - preserved subsystem ideas - subordinate or later value - explicit product-fit verdict @@ -283,6 +332,40 @@ If it still has residual value in a narrower lane, preserve that value there. If it has no durable lane, say so. +## Ownership-versus-route examples + +Example A: + +- a permissive repo is easier to incorporate +- a restrictive repo is clearly stronger in the bounded subsystem + +Correct result: + +- the restrictive repo may still win ownership +- the implementation route becomes boundary-first, clean-room, sidecar, or another constrained path as required + +Example B: + +- a restrictive repo is impressive +- a permissive repo is still the stronger product fit and better owner + +Correct result: + +- the permissive repo wins +- the restrictive repo may remain reference-only, donor-only for later, or subordinate +- the restrictive repo does not lose merely because it is restrictive; it loses because it is the weaker owner here + +Example C: + +- a restrictive repo wins a narrow lane +- a broader permissive repo remains the stronger owner in a neighboring lane + +Correct result: + +- preserve the restrictive repo as the narrow owner where it is strongest +- preserve the permissive repo as the broader owner where it is stronger +- do not let route difficulty distort lane boundaries + ## Failure cases to prevent This doctrine exists to block the following failure modes: @@ -312,6 +395,32 @@ if the full product should be integrated. A repo is discussed often enough that later instances casually describe it as if it already exists in product surfaces. +### 6. Permissive bias + +A later instance assumes that a permissive repo should win by default over a +restrictive or boundary-sensitive repo. + +### 7. Restrictive demotion by reflex + +A later instance sees GPL, AGPL, mixed-license, enterprise-sliced, custom, or +boundary-sensitive posture and casually downgrades the repo's technical +ownership claim without comparing subsystem value. + +### 8. Ownership-route collapse + +A later instance uses legal posture to answer a technical ownership question. + +### 9. Route-to-rank confusion + +A later instance assumes that because a repo must route through clean-room, +sidecar, allowlist, or subtree-boundary handling, it therefore cannot be the +strongest donor. + +### 10. Overcorrection + +A later instance swings too far in the other direction and starts treating +restrictive repos as automatically superior or specially authoritative. + All of these are doctrine failures. ## Operational vocabulary @@ -338,6 +447,26 @@ The repo survived evaluation as having some meaningful preserved value. The retained value actually belongs in HyperTwist’s real product direction. +### Technical owner + +The repo that best owns a lane on architecture, subsystem quality, and +product-fit grounds. + +### Ownership verdict + +The explicit judgment about who should own the lane on technical and +product-fit grounds. + +### Integration route + +The allowed path for using or realizing retained value given license posture, +custody, compliance, and boundary constraints. + +### Route verdict + +The explicit judgment about how the winning value may enter the product, if at +all. + ### Implementation-authorized A bounded implementation lane has been explicitly approved. @@ -360,6 +489,16 @@ lane. Potentially useful later, but not active implementation scope now. +### Permissive route + +A lower-friction incorporation path available when the repo posture allows it. + +### Restrictive route + +A constrained path such as clean-room, sidecar, protocol boundary, +reference-only use, pattern-only use, donor-only deferral, or explicit +non-integration. + ### Not worth integrating No later bounded implementation should be assumed from the current evaluation. diff --git a/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md b/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md index d87a8e5..263021c 100644 --- a/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md +++ b/docs/HYPERTWIST_REPO_STATE_BOARD_2026-05-11.md @@ -147,6 +147,12 @@ This board is not proof of bookmark merit by itself. This board is not proof of implementation by itself. +Legal posture does not decide technical ownership by itself. + +A restrictive or boundary-sensitive row can still be the stronger owner for a lane. + +Harder route does not mean weaker donor. + Use explicit `Current live state`, landed packet authority, and the live-lane audit when implementation truth matters. @@ -169,6 +175,8 @@ audit when implementation truth matters. - `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. +- license posture does not prove that a row is stronger or weaker than an overlapping alternative. +- route difficulty does not answer ownership by itself. - 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 2b3ccff..6fcd09e 100644 --- a/docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md +++ b/docs/MODEL_B_SOURCE_ACCESS_BOUNDARY.md @@ -79,6 +79,8 @@ Purpose: - 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 - for the imported generated-mode executor packet, `Model B` should implement from owned `HyperTwistTraining` runtime/request contracts rather than from donor-facing raw extract files or bundled intake JSON unless those assets were separately scrubbed and allowlisted +- this boundary file governs route, not donor rank; a restrictive or boundary-sensitive row may still be the strongest owner for its lane +- clean-room, subtree-exclusion, or sidecar routing does not imply technical weakness; it only constrains how `Model B` may realize the winning value ## Current topology default diff --git a/docs/REPO_LICENSE_TRACKING.md b/docs/REPO_LICENSE_TRACKING.md index 401a9d2..3964de2 100644 --- a/docs/REPO_LICENSE_TRACKING.md +++ b/docs/REPO_LICENSE_TRACKING.md @@ -48,14 +48,32 @@ Use it for: Do not use it as the primary architecture ledger. The architecture and donor decisions remain in the GPT parse files. +## 2026-05-14 donor-strength versus route doctrine + +This file records legal posture, compliance burden, and route constraints. + +It does not decide technical ownership by permissive status alone. + +Rule: + +- donor strength and legal posture are separate axes +- a restrictive, copyleft, mixed-license, or boundary-sensitive repo can still be the stronger owner for a lane +- if it wins technically, the route may still be clean-room, sidecar, protocol boundary, reference-only, pattern-only, donor-only for later, or explicit non-integration +- harder route does not mean weaker donor +- easier route does not mean better owner + +Use packet and retained-set docs for ownership verdicts. + +Use this file for legal posture and route constraints after the ownership comparison is made. + ## 2026-05-13 current HyperTwist implementation truth This file now also preserves the current truth that future models must not lose: - current curated HyperTwist shallow-eval set: `71` repos -- currently verified live/implemented in checked `UnrealHyperTwist` surfaces: `19` +- currently verified live/implemented in checked `UnrealHyperTwist` surfaces: `20` - permissive live lanes: `13` -- boundary-sensitive live lanes: `5` +- boundary-sensitive live lanes: `6` - restrictive live lanes: `1` The thirteen permissive live lanes are: @@ -74,13 +92,14 @@ The thirteen permissive live lanes are: - `poliva/cubedex` - `newyork-anthonyng/rubiks-cross-trainer` -The five boundary-sensitive live lanes are: +The six boundary-sensitive live lanes are: - `cubing/cubing.js` - `cutelyaware/magiccube4d` - `google/model-viewer/packages/shared-assets` - `PostHog/posthog` - `screenpipe/screenpipe` +- `remotion-dev/remotion` The one restrictive live lane is: @@ -99,7 +118,7 @@ Interpretation rule: Reset rule: -- preserve the nineteen landed/live lanes +- preserve the twenty landed/live lanes - do not treat the remaining non-live rows as already absorbed - route all non-live rows only through the closed `Phase 1R` retained-set contract and the relevant `0R-*` packet diff --git a/docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md b/docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md index bc6d881..f01a0cc 100644 --- a/docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md +++ b/docs/v6_5_deep_manual_pack/HyperTwist/DEVELOPMENT.md @@ -26,6 +26,12 @@ State-separation rule: Do not let bookmark presence, queue position, or frequent mention masquerade as product intent or proof of implementation. +Donor-strength rule: + +- donor strength and legal posture are separate axes +- a restrictive or boundary-sensitive repo can still be the strongest owner for a lane +- route difficulty changes how retained value may enter the product, not whether it may win technically + Current truth: - `20` repos are currently verified live in checked Unreal surfaces diff --git a/docs/v6_5_deep_manual_pack/HyperTwist/LICENSETRACKING.md b/docs/v6_5_deep_manual_pack/HyperTwist/LICENSETRACKING.md index 606a8dc..80a0f5c 100644 --- a/docs/v6_5_deep_manual_pack/HyperTwist/LICENSETRACKING.md +++ b/docs/v6_5_deep_manual_pack/HyperTwist/LICENSETRACKING.md @@ -8,6 +8,14 @@ Every repo should be judged as: - reverse engineer - pattern-only +Ownership and route are separate judgments: + +- donor strength and legal posture are separate axes +- a restrictive, mixed-license, or boundary-sensitive repo may still be the stronger technical owner for a lane +- permissive status does not automatically win a lane +- restrictive status does not automatically lose a lane +- the route categories above answer how a winning repo may be used, not whether it was the stronger donor + ## File boundary This file is the project-level license policy file. @@ -176,7 +184,7 @@ These are often strategic donors or comparators rather than foundations. Current HyperTwist correction: - thirteen permissive lanes are already live, including the landed analytics/reporting lane, the landed hypercubing knowledge and community-reference lane, and the landed browser spatial owner trio -- four boundary-sensitive lanes are already live: `cubing/cubing.js` through an explicit `MPL`-aware adapter posture, `cutelyaware/magiccube4d` through an explicit attribution/provenance boundary, `google/model-viewer/packages/shared-assets` through an explicit allowlist/provenance boundary, and `PostHog/posthog` through an explicit root-`MIT`-core-versus-`ee/` subtree boundary +- six boundary-sensitive lanes are already live: `cubing/cubing.js` through an explicit `MPL`-aware adapter posture, `cutelyaware/magiccube4d` through an explicit attribution/provenance boundary, `google/model-viewer/packages/shared-assets` through an explicit allowlist/provenance boundary, `PostHog/posthog` through an explicit root-`MIT`-core-versus-`ee/` subtree boundary, `screenpipe/screenpipe` through an explicit permissive-core-versus-`ee/` subtree boundary, and `remotion-dev/remotion` through an explicit package-split commercial boundary - `onionhoney/roux-trainers` is the one restrictive training lane already landed through clean-room implementation - timer comparators such as `cstimer` still remain benchmark/reference rows until deep evaluation says otherwise diff --git a/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md b/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md index aa401dd..caca302 100644 --- a/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md +++ b/docs/v6_5_deep_manual_pack/HyperTwist/ROADMAP.md @@ -17,6 +17,12 @@ State-separation rule: Do not let bookmark presence, queue position, planning artifacts, or docs metadata masquerade as product intent or proof of implementation. +Donor-strength rule: + +- donor strength and legal posture are separate axes +- a restrictive or boundary-sensitive repo can still be the strongest owner for a lane +- route difficulty changes how retained value may enter the product, not whether it may win technically + - current shallow-eval set: `71` repos - currently verified live/implemented in checked Unreal surfaces: `20` - permissive live lanes: `13`