yaoireporter
Build log

the receipts.

everything built, broken, and fixed in service of organizing an unconscionable amount of yaoi.

6Weeks logged
43Milestones
700kWords ingested
6Features shipped
37Bugs fixed
Phase A — The Yaoi Trap 50%
Every message wanders into the trap and none of them wander out — ingestion, the reporting API, and the alerts that go off when one nearly escapes.
5 of 10 features shipped see the lab
May 19 – May 25, 2026 Week 6

the receipts came due

RuntimeNarrative Systems
5 bug fixes
A full audit of the bot uncovered about forty places where the code and the docs had stopped speaking to each other, and the first round of repairs landed: a stronger audit trail, the stitching war finally getting its own logbook, and the location lookup learning to point at the right rooms. Universes, not pairings, came into focus as what actually carries the story.
🔧A structural audit of the bot was run end-to-end — about forty places where the code and the docs had stopped speaking to each other were catalogued, severity-ranked, and queued for repair.
🔧A centralized channel model landed in the database — registration, alerts, and admin channels now live as proper rows with strict singleton enforcement, so a future Discord rename can never silently break two commands at once again.
🔧A long-standing config oddity on the alerts channel was quietly resolved — three fields carrying residual misconfiguration from an earlier setup were swept into a clean infrastructure marker, and the location-type scheme was canonicalized in the docs.
🔧The bot got more honest about its own failures — when something goes wrong deep in the pipeline, it now leaves a proper queryable record of what broke and where, instead of a quiet warning in a log file no one reads.
🔧A safety net was added underneath the audit trail itself — if the database is unreachable when a failure happens, the record now goes to a small file on disk and replays the next time the bot comes up clean.
🎭The stitching war finally got a logbook — every time the bot decides whether a Tupperbox burst is one new reply or part of an existing one, it now records *why*. The answer is finally just there.
🔧The room-lookup command was quietly returning the wrong location for each pairing because of a flipped filter. Anyone using it was getting non-canonical answers and probably blamed the data. The data was fine; the question was wrong. Fixed.
🔧A subtle hole in the error-classification layer got closed — scene attachment failures were being swallowed before they could be classified, so they never showed up in the audit trail. They will now.
🎭A bigger shape came into focus while testing the location lookup — universes, not pairings, are what actually carry the story. A future session will redesign around that. Surfacing only because we tested everything, not just the first thing, is its own small win.
May 12 – May 18, 2026 Week 5

The Universe Layer, The Alert System & The Devlog

RuntimeAlertsAPIToolingWebsite
26 universes · 13 API endpoints · alert system live · devlog deployed · 15 messages recovered · 6 split scenes repaired · housekeeping pass · site moved to its own home
With ingestion stable, focus moved up the stack — a universe layer for organizing stories, a self-resolving alert system so the bot can speak, a deep bug hunt that sharpened the system's correctness, and a recovery pass that brought back every message the old catch-up bug had swallowed. The week closed with a housekeeping sweep and a build log to make all this invisible work finally visible.
🔧A universe layer was designed and built — 26 universes seeded with genres, descriptions, and story tags, so the same characters can appear across multiple storylines without duplicating data.
🔔The alert lifecycle system took shape — the bot can now speak. Ownership routing decides whether a failure goes to the admin or the writer, embeds explain what was seen versus expected, and alerts resolve themselves once the problem is fixed.
📡The API grew to 13 endpoints — universe library, character rosters, scoped character stats, and a diagnostic endpoint giving direct visibility into why any message failed.
🔧NPC support reached the finish line — webhook-based NPC characters now travel the full pipeline correctly, and a new guided !register_npc command lets either writer add one with no database access.
🔧A pair of hidden bugs was hunted down — one could have quietly accepted the wrong character, the other had been swallowing messages and splitting replies in two. Every lost message was recovered and every split scene stitched back whole.
🔭The biggest cleanup yet — 20 source documents consolidated to 12, and a housekeeping pass across every storyline that tidied scene names, corrected a stray attribution, and confirmed every multi-part turn is stitched as written.
✨The build log was born — a self-generating timeline that turns weekly notes into a styled page, now living at its proper home, yaoireporter.com, with live counters, a phase bar, and a one-command build-and-publish step.
May 5 – May 11, 2026 Week 4

The Rebuild — Recovery, 700k Words, and V1.1 Complete

