3.2 KiB
Development
This is the contributor entry point for ConfigKit. Read the task-specific owners below before making changes. The repository is in pre-implementation: it has no Go module, packages, tests, or executable examples yet. The component overview owns the implementation inventory.
Initial orientation
- Inspect the working tree and preserve unrelated changes.
- Read the architecture policy for code or design work.
- Read the policy, contract, and internal documents applicable to the task.
- Inspect relevant implementation and tests where they exist before changing them.
Task-specific reading guide
| Task | Read |
|---|---|
| Repository orientation or component responsibility | Architecture policy and component overview |
| Documentation changes | Documentation policy and the owning document |
| Architecture decisions or future work | Documentation policy, initial target design, and relevant ADRs listed below |
| Code and test changes | Architecture policy, testing policy, and owning contracts/tests as they are introduced |
| Examples or copyable assets | The owning implemented contract and related maintained examples, once available |
| Release preparation | Release policy and release-readiness gaps; the operational runbook will be added before release |
Accepted decisions:
For cross-cutting changes, follow every applicable row. The implementation plan owns the ordered stages and their acceptance checks; all remain pending until implementation evidence is recorded.
Baseline validation
For the current documentation-only repository:
git diff --check
Also inspect new untracked documents, verify changed local links and heading fragments, and review paths, examples, ownership, and current-versus-planned claims. The command above does not check links or untracked content.
Go validation is not runnable until a module and packages exist. The scaffolding change must establish and verify library test, vet, and build commands here, including their prerequisites. Do not use an application binary build as the library baseline. Add executable-example and other checks when those artifacts are introduced; do not document nonexistent tools as operational.
Once code exists, use focused checks while iterating and validation proportionate to the change under the testing policy. Documentation-only work does not require Go checks unless it changes behavior-bearing examples or commands they validate. Release validation is a separate, stricter gate governed by release policy.