Build & Jobs

Four admin pages handle build fleet operations and automated job management: Build (/admin/build), Build Swarm (/admin/build-swarm), Jobs (/admin/jobs), and Swarm (/admin/swarm). The Build page is the primary real-time fleet monitoring interface. Build Swarm provides the fleet management view documented separately. Jobs runs an automated job application engine with pipeline tracking. Swarm is a legacy compatibility alias.

Build (/admin/build)

The build page is the real-time fleet monitoring and build management dashboard. It renders a three-column layout that provides full visibility into the distributed build infrastructure spanning Altair-Link (10.42.0.199), Proxmox Izar-Host (10.42.0.2), Proxmox Tarn-Host (192.168.20.100), and Meridian-Host (192.168.20.50).

Data Polling

The page polls /api/gateway/nodes?all=true every 5 seconds. This endpoint returns the full node registry from the build swarm gateway running on Altair-Link at 10.42.0.199:8090. The response includes every registered node (gateway, orchestrators, drones) with their current status, resource utilization, queue depth, and active job details.

Column 1: Fleet Panel

The left column displays the fleet hierarchy in three collapsible sections:

Gateway

Shows the gateway node running on Altair-Link (10.42.0.199). Displays the gateway’s health status, uptime, total builds processed, and the binhost package count. The gateway is the single entry point for all build submissions and the binary package host for completed builds.

Orchestrators

Lists the orchestrator nodes that coordinate build distribution:

orch-Izar-Host — running on Proxmox Izar-Host (10.42.0.2), LXC container at 10.42.0.201 port 8091. Manages drones on the Milky Way local network.
orch-Tarn-Host — running on Proxmox Tarn-Host (192.168.20.100), LXC container CT 102 via Tailscale at 100.64.0.118. Manages drones on the Andromeda remote network.

Each orchestrator shows its connected drone count, queue depth, and health status.

Drones

Lists all build drones with per-drone details:

Drone	Host	Cores	RAM	Status Indicators
drone-Izar-Host	Proxmox Izar-Host (10.42.0.2)	16	11GB	Current job, CPU%, memory%
drone-Tau-Host	Bare Metal (10.42.0.194)	8	31GB	Current job, CPU%, memory%
sweeper-Capella	Proxmox Izar-Host (10.42.0.2)	8	31GB	Current job, CPU%, memory%
drone-Tarn	Proxmox Tarn-Host (192.168.20.100)	14	12GB	Current job, CPU%, memory%
drone-Meridian-Host	Meridian-Host (192.168.20.50)	20	52GB	Current job, CPU%, memory%

Each drone row shows a status badge (idle, building, error, offline, grounded), the current job name and progress if building, and a mini resource utilization bar. Clicking a drone row expands it to show detailed metrics and recent build history.

Drone Actions

Each drone has action buttons available in its expanded view:

Unground — returns a grounded drone to the available pool. Grounded drones are taken out of rotation but remain online. This is used when a drone was manually paused and needs to rejoin the fleet.
Restart — sends a restart command to the drone process. The drone finishes any in-progress build before restarting. Useful for picking up configuration changes.
Stop — immediately stops the drone process. Any in-progress build is interrupted and re-queued to another drone. Use with caution.

Column 2: Build Queue

The center column shows the build queue organized into four tabs:

Active — builds currently running across all drones. Each entry shows the package name, assigned drone, elapsed time, and a progress indicator. Active builds stream log output when clicked.
Queued — builds waiting for an available drone. Entries show the package name, submission time, priority, and estimated wait time based on current fleet throughput. Queue position can be adjusted by dragging entries.
Completed — recently finished builds (last 24 hours). Each entry shows the package name, drone that built it, total duration, and result (success or failure). Completed builds link to their full build log and the compiled artifact in the binhost.
Failed — builds that errored out. Entries show the package name, drone, failure reason (compile error, dependency missing, timeout, OOM), and a link to the build log. Failed builds have a “Retry” button that re-submits the job.

