Recovery-Driven Admin and Backdoor Porting
Nine of the eleven sessions between November 6 and November 19 were restarts. Brett opened nearly every session with some variation of "my session died", "I had to reset", or "the previous session was disconnected". And yet: the entire logging and notifications system was upgraded to a DB2-backed pipeline, the backdoor admin modules were ported into the main frontend, a full restaurant polling system was built from scratch, and the DataHub board engine was prototyped. The disconnects didn't stop the work — they just made the documentation and recovery strategies more sophisticated.
Context
By early November, the RABS admin frontend had been through the initial navigation standardization, the Vite/source rebuild, and several rounds of HR, Reggie, and feature work. The project was running on a dual-database state: the legacy DB1 and the new DB2, with a CUTOVER_DB2 environment variable controlling which database handled requests. The logging and notifications system was still running on the old emit-log.js emitter against DB1, and it needed migration.
The "backdoor" was a separate admin interface — an older frontend that handled participants, staff, vehicles, and venues with a different visual style and separate routes. Porting it into the main admin frontend meant rebuilding those pages with the standardized chrome and wiring them to the DB2-backed routes.
What happened
Sessions 1–3: The logging and notifications upgrade
The arc opened with a deliberate, methodical audit. Brett wanted to understand the current logging and notifications system before proposing an upgrade — specifically how emit-log.js worked, how the bell badge tallies were calculated, what triggered increments, and what removed items from tallies.
The audit produced notifications_preupgrade.md, and then the implementation began in earnest. This was the largest technical deliverable of the arc:
| New file | Purpose |
|---|---|
backend/services/emit-entries.js | DB2 emitter with list validation against lists.* tables |
backend/services/notifications-interpreter.js | Event subscriber: expands recipients (users/roles/curated groups), detects mentions, sets critical flags, upserts syslog.notifications, pushes SSE toast/log/badge events |
backend/routes_v2/notifications.js | Bell, tiles, feed, mark-all, patch endpoints backed by DB2 views |
backend/routes_v2/logs.js | List and get-by-id endpoints for syslog.entries |
admin/src/js/shared/sounds.js | Sound system rewrite with self-vs-other differentiation |
The session hit the token limit and compacted. Brett opened a second session to resume, hit the token limit again, and opened a third. By the end of session 3, the core notifications pipeline was working but the messenger emitter migration was incomplete — the bucket validation against the lists.* tables needed fixing, and the exported DB list schemas (buckets, curated_groups, delivery, platform, sounds, type) had been created but not yet fully wired.
Sessions 4–5: Completing the migration and the monster session
Session 4 continued the migration work — scaffolded the presence monitor, created SQL for tile routes and messenger buckets, and fixed sound file naming conventions (dash to underscore). It ended at the token limit again.
Session 5 was the breakthrough. Brett had prepared fresh recap and migration task documents for yet another restart, and this session became the largest in the entire arc — over 116,000 lines, hitting eleven compaction cycles. It completed:
- Full messenger/comms emitter migration to
emitEntries - Sound system rewrite with self-vs-other differentiation
- AI chat route rebuilt from scratch with file uploads, PDF parsing, Excel parsing, streaming support, and context v2
- Login sound personalization per user
- Multiple
routes_v1proutes migrated to the DB2 pattern - Task files reorganized and renumbered
The notifications upgrade was effectively done. The project had moved from a legacy emitter to a full DB2-backed pipeline with proper recipient expansion, mention detection, and real-time SSE dispatch.
Session 6: The pivot to backdoor porting
With notifications committed, Brett pivoted immediately to backdoor-to-admin porting. The task files 01-05 covered participants, staff, vehicles, and venues — the core modules from the old interface.
The session began modifying page_participants.html, page_participant.html, page_staff.html, page_vehicles.html, and page_venues.html along with their matching JS files. New pages were created: page_staff_hr.html, page_staff_leave.html and their JS counterparts. A task progress document and a 06_backdoor_to_admin_fix.md task file were created.
Then the session crashed — the assistant hit repeated tool errors and died mid-task. The participant, staff, vehicle, and venue pages were in an inconsistent state.
Session 7: Participant cards and the auth cascade discovery
The backdoor porting resumed with a focus on participant card rendering. The cards needed a supervision multiplier indicator bar, three icon identifiers for behaviour support plans (BSP), mealtime management plans (MMP), and restrictive practices (RP), and needs icons for mobility and dietary requirements.
This session also produced a critical discovery about auth middleware consistency. Some newly created routes_v1p routes were missing authentication middleware entirely, causing 401 errors for logged-in users on admin routes like auto-lunch. The supplemental progress documents from November 14 (authentication_complete-fix.md and authentication_fix-applied.md) show that the fix was to add const { authenticate } = require('../middleware/auth') to routes that had no auth at all — not fixing a wrong import path, but adding missing auth where it was absent. The broader lesson was the same: a single missing or wrong auth import in any route file could cause the entire request chain to fail, and the project's dual-database fallback architecture meant that a route-level failure could silently fall back to the legacy database.
Brett created cortical-stack.md as a memory backup for future sessions — a reference to the Altered Carbon concept of a stack that preserves identity across body swaps. It was a fitting metaphor for a project where sessions died and were constantly reborn.
Session 8: Email, venues, and the cortical stack
The next session pivoted again — this time to the email system. The investigation covered email caching, rolling updates, cache limits, deletion failures, storage size per folder, and "get more" button behavior.
While working on email, the session also created a batch of new route files: routes_v1p/staff_documents.js, staff_leave.js, staff_training.js, vehicle_documents.js, vehicle_maintenance.js, venue_documents.js, and venue_inspections.js — adding 20 API endpoints for the compliance tracking modules.
The venues frontend got a 3-tab navigation (Directory, Documents, Inspections) with 430+ lines of JavaScript. The cortical-stack memory file was updated for session continuity.
Session 9: Auto-lunch — the restaurant polling system
Then came the most unexpected feature of the arc: auto-lunch. Brett wanted a restaurant voting and polling system for the office lunch routine. This was not a small sidebar feature — it became a fully engineered system:
- 3 SQL migrations for core schema, tools/stats, and seed holidays
routes_v1p/lunch.js— a complete restaurant polling system with vote windows (blind → tallies visible → full visibility), revote quotas, tie-break resolution (champion mode with roulette/poker/coinflip; crowd mode), ordering system, facilitator selection, dietary filters, and holiday managementservices/autolunch-scheduler.js— automated poll scheduling- Full frontend —
page_lunch.htmlandpage_lunch.js - Stats widgets — most/least chosen, trendsetter, monotony meter, streaks, win distribution
The session died mid-way (Brett explicitly stated this). Auto-lunch was mostly built but not fully working.
Session 10: Auto-lunch fixes
The final fix-up session for auto-lunch dealt with the stats widgets (data extraction from arrays), test mode toggle, filter button text colors, success modal for all users, and vote tallies on cards. The countdown timer fix didn't apply due to a line-ending issue. The feature was 99% done — core functionality complete, with tie-break UI polish and menu item management remaining.
Session 11: DataHub board engine
The arc closed with an entirely new feature: the DataHub board engine — user-configurable boards with compact, standard, and featured table layouts. The WHS hazards page was the testing ground. A blank template (page_datahub_template.html) was created so any page needing boards could duplicate it. Backend API routes for the DataHub were documented but not yet implemented. The session ended mid-implementation.
What changed
| Before | After |
|---|---|
Legacy emit-log.js emitter against DB1 | Full DB2-backed emit-entries.js + notifications-interpreter.js with recipient expansion, mention detection, and SSE dispatch |
| Separate backdoor admin interface | Participants, staff, vehicles, venues pages ported into main admin with standardized chrome |
| No auto-lunch system | Full restaurant polling system with vote windows, tie-breaks, dietary filters, stats widgets |
| No DataHub boards | Board engine template scaffolded for compact/standard/featured layouts |
| Auth cascade unknown | Single wrong import path can cascade-fail the entire system — documented and guarded against |
| No recovery documentation | cortical-stack.md and project documentation folder with continuation guides |
Work produced
| Area | Key files created or heavily modified |
|---|---|
| Logging/notifications | emit-entries.js, notifications-interpreter.js, routes_v2/notifications.js, routes_v2/logs.js |
| Sound system | admin/src/js/shared/sounds.js — self-vs-other differentiation |
| AI chat | routes_v1p/ai.js — rebuilt with file uploads, PDF, Excel, streaming |
| Backdoor porting | page_participants.html/js, page_staff.html/js, page_vehicles.html/js, page_venues.html/js |
| Compliance tracking | routes_v1p/staff_documents.js, staff_leave.js, staff_training.js, vehicle_documents.js, vehicle_maintenance.js, venue_documents.js, venue_inspections.js |
| Auto-lunch | routes_v1p/lunch.js, services/autolunch-scheduler.js, page_lunch.html/js, SQL migrations |
| DataHub | page_datahub_template.html |
| Recovery docs | cortical-stack.md, project documentation folder with continuation guides |
What we learned
The auth cascade discovery was the most durable lesson: a single wrong import path in any route file can take down the entire system. This wasn't a theoretical concern — it happened, and it forced a fallback to the legacy database. The fix was to always import from ../middleware/auth and never from the older ../middleware/authenticate.
The recovery documentation strategy evolved across the arc. It started with simple task files, grew into cortical-stack.md (a dense memory backup for session continuity), and eventually became a full project documentation folder with detailed continuation guides. Each evolution was driven by the same problem: sessions die, and the next session needs to know what happened.
The incremental DB2 cutover pattern also solidified here. Rather than a single migration, the project maintained dual-database state throughout, with the CUTOVER_DB2 environment variable controlling which routes handled requests. Early-mounting critical routes in server.js became the pattern to bypass the legacy fallback.
Where this led next
The auto-lunch feature continued into late November with bug fixes and polish. The DataHub board engine would be revisited in later sessions. The backdoor porting work would expand into HR systems, staff detail pages, and the complex compliance tracking that dominates the December arc.
But the most important legacy of this arc was the recovery pattern itself. Every subsequent arc would face the same disconnects and token limits. The cortical stack concept — preserving identity across session deaths — became the project's operating metaphor and its actual survival strategy.