Lint: flag invariants and action.preserves not covered by a test

Aperta
#6 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
go
Ambito
devtools, testing

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

enhancement

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:

  1. 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.
  2. 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 warning severity 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/lint conventions.

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

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di stacklok/modelith

Tutte le issue di stacklok/modelith

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.