This article preserves the full history and reasoning behind Mission Control and the PassLee Control Centre, migrated from conversation history so it survives independently of any single chat session.
Why this exists
PassLee is Lee’s driving instructor business serving Worcester, Pershore, and Droitwich, with a public marketing site at passlee.com. This Control Centre (knowledge.passlee.com) is a deliberately separate, private, internal system – not a public website, not a blog, not a traditional knowledge base plugin. Its purpose is to hold project decisions, technical knowledge, task tracking, and collaboration history between Lee and AI assistants in one durable place, so that knowledge does not remain trapped inside conversation history and disappear when a chat ends or grows too large to work in.
How it evolved: every completed phase
Phase 1 – Foundation
A brand-new WordPress install was configured as a private internal system: site title, tagline, UK timezone/date formats, search engines discouraged from indexing, default theme (Twenty Twenty-Five) kept, no plugins installed beyond what WordPress required. Nine blank placeholder pages were created (Dashboard, Project Bible, Homepage Blueprint, SEO Tasks, Technical Register, Competitor Intelligence, Decision Register, Change Log, AI Knowledge), gathered under one “Knowledge Base” navigation menu, with Dashboard set as the homepage.
Phase 2 – Core Architecture
Six Custom Post Types were registered entirely in code (no CPT plugin): Task, Decision, Change, Technical Note, Competitor, and Knowledge Article, each with its own archive and clean rewrite slug (/tasks/, /decisions/, /changes/, /technical/, /competitors/, /knowledge/). Navigation was updated to link to these archives instead of the placeholder pages, which were later deleted. One example record was created per type to prove the architecture, and a “System Architecture” Knowledge Article was started as the technical reference that has been extended in every phase since.
Phase 3 – Structured Data Layer
Every content type gained proper metadata fields via native post meta and hand-built meta boxes (no ACF/Meta Box/Pods): Tasks got Status/Priority/Category/Target & Actual Completion Date/Owner; Decisions got Date/Status/Impact/Related Task; Changes got Date/Type/Related Task; Technical Notes got System/Status; Competitors got URL/Strength/Threat/Notes; Knowledge Articles got Category/Version/Last Reviewed. Useful admin list columns were added for each type.
Phase 4 – Relationship Engine
Native many-to-many relationships were added between all six content types, stored as arrays of post IDs in post meta. A single function, passlee_get_related_posts(), resolves a record’s complete relationship graph by combining its own forward links with reverse links discovered on other records – so a connection made from either side is visible from both, without duplicate data entry. A read-only “Related Content” panel and a front-end “Related Items” block were added, both server-rendered with no AJAX.
Phase 5 – Editor Experience & Data Integrity
Required-field validation (soft-block: incomplete Publish attempts revert to Draft with a notice, nothing is lost), smart defaults for new records, non-blocking duplicate-title warnings, native Created/Updated timestamps, an optional Revision Summary field, a Record Health completeness score, and Quick Navigation links (Previous/Next/Archive/Dashboard) at the top of every edit screen.
Phase 6 – Project Intelligence Layer
The static Dashboard page became fully live: a the_content filter replaces its stored placeholder content at request time with data generated from the six content types – Current Tasks, Recent Decisions/Changes, Current Technical Notes, all Knowledge Articles, a Statistics panel, a Priority panel, a Relationship Summary, Recently Updated records, and a System Health panel (including a Broken Relationships integrity check). All data is gathered once per request and cached in a static variable for performance – no external caching plugin.
Phase 7 – Mission Control
A new singleton Custom Post Type, Project Status, was introduced as the single source of truth for “where are we, what are we doing, what’s next” – Current Phase, Objective, Milestone, Overall Completion, Project Health, Target Completion, Current Sprint, Sprint Goal, Current Focus, and a Roadmap (stored as one Label|state-per-line textarea for simplicity, since WordPress has no native repeater field). It was deliberately kept isolated from the Phase 4 relationship engine so Mission Control’s data source could never be disturbed by unrelated changes. The Dashboard was restructured around it: Project Status card, horizontal Roadmap, Current Sprint, Recently Completed, Next Up, with everything from Phase 6 demoted below a divider.
Phase 8 – Design System
A pure visual redesign (no new data): the dashboard was rebuilt to feel like an application (Notion/Linear/GitHub Projects) rather than a WordPress page – exactly three font sizes, spacing over borders, one shared card style, a connected-milestone-card roadmap, equal-height status cards, and the whole of Phase 6’s detail collapsed into a native, closed-by-default <details> accordion. No JavaScript, no animation.
Phase 9 – Visual Command Centre
A further pure visual layer: a full-bleed PassLee-blue application header (“PassLee Control Centre / Mission Control”), a light-grey app-shell background, a circular SVG progress ring in the hero, horizontal progress bars (Overall/Sprint/Knowledge Growth/Project Health), category-colour accents on status cards (website blue, knowledge teal, technical purple), a larger-node connected roadmap, a new “Today’s Mission” card surfacing the single most urgent open task, four Project Health signals (Overall Health, Momentum, Risk, Confidence – the last three computed heuristically from existing task and relationship data, documented transparently rather than fabricated), a chronological Activity Timeline replacing the old two-column Recent Activity, native Quick Action links to each content type’s “Add New” screen, and a reserved empty “Insights” placeholder for future AI-generated summaries.
Design philosophy, consistently applied
- Native WordPress only, never a plugin, for every content type, field, relationship, and validation rule.
- Clean architecture prioritised over speed at every decision point.
- No JavaScript frameworks; interactivity (accordions, navigation) uses native HTML wherever possible.
- Every dashboard number is calculated from real records at request time – nothing is hardcoded or manually maintained.
- Design changes (Phases 8-9) never altered the underlying data model – visuals and data have stayed strictly separate.
Future vision
The Roadmap (as of this migration) lists Search, Migration, Timeline, and AI Layer as the remaining planned work, alongside the newly active Knowledge Preservation Project – moving accumulated conversational knowledge into permanent, structured, cross-linked records like this one, so the Control Centre becomes the durable memory of the whole PassLee project rather than a project-management tool that sits alongside a separately-remembered history.
User feedback that shaped Phases 8-9 (migrated from ChatGPT transcript)
Two pieces of direct user feedback, given between phases rather than at the start of a phase, are worth preserving as the actual reasoning behind the Phase 8/9 redesign work – not just its outcome:
- Before Phase 8: “the front page needs to be more graphical and interesting, at the moment it’s just a sea of text, for a human being this is not the best.” This is what motivated treating Phase 8 as an application-style redesign rather than a documentation layout.
- After Phase 9: the dashboard was “much better” but “still looks too white and clinical,” and the Quick Action buttons had unreadable text that blended into their own background. The button issue was a genuine CSS specificity bug (a general link-colour rule outranking the button’s own class), fixed and documented in the “Quick Actions button text-contrast bug” Technical Note. The “too white and clinical” feedback remains open and should inform any future visual pass.
How the AI-assisted workflow itself evolved
The Knowledge Preservation Project’s own method changed partway through: early sessions had ChatGPT relaying what it remembered from its conversations with Lee, which was recognised as inherently selective. The project moved to treating exported ChatGPT transcripts as primary evidence instead, with Claude reading them directly rather than working from a second AI’s summary of them – see the “Use the raw ChatGPT transcript directly” Decision record for the full reasoning.