One Design island.
Different application experiences.

01 · KEEP WHAT WORKS

Change the Design experience.

The homepage and four islands remain: Learn, Data, Design, and Monitor. Simulation, mission playback, digital-twin work, and Garage remain within Design. The approved “What are you powering?” cards, original Lemonergy logo, neutral surfaces, blue accents, and Light/Dark choice are retained.

The shared advanced pack editor remains useful. It should open with a persistent application, machine, and mission heading, with relevant tools prioritized. An expert can still move into the common cell, topology, component, and analysis tools.

02 · VERIFIED FINDINGS

Three problems need different fixes.

1. The earlier preview omitted the larger detailed car showroom. The separate showroom branch preserves 72 artist car entries: the original 22 plus 50 additions. Two entries are blocked, leaving 70 candidates eligible for the existing hosted viewer; eligibility does not prove current loading, exact trim fidelity, or engineering suitability. The earlier total of 28 described only a narrow selection of 22 engineering donor records, 2 vessel studies, and 4 robot applications. It was not the full Garage inventory.
2. Two different 3D systems were conflated. The artist showroom uses original detailed models hosted in Sketchfab, with source links and creator credits. The live designer’s separate Godot Garage reports its renderer unavailable, and garage3d/build/index.html returns the site’s 404 page. Repairing that Godot export does not restore the larger artist catalog by itself. The recovered artist viewer was checked in this local preview: the original Tesla Model 3 and expansion BMW i4 rendered successfully. The BMW model also responded to orbit controls in its original hosted viewer.
3. Different applications share the same workbench framing. The presets do change requirements and starting pack sizing on a fresh launch. However, the common layout makes that hard to see. In addition, changing only the URL fragment of an already-loaded workspace does not rerun initialization; a saved URL containing cell and series/parallel values can intentionally override a new preset.

Fresh live launches were compared: Drone opened with a 250 Wh requirement and a 6S4P, 24-cell starting pack; Wearable opened with a 1.1 Wh requirement and a 1S5P, 5-cell starting pack. This confirms different preset behavior despite the shared interface. It does not establish which state transition caused every instance of the “same design” observation. These are starter estimates, not engineering validation. Source references ↓

03 · THE CUSTOMER JOURNEY

Application → machine → mission → battery response.

“Run a mission” means execute a supported calculation. “Replay” means play or scrub its completed result. Driving, flying, steering, and interactive robot commands are a later feature, requiring controls connected to a solver. The current inspection viewer and trace player should not be presented as that feature.

04 · WHAT CHANGES FOR EACH APPLICATION

The first screen should answer a different question.

All rows describe the proposed experience, using existing application presets as the starting point. Each output must be connected to an appropriate supported model before it becomes a calculated result.

05 · THE GARAGE CATALOG

A compact chooser beside the original 3D model.

The revised local scope is 72 artist car entries, 2 boat studies, and 4 robot applications. Show family counts, compact searchable rows, and one selected-machine viewer. Keep the machine details and application-specific workflow beside the selection. Large empty cards and oversized icons should not consume the space needed for the model and useful specifications.

For cars, reuse the original Sketchfab model identifiers and viewer behavior, with creator credits and source links. Of the 72 source artist entries, 2 remain blocked and 70 are embed-eligible candidates; show a clear reason for blocked or unavailable models. Load at most one selected model, and provide a direct source link if it cannot load. These are exterior visual references, not validated engineering CAD or evidence of battery fit.

The 22 exact engineering donor records remain a separate, identified subset. Only a confirmed donor mapping should open a donor-specific engineering study; an exterior-only entry must not silently become a different car. Boat entries remain the two existing vessel studies, and robot entries remain application studies rather than four named commercial robot assets. The current Marine URL cannot encode a vessel ID, so its links must still explain the vessel selection inside the workspace.

The wider, unmerged showroom branch contains 172 vehicle contexts and adds 30 visual references beyond the retained 72 artist entries. Those broader research records and visual candidates are not all ready for this preview. Keep that expansion separate from the current 72-car selector, and do not present record counts as counts of verified 3D models.

06 · RESTORE THE ORIGINAL 3D EXPERIENCE

Recover the artist viewer; repair Godot separately.

1. Reuse the existing detailed artist showroom. Its source route is artist-car-gallery/, with selection carried by ?car=<id>. Reuse its original asset IDs, blocked-entry handling, creator attribution, and single selected Sketchfab iframe. The branch also supplies tools/build-refurbishment-showroom.mjs for packaging the complete original gallery and its canonical engine dependencies.
2. Verify the selected model in the local preview. Check an original car and a car from the 50-entry expansion, model switching, orbit/zoom, mobile layout, keyboard access, and recoverable loading failure. Confirm that two blocked entries cannot launch. Recorded source QA is useful evidence, but it is not a current rendering test.
3. Repair the separate Godot deployment. Build its existing car and vessel scenes from a matching revision and deliver the export with all runtime files. The current distribution builder treats that export as optional, and the Pages path has a large-file limitation. Verify the actual deployment route and runtime requirements before release.
4. Keep each integration’s boundaries explicit. The hosted artist model is a visual reference; the Godot scene and engineering calculation have their own identities and capabilities. Preserve source versions, loading policy, required CSP and origin checks, and distinguish inspection, recorded playback, and solver-connected interaction.

The local preview restores access to source artist-viewer candidates. Current model rendering remains an acceptance check. Production Godot repair remains outstanding, and this proposal does not deploy either system.

07 · IMPLEMENTATION SHAPE

Share the engine. Make application context explicit.

• One application registry: map each preset to machine choices, requirement fields and units, applicable mission profiles, scene capability, result priorities, and availability. Keep IDs and default values tied to source definitions.
• One persistent study context: carry application ID, exact machine ID, requirements, mission, selected pack, solver configuration, and source versions from setup through results. Surface the current identity in the workbench heading.
• Intentional transitions: handle application changes through a real navigation/state transition. Reset incompatible fields and explain what will change; preserve or export unsaved work through the established project workflow. Adding an unguarded hash-change reset is insufficient.
• Clean starter links: use a fresh workspace with only the application/tab and optional donor ID. Do not reuse old cell or series/parallel overrides. A starter URL is not a saved project; the current hash omits edited requirements, mission, route, and vessel state.
• Contextual results: reuse the same numerical solvers and shared chart components where appropriate, but prioritize the quantities the selected application needs. Show units, calculation status, assumptions, and limits beside the relevant result.
• Lazy loading: load the detailed 3D runtime when requested and cache compatible assets. The catalog and requirements remain usable while it loads. Preserve keyboard access, focus management, mobile layout, and reduced-motion behavior.

08 · DELIVERY AND ACCEPTANCE

Restore, differentiate, then extend.

The local preview demonstrates the compact catalog, original hosted car-viewer integration, and differentiated presentation. Its rendering checks must be recorded separately from production acceptance. It does not deploy the broader branch, rebuild Godot, or add new simulation capabilities. Start production integration with one confirmed donor journey and one contrasting application, then extend the shared pattern across the registry.

09 · BENEFITS AND COSTS

A coherent product with visible engineering depth.

Recommendation: retain one Design island and a common advanced workbench, recover the original detailed artist showroom with a compact selector, repair Godot separately, and build application-specific entry and mission experiences around the existing engine.