Skip to content

.kanon-lint-baseline.toml burndown has no tracking issue and remove_after is 5 weeks out #277

Description

@forkwright

Finding

.kanon-lint-baseline.toml was created in PR #149 (2026-06-30, commit e6ff656) to let the
canonical fleet CI gate pass while carrying 51 pre-existing lint violations that PR was not
responsible for. Its own remove_after field commits to a burndown deadline:

created = "2026-06-30"
remove_after = "2026-09-30"
reason = "pre-existing theatron lint debt; tracked for cleanup in separate passes. This PR
adopts canonical fleet CI (fixing gate-attestation injection) and is not responsible for the
pre-existing code debt."

The file has had zero commits since its creation (git log --oneline -- .kanon-lint-baseline.toml
shows only e6ff656), and no open or closed issue in this repo tracks the promised cleanup
(gh issue list --state all --search "baseline" / "kanon-lint-baseline" / "lint debt baseline"
all return nothing relevant). With five weeks left before remove_after, there is no place for
that burndown to land.

sphragis carried the same pattern and closed the gap with a real tracking issue
(sphragis#37 -> sphragis#39, merged) that enumerated the debt by rule and file before fixing it.
theatron has no equivalent — this issue is that equivalent.

Evidence

Current baseline contents, grouped by rule (51 entries total, grep -c '^\[\[' .kanon-lint-baseline.toml):

Rule Count Example sites
TOPOLOGY/shallow-struct 18 crates/gramma/src/highlight.rs:92, crates/keryx/src/sse.rs:11, crates/parodos/src/fuzzy.rs:17
TESTING/tautological-test 12 crates/bathron/src/dialogs.rs:186, crates/bathron/src/logging.rs:480, crates/bathron/src/logging.rs:507
DOCS/stale-local-link 9 _meta/INTEGRATION.md:148, _meta/INTEGRATION.md:309, _meta/INTEGRATION.md:313
COMMENTS/journal-shaped 4 crates/dokimasia/src/tokens.rs:4, crates/keryx/src/error.rs:13, crates/parodos/src/lib.rs:4
NAMING/no-owner-prefix 3 examples/full_app/Cargo.toml:1, examples/minimal/Cargo.toml:1, examples/tray_smoke/Cargo.toml:1
RUST/non-exhaustive-enum 2 crates/parodos/src/clipboard.rs:39, crates/parodos/src/theme.rs:72
COMMENTS/deflection-without-tracking 1 crates/parodos/src/sanitize.rs:534
CONTEXT/preamble-required 1 AGENTS.md:1
RUST/no-direct-process-command 1 crates/parodos/src/clipboard.rs:102

Full list with per-entry hashes is in .kanon-lint-baseline.toml at the repo root.

Roughly two-thirds of the count (TOPOLOGY/shallow-struct, TESTING/tautological-test,
RUST/non-exhaustive-enum, RUST/no-direct-process-command — 33 of 51) touches Rust source and
needs a build/test cycle to verify a fix doesn't regress; the rest (DOCS, COMMENTS,
NAMING/no-owner-prefix on example Cargo.toml names, CONTEXT/preamble-required) is
docs/naming/comment work that doesn't need compilation to verify.

Why this matters

remove_after = "2026-09-30" is a self-imposed deadline with no enforcement mechanism behind it
other than someone reading the file — if nobody is tracking the burndown, the deadline passes
silently and the baseline either lingers past its own stated expiry or gets bulk-extended without
the cleanup ever happening, which is the exact drift sphragis's issue caught for itself before it
reached that point.

Desired correction

Burn down the 51 baseline entries (or the subset still live — some may already be fixed
elsewhere without the baseline being updated, in which case removing the stale entry is part of
the work) before remove_after, following sphragis#39's pattern: fix per rule group, verify with
kanon lint (via mcp__kanon__lint_check or kanon lint --all) that each targeted rule/site
clears, run the full gate, and shrink .kanon-lint-baseline.toml to match. Anything that turns out
to be a genuine false positive gets a kanon:ignore with a stated reason instead of a baseline
entry, filed upstream against forkwright/kanon if the rule itself is wrong.

Done when: .kanon-lint-baseline.toml either does not exist, or every remaining entry in it
has a comment/PR reference explaining why it is still there past remove_after — and
kanon lint --all against origin/main shows 0 findings for the rules currently baselined here
that are not otherwise exempted with a stated reason.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions