P3-11: Private beta — internal gate, NOT the release #40

New issue

Open

opened 2026-09-10 17:45:57 +00:00 by Cordy · 1 comment

Cordy commented

2026-09-10 17:45:57 +00:00

Owner

Depends on P3-10. Closes phase 3.

Nothing is published here. v1.0 means "it ships", and nothing ships until phase 4 is
complete — see #50. This milestone proves the sync engine is trustworthy so that placeholders
can be built on top of it. Tag v0.9.0-rc; do not announce, do not publish.

Why an internal gate is worth the effort

If the engine were unproven when placeholders arrive, every subsequent bug report would be
ambiguous: engine fault, or hydration fault? Two clean gates is the only thing that keeps
phase 4 debuggable.

The gate

72 hours of continuous real-world use across three machines with zero data loss and zero
silent divergence.

Not 72 hours of the app being open. 72 hours of real work: editing documents, renaming
folders, deleting things, going offline, closing laptops mid-sync, working on the same files
from two machines.

Beta protocol

Recruit a small group — you, Manuel, and a handful of tolerant volunteers. Cairn is
already in closed beta, so the audience exists.
Every tester runs on real data they care about and has an independent backup. Say this
explicitly and confirm it before they start.
Include at least one Windows, one macOS and one Linux machine, and at least one
user syncing the same folder from two machines simultaneously — that is where conflicts
actually arise.
Run for a minimum of two weeks past the 72-hour clean window.

Adversarial checklist — run these deliberately

Kill the app mid-transfer of a large file. Restart. Verify it resumes and the file is intact.
Pull the network cable mid-sync. Reconnect. Verify recovery.
Edit the same file on two machines while both are offline, then bring both online. Verify a
conflict copy appears and both versions survive.
Rename a folder containing several hundred files. Verify it is a MOVE, not a re-upload.
Fill the quota. Verify a clear message and no retry storm.
Revoke the app password server-side while syncing. Verify a clean re-auth prompt rather
than a crash loop.
Change the system clock backwards, then sync. Verify no data loss.
Put a file with a Windows-illegal name on a Linux server, then sync to Windows. Verify a
skip with a legible reason.
Create Report.pdf and report.pdf server-side, then sync to macOS. Verify both are
skipped rather than one clobbering the other.

Exit criteria — all must hold