Column 3: Controls

The right column provides fleet-wide control actions:

Pause Fleet — stops all drones from picking up new jobs. In-progress builds continue to completion. The queue accumulates while paused. A yellow banner appears across the top of all three columns when the fleet is paused.
Resume Fleet — un-pauses the fleet. Queued builds begin distributing to available drones immediately.
Rebalance — redistributes queued builds across drones based on current load. This is useful when a drone has come back online and the queue has not yet naturally rebalanced. The rebalance algorithm considers drone core count, current memory pressure, and network latency (Tailscale drones get lower weight due to higher latency).

Below the action buttons, a statistics panel shows aggregate fleet metrics: total builds today, average build time, fleet utilization percentage, and a throughput graph showing builds completed per hour over the last 24 hours.

Build Swarm (/admin/build-swarm)

The build swarm page provides the fleet management view for the distributed build system. This page is documented in detail in the Infrastructure Tools documentation under the “Build Swarm” section. It covers fleet status, drone management, capability reporting, and the build pipeline. The build swarm page and the build page share the same underlying fleet data but present different perspectives — build-swarm focuses on fleet management while build focuses on real-time build monitoring.

Jobs (/admin/jobs)

The jobs page runs an automated job application engine. This is a personal productivity tool that manages job application submissions, pipeline tracking, and follow-up scheduling.

Application Pipeline

The pipeline tracks applications through five stages:

Queued — applications prepared but not yet submitted. Each entry includes the company name, position title, job URL, resume variant, and cover letter template.
Submitted — applications that have been sent. Tracks submission date, method (direct apply, referral, recruiter), and confirmation status.
Screening — applications that have received a response or are in initial screening. Tracks response date, screener name, and screening type (phone, email, async).
Interview — applications in active interview stages. Tracks interview dates, interviewers, round number, and format (technical, behavioral, system design, panel).
Offer — applications that have reached the offer stage. Tracks offer details and decision status.

Each stage shows a count badge in its header. Applications move between stages by clicking status buttons on each card.

Session Management

The jobs engine operates in sessions. A session represents an active job search period:

Start Session — begins a new application session. Opens the CSV selector and threshold configuration.
Stop Session — ends the current session. Generates a session summary with statistics: applications sent, response rate, time-to-response averages, and pipeline conversion rates.

CSV Selection

At session start, the user selects a CSV file containing target job listings. The CSV includes columns for company, position, URL, priority, and notes. The engine loads the CSV and populates the queue with application entries. Multiple CSVs can be loaded to combine different job search sources.

Threshold Configuration

Configurable thresholds control session behavior:

Daily application limit — maximum applications to submit per day
Follow-up interval — days to wait before sending a follow-up for non-responsive applications
Auto-pause triggers — conditions that pause the session (e.g., 5 active interviews, 2 pending offers)

Polling and Updates

The jobs page polls /api/jobs/* endpoints every 10 seconds to check for status updates. The API endpoints manage:

/api/jobs/queue — GET/POST for the application queue
/api/jobs/pipeline — GET for pipeline status across all stages
/api/jobs/session — POST to start/stop sessions, GET for current session status
/api/jobs/followups — GET for due follow-ups, POST to mark follow-ups as sent

Follow-Up Tracking

The follow-up panel shows applications that are past the configured follow-up interval without a response. Each entry shows the company, position, days since submission, and suggested follow-up action. Marking a follow-up as sent resets the interval timer. Applications with no response after three follow-ups are automatically moved to a “cold” category.

Swarm (/admin/swarm)

The /admin/swarm route is a legacy compatibility alias. It redirects to /admin/build-swarm with a 301 status code. This route existed in earlier versions of the admin panel when the build fleet was managed under the “swarm” naming convention. It is maintained to avoid breaking bookmarks and external links. No unique UI exists at this route.