Sync lenstringzero across linter docs and spec contract (21 → 22)

[Copilot]

lenstringzero was registered in the analyzer driver but missing from the documented/public spec surface, leaving docs stale at 21 analyzers and omitting spec coverage for the new analyzer entrypoint. This PR aligns package docs, README spec, and spec-test expectations to the 22-analyzer set.

• Documentation surface (pkg/linters/doc.go)

  • Updated the analyzer count from 21 to 22
  • Added the lenstringzero rule description to the canonical analyzer list

• README spec surface (pkg/linters/README.md)

  • Added lenstringzero to the overview subpackage list
  • Added lenstringzero row in Public API → Subpackages
  • Added lenstringzero in the usage import/analyzer example
  • Added lenstringzero to internal dependency listing
  • Placement follows existing ordering (after largefunc, before manualmutexunlock)

• Spec contract enforcement (pkg/linters/spec_test.go)

  • Added lenstringzero import
  • Added {"lenstringzero", lenstringzero.Analyzer} to documentedAnalyzers()
  • Updated the spec comment/count from 21 to 22 documented analyzer subpackages

{"largefunc", largefunc.Analyzer},
{"lenstringzero", lenstringzero.Analyzer},
{"manualmutexunlock", manualmutexunlock.Analyzer},

[github-actions]

🧠 Matt Pocock Skills Reviewer has completed the skills-based review. ✅

[github-actions]

✅ Design Decision Gate 🏗️ completed the design decision gate check.

No ADR enforcement needed: PR #37751 does not have the 'implementation' label (has_implementation_label=false) and has only 14 new lines in business logic directories (default_business_additions=14, threshold=100). Neither Condition A nor Condition B is met.

[github-actions]

✅ PR Code Quality Reviewer completed the code quality review.

[Copilot]

Pull request overview

This PR brings the public-facing linter documentation and the spec-enforcing tests back in sync with the actual registered analyzer set by adding the already-implemented lenstringzero analyzer to the documented/spec surface, updating the documented analyzer count from 21 to 22.

Changes:

• Update pkg/linters/doc.go to reflect 22 active analyzers and include lenstringzero in the canonical list.
• Update pkg/linters/README.md to document lenstringzero across the overview list, Public API table, usage example, and dependency list.
• Update pkg/linters/spec_test.go to include lenstringzero in the documented analyzer contract (imports + documentedAnalyzers() + count comment).

Show a summary per file

File	Description
pkg/linters/spec_test.go	Extends the README-backed spec contract to include lenstringzero and updates the documented analyzer count to 22.
pkg/linters/README.md	Documents lenstringzero consistently across the overview, public API, usage example, and dependency listing.
pkg/linters/doc.go	Updates package docs to list 22 analyzers and adds the lenstringzero entry.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 3/3 changed files
• Comments generated: 0

[github-actions]

🧪 Test Quality Sentinel completed test quality analysis.

[github-actions]

Skills-Based Review 🧠

Applied /grill-with-docs — changes look correct and complete. Approving.

📋 Analysis Highlights

What was checked

• Descriptions match implementation: The lenstringzero package doc, Analyzer.Doc, README overview, and Public API table all accurately describe the analyzer behaviour (flagging len(s) == 0 / len(s) != 0 on strings).
• Alphabetical ordering preserved: largefunc < lenstringzero < manualmutexunlock ✅ across all four README sections, doc.go, and spec_test.go.
• All four README surfaces updated: overview list, Public API → Subpackages table, usage import/analyzer example, and internal dependency listing.
• Spec contract correctly tightened: documentedAnalyzers() entry and the inline comment enumeration both updated; count 21 → 22 is consistent across doc.go and spec_test.go.
• Naming convention followed: description label len-string-zero in the internal deps section matches the hyphenation pattern used by peers (large-func, fprintln-sprintf).

Positive Highlights

✅ PR description is thorough — clearly explains which surfaces were stale and why
✅ README uses s == "" (more explicit than the bare == "" in Analyzer.Doc) — a clearer read for users
✅ No implementation logic touched; a focused, low-risk sync

🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer · 126.8 AIC · ⌖ 13.4 AIC

