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>

code-languages/bash.md

@@ -125,6 +125,10 @@ mistakes before a human does.
 - **A skipped test fails the gate.** Never let a skip report green.
 - **Print a summary with numbers**, not just a verdict — counts of warnings, suppressions, and
   file-size violations. A suppression count that has grown is worth seeing even on a pass.
+- **Don't reimplement in the gate what a test can assert.** Checks like file-size limits
+  belong in the test suite where they travel with the repo and fail with a useful message;
+  the build script is the fallback for projects with no suite to hang them on. See
+  [`coding-dev.md` §4](skills-public/coding-dev.md).
 - Keep per-step logs in a known directory so a failure can be read after the fact.
 - **Never bypass a failed gate** by copying a binary or running the install step by hand. Fix
   the failing step; do not weaken the check to make it pass.

code-languages/csharp-dotnet.md

@@ -80,7 +80,8 @@ dotnet build MySolution.sln -warnaserror
 - Pattern matching and switch expressions over `if`/`else` ladders.
 - `IReadOnlyList<T>` / `IReadOnlyDictionary<K,V>` in public signatures returning collections.
 - `internal` by default; `public` only for genuine API surface.
-- File and function size limits from the general rules apply.
+- File and function size limits from the general rules apply — put the file limit in a test
+  rather than an MSBuild target (see [`coding-dev.md` §4](skills-public/coding-dev.md)).
 - `dotnet format` before committing.
 
 ---

code-languages/go.md

@@ -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)).
 
 ---
 

code-languages/js-typescript.md

@@ -141,7 +141,8 @@ Attach an `AbortController` to every long-lived `fetch` and abort it in cleanup.
   a new formatter or lint config into a project that already has one.
 - **One file until it earns a split** — around 250 lines for a self-contained plugin/feature,
   or when a second file is genuinely reusable (`utils.ts`, `types.ts`, `components/`).
-  Hard limits from the general rules still apply.
+  Hard limits from the general rules still apply: ESLint's `max-lines` and
+  `max-lines-per-function` cover both natively, so prefer those over a separate test here.
 
 ---
 

code-languages/python.md

@@ -132,7 +132,9 @@ When talking to a rate-limited API (a chat platform, a store, a tracker):
   installable package** with its own repo and version, consumed as a dependency.
 - Keep persistent state in the framework's own config/storage system so it survives restarts;
   do not invent a parallel JSON file beside it.
-- File and function size limits from the general rules apply.
+- File and function size limits from the general rules apply — Ruff's `PLR0915` covers
+  function length; put the file limit in a pytest case (see
+  [`coding-dev.md` §4](skills-public/coding-dev.md)).
 
 ---
 

code-languages/rust.md

@@ -75,6 +75,10 @@ workspace = true
 - **Re-test every `#[allow]` periodically.** If removing one produces no warning, delete it.
 - `too_many_lines` is the mechanical enforcement of the 100-line function limit. A function
   that trips it wants extracting, not an allow.
+- Clippy has **no file-length lint**, so the 1000-line file limit belongs in a test — see
+  [`coding-dev.md` §4](skills-public/coding-dev.md) for the pattern. Put it in the workspace
+  root's `tests/` so one test covers every member crate, walking `src/` plus each
+  `crates/*/src`. `cargo test --workspace` then enforces it for free.
 
 ---