TT Claude Memory

feedback_loc_not_significant_metric

Properties2
descriptionRich directive 2026-04-26 — drop "Lines of Code" / "LOC budget" framings from any forward planning doc, scorecard criterion, or briefing artifact. Use structural-completeness metrics instead (Gate 1/2/3 per A-21/A-22/A-56/A-63/A-66/A-33, conformance tier, coverage of 21 v6.6 extensions, primitive-count, classifier-count, AC-1 cross-cut count).
tagsfeedback, planning, metrics, structural-completeness, anti-loc

3 min read

LOC is NOT a significant metric for INHERIT v2 planning

Rule: Do not use “Lines of Code” / “LOC budget” / “LOC target” as a significant planning metric, scorecard criterion, completeness gate, or commitment artifact in INHERIT v2 / InheritKit / IAS work going forward.

Why: Rich directive 2026-04-26T07:00 (“i don’t think we should have Lines of Code as a significant metric”) — repeated correction. Precedent already locked at architecture-state v2.12 (2026-04-24T23:55) when Rich directed Wills brief Decision #5: “REPLACED LOC target with Gate 1/2/3 structural completeness metric (session-consistent with A-21/A-22/A-56/A-63/A-66/A-33; LOC falls where it falls)”. I carried “LOC budgets per module” into the §3 framing in plan-from-the-beginning §2.4 bridge text without honoring the precedent — Rich corrected.

LOC is a noise metric for spec / standard / formal-DSL work because:

  • Schema density varies wildly across modules (Core has dense type axiomatisation; Commerce is structurally light)
  • Catala / SHACL / LinkML LOC is not comparable to TS/Python LOC
  • Verbose vs terse styles produce different LOC at same structural completeness
  • LOC encourages padding (a known anti-pattern in formal-spec work)
  • LOC backlash compresses what should be careful expression

How to apply:

  1. Never propose LOC budgets per module in any §3 / Phase-1 / Phase-1.5 / module-brief framing.
  2. Never use LOC as a scorecard criterion (c2 Phase-1 LOC realism historically used in §2.2 scorecards is admissible only when it captures implementation effort proxy — but use sparingly and rename to “Phase-1 effort realism” or similar).
  3. Replace LOC framings with:
    • Gate 1/2/3 structural completeness (per A-21/A-22/A-56/A-63/A-66/A-33 — the session-consistent precedent)
    • AC-1 cross-cut coverage (how many modules a primitive serves)
    • Conformance tier (Bronze/Silver/Gold per Bowtie/FHIR-Inferno pattern)
    • 21-v6.6-extensions coverage (Phase-1.5 stress-test fidelity)
    • Primitive-count + classifier-count + VC-schema-count (already used; prefer these)
    • CI-gate count (A-21 7→18 has tracked structural maturity better than any LOC metric would have)
  4. Historical LOC references in changelog entries are OK — they record what happened at the time. The directive is forward-looking only.
  5. If LOC sneaks into a phase / module / planning artifact, flag it immediately and propose the structural-completeness replacement.

Boundary test: “Am I proposing this as a target/budget/commitment, or just a passing observation?” If target/budget/commitment → drop it. If passing-observation in changelog/history → fine.

Recurrence-prevention pattern: when authoring §3 / §4 / §5 of plan-from-the-beginning, audit my own framing text for “LOC” / “Lines of Code” / “size budget” / “complexity budget” before sending. Catch in pre-send review, not via Rich correction.

Graph View

Backlinks