← ClaudeAtlas

go-implementation-ownershiplisted

Source ownership in Go. Use when accepted behavior is closed but its package, file, canonical source, dependency direction, or proof location is not.
Dankosik/go-service-template-rest · ★ 7 · API & Backend · score 78
Install: claude install-skill Dankosik/go-service-template-rest
# Go Implementation Ownership Every piece of logic, wiring, and proof has one **owner**. Two plausible owners means placement is not decided. `responsibilities -> owner -> dependency direction -> generated/manual authority -> proof placement -> cleanup` For a delegated Decision or Review, or when the active artifact requires its result interface, load the [shared specialist contract](../../contracts/specialist-contract.md). For every changed responsibility, build `OwnerRecord{responsibility, canonical_source, package, file, dependency_direction, sequence_owner, existing_proof_location_if_known, competing_paths, cleanup}` from accepted behavior through callers, wiring, generated and manual sources, and cleanup. Ownerless, duplicated, or competing production paths are findings. Implementation chooses new test cases, files, and proving layers while writing code; their absence does not block the ownership decision. The nearest record wins: read package `doc.go`, `README.md`, and seam comments before [Repository Architecture](../../../docs/repo-architecture.md), [Project Structure](../../../docs/project-structure-and-module-organization.md), and [Configuration Source Policy](../../../docs/configuration-source-policy.md). Gates prove only what they inspect; use `.golangci.yml` and `scripts/ci/` to subtract mechanical coverage rather than treating green as ownership evidence. Cohesion: Group declarations that must be understood and changed together. Use package boundaries for d