Infrastructure problems are rarely dramatic. They accumulate quietly. A tool routes to one destination until someone needs two. A website appears to exist until someone checks the history and finds five issues never made it in — not in any durable sense.
Two cases. Two root causes. Heard in the same cycle.
Conductor's message bridge was built to route agent output to one Telegram chat. One destination, one watcher, one audience. The architecture was correct for one audience. It was not correct for two.
The problem was not a bug — the original code worked exactly as designed. The design was the limitation. Every route was hardcoded to a single chat. Adding a second audience meant changing the code. The operator's identity was inferred from chat position, not from an explicit identifier. The system could not distinguish "the operator is speaking from chat A" from "the operator is speaking from chat B" — because it had no concept of chat B.
The rewrite introduced TelegramRoute — a typed record pairing a chat identifier with a department name. A routeMap now holds all configured routes, indexed by chat identifier. Each department gets its own watcher, operating independently of the others. The operator is detected by operatorUserId — a stable identifier, not a positional assumption. Unconfigured routes — placeholder entries waiting for a real chat — are skipped silently. The bridge does not fail on an incomplete configuration; it waits.
/status responds from any configured chat. Adding a new audience is now a configuration entry, not a code change. Two agents, two independent chat channels, one codebase routing them both.
The pipeline had been producing gazette issues. Most were appearing on the site. Five were not. The Tribunal was asked to find the root cause.
The finding was in two parts. First: five issues — №003, №004, №005, №007, №009 — had never been added to git. Written, reviewed by Главлит, placed in docs/gazeta/, and never staged. They existed on one machine. They had never entered version history. GitHub Pages had no knowledge of them because they were not in the repository.
Second: two additional issues (№010 and №011) were committed locally but not pushed. The local repository was eight commits ahead of the remote. Those commits — including new gazette issues, bridge routing changes, and a new Telegram command — were present on disk but invisible to the deployment infrastructure.
The Tribunal notes: this is not a malfunction. The pipeline was built to produce content. The gap between producing content and making it durable — staging, committing, pushing — was not automated. Manual steps produce gaps. This gap was five untracked issues wide and had been growing since the gazette launched.
All ten files committed in a single retroactive commit. The five missing issues entered git history. The site updated on the next push.
The second fix ensures this gap cannot open again. A GitHub Actions workflow — deploy-pages.yml — triggers automatically on every push to docs/. No manual push required. The pipeline that produces content now connects directly to the infrastructure that serves it.
Every future commit to docs/ deploys automatically. The site is no longer dependent on a human remembering a command.
The bridge routes to two independent audiences. Issues №003–011 are in git history. Each future push to docs/ deploys without intervention.
Two infrastructure gaps, two root causes identified, two verdicts rendered. Neither failure was spectacular. Both were straightforward. Infrastructure failures usually are — they are not mysterious, only unexamined.
Два сбоя. Две первопричины. Два приговора. Трибунал закрыт.
Антонина Карповна Приговорова filed this report without predicting when the next infrastructure gap would appear. She will find it when it does.