2.0 KiB
Development
This is the contributor entry point for thsi application. Use the task-specific reading guide below before making changes. Canonical architecture, contracts, component behavior, and policies remain in their owning documents.
Initial Orientation
Before starting work:
- inspect the working tree and preserve unrelated changes;
- read the architecture policy for code or design work;
- read the policy, contract, and internal documents listed for the task;
- inspect the relevant implementation and tests before deciding how to change them.
Start with:
- Architecture policy for system boundaries, invariants, and non-goals;
- Internal component overview for the current package and component map;
- Documentation policy before changing documentation;
- Testing policy before adding, rewriting, or deleting tests.
Task-Specific Reading Guide
| Task | Read before changing |
|---|---|
| Repository orientation or component responsibility | Internal component overview and architecture policy |
| Examples or copyable assets | The owning contract for the demonstrated behavior and the related files under examples/ |
| Architecture decisions or future work | The documentation policy and relevant accepted ADRs |
For cross-cutting changes, follow every applicable row. Internal component documents own detailed subsystem change recipes.
Baseline Validation
Use focused checks while iterating, then run validation proportionate to the change and the risks described by the testing policy.
The repository-level baseline for code changes is:
go test ./...
go vet ./...
go build ./cmd/scriptorium
Documentation-only work does not require the full Go suite unless it changes commands, examples, generated output, or another behavior that the suite validates. Always check changed links, paths, examples, and canonical ownership.