Development workflow

How code, tests, docs, and governance move together.

SpineEditor changes are reviewed as a contract change, not just a code diff. If behavior changes, the matching tests and docs should change in the same pull request. If the docs do not change, the PR should say why.

What changes with code

  1. Code - keep the change in the package that owns the contract. Core owns semantic state and the engine pipeline; DOM owns browser evidence and projection; devtools owns replay/session helpers; theme owns optional styling.
  2. Tests - add or update tests at the same boundary the behavior is earned. Use browser tests when correctness depends on DOM selection, layout, clipboard, or input events.
  3. Docs - update the page that describes the changed contract. Readers should not need to infer new behavior from tests.
  4. TSDoc - update exported API comments when names, types, invariants, limits, or public behavior change.

Review checklist

  • Walk the hard rules and call out any rule the change touches.
  • Keep model truth in the engine. DOM, overlay, clipboard, and IME code may collect evidence or paint state, but they must not become the model.
  • Put the change in the package that owns it, and prefer existing helpers before adding a new abstraction.
  • Decide what unsupported input should do. It should fail closed or take a documented fallback, not guess.
  • Add tests at the boundary users rely on: core tests for semantic state, browser tests for DOM selection, layout, input, and clipboard behavior.
  • Update the docs when behavior changes. Update TSDoc when exported API behavior changes.
  • If a docs build output is committed because it is published or indexed, refresh it in the same PR.
  • Include release metadata when the repo workflow requires it.

Governance files

Root governance files are rendered in the docs so there is one source of truth: