1145 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
admin	810b18ab8e	R-361 follow-on: the undo-copy prune must run above the already-current check ... Excluding pre-restore-* from db_dumps made that list stable across restores, so CaptureRecoveryUnit's already-current early return began firing where it never had - and the prune, which sat after it, stopped running in exactly the case it exists for. Measured on demo-hp minutes after the change: four undo copies on disk against a cap of three. The prune is housekeeping on the dump directory and is independent of whether the manifest needs rewriting, so it belongs above the check. Pruning cannot disturb dbDumps, which no longer contains those names. Pinned by TestR361_UndoCapHoldsWhenTheUnitIsAlreadyCurrent; its red-proof moves the call back below the return and the cap fails at 5.	2026-08-23 00:02:32 +02:00
admin	968c968559	R-361: the safety dump destroyed the app's own database backup ... writeSafetyDump called DumpOne into the app's OWN unit dir and renamed the result to pre-restore-* afterwards. DumpOne writes <stack>-<dbtype>.sql - the app's canonical dump - so every safety dump overwrote the app's real backup and then moved it away, leaving the app with no database backup until the next nightly run. A local restore-from-unit in that window tells the customer the app never had a database. The comment beside it asserted the rename meant it 'can never overwrite the app's real dump'. False as written, and believed for four months. Measured live before the fix: docmost and bookstack each held only pre-restore-* files and no canonical dump. DumpOneTo takes the final path and derives its own .tmp from it. DumpOne keeps its signature and calls it with the canonical name. writeSafetyDump asks for its own name directly; the rename is gone; the comment now states the invariant and how it is enforced. db_dumps no longer lists the undo copies. All three consumers of Manifest.DBDumps were grepped and named - all inside recovery_unit.go, none reads it for recovery. The files are neither deleted nor hidden. Tests 1485 -> 1493. FIVE red-proofs, TWO PASSED first time and both are reported: the behavioural tests inject the dump seam so a mutation inside DumpOneTo was invisible, and 1.3 had no test at all. Guards added at the layer each defect lives in; both mutations then convicted.	2026-08-22 23:39:59 +02:00
admin	2024ed9982	CONTEXT + README: the failure ladder and the operator ruling (v0.220.x)	2026-08-22 18:40:33 +02:00
admin	1a2405e86f	R-379: --clear-restore-hold now states the required restart ... It runs as a second process: it clears settings.json but the running controller keeps its in-memory copy and goes on refusing. Measured on demo-hp - clear succeeded, file correct, start button still refused until a restart. Also records the lost-update window between the two processes, and why clearing through the running controller (the right shape) needs an operator tier the controller's HTTP surface does not have.	2026-08-22 18:21:47 +02:00
admin	5b52a5964d	R-379 fix: the rollback must re-discover the DB container ... Found by v0.220.0's own live walk on its first real run. writeSafetyDump captures its DiscoveredDB before the stop; the DB-only start then re-creates the container with a new id, so the rollback's docker exec hit a dead container and sat in waitDBReady for 30s. The app was held for an infrastructure reason while its data was recoverable. Re-discover and match by {stack, engine} - what reimportDBDumpsFrom already did. Fail closed when the container cannot be found. No unit test caught it because they all inject the import seam and never look at container identity. The new test asserts the identity handed to the import.	2026-08-22 18:14:31 +02:00
admin	2c724c9283	R-379/R-380: put the customer's undo copy back when a database restore fails ... R-379 and R-380 were one failure. Both ended with a half-restored database; the only difference was whether it looked broken. Postgres emptied and crash-looped; MariaDB applied part of the dump and reported health=healthy with a zero-row schema-version table. Measured live on demo-hp 2026-08-22. The undo copy was already taken and already good - proven by hand that day on both engines. Nothing in the product could apply it. Now it does, with the same ImportDump call, before any restart and inside the DB-only window. The WHOLE undo set, matched on this run's stamp. writeSafetyDump returned one path for an app with two databases; a rollback on that would restore one and leave the other half-written. When the rollback also fails the app is HELD STOPPED (operator ruling): a running app on a half-written database lets the customer make the damage permanent. Every start path refuses it - customer button, appstop Recover, boot sweep - via the shared driveStartGate, checked ABOVE its driveless early return because these apps have no drive. The marker is ended so nothing auto-restarts it. The row goes red. Cleared with --clear-restore-hold, an operator CLI route. --single-transaction is a belt on Postgres only; MariaDB DDL is not transactional and that is why the rollback is the fix. R-381: the engine's stderr stops reaching the customer (615 bytes on MariaDB, its middle rows out of their own database) and starts reaching the operator log, which never had it. R-382: the summary log prints the volume count it already held. Undo copies resolve to their own app, are marked IsUndo, and are capped at 3 per app, pruned from the capture side. The reported render-as-an-app symptom did NOT reproduce - the live page was read first and had zero occurrences. Tests 1468 -> 1483. Eight red-proofs; ONE PASSED and is reported: the R-381 behavioural test injected below ImportDump. A guard at that layer now convicts.	2026-08-22 18:03:18 +02:00
admin	0f3cf0dbb2	CONTEXT: R-356 design decision (v0.219.0)	2026-08-22 13:26:57 +02:00
admin	c1dbb05ad6	README: where an off-site restore puts the data (R-356, v0.219.0)	2026-08-22 13:26:44 +02:00
admin	cbc3fa589c	docs: R-356 CONTEXT + REPORT (v0.219.0, proven live on demo-hp)	2026-08-22 13:25:36 +02:00
admin	08eb1a6e3a	R-356: the off-site restore refused every app that has no data drive ... ReconstituteFromOffsite and PlaceOffsiteRestore both resolved the restore destination with the RAW HDD_PATH and read an empty answer as "the app is not installed". For 40 of the 53 catalogue apps that answer is correctly empty and permanent, so both actions refused forever for a running, healthy app — and told the customer to reinstall it "in the same place", which those apps never offer. Separate the two questions. "Installed?" is asked of ListDeployedStacks via a new Manager.isStackDeployed that fails CLOSED on a nil provider. "Where?" is answered by GetAppDrivePath — the same resolver CaptureRecoveryUnit wrote the snapshot with, so the restore aims at the place the backup came from. The 13 drive apps are unchanged: own drive, mismatch check, ack still required. A third refusal, with its own sentence, covers installed-but-no-resolvable-root. Fixtures that marked an app "installed" by giving it an HDD path now state deployment as its own fact. No assertion weakened.	2026-08-22 13:08:46 +02:00
admin	2da259af38	docs(v0.218.0): README names the volume leg and the compose-project attribution; CONTEXT records the blocker ... The README's reconstitution sequence gains the volume replay it never had, and the AppBackup row states that DiscoverDatabases now prefers the compose project label. CONTEXT records the thing an operator most needs next: R-354's fix cannot reach the 40 apps that need it most until R-356 is closed, because the off-site restore still refuses outright for every app that declares no data drive. The live confirmation was therefore done on calibre-web and paperless-ngx.	2026-08-22 09:58:57 +02:00
admin	5ce3a44645	v0.218.0: attribute a DB container by its compose project, and replay volumes on the off-site restore ... R-355 (first, because it is the only one where data can be lost for good). paperless-ngx's PostgreSQL was dumped into backups/primary/paperless/db-dumps/ — a directory for a stack that does not exist, on the system drive — while the app's own unit recorded db_dumps: null. The same misattribution reached writeSafetyDump, so a destructive restore of that app took NO undo copy and the fail-closed refusal was never reached. Fixed by reading the compose project label, which is the stack name by construction (compose runs with cmd.Dir set to the stack dir and no -p). The old derivation stays as the fallback and an unresolvable attribution is now loud. Catalogue sweep, proven able to convict: one affected app of 53. The fix is in the controller, not the catalogue. R-354. ReconstituteFromOffsite skipped every unit placement and the volume archives live inside the unit, so the off-site restore had no volume leg at all — proven live with planted files: calibre-web's 1,422,848-byte config archive was in the unit, the snapshot and the checking folder, and the restore reported success without it. For the 40 of 53 apps that declare no data drive that archive is the whole dataset. restoreDockerVolumesFrom is the local path's own replay with an explicit directory: ONE implementation, two callers. Volumes replay before the database and inside the stopped window. VolumesReplayed reaches the message. The comment beside the skip was half false and is corrected; the half that still holds — the live unit is the local path's source — is named, and scenario D fingerprints the whole live unit across the operation. Seven red-proofs, each asserted applied and reverted. Two found defects in the tests, not the code: scenario D passed with the unit guard removed because the fingerprint had been narrowed and was blind to the unit root.	2026-08-22 09:43:22 +02:00
admin	f94543ee5c	v0.217.0: prefill from the app's own backup, where-the-data-goes on deploy, bounded inventory fan-out ... Completes R-351 and ships R-352's visibility half. Gates 11/11 OK, suite 28 packages ok, go vet clean, -race clean on the changed package - all run and read BEFORE this commit. PART 2 SCENARIO A - the deploy page prefills the address and data folder from the app's OWN backup. backup.RecordedUnitForStack scans every readable namespace root (the app is NOT installed in this case, so there is no own drive to ask) and reads manifest.json plus the captured compose/app.yaml. Local file reads only: no network, no restic, no restore. RecordedAddress.Known() requires BOTH halves on purpose - an absent SUBDOMAIN makes the live deploy path substitute the CATALOG default (stacks/deploy.go:88-90), and offering that back as "what your backup says" would be a fabricated fact. The prefill is labelled as coming from the backup and stays editable: a memory, not a lock. PART 1 VISIBILITY (R-352) - the deploy page now states where the app's data will live before the button is pressed. Measured 2026-08-21: 13 of 53 catalogue templates declare a storage field; the other 40 have none and their data goes to the system drive, which no screen said. Metadata.HasDeployField answers "does this app have somewhere to PUT a recorded value?" - for the 40-class a recorded placement is a fact to state, never a value written into a field that does not exist. NO PLACEMENT CHANGED. NOTHING MIGRATED. The rest is a filed specification. PART 4 - measured before theorising, on the live off-site target: snapshots --json 2605 ms once; stats 2697 ms PER APP, sequential, 5 app tags => 2605 + 5*2697 = ~16.1 s, matching the reported ten-to-fifteen seconds. The cause is the shape already on file, so the per-app size calls now run concurrently, BOUNDED TO 4. The bound is the safety property, not the speed one: the repository is a Hetzner Storage Box with a session cap, and a refused size call returns SizeBytes 0 - a silent UNDER-REPORT of the customer's data rather than a visible failure. Peak-in-flight is asserted. OffsiteInventoryList had no test at all before this. TEMPLATE SAFETY - every Restore* key is set UNCONDITIONALLY in the deploy handler, because a template doing index/eq against an undefined key errors at RENDER time: green build, green vet, green suite, 500 on the page. Four render tests, one per branch, because the existing deploy render test only renders AutoFields and never reaches these blocks. RED-PROOFS, mutation asserted applied then reverted to 0: A three template guards dropped (count asserted 3) -> the blank form returned P4 inventorySizeConcurrency = 1 -> "peak in flight was 1", elapsed 282ms = sequential DOCS: CHANGELOG v0.217.0 (MinAgent 0.129.0 unchanged), CONTEXT (the restore's own memory + what is next), controller/README.md (Backup System), REUSE.md (4 new rows), REPORT.md overwritten - the previous REPORT preserved to audits/REPORT-v0.216.0-2026-08-14.md first. NOT fixed here, filed as R-353 and named the next session's first item: a restore whose unit carries no db_dumps and no volume_dumps still reports a bare completion.	2026-08-21 21:29:01 +02:00
admin	985388c6e9	R-351: the restore compares where the backup says the data lived; second press cannot start a second run ... Part 3 (not droppable) and the engine half of Part 2. No version bump yet - one bump and one bake at the end of the session. PART 3a - a second press really did start a second run. Established with a test BEFORE any change: both offboxReconstituteHandler and offboxPlaceHandler answered "...elindult" and overwrote the first restore's op/stack. Cause: every restore handler gated on backupMgr.IsRunning() - the CONCURRENCY flag, which the restore goroutine acquires AFTER the handler returns (offbox_reconstitute.go:180, offbox_restore.go:393). Seven sites. The wizard had read the correct flag since v0.154.0 and said so in a comment; the handlers never moved. New Server.restoreOpBlocked() reads BOTH flags - the display flag covers the whole off-box restore, the concurrency flag is the only one the nightly backup holds - and the refusal now names the running app and a route. PART 3b - the page DOES refresh; the defect was the RESULT. backups_shared.html gated the terminal result on a page-local sawRunning flag, so a restore that finished before the page was opened, or inside one 3s poll, was shown to nobody. The 2026-08-21 OpenGist restore took 8.666s and no screen ever said it completed - the answer existed only in docker logs. RestoreOpStatus.LastRecent now carries the server's verdict. The 10-minute window moved to internal/backup as RestoreResultWindow and internal/web's constant is an alias: one expression, two surfaces. Also removed the wizard's self-contradiction, which said the state refreshes automatically AND that you must refresh the page. PART 2 (engine) - every recovery unit manifest has carried drive and namespace_root since schema 1, and NO non-test code read either back. The reconstitution opened the manifest and took only the coherence stamp, then resolved its destination from the live app. A restore into a different destination succeeded silently under a green message. New backup/offbox_placement.go: CheckPlacement (pure, total), PlacementMismatchMessage, recordedPlacementFromScratch. Compared before the safety dump and before the first byte. A mismatch is NAMED and refused; ackPlacementChange lets the customer proceed deliberately - a separate field from confirm=1, because one click must not carry two decisions. An UNKNOWN recording is never a mismatch: refusing on an absence would strand every pre-field unit. The not-installed refusal (R-253) now names the drive the backup recorded. RED-PROOFS, each mutation asserted applied and reverted to 0: B both guards removed (count asserted 2) -> the restore WAS seen starting with no drive attached: no error, full 3.00s run, wrote into /tmp/mutant-destination C Mismatch forced false -> the silent divergent restore returned E Known() forced true -> the fabricated empty prefill appeared D Mismatch forced true -> 8 ordinary reconstitute tests broke, proving reachability both ways Note on D: the existing fixtures write a schema-1 manifest with NO drive, so they are scenario-E shaped. The matching case is covered in the scenario table, not by them. Gates 11/11 OK. Suite 28 packages ok. Hungarian verified as hex, no BOM, no mojibake sentinels. NOT in this commit, still open: Part 2's scenario-A prefill UI, Part 1's deploy-page visibility line, Part 1's specification document, Part 4's measurement.	2026-08-21 21:04:16 +02:00
admin	2fa1efc5e5	docs(REPORT): confirming cycle on v0.216.0, and persistence proven live ... - 09:31:35Z on 0.216.0: '2 disk(s) evaluated, 0 alert(s)' — the count now matches the 2 persisted records, closing the disagreement that exposed R-335. - The 0.215.0 -> 0.216.0 redeploy replaced the container and the state file came back with a changed_at written by the PREVIOUS version, so the new container loaded the pre-restart record instead of re-baselining. Scenario L observed on real hardware, not just through the production-path unit test. - R-332 narrowed accordingly: what remains unproven is an already-ALERTED disk not re-alerting after a restart.	2026-08-14 11:33:11 +02:00
admin	330e4a051e	docs(REPORT): v0.215.0 -> v0.216.0 run report ... Includes the two clean live cycles, the warning-vs-warn notification_log proof, the 13 red-proof outcomes (A reported as a finding — the spec's mutation for it is not a valid red-proof), and section 14 on R-335, the aliasing defect found live in v0.215.0 and fixed in v0.216.0.	2026-08-14 10:33:22 +02:00
admin	90f2545679	fix(disk-health): one physical disk must be evaluated once per run (R-335) ... Found on live hardware two hours after the v0.215.0 deploy, by noticing the release's own positive observable disagreed with its own persisted artefact: the check logged '3 disk(s) evaluated' while disk-health-state.json held two records. demo-hp's c11-scratch and felhom-backup are the same NVMe and share a durable id, so one disk was walked twice per run. Not cosmetic. The loop writes a disk's record before the next entry reads it, so the second copy of an aliased disk consumed the FIRST copy's write as its prior: the disk sustained against ITSELF and reached Hiba on a first sighting, defeating truth-table row 6 — the rule that separates a one-hour benign excursion from a false critical. It would also have emitted two identical events for one drive. Latent on demo-hp only because all counters are zero. Each diskKey is now evaluated once per run. Both entries stay marked seen so neither looks like a disappeared disk, and the card still renders both rows — the dedup is about state and alerts, not display. Red-proof run and reverted: deleting the guard makes the first sighting emit Kind:2 (Hiba-from-sectors) at 8 sectors.	2026-08-14 10:30:22 +02:00
admin	8144a70a72	docs(v0.215.0): CHANGELOG, CONTEXT decisions, README feature, REUSE entries ... - CHANGELOG leads with the severity fix and the live warning-vs-warn proof. - CONTEXT records the settled decisions so they are not re-litigated: Hiba is the label for predicted failure (no fourth word); sustain before count and why; the provenance of 64/55/60; phase 2 owns the new SMART attributes because they are a wire change under G-1; phase 1 state is one record per disk, not a series. - README documents the 14-row ladder, the persisted state, the hourly cadence and the five message shapes. - REUSE pins the severity wire contract on PushEvent — the defect's real home, so the next typo'd severity is caught at the table rather than in production — and records priorFor vs cardPriorFor, which differ by one observation and make the chip disagree with the email if mixed up.	2026-08-14 08:34:31 +02:00
admin	34d83f5a02	feat(disk-health): poll hourly, not 6-hourly — measured, not assumed ... Part 4 was gated on a measurement. On demo-hp (Tier 0) the controller's real /disks fetch — fetchDisks, the same path the check uses, not the 60s card cache — costs min 0.805s / median 0.821s / max 0.841s over 10 calls, all HTTP 200, across 3 physical disk rows (2 distinct devices). Median is 6x under the 5s bar, so the <5s branch applies and the interval drops 6h -> 1h. Why it matters: the one real failing drive's benign excursion lasted about ONE HOUR and cleared completely. A 6-hourly sampler can land either side of an excursion like that, see nothing, and then catch the terminal run half a day late. The smartd history that produced the whole analysis sampled every 30 minutes and only just resolved the shape.	2026-08-14 08:21:55 +02:00
admin	c24f1920d9	test(disk-health): Group L must run TWO checks after the restart ... One check cannot distinguish a loaded state from a silent re-baseline — a forgetful controller is also silent on its first check. It betrays itself on the second, when the rebuilt prior makes the disk look newly sustained and it alerts all over again. Caught while building the companion red-proof: with the state load skipped, the single-check version still passed.	2026-08-14 08:12:44 +02:00
admin	bb50e1293c	fix(disk-health): the alert that never sent — severity, a real Hiba level, and a memory that survives a restart ... Three defects made the disk-health feature silent in exactly the case it exists for. Evidence: felhom.eu documentation/audits/DIAG-smart-passed-trap-2026-08-14.md 1. SEVERITY (the one that changes whether anything arrives at all). NotifyDiskHealthDegraded emitted severity "warn", which is NOT in the hub's accepted set {info,warning,error,critical}. The hub coerced it to "info" (hub/internal/api/handler.go) and severityNotifies dropped it (hub/internal/notify/dispatcher.go), so every Figyelmeztetes-level disk alert was filed as an informational notice and emailed to NOBODY, on the customer and the operator leg alike. Now "warning". DiskAlertKind.Severity() is exported so the contract is checkable from any package. 2. NO LEVEL ABOVE "worth an eye". smart_status.passed CANNOT fail on unreadable sectors (attrs 187/197/198 all carry thresh 0 and a normalized value floors at 1), so Hiba was unreachable for this whole fault class. DiskVerdictFor now takes a DiskPrior and implements a 14-row top-down ladder: sustained unreadable sectors, a count too large to be a blip (64), unreadable+remapping together, overheating, NVMe critical flag or spent endurance all reach Hiba. No fourth label — predicted failure is "Hiba". 3. IT SPOKE ONCE, AND FORGOT ON RESTART. The baseline was in-memory, so a box that rebooted while a disk was failing never alerted again; and between 8 and 352 sectors nothing was emitted at all. State is now persisted (disk-health-state.json, atomic tmp+rename), the decision compares against the last ALERTED verdict (collapsing flaps to one alert while letting a genuine escalation fire immediately), and a disk already at Hiba re-alerts once it has BOTH doubled its count and waited out a 24h cooldown. The card replays the same prior the check used (diskRecord.PriorSawUncorrectable) so the chip and the email cannot disagree — the property the shared verdict function exists to guarantee, now pinned rather than asserted. Tests: 12 scenario groups A-L. Group L builds the Server through web.NewServer, the same call main.go makes, over a real file.	2026-08-14 08:10:59 +02:00
admin	3e3ee94b7b	REPORT: live 422 proven on hardware; R-308 withdrawn (my quoting bug, not a stale credential)	2026-08-12 19:05:23 +02:00
admin	ae10f64806	REPORT: controller v0.214.0 — the screen stops hedging, and the claim guard grew a surface	2026-08-12 18:49:56 +02:00
admin	3ed5e3e770	v0.214.0 — the recovery screen stops hedging about a code it can now check (R-311) ... MinAgent: 0.129.0 What was already right: the screen did not bluntly accuse. R-222/R-226 hedged, naming both causes and the kept package, and saying it could not tell them apart. That was honest - and it could not tell them apart because nothing ever looked. Agent v0.129.0 looks, so the hedge becomes an answer. New class RecoveryCodeOpensRetained on HTTP 422, gated by FeatureRetainedRecoveryClass (MinAgent 0.129.0). The gate is SEPARATE from the R-224 one because the two name different agent versions and a box can sit between them, where a 422 is a shape we did not design. ClassifyRecoveryFailure therefore takes both flags; the compiler found every call site. The message says the code is correct, names the supersession date, says the earlier package is kept, and says the CURRENT backups are unaffected - the half a customer will otherwise assume wrong. It promises NO restore: there is no in-product route to a set-aside store (R-312) and the retained package may itself predate the repository-password field. It routes to support, which can do it. The claim guard grew a surface and immediately convicted something. It scanned templates only, while every recovery message is a Go string in a handler - the highest-stakes copy in the product, never scanned. It now scans recovery_handlers.go too, and found a PRE-EXISTING unregistered claim on its first run. Six handler tests asserting which SENTENCE the customer sees; red-proofs asserted applied, including: 422 unconditional makes an agent that never looked read as having looked, and routing 400 to the new class congratulates a mistype.	2026-08-12 18:42:02 +02:00
admin	3168a78935	REPORT: v0.213.0 pinned-fingerprint condition, red-proofs, claim guard	2026-08-12 15:39:08 +02:00
admin	89712563a0	R-302: the abandon banner promises only what the box can still see is true ... The retrieval clause rendered unconditionally on every page and is false on a reachable state - the same screen where the orphan card says we cannot tell. The condition is a fingerprint PINNED at the decision, not a comparison against the current key. The obvious proxy asks about the wrong key: the set-aside copies were written under an older key the box no longer has, so on a twice-rebuilt box the proxy promises about copies nothing can open. Demonstrated - under the proxy, the replaced-package and legacy cases both flip back to promising. The pin is a recorded assumption and says so: nothing on the box records which key wrote those copies. Empty is not a match. A countdown started before this carries no pin and takes the cautious branch, not a backfill. A sweep of all 36 templates found a fourth instance (backups page, same condition applied) and a fifth (the confirmation screen, correctly left alone - true at the moment of the decision). New retrieval_promise_gate registers each claim with a reason rather than banning a verb: a string ban failed twice, and the honest replacement copy contains the stem.	2026-08-12 15:27:29 +02:00
admin	1b66010298	REPORT: v0.212.0 orphan card second promise	2026-08-12 14:05:45 +02:00
admin	68f3e12398	R-299: the orphan card's second promise, and a guard that matched one inflection ... The explanation paragraph - the always-visible half of the card - still ended 'a hozzajuk tartozo helyreallitasi koddal kesobb visszaallithatok lehetnek', the same unevaluable claim v0.211.0 removed from the confirm block below it. It survived because the spec called that line accurate, and because the regression guard asserted the SINGULAR form while the card carried the plural, which does not contain that substring. The guard now matches the stem, so any conjugation fails it. The two accurate halves are kept. Also: the guard's failure message sliced rendered HTML at a byte offset and cut Hungarian mid-character; it now slices on rune boundaries.	2026-08-12 13:49:15 +02:00
admin	f87be3575f	REPORT: correct installer publication status	2026-08-10 14:20:22 +02:00
admin	38f4535bfa	REPORT: golden 0.211.0 baked and published; only the Day-0 vouch remains	2026-08-10 14:20:08 +02:00
admin	397d62136f	REPORT: v0.211.0 written, not delivered - bake and Day-0 approval outstanding	2026-08-10 13:58:45 +02:00
admin	86a78c6767	R-294/R-295: orphan card stops promising restorability; one name per secret ... The orphan card told a customer their set-aside off-site history may be restorable later with their recovery code. The discriminator lives on the hub and no wire field carries it, so the box rendering that card cannot evaluate the promise. Copy replaced per the spec: state what happens, decline what we cannot know and say why, name a route. The claim page called the same three-word dashboard code two different names depending on branch, one of which collides with the ten-word escrow code. Retired 'Visszaallito kod'; the name is now constant and the sentence changes. Naming only - a test pins that a reset code is still accepted. secret_in_markup_gate no longer convicts Go template comments, which are stripped before render; still convicts a real rendered secret.	2026-08-10 13:53:21 +02:00
admin	b762a37097	R-280: attach list from mounted-but-unregistered filesystems; two-clicks promise made conditional ... After a reinstall the data drive could not be re-attached through any dashboard route: both candidate lists came from the agent's unclaimed-disk scan, and the rebuilt box's drives are claimed. The restore page said it was two clicks while pointing at an empty picker. The attach list now also carries the controller's own mounted-but-unregistered filesystems. initialize is untouched, so the format wizard's system/backup protection is unchanged. The 'two clicks' sentence is conditional on the picker being non-empty, and says something true and actionable when it is not.	2026-08-10 13:41:32 +02:00
admin	c732fe1283	v0.210.0 — R-259 and R-258: two pictures that were not true ... Both are one shape: something the box already knows, drawn as its opposite. R-259 — A DISK WE FAILED TO READ WAS DRAWN AS A HEALTHY EMPTY DISK. readDiskUsage (internal/system/info_linux.go) logged a statfs failure at DEBUG and returned, leaving the caller's TotalGB/UsedGB/AvailGB/Percent at zero — and usageColor(0) is "nominal". The dashboard's most-looked-at meter therefore rendered "0.0 GB / 0.0 GB (0%)" with a 0%-wide bar in the healthy colour. "We could not look" and "there is plenty of room" were the same picture. readDiskUsage now returns whether the measurement succeeded; SystemInfo gains DiskKnown and HDDKnown (HDDConfigured is not a substitute: it says a path was configured, not that reading it worked); and the template draws NO figure, NO percentage and NO meter fill when unknown, saying "A tarhely merete most nem olvashato ki." instead. A healthy box is byte-identical, colour band included. This session rules the convention (felhom.eu CONTEXT.md S-39): an explicit `...Known bool` companion beside the figures, checked in the template — the shape Offbox.StatsKnown already uses, whose own comment says "a 0%-wide bar over an unread store is a picture of emptiness, and a picture is a claim". Pointers and separate error fields are both legitimate Go, but a codebase with three dialects cannot be gated (ROADMAP G-3 was blocked on exactly this). Existing call sites NOT converted. R-258 — THE PER-APP BACKUP TICK WAS GREEN ON PRESENCE, AND RED ONLY ON A GLOBAL CONDITION. buildAppBackupRows set Tier1LastStatus from status.LastDBDump.Success, which is the box's single most recent dump RUN, whichever app it belonged to. An app whose own dump failed showed a tick as long as some other app dumped successfully afterwards; an app with no database took the nil branch and went green on the mere existence of a restore point. appDumpVerdict now reads THIS app's own entries in DBDumpStatus.Results (matched on DumpResult.DB.StackName, failure = non-nil Error). Three states: any failing database -> error; all clean -> ok; no result recorded -> NO verdict and no icon, titled "Errol a mentesrol nincs eredmenyunk." The recovery unit carries no per-run outcome of its own, so green cannot honestly be derived from presence. The global tier1DBStatus label is untouched — it is correct as a global. RECENCY IS DELIBERATELY NOT ADDED. A tick over a three-week-old restore point is a real weakness, but an age threshold means inventing a number and the time is already printed beside the icon. Recorded as an observation, not changed. AN EXISTING TEST WAS ASSERTING THE DEFECT AND WAS CORRECTED, NOT DELETED: TestBuildAppBackupRows_Tier1FromRestorePoints expected "ok" for a status with no LastDBDump at all — green from nothing but a file's existence. It now expects no verdict; its real subject, the Tier1LastRun time, is unchanged. The dashboard test EXTRACTS the meter block from the shipped template rather than copying it: a copied block drifts, and a drifted copy passes while the page it claims to cover has changed — the fixture-is-not-the-wire mistake this project has now hit twice. Six red-proofs across both parts, each with the mutation asserted applied. No new tag on any declared wire — report/builder.go maps into its own types and is untouched; wire_contract_gate.py confirmed green. go build / go vet / go test ./... green (28 packages), controller_gates --fast all OK, both run separately from this commit.	2026-08-08 16:29:52 +02:00
admin	fcffaf573a	v0.209.0 — R-247: the box stops saying a false thing about its own recovery package ... The answer was on the wire and was discarded at the boundary, for the third time. The hub has sent `escrow_stale` in the report ACK since v0.57.0 (json:"escrow_stale,omitempty"). report.EscrowStatus had no field for it, so encoding/json dropped it, and an empty restic_pw_sha256 had exactly one possible reading here: "hash-less supersession". On demo-hp that reading was false in EVERY clause for four days, and the box told the customer so in its own words. The hub HAD the hash and was withholding it because the escrow row carries a stale flag (R-246); there had been no supersession; and the bundle DID cover the password — the hashes matched exactly. Fixed by receiving the field. EscrowStatus.Stale decodes, and reconcileEscrowed tells the two conditions apart: a withheld hash now reports that the hub has flagged the row and is withholding, that this box therefore cannot verify its bundle either way, and that it is NOT established that the bundle fails to cover the password. The genuinely hash-less case keeps its wording. Deliberately NOT changed, and said rather than skipped: the stale verdict itself (the hub's flag is still the hub's verdict; runs still continue), and the customer-facing Hungarian card copy. Clearing the wrong flag is an operator act hub-side (R-246); re-wording the card is UI work with its own review path. This change is the wire and the diagnosis. Found by felhom.eu/scripts/wire_contract_gate.py (G-1), which was built first and seen failing on 40 fields before anything was fixed, and which now refuses any new field of this shape. go build / go vet / go test ./... green, run separately from this commit.	2026-08-08 08:46:29 +02:00
admin	37b5ba08a7	REPORT: v0.208.0 — both R-254 sites, the guard's measured holes, and what the live read could not prove ... Records the deliverables, and is explicit about the limit on the live half: the curl of an app info page could not be done, and names exactly what was tried — crafty-controller is the only app declaring initial_credentials and is deployed nowhere, and demo-hp's dashboard password in ~/.config/credentials no longer authenticates (200 with no session cookie). A probe of the new routes was discarded because its control killed it: real and bogus paths both 302 behind the auth middleware. §7.2's answer including the part that contradicts the task's premise: no line in the repo says 'no silent auto-fill'; the rule is CONTEXT.md:2070 about accidental EMPTY-password deployments. The hidden input is deliberate and untouched. §7.4's measurement: the gate covers all 36 templates and catches a launder through a local variable, but is blind to a secret under a neutral page-data key — the exact shape of site two. Runtime coverage is 4 of 27 pages. Filed as R-255 rather than described as complete. §7.3: no evidence of actual exposure on the fleet, with the limit stated — it is a current-state measurement and nothing recorded reads, which was part of the fault. Also corrects v0.207.0's report: html/template STRIPS HTML comments; they do not ship in the response body. Measured.	2026-08-07 21:29:13 +02:00
admin	27d1165962	v0.208.0 — R-254: the last two secrets leave the page source, plus a gate against a fourth ... Site one. app_info.html rendered {{.InitialCreds.Password}} into a hidden span — a REAL per-install credential, read live out of the running container, in the response body of every render. The page now carries the non-secret half plus a boolean; the value comes from POST /apps/<slug>/initial-credentials/reveal, which RE-READS the container rather than serving a cached copy (caching it in the handler would put it back in the body one layer in). no-store, CSRF-covered, logged as an act. Both buttons go through it. A reveal that cannot read the value SAYS SO rather than returning an empty string that renders as a blank password. Site two, established before changing. The hidden input is NOT the defect and was left alone: it fires only pre-deploy, and README §318 documents why the value must round-trip — the customer notes the generated secrets down and submitting them back is what makes the saved value the same one they saw. The defect was the neighbouring READONLY input, which on an ALREADY-DEPLOYED app rendered the secret into a page with nothing to submit. Fixed by POST /stacks/<name>/auto-field/reveal, authorised by requiring a type:secret auto-field of that stack. Both directions pinned. The premise that this contradicted a repo rule does not hold: the rule is CONTEXT.md:2070 'Password fields require explicit input — prevents accidental empty-password deployments', about EMPTINESS. No line in the repo says 'no silent auto-fill'. The gate. scripts/secret_in_markup_gate.py, registered in controller_gates.py, convicts any template expression that names a secret unless allowlisted with a reason. Its limits are MEASURED and in its docstring: it catches a launder through a local variable (the assignment names the secret) but is blind to a secret arriving under a neutral page-data key — verified both ways. That is the shape of site two, which this gate would NOT have caught. The runtime body assertion covers all shapes but only 4 of 27 page templates; the other 23 are R-255, filed rather than glossed. Two nets, different holes, both named. Correction to v0.207.0's report: HTML comments do NOT ship in the response body here — html/template strips them, text/template does not. Measured. A red-proof planting a secret in a comment therefore correctly does not fail.	2026-08-07 21:20:26 +02:00
admin	62998aab4f	REPORT: v0.207.0 — R-249 before/after on a live box, the census, and what was NOT proven live ... Records the deliverables: the raw response body before (1 occurrence, v0.206.0) and after (0, v0.207.0) with a positive control in both directions; the §7.1 census finding two more instances of the render-then-hide pattern (R-254, one a real per-install secret); §7.2's decision and why the promise was the wrong half; every changed Hungarian string; all eight tests with their red-proof outcomes. States plainly what was NOT proven live: R-252/R-253's notices could not be rendered on VM 325 because both states are rebuild-only and the box re-registers a drive on restart — the live run therefore exercised Scenario E instead, and the notices are pinned at the template + predicate level with red-proofs. Also records that red-proof D caught a fault in my own work: the explanatory HTML comment quoted the old sentence, and HTML comments ship in the response body, so the contradiction was still on the page and the assertion forbidding it could never fail.	2026-08-07 18:33:37 +02:00
admin	8dbbc98ff2	v0.207.0 — R-249: the retrieval passphrase leaves the page body; R-252/R-253: two refusals learn to say what to do ... R-249. settings_security.html rendered the passphrase into a display:none span behind a Megjelenit button. That toggle stops a browser DRAWING the value and nothing else — the plaintext was in the response body of every render, so a curl of the page returned it. Found by exactly that: it landed in a session transcript while driving the documented rebuild path. The codebase already stated this rule for the recovery code and this page did not follow it (escrow_handlers.go: 'reveal (claim XHR only — R is NEVER templated server-side into HTML)'). The page now carries only HasRetrievalPassword; the value comes from POST /settings/retrieval-password/reveal — CSRF-covered because POST, no-store, and LOGGED as an act, which reading it off the markup never was. The tests assert the RAW RESPONSE BODY. Every test that asked what the customer sees passed while the bytes carried the secret; that is why this survived. Census: the render-then-hide pattern appears twice more — app_info.html (a real per-install app password in a hidden span) and deploy.html. Filed as R-254, NOT fixed here. R-252. A rebuilt box keeps its drives but loses their REGISTRATION. The restore page now states that before the customer presses anything, says the backups and drives are both still there, and links to Tarhely > Meghajtok. Page and resolver ask ONE question — HasRestoreDestination() reads the same GetSchedulableStoragePaths() the scratch resolver reads. R-253. The list promised 'a visszaallitas elobb ujratelepiti' three lines above a refusal that fired BECAUSE the app was not installed. The promise was the wrong half: reconstitution writes to the app's own GetStackHDDPath, which exists only once the CUSTOMER has chosen a drive at deploy time. Auto-reinstalling would mean the product making that choice for them. Copy now says to install first and routes to /stacks/<app>/deploy. Both notices are conditional — a healthy box renders as before, pinned by a test that fails if either becomes unconditional.	2026-08-07 18:04:26 +02:00
admin	3d3b4496f3	REPORT.md — R-241 fixed, deployed, live-validated on both demo boxes ... Scenario A's live result first: on demo-hp in the rebuilt shape, no key was minted on the real start-up offsite-apply path, and the hub received the state it reports instead - offsite.state=awaiting_recovery_key with enabled:false. Key restored byte-identical afterwards. Includes Q4's seven rows mapped to the three states, the SEC 7.2 choice and why, SEC 7.3's answer on the new-code button, every changed Hungarian string quoted, all nine red-proofs with what was mutated, the R-245 reasoning, and three observations noticed but not acted on.	2026-08-07 12:23:55 +02:00
admin	0a9158d53e	docs for v0.206.0: CHANGELOG, CONTEXT, REUSE, README ... CHANGELOG v0.206.0 with the ruling that reversed the fix, the three changes, the SEC 7.2 staleness decision, Q7's closed trap, and the two bugs the tests caught rather than review. CONTEXT carries the three rules this session established, in the form the next session needs them: - a box does not create a repository key while the hub holds a sealed package for it; - the fact that answers a question must be kept where the question is asked; - fix the state, do not remember that it is wrong. REUSE gains four rows, each carrying the trap rather than just the signature: the mint guard is a CONJUNCTION and t.Enabled is load-bearing in the derived predicate; the discriminator ships INERT unless wired in main.go's confirmer literal; the countdown removes BOTH halves or neither and must be driven by an injected clock; and the epoch must be synced FIRST and unconditionally or the falling edge is lost. README documents the three customer-visible changes and the operator levers. No version literal was edited: the controller version is ldflags-only.	2026-08-07 12:12:35 +02:00
admin	72368654e4	R-241 part 5: escalating reminders, and operator levers for a running countdown ... REMINDERS (SEC 2.3). The offer epoch now stamps when it began, and the undecided reminder escalates in EMPHASIS at 1, 3, 7 and 14 days. THE READING IS STATED BECAUSE THE SPEC IS AMBIGUOUS, and it is written into the code where it can be corrected. For an ABANDONING box, 5/3/1 are unambiguously days REMAINING before a deletion. An undecided box has no deadline - nothing counts down to anything, because SEC 7.5 deliberately does NOT auto-abandon - so 14/7/3/1 cannot be "remaining" and are taken as days ELAPSED, with the wording firming up rather than the bar appearing and disappearing. If the operator meant something else, one function changes. The stamp is re-set on every entry into the offered state, so a box that settles and is later rebuilt starts its ladder again instead of inheriting an old one. OPERATOR LEVERS (SEC 7.5). --abandon-status, --abandon-extend=N and --abandon-stop on the controller CLI, beside the existing operator subcommands. They exist because the path that ACTUALLY happens is the customer telephoning, and support needs something to press. They live on the CLI and not in the customer UI deliberately: extending a deletion the customer asked for is an operator judgement, and a customer who wants it stopped already has the self-service route - they recover with their code, which cancels it. BOTH REFUSE RATHER THAN NO-OP, in two situations: when no countdown is running, and when the store has already been deleted. A silent success is the thing an operator most easily mistakes for "handled" - they would tell the customer their data was safe when it is gone. Pinned by two tests. --abandon-extend counts from NOW, not from the old due date, and a test proves the old date passes without deleting anything. Green: go build, go vet, go test ./... all pass; controller gates OK.	2026-08-07 12:08:11 +02:00
admin	de39e47f53	R-241 part 4: the three-state surface, and the copy tells the truth about the date ... FULL PAGE ONCE PER ENTRY, NOT ONCE EVER. "Most nem" used to set a flag that nothing ever cleared, so a box that abandoned its history and was rebuilt months later - a genuinely NEW situation - would never see the page again. The offer now carries an EPOCH, advanced on the edge into the offered state, and a dismissal is recorded against the epoch it was made in. A fresh entry passes the dismissal by arithmetic, with nothing to clear and nothing that can be forgotten to clear. That is NOT the flag the operator's ruling forbids. The forbidden thing remembers that the customer decided so the screen can be suppressed while the state stays wrong. This records WHICH SITUATION a dismissal was about. A REAL BUG, caught by the test and not by review: the first draft returned early from recoveryInterrupts when the offer was false, so the FALLING edge was never recorded, RecoveryOfferActive stayed true through a settled period, and the next entry counted as a continuation. The page never came back - the exact defect the epoch exists to fix, reintroduced inside the fix. The sync is now unconditional and the ordering is commented as load-bearing. THREE LEVERS, THREE SCOPES, and none of them removes the route: - clicking the bar away -> a browser SESSION cookie, cleared on login, so the reminder is genuinely back at the next login. Nothing persisted. - "ne emlekeztessen ujra" -> durable, epoch-scoped, silences the BANNER ONLY. It starts no countdown, abandons nothing, and a fresh entry reminds again. - "most nem" -> suppresses the full page only, as before. The entry point on /backups/remote is bound to the OFFER and to nothing else, pinned by a test that fires all three dismissals and asserts it survives. SEC 7.3 / Q7 - THE TRAP DOES NOT SURVIVE THIS SESSION. While a recovery is outstanding the "Helyrealitasi kod letrehozasa" button is UNAVAILABLE, not merely captioned: creating a new code seals the current key, demotes the package that opens the earlier history to retained custody that no shipped path can read (R-199), and re-enables the recovery screen through the orphan route while invalidating the code that screen accepts. A warning beside a button is a warning people click past. The card now explains and points at /recovery instead. SEC 2.4 - the abandon confirmation changes with the behaviour. It used to promise "felretesszuk - nem toroljuk". It now states the grace in days (from the constant the countdown actually uses, never a literal in prose), that the sealed package goes with it, that the customer can change their mind, where the date is visible, and that the question does not come back afterwards. The countdown is shown on /backups/remote for the WHOLE window - the bar elsewhere is a nudge, this is the record, and a deletion date must be findable on a quiet day too. Tests: once-per-entry across a full settle-and-re-enter cycle; the banner dismissal proven to be a session cookie (MaxAge 0, no Expires) and to persist nothing; the opt-out proven to silence the banner while leaving the offer, the route and the countdown untouched, and to remind again on a fresh entry; the entry point surviving all three dismissals; a settled box showing nothing; and the back-redirect refusing "//evil.example". An existing test (TestRecovery_E) was updated: it asserted the legacy boolean, which the epoch replaces. It now asserts the dismissal landed on the current epoch, which is the stronger property. Green: go build, go vet, go test ./... all pass; controller gates OK.	2026-08-07 12:01:30 +02:00
admin	a5d90ff801	R-241 part 3: abandoning starts a 14-day countdown that ends the question ... Until now "set aside" renamed the remote store and touched neither the escrow nor the key, so the hub went on holding a sealed package for a key the box no longer used. Shape (c) compares those two, finds them different, and offers recovery - correctly, and for ever. A customer who had already said "I do not want the old data" would be asked again at every login. The operator's ruling is that the answer is NOT a "they decided" flag: fix the state, do not remember that it is wrong. So the decision starts a countdown, at the end of which the set-aside store and the sealed package that protects it are removed TOGETHER. Afterwards shape (c) has nothing to compare and the offer falls silent on its own - because the state is right, not because something remembers it once was not. THE GRACE IS REAL. The recovery offer stays reachable for the whole 14 days; that is the change-of-mind path, and a grace in which recovery is impossible would be decorative. BOTH HALVES OR NEITHER. Removing only the store leaves a package that opens nothing; removing only the package leaves ciphertext nobody can ever decrypt. The two cannot be atomic across two machines, so it is a two-phase commit: delete the store, record a durable marker, and keep DECLARING offsite.abandon_purge_requested until the hub's ACK stops reporting a superseded package. A crash between the halves re-declares on the next sweep; it never leaves the pair half-removed and silent. HUB HALF - SEC 8.2 ANSWERED: yes, the hub was needed, and only for this. store.PurgeSupersededEscrowForCustomer is the one place R-198's retention is ever undone, and it never touches host_escrow (the package covering the key the box uses now). The handler acts on the DECLARATION, never an inference, and is placed immediately BEFORE the ACK is built - so GetEscrowStatusForCustomer reads the effect and the SAME response closes the box's two-phase commit. No second round-trip and no window where the box thinks it is still owed. felhom-agent was NOT touched. The countdown starts in ResetOrphanedRepo, NOT in the shared helper: the helper is also the unclaimed auto-reset path, where nobody decided anything, and an as-delivered box tidying a stranger's leftover store must not get a customer's deletion clock. Pinned by a test. Cancellation is wired into the recovery unlock, BEFORE the tier-up and the listing - those can fail, and a countdown surviving a successful unlock because a later step errored would delete the history the customer just proved they can open. The sweep is a Daily job at 05:10, not on the backup leg: it must run on a box whose tier is not configured for runs. Quiet by construction on every box with no countdown, and that silence is asserted. Tests (all clock-injected; SEC 7.4 forbids shortening a live timer): Scenario E (aside + package kept + countdown + offer still reachable, and NOTHING deleted), Scenario F (both halves, the declaration repeating, the close-out), Scenario G (cancel, path still nameable, no later deletion), plus: not closed out while the package remains, a transport failure leaves the countdown due and retrying, the no-op sweep issues zero remote commands, and the unclaimed auto-reset starts no countdown. RED-PROOFS, each with the mutation confirmed present in the file first: F1) store deletion skipped -> Scenario F FAILS (no rm issued) F2) declaration dropped from the report -> Scenario F FAILS (the hub is never asked; the package would outlive the store for ever) G) CancelAbandon made a no-op -> Scenario G FAILS (uncancellable countdown) Green: controller and hub both build, vet and test clean; controller gates OK. NOTHING WAS DELETED ANYWHERE - the terminal step has only ever run against in-test fakes.	2026-08-07 11:47:42 +02:00
admin	a491abef6c	R-241 part 2: the comparison the box already makes becomes the thing that offers recovery ... THE FACT WAS COMPUTED EVERY CYCLE AND KEPT NOWHERE. EscrowAutoConfirmer.Reconcile has compared the hub's restic_pw_sha256 against the local key on every ACK since SLICE 3. On the final-walk venue it logged, at 03:28:03Z and thirty-five minutes before the customer looked, "the hub's escrow blob does not cover the CURRENT repo password (hub hash 30ef574f != local 9b4a9a9d)" - and dropped it. The recovery screen, evaluating in the same process, went on asking a question that could not see it. Now persisted: settings.HubEscrowKeySHA256 + HubEscrowKeyCheckedAt, recorded UNCONDITIONALLY in Reconcile beside RecordPresence and RecordSuperseded - same place, same reason: the box that needs it most is the rebuilt one with no target, on which every gate below returns early. OffsiteRecoveryOffer gains SHAPE (c): the hub holds a package for a key OTHER than the one we are using. (a) and (b) are both proxies for that question and both have now been wrong in opposite directions - (a) goes false the moment anything mints, (b) is unreachable while the escrow is pending. SEC 7.2, decided deliberately and stated in the code: - a KNOWN DIFFERENCE offers, however old the reading. Age is not gated on. Both sides are local; only the hub's half can be stale, and what the hub holds does not change without a ceremony THIS box runs, which refreshes the hash on the next ACK. Gating on age would make a box offline from the hub silently stop offering - the exact failure this session removes. CheckedAt is persisted for diagnosis, not as a gate. - an ABSENT hash falls back to (a)/(b) and does NOT offer. "" is the hub positively saying its package seals no repository password (legacy hash-less escrow). Nothing to compare, and offering would put a permanent screen in front of every legacy box. The write damper: CheckedAt refreshes on every ack carrying a hash, but a save is skipped when both the hash and the UTC day are unchanged, so an idle box does not rewrite settings.json every fifteen minutes. It records WHEN WE LAST HEARD, not when it last changed - the R-100 distinction. Tests: Scenario C (a differing key offers, with both proxies asserted false first), Scenario D (a matching key offers nothing), fact 1 still required, shape (a) still works, and both SEC 7.2 halves. RED-PROOFS, each with the mutation confirmed present in the file first: D) hubHash != localHash conjunct dropped -> Scenario D FAILS (a healthy box offered recovery forever); Scenario C still passes WIRING) RecordEscrowKeyHash removed from the EscrowAutoConfirmer literal in main.go -> TestMainWiresRecordEscrowKeyHash FAILS. This is the ships-inert shape: unwired, everything compiles, every test in the package passes, the auto-confirm still works, and shape (c) reads an empty hash forever. Green: go build, go vet, go test ./... all pass.	2026-08-07 11:33:42 +02:00
admin	763de3a025	R-241 part 1: the box does not mint a repository key over a sealed package ... THE DEFECT. WriteOffboxSecrets auto-generated on ONE input - does the file exist. Its two neighbours in the same file, OffsiteRecoveryOffer and needsOffsiteCredential, both consult GetHubEscrowIdentityPresent(). The same fact was available on three paths and used on two. Measured on the final walk: a rebuilt box's credential self-heal reached here at 03:18:06Z and minted 9b4a9a9d over a hub package sealing 30ef574f. The recovery screen then correctly reported nothing recoverable under the key the box held. The screen was honest; the minting was not. And the flag was not merely available at that moment - it was the PRECONDITION of the chain that reached this function, logged at 02:48:03Z, six ticks earlier. THE GUARD IS A CONJUNCTION, deliberately: a package held AND no key present. A box the hub holds nothing for mints exactly as before. The refusal is a HOLDING state, not a failure. ApplyOffsiteTarget catches the sentinel and still writes the transport (ssh key, known_hosts, coordinates), so the recovery screen can bring the tier up the instant the escrowed key is placed (R-219). Returning the error instead would leave needsOffsiteCredential true forever and the hub re-staging a consumed credential on every cycle. New declared state offsite.state=awaiting_recovery_key, shown INERT to every existing hub reader from their code rather than assumed: offsiteheal acts on exactly one string; isStale needs Enabled && escrowed and this carries Enabled=false; the delivery checker skips the applied shape; an unknown state string is ignored by encoding/json. So NO hub change is needed for this part. OffboxAwaitingRecoveryKey is DERIVED, not stored - the operator's ruling that the state should be fixed rather than remembered, applied to this field too. t.Enabled is load-bearing in that predicate and was MISSING in the first draft. The existing TestOffsiteDeclare_DisabledTargetIsNotStranded caught it, not review: a customer who switched off-site off is not awaiting anything. Now pinned from the new predicate's own side as well. Tests: Scenario A (no key written; transport still written; apply holds and stages nothing), Scenario B (first-time box still mints), idempotency, the nil-settings fail-safe, and the Scenario E carve-out. RED-PROOFS, each with the mutation confirmed present in the file first: A) guard block deleted -> both Scenario A tests FAIL with "R-241 REGRESSION: apply minted a repository password over the sealed package"; Scenario B still passes (the mutation is specific) B) guard over-widened (hub-package conjunct dropped) -> Scenario B FAILS with a first-time box unable to start; Scenario A still passes Green: go build, go vet, go test ./... all pass; controller_gates all OK.	2026-08-07 11:25:58 +02:00
admin	c6b69d888e	v0.205.0 — a run that skipped an app the customer selected is not successful (R-234) ... THE VERDICT. The R-203 block already said "a warning beside a success is read as a success" and applied it to ONE of the two shapes it describes: an app missing a declared mandatory FOLDER made the run incomplete, while an app skipped ENTIRELY still reported ok. Both do now. Which skips count, decided by measurement: selected+deployed with no recovery unit YES; selected but NOT deployed no (named, with what to do — a box left amber by an app somebody removed is a status nobody reads); disconnected/decommissioned drive no (own signal); nothing selected no. LastSuccess and SnapshotCount still record what WAS captured. THE FILED MECHANISM WAS NOT THE MEASURED CAUSE, and saying so is the point. §3 stated that toggling an app on leaves it without a bundle so the first run skips it. Measured on demo-hp: the run's own pre-dump phase calls captureAllRecoveryUnits for every DEPLOYED stack, through admitApp, before the push — a unit moved aside was RECREATED and the run reported ok. That state does not survive a run. What actually produced the 2026-08-06 sequence: the manual run was dropped by the single-flight while an earlier run was still going. runOffboxBackup returned nil, the handler had already answered "A tavoli mentes elindult", and the card then showed the PREVIOUS run's green verdict — read as covering the app just selected. The decision is now taken synchronously in the handler and a dropped request says so. The nightly path still returns nil on purpose: nobody asked, and it retries. §7.3 measured before deciding: CaptureRecoveryUnit writes a few KB of compose + manifest, only ENUMERATES dumps rather than creating them, is idempotent and does NOT stop the app — and already runs inside the off-site run. So there is no wait to remove for a deployed app and NOTHING was built. 28 packages ok, 9/9 gates. Four red-proofs, each asserted to have applied. Fixture note: the shared provider's ListDeployedStacks returned nil, so Scenario A first passed for the wrong reason; fixed with an opt-in deployed set that defaults to nil.	2026-08-06 21:58:21 +02:00
admin	53e9bf0224	v0.204.0 — the restore list is keyed on the store (R-237); the size gate stops refusing in silence (R-238) ... R-237: /backups/restore listed apps that are CURRENTLY DEPLOYED and CURRENTLY TOGGLED ON for future off-site backups. A rebuilt box has neither, so a household that had just lost everything was shown nothing to restore while the repository held their snapshots — measured live on the R-201 re-walk. To restore an app you had to select it, to select it you had to have installed it, and to know what to install you had to see the backup you could not see. The store is now the source of the list (offsite_restore_list.go), built on the existing R-193 OffsiteInventoryList. Installed-ness became a property OF a row, never a filter on it. Every case is answered rather than hidden: a snapshot for an app that is not installed is offered and says it will reinstall first; an installed app with no snapshot is shown as having nothing; an unreadable store renders as UNKNOWN (R-225's rule, one screen over) AND keeps the action, because "we could not look" is not "there is nothing"; no-target is its own state. The felhom-offbox and _shares marker tags are excluded from the app list. R-238 classified as a HARNESS ARTIFACT: mode=full without confirm=1 is step 1 of a deliberate two-step — it starts no job by design and redirects carrying &full_prep=<app>, which deriveWizardStep requires to reveal the commit. A driver that did not carry it forward landed back on the intent step. The operator's browser run completed the same restore. The wizard's precedence rules were NOT re-keyed: a stale ?full_prep= must never resurrect a commit button mid-restore. The residue WAS real and is fixed: neither branch of that step wrote anything to the log, so a refusal — including by the headroom gate — left no trace on the box. Both branches now log, and so does the concurrent-op refusal. resolveWizardApp is removed: it was dead once the gate moved, and its test pinned the defect's behaviour (an untoggled app refused), which would have read as policy. 28 packages ok, 9/9 gates OK. Three red-proofs, each asserted to have applied.	2026-08-06 16:44:05 +02:00
admin	4d349d1106	REPORT + CONTEXT for v0.203.0: the retry shape, the marker answer, R-220's shape ... Records the decisions rather than only the code: - POLL not ACK, decided on Scenario B against the ACTUAL promises — the no-target message gives no deadline and the card says 'within a day', so a 5-minute tick is inside both and no text needed changing. If either promise tightens to minutes, go ACK-driven. - The marker question: applied_marker lives in the guest's DataDir, which a rebuild destroys, so it cannot suppress a legitimate re-run. Left alone. - R-220 candidate (b), corroborated rather than a wider prefix, reading /proc/mounts because the lsblk args are pinned in sudoers. Live: Scenario C proven on demo-hp WITH a positive control — the job ran once and logged nothing. A first reading counted 2 lines that turned out to be the start-up reconcile, not the retry; the instrument was corrected before the conclusion. Scenarios A and E are deliberately NOT live-proven here: both need a rebuilt box, and that state arises naturally in Part 4.	2026-08-06 13:05:30 +02:00
admin	9dc26459ea	v0.203.0: the box collects what the hub staged for it (R-218 consume half) + R-220's message ... R-218's declaration half shipped in v0.201.0 and works. Its consume half never existed. Reconcile ran exactly twice per process — at start-up and when the recovery screen drives it — and BOTH fire before the hub has anything staged, because the hub stages in RESPONSE to the declaration those runs precede. Measured on the R-201 re-walk: unlock reconcile 11:43:07, hub staged 11:44:57 saying 'next cycle', a full report cycle ran 11:55:46, still unconsumed at 12:06. A guest command line applied it in 18 seconds — everything correct except the trigger. Bridge.RetryIfDeclared re-runs the SAME reconcile on a 5-minute tick, driven from the box's own published declaration (OffboxReportStatus().State) — the very statement the hub acts on, so the two cannot disagree. Poll, not an ACK flag, decided on the promise: the no-target message says 'amint megvannak' (no deadline) and the card says 'within a day'. Five minutes is inside both by a wide margin and needs no hub change. It stops by construction — a healthy box does no work and logs nothing — and the settle gate is deliberately kept via ReconcileWhenSettled. The marker was investigated and left alone: applied_marker lives in the guest's DataDir, which a rebuild destroys, so it cannot suppress a legitimate re-run. R-220's customer half: the refusal no longer tells the customer to choose from a list that may be empty. It names the rebuild, points at the Meghajtók page, and promises no outcome. Red-proofs: remove the retry -> credential uncollected (the dead end reproduced); drop the stop condition -> a healthy box hammers the hub; call Reconcile instead of ReconcileWhenSettled -> settle gate bypassed; restore the old sentence -> the impossible action returns. 28 packages ok, vet clean, all controller gates OK.	2026-08-06 12:56:12 +02:00