# HyperTwist Phase 0R Packet 0R-C Deep Source Evaluation

Created on `2026-05-12`

## Status

`Packet 0R-C` is now `closed` as a `Phase 0R` evaluation packet.

This packet applies the same deep-source standard already established by `0R-A` and `0R-B`:

- read the upstream source directly
- salvage all meaningful value
- omit only when the surface is:
  - an inferior duplicate
  - superseded by a stronger retained donor
  - off topic to HyperTwist's retained product scope
  - host-shell glue with no durable architecture value
- record the rationale every time something is not promoted

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
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

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)

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:

- `cubing/cubing.js`
- `cutelyaware/magiccube4d`
- `google/model-viewer/packages/shared-assets`
- `PostHog/posthog`
- `remotion-dev/remotion`
- `screenpipe/screenpipe`

It answers, repo by repo:

- what was actually read in source
- what value HyperTwist should salvage
- what is subordinate, duplicate, inferior, or off topic
- why that non-promotion decision was made
- which repo should own a domain when multiple boundary-sensitive rows overlap
- how the repo should enter `Phase 2R`, `Phase 4R`, or later implementation work

## Storage boundary

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
- [HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md](C:/HyperTwist/docs/HYPERTWIST_CANONICAL_RESTART_RECONCILIATION_2026-05-12.md:1): cross-location authority routing

This packet must carry a concise per-repo licensing snapshot so an implementation-facing instance sees the legal posture at handoff time.
Where a repo's integration posture depends directly on licensing, restate that posture inline in the repo section as well.
Full legal obligations still belong only in [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:1).
Deep source-value extraction does not belong in the license tracker.

## Packet licensing snapshot

- `cubing/cubing.js`: `MPL-2.0 OR GPL-3.0-or-later`
- `cutelyaware/magiccube4d`: custom broad-use license with attribution-preservation expectations
- `google/model-viewer/packages/shared-assets`: `Apache-2.0` package container with mixed per-asset terms
- `PostHog/posthog`: `MIT` outside `ee/`; enterprise-restricted `ee/` subtree excluded
- `remotion-dev/remotion`: custom two-tier commercial license; package-level strings are mixed and do not flatten the row into `MIT`
- `screenpipe/screenpipe`: `MIT OR Apache-2.0` core with restrictive `ee/` subtree excluded

## Inputs used

This rewrite used:

- current reset docs in `C:\HyperTwist\docs`
- current mirrors under:
  - `C:\Workspaces\HyperTwist\mirrors\permissive\cubing\cubing.js`
  - `C:\Workspaces\HyperTwist\mirrors\permissive\cutelyaware\magiccube4d`
  - `C:\Workspaces\HyperTwist\mirrors\permissive\google\model-viewer`
  - `C:\Workspaces\HyperTwist\mirrors\restrictive\PostHog\posthog`
  - `C:\Workspaces\HyperTwist\mirrors\restrictive\remotion-dev\remotion`
  - `C:\Workspaces\HyperTwist\mirrors\restrictive\screenpipe\screenpipe`
- checked live Unreal surfaces under:
  - `C:\HyperTwist\UnrealHyperTwist\Source`
  - `C:\HyperTwist\UnrealHyperTwist\Content\HyperTwistTraining\MaterializedCatalog`

## Mirror topology caveats

Some `0R-C` rows are package or mixed-license rows inside broader upstream trees.

That must stay visible:

- `google/model-viewer/packages/shared-assets` was inspected inside the `google/model-viewer` monorepo, not as a separate top-level repo
- `PostHog/posthog`, `screenpipe/screenpipe`, and `remotion-dev/remotion` are not plain permissive mirrors in practice even where parts of their trees are usable
- `cutelyaware/magiccube4d` has both a workspace mirror and a local zip archive, but the mirror is the canonical source surface for integration-facing reading

Future instances must not mistake package rows for missing source, and must not mistake mixed-license monorepos for carefree donor trees.

## Live-state result

Current live-evidence check result for all six `0R-C` repos:

- no exact live-surface match found in checked Unreal source or materialized catalog

That means:

- none of these six are currently proven live in checked Unreal surfaces
- all six remain retained candidates, not landed implementation lanes

## Packet-wide hierarchy

This packet does not treat all six repos as equal.

| Domain | Primary retained owner | Secondary retained owner | Non-promotion rule |
| --- | --- | --- | --- |
| Classic-cubing semantics, notation, puzzle geometry, and browser player/runtime support | `cubing/cubing.js` | none in `0R-C` | Do not let this row displace `HactarCE/Hyperspeedcube` as the hyper runtime foundation. Keep it as the classic-cubing semantic/runtime lane. |
| Legacy `4D` interaction grammar, history, macros, and generic puzzle-description semantics | `cutelyaware/magiccube4d` | none in `0R-C` | Do not let the Java Swing shell displace `Hyperspeedcube`; mine it for interaction grammar, history, macro, and generic hyper-puzzle semantics. |
| Sample-model and environment fixture pack | `google/model-viewer/packages/shared-assets` | none in `0R-C` | Treat it as a fixture and QA lane only, never as a blanket shippable asset source. |
| Telemetry, replay diagnostics, and feature-governance patterns | `PostHog/posthog` | none in `0R-C` | Keep it as a bounded control-plane donor; do not let it become a product shell, gameplay core, or vision donor. |
| Local capture, timeline, retention, vault, and deterministic agent-permission surfaces | `screenpipe/screenpipe` | `PostHog/posthog` | `screenpipe` owns local capture/history and pipe-permission architecture. `PostHog` stays subordinate there and instead owns feature-governance and replay-diagnostic patterns. |
| Programmatic media export and replay-explainer rendering | `remotion-dev/remotion` | none in `0R-C` | Keep it as a commercially sensitive presentation sidecar. Do not treat it as core runtime architecture. |

## Packet outcome summary

- retained: `6`
- discarded: `0`
- newly proven live: `0`

Most important scheduling consequences:

- the boundary-sensitive backlog is now closed at the deep-source standard
- `cubing/cubing.js` remains retained, but only through MPL-aware dependency or adapter seams
- `cutelyaware/magiccube4d` remains retained as an attributed strategic donor beneath the `Hyperspeedcube` anchor
- `google/model-viewer/packages/shared-assets` remains retained only as a local fixture and QA pack
- `PostHog/posthog`, `screenpipe/screenpipe`, and `remotion-dev/remotion` remain retained only as bounded sidecar, allowlist, or reference lanes rather than as broad donor shells
- the next clean packet is `0R-D`

## Repo evaluations

### `cubing/cubing.js`

Inspected source surfaces:

- [package.json](C:/Workspaces/HyperTwist/mirrors/permissive/cubing/cubing.js/package.json:1)
- [README.md](C:/Workspaces/HyperTwist/mirrors/permissive/cubing/cubing.js/README.md:1)
- [src/cubing/kpuzzle/index.ts](C:/Workspaces/HyperTwist/mirrors/permissive/cubing/cubing.js/src/cubing/kpuzzle/index.ts:1)
- [src/cubing/puzzle-geometry/index.ts](C:/Workspaces/HyperTwist/mirrors/permissive/cubing/cubing.js/src/cubing/puzzle-geometry/index.ts:1)
- [src/cubing/twisty/index.ts](C:/Workspaces/HyperTwist/mirrors/permissive/cubing/cubing.js/src/cubing/twisty/index.ts:1)
- [src/cubing/puzzles/implementations/melindas2x2x2x2/index.ts](C:/Workspaces/HyperTwist/mirrors/permissive/cubing/cubing.js/src/cubing/puzzles/implementations/melindas2x2x2x2/index.ts:1)
- [src/cubing/protocol/index.ts](C:/Workspaces/HyperTwist/mirrors/permissive/cubing/cubing.js/src/cubing/protocol/index.ts:1)
- [src/cubing/stream/index.ts](C:/Workspaces/HyperTwist/mirrors/permissive/cubing/cubing.js/src/cubing/stream/index.ts:1)
- [src/cubing/bluetooth/index.ts](C:/Workspaces/HyperTwist/mirrors/permissive/cubing/cubing.js/src/cubing/bluetooth/index.ts:1)
- [src/cubing/search/index.ts](C:/Workspaces/HyperTwist/mirrors/permissive/cubing/cubing.js/src/cubing/search/index.ts:1)

