Build Log

June 12, 2026 · Barndoor / 9eo · 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

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

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

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

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

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

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

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

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

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

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

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

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

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.