Add design research knowledgebase and rendering experiment plan

README.md

@@ -25,6 +25,7 @@ Support initial development through the [Frontier Systems funding goal](https://
 - The first access-bypass runtime slice is documented in [`access-control-and-bypass.md`](docs/design/access-control-and-bypass.md); it uses synthetic debug tools until authoritative player inventory and equipment are implemented.
 - Modular machine control definitions, slot/port compatibility checks, and a trusted-handler catalog are implemented under `src/core/control/`. The [modular controls contract](docs/design/modular-controls-and-signals.md) specifies wired/radio pulses, machine actions, alarms, and messages; live installations and signal routing remain future work.
 - Control-board replacement plans retain fitted modules and check explicit relocations. Physical mounting and cable attachment allow dormant or unusual configurations; operability is diagnosed separately. The expanded door-board/igniter example is definition data, with construction execution and combustion still future work.
+- The [design and engineering research knowledgebase](docs/research/README.md) connects source-backed leads to bounded experiments, evidence limits and design decisions.
 - Foundation architecture and known limitations are documented in [`docs/architecture/foundations.md`](docs/architecture/foundations.md).
 - Non-fatal component integrity, gas/liquid pressure, docking, EVA, and remote-control invariants are documented in [`docs/design/survival-pressure-and-recovery.md`](docs/design/survival-pressure-and-recovery.md).
 

docs/research/README.md

@@ -0,0 +1,50 @@
+# Design and engineering research
+
+This is Frontier Systems' version-controlled knowledgebase for design decisions and bounded experiments. Research informs proposals; adoption belongs in the relevant design/architecture contract with measured acceptance evidence.
+
+## Start here
+
+| Entry | Topic | Outcome | Evidence limit | Next step |
+| --- | --- | --- | --- | --- |
+| [R-001: modern rendering optimization leads](entries/R-001-modern-rendering.md) | Rendering/performance | proposed | Official engine/vendor guidance and pinned source inspection; no reproduced rendering gains | [E-001: baseline and shared wall resources](experiments/E-001-rendering-baseline.md) |
+| [Reference manifest](reference-manifest.csv) | Cross-topic provenance | existing registry | Each row states its reviewed scope and rights limits | Append targeted sources; preserve the CSV contract |
+| [Foundational capability matrix v1](foundational-capability-matrix.v1.csv) | Engineering-game design | existing audit | Historical capability/gap statements have their own evidence dates | Revalidate a row before treating it as current implementation |
+
+Use [the entry template](entry-template.md) for new investigations. Stable entry IDs identify a question, rather than each newly found URL. Search the index, manifest, design contracts and open research PRs before adding an entry; update an existing entry when the question/source is already covered.
+
+## Existing knowledge and authority
+
+- [Architecture contracts](../architecture/) describe owners and implemented boundaries.
+- [Design contracts](../design/) distinguish direction from implementation, including [persistence and command boundaries](../design/persistence-and-command-boundary.md) and [bounded procedural worlds](../design/procedural-planets-and-memory-budgets.md).
+- [Original planning notes](../../research_notes/Godot%20colony%20simulation%20plan/godot_architecture.md) remain historical research; this index links to them rather than copying or relocating them.
+- [Performance reports](../../reports/performance/2026-10-09-baseline.md), [tick profiling](../architecture/tick-profiling.md) and [the simulation-rate matrix](../development/simulation-rate-benchmark-matrix.md) retain their original scope and caveats.
+
+The manifest remains the shared provenance registry required by AGENTS.md. An external URL, video, benchmark screenshot or source-level optimization opportunity is not project performance evidence. Record author claims, independent source inspection, reproduced measurements and adoption decisions separately. Missing publication dates, inaccessible material, mutable documentation and incomplete coverage must stay explicit. Summarize independently; do not store full articles/transcripts or import code/assets without the project's rights review.
+
+## Scope and research queue
+
+Keep each pass bounded to one project decision and a practical way to disprove it.
+
+| Topic | Bounded next question | Consult existing work first |
+| --- | --- | --- |
+| Rendering/performance | Can shared immutable wall resources improve a controlled workload? | R-001 / E-001 and the existing client benchmark |
+| Simulation | Which measured owner/command work exceeds a tick budget? | Tick profiling and simulation-rate matrix |
+| Persistence | Which interrupted checkpoint/retry failure needs stronger recovery evidence? | Persistence/command design and current checkpoint milestones |
+| Multiplayer/networking | Which join/reconnect observation or bandwidth bound lacks exact-head evidence? | First-playable adapters and current observation contracts |
+| Engineering-game design | Which repair/salvage/resource decision improves understandable recovery? | Capability matrix and survival/recovery design |
+
+These are research questions, not approved runtime features. Prefer official engine documentation, papers with inspectable methods, and reproducible analyses. Videos supply leads; hardware/vendor advice must be evaluated against the actual renderer, API and target hardware.
+
+## Weekly pass and handoff
+
+The dedicated Frontier research task owns this index and its evidence updates. The parent coordinator owns scheduling; this document creates no automation. This workflow does not authorize disclosure of additional unfinished/private engine research, logs or credentials. Each weekly pass:
+
+1. Read current AGENTS.md, this index, the manifest, affected contracts and open PRs through cloud tools. Pin the current integration commit; preserve desktop processes and working trees.
+2. Revisit changed evidence and unresolved source gaps first. Deduplicate by URL/video ID, stable entry ID and research question; do not append unsupported links merely to show activity.
+3. Investigate one bounded question using primary sources. Record access/version context, what was actually inspected, costs, limits and a reproduction/A/B proposal. An unrun experiment remains proposed.
+4. Update the existing entry and manifest, retaining prior failures or superseded conclusions with dates. Propose at most one consolidated docs-only PR for the pass. Use a regular PR when the documentation slice is complete; reserve draft status for unfinished documentation or an actual unresolved blocker. If an equivalent PR is already open, update that research branch after checking its head rather than opening a duplicate.
+5. Report PR/head, exact files, source/diff checks, measurements actually run, missing evidence and the next decision. Runtime experiments need separately authorized execution; this research workflow does not launch local games, benchmarks, GPU workloads or paid services.
+
+Outcome vocabulary: **proposed** (hypothesis/plan), **tested** (bounded independent reproduction linked), **adopted** (decision accepted into a project contract), **rejected** (failed criterion or unsuitable tradeoff), **superseded** (replacement linked). Evidence can be source-checked while the outcome remains proposed. Record a decision date and scope for every transition.
+
+Initial pass: **2026-10-25**; integration snapshot `b19e99ffd964006c4e590435239a8f17adbd62d5`. Existing research/design organization, manifest, renderer settings, wall presentation path, baseline report and CI scope were inspected through GitHub cloud reads. Runtime and visual acceptance were not exercised.

docs/research/entries/R-001-modern-rendering.md

@@ -0,0 +1,54 @@
+# R-001: modern rendering optimization leads
+
+- **Topic:** rendering/performance; engineering-game readability
+- **Outcome/status:** proposed; source-checked on 2026-10-25; no project rendering gains reproduced
+- **Decision date:** pending
+- **Project snapshot:** `b19e99ffd964006c4e590435239a8f17adbd62d5` on dev-master
+- **Next step:** [E-001: controlled baseline and shared wall resources](../experiments/E-001-rendering-baseline.md)
+
+## Sources and access
+
+All access/review dates below are **2026-10-25**. Godot 4.7 pages were opened alongside the supplied stable aliases; versioned URLs narrow context but remain mutable, without a captured documentation commit.
+
+| ID | Source/title | Author/publisher | Publication date | Reviewed version/context |
+| --- | --- | --- | --- | --- |
+| V1 | [Tutorial: How To Optimize Almost Every Step In Modern Game Rendering](https://www.youtube.com/watch?v=SnNm7rSSvlg) | Threat Interactive | Unverified | Video ID SnNm7rSSvlg; title/channel supplied by parent review. This pass's public video/oEmbed fetches were throttled. |
+| D1 | [Optimizing 3D performance](https://docs.godotengine.org/en/4.7/tutorials/performance/optimizing_3d_performance.html) | Godot documentation contributors | Not stated on reviewed page | 4.7; culling, automatic/manual instancing and lighting |
+| D2 | [3D antialiasing](https://docs.godotengine.org/en/4.7/tutorials/3d/3d_antialiasing.html) | Godot documentation contributors | Not stated | 4.7; MSAA, TAA and FSR2 |
+| D3 | [Occlusion culling](https://docs.godotengine.org/en/4.7/tutorials/3d/occlusion_culling.html) | Godot documentation contributors | Not stated | 4.7; mechanism, bake limits, moving occluders and runtime comparison |
+| D4 | [MultiMesh](https://docs.godotengine.org/en/4.7/classes/class_multimesh.html) | Godot documentation contributors | Not stated | 4.7 class description; group visibility/AABB and light limits |
+| A1 | [RDNA Performance Guide](https://gpuopen.com/learn/rdna-performance-guide/) | AMD GPUOpen | 2023-03-22 originally posted; later update date unverified | Mutable guide with RDNA 3 updates; command buffers, PSOs, barriers and memory |
+| G1 | [Introducing Reverse Z](https://godotengine.org/article/introducing-reverse-z/) | Clay John / Godot | 2024-04-29 | Historical 4.3 introduction and shader compatibility note |
+
+V1 coverage is inherited evidence from the parent research review: **3,235 caption segments through 2:00:36 of a 2:01:25 video**, obtained through [LinkTranscript](https://linktranscript.com/result?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DSnNm7rSSvlg). The caption service retained an older title and transcription errors. This pass could not independently retrieve that page; the final 49 seconds/outro remain unverified. No full transcript or benchmark assets are copied here.
+
+## Claims versus evidence
+
+| Lead | Source claim/context | Independently checked here | Limit / project inference |
+| --- | --- | --- | --- |
+| Rendering pipeline changes | Parent's V1 review identifies optimization ideas; many GI, AA and motion-blur sections are explicitly unfinished proposals | No video technique or benchmark was reproduced | Treat as investigation leads; no compounded percentage or whole-game gain |
+| Repeated geometry | D1 documents Forward+ automatic instancing for shared mesh/material resources, with transparency restrictions | Pinned wall code constructs distinct resources; see audit below | Sharing is a small first hypothesis; no measured speedup |
+| Image stability/readability | D2 describes MSAA's edge coverage limits and TAA's shader/specular coverage with camera-motion blurring/ghosting risks; FSR2 can run at native resolution with added cost | Documentation checked, no capture comparison performed | Assess moving cables, panel edges, labels and selection feedback, not only still screenshots |
+| Hidden rooms | D3 describes CPU occlusion rasterization, setup/CPU overhead and static bake constraints; moving occluders can require BVH rebuilds | Documentation checked, no dynamic-room experiment performed | Doors and demolition must retire occlusion immediately when view opens; stale occluders are a correctness failure |
+| Low-level renderer work | A1 discusses submission/state/barrier/memory costs for RDNA/DX12/Vulkan | Vendor guidance checked, no native experiment | Godot owns these mechanisms; RDNA tuning is not a universal RTX result or an instruction to modify the engine |
+| Depth precision | G1 introduced reverse-Z in Godot 4.3 | Historical primary source checked | Already engine functionality; no new Frontier reverse-Z project |
+
+D4 cautions that MultiMesh groups instances as one spatial object with an encompassing AABB and shared per-object lighting limits. Grouping an entire base could worsen visibility/light behavior; consider spatial batches only if simpler sharing leaves a measured bottleneck.
+
+## Pinned Frontier evidence
+
+The following are source observations at the stated commit, not runtime results from this pass:
+
+- [project.godot](https://github.com/Valgorithms/Frontier-Systems/blob/b19e99ffd964006c4e590435239a8f17adbd62d5/project.godot) declares 4.7 / Forward Plus, Windows D3D12, 1920x1080 viewport/window defaults and 60 Hz physics. [CI](https://github.com/Valgorithms/Frontier-Systems/blob/b19e99ffd964006c4e590435239a8f17adbd62d5/.github/workflows/ci.yml) selects Godot 4.7.2. Defaults do not prove actual runtime viewport sizes or minimum hardware.
+- [The October 9 report](https://github.com/Valgorithms/Frontier-Systems/blob/b19e99ffd964006c4e590435239a8f17adbd62d5/reports/performance/2026-10-09-baseline.md) describes a working tree based on f830bcb with uncommitted changes, five-second warmup and one fifteen-second session per profile. Habitat rendering was **523x504**, root **1152x648** despite a requested 1280x720 window. It explicitly identifies unresolved pacing near 75/120 Hz and changes both renderer and driver. Its FPS difference is not a clean renderer-throughput comparison or an exact-b19e99f measurement.
+- [ProceduralProductionPreview._update_spatial_walls](https://github.com/Valgorithms/Frontier-Systems/blob/b19e99ffd964006c4e590435239a8f17adbd62d5/src/presentation/production/procedural_production_preview.gd) creates a BoxMesh and material per new wall before calling [EngineeringObjectDetails.wall](https://github.com/Valgorithms/Frontier-Systems/blob/b19e99ffd964006c4e590435239a8f17adbd62d5/src/presentation/production/engineering_object_details.gd). That helper replaces the panel mesh/material, then creates eight decorative boxes, each with its own mesh/material. Source-level expansion gives **10 BoxMesh and 10 StandardMaterial3D constructions per newly created wall**: initial panel 1 + replacement 1 + details (2 + 2 + 2x2). One panel pair is replaced before the wall body is added to the preview; this arithmetic is not a retained-memory, allocation-byte, draw-call or GPU-timing measurement.
+- [SpatialWallConstruction](https://github.com/Valgorithms/Frontier-Systems/blob/b19e99ffd964006c4e590435239a8f17adbd62d5/src/core/production/spatial_wall_construction.gd) caps canonical prototype walls at **32**. Therefore 100/1,000-wall tests are isolated presentation stress fixtures, not supported gameplay populations or authorization to raise that cap.
+- [The existing client benchmark](https://github.com/Valgorithms/Frontier-Systems/blob/b19e99ffd964006c4e590435239a8f17adbd62d5/tools/godot/benchmark_client.gd) collects viewport render times, frame intervals and resource gauges. It uses a stationary main scene and writes renderer/rate-qualified reports. It does not provide the moving-camera, wall-count or per-pass experiment automatically. [Tick profiling](https://github.com/Valgorithms/Frontier-Systems/blob/b19e99ffd964006c4e590435239a8f17adbd62d5/docs/architecture/tick-profiling.md) excludes rendering/GPU and is a different measurement boundary.
+
+## Relevance, costs and decision
+
+Repeated resource construction offers a narrow presentation experiment while preserving canonical wall ownership, collision, selection and persistence. Shared resources need complete immutable cache keys; mutating a shared highlight/material can accidentally change every wall. Decoration, shadow passes and CPU scene traversal may dominate even after sharing. Wall removal/recreation needs bounded cache retention.
+
+A future comparison should establish actual 1080p render targets and CPU/GPU/frame-tail timing, then change only resource sharing. Supported AA comparisons and room/shadow budgets follow separately. Dynamic geometry makes baked lighting/occlusion less straightforward; visibility must follow authoritative observations without becoming simulation authority.
+
+**No custom GI, deferred renderer, motion-blur or AA rewrite is justified by this entry.** First identify a measured project bottleneck and preserve motion readability. Runtime reproduction, target lower-end hardware, VR/stereo behavior, video publication date and the unreviewed outro remain open. See E-001 for falsifiable controls and acceptance limits.

docs/research/entry-template.md

@@ -0,0 +1,33 @@
+# R-NNN: question or decision
+
+- **Topic:** rendering/performance | simulation | persistence | multiplayer/networking | engineering-game design
+- **Outcome/status:** proposed | tested | adopted | rejected | superseded
+- **Reviewed / decision date:** YYYY-MM-DD / pending
+- **Project snapshot:** full commit, relevant paths/contracts and configuration
+- **Owner / next review:** research task and a bounded unresolved question
+
+## Sources and access
+
+| ID | URL and title | Author/publisher | Publication/update date | Access date | Version/context and reviewed scope |
+| --- | --- | --- | --- | --- | --- |
+| S1 | Direct source link | Known author or unknown | Exact date or unverified | YYYY-MM-DD | Commit/version; mutable-page caveat; sections/time coverage |
+
+Append reviewed sources to reference-manifest.csv using its existing columns. State rights restrictions; linking/summarizing is not permission to copy code or assets.
+
+## Claims and independent evidence
+
+| Claim/hypothesis | Source's actual claim | Independent evidence and exact scope | Remaining gap |
+| --- | --- | --- | --- |
+| One bounded claim | Distinguish demonstrated material from proposals | Source inspection, reproduced measurement or none | Missing configurations, runs or inaccessible content |
+
+## Project relevance, costs and limitations
+
+Name the owner, affected contract and decision this could change. Explain engineering time, CPU/GPU/memory/network/storage costs, correctness/readability risks and applicability limits. Separate inference from observation.
+
+## Reproduction or A/B experiment
+
+Define control/variant, fixed inputs/configuration, sample/repetition method, metrics, correctness guardrails, adoption/rejection criteria and artifact locations. Reuse an existing harness where suitable; disclose its coverage gaps. Record exact tested commit/diff and environment. Do not imply the plan ran.
+
+## Outcome and follow-up
+
+Record actual result, evidence links, failures and what remains unrun. An adopted decision links to its accepted contract; a superseded entry links to its replacement. Preserve the dated rationale.