Source: ViewEdit

Implementation plans — index

This folder holds detailed, actionable plans for work that is not yet implemented or only partially implemented in the repository. It complements vision and constraints (product direction) and CHANGELOG (what shipped).

Build order is gated by what to build first. A plan file is a subsystem design. It is not permission to open a later market.

How to use these documents

  1. Pick a plan by area (table below).

  2. Each plan states current state, target state, phased work, dependencies, and acceptance criteria.

  3. Update the plan file when scope shifts; add a short entry to changelog-details/ when a phase completes if the change is non-trivial.

Status legend

Status Meaning

Not started

No production-bound implementation; sketches or spikes only.

Partial

User-visible or internal scaffolding exists; not feature-complete.

Research

Requirements or technology choice still open.

Plan documents

Document Status (high level) Scope

Desktop application

Partial

Electron shell → full vault UX, storage, sync hooks, optional Kobalte alignment with the site.

Browser extension

Partial

MV3 scaffold → messaging, vault handoff, provider assist flows, security model.

Web vault, auth, and static site

Partial

Session marker + Veramo in browser → real auth story, SSR boundaries, feature parity decisions with desktop.

Provider fetch, merge, and interchange

Partial

Demo JSON + ad hoc GET → signed exports, optional proxy, schema alignment with OpenAPI/SDK.

Hardware presence and trust

Research / Partial

Directory permission + optional Web Bluetooth → USB/FIDO reality, threat model, UX for “public computer.”

Data model and indexing

Not started

Event log, document store, graph index, VC anchors — turn vision sketch into phased schema and code.

Release signing and distribution

Partial

CI builds → codesigned installers, macOS notarization, extension store readiness.

Native CLI and tooling

Partial

Optional D CLI under native/cli → role vs Electron, packaging, developer workflows.

Cross-cutting themes

These appear in multiple plans; keep them consistent across documents.

  • Local-first and minimal trust in hosts: anything “cloud” is opt-in and explicit.

  • Interchange: prefer OpenAPI + JSON Schema as contracts before ad hoc JSON.

  • Provenance: VCs, hashes, and append-only or versioned events should agree across desktop, extension, and web where the same data is shown.

  • Regulatory posture: certification programs (HIPAA tooling, FDA SaMD, etc.) stay out of scope until a deliberate program exists; plans must not imply certification by shipping a feature flag.

Related reading