The reusable engineering conventions behind the Purview projects — how a repository is shaped, how architecture is held by tests, how a change is verified in tiers, how data crosses a boundary, and how coding agents are enabled to work in a codebase without hand-holding.
Documentation-first. This repository ships no library and no NuGet package. It contains the conventions themselves, ready-to-copy templates, and a small in-repo reference implementation whose only job is to prove the conventions compile, run, and fail when they should.
| Area | Question it answers |
|---|---|
| Getting started | What is the smallest repository that satisfies every rule, in the order you build it? |
| Engineering principles | What are the non-negotiable rules, and where is each one stated in full? |
| Repository shape | Where does a file go, and what is it called? |
| Project responsibilities | What is each project for, how is it named, and what may it depend on? |
| Architecture as tests | How does the build refuse a dependency that points the wrong way? |
| Verification model | Which checks run, in which tier, for which change? |
| Contracts and data exchange | How do value objects, schemas and results cross a boundary? |
| Testing and test data | How are tests written, and where does their data come from? |
| Agent enablement | How is a repository made legible to a coding agent? |
| Agent skills distribution | How is a skill published once and reach an agent? |
| Agent guidance skills | Which shared guidance ships as a skill, and what context comes first? |
| Documentation convention | How is the wiki written, structured and published? |
| Worked examples | What does the reference implementation under src/ actually demonstrate? |
| Adopting this at your scale | Which parts apply to a small, medium or large repository? |
| Contributing | How do I change the playbook itself? |
| Release flow | How does a change become a version, and what does a release mean here? |
- New to the playbook? Getting started walks the smallest repository that satisfies every rule.
- Adopting it? Adopting this at your scale picks the
subset that fits, and
templates/is the copy-paste starting point. - Want to see it run? Worked examples walks the reference
implementation under
src/, which this repository's own pipeline builds and tests.
| Path | Purpose |
|---|---|
docs/wiki |
The playbook. Aggregated by the purview-dev website. |
templates/ |
Ready-to-copy starter files for a repository adopting the playbook. |
src/ |
The reference implementation: a layered repository whose architecture rules are tests. |
mkdocs.yml |
Wiki site configuration (docs_dir: docs/wiki). |
.config/purview-build.json |
Pipeline configuration for the shared Purview build workflow. |
Justfile |
Supported local workflow commands. |
package.json |
Authoritative version for the repository. |
just build # dotnet build (Debug)
just test # run the unit tests
just lint-check # CSharpier check
just pipeline-pr # restore, build, lint, test through the shared Purview.Build tool
just scrub # reset bin/obj, forced restore, build-server shutdown
MIT.