# TERMINOLOGY NOTE (2026-06-21): Historical rows in this file may use "clean-room" generically. New rows must follow FamiliarOS/docs/consolidated_workflows/shared/TERMINOLOGY_REFORM_GLOSSARY.md: MIT/BSD/Apache donors whose only barrier is product identity -> "first-party restatement"; restrictive/copyleft/no-grant -> "legal clean-room".
"packet_id","title","scope","top_repos_in_packet","primary_goal_for_coding_model","what_to_extract_first","decision_questions","required_outputs","grading_rubric","paste_ready_instruction","packet_scope_type","project_context","source_of_truth","repo","repo_key","scriptorium_bucket","source_audit_priority","current_reality_status","packet_prompt","must_inspect","integration_path","repurpose_path","merger_partner_1","merger_partner_2","merger_partner_3","success_condition","warning","_repo_norm","v6_source_of_truth","copyleft_strategy_layer_v6_1","copyleft_packet_note_v6_1","v6_3_source_of_truth"
"HT_browser_support","HyperTwist Browser Support Stack","Lower-level browser support utilities and package-level lanes beneath the main browser surface anchors: render substrates, helper layers, QA harnesses, motion internals, state and gesture utilities, docs/demo tooling, and selected fixture packs.","ecomfe/zrender | KhronosGroup/glTF-Sample-Renderer | pmndrs/zustand | pmndrs/use-gesture | @react-spring/core | pissang/claygl | pissang/clay-viewer | google/model-viewer/packages/space-opera | google/model-viewer/packages/render-fidelity-tools | google/model-viewer/packages/model-viewer-effects | google/model-viewer/packages/modelviewer.dev | google/model-viewer/packages/shared-assets | pmndrs/react-postprocessing | pmndrs/three-stdlib | pmndrs/maath | pmndrs/leva | @react-spring/parallax | @react-spring/rafz | @react-spring/animated | @react-spring/shared | @react-spring/types","Identify the strongest lower-level browser support stack for HyperTwist beneath the already-chosen browser surface anchors.","Render substrates, QA harnesses, helper abstractions, docs/demo tooling, state and gesture utilities, motion internals, and any boundary-sensitive asset-fixture packs.","Which packages deserve direct dependency use, which should stay merge-bounded, and which are valuable mainly as support utilities rather than product-level lanes?","module map; dependency versus merge recommendation; retained support stack; notable risks or boundary constraints","Prefer lower-level utilities that materially reduce implementation cost without distorting the Unreal-first runtime direction or overgrowing the browser companion stack.","Audit cluster HT_browser_support for HyperTwist. Candidate repos: ecomfe/zrender | KhronosGroup/glTF-Sample-Renderer | pmndrs/zustand | pmndrs/use-gesture | @react-spring/core | pissang/claygl | pissang/clay-viewer | google/model-viewer/packages/space-opera | google/model-viewer/packages/render-fidelity-tools | google/model-viewer/packages/model-viewer-effects | google/model-viewer/packages/modelviewer.dev | google/model-viewer/packages/shared-assets | pmndrs/react-postprocessing | pmndrs/three-stdlib | pmndrs/maath | pmndrs/leva | @react-spring/parallax | @react-spring/rafz | @react-spring/animated | @react-spring/shared | @react-spring/types. Determine which support utilities deserve direct dependency use, bounded merge use, or narrow reference status.","HyperTwist cluster packet","HyperTwist / browser-side support utilities","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. Most repos in these packets are permissive utility layers, but mixed or commercial rows still require bounded usage.","Default posture here is dependency use or bounded merge. Do not assume the whole upstream shell should be inherited.","v6.3_markdown_backfill"
"HT_browser_surface","HyperTwist Browser Surface Stack","Browser-side companion stack for analytics, 3D presentation, XR interaction, spatial UI, and embodied coach surfaces.","mrdoob/three.js | pmndrs/react-three-fiber | pmndrs/xr | pmndrs/uikit | google/model-viewer | apache/echarts | met4citizen/TalkingHead | KhronosGroup/glTF-Sample-Viewer | ecomfe/echarts-gl | pmndrs/drei | pmndrs/postprocessing | pmndrs/react-spring","Identify the strongest browser-side companion stack for HyperTwist across 3D presentation, analytics, XR interaction, spatial UI, and embodied coach surfaces.","Browser 3D substrate, XR and spatial UI seams, analytics/reporting surfaces, embodied coach presentation seams, and the highest-leverage helper layers.","Which repo should anchor browser 3D? Which repo should anchor browser XR and spatial UI? Which repos are direct dependency substrates versus merge candidates or concept-only helpers?","module map; retained browser-side stack recommendation; dependency versus merge-boundary recommendation; major risks; pairing order","Prefer bounded companion-surface leverage, clean dependency or merge seams, and browser-side reuse that does not distort the Unreal-first runtime direction.","Audit cluster HT_browser_surface for HyperTwist. Candidate repos: mrdoob/three.js | pmndrs/react-three-fiber | pmndrs/xr | pmndrs/uikit | google/model-viewer | apache/echarts | met4citizen/TalkingHead | KhronosGroup/glTF-Sample-Viewer | ecomfe/echarts-gl | pmndrs/drei | pmndrs/postprocessing | pmndrs/react-spring. Determine the best browser-side companion stack for analytics, 3D presentation, XR interaction, spatial UI, and embodied coaching. Identify substrate anchors, merge candidates, and clean dependency boundaries.","HyperTwist cluster packet","HyperTwist / browser-side companion surfaces","Backfilled from canonized Markdown dossier pass on 2026-04-24.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Before recommending direct code use, inspect repo-level v6 license and copyleft columns. These browser-side repos in this packet are permissive, but still preserve notices and treat assets separately where relevant.","Default posture in this packet is direct incorporation or bounded dependency use, not clean-room reimplementation, unless a later repo-specific exception appears.","v6.3_markdown_backfill"
"HT_control_plane","HyperTwist Telemetry / Replay Governance","Telemetry, replay diagnostics, feature-flag governance, and control-plane donor material for HyperTwist.","PostHog/posthog","Identify the highest-value telemetry, replay, and feature-governance seams worth retaining without inheriting the broader analytics platform shell.","Replay diagnostics, replay deep links and query surfaces, feature-flag CRUD/dependency logic, event-schema design, activity logs, and service-boundary patterns.","Which surfaces should stay bounded sidecar or service-only, which MIT paths are worth direct reuse, and which ee/ or mixed-license slices should be excluded or reimplemented?","module map; boundary recommendation; reusable schemas; replay and flag-governance surfaces; mixed-license risk notes","Prefer clean control-plane seams, replay/debugging leverage, and governance utility over broad analytics-shell adoption.","Audit cluster HT_control_plane for HyperTwist. Candidate repos: PostHog/posthog. Determine the highest-value telemetry, replay diagnostics, feature-flag governance, and service-boundary seams worth retaining. Identify bounded donor surfaces, mixed-license risks, and the cleanest control-plane boundary.","HyperTwist cluster packet","HyperTwist / telemetry and replay governance","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. Mixed-license rows require path-level review and bounded usage.","Default posture here is bounded donor use or selective reimplementation. Do not assume the analytics platform shell or any ee/ path should be inherited.","v6.3_markdown_backfill"
"HT_cube_semantics","HyperTwist Classic Cube Semantics","Classic-cubing semantics, algorithm language, twisty playback/viewer behavior, and compact state-generation donors for HyperTwist.","cubing/cubing.js | cubing/alg.js | cubing/twisty.js | HactarCE/2x2x2x2-Scrambler","Identify the highest-value classic-cubing semantics, parser, player, and compact scrambler/state seams worth retaining without inheriting upstream shells wholesale.","Algorithm grammar and AST semantics, canonical move/state boundaries, twisty playback behavior, scrubber/viewer seams, and compact solvable-state generation logic.","Which seams should stay direct under cubing/cubing.js, which restrictive companion packages justify separate clean-room reimplementation, and what is the cleanest semantics boundary for HyperTwist?","module map; semantics boundary recommendation; reusable parser/player/state surfaces; clean-room notes for restrictive companions","Prefer canonical semantics, clean state/render boundaries, and compact reusable runtimes over broader package shells or demo surfaces.","Audit cluster HT_cube_semantics for HyperTwist. Candidate repos: cubing/cubing.js | cubing/alg.js | cubing/twisty.js | HactarCE/2x2x2x2-Scrambler. Determine the best classic-cubing semantics boundary, the retained player and state-generation seams, and which restrictive companions require separate clean-room treatment.","HyperTwist cluster packet","HyperTwist / classic-cubing semantics and supplemental runtimes","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","P0","supplemental_v6_packet","Use v6 as the source of truth. Audit the extended HyperTwist core around logic, renderer, and puzzle-surface infrastructure. Focus on: State representations, algorithm parsers, scramblers, geometry cores, renderer abstractions, engine bindings.. Answer: Which new cubing/HactarCE repos materially deepen HyperTwist vs merely surround the existing core?.","State representations, algorithm parsers, scramblers, geometry cores, renderer abstractions, engine bindings.","HyperTwist physical + virtual hypercube training stack.","Repurpose according to v6 project design language and family role.","","","","Promotion notes, renderer/binding extraction notes, integration and merger decisions.","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. This packet intentionally mixes a boundary-sensitive usable anchor with restrictive clean-room companion rows.","Do not silently launder restrictive companion packages into the cubing/cubing.js lane. Keep direct-use and clean-room paths explicit.","v6.3_markdown_backfill"
"HT_cube_vision","HyperTwist Physical Cube Vision","Extract camera calibration, cube-state reconstruction, replay, and AR handoff.","kkoomen/qbr | vivaansinghvi07/rubix-cube-solver | cahidenes/rubiks-cube-solver | tentone/rubix-solver | aMonteSl/CodeXR | brianpeiris/RiftSketch | NuiLab/code-vr | yakupbilen/drl-rubiks-cube","Identify the strongest extractable engine(s), donor modules, hidden subsystems, and merger path(s) inside the HT_cube_vision cluster.","Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.; Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.; Inspect preprocessing/calibration; tracking stabilization; state reconstruction; replay/event model; camera abstraction; fallback heuristics; testing assets/videos; performance shortcuts.","Which repo actually owns the deepest engine? Which should remain shell-only? Which hidden modules are reusable even if the surface app is not?","module map; hidden feature list; reusable schemas; protocol/adapters; merge recommendation; estimated extraction boundary; tests/examples worth preserving","Prefer concrete internal engines, schemas, adapters, and extension hooks over README claims or surface UI appeal.","Audit cluster HT_cube_vision. Candidate repos: kkoomen/qbr | vivaansinghvi07/rubix-cube-solver | cahidenes/rubiks-cube-solver | tentone/rubix-solver | aMonteSl/CodeXR | brianpeiris/RiftSketch | NuiLab/code-vr | yakupbilen/drl-rubiks-cube. Identify base-vs-donor roles, hidden internal modules, schemas, adapter layers, plugin hooks, and the best clean-room reimplementation path.","Global cluster packet","Multi-project / global","Original global VS Code packets v3 retained","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Before recommending direct code use, inspect the target repo row in the v6.1 operational/phase/source-audit boards. Respect copyleft_strategy_v6_1, preferred_boundary_model_v6_1, and open_compliance_if_used_as_is_v6_1. Do not assume reverse engineering is mandatory or that as-is use is always sensible.","If the repo-level strategy says bounded_sidecar_preferred or boundary_first_then_decide_as_is_vs_reimplementation, audit clean interfaces, protocol seams, subprocess/container boundaries, and what would be required to reimplement only the strategically necessary portions.","v6.3_final_source_of_truth"
"HT_hyper_engine","HyperTwist Hypercubing Engine","Extract generalized puzzle/state/render abstractions for 3D–nD puzzles.","HactarCE/Hyperspeedcube | kash/cubedesk | cutelyaware/magiccube4d | roice3/Magic120Cell | roice3/MagicCube5D | roice3/MagicTile | Hypercubers/hypercubing.xyz","Identify the strongest extractable engine(s), donor modules, hidden subsystems, and merger path(s) inside the HT_hyper_engine cluster.","Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.; Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.; Inspect generalized puzzle/state model; notation parser; transform math; rendering abstraction; save/load format; puzzle generator; input mapping; performance optimizations.","Which repo actually owns the deepest engine? Which should remain shell-only? Which hidden modules are reusable even if the surface app is not?","module map; hidden feature list; reusable schemas; protocol/adapters; merge recommendation; estimated extraction boundary; tests/examples worth preserving","Prefer concrete internal engines, schemas, adapters, and extension hooks over README claims or surface UI appeal.","Audit cluster HT_hyper_engine. Candidate repos: HactarCE/Hyperspeedcube | kash/cubedesk | cutelyaware/magiccube4d | roice3/Magic120Cell | roice3/MagicCube5D | roice3/MagicTile | Hypercubers/hypercubing.xyz. Identify base-vs-donor roles, hidden internal modules, schemas, adapter layers, plugin hooks, and the best clean-room reimplementation path.","Global cluster packet","Multi-project / global","Original global VS Code packets v3 retained","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Before recommending direct code use, inspect the target repo row in the v6.1 operational/phase/source-audit boards. Respect copyleft_strategy_v6_1, preferred_boundary_model_v6_1, and open_compliance_if_used_as_is_v6_1. Do not assume reverse engineering is mandatory or that as-is use is always sensible.","If the repo-level strategy says bounded_sidecar_preferred or boundary_first_then_decide_as_is_vs_reimplementation, audit clean interfaces, protocol seams, subprocess/container boundaries, and what would be required to reimplement only the strategically necessary portions.","v6.3_final_source_of_truth"
"HT_solver_oracles","HyperTwist Solver Oracles","Solver-oracle and benchmarking lanes for correctness, robot metrics, and larger-cube planning reference.","efrantar/rob-twophase | ShellPuppy/RCube","Identify what should remain pure oracle or benchmark behavior and whether any narrow algorithmic seam deserves later clean-room extraction.","Correctness-oracle behavior, large-N or robot-metric seams, and benchmark harness details.","What should remain benchmark-only, and are there any bounded solver or metric seams worth later clean-room reimplementation?","oracle map; benchmark surfaces; retained algorithmic seams; clean-room candidate note","Prefer correctness, benchmark value, and bounded oracle surfaces over any upstream shell adoption.","Audit cluster HT_solver_oracles for HyperTwist. Candidate repos: efrantar/rob-twophase | ShellPuppy/RCube. Determine what must remain benchmark/oracle-only and whether any narrow seam justifies later clean-room extraction.","HyperTwist cluster packet","HyperTwist / solver oracles and benchmarks","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. These are retained mainly as benchmark/oracle rows, not donor shells.","Default posture here is benchmark use or clean-room extraction, not direct donor adoption.","v6.3_markdown_backfill"
"HT_support_sidecars","HyperTwist Support Sidecars","Support-plane sidecars for local capture/history/replay and media export or explainer rendering.","screenpipe/screenpipe | remotion-dev/remotion","Identify the strongest support-plane sidecars for capture/history/replay and media export without letting them distort the core product architecture.","Capture and replay seams, permission-aware support tooling, media export and explainer rendering surfaces.","Which support-plane sidecars should stay outside the product core and what is the cleanest bounded deployment posture for each?","sidecar recommendation; boundary model; retained modules; licensing or deployment risks","Prefer clean sidecar boundaries, operational usefulness, and bounded leverage over broad product-shell adoption.","Audit cluster HT_support_sidecars for HyperTwist. Candidate repos: screenpipe/screenpipe | remotion-dev/remotion. Determine the best bounded support sidecars for local capture/history/replay and media export or explainer rendering. Identify the cleanest boundary model and the modules worth retaining.","HyperTwist cluster packet","HyperTwist / support-plane sidecars","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. Most repos in these packets are permissive utility layers, but mixed or commercial rows still require bounded usage.","Default posture here is dependency use or bounded merge. Do not assume the whole upstream shell should be inherited.","v6.3_markdown_backfill"
"HT_timer_training","HyperTwist Timer Gold Standards","Timer behavior, inspection flow, and mature stats ergonomics benchmark.","cs0x7f/cstimer","Capture the gold-standard timer behavior and edge-case handling worth preserving as a benchmark reference.","Timer-state edge cases, inspection handling, rolling stats behavior, and event sequencing details.","Which timer behaviors are canonical enough to preserve as benchmark expectations, and what should remain pure reference rather than donor code?","behavior map; benchmark expectations; edge-case list; bounded timer reference notes","Prefer precise benchmark behavior and timer-state correctness over shell adoption.","Audit cluster HT_timer_training for HyperTwist. Candidate repos: cs0x7f/cstimer. Capture the timer, inspection, and stats behaviors that should survive as benchmark expectations.","HyperTwist cluster packet","HyperTwist / timer benchmark lane","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. This packet is benchmark-first, not donor-first.","Default posture here is benchmark/reference use or clean-room extraction if a timer seam later proves essential.","v6.3_markdown_backfill"
"HT_training_clean_room","HyperTwist Training Clean-Room Bench","Clean-room training benchmarks and restrictive training donors beneath the main training stack.","onionhoney/roux-trainers | alinen/cube | ambisinister/blindsolve | AviKaufman/Rubix-cube-trainer | MathewKJ2048/Rubiks-cube-simulator | vwcwong/CubeSim","Identify the highest-value clean-room training and pedagogy patterns worth preserving while keeping restrictive or no-license rows out of the direct donor path.","Planner behavior, drill pacing, pedagogy scaffolds, state-history handling, blindfold memo flows, and method-specific trainer logic.","Which rows stay benchmark-only, which deserve further Model A work, and which narrow training seams justify explicit clean-room extraction?","clean-room spec map; benchmark-only list; retained pedagogy and planner seams; custody recommendations","Prefer clean-room-safe behavior extraction and narrow subsystem specs over any temptation to inherit upstream shells.","Audit cluster HT_training_clean_room for HyperTwist. Candidate repos: onionhoney/roux-trainers | alinen/cube | ambisinister/blindsolve | AviKaufman/Rubix-cube-trainer | MathewKJ2048/Rubiks-cube-simulator | vwcwong/CubeSim. Determine benchmark-only versus clean-room-donor status and the highest-value training/pedagogy seams.","HyperTwist cluster packet","HyperTwist / restrictive and clean-room training lane","Backfilled from canonized Markdown dossier pass on 2026-04-25.","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Respect each repo row in the v6.3 legal columns before recommending direct use. This packet intentionally concentrates restrictive or no-license rows that should stay benchmark-first or clean-room-only.","Default posture here is Model A analysis, clean-room spec extraction, or benchmark use. Do not propose direct adoption of these shells.","v6.3_markdown_backfill"
"HT_training_stack","HyperTwist Training Stack","Extract trainer scheduling, timer/replay, case databases, and pedagogy UX.","tao-yu/Alg-Trainer | poliva/cubedex | Lykos/cube_trainer | abunickabhi/5style-Trainer | brownan/Rubiks-Cube-Solver | newyork-anthonyng/rubiks-cross-trainer | Aarav2709/KubeTimr","Identify the strongest extractable engine(s), donor modules, hidden subsystems, and merger path(s) inside the HT_training_stack cluster.","Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.; Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.; Inspect cube-state model; scramble generator; trainer weighting/scheduling; case database and metadata; replay/timer model; import/export of alg sets; smartcube or sensor adapters.","Which repo actually owns the deepest engine? Which should remain shell-only? Which hidden modules are reusable even if the surface app is not?","module map; hidden feature list; reusable schemas; protocol/adapters; merge recommendation; estimated extraction boundary; tests/examples worth preserving","Prefer concrete internal engines, schemas, adapters, and extension hooks over README claims or surface UI appeal.","Audit cluster HT_training_stack. Candidate repos: tao-yu/Alg-Trainer | poliva/cubedex | Lykos/cube_trainer | abunickabhi/5style-Trainer | brownan/Rubiks-Cube-Solver | newyork-anthonyng/rubiks-cross-trainer | Aarav2709/KubeTimr. Identify base-vs-donor roles, hidden internal modules, schemas, adapter layers, plugin hooks, and the best clean-room or direct-integration path for the training pillar.","Global cluster packet","Multi-project / global","Original global VS Code packets v3 retained","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Before recommending direct code use, inspect the target repo row in the v6.1 operational/phase/source-audit boards. Respect copyleft_strategy_v6_1, preferred_boundary_model_v6_1, and open_compliance_if_used_as_is_v6_1. Do not assume reverse engineering is mandatory or that as-is use is always sensible.","If the repo-level strategy says bounded_sidecar_preferred or boundary_first_then_decide_as_is_vs_reimplementation, audit clean interfaces, protocol seams, subprocess/container boundaries, and what would be required to reimplement only the strategically necessary portions.","v6.3_final_source_of_truth"
"MU_misc","HyperTwist Voice / Coaching Stack","Bounded voice sidecars for HyperTwist coaching, spoken guidance, and local speech IO.","ggml-org/whisper.cpp | SYSTRAN/faster-whisper | rhasspy/piper | coqui-ai/TTS","Identify the strongest bounded local speech stack for HyperTwist coaching and hands-free interaction, preferring ggml-org/whisper.cpp as the native STT anchor and treating faster-whisper as the complementary Python path.","Inspect streaming pipeline; VAD/segmentation; device abstraction; latency handling; multilingual or translation chain; local/offline fallback; API wrappers.","Which repo is the best STT anchor? Which repo is the best TTS anchor? What should stay sidecar-only rather than enter the runtime core?","module map; reusable audio pipeline pieces; boundary recommendation; latency risks; recommended STT/TTS pairing","Prefer low-latency local speech paths, clean sidecar boundaries, and reusable adapters over flashy surface UX.","Audit cluster MU_misc for HyperTwist. Candidate repos: ggml-org/whisper.cpp | SYSTRAN/faster-whisper | rhasspy/piper | coqui-ai/TTS. Determine the best bounded local voice stack for coaching and hands-free interaction. Identify STT/TTS anchors, reusable modules, adapter layers, and the cleanest sidecar boundary.","HyperTwist cluster packet","HyperTwist / voice coaching sidecars","Original global VS Code packets v3 retained","","","","","","","","","","","","","","","","v6_unified_source_of_truth_pack","Before recommending direct code use, inspect the target repo row in the v6.1 operational/phase/source-audit boards. Respect copyleft_strategy_v6_1, preferred_boundary_model_v6_1, and open_compliance_if_used_as_is_v6_1. Do not assume reverse engineering is mandatory or that as-is use is always sensible.","If the repo-level strategy says bounded_sidecar_preferred or boundary_first_then_decide_as_is_vs_reimplementation, audit clean interfaces, protocol seams, subprocess/container boundaries, and what would be required to reimplement only the strategically necessary portions.","v6.3_final_source_of_truth"
