Define a complete daily-use app release milestone and acceptance checklist #83

New issue

Closed

opened 2026-05-22 11:34:51 +00:00 by steve · 0 comments

steve commented

2026-05-22 11:34:51 +00:00

Owner

Create a release milestone and checklist that defines what must be true before
Lapis Notes can be treated as a complete daily-use notes app.

Problem

Lapis Notes already has strong platform coverage and a broad feature set, but
work is spread across multiple parallel directions. The project needs a single
release-readiness target so new work can be judged against a concrete daily-use
flow instead of feature breadth.

Goal

Add a release-readiness spec page that defines the complete daily-use app
milestone, the required user journeys, and the release gate for tagging that
milestone.

Scope

Add a milestone or roadmap page under spec/src/ in the location that best
matches the existing spec structure.
Define the release goal and core daily-use loop.
Separate must-have, should-have, and deferred work.
List required user journeys, reliability checks, tests, documentation, and
recovery flows.
Link relevant backlog items where work is already tracked.
Point the spec index or README at the new milestone page.

Non-goals

Inventing new architecture for release management.
Expanding the current release to cover speculative platform or AI features.
Treating nice-to-have work as release scope without a concrete acceptance
test.

Acceptance Criteria

A release milestone or roadmap page exists under spec/src/.
The page defines the complete-app user journey in concrete terms.
The page separates must-have, should-have, and deferred work.
Relevant existing backlog items are linked or referenced.
Ambiguous nice-to-have items are either removed from the milestone or given a
clear acceptance test.
The document includes a short release-gate checklist that can be used before
tagging a release.
The spec index or README points to the milestone page.

Implementation Notes

Inspect the existing spec structure before choosing the final page path.
Reuse current architecture and package terminology.
Prefer checklist-style structure over long prose.
Keep the milestone focused on the daily-use loop: vault open/create,
note CRUD, links, search, notebooks, plugin controls, restart persistence,
and recovery from common failures.

Suggested Files or Specs To Inspect

spec/src/SUMMARY.md
spec/src/20-packages/
spec/src/30-cross-package-contracts/
.issues/index.md

Validation Commands

make spec-lint
mdbook build spec
pnpm test:smoke

Follow-up Tasks

Use the milestone to classify release-critical and deferred backlog items.
Link the resulting milestone from agent workflow guidance.

Implementation Summary

Duplicate of completed issue #77; keeping #77 as the canonical closed milestone issue.

Create a release milestone and checklist that defines what must be true before Lapis Notes can be treated as a complete daily-use notes app. ## Problem Lapis Notes already has strong platform coverage and a broad feature set, but work is spread across multiple parallel directions. The project needs a single release-readiness target so new work can be judged against a concrete daily-use flow instead of feature breadth. ## Goal Add a release-readiness spec page that defines the complete daily-use app milestone, the required user journeys, and the release gate for tagging that milestone. ## Scope - Add a milestone or roadmap page under `spec/src/` in the location that best matches the existing spec structure. - Define the release goal and core daily-use loop. - Separate must-have, should-have, and deferred work. - List required user journeys, reliability checks, tests, documentation, and recovery flows. - Link relevant backlog items where work is already tracked. - Point the spec index or README at the new milestone page. ## Non-goals - Inventing new architecture for release management. - Expanding the current release to cover speculative platform or AI features. - Treating nice-to-have work as release scope without a concrete acceptance test. ## Acceptance Criteria - A release milestone or roadmap page exists under `spec/src/`. - The page defines the complete-app user journey in concrete terms. - The page separates must-have, should-have, and deferred work. - Relevant existing backlog items are linked or referenced. - Ambiguous nice-to-have items are either removed from the milestone or given a clear acceptance test. - The document includes a short release-gate checklist that can be used before tagging a release. - The spec index or README points to the milestone page. ## Implementation Notes - Inspect the existing spec structure before choosing the final page path. - Reuse current architecture and package terminology. - Prefer checklist-style structure over long prose. - Keep the milestone focused on the daily-use loop: vault open/create, note CRUD, links, search, notebooks, plugin controls, restart persistence, and recovery from common failures. ## Suggested Files or Specs To Inspect - `spec/src/SUMMARY.md` - `spec/src/20-packages/` - `spec/src/30-cross-package-contracts/` - `.issues/index.md` ## Validation Commands - `make spec-lint` - `mdbook build spec` - `pnpm test:smoke` ## Follow-up Tasks - Use the milestone to classify release-critical and deferred backlog items. - Link the resulting milestone from agent workflow guidance. ## Implementation Summary Duplicate of completed issue #77; keeping #77 as the canonical closed milestone issue.

steve

2026-05-22 11:34:51 +00:00