pracht

Always look at the vision_mvp and docs before starting work. Documentation lives in two places and both need updating. docs/ is internal contributor reference — architecture, request flows, workspace shape; nobody outside the repo reads it. examples/docs/src/routes/docs/*.md is the public site (https://pracht.resynapse.dev) that users and coding agents read, and it is also what feeds the generated llms.txt and the agent-skills discovery index. A user-facing change is not finished until the site page covers it. A new page needs its route in examples/docs/src/routes.ts and a nav entry in examples/docs/src/nav.ts. Never point a site page at a docs/*.md path — that file does not exist for a reader on the site. Write a site page for someone using the feature: what to do, and what they will observe. Validation, rejection, and hardening behaviour is documented by its error message, not in prose, so a bug fix or review finding normally changes no site page. When a page must change, rewrite the affected sentence instead of appending a clause to it. Implementation detail and exhaustive guarantees belong in docs/. examples/docs/test/site-content.test.ts caps paragraphs and list items at 600 characters and pages at 2,500 words, and checks every internal link. When you finish work update the docs and skills if needed. When making changes that affect published packages, create a changeset (.changeset/<name>.md) describing the change. Use patch/minor/major as appropriate. Normally use one direct sentence stating the user-visible outcome. Add a second sentence only when an important behaviour needs clarification; add a short migration note or example only for a breaking change. A changeset becomes a CHANGELOG entry, not a miniature PR description: never narrate the implementation, investigation, tests, edge cases, rationale, benchmarks, alternatives, or review history. If it needs headings, bullets, or multiple paragraphs, it is too long. Before committing, always run pnpm run verify. It builds, formats, lints, then runs typecheck, the unit tests, and the bench:check client-byte gate in parallel when system load permits, then e2e, and prints output only for failing steps. The build and typecheck steps are incremental, so an unchanged package is not rebuilt or re-checked — do not reach for --skip-build. Pass --check to report formatting and lint instead of rewriting files. When creating a pull request, always follow .github/PULL_REQUEST_TEMPLATE.md and fill any non-applicable sections with N/A.