Build Log

July 8, 2026 · Documentation + Operations

System Status operations deck reached verified checkpoint

Established commit 3f5c17c as the verified source-of-truth checkpoint for System Status operations deck v3. The compact status rail now presents Health, Services, Websites, Events, and a dedicated Thermals card with independent CPU and GPU readings, followed by separate Critical, Warning, and Info counters.

Typed recovery evidence supplied all four recovery roles, with Last Incident, Last Deploy, and Full Backup above a full-width Recovery Seal. Repository and live NOC hashes matched, public smoke and API checks passed with 15/15 services healthy, Hayloft Secure remained green, and whole-tree main-bot drift protection passed. This was a static release, so no bot restart or Discord command deployment was required.

July 8, 2026 · Operations

Sheppard gained shared signals and live thermals

Centralized active-versus-resolved event decisions in one shared resolver used by Sheppard, the Discord NOC, the platform APIs, and the public NOC. Historical warnings remain visible for audit history while counters and recommendations now reflect only current operational signals.

Static NOC deployments now require an explicit --dry-run or --live mode, and the Operations Brief now reports CPU package and NVIDIA GPU temperatures from verified host sources. The completed release passed with 15/15 services healthy, green backup confidence, clean source/live parity, and successful repository and runtime gates.

July 7, 2026 · Shipped

NOC UI 2.2.26 shipped with Market Pulse

Expanded the Hero Watchtower with a live Market Pulse for SPY, QQQ, DIA, and IWM using TradingView’s isolated ticker-tape widget.

The opaque adaptive presentation is now synchronized across source, live, and public copies. NOC UI 2.2.26 passed the complete repo and runtime release gates with all 15 monitored services healthy and no additional frontend timer.

July 2, 2026 · Platform

NOC UI 2.1.82 reached stable checkpoint

Stabilized the Barndoor NOC after the diagnostics layout cleanup, Recovery Seal static markup pass, mode persistence repair, and Source of Truth scrollbar polish.

The selected theme and viewing mode now persist across refresh, Git History and Source Tree use static scroll containers, live NOC matches the repo, and the frontend, theme parity, public smoke, MC label, version, runtime, and backup-confidence guardrails passed.

July 2, 2026 · Platform

NOC mobile command bar and live repository activity

Condensed the mobile command bar into a compact translucent sticky tray so the NOC controls stay usable without taking over the first screen.

Repaired the Build Log latest-entry layout, restored public latest-preview synchronization, and updated the repository activity graph to prefer live 30-day commit activity from the platform API with the static graph kept as fallback.

July 2, 2026 · Reliability

NOC Last Snapshot removal and theme retention checkpoint

Closed the temporary Last Snapshot experiment and verified that the NOC keeps the selected theme through browser, manual, and automatic refresh paths.

The snapshot row is back to Last Incident, Last Deploy, and Last Backup. Theme retention stays in the lightweight prepaint, init, and theme-button path. NOC frontend, theme parity, MC label guardrail, public smoke, and backup confidence checks passed.

July 2, 2026 · Reliability

NOC theme refresh and MC Agent registry repair

Fixed the MC Agent false-down registry state and replaced the freezing theme observer with a lightweight refresh theme pin.

MC Agent now maps correctly to the backend service check, manual and automatic NOC refreshes keep the selected theme without freezing the page, and NOC smoke, theme parity, MC label guardrail, and backup confidence checks passed.

July 2, 2026 · Platform

NOC System Status and Repository UI polish

Finished the MC label cleanup, added the System Status command deck, and added a 30-day Repository commit graph with smoke-test guardrails.

System Status now has refresh-loop, services, event-bus, and recovery chips. Repository now includes a compact 30-day commit activity graph, and NOC frontend, theme parity, MC label guardrail, public smoke, and backup confidence checks passed after deployment.

June 30, 2026 · Website

Polished NOC Ops Light Desert UI

Balanced the Ops layout, compacted Source of Truth, softened Git History and Source Tree, and tuned Light Desert surfaces so Quick Actions, Ops Diagnostics, and Release Guardrails stay warm, readable, and visually consistent.