Licensing posture:

- `MPL-2.0 OR GPL-3.0-or-later`
- retain only through an `MPL`-aware dependency, adapter, or companion-library seam
- do not flatten this row into a generic permissive donor or a deep private fork

High-value salvage:

- `KPuzzle`, `KPattern`, and `KTransformation` are the strongest retained classic-cubing state and transform seam in the current set
- the puzzle-geometry layer exposes generalized puzzle-description parsing, named-puzzle resolution, notation mapping, and geometry-backed puzzle construction
- the `twisty` layer contributes a mature browser-side viewer/player taxonomy: player, viewer, editor, indexers, and view props
- the package already includes a `melindas2x2x2x2` loader, which is strategically important because it shows a real bridge between the classic-cubing library and HyperTwist-adjacent puzzle families
- the protocol and bluetooth layers contribute smartcube, smart-timer, smart-robot, and binary interchange thinking that HyperTwist can reuse in bounded companion surfaces
- the search layer contributes classic solve and random-state helpers that remain useful reference seams even when they are not the main hyper runtime owner

Subordinate or later value:

- the `stream` package explicitly self-identifies as older code likely to be overhauled, so it is not a stable foundation owner
- Twizzle sites, experiments, docs generation, and deployment tooling are useful reference surfaces but not the main donor value
- build scripts, vendor trees, and docs/demo shells are secondary compared with `kpuzzle`, puzzle geometry, `twisty`, and protocol seams

Non-promotion decisions and rationale:

- do not deep-fork it into a private proprietary core: `implementation detail better reauthored first-party` and `boundary cost` because source-file modifications create publication obligations on the `cubing.js` source itself
- do not let `cubing.js` replace `Hyperspeedcube` as the hyper runtime owner: `superseded by stronger retained donor` for higher-dimensional runtime architecture
- do not promote Twizzle docs/demo shell as a product-shell donor: `host-shell glue`
- do not promote the older `stream` package as a major architecture owner: `inferior duplicate` relative to cleaner modern seams elsewhere in the repo

Integration call:

- retain as the primary classic-cubing semantic/runtime donor in the retained set
- use it in `Phase 2R` to freeze `KPuzzle`, notation, puzzle-geometry, viewer/player, and smart-device contracts for non-hyper cubing lanes
- schedule implementation in `Phase 4R` through MPL-side dependency, adapter, or companion-library consumption rather than a deep private fork

### `cutelyaware/magiccube4d`

Inspected source surfaces:

- [README.md](C:/Workspaces/HyperTwist/mirrors/permissive/cutelyaware/magiccube4d/README.md:1)
- [LICENSE.md](C:/Workspaces/HyperTwist/mirrors/permissive/cutelyaware/magiccube4d/LICENSE.md:1)
- [src/com/superliminal/magiccube4d/History.java](C:/Workspaces/HyperTwist/mirrors/permissive/cutelyaware/magiccube4d/src/com/superliminal/magiccube4d/History.java:1)
- [src/com/superliminal/magiccube4d/Macro.java](C:/Workspaces/HyperTwist/mirrors/permissive/cutelyaware/magiccube4d/src/com/superliminal/magiccube4d/Macro.java:1)
- [src/com/superliminal/magiccube4d/PolytopePuzzleDescription.java](C:/Workspaces/HyperTwist/mirrors/permissive/cutelyaware/magiccube4d/src/com/superliminal/magiccube4d/PolytopePuzzleDescription.java:1)
- [src/com/superliminal/magiccube4d/RotationHandler.java](C:/Workspaces/HyperTwist/mirrors/permissive/cutelyaware/magiccube4d/src/com/superliminal/magiccube4d/RotationHandler.java:1)
- [src/com/superliminal/magiccube4d/MC4DView.java](C:/Workspaces/HyperTwist/mirrors/permissive/cutelyaware/magiccube4d/src/com/superliminal/magiccube4d/MC4DView.java:1)
- [src/com/donhatchsw/util/MyMath.java](C:/Workspaces/HyperTwist/mirrors/permissive/cutelyaware/magiccube4d/src/com/donhatchsw/util/MyMath.java:1)

