admin
e34b614e5b
gates / gates (push) Successful in 7s
R-182 CLOSED (controller v0.194.0 + hub v0.90.0/.1), proven live on demo-hp. The hub's notification_log for the run reads: two per-app failures RECORDED, one digest SENT naming both, and the customer channel SKIPPED with operator_only. Against the measured previous behaviour — two failures, one email naming one app, one leaving no trace anywhere. Scenario D proved itself on an event I had not planned: disk_critical alarmed on two filesystems, the second was collapsed by the cooldown, and that collapse is now visible WITH ITS KEY. Yesterday it would have left nothing at all. A gap the spec did not anticipate is recorded with its fix: the per-app event also fires from the periodic sweep, outside any run, so making it record-only would have created a NEW silence. The sweep emits a digest too, with no run_id, so it stays under the ordinary hourly cooldown. ep0: MEASURED on the box — 7757 MB (8 GB), 4 vCPU, and the 4 GiB swapfile SURVIVED the resize and is active (checked, because a resize is a stop/start). The 40 GB local disk is UNCHANGED, so no disk figure was touched anywhere. Five documents corrected — three of which the task's list did not name, found by searching. Two audit/evidence documents ANNOTATED, body untouched: they record what was true when written and that is their value. R-90 CLOSED. R-86 unblocked and re-ranked, stated honestly: 8 GB is comfortable, not unbounded — the original OOM was a 14.46 GB restore — so the restore-test cadence should still be paced, just not by fear of the endpoint. target-selection.md's "D-d did not name ep0 either way" is deliberately left standing. It is the operator's question, not CC's. STATUS.md 127 -> 83 lines, items rather than sentences.
84 lines
5.4 KiB
Markdown
84 lines
5.4 KiB
Markdown
# STATUS — what works, what's broken, what's next
|
|
|
|
**Updated 2026-08-03.**
|
|
|
|
> **A view, not a source.** `documentation/backlog/OPEN-ITEMS.md` is the authority on open work; this
|
|
> page restates part of it in plain words, and **nothing may exist only here**. **Not `CONTEXT.md`**,
|
|
> which is technical state written for Claude Code — keep the two separate. **Maintenance:** update
|
|
> at the end of every session in which something shipped, broke, or was decided. One screen; cut
|
|
> items rather than extend it.
|
|
|
|
## What works right now
|
|
|
|
A blank machine boots the Felhom disc, installs itself unattended, and is claimed by the customer,
|
|
who sets their own password. They install apps from a catalogue of fifty-three, share files over the
|
|
home network, and open apps from a launcher or a shared link. Backups run on their own to three
|
|
places — the machine's drive, a second drive, and an encrypted off-site copy — and a customer can
|
|
restore files and app data from the drive alone. Apps come back after a power cut: hard-reset the demo
|
|
box six times, everything returned every time, and an app switched off deliberately stayed off.
|
|
Proven end to end on real hardware.
|
|
|
|
## What's broken
|
|
|
|
- **The off-site copy can be erased by the machine that made it.** The credential that writes it can
|
|
also delete it. A daily snapshot is armed as a stopgap, and we have never restored from that copy.
|
|
*(R-95, R-87)*
|
|
- **Nothing else open that affects a customer.** The three faults that were on this list yesterday —
|
|
the reserve watching the wrong step, the last app whose data was never saved, and the alert that
|
|
told you about one app and swallowed the rest — are all fixed and proven on a real machine.
|
|
|
|
## What shipped recently
|
|
|
|
- **A failed backup now tells you about every app, once.** When several apps fail in one night you get
|
|
**one** email listing all of them, what kind of backup failed for each, why, and how much space is
|
|
left — instead of an email about one app and silence about the rest. Measured before the fix: nine
|
|
failures, two emails. Separately, **every failure is now written down the moment it happens**,
|
|
whether or not it is emailed, and **a message the machine decides not to send now leaves a record
|
|
saying so**. A machine choosing not to tell you and nothing happening no longer look identical.
|
|
A run that finds nothing wrong stays silent, and a backup you trigger yourself always reports.
|
|
*(R-182)*
|
|
- **Publishing became something you do, not something that happens.** The installer that runs as root
|
|
on a new machine, and the agent, both moved onto labelled versions with a way back; a check now
|
|
refuses a release nobody can download. *(R-110, R-115)*
|
|
- **The reserve now guards the step that fills the disk, and its promise is true.** It decides once
|
|
per app, before writing anything, and no longer waves an app through at 96% full. *(R-181)*
|
|
- **The backup partition is gone**; both demo machines were rebuilt on the new shape by two different
|
|
routes. Backup space went from 19 GB to 65 GB on the small machine, 45 GB to 233 GB on the big one.
|
|
*(R-165, R-178)*
|
|
- **The last of the three apps that never saved their data is fixed.** *(R-156)*
|
|
- **A filling disk warns the customer before anything breaks**, naming the drive and the space left.
|
|
*(R-167, R-158)*
|
|
- **The checks have two nets** — one before every push, one on the build server that emails you.
|
|
*(R-29, R-161, R-168)*
|
|
|
|
## What we're working on
|
|
|
|
- **Now:** nothing outstanding. Everything raised in the last three days is closed.
|
|
- **Next:** restore-tests scheduled around each backup rather than on a free-running timer — now
|
|
unblocked, because the off-site endpoint has the memory for it. *(R-86)*
|
|
- **After:** the off-site copy that the machine making it can still erase. *(R-95, R-87)*
|
|
|
|
## Waiting on you
|
|
|
|
- **A job, not a decision: the hub password needs changing.** A diagnostic command printed it into a
|
|
session log; nothing suggests anyone else saw it. *(R-132)*
|
|
- **One small question, not urgent.** The automatic check cannot see which version you have told
|
|
machines to install, only which ones exist. Closing that needs either a password given to the build
|
|
server or a check inside the hub itself. *(R-184)*
|
|
- **One older question still standing:** whether the off-site endpoint counts as protected. It was
|
|
never named either way, and it is yours to settle. *(target-selection.md)*
|
|
|
|
## Changed since last update
|
|
|
|
- **2026-08-03** — A failed backup now reports every app in one email, and nothing is dropped without
|
|
a record. You rescaled the off-site endpoint to twice the memory, which closed one item and
|
|
unblocked another; the documents describing the old machine were corrected, and the audit records
|
|
of what it used to be were annotated rather than rewritten.
|
|
- **2026-08-03** — Publishing became deliberate for both the installer and the agent, with a way back
|
|
and a check that a release can actually be downloaded.
|
|
- **2026-08-03** — The reserve was fixed to guard the step that fills the disk; the last unsaved app
|
|
was fixed; both demo machines were rebuilt on the merged disk layout and proven end to end.
|
|
- **2026-08-02** — Thirteen mechanical checks had built up and nothing ran most of them; two were
|
|
failing quietly. Fixed. Decided the same day: the 20 GB backup partition goes away; and only this
|
|
machine and the tester's box are protected, every other box may be broken or reinstalled freely.
|