This pass reduced Source of Truth weight in Ops mode, removed overly white utility containers, improved Light theme panel hierarchy, and consolidated temporary NOC polish CSS into one maintained Ops polish section.

June 30, 2026 · Operations

Admin commands now run clearer smoke and guardrail checks

The bdq and bdfull admin commands now surface smoke and guardrail checks more directly.

Quick checks include repo hygiene, shell syntax, public-site safety, Build Log style, backup confidence, NOC public smoke, public API summary, and runtime doctor checks. Full checks now run the runtime release gate instead of stopping at repo-only validation.

The bdmaint maintenance command also gained a safer --check mode, repo preflight, live bot syntax checks, post-maintenance smoke checks, and clearer service status output before real maintenance is run.

June 29, 2026 · Operations

NOC static deploys now emit platform events

The NOC static deploy helper now emits a Barndoor platform deploy event after successful live deployment.

This lets the Operations Timeline show NOC static deploys as first-class deploy events instead of only relying on Git history or manual notes.

June 29, 2026 · Workflow

NOC deploy helper joined the release workflow

The NOC static deploy helper is now wired into the broader release workflow.

The repo release check runs the helper in dry-run mode, and the broad tylerrodgers.space deploy script runs the public NOC smoke test after live rsync. This keeps NOC and Build Log deploy safety aligned whether the change is NOC-only or part of a wider website deploy.

June 29, 2026 · Operations

NOC static deploy helper added

Added scripts/deploy-noc-static.sh to make NOC and Build Log static website deploys safer and repeatable.

The helper supports dry-run mode, validates source files, backs up live targets, copies to the known live static web root and skips missing mirror paths, and runs the public NOC smoke test after deployment.

June 29, 2026 · Reliability

NOC API fallback states now look intentional

The NOC API failure path now keeps the dashboard shell feeling intentional when platform or events data cannot be read.

Affected panels render styled fallback states instead of raw plain text, while Ops Diagnostics keeps structured rows for shell status, failure mode, API state, and next retry.

June 29, 2026 · Reliability

NOC release guardrails got clearer

The Ops-only Release Guardrails card now names the frontend syntax check, public smoke check, static website deploy target, no-restart rule for static NOC changes, and source repo path.

Guardrail chips now wrap more safely so longer commands like node scripts/check-noc-frontend.js and ./scripts/check-noc-public.sh stay readable in narrow Ops layouts.

June 29, 2026 · Website

NOC mobile chip readability improved

The NOC now has stronger mobile wrapping for hero controls, Service Registry filter chips, and Operations Timeline chips.

On small screens, hero control clusters become full-width, labels move above their chip group, service filters use a compact grid, and timeline category chips use a compact grid with safer label truncation. Very narrow screens fall back to one-column chip lists.

June 29, 2026 · Reliability

Backup Confidence guardrails tightened

Backup Confidence smoke guardrail: the public NOC smoke test now protects the visible Backup Confidence chain and matching Build Log notes, so future UI work cannot quietly remove the Green recovery-confidence summary.

Backup Confidence visible chain: the NOC Backup Confidence snapshot now shows a compact Green chain: backup, verification, and restore drill passed. If an older restore failure was superseded by a newer restore-tested signal, the visible detail says so directly.

Backup Confidence source reason: the source model now explains the full Green chain: latest backup completed inside the expected window, verification passed, restore drill passed, and older restore failures are marked superseded when a newer restore drill passed.

The Ops Snapshot grid also gives Backup Confidence a wider desktop card and a full-width tablet card so the recovery-confidence chain wraps cleanly instead of cramming into a narrow slot.

June 29, 2026 · Operations + Monitoring

NOC theme polish gained Matrix green and release guardrails

The Barndoor Operations Center received another visual polish pass. The default Dark theme now restores the sharper Matrix-style neon green status hue with a little more glow, while Light mode has stronger day-shift contrast and less flat card styling.