Licensing posture:

- custom broad-use upstream license rather than a standard `MIT` or `Apache-2.0` grant
- preserve the attribution and notice posture already tracked in [REPO_LICENSE_TRACKING.md](C:/HyperTwist/docs/REPO_LICENSE_TRACKING.md:101)
- retain as an attributed strategic donor, not as a casual drop-in dependency

High-value salvage:

- `History` is a strong retained donor for move logs with marks, macro boundaries, undo/redo traversal, and save/restore semantics
- `Macro` is major value, not a footnote: relative macro application against reference grips, transform remapping, and reversal logic are exactly the kind of higher-dimensional training behavior HyperTwist needs
- `PolytopePuzzleDescription` contains the strongest retained legacy evidence for generic polytope slicing, grip/sticker/face relationships, and generalized puzzle-description plumbing
- `RotationHandler` contributes concrete `4D` rotation-state, snap-to-center semantics, spin continuation, and drag grammar
- `MC4DView` contributes animation-queue behavior, sticker picking/highlighting, slice-mask handling, and viewer/controller composition
- the repo as a whole preserves a mature legacy hypercubing interaction grammar that still matters even if the Java shell itself is not the final foundation

Subordinate or later value:

- applet, launcher, Swing shell, preference plumbing, and audio/resource packaging are mostly host-shell value, not primary donor value
- utility math helpers are useful only selectively; they do not own a modern first-party math stack by default
- long in-file TODO and issue logs are useful historical context, but not architectural goals to inherit wholesale

Non-promotion decisions and rationale:

- do not transplant the Swing/applet product shell: `host-shell glue / legacy packaging`
- do not let this repo replace `Hyperspeedcube` as the main runtime owner: `superseded by stronger retained donor`
- do not promote `MyMath.java` wholesale into first-party utility code without provenance discipline: `implementation detail better reauthored first-party`
- do not treat every generic-puzzle comment or TODO as a current product requirement: `off topic` to the actually proven retained value

Integration call:

- retain as an attributed strategic donor beneath the `Hyperspeedcube` runtime anchor
- use it in `Phase 2R` to freeze history, macro, generic puzzle-description, and `4D` interaction contracts
- schedule bounded extraction in `Phase 6R`, not as an early standalone shell and not as a replacement for the `Hyperspeedcube`-owned runtime spine

### `google/model-viewer/packages/shared-assets`

Inspected source surfaces:

- [README.md](C:/Workspaces/HyperTwist/mirrors/permissive/google/model-viewer/packages/shared-assets/README.md:1)
- [ATTRIBUTIONS.md](C:/Workspaces/HyperTwist/mirrors/permissive/google/model-viewer/packages/shared-assets/ATTRIBUTIONS.md:1)
- [scripts/fetch-khronos-gltf-samples.sh](C:/Workspaces/HyperTwist/mirrors/permissive/google/model-viewer/packages/shared-assets/scripts/fetch-khronos-gltf-samples.sh:1)

Licensing posture:

- the package lives inside an `Apache-2.0` monorepo, but the retained asset pack is governed by mixed per-asset terms
- every retained asset use still needs allowlist review against `ATTRIBUTIONS.md`
- treat this row as fixtures and QA material first, not as a blanket shippable asset source

High-value salvage:

- the package is a useful local fixture library for viewer tests, environment-lighting checks, sample-model coverage, and docs/demo payloads
- `ATTRIBUTIONS.md` is strong retained value in its own right because it documents asset provenance explicitly rather than pretending the package container license resolves everything
- the fetch script is useful as a pattern for reproducible sample-fixture refresh against upstream glTF sample sources
- this package can materially shorten HyperTwist QA and browser-viewer smoke-test setup if handled as fixtures instead of donor product assets

Subordinate or later value:

- the assets are support material, not code architecture
- the package is subordinate to the broader `google/model-viewer` lane and to any first-party asset program HyperTwist later adopts
- fixture organization is useful; broad asset adoption is not

