Project Fragmentation

Improvement #13 proposes compiling STATUS.md nightly from memory files, treating memory as ground truth. But memory is derivative. Each project's actual source of truth is in its native tool: Loganix for Regulator backlinks, Google Sheets for WEM cluster mapping, WordPress for OHP, Google Docs for MyRV. When STATUS.md drifts, it's because projects are out of sync with each other, not because of cache staleness.

The assumed flow: memory files (ground truth) → sleep script → STATUS.md (compiled output). The actual reality: Loganix (ground truth for Regulator) → memory file (logged) → STATUS.md (compiled) → SESSION-CHECKPOINT (display). Each project type has a different sync path through different tools. When these fall out of sync, open-loops requires manual arbitration.

Recompiling STATUS nightly works as a surface fix and scales to current project count. But if new project types are added, it scales to O(projects) problems — each with its own sync path, each requiring its own parsing logic. The deep fix is a unified project hub that every project pushes status to, then open-loops pulls from hub rather than scattered STATUS files.

Mike is considering deploying OpenClaw for Bonsai coworkers, but this assumes the knowledge base is unified and transferable. It isn't. Each Bonsai project uses different tools: Regulator uses Loganix plus manual outreach. WEM uses Figma plus Sheets. OHP uses WordPress. MyRV uses Google Docs. Without documented playbooks, deploying team OpenClaw will copy the fragmentation to the team.

Each coworker would need to recreate tribal knowledge about their assigned project's tool chain. Dustin gets OpenClaw access but doesn't know: where's the source of truth? How do I check status? What's the next step? For a Regulator backlink campaign specifically, the answer spans Loganix cart, article writing, outreach email, and follow-up tracking — none of it documented as a reusable workflow.

The prerequisite: document 3–5 core project types as reusable playbooks, then deploy. Improvement #12 (backlink framework) is partially addressing this for one project type. A projects/bonsai/PROJECT-PLAYBOOKS.md would extend this to all of them. The sequencing matters: documentation before deployment, not after.

Session activity dips after blocking items accumulate. March 10 (OHP editorial blocked) → March 12 (Regulator follow-ups ready) → March 13 (audit + articles) → March 14 (light session) → March 15 (finance deep-dive). When urgent items pile without resolution, sessions shift to tangential work. The checkpoint correctly identifies urgency but doesn't explain why it's blocked.

The specific questions matter: Is the OHP editorial blocking on "Mike hasn't reviewed" or "waiting on something else"? Are the Regulator paid follow-ups unsent because there's a decision checkpoint, or because the draft just needs to go? Is Folicare pending because Mike is deciding, or because DNS clarification is needed first? Without the blocker reason, even light sessions become justifiable — "not sure how to unblock, so let me do finance work instead."

Improvement #14 (NEXT COMMAND) addresses execution clarity. This adds decision clarity. The [NEXT COMMAND] field in SESSION-CHECKPOINT should also reference the blocker condition — "blocked on: Mike approval," "blocked on: DNS change," "blocked on: decision between A and B." That distinction is the difference between a session that unblocks something and a session that defers it again.