Tax Year Constant Drift

payroll/limits.js
  1: Tax/fiscal year pinned to a literal. This is the constant that must roll over on a date, and it is the one an assistant completes with the year it was trained on. Drive it from the transaction date or a configured year.
  2: Inflation-indexed statutory limit stored as a bare number with no effective year. The IRS and SSA re-publish these every autumn for the following year. Key it by year and record where the figure came from.
  3: A 1099 reporting threshold appears as a literal. The 1099-K threshold in particular has been changed and its enforcement postponed more than once. Pin it to a tax year with a citation, never to a bare number.
  4: Tax rate constant with no jurisdiction and no effective date beside it. Rates differ by country and by state and change on an announced day, so one global rate is wrong for somebody the day you ship it.
  5: A deadline written as one absolute date. Statutory filing deadlines shift when they land on a weekend or a public holiday and are re-set every year, so this has to be computed or keyed by year.
—— 5 ——

Five findings. Five lines of input, and every line is a finding:

const TAX_YEAR = 2025;
const SS_WAGE_BASE = 176100;
const FORM_1099K_THRESHOLD = 5000;
const VAT_RATE = 0.19;
const FILING_DEADLINE = "2025-04-15";

Nothing is wrong with that code. It parses, it lints, it passes review, and every test that touches it stays green. It is also wrong on a date that is not in the file.

Why it survives every tool you already run

A linter checks syntax, not the calendar, so a wage base from two years ago looks exactly like one published last month. A test pinned to a fixture passes forever, because the fixture went stale the same day the constant did.

And the thing that most often *wrote* the constant is the thing you would ask to check it. Assistants complete SS_WAGE_BASE = from training data that is by construction at least a year behind, then agree with themselves when you ask them to review it. Both halves of the loop share one blind spot, and it points at the past.

The rule, not the number

Keeping a table of correct values is the wrong shape, because the table goes stale too. Detect the *shape* instead - a value whose truth has an expiry date, stored as if it were eternal. Then you see it everywhere: the inflation-indexed limits the IRS republishes every autumn, the wage base the SSA reissues every October, per-diem rates that turn over on 1 October, minimum wages that step on 1 January or 1 July. None of them need you to know the right answer, only that an answer written in 2025 is a claim about 2025 and nothing else.

What twenty rules of that shape actually find

Twenty regular expressions. Over the 25-line sample in the free web page they produce 20 findings, each with a line number and a reason. Over 1,325 lines of ordinary application code that has nothing to do with tax, they produce 1. That ratio is the design goal: firing on everything is noise; firing on nothing only looks like rigour.

A subtlety worth stealing: \b treats _ as a word character, so \bwage_base\b does not match SS_WAGE_BASE - the exact casing these constants use. That mistake dropped a third of the real hits in the first version, and only a test asserting each rule fires on a line built for it caught it.

It never tells you the correct figure - only which lines stop being true, and the authority that republishes them.

Where the free line sits

The rules run in a browser page on a file you paste, and in a VS Code extension over the file you have open. That finishes one job completely. A licence is $29 once and buys scale, not answers: the same twenty rules over every file in the repository, re-run on every save, written out as a report CI can fail on. The checks are identical either way: a free tier that is a worse version of the paid one tells you nothing about the paid one.