[github-actions]

🧪 Test Quality Sentinel Report

✅ Test Quality Score: 100/100 — Excellent

Analyzed 1 test scenario (new lenstringzero table entry extending existing table-driven tests): 1 design, 0 implementation, 0 guideline violations.

📊 Metrics & Test Classification (1 test scenario analyzed)

Metric	Value
New/modified test scenarios analyzed	1
✅ Design tests (behavioral contracts)	1 (100%)
⚠️ Implementation tests (low value)	0 (0%)
Tests with error/edge cases	1 (100%)
Duplicate test clusters	0
Test inflation detected	No
🚨 Coding-guideline violations	0

Test Classification Details

Test	File	Classification	Issues Detected
documentedAnalyzers()["lenstringzero"] entry → drives TestSpec_PublicAPI_SubpackageAnalyzers/lenstringzero, TestSpec_UsageExample_AnalyzersUsable, TestSpec_DesignDecision_UniqueAnalyzerNames	pkg/linters/spec_test.go:72	✅ Design	None

Nature of Change

No new test functions were added. The PR modifies the documentedAnalyzers() table slice, adding one new entry ({"lenstringzero", lenstringzero.Analyzer}). This extends three existing table-driven tests:

• TestSpec_PublicAPI_SubpackageAnalyzers/lenstringzero — checks the analyzer is non-nil, is *analysis.Analyzer, has Name set, and has Run wired. The require.NotNil catches the nil-pointer failure condition (edge case credit).
• TestSpec_UsageExample_AnalyzersUsable — checks the analyzer is referenceable in a multichecker slice.
• TestSpec_DesignDecision_UniqueAnalyzerNames — contributes lenstringzero.Analyzer.Name to the uniqueness invariant check.

Language Support

Tests analyzed:

• 🐹 Go (*_test.go): 1 test scenario — unit (//go:build !integration) ✅
• 🟨 JavaScript (*.test.cjs, *.test.js): 0 tests

Verdict

✅ Check passed. 0% of new test scenarios are implementation tests (threshold: 30%). Build tag present. No mock libraries. All assertions carry descriptive messages. Inflation ratio: 7 test lines / 7 production lines (README + doc.go) = 1.0, well within limits.

📖 Understanding Test Classifications

Design Tests (High Value) verify what the system does:

• Assert on observable outputs, return values, or state changes
• Cover error paths and boundary conditions
• Would catch a behavioral regression if deleted
• Remain valid even after internal refactoring

Implementation Tests (Low Value) verify how the system does it:

• Assert on internal function calls (mocking internals)
• Only test the happy path with typical inputs
• Break during legitimate refactoring even when behavior is correct
• Give false assurance: they pass even when the system is wrong

Goal: Shift toward tests that describe the system's behavioral contract — the promises it makes to its users and collaborators.

References: §27118693886

🧪 Test quality analysis by Test Quality Sentinel · 220.6 AIC · ⌖ 19.2 AIC · ◷

[github-actions]

✅ Test Quality Sentinel: 100/100. Test quality is excellent — 0% of new test scenarios are implementation tests (threshold: 30%). The lenstringzero entry correctly extends three existing table-driven spec tests with a design-level behavioral contract check.

[github-actions]

REQUEST_CHANGES — one blocking regression in the workflow step; the lenstringzero registry additions are correct.

🔴 Blocking issue: `set -e` + grep without `|| true`

The Extract designer file metadata step removes || true from two grep commands inside { ... } command groups. GitHub Actions runs run: steps with bash -eo pipefail; a zero-match grep returns exit code 1, which set -e treats as a fatal error. The step then aborts before fully writing its output files, breaking the drift-audit agent that depends on them.

This is a latent fragility: it works today only because both files happen to contain .github/aw/ references, but will silently break the workflow whenever either file is refactored.

See inline comments for the specific lines.

✅ Looks fine: `lenstringzero` additions

The README, doc.go, and spec_test.go changes correctly register the new linter: count updated (21→22), alphabetical ordering maintained in all lists, import and blank-identifier entries added. No issues.

🔎 Code quality review by PR Code Quality Reviewer · ⌖ 13.8 AIC