Releases
One release train. Each XenoRack release carries the node, and the collector when it changes.Your role has no access to the Releases area.
Needs a person most severe first · each row opens the record behind it
| State | What happened |
|---|
Nothing needs a person.
Ship a release start to promotion · each step says where it happens and what to do now
Fleet pairing what each node runs · from its last signed check-in
| Node | Class | XenoRack | Status | Collector in its package | Last check-in |
|---|
No node has reported its package yet.
The on-site update channel (ADR-016, ADR-028). New signed releases arrive from GitHub by themselves (every 15 minutes, or Check GitHub now); the Head verifies each one and keeps the package. A release goes to the canary nodes in order, then to every node once each canary has run it cleanly for the hold time and checked in after. The first failure on any node halts it for every node that has not taken it; resuming is a person's decision.
Releases
| Release | Carries | Pipeline | Rollout | Published |
|---|
No XenoRack package release has been published yet.
Break-glass: publish a package by URL and sha256 (admin)
The pre-ADR-022 path, kept for a GitHub outage. Nodes still verify the package signature themselves; a URL here grants nothing the signature does not. A release id is never reused.
The collector rides the release train: a release carries it only when ops/release/collector.lock changed, and a node offers it to its collectors only after it has committed that release (ADR-025). A collector fix ships as a collector-only release, which carries no node_db and so runs no migrations. Each node rolls the build out to its own collectors, canary per site first, wherever they run: a collector host of their own or the node's host. A collector never talks to the Head; its node reports what each one runs. Hold stops collector rollouts of a build (one node or every node) without stopping node installs. A collector canary that rolls back or fails holds its build on every node by itself.
Every collector as each node's signed check-in reported it; judged against the build that node offers
| Node | Class | Build it offers | Collectors | Rollout | Automatic rollout | Held | Problems |
|---|
No node has reported its collectors yet. A node sends them with each signed check-in.
Held collector builds sent to each node in the signed release channel
| Scope | Why | By | Since |
|---|
Nothing is held. Every node rolls out the collector build its release carries.
Hold a collector build
Collector update problems rolled back or failed, until a person acknowledges them
| When | Node | Collector | Release | Wave | From → to | Outcome |
|---|
No collector update has rolled back or failed.
Collector by node the collector each node's installed package holds
| Node | Class | XenoRack | Collector in its package | Against the newest carried | Last check-in |
|---|
No node has reported its package yet.
Releases that carried a collector
| Collector | Release | Carries | Rollout | Published |
|---|
No release on this Head states that it carries a collector. Releases ingested before their notes listed components show "not stated".
Customer downloads
What customers can download from the portal's Support menu, per operating system. A release appears there only when promoted here, and only after the Head has proven the GitHub Release is the signed release: the manifest signature verifies against a release key, every artifact in the package matches it, and the installer is byte for byte the signed one. The Head then keeps the bytes. Promote only what passed DEV and UAT (SOP-RG-01). Withdraw removes it from the portal at once; nothing is deleted. A standalone collector bundle (ADR-031 D4) is not published yet; collectors install from the node package.
| Release | OS | State | Files | Key | Why | Promoted |
|---|
Nothing is offered to customers yet.
Promote to customers
The reason does not mention UAT. SOP-RG-01 asks for DEV and UAT before customers get a release. Press Promote again to promote anyway, or use Break glass.
Break glass. Puts the release on the portal now, before its canaries finish (SOP-RG-01 is set aside, on the record). The Head still proves the signature, every artifact and the installer, and refuses a paused release. Say why it cannot wait (at least 10 characters): the reason is kept as BREAK GLASS — … and the offer stays flagged on Overview until someone confirms the canaries or withdraws it.
for an urgent install (a customer blocked on install day) that cannot wait for the canaries
Recent downloads
| When | Customer | Who | File | Via | IP |
|---|
No downloads yet.
Sign a release manifest
Choose the manifest.json that xr-release.mjs build wrote. The Head names the active key in it, signs it, and gives back one file; on the Mac, xr-release.mjs seal turns it into the .xrpkg. A release id is signed once.
Release signing key
One fleet key signs every XenoRack release. This Head makes it and keeps the private half sealed under RELEASE_SIGNING_KEK; no route ever returns it. A node trusts a key only once a person pins it on that node's host; the Head never pushes a key. Coverage counts nodes whose last signed check-in lists the key (unknown = the node has not reported its pins). Rotation: create the next key, pin it everywhere, promote it, then unpin the retired one. Keys are never deleted. Licence keys (ADR-030) live under Customers.
| Key id | Status | Public key (hex) | Coverage | Made | History |
|---|
No release key has been made yet.
Directive signing key
ADR-042 D2a. A SEPARATE key (never the release key) signs protective directives: pause an integration type, pause all reads, hold updates, sent from a node's page under Fleet. This Head keeps the private half sealed under DIRECTIVE_SIGNING_KEK; no route returns it. A node trusts a directive key only once a signed XenoRack release carries its .pub: commit the file shown below to the xenorack repo in a PR, and ship it. Until then the node refuses every directive (no_key). A leaked directive key can pause reads; it can never ship code.
| Key id | Status | File to commit to xenorack | Made | History |
|---|
No directive key has been made yet.
Signature ledger the Head's own record · checkable against GitHub
| Signed release | Key | Manifest sha256 | Commit | By |
|---|
This is the knowledge channel, not software. It moves to Catalog in a follow-up (ADR-036 D6); it sits here until then so nobody loses access to it.
Manifest delivery
Which nodes run the active curriculum manifest. A publish or retract is not fleet-effective until nodes ack it (G8 acks-barrier): current = acked the active manifest, stale = acked an older one (drift), missing = never acked. Excludes the demo teacher.
| Node | Class | Status | Acked manifest | Applied | Acked |
|---|
No manifest acks yet — nodes report the manifest they apply via POST /nodes/:id/manifest-ack.
Retracted doctrine
Authored knowledge pulled from doctrine (a bad MOP, a superseded playbook or lesson). Retracts are monotonic — they persist across publishes and change the manifest id, so nodes must re-apply (watch them go stale above). Retracting a MOP once coverage is in an MSA is a legal event, so a reason is required and audited.
| Kind | Ref | Reason | Retracted |
|---|
No doctrine retracted — the active manifest pulls nothing.
The hosted-demo push topology only. Customer nodes behind a firewall never receive these; they pull signed releases (Releases tab).
Compose update notice
Outstanding notices
| Slug | Message | Priority | Recipients | Last sent |
|---|
No update notices are outstanding.
Demo releases
| Version | Notes | Published by | When |
|---|
No demo releases published.