Non-promotion decisions and rationale:

- do not treat it as a normal code donor: `off topic`
- do not treat it as a blanket shippable asset bundle: `boundary cost exceeds naive use`
- do not assume Apache at the package container overrides per-asset conditions such as `CC-BY-NC`, `CC-BY-NC-SA`, or Smithsonian usage terms: `implementation detail belongs in per-asset review`

Integration call:

- retain only as a local fixture, docs, and visual-QA pack beneath the `google/model-viewer` lane
- do not give it `Phase 2R` product-core contract ownership
- schedule any real use only in `Phase 4R` as a per-asset allowlist for local fixtures, demos, or specifically reviewed shippable assets

### `PostHog/posthog`

Inspected source surfaces:

- [README.md](C:/Workspaces/HyperTwist/mirrors/restrictive/PostHog/posthog/README.md:1)
- [LICENSE](C:/Workspaces/HyperTwist/mirrors/restrictive/PostHog/posthog/LICENSE:1)
- [products/replay/manifest.tsx](C:/Workspaces/HyperTwist/mirrors/restrictive/PostHog/posthog/products/replay/manifest.tsx:1)
- [products/replay/skills/diagnosing-missing-recordings/SKILL.md](C:/Workspaces/HyperTwist/mirrors/restrictive/PostHog/posthog/products/replay/skills/diagnosing-missing-recordings/SKILL.md:1)
- [products/feature_flags/mcp/tools.yaml](C:/Workspaces/HyperTwist/mirrors/restrictive/PostHog/posthog/products/feature_flags/mcp/tools.yaml:1)
- [posthog/models/feature_flag/feature_flag.py](C:/Workspaces/HyperTwist/mirrors/restrictive/PostHog/posthog/posthog/models/feature_flag/feature_flag.py:1)
- [posthog/models/feature_flag/user_blast_radius.py](C:/Workspaces/HyperTwist/mirrors/restrictive/PostHog/posthog/posthog/models/feature_flag/user_blast_radius.py:1)

Licensing posture:

- `MIT` core outside `ee/`
- `ee/` remains enterprise-restricted and excluded from HyperTwist donor use
- any implementation must stay on explicitly permissive paths or reauthor the behavior first-party

High-value salvage:

- the replay manifest contributes a concrete deep-link and product-manifest grammar for replay home, filtered lists, single-session offsets, file playback, kiosk mode, playlists, and settings routes
- the replay diagnostic skill is strong retained value because it encodes a structured reason-about-missing-recordings workflow, not just UI
- the feature-flag MCP tool definitions contribute a practical capability map for CRUD, dependency inspection, evaluation reasons, status, activity log, scheduled changes, and blast-radius analysis
- `feature_flag.py` is a strong donor for flag data modeling: conditions, variants, bucketing identifiers, evaluation runtime, dashboard attachment, usage metadata, and filesystem sync thinking
- `user_blast_radius.py` contributes concrete query and property-normalization discipline for rollout-impact estimation before a change is shipped
- the repo as a whole contributes product/service boundary thinking for telemetry, replay diagnostics, and feature governance, which is the actual value lane for HyperTwist

Subordinate or later value:

- the all-in-one analytics shell, data warehouse, surveys, LLM analytics, and broader SaaS product surface are not the retained center of gravity for HyperTwist
- self-hosting/deployment shell and large cloud product areas are secondary to the telemetry, replay, and governance seams above

Non-promotion decisions and rationale:

- do not treat it as a vision, perception, or cube-state donor: `off topic`
- do not inherit the broader analytics platform shell: `host-shell glue / off mission`
- do not consume `ee/` or treat the repo as a carefree whole-tree MIT donor: `boundary cost exceeds naive use`
- do not overfit HyperTwist to PostHog's full product taxonomy when the retained value is much narrower: `superseded by first-party scope discipline`

Integration call:

- retain as a mixed-license control-plane donor for telemetry, replay diagnostics, and feature-governance patterns
- use it in `Phase 2R` to freeze event-schema, replay-diagnostic, audit-log, rollout, dependency, and blast-radius contracts
- if later implementation proceeds, schedule it in `Phase 4R` only as a clearly MIT-path bounded sidecar or selective first-party reimplementation lane, with `ee/` still excluded and mixed-license source kept out of generic implementation work