Signal mode was preserved as its own teal/amber operations-console theme, while Light mode moved toward a brighter sandstone desert palette with warmer panels, sage success accents, dusty-blue support colors, and less harsh white. The three viewing modes now feel more distinct: Matrix-green Dark, sandstone Light, and high-contrast Signal. The hero controls were also grouped into Layout, Theme, and Refresh clusters so Default, Dense, Ops, Dark, Light, Signal, Now, and the R-key shortcut no longer read as one long mixed control row. The alert-first empty states also gained more Barndoor-flavored good-news copy for zero incidents and zero down services, with the smoke test updated so those positive states stay protected. Follow-up guardrails now protect the timeline filter behavior too: All mode keeps the raw event window, category modes stay grouped, and the Service Registry starts with the Down chip active to match the alert-first default. The hero live line now exposes data freshness directly as Live, Aging, Stale, or Offline so stale API data is easier to spot. Ops Diagnostics now separates Platform freshness from Events freshness, and the hero Events rail reflects /api/events freshness when available. Backup Confidence now includes a supporting detail line for backup age, verification age, restore-tested age, and superseded restore failures.

Verified: the Ops-only Release Guardrails panel is live in the dashboard, Zero Incidents now has theme-specific styling, Signal was restored to teal, and the public NOC smoke test still reports 25 events with 15/15 healthy services.

June 29, 2026 · Operations + Monitoring

NOC gained a Signal operations-console theme

The Barndoor Operations Center now has a third theme mode: Signal. Signal adds a sharper deep black/blue operations-console look with teal-green status accents, amber warning color, stronger contrast, and a cleaner glow profile than the default dark theme.

The existing layout modes still remain separate: Default, Dense, and Ops. The theme chips are now Dark, Light, and Signal.

Verified: the NOC smoke test now includes a local source theme contract for the Dark, Light, and Signal controls, body.signal CSS, and the Signal JavaScript class toggle. The public smoke test still reports 25 events and 15/15 healthy services.

June 29, 2026 · Operations + Monitoring

NOC now defaults to alert-first operations views

The Barndoor Operations Center now opens in an alert-first posture after a hard page load. The Service Registry starts on the Down filter and the Operations Timeline starts on the Incident filter so service problems and incident activity are immediately visible.

This pass also clarified the timeline behavior: All preserves raw 6/12/24 event rows, while category filters such as Deploy keep grouped stacked views for cleaner operational scanning.

Verified: the live NOC page shows the alert-first cue text, the public events API returns newest-first results, the NOC smoke test passes, and the dashboard remains live at /barndoor/noc/.

June 29, 2026 · Operations + Reliability

Barndoor NOC v2 reached release checkpoint

The Barndoor Operations Center reached its v2 release checkpoint as a live public-facing operations dashboard for platform health, repository state, service checks, deployment visibility, and recent operational events.

This pass polished the dashboard into a clearer command-center interface with Incident Watch, an Operations Timeline, Ops Diagnostics, data freshness warnings, service group health counts, cleaner Dense/Ops modes, and tighter utility-card layout.

Verified: the public NOC route returns HTTP/2 200, /api/platform reports healthy, the service registry shows 15/15 services healthy, and the source repo is clean and synced with GitHub.

June 28, 2026 · Platform + Architecture

Barndoor Platform Foundation

Barndoor reached a new platform milestone with shared health utilities, reusable UI components, modular collectors, a service registry, local status APIs, a JSON status CLI, and a platform event bus. The main /noc and /events commands now sit on top of reusable platform data instead of one-off command logic.

This creates a single source of truth for future dashboards, alerting, historical metrics, monitoring integrations, and eventually multi-node Barndoor operations.

June 28, 2026 · Architecture + Platform

Barndoor platform architecture enters a new phase

Barndoor's internal architecture has entered a new phase focused on long-term scalability and maintainability. Rather than continuing to grow as a collection of individual tools and commands, the project now centers around shared services, reusable components, and a unified operations framework.

The latest development work introduced a common data layer, centralized system health evaluation, and a reusable interface framework that separates data collection, health analysis, and presentation. Administrative tools now share the same underlying architecture, providing a consistent experience while reducing duplicated logic throughout the project.

This architectural shift lays the groundwork for future capabilities including unified operations dashboards, live monitoring, centralized APIs, infrastructure automation, and additional self-hosted services. New functionality can now build on a common platform instead of requiring separate implementations.

