OKF Workbench keeps Markdown as the source of truth and turns the complete authoring loop into editor commands:
initialize -> create -> edit -> validate -> explore -> repair
Local by default
Bundle parsing, validation, generation, and graph construction run in the editor workspace without an account or hosted content service.
Privacy boundarySafe authoring
New files use guarded no-overwrite creation, while existing-file changes are previewed and unrelated Markdown and unknown frontmatter remain under user control.
Safety modelOpen implementation
The extension is published under the MIT License with its production dependency notices included in every VSIX.
LicensePublic resources
- Source code and README
- Issue tracker
- Privacy statement
- Support
- Security policy
- MIT License
- Third-party notices
Project documentation
The repository keeps its product decisions, compatibility evidence, and implementation references
under docs/. The documents below
are the source of truth for the initial product and engineering direction.
Product
| Document | Purpose |
|---|---|
| Product brief | Target users, problem, value proposition, and product boundaries |
| MVP scope | Initial commands, workflows, acceptance criteria, and exclusions |
| Roadmap | Proposed delivery stages and release gates |
Engineering
| Document | Purpose |
|---|---|
| Functional requirements | Testable MVP behaviors, acceptance scenarios, constraints, and open questions |
| Architecture | Module boundaries, data flow, security, performance, and testing |
| Implementation environment | Accepted runtimes, toolchain, dependencies, test layers, CI, and packaging baseline |
| OKF v0.1 compatibility contract | The subset and interpretation of the OKF specification the extension must honor |
| Agent integration | Safe generation of AGENTS.md and Agent Skill templates |
Release and operations
| Document | Purpose |
|---|---|
| Release checklist | Immutable candidate, approval, publication, verification, and rollback gates |
| Open VSX listing draft | Candidate metadata and listing copy for straydog.okf-workbench |
| Compatibility matrix | Exact editor/OS lanes and required retained lifecycle evidence |
| Acceptance evidence | Component coverage, packaged lifecycle evidence, and remaining scenario gaps |
| Performance evidence | Reproducible fixtures, thresholds, and headed-editor measurement authority |
| Security and privacy evidence | Technical controls, findings, dependency inventory, and proof gaps |
| Privacy statement | User-facing data-processing and network boundary |
| Support | Bug, compatibility, and private vulnerability reporting guidance |
| Security policy | Private vulnerability reporting and disclosure expectations |
| Changelog | Release-candidate changes and release status |
Decisions
Accepted decisions are recorded under decisions/:
- 0001 — Build a workbench, not a standalone viewer
- 0002 — Keep the core deterministic and AI-provider-free
- 0003 — Use 3d-force-graph for the initial 3D renderer
- 0004 — Use a single-package npm, TypeScript, and esbuild toolchain
- 0005 — Resolve the MVP implementation questions
- 0006 — Publish Open VSX releases from version tags
- 0007 — Adopt a Rust/Wasm shared OKF core and native CLI
- 0008 — Bundle the native CLI in platform VSIX packages and distribute it separately
- 0009 — Preview only proposals that may change existing files
Documentation rules
- Update the relevant document when a product or architecture decision changes.
- Add an architecture decision record when a choice constrains future implementation.
- Separate facts required by the OKF specification from OKF Workbench product decisions.
- Link to primary specifications rather than copying large portions of them.