### `remotion-dev/remotion`

Inspected source surfaces:

- [README.md](C:/Workspaces/HyperTwist/mirrors/restrictive/remotion-dev/remotion/README.md:1)
- [LICENSE.md](C:/Workspaces/HyperTwist/mirrors/restrictive/remotion-dev/remotion/LICENSE.md:1)
- [packages/player/package.json](C:/Workspaces/HyperTwist/mirrors/restrictive/remotion-dev/remotion/packages/player/package.json:1)
- [packages/renderer/package.json](C:/Workspaces/HyperTwist/mirrors/restrictive/remotion-dev/remotion/packages/renderer/package.json:1)
- [packages/studio/package.json](C:/Workspaces/HyperTwist/mirrors/restrictive/remotion-dev/remotion/packages/studio/package.json:1)
- [packages/media-parser/package.json](C:/Workspaces/HyperTwist/mirrors/restrictive/remotion-dev/remotion/packages/media-parser/package.json:1)
- [packages/player/src/Player.tsx](C:/Workspaces/HyperTwist/mirrors/restrictive/remotion-dev/remotion/packages/player/src/Player.tsx:1)
- [packages/renderer/src/client.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/remotion-dev/remotion/packages/renderer/src/client.ts:1)
- [packages/media-parser/src/index.ts](C:/Workspaces/HyperTwist/mirrors/restrictive/remotion-dev/remotion/packages/media-parser/src/index.ts:1)

Licensing posture:

- the checked `LICENSE.md` uses a two-tier commercial model, not a `$1M` revenue threshold
- free use in the checked mirror is limited to individuals, non-profits, evaluation use, and for-profit organizations with up to `3` employees
- `@remotion/studio` exposes `MIT`, but `@remotion/player`, `@remotion/renderer`, and `@remotion/media-parser` still point back to the broader Remotion license posture
- do not treat this row as plain `MIT` unless a future package-specific licensing decision narrows the shipped surface explicitly

High-value salvage:

- the player package contributes an embeddable timeline-aware playback surface with explicit frame, duration, dimension, control, poster, and validation contracts
- the renderer package contributes a reusable browser-safe export option grammar around codecs, CRF, pixel formats, hardware acceleration, Chrome mode, and output validation
- the media-parser package contributes a pure-JavaScript parsing surface for ISO/WebM/M3U and worker/node/web entry points that is useful for bounded media inspection
- the studio package shows a real editor/preview/render API split, even if HyperTwist should not inherit the whole authoring shell
- the repo's strongest HyperTwist value is generated coaching media, replay explainers, export workflows, and embeddable playback contracts

Subordinate or later value:

- templates, docs, create-video shell, and showcase ecosystem are not core donor value for HyperTwist
- full Remotion Studio authoring shell is secondary to the bounded export and playback seams
- broader React-video identity is valuable context, but not a reason to let it shape runtime architecture

Non-promotion decisions and rationale:

- do not treat the monorepo as a plain permissive donor just because some subpackages expose narrower package-level license strings: `boundary cost exceeds naive use`
- do not promote it into gameplay core, recognition, or main runtime ownership: `off topic`
- do not inherit the whole authoring or template shell: `host-shell glue`

Integration call:

- retain as a commercially sensitive media-export and replay-explainer sidecar/reference lane
- use it in `Phase 2R` only to freeze playback, export, and explainer contract language
- before any `Phase 4R` implementation, make an explicit license decision for the exact package set being shipped; without that decision, keep it as reference or reimplement the narrower first-party behaviors instead of lifting repo code

### `screenpipe/screenpipe`

Inspected source surfaces:

