Dead Code Detection

Overview

Dead code — written but never called, imported, or used — is a direct signal of incomplete integration: a function nothing calls means the feature isn't wired up. In loom it serves two roles: wiring verification (catch implemented-but-unintegrated code) and code quality (cleanup). Most valuable in integration-verify stages as a final gate over all implementation stages.

⚠️ truths is GONE as a standalone field. Put dead-code checks in the first-class deadcodecheck field (a goal-backward layer, run by loom check) or in acceptance (a build/lint command that exits non-zero on findings). A top-level truths: block is rejected as an unknown field.

If dead code survives implementation it usually means: feature not wired (command unregistered, route unmounted), test code never run, refactor leftovers, or an incomplete implementation.

The deadcodecheck field (preferred, first-class)

deadcodecheck is a goal-backward check evaluated by loom check <stage-id>. Schema:

dead_code_check:
  command: "cargo build --message-format=short 2>&1"
  fail_patterns: ["warning: unused", "is never read", "never constructed"]
  ignore_patterns: ["generated.rs", "#[allow(dead_code)]"]

Exactly how loom evaluates it (verify/goalbackward/deadcode.rs):

1. Runs command in working_dir, 120 s timeout, capturing stdout and stderr.
2. Scans the combined output line by line.
3. A line is a violation if it contains any failpattern (plain substring, not regex) AND contains no ignorepattern.
4. Each violating line becomes one gap.

⚠ The command's exit code is ignored — only output text matters. So cargo build (exit 0 with warnings) works fine; you do NOT need -D warnings. This is the key difference from an acceptance command, which passes/fails on exit code.

⚠ ignorepatterns match the whole output line, so you can suppress by symbol name, file path, or an #[allow(...)] echo — whatever appears on the tool's line. Substring, so oldhelper also ignores oldhelper2.

⚠ Choose fail_patterns that appear on the SAME line as the offending item. Tools that split a finding across lines (a header line + an indented location line) may put the symbol name on a different line than the keyword — test the real output first.

deadcodecheck vs acceptance

Use deadcodecheck when you want dead code counted as goal-backward proof; use acceptance when a tool already exits non-zero on findings and you want it in the build gate.

Per-language tools and patterns

⚠ Tools ship NO deps in a fresh loom worktree (nodemodules, cargo tool binaries, staticcheck). Install or vendor them in knowledge-bootstrap, or require them as preinstalled prerequisites; never bypass the host sandbox with excludedcommands. Otherwise the command errors and the check silently "passes" on empty output or fails opaquely. Rust's compiler-based check has no such dependency; prefer it.

Rust example — both forms

# Goal-backward form (exit code ignored, pattern-driven):
dead_code_check:
  command: "cargo build --message-format=short 2>&1"
  fail_patterns: ["warning: unused", "is never read", "never constructed"]
  ignore_patterns: []

# OR acceptance form (exit-code driven — needs -D):
acceptance:
  - "cargo clippy -- -D warnings"        # dead_code is a subset of clippy warnings

Tool config keys (suppress false positives at the source)

ts-prune   .tsprunerc          {"ignore": "index.ts|types.d.ts"}
vulture    pyproject.toml       [tool.vulture] min_confidence=80  paths=["src"]  ignore_names=["setUp","tearDown","test_*"]
staticcheck .staticcheck.conf   checks = ["all", "-ST1000"]
unimported .unimportedrc.json   {"entry":["src/index.js"], "extensions":[".js",".jsx"], "ignorePatterns":["**/*.config.js"]}

Working directory

Dead-code commands run in workingdir, where the build manifest lives (Cargo.toml, package.json, go.mod, pyproject.toml). If Cargo.toml is at loom/, set workingdir: "loom" — otherwise could not find Cargo.toml. All paths in every field are relative to working_dir; never ../.

False positives — what each tool excludes and how to suppress

Real code that looks unused. Handle via the tool's own mechanism first, ignore_patterns second.

| Cause | Rust | TS/JS | Python | Go | | ----- | ---- | ----- | ------ | -- | | Entry points | fn main() auto-excluded | configure entry in tool config | mark all | exported main-pkg funcs excluded | | Test code | #[cfg(test)] auto-excluded | exclude test dirs in config | ignore test/setUp/tearDown | test.go handled | | Framework magic (derives/decorators) | #[allow(dead_code)] on the item | tool ignore for decorators | vulture respects all | — | | Public API in a lib | pub items excluded by default | ignore lib entry in .tsprunerc | all | exported (capitalized) excluded | | Feature-gated / build-tagged | run with --features=all | enable during check | enable during check | build tags to include variants | | Reflection / dynamic load | document + integration test | — | — | assigned-to-var for reflection |

Golden rule: prefer a language-native suppression (#[allow(deadcode)], all, tool config) that lives WITH the code over a broad ignorepatterns entry that can mask real regressions later.

Combine with wiring for a reliable signal

Dead-code detection is a strong signal, not proof. The triple check catches integration holes reliably:

stages:
  - id: integration-verify
    stage_type: integration-verify
    working_dir: "loom"
    acceptance:
      - "cargo test"
      - 'loom new-command --help'                 # functional: feature reachable
    dead_code_check:
      command: "cargo build --message-format=short 2>&1"
      fail_patterns: ["warning: unused", "never constructed"]
    wiring:
      - source: "src/cli/dispatch.rs"
        pattern: "Commands::NewCommand"           # CONSUMER: dispatch arm, not `mod new_command`
        description: "New command dispatched in CLI"

Dead-code says "code is used somewhere"; wiring says "used at the RIGHT place"; the functional command says "reachable by a user." A stub that's referenced only by its own unit test passes dead-code but fails the functional check.

YAML gotchas

• ⛔ Never put triple backticks inside a YAML description — breaks parsing.
• Quote every command; default to YAML single quotes so nothing inside is special.
• For an acceptance negation, ! cmd | rg -q 'warning:' passes when the pattern is absent (! inverts exit code). This is shell !, valid in acceptance — but wiring patterns treat ! as a literal, not negation.
• Prefer rg over grep (cross-platform, no BSD/GNU -P differences).

Placement

• integration-verify — primary home; catches orphans from every implementation stage.
• Per implementation stage — optional, for fast feedback; scope to the package touched (cargo clippy -p auth -- -D warnings).
• knowledge-bootstrap — install any external tool the plan's checks depend on.

Checklist

• Dead-code checks use deadcodecheck (goal-backward) or acceptance (exit-code) — NOT a removed truths: block
• fail_patterns are substrings that appear on the SAME output line as the finding (verified against real tool output)
• deadcodecheck command doesn't rely on exit code (it's ignored); acceptance form uses -D/--error so it exits non-zero
• Any external tool (ts-prune, vulture, staticcheck, unimported) is installed in the worktree or bootstrap stage
• working_dir points at the build manifest; all paths relative to it, no ../
• False positives suppressed with a language-native mechanism where possible, ignore_patterns only as fallback
• Paired with wiring (consumer site) + a functional command for reliable integration proof
• No triple backticks in any description