Metadata-Version: 2.4
Name: rework-rate
Version: 0.1.1
Summary: Measure how much of your git history is rework. No config, no signup, no network.
Author-email: Tetsuroh Hori <43089161+Tetsurohhori@users.noreply.github.com>
License-Expression: MIT
Project-URL: Homepage, https://github.com/Tetsurohhori/rework-rate
Project-URL: Repository, https://github.com/Tetsurohhori/rework-rate
Keywords: git,rework,churn,cli
Classifier: Development Status :: 3 - Alpha
Classifier: Environment :: Console
Classifier: Intended Audience :: Developers
Classifier: Operating System :: OS Independent
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Classifier: Programming Language :: Python :: 3.13
Classifier: Typing :: Typed
Requires-Python: >=3.10
Description-Content-Type: text/markdown
License-File: LICENSE
Dynamic: license-file

# rework-rate

Measure how much of **your** git history is rework. One command. No config. No signup.

```
rework-rate
rework-rate 34
rework-rate 34 --minutes 20 --hourly 5000
```

`--minutes` and `--hourly` have **no defaults**. Both must be given, or neither. The printed yen line repeats those inputs. They are yours, not a measurement.

## Definition (public, breakable)

A commit counts as **rework** when:

1. its subject starts with `fix` or `revert` (case-insensitive), **and**
2. it touches a file that **this same history** already touched less than **24 hours** earlier.

```
rework = a fix touching a file you changed less than 24h earlier
```

That is the whole definition. If you disagree with it, you can show a counterexample on a real repository and we will treat that as a successful break. **This definition is not the only valid one. A claim that it is "the right" definition is not part of the tool.**

## Limits of this definition

- Fixes that are **not** labeled `fix` / `revert` are not counted.
- Operators who **commit corrections** (instead of amending silently, squashing, or force-pushing) will score **higher**. The number rewards leaving a trail, not "worse work."
- **24 hours is an arbitrary threshold.** It is not a natural unit of software. A 25-hour fix of the same file is invisible to this tool. A 23-hour rename that happens to start with `fix` is visible.
- Merge commits, empty commits, and files whose names contain whitespace follow the same `git show --name-only` split the prototype used. That is a limitation, not a feature.

If you have a definition that is stricter, looser, or labeled differently, write it down and run it. A definition that cannot be broken is not a definition.

## When this tool cannot measure

If the window contains **no** commit whose subject starts with `fix` or `revert`, the tool prints `not measurable here` and exits 0. It does **not** print 0%. A repository that never labels fixes is outside the definition, not a healthy score.

If at least one such subject exists, the rate and the weekly table are printed. The published reference line is printed only when there are **5 or more** `fix`/`revert` subjects. Fewer than that is too thin to sit next to another person's number.

## Published reference (one operator, one repo)

```
window     2026-07-21 … 2026-08-30 (34 days)
commits    817
overall    181 / 816 = 22.2%
Cursor     170 / 593 = 28.7%
reference  28.7%  (n=1 repository, 1 operator, 6 complete weeks)
reference r = +0.87  (n=6 complete weeks)
```

**The n of the rate is not 817 commits.** It is one repository and one operator. The n of r = +0.87 is six complete ISO weeks. This is a published run, not a benchmark. The tool prints `yours` next to `reference` and does not say which is better.

## Relation to change failure rate

This number is a **pre-merge cousin of change failure rate** (CFR), the DORA / Accelerate term for the share of production deployments that fail.

| | CFR | this tool |
|--|-----|-----------|
| Place | production | commit history |
| Event | a deploy that failed in production | a `fix`/`revert` that retouches a file seen in the last 24 hours |

They are not the same quantity. This tool is not part of the DORA research program, and it is not an AI-era stand-in for those four measures. The vocabulary is borrowed. The authority is not.

Weekly correlation is Pearson's r of weekly commit count vs weekly rework rate. It is printed only when **at least 3 complete ISO weeks** remain after dropping incomplete weeks at **both ends** of the window. Two weeks can always produce r = ±1.00. We do not print that number.

An ISO week is **incomplete** when:

- it has not finished yet (the following Monday 00:00 UTC is still after the window end), **or**
- the window opens two or more UTC days after that week's Monday.

The first case is why a Monday run and a Sunday run used to disagree: one in-progress week (2 commits, 0% rework) moved r by 0.22. That week is still listed in the table, marked `(partial)`, and is **not** fed into r. The second case is why `N days ago` landing on a Tuesday does not, by itself, drop the first week. A two-day-or-more cut does.

**Display:** every ISO week that has commits in the window appears in the weekly table. Incomplete weeks are marked `(partial)`. Exclusion applies to the correlation only.

## What this tool does not do

- It does not send telemetry, usage data, crash reports, or version-check requests.
- It does not import `urllib`, `requests`, `http`, or `socket`.
- It does not write to your repository. The only git verbs it runs are `log`, `show`, and `rev-parse`.
- It does not create temporary files.
- It does not fetch, checkout, or change branches.

If it is not a git repository, or the window has no commits, it exits with a clear error.

## Install

```
pip install rework-rate
```

## Changelog

- 0.1.1 — README の導入手順を PyPI 名に修正（機能変更なし）

## License

MIT.
