Leads with what held — nothing lost a byte, the set-aside really is set aside (verified 12.5 MB untouched at the far end), a wrong code refused three times with nothing written and no lockout, the alarm fired and cleared itself. Then the four new findings in operator language: R-224 (our own systems being down is reported to the customer as a bad recovery code — the same lie as yesterday through a different door, and the machine had not even tried the code: three hundredths of a second against a real attempt's one second), R-226 (a mistyping customer can no longer be told to check their typing), R-225 (0 snapshots / 0 GB shown above a paragraph saying the store holds backups), R-228 (the set-aside backups become invisible). States explicitly that nothing was fixed last night, on purpose.
This commit is contained in:
@@ -44,6 +44,34 @@ code was wrong. *(CAMPAIGN 11)*
|
|||||||
- **The off-site copy can be erased by the machine that made it.** A daily snapshot is armed as a
|
- **The off-site copy can be erased by the machine that made it.** A daily snapshot is armed as a
|
||||||
stopgap. *(R-95, R-87)*
|
stopgap. *(R-95, R-87)*
|
||||||
|
|
||||||
|
## What last night's stress test found (2026-08-05/06, unattended)
|
||||||
|
|
||||||
|
We spent the night trying to break the recovery journey with eleven deliberate faults, then left the
|
||||||
|
machine alone and watched it run on its own. **The good news is real and worth saying first: nothing
|
||||||
|
we did lost a single byte.** When the customer chose "I do not want the old data", the old backups
|
||||||
|
were **set aside and not deleted** — we checked the far end of the wire and the 12.5 MB was still
|
||||||
|
there, untouched, to the byte. A wrong code was refused three times with nothing written and no
|
||||||
|
lockout. The machine's own alarm fired when we switched it off and cleared itself when it came back.
|
||||||
|
|
||||||
|
**What we found is that the machine still tells people the wrong thing when something else is wrong.**
|
||||||
|
|
||||||
|
- **Pull the plug on our own central system, and the customer is told their recovery code is bad.**
|
||||||
|
Same if the machine's in-house service is stopped. In both cases the code was **perfect** — and the
|
||||||
|
machine had not even tried it (we can prove that: a real attempt takes about a second, these failed
|
||||||
|
in three hundredths). The machine knows the difference internally and throws it away before anyone
|
||||||
|
sees it. **This is the same lie we fixed yesterday, coming back through a different door.**
|
||||||
|
*(R-224)*
|
||||||
|
- **A customer who mistypes is no longer told to check their typing** — on any machine that has been
|
||||||
|
given a new recovery code, that message can no longer appear at all. *(R-226)*
|
||||||
|
- **The backups page says "0 snapshots · 0 GB" when it cannot read the store** — directly above a
|
||||||
|
paragraph saying the store contains backups. It really held one snapshot and 12.5 MB. The machine
|
||||||
|
does not know the number and shows a confident zero instead of "unknown". *(R-225)*
|
||||||
|
- **After "I do not want the old data", the set-aside backups become invisible.** They are kept, and
|
||||||
|
the machine writes down exactly where — and then shows that to nobody, ever. *(R-228)*
|
||||||
|
|
||||||
|
**Nothing was fixed last night, on purpose** — a campaign that fixes as it goes is measuring a moving
|
||||||
|
target. Everything above is written down and ready to work on.
|
||||||
|
|
||||||
## What shipped recently
|
## What shipped recently
|
||||||
|
|
||||||
- **2026-08-05 (late)** — **New machines now get current software again — and the disc image had been
|
- **2026-08-05 (late)** — **New machines now get current software again — and the disc image had been
|
||||||
|
|||||||
Reference in New Issue
Block a user