18 — Phasing

Build sequence: from spec to publicly-discoverable apps. Phases are months, not weeks. Each phase has clear success criteria and explicitly-deferred concerns.

Overview

Phase	Duration	What ships
0	2 weeks	Spec, manifesto, repo skeleton, public posture
1	8 weeks	Core + CLI + Transcribe (you + 5 friends use daily)
2	8 weeks	DocVault + paved-path components + framework hardening
3	10 weeks	Distribution: registry, review pipeline, website, 5–10 hand-picked devs
4	Ongoing	Open submissions; trust + community + quality maintenance

Phase 0 — Spec & narrative (2 weeks)

Goal: A reader can understand what Locara is, why it matters, and how it works, without you in the room.

Deliverables:

• This spec (all 18 docs) reviewed for internal consistency.
• Public manifesto: 1-page, jargon-free thesis (/website/content/manifesto.md).
• Monorepo skeleton (per 17-repo-layout.md): empty crates + packages with lib.rs / index.ts stubs + CI green on cargo build and bun run build.
• ADR 0001–0005 covering already-made decisions.
• Public posture: GitHub repo public from end of phase 0; project name + domain locked in.
• Apple Developer Program enrollment (~$99). Required for all subsequent signing.

Success criteria:

• A technical friend reads the spec + manifesto and can explain Locara back to you correctly.
• Repo passes CI.
• Public repo is live; first commit is the spec + skeleton.
• ~5 hand-picked early supporters following.

Explicitly deferred: Any actual functionality. Phase 0 is pure setup.

---

Phase 1 — Core + Transcribe (8 weeks)

Goal: A working framework that produces a working app. You and ~5 friends use Transcribe daily.

Framework deliverables:

• locara-core: llama.cpp inference (MLX in v2 if scope allows), capability enforcement v0.1.
• locara-storage: sqlite + sqlite-vec, schema declaration, basic migrations.
• locara-models: content-addressed cache, fetch from HF (no Locara CDN yet — direct HF URLs).
• locara-runtime: app lifecycle, Tauri IPC, capability enforcement at runtime.
• Reference apps each ship as standalone Tauri apps (no separate locara-shell; framework is linked in).
• locara-cli: init, dev, test, build, verify. (No publish yet — there’s no registry.)
• @locara/sdk v0.1: llm, embed, transcribe, db. (Other modalities deferred.)
• @locara/manifest: schema + types.
• Manifest schema v0.1 covering: identity, display, capabilities (net/fs/device/models), profiles, storage, entry.
• Capability enforcement: macOS App Sandbox + Tauri permissions + Locara-runtime checks.

App deliverable:

• Transcribe working end-to-end: drop audio → transcribe → search → export. Three modalities: speech-to-text + text-to-text (for chat over transcripts) + text-to-embedding (for vector search).

Public deliverables:

• Weekly devlogs (start of phase 1).
• ADRs documenting decisions made during phase 1.
• Demo video of Transcribe working.

Success criteria:

• You use Transcribe daily for one month without rage-quitting.
• 5 friends install Transcribe (sideload .locapp) and use it weekly.
• Framework shipped as a numbered v0.1 release.
• CLI demo loop works: locara init transcribe my-app && cd my-app && locara dev opens working Tauri window.

Explicitly deferred:

• Registry / submission / locara publish.
• Modalities like voice-to-voice, image-to-text (only what Transcribe needs).
• DocVault, paved-path components, custom tools.
• Daemon / shared model server (apps load their own).

---

Phase 2 — DocVault + paved paths (8 weeks)

Goal: Second app exposes framework gaps; framework hardens; component library emerges.

Framework deliverables:

• @locara/sdk v0.2: vlm, ocr, tools modules.
• @locara/components v0.1: 8–12 paved-path components (Chat, DocDropzone, TranscriptStream, ResultsList, etc.) — extracted from Transcribe and DocVault.
• locara-tools: Wasmtime runtime, OCR + filesystem tools curated.
• Modality expansion logic in CLI + manifest (v1 modality taxonomy).
• Manifest schema v0.2: modalities + tooling first-class.
• locara add command for components.

App deliverable:

• DocVault: drop PDFs/images → OCR + extract → store in sqlite + sqlite-vec → search. Modalities: image-to-text (OCR + VLM) + text-to-text (chat over corpus) + text-to-embedding.

Public deliverables:

• Continued weekly devlogs.
• Long-form blog post on capability model (Tailscale-style).
• Demo video of building a Locara app from scratch (60-second loop).

