"Closed alpha" has no feature list and no exit criteria anywhere in the corpus — so the gap has no denominator

Источник: dev/fera-research/docs/oc3/009-no-closed-alpha-scope.md (read-only; сгенерировано scripts/sync-docs.mjs)

“Closed alpha” has no feature list and no exit criteria anywhere in the corpus — so the gap has no denominator

kind: problem
area: modules
severity: mid

Evidence

A grep for closed alpha, M0, milestone, and exit criteria across the two documents that are supposed to define them returns nothing:

project-design/context/TECHSPEC.md — zero occurrences of alpha, M0, milestone, exit criteria.
project-design/context/QA.md — zero occurrences of alpha or M0; exactly one occurrence of milestone, at QA.md:182, and it is about this QA document’s own scope.

The only “definition of done” in the entire corpus is QA.md:181-192:

181: ## Definition of "architecture skeleton complete" (this document's own
182:    scope milestone)
184: This QA document, together with `ADR.md`/`RFC.md`/`TECHSPEC.md`, is
185: considered a complete architectural baseline once:
186: - [ ] Every ADR has a corresponding section in `RFC.md` and/or
187:       `TECHSPEC.md` (no decision left undocumented downstream).
188: - [ ] Every "open question" flagged inline across these docs is also
189:       present in `OQ.md` (no orphaned TODOs).
190: - [ ] Phase 1 of the sequencing plan (`TECHSPEC.md` §10) is achievable
191:       using only crates/decisions already recorded here — i.e., no hidden
192:       unresolved dependency blocks even the first implementation step.

All three are about document completeness, not about a shippable client. A client could satisfy all three with 3 821 LOC of doc comments.

The real alpha definition lives in NAMING-UX.md, and it is process, not scope. NAMING-UX.md:75-90:

