Developer Focus 2026-05-18 · Discussion chain · LDD UI method note

Recursive Zooming UI

Core read: the LDD hierarchy should behave like a living systems map, not a rigid linear instruction manual. The UI should protect stable governing logic while making it easy to jump into any subsystem that has energy, curiosity, or risk attached to it.

This page captures the chain of discussion after the first migration-shaped LDD pilot. The key correction is that Barndo's design workflow is not a waterfall plan moving from macro to micro. It is iterative systems discovery through recursive zooming.

Discussion Chain

1. Peter's clarification

Peter reframed the workflow as recursive zooming: establish a broad architectural instinct, zoom into a subsystem, learn the technical reality, zoom back outward, refine the governing principles, and repeat.

The important distinction: hierarchy is useful as a knowledge-integration framework, but dangerous if it becomes a restrictive design sequence.

2. The successful loop

Peter named the feedback loop that has made the project work: curiosity drives exploration, exploration increases technical literacy, literacy strengthens design confidence, confidence sharpens system simplification, and simplification reinforces project clarity.

The UI should preserve that loop instead of forcing the work into an artificial order.

3. Gemini's response

Gemini emphasized the human engine behind the build: David's curiosity. The micro-focus is often the entry point. A specific object, system, or tactile detail creates momentum, then the macro architecture adjusts to hold what was learned.

That means jumping around is not a problem to solve. It is one of the system's strongest behaviors.

4. Codex synthesis

The UI needs two simultaneous layers: a stable map that prevents contradiction, and flexible entry points that support subsystem deep dives in any order.

In practical terms: keep the category hierarchy, but add jump paths, collision maps, zoom links, and discovery trails.

The Recursive Loop

Instinct A broad architectural direction or emotional pull appears.

Zoom in A subsystem, object, material, appliance, or technical question becomes interesting.

Reality The deep dive exposes constraints, costs, code issues, geometry, or maintenance needs.

Zoom out The new knowledge changes how the larger building system is understood.

Resync The governing LDD logic tightens, simplifying the overall project.

What The UI Must Not Do

Do not turn hierarchy into permission

The UI should never imply that David must finish "master planning" before exploring a toilet, fan, clerestory, bidet, light fixture, drain, floor sample, mirror detail, or mechanical-room component. Micro curiosity is often the fastest path to macro understanding.

Do not punish jumping

If the interface makes jumping feel like disorganization, it will fight the actual design method. Jumping should be captured, linked, and re-synced back into the LDD map.

UI Principles

Stable map Keep categories, LDD IDs, lifecycle state, source attribution, and revision history stable. This prevents contradiction and gives the wiki migration a clean data shape.

Flexible entry Let David enter through any active curiosity: plumbing, acoustics, ventilation, lighting, floor structure, athletic systems, appliances, or serviceability.

Collision first Show where systems reshape each other. HVAC affects ceilings. Radiant affects flooring. Kitchen MUA affects mech-room architecture. Athletic openness affects structure.

Zoom paths Each LDD should show how to zoom out to governing strategy, sideways to related LDDs, and inward to unresolved technical decisions.

Resync ritual Every deep dive should have a lightweight way to return the discovery to the master logic: what changed, what it affects, what still needs review.

Recommended UI Additions

UI element	Purpose	Example
Jump by relationship	A second navigation mode beyond categories.	Affects gym, affects slab, affects ceiling, affects serviceability, affects AHJ/code.
Zoom links panel	Make every LDD a hub, not a dead-end document.	Zoom out to master strategy, sideways to related LDDs, inward to equipment/spec questions.
System collisions	Surface the real design engine.	Kitchen ventilation reshaped island proportions and MUA routing.
Discovery trail	Explain why a decision exists.	Gym comfort led to floor resilience, which changed render prompts and flooring LDD dependencies.
Decision backlinks	Use stable block IDs to show what depends on a decision.	LDD-30 decision #17 can point to HVAC, plumbing, electrical load, and budget.
Resync checklist	Close the loop after a deep dive.	New constraint found, affected LDDs listed, status chip updated, open review owner named.

How This Changes The Current Pilot

The current V2 pilot is still directionally correct: sidecar index, category sidebar, stable decision IDs, semantic chips, and revision history are all useful. But the next layer should not be more hierarchy. The next layer should be more movement.

Add relationship tags to the sidecar index, not just category tags.
Add a "Jump paths" panel to LDD-29 and LDD-30.
Track "system collisions" as first-class records.
Use stable decision IDs as backlink targets.
Keep status chips descriptive, not sequential. "Pending review" means needs attention, not "do not explore yet."

Bottom Line

The right interface is not a command hierarchy. It is a working map for a curious mind moving through a complex building. The map should let David jump anywhere, learn something real, and then bring that discovery back into the whole system without losing the thread.