lang/generic: the linter-driven-development plugin for any language

[buzzdan]

What this adds

Step 4 of the Python-edition stream: the generic binding lang/generic/ and its rendered plugin linter-driven-development/ (version 0.1.0, prefix ldd), in one commit so task check stays green for every binding.

• Profile. Scalars are phrases the model reads as instructions, each chosen to read in every core sentence that substitutes it: any-language, detected-language source, lint-suppression, the repository's test command, .<ext>, <test-file suffix>, <comment-marker>. nil: "null", task: concurrent task, doc_form/doc_comment: doc comment, unexported: unexported.
• Core defaults for every slot the Go binding fills. 24 rule slots (canonical examples as language-neutral pseudocode; falsifying questions with the same numbering and detection phrased as "search the language's source files for …"), R10's linter-neighbors line, the skill, agent and command blocks, and routing tables keyed by finding family (complexity, length, nesting, duplication, unused, shadow, unchecked error; unknown → escalate by message, attribute to the linter).
• Generic-only files. Pre-flight detection (marker → row as examples; commands from Taskfile, Makefile, package scripts, CI; no linter → 🟠 finding, review continues), the analyze command's discovery step, the /wire-repo-brain language scope, a gate adapter that dispatches on the marker (go.mod → Go block, pyproject.toml/setup.cfg/setup.py → Python block, neither → structure checks only with an "edges are unverified" first line), and the fixture rows for the matrix. /wire-repo-brain keeps no prefix.
• The worked case files under examples/, as passthrough copies of the Go plugin's six studies, each opening with a note that the Go is for demonstration only and the move holds in any language (Dan's call, second commit). Core cites them by path and the review skill pastes two into agent payloads, so a plugin without them would dangle at run time.
• Two promotions into core. skills/documentation/reference.md (the documentation skill cites it thirteen times; Go-only blocks became includes with neutral defaults) and scripts/check-repo-brain_test.sh (cases in core, fixture rows in the binding). The Go binding keeps its previous matrix verbatim as lang/go/overrides/scripts/check-repo-brain_test.sh — the one override in the repo — so the Go plugin stays byte-identical; the override goes when a Go release adopts the promoted matrix.
• Repo. Root README row and install line, marketplace manifest entry, CLAUDE.md, Taskfile (test-gate runs both matrices), core/README.md, docs/generator.md, docs/language-residue.md.

Checks

task generate && task generate BINDING=generic && task check && task lint-core && task test-gen && task test-gate && task docs:check — all green; git diff --stat go-linter-driven-development empty. Gate matrix: Go 45/45; generic 93/93 (44 cases × Go row and Python row, plus the usage-error case and four detection cases). Soft residue 52 → 99 lines, mostly interface asides and the Go example fences in the promoted documentation reference.

Decisions that deviate from the handoff — please read

1. src_ext is .<ext>, not "the language's source suffix". Every use site glues it to a file name (user/service{{.SrcExt}}:14), where the phrase renders as user/servicethe language's source suffix:14. Same reasoning for test_glob (*<test-file suffix>) and comment_prefix (<comment-marker> See docs/x.md). The residue doc's scalar table is updated.
2. Canonical examples are pseudocode, not paired Go + Python snippets. A Go signature like (Port, error) is a hard residue token, so a Go snippet cannot live under core/includes/; the residue doc records this.
3. The gate matrix is promoted with a Go override rather than left as Go passthrough, so the generic adapter gets the 45-case matrix per detection row without duplicating the cases.

Open questions

• The README's linter-phase promise is drafted under "The linter phase without a binding" with a blockquote flag; it is the open question from the handoff.
• lang renders as "any-language" — "Using ldd workflow for this any-language code work" reads a little odd; the roadmap's "the repository's language" reads worse in the same slots. Easy to change in the profile.

Not in this PR

The floor run (steps 5–6), the ldd-evals prompt-prefix variable, and any Python material.

🤖 Generated with Claude Code

https://claude.ai/code/session_018Gc92pr3YAZt1g5EvJgKqt