Skip to content
🚧 Early alpha — building the foundation. See the roadmap →

v0.1-RC — Artifact-chain acceptance, bundle, polish, ship

Updated

Ship the v0.1 implementation phase only after the complete artifact chain is demonstrably coherent: source bytes → reusable configuration → Knowledge Set/MappingSet → Execution Record → Package Manifest. The RC then verifies bundle size, confirms mobile portability (per Ch 23 §5 isDesktopOnly: false commitment), polishes remaining UX rough edges, and prepares community-plugin submission. Released as v0.2.0 since v0.1.0 was the original MVP shipped 2026-04-02.

This RC consolidates the six v0.1 architectural commitments and verifies the artifact boundaries described by artifact roles and authority and the artifact-role synthesis.

📋 Planning

Status last verified: 2026-09-05 — scoped to planning state at commit 30aee63b: the milestone hub still marks RC as Planning, and its prerequisite Execution Record and Package Manifest contracts remain undefined in spec/README.md. No artifact-chain replay, bundle-size, mobile, real-Obsidian, release, or community-submission gate was run or newly verified.

  • All prior v0.1 milestones complete (v0.1.1 through v0.1.8)

In:

  • Artifact-chain acceptance — exact replay from pinned source bytes + reusable configuration through canonical Knowledge Set/MappingSet output, terminal Execution Record, and verified Package Manifest
  • UI/config parity — every release-critical portable operation available through UI has equivalent programmatic/config behavior, and every supported programmatic path has a discoverable UI path or an explicitly documented escape-hatch exception
  • Truthful public language — README, notices, settings, docs, and release notes describe implemented guarantees without claiming unsupported OSCAL mappings, generalized Knowledge Set governance, or stronger audit assurance than v0.1 provides
  • Docs/roadmap parity — milestone hub, docs roadmap, root ROADMAP.md, release notes, and status labels agree
  • Bundle size verification — measure plugin core + sqlite-wasm + sqlite-vec; target ≤ 1.2 MB compressed
  • Mobile portability test — install on Obsidian Mobile (iOS or Android via Capacitor); verify import wizard, Tier 1 generation, sidecar projection, exporters all work
  • README final polish — aligned with the design-phase-complete state; tagline preserved; jargon stripped
  • Lint clean — bun run lint passes for community-plugin submission rules
  • Community plugin submission prep — checklist run-through per Obsidian Plugin Guidelines
  • Release notes — comprehensive but user-facing (no internal-vocabulary leaks per memory entry)
  • Version bump to v0.2.0 — package.json, manifest.json, versions.json

Out:

  • v0.2 milestones (XLSX/JSON parsers, tag/wikilink mechanism wiring, graph_edges)
  • v0.5 external Python producer
  • Marketplace registry
  • Exact replay — pin source bytes by content hash, reopen the reusable configuration + binding, replay through UI and programmatic paths, and verify equivalent canonical output plus a valid terminal Execution Record
  • MappingSet round-trip — canonical set identity/version, participants, membership/integrity, and provenance/license survive SSSOM → canonical → STRM → canonical interchange
  • Execution Record terminal coverage — successful, failed, and cancelled UI/programmatic runs each produce one valid terminal record with resolvable source, recipe, output, validation, and trace facts
  • Package Manifest verification — every distributed artifact is inventoried; byte hashes, dependencies, license/attribution, and signatures verify; tampering or omission fails closed
  • UI/config parity audit — reusable-configuration lifecycle, source binding/replay, MappingSet inspect/export, run history, and package inspection have equivalent supported UI and programmatic paths
  • Public-language audit — no unsupported OSCAL, audit, portability, generalized Knowledge Set, or mobile claims
  • Docs/roadmap parity audit — milestone pages, milestone hub, docs roadmap, root ROADMAP.md, README, and release notes agree on scope and status
  • Run bun run build in production mode; report final bundle size
  • Compare against the 1.2 MB target; if over, identify trim opportunities (lazy-load XLSX, skip SSSOM exporter unless user enables, etc.)
  • Install plugin in a real Obsidian Desktop install (not just test-vault/); run a full import workflow
  • Install on Obsidian Mobile; run a tree-shaped-source import (CSV); verify sidecar projects + queries work
  • bun run lint clean — no obsidianmd/* rule violations
  • README pass — verify against the “no internal vocabulary” memory rule; tagline still says “Turn your Obsidian vault into an operational GRC knowledge graph”; “How it works” diagram up-to-date
  • CHANGELOG.md update — convert “Unreleased” section to “0.2.0 — 2026-MM-DD”
  • ROADMAP.md update — flip v0.1 implementation phase status to ✅ Complete; add a “What carried forward” section
  • Archive v0.1 implementation roadmap page — move to reference/roadmap/v0-1-implementation.mdx per the archive convention
  • Submit to obsidianmd/obsidian-releases via PR per community plugin process
  • The chain source bytes → reusable configuration → Knowledge Set/MappingSet → Execution Record → Package Manifest passes exact-replay and tamper-detection gates
  • MappingSet canonical SSSOM/STRM round-trip preserves set and assertion integrity
  • Every UI and programmatic run path produces a valid terminal Execution Record
  • Every release Package Manifest completely inventories distributed artifacts and verifies every byte hash/signature
  • UI/config parity audit has no unexplained lifecycle gaps
  • Public language is truthful about implemented formats, audit assurance, portability, and deferred governance
  • Docs, roadmap mirrors, release notes, and milestone status are semantically aligned
  • Bundle ≤ 1.2 MB compressed total
  • Plugin installs and runs cleanly on Obsidian Desktop AND Mobile
  • bun run lint exits 0
  • All v0.1.1–v0.1.8 milestones marked ✅ Done
  • PR submitted to obsidianmd/obsidian-releases for community-plugin inclusion
  • package.json — version bump
  • manifest.json — version bump
  • versions.json — append entry
  • CHANGELOG.md — finalize 0.2.0 entry
  • ROADMAP.md (root) — phase status flip
  • docs/.../reference/roadmap/index.mdx — phase status flip + archive link
  • docs/.../reference/roadmap/v0-1-implementation.mdx — new archive page
  • README.md — final polish pass
  • docs/.../development/contributing.mdx — verify install/contribute paths still accurate
  • Is the v0.2.0 number right, or do we want v0.1.0-rc.1 → v0.1.0 (overwriting the existing 0.1.0 MVP semantically)? Lean toward v0.2.0 since the MVP shipped and is in user hands; this is genuinely the next minor
  • Community plugin submission timing — submit immediately on RC pass, or wait through a quiet “early adopter” period?

Concept pages:

Agent context:

  • Vision — what the RC needs to deliver against
  • Tradeoffs — known limitations to be transparent about
  • v0.1 schema spec — the schemas RC publishes
  • Decisions — architectural decisions consolidated

Design decisions (synthesis logs — the 6 architectural commitments):

Research deliverables (RC verification context):

Spec & schema files:

External references:

Other milestones: