fix(coding-dev): prefer a test over the build script for size limits

A shell check only runs where that script runs. A test travels with the repo,
needs no extra tooling, and fails with a message naming the offending files.
Enforcement is now a preference order: native linter rule > test > build
script as fallback, with a worked example and a note on why a per-compile
build hook usually is not worth the incremental-build cost.

Propagated per language: rust (clippy has no file-length lint -> workspace
root test), js-typescript (ESLint max-lines covers both natively, no test
needed), go/python/csharp (linter for functions, test for files), bash (don't
reimplement in the gate what a test can assert).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
BluscreamandClaude Opus 5 committed 2026-09-18 12:52:37 +02:00
1 parent 5d96e69d2b
commit 32b47b075b
7 files changed
+60 -8

No files matched your search

+2 -1
View File
@@ -137,7 +137,8 @@ CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o bin/app ./cmd/app
- Keep the exported surface small. Unexported by default.
- Embed frontend/static assets with `//go:embed` for single-binary distribution — the frontend
itself follows [`js-typescript.md`](skills-public/code-languages/js-typescript.md).
- File and function size limits from the general rules apply.
- File and function size limits from the general rules apply — `funlen` in `golangci-lint`
covers functions; put the file limit in a test (see [`coding-dev.md` §4](skills-public/coding-dev.md)).
---