yaoireporter
Build log

the receipts.

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

5Weeks logged
37Milestones
~700kWords ingested
28Bugs fixed
May 12 – 16, 2026 Week 5

The Universe Layer, the Alert System & the Devlog

Narrative Systems Alerts API Tooling Website
26 universes · 13 API endpoints · alert system live · devlog deployed
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 build log to track it all.
🌌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. A full-stack feature spanning schema, seeding, API, and docs.
🔔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 what was expected, and the alert_watchlist table backs self-resolving alerts.
📡The API grew to 13 endpoints — universe library, character rosters, scoped character stats, and a diagnostic ingestion-events endpoint giving direct visibility into why any message failed.
🧹The largest documentation consolidation yet — 20 source documents reduced to 12, with retired specs archived and a clean authority hierarchy established across the whole set.
🔬A subtle query-scoping bug was hunted down and fixed — the "pairing-scoped" alias lookup was never actually scoped to the character, which could have silently accepted the wrong one. The fix came once the deeper truth was understood: a pairing is exactly two leads, NPCs are global.
🎭End-to-end NPC ingestion was confirmed — webhook-based NPC characters now travel the full pipeline correctly, validated live against a test character in the sandbox.
💬The first bot-facing config command shipped — !register_npc, a guided Discord conversation that lets either writer register a new NPC with no database access required.
🛡️Alert ownership was made fully dynamic — a hardcoded user ID was removed so the responsible writer is now resolved at fire time, making the routing correct rather than correct-by-coincidence.
📓This build log was created and deployed — a self-generating timeline that turns weekly notes into a styled page, now live at devlog.yaoireporter.com through the same Cloudflare tunnel that serves the API, running as its own service so it survives reboots.
📊The build log gained a metrics layer — four live counters (weeks, milestones, words ingested, bugs fixed) and a phase progress bar that shows how far along the roadmap the project is. Words pull straight from the live archive; the rest update themselves as entries are written.
May 5 – 11, 2026 Week 4

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

Runtime Narrative Systems API Tooling
~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 previous destructive AI editing pass had replaced working implementations with stubs and broken signatures. Repositories, processor, resolvers, canonical logic, stitching, and the bot entry point were all restored to full working order.
🐛Three deep ingestion bugs were diagnosed and fixed — the interruption check was querying the wrong table, thread_id was never being stored, and duplicate detection was checking the wrong log. Together these 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 for historical Tupperbox scenes, 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 through a persistent Cloudflare tunnel. 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.
Apr 28 – May 4, 2026 Week 3

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

Runtime Narrative Systems Tooling
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 integrity of 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 (sensory, tension, and intensity lexical signals), and cadence metrics measuring true cross-writer reply timing.
🧹The full documentation set was reconciled — schema, ingestion rules, runtime behaviour, and pairing config were 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.
Apr 23 – 27, 2026 Week 2

V1 Core — From Half-Built to Production-Ready

Runtime Narrative 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, each resolved in a way that kept runtime behaviour aligned with the schema.
🧭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.
Apr 19 – 22, 2026 Week 1

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

Runtime Narrative 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 (writers, servers, characters, pairings) 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, with strict separation of concerns throughout.
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 — wallet-based database connectivity, the repository layer, and the live bot connection all validated on the actual hardware.