Current plan Needs David/Peter approval · Execution target for LDD V2

LDD System Plan

Goal: turn the LDD set into a living, zoomable project knowledge system while keeping the static site stable, reviewable, and safe to deploy today.

This is the current approval page. The earlier rebuild proposal and AI responses are now background archive material. This page is the plan to vet, approve, and then execute.

What stays stable

LDDs remain canonical outputs. Claude controls LDD rewrites unless David explicitly overrides the lock.

What changes now

The static site becomes data-shaped: sidecar maps, stable IDs, semantic status, hierarchy, backlinks, and visible rollups.

Where this leads

The future wiki can ingest the same model as projects, topics, documents, signal blocks, channels, revisions, and scorecards.

Core Concept

The LDD hierarchy should not be flat, and it should not be a rigid top-down sequence. It should be a roll-up / drill-down knowledge map that lets a human or LLM move between project atmosphere, system headers, focused LDDs, decision blocks, active research, and canonical outputs.

Working model

Input → Logic / Analysis → Output. Raw comments, product ideas, screenshots, sketches, and research enter the system as inputs. They are worked through in analysis spaces: collisions, scorecards, comparisons, and debate. Mature results then become formal LDD decisions or proposed LDD revisions.

Four Axes

Hierarchy Project world → top-level header documents → subsystem LDDs → decision blocks → evidence and open questions.

Process stage Input, exploration, analysis, proposal, canonical LDD output, superseded history.

Status Draft, exploring, proposed, pending review, locked intent, locked, needs update, superseded. Status can exist at every level.

Experience Spatial narrative, sensory hierarchy, emotional purpose, behavioral choreography, maintenance calm, and future lived experience.

Target Hierarchy

Barndo Project
  Atmosphere / World Bible
    Great Hall thesis
    Calm industrial language
    Korean cooking / social intimacy
    Maintenance as psychological calm
    Aging-in-place dignity

  Header LDDs
    Building Shell
    Comfort / HVAC / Radiant
    Gym / Athletic Great Hall
    Mechanical Core
    Living Program
    Site / Civil / AHJ
    Budget / Build Sequence

  Focused LDDs
    Clerestories
    Flooring
    Basketball
    MUA
    Plumbing
    Lighting
    Equipment / appliances

  Working Buckets
    Inputs
    Research
    System collisions
    Proposals
    Canonical outputs

Execution Plan

Phase	Build	Approval question
1. Knowledge map	Expand `site/assets/ldd-index.json` into a richer map with hierarchy, parent/child nodes, process stage, and relationship tags.	Do the top-level header documents feel right?
2. Header pages	Create top-level LDD header pages for major systems that roll up child LDDs, status, collisions, and open decisions.	Can Peter or an LLM understand the whole section from the header?
3. Working buckets	Add Input, Logic / Analysis, and Output areas so brainstorming does not prematurely overwrite canonical LDDs.	Does the process protect curiosity without polluting locked documents?
4. Zoom UI	Add jump paths, backlinks, rollups, and drilldowns to LDD pages using stable IDs and sidecar data.	Can users move up/down/sideways without getting lost?
5. Wiki migration	Translate the static model into the future wiki schema: projects, topics, documents, revisions, signal blocks, comments, and scorecards.	Does the static model import cleanly without rewriting meaning?

Approval Checklist

Approve the top-level header categories.
Approve the Input → Logic / Analysis → Output workflow.
Approve separating experiential intent from technical implementation status.
Approve using the static site as a published view, not the whole source of truth.
Approve expanding the sidecar map before deeper UI work.

Decision Needed

If this page is approved, the next implementation step should be Phase 1: expand the knowledge map. That is the lowest-risk move because it does not rewrite LDD content. It gives the project a stronger skeleton that can drive both the current static site and the future wiki.