admin
186546d562
All 28 walked on scratch guest 9202 against the private drill catalog. 26 deployed, 6 proven, 5 inconclusive, 14 with no upstream edge, 1 failed honestly (outline 1.9.1->1.10.1, HELD with the right sentence), 2 undeployable - one (plant-it) by design, refused by the lifecycle gate, proven live for the first time. Each app also got the half the update night skipped: a restore from its own copy with the seed read back again - 21 restored, 2 correctly REFUSED per 07 6.2. R-630 RAISED TO P1 by measurement: a stack with NO probe container does not skip verifying - it waits out the full health timeout and HOLDS, stopping an app whose three containers read healthy. The controller's own words: "not healthy within 5m0s (last: no probe container)". R-633 opened: a remove sent during a restore reports success and leaves a container restarting with a live public route. The product already refuses that clash for update and for restore, naming the blocker; remove has no such guard. R-634 opened: an app can be running, healthy and serving while recorded as deployed=false, and is then unremovable. Reproducible alone on sparkyfitness; concurrency-linked on two others. R-631 and R-632 CLOSED. Register 321 -> 323. Seven interventions, six of them my own harness - named, with what each cost. No product code. The live catalog's image: lines are byte-identical to the start of the night. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2.1 KiB
STATUS — what works, what's broken, what's next
Updated 2026-09-22 (overnight) — I installed and tested the N apps that no test had ever touched. Here is what we now know, and the two things that are quietly wrong.
Decisions I took on my own: none.
What I did. Every one of the twenty-eight apps nobody had ever installed in a test got the same walk: install it at the version our catalog offers today, put real data in through the app's own front door, back it up, update it if a newer version really exists, restore it from that backup, read the data back, and remove it. SUMMARY
The thing I would fix first — deleting an app while it is being restored leaves a ghost. I restored one app and deleted it fifteen seconds later. Both buttons said they worked. The app is gone from every screen — and a container is still running on the machine, restarting over and over, still holding a public web address. Nothing can warn you, because the machine no longer knows the app exists. A household can press exactly those two buttons in that order. This is the same thing we saw once before and could not explain; this time the whole seventeen-second window is recorded.
The best thing I saw — the machine refusing to do something dangerous, in plain Hungarian. One app keeps its files outside the database. Its local copy does not hold those files. When I asked to restore it, the machine refused, and said why: it will not put an old database on top of files it does not have, the files stay where they are, and here is the button that does work. That is exactly right, and my own test script nearly recorded it as a failure.
FINDINGS
Rows opened and closed. ROWS
What needs you.
- The second promotion list — the app versions this night proved safe enough to move on the real catalog, listed in the report. Moving a version is your call. If you do nothing: nothing breaks; those apps drift further from upstream each month.
Nothing on your own machine, the tester's machine, or the off-site box was touched. No product code was written. The real catalog was never changed.