Docs
On this page
Overview
read-only consoleDesert Eagle Ops is a local, static operations console for Operation Desert Eagle. It shows what the Leonidas job system has done (runs, jobs, digests), what went wrong (issues, roadblocks, environment gaps), and the live posture (caps, guardrail counters, agent roster, configuration).
The data behind every page is regenerated every 3 hours by Iris (RPT-WEB-01), a deterministic, read-only child agent of Leonidas (D-041). Iris never writes to the ledger, never sends anything outbound, and never touches guardrail rule text. The console itself writes nothing either: it is a one-way window into the repo.
Everything renders from a single generated file,
data/data.js. Pages show honest empty states: a metric with no
data yet appears as an empty block or a dash, never as a fake zero. The site
works over file:// (double-click index.html) or from
any static server.
- 12 pages in four sidebar sections: Command, Team, Posture, Help.
- Reporter: Iris (RPT-WEB-01), cadence 3 hours, tunables in
agents/leonidas/config/iris.yaml. - House rule: every number comes from the data file; nothing on these pages is hardcoded.
Page guide
all 12 pages
The landing view. KPI cards summarize jobs discovered (with the 24 hour delta), scored jobs with the average score, queued plus prepared counts, and open issues (danger-tinted when above zero). Below them: the pipeline funnel with stage-to-stage conversion percentages, a status donut, the 14 day runs-vs-errors trend, an applications-per-day card, the collector status card (per-source ok / empty / missing chips), the latest digest preview, and the eight most recent runs.
The job table. Lifecycle totals up top, then a
sortable, searchable table of the newest 200 jobs: score badge, title
(linked to the posting), company, source, status, remote posture, salary,
discovery date, scam risk, and skip reason. Charts break down skip reasons,
source mix, and score bands. Source performance and top role title tables
fill in once applications begin. The topbar search on every page lands here
as pipeline.html?q=...
Execution history. A KPI row covers total runs, the last 24 hours, error runs, and token plus estimated cost totals. The table lists the newest 100 runs with kind, status, duration, key stats chips, and per-run cost. A stacked daily chart separates clean runs from errors, and the self-improvement feed shows what the system logged about its own fixes.
Everything that needs attention: roadblocks from the ledger, runs that ended in error, environment gaps from the newest env report (keys are configured on the host, never in the repo), the guardrails posture card (presence checks only), and Iris's own issues. A SEV explainer describes the four severity classes. The topbar bell mirrors the first six open items.
The team. An orchestrator card for LEONIDAS, then the child agent grid with agent id, role, model tier, status, and respawn count. Reserve callsigns and peer super agents (Elon, future phase) are listed separately. A banner appears when the page shows the specified baseline roster because Leonidas has not written a live registry yet. Iris injects itself into the roster it publishes.
The daily digest reader. The newest 14 digests
appear in the left list; the right pane renders the selected one with a
raw / rendered toggle plus "Copy markdown" and "Download .md" buttons
(disabled while there is nothing to export). Digests appear after the first
scored run: python -m jobcore.cli run --limit 25
Outbound comms posture. Cards for the 06:45 morning and 19:00 evening reports with next-occurrence countdowns, the email mode (dry-run outbox vs live SMTP) with an outbox table, the Telegram mirror posture, the notifications ledger, and the asks-and-learning card (pending proposals, queued questions, status and topic counts only; the content itself lives in the morning email per D-023).
Tunable posture, never rule text. The caps board shows used-vs-limit progress for each daily cap, alongside score thresholds, pacing settings (with a warning when the pacing cap disagrees with the settings cap), gates (auto-submit, browser apply, Alex, kill switch), and a rule inventory card with counts only. Hard rules live in the private guardrails folder (D-036). The LLM budget row links to the Costs page for the full cost view.
A read-only mirror of
agents/leonidas/config: schedules, search queries, role
taxonomy tiers, tracked companies, the model pool (with live model stats
when present), tier budgets, and Alex's settings. Edit the YAML files in
the repo; this page reflects the change on the next collector run.
LLM spend. Today's and month-to-date spend, calls today, and the estimated cost per application, followed by a 30 day spend chart with a calls overlay, a per-model spend table, tier budget cards (future placeholders from models.yaml), and today's usage against the daily LLM budget cap. Mostly empty states until spend is recorded.
The big picture. The architecture diagram (Hermes engine, Leonidas, child agents, jobcore), the phase board, machine cards (Vader II, Quantum Core), the environment report, decision highlights, the test suite, and the experiment board (filled by Sage and Oracle in Phase 7). The about card repeats the collector metadata shown on Mission Control.
This page. A static, self-contained guide
authored directly in HTML. It needs no collector data and renders even when
data.js is missing, so it is always available for
troubleshooting.
Data flow
one-way, read-onlyOne direction only. Iris reads the repo, writes one data file, and the pages render it in the browser. Nothing ever flows back.
Repository
read-only sourcesSQLite ledger
(memory/desert_eagle.db), logs (digests, env reports, outbox,
iris_runs.log), YAML configs under
agents/leonidas/config/, the agent registry, and a guardrails
presence check (never rule text).
iris_collect.py
Iris RPT-WEB-01Deterministic Python collector. Every
source is read defensively, so one failing source never kills a run.
Appends one status line per run to logs/iris_runs.log.
data/data.js
window.DE_DATAOne generated data file (plus
data.json for tooling), replaced atomically on every
run. Missing data stays null or empty, never a fake number.
Each page reads window.DE_DATA through the shared DE helpers and renders cards, tables, and charts locally. No fetch, no backend, no write-back.
Refresh model
every 3 hoursThe scheduled task DesertEagleIrisWebUpdate runs
agents/leonidas/scripts/iris_run.ps1 every 3 hours. The interval is
fixed when the task is registered (register_iris_task.ps1 -IntervalHours,
default 3); cadence_hours in agents/leonidas/config/iris.yaml
drives the stale-data banner and should stay equal to the task interval. The task
starts at the top of an hour. Registered from an elevated PowerShell it uses
an S4U principal, so it fires even while the operator is logged out; registered
without elevation it falls back to an interactive task that only runs while the
user is logged in.
The wrapper resolves the repo root from its own location,
then picks a Python: the repo .venv first, then per-user installs,
the py launcher, and python on PATH, preferring the
first candidate that has PyYAML. Wrapper-level failures (no Python, non-zero
exit) are also appended to logs/iris_runs.log, so a broken box
still leaves a trace.
Manual refresh
| Method | Command (from the repo root) |
|---|---|
| Collector direct | python agents/leonidas/scripts/iris_collect.py
add --check to print the summary without writing files |
| Wrapper | powershell -NoProfile -ExecutionPolicy Bypass -File agents\leonidas\scripts\iris_run.ps1 |
| Scheduled task | Start-ScheduledTask -TaskName "DesertEagleIrisWebUpdate" |
Then reload the page; the operator menu in the topbar has a "Refresh data" item that does the same thing.
Automatic staleness detection
Every data build carries a stale-after mark: the generation time plus the cadence plus a 45 minute grace window. When the browser clock passes it, every page shows a yellow "Data is stale" banner. A missing data file shows the separate "No data yet" banner instead; only one of the two ever appears.
The "data as of" chip in the topbar shows the last collector run; its tooltip counts down to the next expected update. Two minutes past due, a hidden tab reloads itself once to pick up fresh data, while a visible tab pulses the chip instead of yanking the page out from under the reader.
Privacy rules
hard rules- No PII. The collector never
reads
memory/profile.yaml,memory/resume-master.md, anything undermemory/credentials/, personal files underknowledge/, or.env. Job data (titles, companies, urls, salaries) is in scope; personal identity data is not. - No guardrail rule text. Iris only checks that the private guardrails folder, its integrity file, and the control/STOP switch exist. The site shows counters and tunable posture only (D-036).
- Asks stay private. The asks-and-learning card on Reports shows counts, statuses, and topics only, never question text or answers.
- No secrets. API keys are configured on the host machine, never in the repo, so no page can display one. The environment report only says whether a provider is configured.
- Local only. Pages load data from a local script tag and make no fetch or XHR calls. The only external requests are the template's Google Fonts stylesheet and iconify icon fetches.
Vader II deployment
runbook pointerThe console ships to Vader II (the control node per D-030) by copying the repo; the site itself needs nothing but a browser. The full migration runbook lives one folder above this site:
Agent update website/docs/DEPLOY_VADER_II.md
companion runbooks in the same
folder: USER_GUIDE.md and OPERATIONS.md
In short: copy the repo to D:\Desert Eagle,
create a .venv and install PyYAML, then register the refresh task
from an elevated PowerShell in the scripts folder:
.\register_iris_task.ps1 -ScriptPath "D:\Desert Eagle\agents\leonidas\scripts\iris_run.ps1"
Verify that the task exists, logs/iris_runs.log
gains a line, site/data/data.js regenerates, and the site opens
with a fresh "data as of" chip. Rollback is a single
Unregister-ScheduledTask; the site is read-only, so there is
nothing else to undo.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| "No data yet" banner on every page | site/data/data.js is missing or did
not define window.DE_DATA |
From the repo root run
python agents/leonidas/scripts/iris_collect.py,
then reload |
| "Data is stale" banner | No fresh build within the cadence plus the 45 minute grace: task unregistered, machine asleep, or the run failed | Confirm with
Get-ScheduledTask -TaskName "DesertEagleIrisWebUpdate",
read the tail of logs/iris_runs.log, then force a
run with Start-ScheduledTask |
| Sources show "missing" chips on Mission Control | That source file or table does not exist on this machine yet (normal in early phases) | Usually nothing; confirm the expected path exists and check the collector errors on the Issues page |
| Task exists but never fires | Registered without elevation (interactive mode) while the operator is logged out, or the box was off at trigger time | Re-run
register_iris_task.ps1 from an elevated PowerShell
to upgrade it to S4U; StartWhenAvailable catches up missed
triggers after boot |
| Task runs but the log line says error | The wrapper found no usable Python or the collector exited non-zero; a frequent culprit is PATH resolving python to the WindowsApps store stub without site packages | Read the note field of the failing line in
logs/iris_runs.log; the wrapper prefers the repo
.venv and per-user installs with PyYAML, so create
the .venv or install PyYAML for a real Python |
FAQ
Why are so many panels empty?
The operation is in its early phases, so much of the data simply does not exist yet. The console renders honest empty states by design: null data never appears as a zero, and each empty block says what will fill it.
Does this site change anything on the system?
No. The console is strictly read-only. Even the red kill-switch banner is informational; it reports that control/STOP exists, it does not create or remove it.
How current is what I am looking at?
The "data as of" chip in the topbar shows the last collector run; Iris refreshes the data every 3 hours. A page shows a snapshot from load time, so reload after a manual collector run.
Why can I not see the guardrail rules?
Hard rules live in the private guardrails folder (D-036) and are never published to this site. The Guardrails page shows counters, caps, and tunable posture only.
Do I need a web server to open the console?
No. Double-click site/index.html
and everything works over file://. If you prefer a server,
python -m http.server from the site folder works too.
What exactly is Iris?
Iris (RPT-WEB-01) is a deterministic,
read-only reporter script registered as a child agent of Leonidas (D-041).
It gathers repo data every 3 hours, regenerates
data/data.js, and logs each run. It sends nothing outbound and
writes nothing except the site data files and its own log line.