Codereport – track TODOs, refactors, and bugs in your repo with a CLI

Name: Codereport – track TODOs, refactors, and bugs in your repo with a CLI
Availability: InStock
Author: pulko

by pulko·Feb 18, 2026·4 points·2 comments

Visit Project View on HN

AI Analysis

●●SolidSolve My ProblemShip It

Tech debt tracking in-repo beats scattered tickets, but YAML storage may scale poorly.

Strengths

•File + line-range binding is more precise than generic issue trackers, reducing context-switching.
•CI enforcement with expiration dates makes tech debt visible and actionable, not aspirational.
•Repo-owned YAML store means no external service dependency or vendor lock-in.

Weaknesses

•Solves a real problem but competes with GitHub Issues, Linear, and internal tracking systems that teams already own.
•YAML storage in large repos could become a bottleneck; unclear scalability for teams with hundreds of reports.

Post Description

I got tired of TODOs, temporary hacks, and refactors that never get addressed. In most repos I work on:

- TODOs are scattered across files/apps/messages - “Critical” fixes don’t actually block people from collecting debt - PR comments or tickets aren’t enough actionable

So I built codereport, a CLI that stores structured follow-ups in the repo itself (.codereports/). Each report tracks:

- file + line range (src/foo.rs:42-88) - tag (todo, refactor, buggy, critical) - severity (you can configure it to be blocking in CI) - optional expiration date - owner (CODEOWNERS → git blame fallback)

You can list, resolve, or delete reports, generate a minimal HTML dashboard with heatmaps and KPIs, and run codereport check in CI to fail merges if anything blocking or expired is still open.

It’s repo-first, and doesn’t rely on any external services.

I’m curious:

Would a tool like this fit in your workflow? Is storing reports in YAML in the repo reasonable? Would CI enforcement feel useful or annoying?

CLI: https://crates.io/crates/codereport + codereport.pulko-app.com