Repository navigation
MVP 0.3: owner decisions (pilot, invitation expiry) #2
Description
@apankov — owner input needed for MVP 0.3 (tracker #1). None of these blocks the work that starts today; they block the pilot (028) and the release (029/030).
Q1. Pilot participants and date (blocks LFCP-03-028, gate G03-G)
The 0.3 plan asks for 5 new pairs, at least 4 finish the core flow in ≤10 min and a prepared problem in ≤5 min without hints; zero privacy/data-loss/wrong-target events. The 0.2 pilot (company staff, ~2 weeks out) has not run yet.
Recommendation: run one pilot, on the 0.3 candidate, instead of two. People who already used 0.4.0 are no longer "new" for the 0.3 measurements. Server sync.openlfcp.org, GitHub Discussions for support, retention 90 days (as decided for 0.2).
Need from you: OK to merge the pilots; who the 10 participants are (≥2 pairs of non-developers); facilitator; earliest date.
Q2. Invitation expiry and cancel (open decision D-01)
Today an invite is one-time but never expires, and an unused invite cannot be cancelled from the UI. The 0.3 scope explicitly excludes "cancel invitation as a new control operation".
Recommendation (my default if no answer): no protocol/server change in 0.3. The 0.3 invite flow states plainly "one-time link, does not expire; anyone who opens it first joins", and the pane lists unused invites. After 0.3: server-side policy expiry, 7 days by default, plus cancel via the existing grant revocation.
Need from you: OK, or move expiry/cancel into 0.3 (adds server + plugin work, about +1 week).
Decided by me (FYI, reverse if you disagree)
- Post-0.2 protocol items stay out of 0.3 (it is a UX milestone): full rejoin after removal, newcomer access to closed-epoch history, MS14 freeze scope, baseline.13 vectors. They go to the next track.
- Project docs that the pack assigns to "spec" (baseline manifest, UX contracts, evidence) live in
openlfcp/.github/docs, like the 0.2 backlog. The protocol spec is not changed unless a task proves a contract gap. - Release numbering: MVP 0.3 ships as plugin 0.5.0 (betas
0.5.0-beta.Nvia BRAT); SDK/server get a release only if a task changes them.
Activity
apankov commentedon Oct 15, 2026
@apankov — Q3: hotfix for released users (needs your yes/no, tags are yours).
LFCP-03-033 found a silent-divergence bug that is already in the released plugin 0.4.0 / SDK 0.2.0: if the connection drops (or a status listener throws) right after a local change is saved, the SDK reverts that change in memory although it was saved and is later sent. The other side sees a conflict; this device loses the edit from its note and model and shows "Current". Later edits from the peer then stay stuck on this device. Reproduced headless; intermittent in the native acceptance spec.
SyncClient#commitmust not revert a durable batch) — new task LFCP-03-034.Recommendation: ship a patch for current users and for the pilot: SDK
0.2.1(root fix) + plugin0.4.1(0.4.0 + guard + SDK 0.2.1), prepared on release branches without any 0.3 UX code. I prepare everything and give you the tag commands; your part is the tags and the npm approval. This fits the "critical = data loss / silent divergence" rule.Need from you: OK for 0.2.1 + 0.4.1, or wait and ship only with 0.5.0.
apankov commentedon Oct 15, 2026
@apankov update on Q3: confirmed that released 0.4.0 is affected (race tests fail on ce0660a). Two independent causes, both fixed: (1) plugin opens one section twice after a restart → edits go to an unread model (obsidian PR #16, native acceptance 5/5 after fix, 2/5 failed before); (2) SDK reverts a durable batch when a later step throws (sdk-ts main c08d483, ready for 0.2.1). Still recommending SDK 0.2.1 + plugin 0.4.1 (0.4.0 + single-flight fix + SDK 0.2.1, no 0.3 UX code). I'm preparing both on branches with green dry runs; you only tag + approve npm. Default if no answer by the time it's ready: I hold and ask again in chat.
apankov commentedon Oct 15, 2026
Q3 approved by the owner (chat): ship SDK 0.2.1 + plugin 0.4.1. SDK release commit 90ba7e4, dry run 38671008948 green; plugin 0.4.1 being prepared on a release branch from 0.4.0.
apankov commentedon Oct 15, 2026
Owner answers (chat, 2026-10-15): Q2 confirmed — no invite expiry change in 0.3, honest wording (D2). Q1 — pilot participants will be found within a week (~2026-10-22); PM targets the 0.5.0-beta candidate (027) and pilot materials for that date.