Lint: flag invariants and action.preserves not covered by a test
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 45/100
Direzione di ricerca
Risolvi innanzitutto la questione della convenzione dei marker rispetto al manifest sidecar, incluso il modo in cui si collega all’issue #5 e all’unico input YAML. Poi leggi le convenzioni interne di lint esistenti e i test golden/lint-model, e registra la decisione in audits/ se appropriato. Il lavoro è completato quando un rilievo di completezza o tracciabilità identifica le voci invariant.id e action.preserves non referenziate, con il comportamento di warning predefinito e quello in strict mode coperti dai test.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
Add a lint/completeness signal that flags every invariant.id (entity-level and model-level) and every action.preserves entry that is not referenced by any test in the repo. This is the durable, on-mission version of "wire testing in from the model": modelith already emits completeness findings (e.g. entities with no invariants, entities no scenario touches). This extends that discipline outward to the model↔test relationship.
Why a checker, not a generator
The tempting version — generate a skipped t.Skip test stub per invariant — is a false green: coverage tools count the stub as present, go test passes, CI is green, and the test asserts nothing. A directory of 40 skipped invariant tests reads as "we have invariant coverage" while proving nothing. Worse, the model↔test link is by invariant.id, and renaming an invariant is a first-class modelith operation (IDs sharpen as understanding does) — a generator would then clobber human-written bodies or orphan them.
Checking references instead of generating code turns the false-green inside out: rather than emitting stubs that lie, flag the invariants that lack a real test. It's deterministic, its output is disposable (a finding, not owned code), and it survives renames because it checks references rather than owning generated files.
Open design question (must resolve before building)
modelith today reads a single YAML file; traceability requires knowing what tests exist. Two candidate input surfaces:
- Marker convention — tests reference the invariant id in a structured, greppable way (e.g. a comment token or test-name convention); modelith scans a configured test path.
- Sidecar manifest — a small mapping file (
invariant-id → test reference) that the #5 skill emits and the engineer maintains; modelith validates coverage against it.
Option 2 keeps modelith's "reads declared inputs" character intact and pairs naturally with #5; option 1 is lower-friction but expands modelith into a repo scanner. Decide this first — it's the crux of whether this stays on-mission.
Scope
- New completeness (or a new "traceability") category finding.
- Likely
warningseverity by default (an unproven invariant is a gap, not a structural error), with an opt-in strict mode consistent with how completeness is already treated. - Golden/lint-model test coverage consistent with the existing
internal/lintconventions.
Relationship to the other issues
- Consumes the traceability convention produced by #5.
- Replaces the discarded "generate skipped test scaffolds" idea (former Tier 2).
Background
Descends from "Tier 2" of a three-tier design discussion, reshaped by a skeptic pass from generate stubs to check references. Consider recording the decision in audits/.
🤖 Generated with Claude Code
- Lingua principale
- Go
- Stelle
- 32
- Fork
- 5
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di stacklok/modelith
-
enhancement
Difficoltà 2/5 Mezza giornata Idoneità per principianti 68/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 28/100
-
documentation
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
Tutte le issue di stacklok/modelith
Issue simili
-
kind/bug needs-triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
matrixorigin/matrixone#29223 ·
-
needs-acceptance wg/data-plane-networking
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
vllm-project/semantic-router#4024 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
alexgorbatchev/dotfiles#107 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 84/100