Wiki migration status 2026-05-18 · Planning note · Checked against 4019-a-wiki-wiki-wiki

Wiki Migration Status

Core read: the Barndo V2 LDD UI plan is parallel-correct with the future wiki product. The adjustment is to make the V2 UI data-shaped now, so a later migration becomes a transform instead of a rewrite.

This page compares the Barndo LDD rebuild direction against the current local wiki prototype at /Users/davidkim/SpicyRiceCakes/projects/04-Fourth Grade/4019-a-wiki-wiki-wiki. It is a migration-readiness note only; Barndo stays a static Cloudflare site for now.

Verdict

Proceed with the V2 LDD UI changes, but encode status, category, identity, and signal meaning in data attributes or a sidecar index.

Migration target

The wiki already has a barndo_decision template for building/LDD projects with scorecards, status boards, risks, and next actions.

Not yet

Do not migrate Barndo into the wiki now. The wiki is still a prototype and needs import, lock, and API validation before becoming canonical.

Fit Check

Green Project shape fits. The wiki model has projects, topics, documents, document revisions, channels, scorecards, and project locks. That matches Barndo's LDD bible, Watercooler, audits, scorecards, and Claude LDD lock.

Green AI attribution fits. The wiki treats AI access points as delegated actors under humans, with model/version and on-behalf-of attribution. That is exactly the kind of audit trail Barndo needs once AI commentary becomes database-backed.

Yellow Status semantics need normalization. Barndo currently mixes page lifecycle, item status, risk type, and visual callouts. The wiki separates signal kind from resolution state. V2 should respect that split.

Yellow Stable block IDs are missing. Future comments, signals, and proposed patches should target a specific decision, risk, diagram, or open item. V2 can prepare by adding stable IDs to important LDD blocks.

Red No migration pipeline yet. There is no proven import path from Barndo's canonical Markdown/static HTML into the Pocketbase document/topic/signal model. Build that later, after V2 UI semantics settle.

Concept Mapping

Barndo V2 concept	Wiki target concept	Status	Migration note
LDD Bible	`project` + `topics` + `documents`	Fits	Each LDD becomes a document with `content_type = ldd`; category grouping maps to topics/sections.
Sidebar categories	`default_nav_json` / project sections	Fits	Master Strategies, Building Systems, Zones, Elements, Materials, and Process can become project navigation groups.
Page-level LDD dot	`topics.status` or document lifecycle	Needs rule	Keep this separate from item-level status. It answers "can I rely on this LDD page?"
Decision cards	`body_blocks_json` blocks with stable IDs	Prepare now	Add predictable anchors such as `ldd-30-decision-17` so comments and signals can target them later.
Status chips	`content_signal_blocks.kind` + `resolution_state`	Refine	Do not store only "yellow chip." Store meaning: question/open, risk/active, decision/accepted, uncertainty/open, etc.
Change history	`document_revisions`	Fits	Human-curated page history can map to revision summaries later; wiki can also preserve raw edit snapshots.
Claude LDD lock	`project_locks` + MCP access policy	Needs enforcement	The data model exists; before migration, prove tools enforce propose-vs-edit permissions.
Watercooler	`channels` + `messages`	Fits	The wiki's channel model is directly compatible with Barndo's discussion layer.
Reviewer scorecards	`scorecards`	Fits	The wiki prototype explicitly preserves the Barndo-style per-AI scorecard band.

What This Changes In The LDD UI Plan

Keep the plan

Category-based LDD navigation, page-level lifecycle dots, status chips, and structured history are still the right V2 direction.

Make it migration-shaped

When adding chips or special blocks, include stable IDs and semantic data. A future importer should see data-signal-kind="question" and data-resolution-state="open", not just a CSS class named yellow.

Do not collapse the axes

A block can be a decision and still be pending review. A block can be a risk and be resolved. The wiki model is stronger than a single color chip, so the V2 UI should preserve that nuance.

Recommended Bridge Work

Current pilot

The first V2 bridge pass is active on LDD-29 Gym Systems and LDD-30 Mech Core. These pages now read from site/assets/ldd-index.json for category, wiki slug, page lifecycle, stable decision IDs, semantic chips, and revision history.

Create a sidecar LDD index for category, page lifecycle, audience, source file, and future wiki slug. Status: active for all 30 LDDs, with richer pilot metadata for LDD-29 and LDD-30.
Use the index to render category-based sidebar groups in the static site. Status: first pass active in the shared sidebar.
Pilot semantic chips on LDD-29 and LDD-30 with stable block IDs. Status: active on both master-strategy pages.
Add status/history tables in HTML now, but keep the row structure close to future document_revisions.
Do not edit canonical Markdown frontmatter yet unless David explicitly overrides the Claude LDD lock.
Later, build an importer that creates wiki projects, topics, documents, document revisions, signal blocks, channels, and scorecards from the static corpus.

Migration Gates

Gate	Status	What must be true before Barndo migrates
Schema fit	Good	Current wiki schema already has the major Barndo-shaped entities.
Import pipeline	Missing	Need a repeatable script from Barndo source/site into Pocketbase records.
Access control	Partial	Project lock exists in data; MCP/web edit enforcement must be proven.
Block targeting	Prepare	V2 LDD pages need stable block IDs for comments/signals/proposals.
Operational deployment	Not proven	Need live Unraid/Docker deployment and MCP/API validation before canonical use.

Bottom Line

The wiki project and Barndo V2 are moving in the same direction. Barndo should stay static now, but the UI changes should be implemented as if the wiki migration is real later: structured navigation, stable page IDs, semantic signal blocks, clean attribution, and a clear distinction between lifecycle, signal kind, and resolution state.