Operations · 0. The operations manual
This set is for the person who has to keep a Crux daemon running and has to be able to say what it is doing. It covers the decisions you make once, every screen in the console and every control on those screens, the checks that make up a normal day, and the procedures for the days that are not normal.
It is a how-to and reference set. The internals set (/docs/daemon/00-index) explains how the daemon is built; this set explains how you drive it.
0.1 Who this is for
| You are | This set gives you |
|---|---|
| Running a daemon for a fleet of agents and accountable for their work | Chapters 2 to 6: the console, screen by screen, control by control |
| Standing one up for the first time | Chapter 1, then chapter 2 |
| On call | Chapter 7 (what normal looks like), chapter 8 (symptom-first fixes) |
| Responsible for the data surviving | Chapter 9, then chapter 10 |
| Evaluating whether the console shows you enough to be accountable | Chapters 3 to 6, and specifically every row marked STUBBED or FLAG |
If you are writing code against the daemon, you want the API reference and the developer guide instead.
0.2 The one thing to understand before anything else
The console is a read surface with a small, named set of writes bolted on, and it decides which of the two you get by asking the daemon a question at boot.
At start-up the console probes GET /v1/admin/version. If that returns 200, or if the daemon reports auth_mode: off, you are an operator and the write controls appear. Anything else, including a probe that fails, times out or is blocked, makes you a customer, and every mutating control is hidden (render.js:62, shell.html:5590).
This has two consequences you will meet immediately. A screenshot from someone else's daemon may show buttons yours does not. And "the button is missing" is almost never a bug; it is the posture probe telling you what it found.
The complete list of writes the console can perform is 40 curated routes, enumerated in one array in the source (api.js:706). There is no arbitrary write surface. Reads are equally constrained: 173 generated GET methods plus seven curated read-POSTs for search (api.js:40, api.js:887).
0.3 Router: what you are trying to do
| You want to | Go to |
|---|---|
| Get a daemon running for the first time | 1. First run |
| Open the console and understand what you are looking at | 2. The console tour |
| Understand the Rings view, the work board, or the live session board | 3. Rings and work |
| Browse facts, tune retrieval, approve a gate, mint a passport | 4. Memory and trust |
| Read token spend, or change a daemon setting | 5. Meters and system |
| Build a dashboard, search the corpus, or find a page you have lost | 6. Explorer, Studio and graphs |
| Know what to check each morning | 7. Daily operation |
| Fix something that is broken now | 8. Troubleshooting |
| Take a backup you can actually restore | 9. Backup and recovery |
| Move to a new version without losing the data directory | 10. Upgrade and rollback |
0.4 The whole set
| # | Chapter | Mode | What it gives you |
|---|---|---|---|
| 1 | First run | How-to | The four decisions, a minimum working environment, and what a healthy first boot looks like |
| 2 | The console tour | Explanation | Opening it, the shell, navigation, theme, workspaces, posture, and how it authenticates |
| 3 | Rings and work | Reference | The ring canvas and its nine views; the ExecPlan board, activity log, projects and sessions |
| 4 | Memory and trust | Reference | Facts, tenants, documents, review, lane weights; receipts, gates, mints, passports, identity, mediation |
| 5 | Meters and system | Reference | Token burn, measured usage, and every Settings control including AMR defaults |
| 6 | Explorer, Studio and graphs | Reference | Studio (Board, Pages, Integrations, Library), Explorer, Site map, Link graph, the graph and tree views |
| 7 | Daily operation | How-to | The routine, what normal looks like, and the signals that come before a failure |
| 8 | Troubleshooting | How-to | Symptom, check, cause, fix |
| 9 | Backup and recovery | How-to | What to copy, how to prove it restores, and the restore procedure |
| 10 | Upgrade and rollback | How-to | Upgrading live, what breaks, and what is honestly unknown about rolling back |
0.5 What this set does not cover
- Route-level API detail. Request and response shapes are in the API reference. This set names endpoints so you can verify a number, not so you can integrate against one.
- Extending the daemon. Writing an integration pack, a WASM extension or a connector is the developer guide.
- Anything about the hosted tier's internals. Where a console surface proxies a hosted CruxEngine, this set documents the contract the daemon exposes and says plainly when the answer is "this daemon holds none of that".
0.6 How to read a claim here
Every sentence that names a control, a file, a flag or a route links to the line of public source that makes it true. Console claims link into crates/corecruxd/console/v2/; daemon claims link into crates/corecruxd/src/.
Where a control exists in the interface but has nothing behind it, this set says so and names the reason the code gives. There are several. They are not hidden in a footnote, a control inventory that lists a dead button as though it works is worse than no inventory.
Sources
- crates/corecruxd/console/v2/shell.html, the SPA shell: routing, rail, theme, posture, boot
- crates/corecruxd/console/v2/pages.js, the page registry and control declarations
- crates/corecruxd/console/v2/render.js, the renderer and every custom surface
- crates/corecruxd/console/v2/api.js, the generated read client and the 40 gated mutations
- crates/corecruxd/src/console.rs:294, the routes that serve the console
- crates/corecruxd/src/config.rs:830,
CORECRUXD_CONSOLE_ENABLED, default on