Barndoor is evolving from a collection of utilities into a cohesive self-hosted operations platform designed to manage infrastructure, services, and automation through a shared control plane.

June 27, 2026 · Source Control + Workflow

Barndoor full-stack review completed

Completed a full-stack review of the Barndoor source repo, covering the main Discord bot, 9eo, website source, deployment helpers, release checks, CI workflow, and operational documentation.

The review confirmed that Barndoor has successfully become a source-controlled self-hosted operations platform. The project now has local AI through Discord, owner-only health and service commands, website monitoring, searchable notes, backup visibility, safer deployment helpers, public project pages, and a unified release gate.

The next roadmap focuses on cleanup and hardening: split the main bot into smaller modules, remove command-definition drift, pin agent dependencies, centralize service allowlists, improve structured observability, and update the public website copy to reflect the current state of the system.

June 12, 2026 · Shipped

9eo Music Bot Is Live on Barndoor

9eo reached its first full deployment milestone as a standalone Discord music bot hosted from Barndoor. It now runs as its own systemd service, uses slash commands, joins voice channels, plays audio, shows a rich now-playing card, and is backed by the main Barndoor GitHub repo under agents/9eo.

This pass added working YouTube playback, SoundCloud search and direct track links, copied SoundCloud share-link cleanup, local .mp3 / .wav playback, basic queues, playlist save/call/list commands, and interactive playback controls.

I also completed the public launch pieces: Discord install permissions were tightened, Message Content intent is not required, legal pages are live, and a dedicated landing page is available at tm44.link/9eo.

Verified: npm run check passes, 9eo.service is enabled and running, slash commands work, YouTube and SoundCloud playback work, SoundCloud share URLs are cleaned automatically, the now-playing card renders correctly, and the landing page returns HTTP/2 200 through Caddy.

June 6, 2026 · Reliability + Operations

Runtime guardrails added for Barndoor

Added a new runtime check so Barndoor verifies more than basic uptime. The bot now checks that it is running under the intended systemd service, from the expected live folder, with no duplicate bot runner active.

The guardrail was tested and tuned after the first version counted a normal shell wrapper as a second bot process. The corrected check now confirms the real operating state: one service owner, one bot process, and no competing process manager.

This makes Barndoor’s maintenance workflow stronger by treating process ownership as part of system health. Future checks, deploys, and restarts now verify that Barndoor is not just online, but running cleanly.

June 6, 2026 · Operations + Deployment

Barndoor bot deployment workflow standardized

Standardized the way Barndoor bot updates move from source files to the live service. Bot changes now follow a safer path: edit in the repo, run checks, preview the deploy, update the live bot folder, restart deliberately, and verify the service is running cleanly.

Added helper scripts for checking bot source files, deploying bot updates, and restarting the systemd service with status, recent logs, and process-tree output. The deploy process keeps live-only runtime files separate, so environment settings and installed dependencies are not overwritten during normal updates.

This gives Barndoor a more reliable maintenance model. Website updates and bot updates now both have repeatable deployment steps, preflight checks, rollback documentation, and a clearer separation between source-controlled files and live runtime state.

June 6, 2026 · Workflow + Deployment

Editor workflow and deploy preflights added

Improved the day-to-day Barndoor workflow by setting up VS Code Remote SSH as the primary editor and WinSCP with Sublime Text as a backup file browser and quick editor.

Website deployment safety also improved. The main site and TM44.link deploy helpers now run public-site safety checks before live deploys, and a new combined check script gives the repo one command for common validation.

Documentation was expanded with editor workflow notes, rollback guidance, and private recovery-note scaffolding so future maintenance can stay organized without publishing sensitive operational details.

June 6, 2026 · Security + Documentation

Public recovery page sanitized and safety checks added

Cleaned up the public recovery documentation so it describes Barndoor’s reliability goals without exposing operational restore details. The recovery page now stays intentionally high level, while detailed maintenance and restore notes remain internal.

The website workflow was also tightened with a new public-site safety checker. Before future deploys, the repo can now scan public website files for wording that may reveal private paths, sensitive configuration details, backup workflow clues, notification setup details, or outdated hidden-page language.

