[deep-report] Share graderManifestEntry type between writer (compiler) and reader (CLI audit) #64946

Description

pkg/workflow/compiler_yaml_graders.go:86-101 defines graderManifestEntry with 14 JSON fields (the writer, serializing the grader manifest). pkg/cli/audit_report_graders.go:67-73 defines a second, independently-maintained graderManifestEntry with only 5 of those fields (ID, Name, Unit, Direction, Threshold) — the reader. Because these are separate Go types connected only by matching JSON tags, renaming or changing a field's JSON tag in the writer (e.g. Unit) would silently stop populating that field when the CLI reads the manifest back, with no compiler error to catch it.

Expected Impact

Removes a silent-divergence risk in the operational-value/grader audit pipeline: a future writer-side field rename would otherwise fail silently (reader just gets a zero value) rather than fail to compile. Sharing one type (e.g. moving the narrower struct into a package both can import, or having the CLI reader deserialize into the workflow package's exported type) makes the schema a single source of truth.

Suggested Agent

Code Simplifier or a general refactoring agent (Go-only change, no behavior change expected since the reader only needs a subset of fields).

Estimated Effort

Quick (<1 hour) — export graderManifestEntry (or a shared subset type) from one location and update the other to reference it.

Data Source

DeepReport Intelligence Briefing cycle (2026-10-02), surfaced via discussion #64752 (Typist: Go type consistency analysis).

Generated by 🔬 Deep Report · claude · agent · 298.7 AIC · ⌖ 7.67 AIC · ⊞ 7.3K · ◷

• expires on Oct 3, 2026, 10:53 PM UTC-08:00