Archives: Decisions

Earlier in the Knowledge Preservation Project, ChatGPT relayed what it remembered as important from its own conversations with Lee. This was recognised as inherently selective and unreliable for a preservation effort – ChatGPT (and Claude) cannot honestly guarantee recalling every discussion, dead end, or decision from memory alone. The exported HTML transcript is the primary evidence, so from this point AI-assisted migration work reads transcripts directly rather than relying on a second AI’s recollection of them. ChatGPT’s role shifts to quality control, review, and planning once a transcript has been handed to Claude for migration.

Rather than hardcoding absolute paths for either the staging or production environment, FastPixel’s cache path resolution was changed to use WP_CONTENT_DIR dynamically. This allows the same codebase to work correctly whether cloned to staging or run on production, preventing a repeat of the hardcoded-path bug found during migration.

Avada’s Dynamic CSS pipeline proved unreliable for injecting the scoped mobile-only fix needed for the header/hero display bug. A must-use plugin injecting plain scoped CSS at a fixed breakpoint was used instead, since it loads deterministically on every request regardless of Avada’s own CSS compilation state.

WordPress has no clean native way to fully refuse a save from the post editor without JavaScript. Instead, if a Task/Decision/Change/Technical Note is missing a required field when set to Publish, it is silently saved as Draft with an admin notice explaining what's missing – no data is lost, and the record simply can't go live incomplete.

The Dashboard page's stored content is a placeholder only; a the_content filter (priority 20) completely replaces it at request time with live, generated markup. This avoids touching the Twenty Twenty-Five theme's template files or requiring a child theme, at the cost of not being able to restyle the theme's own header/navigation/footer chrome directly (footer is hidden per-page via a scoped inline style instead).

Roadmap items, their order, and their state (completed / current / planned) are all stored in a single textarea meta field (status_roadmap), one 'Label|state' pair per line. Line order is roadmap order. WordPress has no native repeater UI, so this keeps the whole roadmap editable as one ordinary field rather than requiring custom admin UI or a plugin.

Project Status (the singleton record driving Mission Control) has its own dedicated meta box and its own Sprint Tasks checklist, deliberately separate from passlee_relationship_map(). This means changes to the six core content types' relationships can never accidentally break Mission Control's data source.

Each relationship field (e.g. rel_decisions on a Task) stores a plain array of related post IDs as a single post meta value. A record's full relationship graph is computed on read by combining its own forward links with reverse links discovered on other posts – so linking from either side makes the connection visible from both, without a database migration or custom table.

Custom Post Types (Task, Decision, Change, Technical Note, Competitor, Knowledge Article, Project Status) all store their fields as native post meta with hand-built meta boxes, rather than ACF, Meta Box, or Pods. This keeps the Knowledge Base free of plugin dependencies and fully portable via standard WordPress export/import.

This is a placeholder decision record used to test the Decision architecture. Replace with a real decision.