The website runbook was updated to document the safer recovery-page workflow. Normal website deploys now skip the root-owned recovery page, and recovery-page updates require an intentional manual copy step. This keeps regular deploys clean while making sensitive public copy changes more deliberate.

June 6, 2026 · Websites + Source Control

Website source-of-truth workflow completed

Moved the public website workflow into the Barndoor source repo so future updates can be edited, reviewed, committed, and deployed from a clean Git-backed process instead of manual live-file edits.

Both tylerrodgers.space and TM44.link are now tracked under the websites/ folder in the repo, with safe deploy helper scripts for dry-run and live syncs.

The deploy flow now uses rsync without ownership or group changes, which avoids noisy permission errors from root-owned live paths while keeping live-only backup files untouched.

The build log system was also improved. Entry counts now update automatically from the log entries on the page, and focus areas are counted from broad build-log categories instead of every small tag. The homepage was updated to point cleanly to the latest build log entry and the full /build-log/ archive.

June 6, 2026 · Documentation + Reliability

Project documentation and recovery workflow improved

Improved the project’s documentation, update workflow, and recovery planning so future changes are easier to review, test, and maintain.

The project now has a cleaner separation between development files and live production services. This helps reduce the risk of accidental changes while making updates easier to track and deploy.

Recovery planning also moved forward with clearer rebuild notes, backup guidance, and health-check steps that make it easier to confirm core services are working after maintenance or restoration.

June 5, 2026 · Website + Operations

Project pages and internal operations dashboard refined

Paused major feature work to clean up the public project pages and improve the internal Barndoor operations workflow.

The Barndoor page was tightened into a clearer operations-platform overview, Haystack received a gold Discord-app themed refresh with a direct install link, TM44.link was cleaned up as a simple short-link hub, and the build log was made more chronological and easier to scan.

On the private operations side, the SSH dashboard was upgraded with clearer health checks, website checks, backup retention status, overview stats, build log notification state, and a recommendation section.

June 5, 2026 · Infrastructure

Barndoor power infrastructure documented

Updated the Barndoor project description to include the physical rack power infrastructure supporting the system.

Barndoor is now documented as a rack-supported system with a PDU, UPS, and power meter alongside the software stack.

June 5, 2026 · Milestone

Barndoor moves into an operations platform phase

Barndoor has moved beyond a basic self-hosted server and Discord bot into a personal operations platform for websites, local AI, infrastructure checks, documentation, backups, and recovery workflows.

Recent work upgraded the Discord command layer with a clearer health dashboard, better command navigation, expanded knowledge and recovery notes, and a more polished public website overview of the project.

June 5, 2026 · Operations

Barndoor Doctor upgraded into a first-stop dashboard

Upgraded /doctor from a basic health check into a more complete first-stop operations dashboard for Barndoor.

The command now checks the most important operating areas: core services, containers, disk usage, network connectivity, local AI availability, backup status, public website availability, and build log notification state.

This gives Barndoor a clearer troubleshooting path: start with the main health dashboard, review the summary, then move into the specific service, disk, network, backup, website, or notification check that needs attention.

June 5, 2026 · Operations

Barndoor Doctor command added

Added /doctor, an owner-only quick health diagnosis command for Barndoor. Instead of running several checks manually, this command gives a short summary of the system’s most important areas.

The doctor check looks at core services, disk usage, network and Ollama connectivity, backup freshness, and public website availability. It then gives a recommended next check if something needs attention.

This adds a simple first-response layer to Barndoor’s operations workflow: run the main health check, see what area needs attention, then move into the more detailed service, disk, network, backup, or website checks.

June 5, 2026 · Discord Bot + Workflow

Barndoor command interface cleaned up

Cleaned up Barndoor’s Discord command interface so it is easier to understand and use as the command list grows.

The help flow is now split into a short starter menu, a grouped command reference, and a quick list of available knowledge topics.

This makes Barndoor feel less like a pile of commands and more like a structured operations assistant with clear entry points for general use, system checks, documentation, backups, website tools, and local AI controls.

June 5, 2026 · Documentation + Recovery

Barndoor documentation and recovery workflow cleaned up

Cleaned up Barndoor’s documentation and recovery workflow after expanding the knowledge base and completing a restore drill.

