3 Commits

Author SHA1 Message Date
fd5d305ba7 Merge branch 'main' into policy/scope-golangci-rule-to-vendored-copies
All checks were successful
check / check (push) Successful in 24s
2026-08-30 06:26:09 +02:00
3f8201d532 Require thin cmd/ entrypoints: all logic in internal/ or pkg/ (#54)
All checks were successful
check / check (push) Successful in 13s
Codifies your ruling (2026-08-30, filed as homoicon issue 555): no project logic outside `internal/` or `pkg/`; each `cmd/<name>/` is a single `main.go` whose body is one call into library code.

- `CODE_STYLEGUIDE_GO.md`: strengthens the "keep `main` small" rule to the single-call form and adds the no-logic-outside-`internal/`-or-`pkg/` rule.
- `REPO_POLICIES.md`: annotates `cmd/` in the canonical subdirectory list accordingly. (Root copy is a symlink; one edit covers both.)

Co-authored-by: sneak <sneak@sneak.berlin>
Reviewed-on: #54
Co-authored-by: clawbot <clawbot@noreply.example.org>
Co-committed-by: clawbot <clawbot@noreply.example.org>
2026-08-30 04:20:42 +02:00
a614cd6ffb policy: scope the .golangci.yml rule to vendored copies
All checks were successful
check / check (push) Successful in 9s
Stated unqualified, the rule forbade an agent from modifying
.golangci.yml anywhere, including the canonical copy in this repo --
the only place it can be fixed. Compliance and remediation were
mutually exclusive.

Scope the prohibition to the vendored copy in a consuming repo, which
is the property the rule exists to protect, and name the one legitimate
path for change: a PR against canonical here, merged only by the user.
2026-08-19 14:25:30 +00:00
2 changed files with 23 additions and 20 deletions

View File

@@ -124,10 +124,15 @@ last_modified: 2026-03-18
1. Keep the `main()` function as small as possible.
1. Keep the `main` package as small as possible. Move as much code as is
feasible to a library package, even if it's an internal one. `main` is just
an entrypoint to your code, not a place for implementations. Exception:
single-file scripts.
1. Keep the `main` package as small as possible. Each `cmd/<name>/` directory
contains a single `main.go` whose body is one call into library code (for
example `os.Exit(cli.Main())` calling `internal/cli`). All CLI logic — flag
parsing, subcommand dispatch, argument handling, output formatting — lives
in `internal/` or `pkg/`, not in `cmd/`. `main` is just an entrypoint to
your code, not a place for implementations. Exception: single-file scripts.
1. No project logic outside `internal/` or `pkg/`. Anything in `cmd/` is a thin
entrypoint only.
1. HTTP HandleFuncs should be returned from methods or functions that need to
handle HTTP requests. Don't use methods or your top level functions as

View File

@@ -1,6 +1,6 @@
---
title: Repository Policies
last_modified: 2026-08-20
last_modified: 2026-08-19
---
This document covers repository structure, tooling, and workflow standards. Code
@@ -69,15 +69,8 @@ style conventions are in separate documents:
outputs the project's name. Scripts that need the name call
`script/projectname` — e.g. `script/docker` assembles its image tag from it —
so those scripts stay byte-identical across all repos. Repo-type-specific
verifications (e.g. `go mod tidy` verification in Go repos) belong in
`script/check`, which is the gate the other entrypoints funnel through: it
runs in the Dockerfile build step and therefore in CI, and `script/precommit`
inherits it by calling `script/check`. In `script/precommit` alone such a
check binds only the contributors who installed the hook, and the hook file
itself stays a shim that carries no checks of its own. Anything added to
`script/check` must be read-only, since `make check` must not modify files, so
use a verify or diff mode (`go mod tidy -diff`) rather than a command that
rewrites the tree. Model scripts are at
pre-commit extras (e.g. `go mod tidy` verification in Go repos) belong in
`script/precommit`, not in the hook itself. Model scripts are at
`https://git.eeqj.de/sneak/prompts/raw/branch/main/script/<name>`. The README
must document the provided scripts in an **Entrypoints** section (see the
README requirements below).
@@ -270,11 +263,14 @@ style conventions are in separate documents:
- Make all changes on a feature branch. You can do whatever you want on a
feature branch.
- `.golangci.yml` is standardized and must _NEVER_ be modified by an agent, only
manually by the user. Fetch from
`https://git.eeqj.de/sneak/prompts/raw/branch/main/.golangci.yml`. The
canonical golangci-lint version is v2.12.2 (released 2026-05-06), installed
commit-pinned via
- `.golangci.yml` is standardized. The vendored copy in a consuming repo must
_NEVER_ be modified by an agent: fetch it from
`https://git.eeqj.de/sneak/prompts/raw/branch/main/.golangci.yml` and keep it
byte-identical, so that no repo can quietly loosen its own linting. Linter
configuration changes are made to the canonical copy in the `prompts` repo and
reach consuming repos by re-vendoring; an agent may open a PR against
canonical, which only the user merges. The canonical golangci-lint version is
v2.12.2 (released 2026-05-06), installed commit-pinned via
`go install github.com/golangci/golangci-lint/v2/cmd/golangci-lint@c0d3ddc9cf3faa61a4e378e879ece580256d76e5`.
- When pinning images or packages by hash, add a comment above the reference
@@ -394,7 +390,9 @@ style conventions are in separate documents:
language-specific config). Everything else goes in a subdirectory. Canonical
subdirectory names:
- `bin/` — executable scripts and tools
- `cmd/` — Go command entrypoints
- `cmd/` — Go command entrypoints; thin only: one `main.go` per binary whose
body is a single call into `internal/` or `pkg/`, no project logic in
`cmd/`
- `configs/` — configuration templates and examples
- `deploy/` — deployment manifests (k8s, compose, terraform)
- `docs/` — documentation and markdown (README.md stays in root)