Draconai Documentation

dd_id_8ec9a00bfd

Home

Table of Contents

This folder contains documentation for the app in server/var_www/. Two Symfony apps: one for frontend, one for backend, connected via API. Using docker-compose.

Project Principles

  • This project is documentation-first. Documentation is the source of truth.
  • This project is test-driven. As much as possible should be covered by tests.
  • docs/rulebook/ is the source of truth; DevDocs (devdocs) are WordPress-based pages.

DevDocs vs rulebook

Rulebook

  • docs/rulebook/ is the primary authority for rules/contracts.
  • docs/devdocs/ is the source of truth for DevDocs page content.
  • The DevDocs WordPress stack (themes/plugins/config) lives at server/var_www/devdocs_wp/.
  • Update docs/devdocs/ first, then publish via python3 scripts_local/publish_devdocs.py.
  • Theme/plugin changes must be deployed via the same sync (repo server mirror) so the server gets the updated files.

Transition Plan

  • See transition_plan_devdocs.md for the detailed migration plan to the seven-section documentation structure.
  • fixme remove

Codex Instructions

This is an instruction file only for Codex to read on each start up. Follow the instructions:

  • The highest-priority behavioral contract is docs/devdocs/ai_rulebook.md. It overrides any other behavioral guidance if conflicts exist.
  • "+ old" is just for reference.
  • server/var_www is where the current app is located. This app is entirely generated by codex.
  • docs/rulebook/ for the app is the rulebook. Read all of it now to get up to speed.
  • Prefer small, incremental steps. Split larger tasks into smaller units and execute them one by one.
  • when writing or changing code, add comments that explain in detail what is being done and why, and include references to relevant documentation with explicit file locations. If helpful, add identifiers to documentation sections so they can be referenced by id.
  • always update the documentation AND the HTML documentation output whenever changes are made.
  • always deploy to the server after making changes (rsync deploy, sync docs).
  • Codex must not commit or push; git usage is reserved for the user.
  • Output verbosity: use high detail. Always report every file touched, commands run, and summarize key diffs.

Work Queue System (Codex)

System

  • Instructions are stored as individual numbered files in codex_work_queue/.
  • New tasks are created in codex_work_queue/1. new/.
  • When the doer starts a task, it is moved into codex_work_queue/2. current/.
  • Each instruction is a single file (e.g., 001_...md) so tasks can be executed one-by-one in order.
  • A 3. done/ subfolder exists under codex_work_queue/ for completed instructions.
  • Workflow:
  • Process the lowest-numbered file first.
  • Execute only that instruction.
  • When finished, move the file into codex_work_queue/3. done/.
  • After completing a task, the doer must verify the task is actually completed.
  • Work on one task at a time only; do not start a second instruction until the current one is completed and moved to 3. done/.
  • Execute tasks in strict chronological/consecutive order (lowest numbered first, no skipping).
  • Do not modify or write to the .ssh folder. Stay inside the repo directory and use the sync helper script for server access.
  • When the queue is empty and any DevDocs inputs changed (docs content, theme, or plugins), automatically sync the docs to WordPress.
  • Do not reorder files; add new instructions as new numbered files.