The project now has organized knowledge notes, internal recovery notes, a maintenance lifecycle PDF, daily backups, retention cleanup, and a verified recovery review process. Temporary test notes and cleanup folders were removed so the home directory and knowledge base are easier to maintain.

This marks a reliability checkpoint for Barndoor: the system is not only being built and documented, but also backed up, searchable, and tested for recovery.

June 5, 2026 · Documentation

Barndoor knowledge base expanded

Expanded Barndoor’s local knowledge base so the Discord bot can return and search more useful infrastructure documentation from the server itself.

The knowledge files now include deeper notes for services, networking, backups, commands, recovery, and websites. This makes /notes, /searchnotes, and /addnote more useful during normal maintenance, troubleshooting, and recovery work.

I also added a new websites topic that documents tylerrodgers.space, TM44.link, Caddy, website file paths, the build log watcher, and the hidden recovery guide. Barndoor can now return this topic directly with /notes topic: websites.

June 4, 2026 · Recovery + Documentation

Internal Barndoor recovery notes created

Added internal recovery notes for Barndoor to support maintenance planning, backup review, and safer restore practice without publishing operational details.

The detailed notes are kept internal, while the public build log records the reliability work at a high level.

June 4, 2026 · Milestone

Barndoor enters the admin assistant phase

Barndoor began shifting from a basic Discord chatbot into a local operations assistant for the server.

The bot gained practical owner-only commands for checking status, reviewing services, inspecting logs, switching models, and managing local AI settings. This created the first version of Barndoor as a Discord-based control surface for the home lab.

June 4, 2026 · Documentation + Workflow

Barndoor knowledge editing added

Added /addnote to the Barndoor Discord bot so I can append new information to the local knowledge files directly from Discord.

Combined with /notes and /searchnotes, this creates a simple read, search, and write workflow for Barndoor’s project-specific infrastructure documentation.

This makes the knowledge base easier to maintain while I’m actively working on the server. Instead of SSHing in every time I want to record a recovery note, service detail, backup reminder, or command reference, I can now add it from Discord.

June 4, 2026 · Documentation

Barndoor knowledge notes added

Added a local Barndoor knowledge folder and new Discord commands that let the bot return and search project-specific infrastructure notes.

The new /notes command returns fixed notes by topic, while /searchnotes searches across the local knowledge files. Current topics include services, network, recovery, backups, and commands.

This is the first step toward giving Barndoor more awareness of its own environment, including the services it runs, the ports it uses, recovery steps, backup locations, and local admin shortcuts.

June 4, 2026 · Operations

Barndoor admin toolkit added

Expanded the Barndoor Discord bot with an owner-only server administration toolkit for monitoring, diagnostics, and basic service recovery from Discord.

New commands now let me check overall system health, view service and container status, inspect disk usage, test network and Ollama connectivity, read recent logs, restart approved services, and check backup status.

This creates the first full admin loop for Barndoor: check the system, inspect the problem, and recover a service without immediately needing to SSH into the server.

June 4, 2026 · Websites + Infrastructure

Local website migration to Barndoor

Migrated tylerrodgers.space and TM44.link from hosted web services to Barndoor, a locally hosted Ubuntu server running Docker, Caddy, and HTTPS.

This included DNS cleanup, router port forwarding, Caddy reverse proxy setup, production TLS certificates, and local firewall tightening.

June 4, 2026 · Websites

TM44.link short-link hub

Turned TM44.link into both a public link hub and a short-link redirect domain for my active projects and build-log pages.

Current short links include /now, /buildlog, /barndoor, /haystack, and /me.

June 4, 2026 · Discord Bot + Monitoring

Barndoor Discord operations commands

Added operational commands to the Barndoor Discord bot so I can check site status, public links, host uptime, service health, GPU status, and active model information from Discord.

Commands added or improved include /websites, /links, /uptime, /report, and /help.

June 3, 2026 · Websites + Documentation

Dedicated project pages

Added standalone project pages for Barndoor and Haystack so each project has a clearer overview, current stack, next steps, and direct short-link destination.

This gave the public site a cleaner project index while keeping the Build Log connected to the active Barndoor and Haystack work.