- [README.md](C:/Workspaces/HyperTwist/mirrors/restrictive/screenpipe/screenpipe/README.md:1)
- [Cargo.toml](C:/Workspaces/HyperTwist/mirrors/restrictive/screenpipe/screenpipe/Cargo.toml:1)
- [LICENSE.md](C:/Workspaces/HyperTwist/mirrors/restrictive/screenpipe/screenpipe/LICENSE.md:1)
- [ee/LICENSE](C:/Workspaces/HyperTwist/mirrors/restrictive/screenpipe/screenpipe/ee/LICENSE:1)
- [crates/screenpipe-engine/src/lib.rs](C:/Workspaces/HyperTwist/mirrors/restrictive/screenpipe/screenpipe/crates/screenpipe-engine/src/lib.rs:1)
- [crates/screenpipe-engine/src/event_driven_capture.rs](C:/Workspaces/HyperTwist/mirrors/restrictive/screenpipe/screenpipe/crates/screenpipe-engine/src/event_driven_capture.rs:1)
- [crates/screenpipe-engine/src/pipe_permissions_middleware.rs](C:/Workspaces/HyperTwist/mirrors/restrictive/screenpipe/screenpipe/crates/screenpipe-engine/src/pipe_permissions_middleware.rs:1)
- [crates/screenpipe-db/src/lib.rs](C:/Workspaces/HyperTwist/mirrors/restrictive/screenpipe/screenpipe/crates/screenpipe-db/src/lib.rs:1)
- [crates/screenpipe-db/src/write_queue.rs](C:/Workspaces/HyperTwist/mirrors/restrictive/screenpipe/screenpipe/crates/screenpipe-db/src/write_queue.rs:1)
- [crates/screenpipe-vault/src/lib.rs](C:/Workspaces/HyperTwist/mirrors/restrictive/screenpipe/screenpipe/crates/screenpipe-vault/src/lib.rs:1)
- [crates/screenpipe-vault/src/manager.rs](C:/Workspaces/HyperTwist/mirrors/restrictive/screenpipe/screenpipe/crates/screenpipe-vault/src/manager.rs:1)
- [apps/screenpipe-app-tauri/components/rewind/timeline/timeline.tsx](C:/Workspaces/HyperTwist/mirrors/restrictive/screenpipe/screenpipe/apps/screenpipe-app-tauri/components/rewind/timeline/timeline.tsx:1)

Licensing posture:

- permissive core is `MIT OR Apache-2.0`
- `ee/` remains restrictive and excluded from any relaxed donor posture
- any implementation must stay on a scrubbed permissive-core allowlist or a first-party reimplementation path

High-value salvage:

- the engine crate layout is already shaped like a support-plane platform: capture, recording config, power, retention, permissions, pipes, routes, server, video, and vision manager seams
- `event_driven_capture.rs` is strong retained value for event-triggered capture, debounce rules, typing-pause and idle logic, visual-change detection, and paired screenshot-plus-accessibility capture discipline
- `pipe_permissions_middleware.rs` contributes deterministic endpoint gating, token-scoped permissions, and backpressure thinking for agent-triggered automation
- the DB layer contributes write coalescing, batch transactions, pause/resume during sleep, and sync-table serialization discipline
- the vault layer contributes a concrete lock/unlock, migration, and encryption-state lifecycle instead of vague at-rest-encryption claims
- the timeline UI contributes multi-app, multi-domain, multi-speaker, and replay-control ideas that are actually useful for HyperTwist support-plane history tooling

Subordinate or later value:

- the full AI-memory product shell, app-branding layer, and large local-assistant product frame are not the retained HyperTwist center of gravity
- cloud search, broad AI agent ecosystem, and adjacent assistant features are secondary to capture/history/permissions/vault seams
- many UI surfaces are useful patterns but not product-shell owners

Non-promotion decisions and rationale:

- do not treat it as gameplay core, cube-state owner, or product shell: `off topic`
- do not consume `ee/` or flatten the repo into a blanket permissive donor: `boundary cost exceeds naive use`
- do not inherit its full AI memory product framing when the retained value is the support-plane architecture beneath it: `host-shell glue`

Integration call:

- retain as the primary local capture/history/replay, permissions, and vault donor in the support-plane lane
- use it in `Phase 2R` to freeze capture-trigger, retention, permission, vault, and timeline-sidecar contracts
- if later implementation proceeds, schedule it in `Phase 4R` only as a permissive-core allowlist or selective first-party reimplementation lane with `ee/` still excluded