Success criteria:

• DocVault works for ~50–100 users (broadened test group, sideload).
• Transcribe and DocVault share @locara/components; no duplicated UI work.
• A first external developer (not you) successfully scaffolds a working app from Cursor + the SDK docs.
• Framework v0.2 release; manifest schema v0.2.

Explicitly deferred:

• Public registry.
• Automated review pipeline (still hand-reviewed for trusted testers).
• Multi-app daemon / shared model server.
• iOS / Linux / Windows.

---

Phase 3 — Distribution (10 weeks)

Goal: Working registry, review pipeline, public website, 5–10 hand-picked external developers publishing standalone signed Mac apps.

Registry deliverables:

• registry/ Git repo + Postgres-backed metadata + R2 artifact storage.
• Submission flow: locara publish → CI → review queue → live.
• Automated review pipeline (GitHub Actions): build, sign, attest, static-analyze, risk-classify.
• Sigstore-style provenance attestations.
• Verified publisher accounts (GitHub OAuth + DNS verification).
• Capability cool-down + kill-switch infrastructure.

Frontend deliverables:

• locara.app: static website with catalog + app pages + search + capability filters.
• Direct .dmg downloads served from CDN.
• Capability badges, device-fit indicators.
• (Optional, not blocking phase 3) Locara Manager menubar utility for unified install/update view across installed Locara apps.

Operations deliverables:

• Locara CI hosted on GitHub Actions (paid signing + notarization via Locara’s Apple Developer account).
• Cloudflare R2 + Pages set up.
• Sigstore integration.
• Public incident log + revocation process.
• Domain locked, certs in place.

Onboarding:

• 5–10 hand-picked external developers given accounts + early access.
• 10–20 published apps in catalog by end of phase.

Success criteria:

• A user can Browse locara.app → click Install Transcribe → drag to Applications → use it in under 5 minutes from a fresh Mac.
• ~500–2000 active users.
• 10+ apps in catalog, all genuinely useful.
• Registry uptime >99% over the phase.
• One real takedown drill performed (revocation tested end-to-end).

Explicitly deferred:

• Open submissions (still curated invitations only).
• Payments / monetization.
• Mobile.
• Daemon / shared models.
• Anomaly detection.

---

Phase 4 — Open the gates (ongoing)

Goal: Open submissions, sustain quality, grow the community.

Mechanics:

• Public application form for new publishers.
• Trusted-reviewer program: invite community members to help review.
• Bug bounty program.
• Beta channels (publishers can ship beta versions).
• Editorial collections + featured surfaces.
• Conferences / podcasts / educational content.

Possible extensions (any/all):

• iOS support (capability subset).
• Daemon / shared model server (v2 architecture).
• Anomaly detection.
• Verified-privacy certification (paid product).
• Enterprise registry features.
• Linux / Windows.
• Multi-locale i18n.
• More modalities (text-to-image, video, etc.).

Success criteria (long-running):

• 100+ apps in catalog, sustained quality (rare takedowns, low malicious-app rate).
• Active community contributions to framework + registries.
• Stable financials: <$50/mo opex through phase 3; $X/mo predictable thereafter.
• Sustainability: project survives if its current maintainer steps back.

---

What every phase needs (cross-cutting)

• No telemetry. Ever. Always.
• OSS / open spec. Phase 0 onwards.
• Public ADRs. Resolve (open)s with documented rationale.
• Weekly devlogs. Phase 1 onwards.
• Stable manifest schema. Breaking changes have months of lead time.
• Privacy posture review at end of each phase.

Risks per phase

Risk	Mitigation
Phase 1: framework too rough for even Phase 1’s testers	5 friends are honest; aggressively iterate; Transcribe’s daily-use bar forces real polish
Phase 2: components don’t generalize from 2 apps	Build a third small app internally (chat + RAG) before declaring components done
Phase 3: registry attracts bad actors	Verified publishers + risk-based review + cool-down infrastructure ALL in place before opening
Phase 3: Apple breaks something	Have notarization tested end-to-end early; relationships with Apple if possible
Phase 4: scale outruns review	Volunteer reviewer program planned by mid phase 3
Any phase: maintainer burnout	Defined scope, clear “no” list, sustainable pace, open community structure

Cross-references

• All other spec docs.
• Notes on prior-art phasing: Tailscale (careful build), Pieter Levels (relentless ship), gpt-engineer (viral launch playbook).