Blog drafts¶
Working drafts for the chunkydragon.com blog. Nothing here is published. These live in the docs tree so they're versioned alongside the code they describe and easy to keep accurate as the project changes.
Status¶
All posts in this folder are drafts. The editorial workflow is:
The live docs draft site is password-gated during this draft phase.
- Drafts authored here, in-repo, alongside the code/docs they reference.
- Editor (separate person) polishes voice, fact-checks, fills CTAs.
- Editor publishes to Hashnode backing
blog.chunkydragon.com(see infrastructure ticket below). - Editor cross-posts to dev.to with canonical URL pointing at
blog.chunkydragon.com.
Infrastructure setup (DNS, Hashnode publication, cross-post automation, RSS, newsletter) is tracked separately.
Posts (educational tracks)¶
Start with The AI fluency trail guide. It is the overview map for the whole catalog: the personal eight-stage journey from "AI as a better Google" to an autonomous build pipeline, with links into the deeper posts below.
The catalog is organized as a learning path, not a publishing queue. One overview post leads sixty track drafts grouped into six named tracks, ordered so a newcomer absorbs the mindset first, sees it applied to the product and the engineering, and reaches the compounding-case capstone last. Read top-to-bottom for the full course, or jump to the track that matches what you came for.
The track order is the recommended reading order:
- Track A -- The mindset. How this project thinks: privacy-by-design, AI-as-personality, honest boundaries around AI-built code, and the builder's-eye onboarding stance everything else leans on.
- Track B -- Designing the product. The role/device architecture and the games built on it -- what gets built and why.
- Track C -- AI-first engineering. The codemap annotation/test/log control plane and the metadata-as-infrastructure thread.
- Track D -- Building with AI. The builder's on-ramp: idea -> repo -> UI spec -> mockups -> build loop.
- Track E -- The orchestrator evolves. The orchestration internals: lifecycle, review guardrails, detection, and failure recovery.
- Track F -- Forward-looking. The capstone thesis that argues the compounding case.
Every track draft in this folder is slotted into one of these six tracks in reading order. The overview post sits above the tracks as the recommended first read. Posts are referenced by title and relative link rather than by a frozen number, because the catalog grows.
Track A -- The mindset¶
Start here. These posts establish the worldview every later track assumes: profiles are devices, not people (the load-bearing privacy rule the whole catalog hangs on); AI opponents are personalities, not optimizers; and a backend developer can drive an AI-built frontend only by staying honest about what he has and has not read. Read Device profiles, not user accounts first -- the per-game posts in Track B cross-link it as the source of the "kid-safe by design, not by settings" rule.
After the privacy rule, Why build it this way: the marginal cost of a game makes the economic case the rest of the machinery serves -- the bet that drives a new game's cost from a phase of work down to a designer-in-the-loop afternoon. The track then turns from worldview to working habits: Read before you write is the pattern behind the patterns (look before you generate), Don't fold it in teaches the single discipline of deferring a second problem into its own ticket, and Your first runnable line drops from mindset to the keyboard -- the literal sequence to clone the repo, run it, file a ticket, and watch it merge.
| Post | Audience | Platform of record |
|---|---|---|
| Device profiles, not user accounts | Privacy-conscious parents, ethical-tech devs | Hashnode -> cross-post LinkedIn |
| Why build it this way: the marginal cost of a game | Builders weighing AI-assisted development | Hashnode -> cross-post dev.to |
| AI personalities, not optimizers | Board game families | Hashnode -> cross-post Substack |
| Shipping a React client I have not read | Backend devs, indie hackers | Hashnode |
| Read before you write | Developers learning to build with AI | Hashnode -> cross-post dev.to |
| Don't fold it in: file the second problem | Developers learning to build with AI | Hashnode -> cross-post dev.to |
| Your first runnable line | Backend devs, indie hackers | Hashnode -> cross-post dev.to |
Track B -- Designing the product¶
With the mindset in place, this track shows what the project actually builds. It opens with the systems foundation -- the Four-role WebSocket protocol whose role-based view filtering is the mechanism behind the privacy rule from Track A -- then walks the per-game cluster, simplest game first. Each per-game post picks one game from the catalog and carries the privacy-by-design rule forward into the design choices that game forced, cross-linking Device profiles, not user accounts and AI personalities, not optimizers. Two more systems posts sit alongside the protocol: Design for the flakiest client in the room takes the TV browser -- the weakest device in the room -- as the constraint that shapes reconnection and server authority, and One engine, two information modes shows how the same engine drives a perfect-information game and a hidden-information one purely by switching the role view filter.
The catalog now spans six games -- Memory Match, Bluff, Werewolf, and Dice Room from the completed phases, plus Battleland and Texas Hold'em landing in the current Phase 7 -- per ROADMAP.md, which marks Phases 1-6 complete and Phase 7 (Battleland + Texas Hold'em) as the current phase. The per-game cluster runs simplest-first and now covers all six: Memory Match for pre-readers, a game built on lying, Werewolf without a moderator, then a fair die is a product decision for Dice Room, Battleland: the first game that trains its own opponent, and the equity panel is the AI for Texas Hold'em. Two posts close the track at a higher altitude: Bring your own key on adding an LLM advisor without betting the product on one model, and When the algorithm depends on the game, which steps back across the whole cluster to argue that the right hidden-information algorithm is a function of the game's structure.
| Post | Audience | Platform of record |
|---|---|---|
| Four-role WebSocket protocol | Backend / systems devs | Hashnode -> cross-post dev.to |
| Design for the flakiest client in the room | Architecture / systems devs | Hashnode -> cross-post dev.to |
| One engine, two information modes | Backend / systems devs | Hashnode -> cross-post dev.to |
| Memory Match for a 5-year-old who can't read yet | Parents of young kids, early-childhood educators | Hashnode -> cross-post Substack / LinkedIn |
| A game built on lying, with no chat panel | Card-game players, social-deduction folks | Hashnode -> cross-post dev.to |
| Werewolf without a moderator (and without a chat panel) | Social-deduction players, board game families | Hashnode -> cross-post Substack |
| A fair die is a product decision | Developers learning to build with AI | Hashnode -> cross-post dev.to |
| Battleland: the first game that trains its own opponent | Game-AI curious developers | Hashnode -> cross-post dev.to |
| The equity panel is the AI | Developers, AI-product builders | Hashnode -> cross-post dev.to |
| Bring your own key | Developers, privacy/cost-curious | Hashnode -> cross-post dev.to |
| When the algorithm depends on the game | Developers, game-AI curious | Hashnode -> cross-post dev.to |
Track C -- AI-first engineering¶
This is the inside-baseball track: the control plane that makes the codebase legible to an AI agent. It starts with the two foundations -- Code comments written for the robot, not the human (the codemap: annotation and risk system) and The test that knows what it is (the test taxonomy and log-aligned UIState dump) -- then shows how the same pattern reaches UI design in When layout taste becomes a test: a recurring landscape-layout judgment becomes a written lens and an opt-in geometry guard. From there the track situates the control plane against the published literature, walks the "shrink the codebase safely" payoffs (library swap, decomposition, dedup), extends each foundation into observability and history, and closes on project memory: ordinary artifacts become agent infrastructure once they are typed, local, and mechanically searchable. It sits after the product track because it is the most inside-baseball thread in the catalog and reads best once the games have made the project concrete. Inside the observability-and-history stretch, Store the moves, not the board makes the case that the action log -- recorded moves replayed to reconstruct state, not per-move snapshots -- is the durable record the logging and project-memory posts both lean on. Find every surface related to X extends The project that remembers itself from ticket and run-record prose to the code-doc capability graph: one closed capability vocabulary carried in both codemap: blocks and doc frontmatter, generated capability-hub pages that join tagged docs to annotated code units, and semantic retrieval that now ranks doc and code metadata alongside the project's own history. The run record that grades itself then follows the same memory corpus in a different direction, showing how the ticket and run-record pair became predicted-vs-actual training feedback. A three-post AI audit trail series then closes the track: What an AI researcher wants from a dev loop translates SFT, preference learning, and RLVR into what each actually wants from a real dev loop; Building an audit trail for AI-assisted development is the builder's-eye account of capturing the trajectory triple -- context, decision, outcome -- in a store deliberately kept outside git; and Why this project is a strong AI training substrate synthesizes the whole control plane into the case that this repo can measure whether an agent understood the project before it acted, then names the game-authoring flywheel that could turn verified game builds into better future authoring attempts.
| Post | Audience | Platform of record |
|---|---|---|
| Code comments written for the robot, not the human | Developers, AI tooling | Hashnode -> cross-post dev.to |
| The test that knows what it is | Developers, AI tooling | Hashnode -> cross-post dev.to |
| When layout taste becomes a test | Developers, AI tooling, UI builders | Hashnode -> cross-post dev.to |
| What the literature got to first (and the parts we made mandatory) | Developers, AI tooling | Hashnode -> cross-post dev.to |
| Let the library carry the proof | Developers, AI tooling | Hashnode -> cross-post dev.to |
| The refactor the annotations made safe | Developers, AI tooling | Hashnode -> cross-post dev.to |
| Derive It, Don't Stamp It | Developers, AI tooling | Hashnode -> cross-post dev.to |
| Trimming the duplication an AI cannot see | Developers, AI tooling | Hashnode -> cross-post dev.to |
| The logs already knew the order | Developers, AI tooling | Hashnode -> cross-post dev.to |
| Store the moves, not the board | Developers, AI tooling | Hashnode -> cross-post dev.to |
| Watching code risk trend over time, with no metrics datastore | Developers, AI tooling | Hashnode -> cross-post dev.to |
| The project that remembers itself | Developers, AI tooling | Hashnode -> cross-post dev.to |
| Find every surface related to X | Developers, AI tooling | Hashnode -> cross-post dev.to |
| The run record that grades itself | Developers, AI tooling | Hashnode -> cross-post dev.to |
| What an AI researcher wants from a dev loop | Developers, AI tooling | Hashnode -> cross-post dev.to |
| Building an audit trail for AI-assisted development | Developers, AI tooling | Hashnode -> cross-post dev.to |
| Why this project is a strong AI training substrate | Developers, AI tooling | Hashnode -> cross-post dev.to |
Track D -- Building with AI¶
A builder's-eye on-ramp aimed at a wider audience than Track C. It is a four-post series that walks the full pipeline a non-frontend builder lives: From an idea in a chat window to a repo the robot can build (idea -> git repo -> orchestrator), then Describe the screen, don't draw it (the UI-spec prompt playbook) (a screen description becomes a frozen, buildable UI spec), then Make it real before you build it (throwaway HTML mockups) (render that spec into HTML you can actually see), and finally Tickets in, a game I can play out (the orchestrated build-and-feedback loop) (what shipping through the orchestrator feels like day to day). It stays at the builder's altitude and defers the machine internals to Track E. Two further posts extend the loop past the four-step series into what it produces over time: The orchestrator that drafts its own backlog on the soft-checks and periodic passes that let the system file its own follow-up tickets, and From surprise to rule to skill on how a surprise in one run graduates into a durable rule and then a reusable skill -- the agent contract teaching itself.
| Post | Audience | Platform of record |
|---|---|---|
| From an idea in a chat window to a repo the robot can build | Developers, indie hackers, solo builders | Hashnode -> cross-post dev.to |
| Describe the screen, don't draw it (the UI-spec prompt playbook) | Non-designer builders, backend devs, solo founders | Hashnode -> cross-post dev.to |
| Make it real before you build it (throwaway HTML mockups) | Non-designer builders, backend devs, solo founders | Hashnode -> cross-post dev.to |
| Tickets in, a game I can play out (the orchestrated build-and-feedback loop) | Solo founders, backend/systems devs, non-frontend builders | Hashnode -> cross-post dev.to |
| The orchestrator that drafts its own backlog | Developers, AI tooling | Hashnode -> cross-post dev.to |
| From surprise to rule to skill | Developers, AI tooling | Hashnode -> cross-post dev.to |
Track E -- The orchestrator evolves¶
The machine internals the builder's-eye series keeps pointing at. It opens the lifecycle box with The orchestration lifecycle: from phase to ticket to retro, opens the review box with Review surfaces and the AI-first guardrails and Risk-routed review: spending human attention where it earns its keep (routing scarce human review to the changes whose risk signals earn it), then turns to the failure side: Spiral-detection watchdog (catching a busy-but-spinning run before it fires) and When a stage fails: what is mechanical and what is the LLM? (the diagnosis-and-retry recovery loop, the diagnosis-side companion to the watchdog). Risk-routed merge resolution applies the same routing lens to merge conflicts: deterministic .gitattributes drivers first, default-on gated AI second, and a human only when those rungs cannot safely finish. Its through-line is that the lifecycle is governance, not autonomy: every stage exists to make an autonomous run debuggable by a human after the fact. From there the track follows the orchestrator as it evolves. How a ticket picks its brain shows the engine-policy layer that maps a ticket's semantic tier to whichever model provider is current, so the lifecycle is not welded to one vendor. Anatomy of a ticket: one contract, one run record, every field opens the ticket-contract thread that the brain-picking post and the Tempo arc both rely on: one schedulable contract paired with one run record. Then the Tempo arc: Meet Tempo introduces the Go reimplementation of the dispatcher, Two rewrites, one strategy tells how a never-shipped Python design doc set the strategy the Go binary cashed in, Parity-first is the discipline for replacing a build system you depend on without trusting the rewrite, and The orchestrator leaves home follows the loop from a workflow welded into one repo to a binary you can install on a project of your own.
| Post | Audience | Platform of record |
|---|---|---|
| The orchestration lifecycle: from phase to ticket to retro | Developers, AI tooling, orchestration engineers | Hashnode -> cross-post dev.to |
| Review surfaces and the AI-first guardrails | Developers, AI tooling, orchestration engineers | Hashnode -> cross-post dev.to |
| Risk-routed review: spending human attention where it earns its keep | Developers, AI tooling, orchestration engineers | Hashnode -> cross-post dev.to |
| Spiral-detection watchdog | Developers, AI tooling | Hashnode -> cross-post dev.to |
| When a stage fails: what is mechanical and what is the LLM? | Developers, AI tooling, orchestration engineers | Hashnode -> cross-post dev.to |
| Risk-routed merge resolution: let git handle the boring conflicts | Developers, AI tooling, orchestration engineers | Hashnode -> cross-post dev.to |
| How a ticket picks its brain | Developers, AI tooling, multi-provider | Hashnode -> cross-post dev.to |
| Anatomy of a ticket: one contract, one run record, every field | Developers, AI tooling, orchestration engineers | Hashnode -> cross-post dev.to |
| Meet Tempo: when the orchestrator becomes a Go binary | Developers, orchestration / AI tooling | Hashnode -> cross-post dev.to |
| Two rewrites, one strategy | Developers, AI tooling | Hashnode -> cross-post dev.to |
| Parity-first: replacing the system that builds your software | Developers, orchestration engineers | Hashnode -> cross-post dev.to |
| The orchestrator leaves home: from welded-in workflow to installable binary | Developers, solo builders | Hashnode -> cross-post dev.to |
Track F -- Forward-looking¶
Forward-looking. This track collects honest research directions and the points where scoped directions turn into shipped machinery, then closes on the thesis the whole machine exists to make. The directions come first: CFR for 6-max Hold'em on the poker AI the catalog has designed but not implemented; How cheap can a new game get? on the rulebook-PDF-to-engine experiment that would test the central economic bet; What a numeric risk dashboard would have to be on the now-shipped ruler-aware codemap dashboard; The action log is an analytics engine waiting to happen on turning data the project already records into observability it has not built yet; How do you test an orchestrator whose job is to call an LLM? on proving the orchestration spine with fakes; and Sharing the orchestrator upstream on the line between a reusable template and the project that grew it. Then the capstone: The cross-game compounding flywheel argues the case the whole machine exists to make: an AI-orchestrated catalog gets better in two directions at once -- every shipped game makes the next one cheaper, and every lesson learned is folded back into the already-shipped games via the retro, so quality is roughly monotonic across the library instead of stratified by build date. It also points to the adjacent game-authoring flywheel: verified game builds can become eval and training material for the next authoring attempt. It re-teaches none of the internals; it is the thesis.
| Post | Audience | Platform of record |
|---|---|---|
| CFR for 6-max Hold'em: the poker AI this catalog hasn't built yet | Developers, game-AI curious | Hashnode -> cross-post dev.to |
| How cheap can a new game get? The rulebook-PDF-to-engine experiment | Backend devs, solo builders | Hashnode -> cross-post dev.to |
| What a numeric risk dashboard would have to be | Developers, AI tooling | Hashnode -> cross-post dev.to |
| The action log is an analytics engine waiting to happen | Developers, AI tooling, analytics | Hashnode -> cross-post dev.to |
| How do you test an orchestrator whose job is to call an LLM? | Developers, orchestration engineers | Hashnode -> cross-post dev.to |
| Sharing the orchestrator upstream: template vs. the project that grew it | Developers, orchestration / AI tooling | Hashnode -> cross-post dev.to |
| The cross-game compounding flywheel | Developers, AI tooling, builders | Hashnode -> cross-post dev.to |
Cadence, cross-posting, and launch order¶
Cadence target: one post every 10-14 days. Hashnode is the platform of record for every post; the Platform of record column above records where each draft cross-posts after it lands (dev.to for the developer-facing posts, Substack and LinkedIn for the family- and parent-facing ones).
Launch order is not the same as track order. Lead the launch with Device profiles, not user accounts: it establishes the rule every later post leans on -- no person-shaped profile fields, no chat panel, no friend list, "kid-safe by design, not by settings" -- and the per-game cluster cross-links it as the source, so shipping it first means those posts can publish without dangling forward-references. Its contrarian "no chat panel, ever" framing and enumerated list of deliberately-uncollected fields are also the most Hacker-News-shaped writing in the queue, and the LinkedIn cross-post seeds B2B / classroom-pilot conversations early.
Spiral-detection watchdog was originally slated to lead but moved back a few slots once a prior-art scan at the bottom of that draft turned up ~10 public sources covering the same heuristics. It still earns an early slot for tech credibility and dev.to reach, but it cannot carry the launch on a "defensive publishing" framing the draft itself undermines.
Conventions for drafts in this folder¶
- One file per post. Slug matches the title.
- Top of each draft: a short STATUS admonition (audience, platform, what the editor needs to fill in).
- Code examples and stat numbers reference real files in this repo -- don't invent. If a number isn't grounded, leave a `` marker.
- First-person lived experience must be real, not invented. Do not fabricate timelines, sensory or emotional detail, "what surprised me" or "when it clicked" narrative, or any other experiential claim that did not happen. Every first-person claim must be grounded in either verifiable repo artifacts (metrics, commits, files, run records) or the author's actual stated experience; when a post needs narrative color the author cannot ground, omit it or use a non-experiential voice. The grounding-audit tickets flag existing violations against this standard.
- Don't link to internal repo paths from the published version -- convert them to public GitHub URLs at publish time.