RuntimeNarrative SystemsAPITooling
~700k words ingested · 25 scenes · 8+ bugs fixed · API live
The hardest week. A destructive AI editing pass had gutted the codebase; it was rebuilt from the ground up, three deep ingestion bugs were found and fixed, the entire corpus was backfilled, and V1.1 reached full completeness.
🔧The core ingestion stack was rebuilt from scratch — a destructive AI editing pass had replaced working code with stubs and broken signatures. Repositories, processor, resolvers, canonical logic, stitching, and the bot entry point were all restored.
🔧Three deep ingestion bugs were diagnosed and fixed — the interruption check queried the wrong table, thread_id was never stored, and duplicate detection checked the wrong log. Together they had caused messages to "blob" into giant malformed replies.
🔧The full historical corpus was backfilled — roughly 700,000 words across 25 scenes and 4 pairings, ingested chronologically, fully deduplicated, with correct narrative-turn structure and zero disruption to the writers.
🎭A breakthrough on Tupperbox history — instead of needing deleted trigger messages, writer identity was recovered from the character name carried in the webhook itself. A fully passive, deterministic path with no writer friction.
🔧V1.1 reached full feature completeness — multi-character Nitro attribution, ambiguity-safe Tupperbox resolution, scene lifecycle management, message edit and delete handling, bot-restart catch-up, and mixed Nitro + NPC webhook handling all live.
📡The read-only reporting API went live — eight endpoints exposing pairing, writer, character, and scene data, served publicly at api.caity.me. This unblocks the cowriter dashboard.
🔭Recovery discipline held throughout — systematic backups, a dedicated fix branch, and careful verification at every step turned a contaminated codebase back into a stable, documented system.
April 28 – May 4, 2026 Week 3

V1.1 — Mixed-Mode Ingestion, Scenes & First Analytics

RuntimeNarrative SystemsTooling
1,268 messages backfilled · scene model corrected · analytics v1
The system grew past pure ingestion. Mixed Nitro and NPC-webhook handling shipped, the scene model was corrected to match how stories are actually written, and the first narrative analytics layer came to life.
🎭Mixed-mode ingestion shipped — webhook-based NPCs can now post inside Nitro locations, resolved deterministically through an alias-to-character-to-owner chain, without compromising the Nitro path.
🔧Production backfill ran across two pairings — 1,268 historical messages ingested with perfect structural integrity, idempotent re-runs, and confirmed pairing isolation.
🎭The scene model was corrected — instead of fragile time-gap heuristics, a Discord thread is now the atomic scene. Deterministic, Discord-native boundaries with no artificial fragmentation.
🎭The first analytics layer came online — pairing signature analysis, narrative signal modelling, and cadence metrics measuring true cross-writer reply timing.
🔭The full documentation set was reconciled — schema, ingestion rules, runtime behaviour, and pairing config aligned under a single source-of-truth hierarchy, eliminating drift between intended and actual behaviour.
🔧A real-world edge case was formally captured — Nitro locations can contain webhook NPC messages, which became the defining feature work for the V1.1 cycle.
April 23 – April 27, 2026 Week 2

V1 Core — From Half-Built to Production-Ready

RuntimeNarrative Systems
V1 core 100% · 2 posting modes live · deterministic attribution
The ingestion system raced from roughly half-complete to a fully deterministic V1. Both posting modes went live, runtime bugs were hunted down, and the system crossed from "being proven" to "being used."
🔧Live runtime ingestion went fully operational — the system moved past manual inserts and test harnesses into processing real Discord activity in real time, persisting structured narrative data as it arrived.
🎭Both ingestion paths went live — Nitro profile messages fully operational, and Tupperbox webhook reposts working via deterministic trigger-to-webhook fallback correlation.
🔧Reply stitching matured — a bounded stitch window was introduced so replies reflect genuine conversational continuity rather than naive attribute matching.
🔧Pairing context began flowing end to end — pairing_id now propagates from location config straight through to discord_messages and ingestion_events.
🔧A run of real-world runtime bugs was hunted down and fixed — schema mismatches, missing-field constraint failures, and channel-to-location mapping errors.
🔧Multi-pairing support landed — forum-thread inheritance meant new threads inherit their parent channel's config automatically, with zero per-thread setup.
🔧V1 core reached completion — deterministic processing, configuration-driven behaviour, full audit logging, and a system that prefers rejecting a message over attributing it incorrectly.
April 19 – April 22, 2026 Week 1

Foundation — The Schema, The Seed World, The First Heartbeat

RuntimeNarrative Systems
19 tables built · 8 smoke tests passed · first live ingestion
The entire relational schema was built table by table, seeded with a test world, and proven alive. By the end of the stretch, a real Discord message had travelled the full pipeline end to end.
🔧The full relational schema was built across eight phases — 19 tables in all, from the configuration layer through raw ingestion, stitched replies, scenes, and milestone events. Every foreign key wired, every constraint in place.
🎭The core narrative model was locked in — the distinction between a raw Discord message, a stitched reply (one narrative turn), and a scene (a Discord thread). This separation is the foundation everything else stands on.
🎭A complete seed world was created — a test server, two writers, two characters, one pairing, and both a Nitro and a Tupperbox location, so the system had something real to run against.
🔧Four smoke tests proved the database alive — a single message moving end to end, a multi-reply scene, true message stitching, and the full Tupperbox path all passed.
🔧The Python ingestion engine was built — canonical filtering, writer and character resolvers, the stitching continuity engine, and the processor that orchestrates them.
🔧First live ingestion succeeded — a real Discord message was received by the bot, resolved, accepted as canonical, and stitched into a reply. The system was no longer a lab prototype.
🔧The Oracle VM environment came online — database connectivity, the repository layer, and the live bot connection all validated on the actual hardware.