When Yesterday's Design Decision Kills Today's Work

Our dashboard said 366 of our 757 published posts had no plain-language retelling, so we asked an assistant to build a nightly job for the blog. The request came from a ticket (our word for a to-do item) dated September 14. The problem on it was real. Most of the posts are technical write-ups, and the retellings are for readers who don’t write code. A queue of pairing candidates existed, but nothing turned it into assignments for the writing assistant. The ticket asked for a job that would do that every night.

The assistant read the ticket, then read the code around it. A decision from September 30 had retired retellings altogether. The reasoning was that a retelling covers a story we already told, from the same evidence, so it doubles the post count without adding a story. Plain-language posts would come only from original ideas from then on. The publishing check now skips any plain-language draft that carries a link to a technical post it retells.

So the job we asked for would have run perfectly and produced waste. Each night it would have fed seeds into a pipeline that uses prepaid drafting, a cleanup pass, scoring and the daily review-door quota. Then the publishing step would have skipped every draft it produced.

We have been wrong in this corner before

On August 21 we quarantined 11 plain-language drafts because they contained fabricated details. The fix we reached for was a rule that every plain-language post had to point to a real technical post it retold. Until September 22 that rule also blocked honest plain-language stories that had solid evidence behind them but no technical twin. The module that enforced it still carries the correction in its own comments, with our ruling from that day: “Non technical should not require a paired technical post.” The real fix for the fabricated details had been the evidence discipline in the drafting step, where the writer has to show its sources.

Eight days after that reversal we went one step further and retired retellings entirely. That left the September 14 ticket sitting on the board, still asking us to feed the thing we had just shut off. It also left the dashboard counting 366 posts as missing a twin, when pairing was now optional. A normal state of the blog was being reported as a backlog.

What the assistant handed us

It did not build anything, did not comment on the ticket, and did not move it. It wrote us two options.

Option A: honour the retirement. Close the ticket as superseded and change the dashboard so unpaired technical posts stop counting as a gap.

Option B: reverse the retirement. It would build the job as specified, capped at 3, dry-run by default, and run it once with --write --cap 3. It also warned us that we would have to lift the retirement for those drafts, because otherwise nothing the job made could ever reach the site.

Six minutes after that report, a different assistant finished the dashboard change. The count now prints in a separate info block instead of under the stalls heading. The ticket itself was untouched, waiting on our choice between the options.

A spec written under yesterday’s rules

The hold cost one minute of the assistant’s time. Building the job would have cost a nightly run of seeds that could never be promoted.

The ticket and the decision that superseded it sat in the same repo, and nothing connected them until the assistant read the code instead of just the ticket. A ticket is a spec written under the rules of the day it was filed. When the rules change underneath it, the job it describes can pass every check except the one that matters, which is whether anything it makes can ship.

dxdev LESSON · paste into your AI coding agent
LESSON: Check Whether A Ticket's Premise Still Holds Against Current Decisions Before Building What It Asks For
SOURCE: dxdev.com/blog/yesterday-decision-kills-todays-work
WHAT HAPPENED: The assistant was asked to build a nightly job from a ticket filed September 14. Before writing anything, it read the code around the ticket and found that a September 30 decision had retired retellings, and the publishing check now skips plain-language drafts that link to a technical post they retell. The job would have run correctly each night while spending prepaid drafting, cleanup, scoring and review quota on drafts that could never ship. The assistant built nothing and left the ticket untouched. It wrote two options instead: close the ticket as superseded and fix the dashboard, or reverse the retirement and build the job with a cap and dry-run default. A separate assistant then changed the dashboard so the 366 unpaired posts no longer show as a backlog.
THE RULE: A ticket is a spec written under the rules of the day it was filed, so before building from it, check it against the decisions and enforcement code made since. If they conflict, stop and put the choice to the owner instead of building.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Before starting work on an old ticket, someone compares its premise against decisions and code changes made after its filing date.
      2. A job that feeds a pipeline is checked against the downstream step that accepts or rejects its output, to confirm that at least some of what it produces can ship.
      3. When a decision retires a feature, the open tickets and dashboard metrics that depend on that feature are found and updated or closed in the same pass.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.