3.5 KiB
Development
This is the contributor entry point for ConfigKit. Read the task-specific owners below before making changes. The repository is in early implementation: its public loader currently covers one strict source, typed defaults, schema-version checks, recorded application resolution, semantic validation, and metadata. 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 and recorded implementation evidence.
Baseline validation
Install Go 1.25.0 or a supported patched/newer Go toolchain. Acquire declared dependencies explicitly before entering an offline development or validation environment:
go mod download
Run the library baseline from the repository root:
go test ./...
go vet ./...
go build ./...
git diff --check
The default tests must remain deterministic and runnable without network access or credentials after dependency acquisition. Also inspect new untracked files, verify changed local links and heading fragments, and review paths, examples, ownership, and current-versus-planned claims. The commands above do not check links or untracked content. 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.