Skip to main content
The specs were published before the implementation so they could be argued with, and the implementation has sent corrections back to them. They are the contract; the packages are one implementation of it. Each spec ends with a conformance section, and @nativeharness/conformance is those sections as tests.

​
The interfaces

The four adapter points, as TypeScript, in @nativeharness/types:

​
Reading order

  • New to it: workspace-format.md §1–3, then bash-tool.md §1–3, then protocol.md §1–4.
  • Implementing a store: workspace-format.md in full, then workspace-store.ts.
  • Implementing a sandbox provider: bash-tool.md §§4–7, then sandbox-provider.ts, then run sandboxConformance() against it.
  • Writing a connector: connector-schema.md §§2–5, then an existing declaration.
  • Building a UI: protocol.md in full, then the event union in types.ts.

​
Versioning

Additive changes to a published spec are minor. Anything a conforming reader would misread is major. The useful contribution while they are drafts is disagreement: a case a rule gets wrong, a MUST that cannot be implemented, a shape that makes a reasonable UI awkward.