75: **Release pipeline:** ЗАТ (closed alpha) → ЗБТ (closed beta) → ОБТ
76: (open beta) → Release.
78: **ЗАТ (closed alpha) plan (author's, 2026-10-02):**
79: - Participants: the author's friends (small trusted circle).
80: - An **in-app bug-report button** ships with the alpha build.
81: - **Self-hosted Sentry** for crash/telemetry collection — deployed
82:   locally (on own infrastructure), not SaaS. ...
87: - **Telemetry is a separate DLL module** (author's decision, 2026-10-02,
88:   mid-edit): opt-out by removing/disabling the module ...

That is: audience, a bug-report button, self-hosted Sentry, and a telemetry DLL. It contains no feature list (does the alpha send messages? paginate history? render text?) and no exit criteria (what must be true to invite the friends?).

TECHSPEC.md:451-453 disclaims being a roadmap: “## 10. Sequencing notes (not a committed roadmap, a dependency ordering) / Rough dependency order, not a schedule”.

An undefined term inside QA.md. QA.md:190 says “Phase 1 of the sequencing plan (TECHSPEC.md §10)”. But §10 (:451-469) enumerates 9 unnumbered steps, not phases. There is no “Phase 1” in §10. The repo’s own CLAUDE.md says “TECHSPEC §10 items 1-2 first”, which suggests the author reads “Phase 1” as ≈ steps 1-2 — but that mapping is nowhere written down.

Суть

“Closed alpha” is the milestone the README leads with (README.md: “Release pipeline: closed alpha → closed beta → open beta → release”), it has a dedicated planning section in NAMING-UX.md, and it has a Sentry deployment and a bug-report button attached to it — but no one has written down what the thing must do.

This matters concretely for the current mission because every other finding in this folder had to answer “does this block the alpha?”, and the honest answer for most of them is unanswerable. Consider the three-way split that falls out:

docs/oc3/001 (encryption tier dropped from the storage seam) — definitely blocks: ADR-016 has no deferral anywhere, and shipping unencrypted message content to a circle of friends’ machines is not something a closed alpha does.
docs/oc3/002 (module system is zero lines) — almost certainly blocks: the launcher/trust/self-update story is the alpha’s distribution story, and NAMING-UX.md:80 (bug-report button) implies running builds exist to report from.
docs/oc3/006 (lattice has no reader) — does not block: TECHSPEC.md:359 and OQ-013 explicitly defer the container format to the author.
docs/oc3/007 (calls work in /tmp) — does not block: RFC.md:27-28 and RFC.md:245-248 defer calls past the initial release. Only the loss risk is urgent.

Those verdicts came from reading deferral statements scattered across four documents, not from a scope definition. Any agent auditing this corpus will re-derive that mapping from scratch, and two agents will disagree about which half of step 3 is in scope.

OQ-019 makes the gap explicit from the other direction: the Telegram Desktop feature survey is “planned, not started — explicitly a ‘later’ task; launch the survey agents when v1 scoping begins” (OQ.md:580-591). So the corpus knows that scope definition is a pending, named piece of work. It is the only OQ that gates scope definition rather than implementation.

Варианты решения (с tradeoffs)

Option A — define closed alpha as “TECHSPEC §10 steps 1-3, wired for real”.

Cost: small, and it is defensible — fera/CLAUDE.md already says the workstream is “§10 items 1-2 first”, so steps 1-3 is the natural extension.
Benefit: gives a denominator immediately, and it is honest about what it excludes (steps 4-9 = module system, search, crypto tiers, trust, plugins, calls).
Risk: steps 1-3 “wired for real” requires grmrs + sanakirja, which do not exist on this machine (see docs/oc3/002). So this definition may be unreachable on the current dependency footing.

Option B — write a real feature list for the alpha, derived from Telegram Desktop’s must-haves.

Cost: significant, and it is exactly the work OQ.md:580-591 assigns to the not-yet-launched survey agents.
Benefit: the only definition that is actually actionable for the alpha’s audience.
Risk: premature — OQ-019 deliberately sequences this after v1 scoping begins.

Option C — leave it undefined and rely on the deferral statements.

Cost: zero.
Benefit: nothing is prematurely committed.
Risk: every audit re-derives the blockers list; scope creep is invisible; “we’re nearly alpha-ready” cannot be assessed.

Предлагаемое решение

A now, B when OQ-019 fires — and fix the undefined “Phase 1” in the same edit.

Add an explicit scope line to the corpus stating: closed alpha = TECHSPEC §10 steps 1-3 with real I/O bindings (real MTProto transport via grmrs, real persistence via sanakirja, text-only chat view per §10 step 3), plus the three NAMING-UX.md:80-90 alpha-specific items (bug-report button, self-hosted Sentry, telemetry DLL). Everything in steps 4-9 is explicitly out.
Replace “Phase 1” at QA.md:190 with the actual step numbers. It currently references a phase structure that does not exist in the document it cites. If the intended meaning is steps 1-2, write “step 1”; if it is steps 1-3, write that. Either is fine — the current text is not.
Record the alpha-blocking set explicitly so future audits inherit it rather than re-deriving it. Based on the deferral statements in the corpus, the set is: real transport, real persistence, the encryption tier (docs/oc3/001), and the launcher/trust/self-update path (docs/oc3/005). Everything else has a written deferral.
Note that §10 step 3’s wording is stale: it says “minimal GPUI rendering” (TECHSPEC.md:458), but OQ.md:476-483 resolved OQ-014 to “Vello + Parley + native text-input slots” and ADR.md:957-1000 (ADR-028) confirmed it. The repo follows the resolution (core/crates/ui-engine-vello/). Fix the sentence while editing the section — see docs/oc3/010-spec-hygiene-defects.md.

Cross-references

docs/oc3/002-module-system-is-zero-lines.md — the dependency facts that decide whether option A is reachable
docs/oc3/010-spec-hygiene-defects.md — the other stale-text defects in the same corpus
QA.md:188-189 (“no orphaned TODOs”) is the gate that should have caught several of these; it is a manual checklist with no automated form.