Skip to main content

OpenSpec, E2E, and docs

Keep requirements, browser/API checks, and public documentation aligned when behavior changes.

SectionFor developers / Quality workflow
PurposeDeveloper workflow reference
UpdatedJul 6, 2026
AuthorTemplate Maintainers
Versionv1.2.0
Reading time1 min

OpenSpec, E2E, and docs

Feature work in this template should keep requirements, implementation, checks, and public documentation aligned. This prevents the template from shipping behavior that only exists in code.

Before implementation

Find the closest capability under openspec/specs. If no capability exists and the change is visible to users or API clients, create or update the OpenSpec coverage before implementation.

During implementation

Use the spec to drive the feature boundary. Keep implementation inside the owning feature slice and avoid pulling unrelated behavior into the change.

E2E coverage

OpenSpec-backed E2E tests live under e2e/specs/<capability>. Quick reachability checks belong in e2e/smoke.

Use shared helpers from e2e/support for auth, routes, workspaces, invitations, and API keys.

Public documentation

When the user-visible behavior changes, update the closest public documentation page. Add both .en.md and .ru.md variants when the page is public.

Verification

Run focused checks while iterating and the relevant broader checks before completion. For documentation-only changes, run the documents-system content tests and formatting checks.