CLEAN-ROOM REBUILD BRIEF — NEUROMEKA DIGITAL TWIN
User-authorized reset, 2026-10-04

MISSION
Discard the rejected implementation. Build a new, convincing, professional browser-based digital twin from the user's ORIGINAL Neuromeka Pangyo office PDF. The customer judges the whole experience by its visual quality and utility, not by test counts, research page length, or number of features. The previous output had unacceptable modeling, weak visual effects, flickering illumination, incoherent space/UI composition, and insufficient differentiation from the supplied Megazone reference. Do not repair or import the old code, generated scene, lighting maps, or CSS. They have been removed.

SOURCE AND SCOPE
Work only under C:/99.기술검토/07.뉴로메카-DT. Deploy only to C:/mongoose/neuromeka-twin. Preserve the original user PDF in Downloads as a read-only source; never generate work in Downloads. Inspect the original PDF and document only significant assumptions. Do not invent a floor number, facade, dimensions, equipment connectivity, or source-derived accuracy. Preserve the asymmetrical building perimeter and the meaningful lab/research/factory/service/meeting layout. Recreate from source, not rejected generated data. Keep all resources local for the deployed application and support the slashless /neuromeka-twin URL.

VISUAL TARGET
Study the supplied Unity whole-floor and room reference images and the Megazone web reference as a minimum functional comparison. Research additional high-quality real-time architectural visualization examples, production furniture, materials, lighting pipelines, and spatial UI. Compare multiple tools and methods; neither Blender nor a rendering engine is inherently the solution. Asset quality, believable proportions, light transport, contact, composition, and interaction must all be judged together. Do not substitute a generated still for an interactive scene.

ART DIRECTION
Create a calm architectural workspace: warm mineral background, dark readable typography, disciplined spacing, generous model area, and a restrained panel system. Use one typographic family with clear scale. Coordinate colors semantically: selected space, active light, airflow, warning, and disconnected state each have consistent visual meaning shared between HTML UI and 3D. A mode or light change must visibly change the intended space without repainting unrelated controls. Avoid busy badges, tiny labels, opaque highlighted room floors, clipping furniture, repeated plastic boxes, glowing outlines everywhere, and labels obscuring the model.

MODEL AND MATERIAL REQUIREMENTS
Prioritize the full-floor dollhouse composition, then selected-room inspection. Differentiate workstations, research benches, factory equipment, conference tables, lounge seats, storage, glazing, and circulation. Use believable rounded silhouettes, chair backs/seats/legs, monitor stands, joinery, wall thickness, window mullions, door openings, floor seams, and grounded contact. Prefer appropriately licensed production furniture when it improves silhouettes/materials over procedural approximations. Compare glTF assets, script-authored geometry, and offline DCC authoring. Use normal/roughness/base-color textures at believable physical scale; do not paint the same wood texture over every surface. Glass must remain readable with reflections and framing without hiding rooms. Validate near and far views.

RENDERING
Begin with a deterministic stable pipeline. Establish a single authoritative scene state and frame loop. No overlapping animation loops, dynamic shader recompilation per toggle, random-frame lighting, temporal accumulation artifacts, or competing lighting controllers. Light on/off and dimming must visibly affect room surfaces as well as fixtures. Ensure off does not remain equally illuminated by a baked on-state. Distinguish daylight from electric light. Assess baked indirect plus dynamic direct, analytic real-time lighting, and stable AO/contact approaches through actual experiments. Do not blindly adopt a sophisticated algorithm that performs poorly or flickers. If using baked maps, preserve UVs, energy separation, linear color workflow, and clear provenance. Use exposure/tone mapping consistently.

MODES
Maintain one authoritative floor graph and asset identity across 2D, 2.5D, and 3D.
2D: true top-down plan presentation with crisp outlines, readable zoning, minimal vertical clutter.
2.5D: elevated operational dollhouse; restrained wall heights, furniture volume, easy spatial scanning.
3D: full-height architecture and detailed furniture with orbit and useful room inspection.
Morph the same geometry/camera: architectural layers and furniture rise in a carefully staged, short sequence. Never swap screenshots or unrelated scenes. Preserve selected room, lighting, HVAC, temperature, labels, and camera intent through mode changes. Respect reduced-motion preference. Avoid nausea, huge camera jumps, and camera clipping.

OPERATIONS AND UI
Provide legible environmental context, space selection by label/list/model, a selected-space inspector, lighting power/dimming, HVAC power/fan/setpoint, event feedback, layer toggles, a truthful sheet/floor navigator, and useful zoom/reset controls. Mock telemetry must be labeled as simulated and must not pretend to control physical equipment. HVAC visualization must originate at the right outlet, convey direction and intensity, fade spatially, cease when off, and never resemble opaque ropes. Coordinate UI lighting warmth and effect colors without sacrificing contrast. Use keyboard semantics, focus indicators, responsive drawers, and unobstructed workspace.

TEAM AND OWNERSHIP
Orchestrator / Product & Rendering Lead: execute this English brief directly, integrate implementation, own app/UI/renderer, deploy and validate actual browser.
Research Architect: investigate multiple approaches and primary sources, compare costs/quality/stability, implement approved asset/material acquisition and report evidence.
Spatial & Asset Lead: reconstruct source geometry, create new spatial model and reusable detail assets, validate footprints and non-overlap.
Independent Critic: challenge assumptions, reject unconvincing whole scenes, inspect actual captures, judge visual quality and behavior independently of feature completion.
Agents must communicate dependencies and findings. A reviewer must not rubberstamp their own implementation. Avoid concurrent edits of the same files.

DOT-INSPIRED EVIDENCE LOOP
The term DoT is ambiguous. Diagram of Thought (Zhang et al., 2024) is a single-model reasoning framework, not a downloadable self-training guarantee. Apply only an explicitly labeled engineering adaptation: propose alternatives, have an independent critic challenge them, implement a bounded experiment, capture actual evidence, mark accept/reject, and branch on failure. Do not claim model retraining, formal proof, or automatic customer acceptance.
Record concise engineering decisions and evidence, not private chain-of-thought. Evidence records include hypothesis, alternate method, source links, changed files, screenshot/test result, reviewer verdict, unresolved defect, and next action. Rejected approaches must not leak into the release.
Carry forward the requested minimum five loops as whole-product comparisons, not five arbitrary features. Every loop must include a running integrated scene and a critical visual review. Stop counting a loop as successful merely because code compiles.

QUALITY GATES
- Full source footprint fits and remains recognizable in the opening view.
- Scene dominates the interface; all primary controls remain usable at common desktop sizes and in a narrow responsive layout.
- Selected spaces remain readable without covering furniture.
- Materials, furniture silhouette, contact and lighting visibly outperform crude placeholders.
- Same-camera light ON/OFF captures show an unmistakable intended surface difference.
- Static lighting is stable over a timed sequence; investigate any flicker quantitatively and visually.
- HVAC ON/OFF and fan speeds produce visible consistent differences.
- Repeated 2D/2.5D/3D transitions preserve identity and operational state without geometry failures.
- Report actual GPU/viewport/render frame timings, loading bytes and draw counts; do not promise universal 60fps.
- Verify missing assets, console errors, local deployment parity and slashless navigation.
- Perform a second independent whole-scene review AFTER final transition tests; fix significant findings.

DELIVERY
Deliver an actual working local website, not a research document. Provide direct links and representative real application screenshots, a readable English brief, a short evidence record and licensed asset provenance. Explain what is materially new and what remains below the reference bar. Never describe a partial feature pass as full visual acceptance. Continue implementation/research/review when evidence shows failure rather than repeatedly declaring completion.