Command line and live demo move to the near term
1. The decision
Section titled “1. The decision”Two items join the near-term roadmap, alongside the active v0.1 implementation work, under the heading Deterministic avenues: command line and live demo.
| Item | What it is | What it is not |
|---|---|---|
| Command line first slice | Headless commands (commands that run without opening Obsidian) over the same engine the plugin uses: import with a recipe, export, validate against spec/tier1.schema.json and spec/recipe.schema.json, and replay a saved recipe. Run from the repo with bun against a plain folder of Markdown | A second engine, or a rewrite. It also does not wait for the monorepo restructure |
| Live demo workspace | A full multi-framework demo (several frameworks, crosswalks between them, evidence junction notes, saved queries) built by the command line from content the repo may redistribute, then loaded into an OpenClast workspace (OpenClast runs real Obsidian in a browser tab) so anyone can open it | Hand-built. The demo is regenerated by one command, never edited by hand |
How the command line avoids waiting on the restructure: a thin filesystem vault adapter (a small layer that lets the engine read and write a plain folder the same way it reads and writes an Obsidian vault) lands now. Extracting the engine into packages/core and the command line into packages/cli stays on the roadmap as the later, additive move described in the distribution architecture research.
2. The owner’s words
Section titled “2. The owner’s words”“We should definitely be developing CLIs and what not too in the long or even short or mid-term as well btw - if i wasn’t clear. Makes it so that we have deterministic methods by multiple avenues”
“put that on roadmap for sure - near term probably even”
On the demo, the owner expected it to exist already:
“i thought you would’ve used openclast to esablish a full frameworks and ontology demo by now for crosswalker”
3. Why
Section titled “3. Why”| Reason | In one line |
|---|---|
| Deterministic results by more than one route | Every lifecycle stage is reachable from the UI and from a script, and both give the same output. This pairs with the UI parity rule: the UI stays primary, the recipe and command line are the escape hatch, and parity gaps are tracked |
| Agents and CI drive the same engine | An agent or a CI job can import, validate, export and replay without driving a desktop app, so checks run against the real engine instead of a stand-in |
| A demo anyone can open | A reader evaluating Crosswalker sees several frameworks, their crosswalks, evidence and queries in a browser tab, with no install |
| The demo stays honest | Because the command line builds it from source files, a rebuild after an engine change shows the current behavior, not a stale snapshot |
| It follows schema-as-primitive | Any producer that writes valid Tier 1 notes is first-class. The command line is one more producer using the same contract |
4. What changes on the roadmap
Section titled “4. What changes on the roadmap”| Where | Change |
|---|---|
Roadmap and ROADMAP.md | New near-term section, Deterministic avenues: command line and live demo, placed with the active v0.1 work and before the later Formats and Crosswalks phases. Two items: command line first slice, live demo workspace |
| Crosswalks phase | The late “CLI implementation” item now points at the near-term first slice instead of repeating it. What stays there is crosswalk generation and batch operations from the command line, built on that slice |
| Monorepo restructure item | Kept, and marked as the later extraction step. The command line no longer waits for it |
5. Open questions
Section titled “5. Open questions”| Question | Why it matters |
|---|---|
| Which content can the demo redistribute? | Some framework sources and crosswalks carry licenses that forbid redistribution. The demo needs frameworks and mappings the repo may ship publicly, or synthetic stand-ins where it may not |
| Does the command line ship in releases? | The plugin release ships only main.js, manifest.json and styles.css. A command line either stays repo-only (run with bun from a checkout) or gets its own release artifact or package later, after the extraction into packages/cli |
Related
Section titled “Related”- Roadmap: the near-term section this decision adds
- Distribution architecture research: the core, plugin and command line package split, and when to restructure
- UI parity audit: UI first, config and command line as the escape hatch
- ETL and import: schema-as-primitive, any valid producer is first-class
- v0.1 schema spec: the contracts the command line validates against