72 continuous hours, three machines, zero data loss, zero silent divergence.
Every adversarial case above behaves as designed.
No open issue labelled data-integrity.
TestConvergence green at 500 seeds.
Full integration suite (#29) green.
Diagnostics export verified free of credentials.
Auto-update tested end to end on macOS and Windows.

Then

Tag v0.9.0-rc. Internal only.
Close the phase-3-desktop-app milestone.
Begin phase 4 (#44).

Do not publish the website clients page, announce anything, or tag v1.0.0. Those belong
to #50, once files-on-demand has passed its own gate.

If the gate is not met

Do not proceed to phase 4. Extend the beta. Layering placeholders onto an engine that still
loses data would make both problems harder to find.

Depends on P3-10. Closes phase 3. **Nothing is published here.** v1.0 means "it ships", and nothing ships until phase 4 is complete — see #50. This milestone proves the sync engine is trustworthy so that placeholders can be built on top of it. Tag `v0.9.0-rc`; do not announce, do not publish. ## Why an internal gate is worth the effort If the engine were unproven when placeholders arrive, every subsequent bug report would be ambiguous: engine fault, or hydration fault? Two clean gates is the only thing that keeps phase 4 debuggable. ## The gate > **72 hours of continuous real-world use across three machines with zero data loss and zero > silent divergence.** Not 72 hours of the app being open. 72 hours of **real work**: editing documents, renaming folders, deleting things, going offline, closing laptops mid-sync, working on the same files from two machines. ## Beta protocol - [ ] Recruit a small group — you, Manuel, and a handful of tolerant volunteers. Cairn is already in closed beta, so the audience exists. - [ ] Every tester runs on real data they care about **and has an independent backup**. Say this explicitly and confirm it before they start. - [ ] Include at least one **Windows**, one **macOS** and one **Linux** machine, and at least one user syncing the same folder from two machines simultaneously — that is where conflicts actually arise. - [ ] Run for a minimum of two weeks past the 72-hour clean window. ## Adversarial checklist — run these deliberately - [ ] Kill the app mid-transfer of a large file. Restart. Verify it resumes and the file is intact. - [ ] Pull the network cable mid-sync. Reconnect. Verify recovery. - [ ] Edit the same file on two machines while both are offline, then bring both online. Verify a conflict copy appears and **both versions survive**. - [ ] Rename a folder containing several hundred files. Verify it is a MOVE, not a re-upload. - [ ] Fill the quota. Verify a clear message and no retry storm. - [ ] Revoke the app password server-side while syncing. Verify a clean re-auth prompt rather than a crash loop. - [ ] Change the system clock backwards, then sync. Verify no data loss. - [ ] Put a file with a Windows-illegal name on a Linux server, then sync to Windows. Verify a skip with a legible reason. - [ ] Create `Report.pdf` and `report.pdf` server-side, then sync to macOS. Verify both are skipped rather than one clobbering the other. ## Exit criteria — all must hold - [ ] 72 continuous hours, three machines, **zero data loss**, zero silent divergence. - [ ] Every adversarial case above behaves as designed. - [ ] No open issue labelled `data-integrity`. - [ ] `TestConvergence` green at 500 seeds. - [ ] Full integration suite (#29) green. - [ ] Diagnostics export verified free of credentials. - [ ] Auto-update tested end to end on macOS and Windows. ## Then - [ ] Tag `v0.9.0-rc`. **Internal only.** - [ ] Close the `phase-3-desktop-app` milestone. - [ ] Begin phase 4 (#44). **Do not** publish the website clients page, announce anything, or tag `v1.0.0`. Those belong to #50, once files-on-demand has passed its own gate. ## If the gate is not met Do not proceed to phase 4. Extend the beta. Layering placeholders onto an engine that still loses data would make both problems harder to find.

Cordy added this to the phase-3-desktop-app milestone

2026-09-10 17:45:57 +00:00

Cordy added the

data-integrity

label

2026-09-10 17:45:57 +00:00

Cordy commented

2026-09-10 18:23:52 +00:00

Author

Owner

Amendment — 2026-09-10: this is not the release

Decision: v1.0 means "it ships", and nothing ships until phase 4 is done too. There is no
v1.0-then-v1.1 split. Files-on-demand is part of the product, not a follow-up.

So this issue is now an internal milestone gate, not a public release. Everything about the
testing bar stays exactly as written — 72 hours, three machines, zero data loss, the full
adversarial checklist. What changes is what happens afterwards.

Remove from the "Then" section:

~~Tag v1.0.0~~ → tag v0.9.0-rc or similar. The version number is not the point; not
calling it 1.0 is.
~~Publish the "Clients" page on swisscairn.ch~~ → moves to #50, since the page should
describe the product as it actually ships, files-on-demand included.
~~Update the handbook with the §8.3 network-behaviour statement~~ → also moves to #50.

Keep: every exit criterion, and the instruction not to proceed if the gate is not met.

Why the gate still matters even though nothing ships here

Passing this gate is what proves the sync engine is correct before placeholders are layered
on top. If you skip it and go straight to phase 4, every subsequent bug report is ambiguous —
engine fault or hydration fault? Keeping two clean gates is the only way phase 4 stays
debuggable.

Closing this milestone means: the engine is trustworthy, and phase 4 can start.

## Amendment — 2026-09-10: this is not the release **Decision: v1.0 means "it ships", and nothing ships until phase 4 is done too.** There is no v1.0-then-v1.1 split. Files-on-demand is part of the product, not a follow-up. So this issue is now an **internal milestone gate**, not a public release. Everything about the testing bar stays exactly as written — 72 hours, three machines, zero data loss, the full adversarial checklist. What changes is what happens afterwards. **Remove from the "Then" section:** - ~~Tag `v1.0.0`~~ → tag `v0.9.0-rc` or similar. The version number is not the point; not calling it 1.0 is. - ~~Publish the "Clients" page on swisscairn.ch~~ → moves to #50, since the page should describe the product as it actually ships, files-on-demand included. - ~~Update the handbook with the §8.3 network-behaviour statement~~ → also moves to #50. **Keep:** every exit criterion, and the instruction not to proceed if the gate is not met. ### Why the gate still matters even though nothing ships here Passing this gate is what proves the sync engine is correct **before** placeholders are layered on top. If you skip it and go straight to phase 4, every subsequent bug report is ambiguous — engine fault or hydration fault? Keeping two clean gates is the only way phase 4 stays debuggable. Closing this milestone means: the engine is trustworthy, and phase 4 can start.

Cordy referenced this issue

2026-09-10 18:24:01 +00:00

P4-7: Files-on-demand gate — THIS is the v1.0 release #50

Cordy changed title from ~~P3-11: Private beta and v1.0 release gate~~ to P3-11: Private beta — internal gate, NOT the release

2026-09-10 18:29:51 +00:00

Cordy referenced this issue

2026-09-10 18:30:06 +00:00

P4-7: Files-on-demand gate — THIS is the v1.0 release #50