What dogfooding changed in specdx

Sixteen of the 22 issues on the specdx tracker came from this site. Fifteen are closed, and eleven of those closed on the day I filed them. Dogfooding gave specdx declared artifacts, status-aware checks and honest exit codes. It also exposed the step my contract skipped: three fixes merged on August 23 have never shipped.

Six specdx releases that exist because this site tripped

specdx is my own tool, and this site runs it as a real project under a written contract: friction becomes a GitHub issue, never a workaround. The first log of that contract covered its first four days. Read as release notes, the changes it forced look like this:

The other six issues on the tracker came from work inside the specdx repo itself: a broken plugin hook manifest, a stale build cache, an MCP server that could not start from a published install. Without this site, specdx would have those fixes and none of the rows above.

Each fix came from a spec, not from a test

Every row in that table started with a spec I needed for this site, not with a bug hunt. The draft-status rule exists because I wrote the crawler-log drain spec before the drain, which is the order spec-first work is meant to run in. The exports rule exists because I re-ran that repro on 0.4.0-alpha.9 instead of trusting the release note, and found that a planned export on an existing file still failed with exit 1.

specdx’s own test suite could not have found these. Its tests are written in the syntax its parser expects, by the person who wrote the parser, and that person is me. A second project writes specs the way it needs them, and that is where the parser’s assumptions show. The Data Model fix, when it came, added 14 tests, and each one fails if its fix is reverted. So the suite before it did not exercise the shapes this site writes.

The Data Model fix merged and never shipped

On August 11 I found that a warning I had treated as noise was not. check printed “no fields recognised in its Data Model” for every technical-design spec here, because a field written as - key: string — description failed the parser’s shape test. The warning asked for - name: type, and these specs wrote exactly that, with an em dash description after it. Result: 8 of 8 specs, zero fields parsed, and type checking off since the first spec, while check reported 100% coverage from artifacts alone. I filed two issues that day, beside an earlier one about prose Data Models, and all three closed together when the fix merged on August 23, 13 and 14 days after filing.

That fix is on specdx’s main branch. It is not on npm. On August 11 I also made releasing a manual action instead of a side effect of merging, and 0.5.0, the release from that same day, is still the latest. 45 days on, this site pins 0.4.0-alpha.24, and today’s pnpm check-specs prints eight “no fields recognised” warnings above “100% implementation coverage”, earned from 110 artifact checks with no type assessed.

A closed issue is not a shipped fix

The contract had two clauses that worked: file the issue, then verify the fix against the original repro. While a merge produced a release, closing an issue meant a version I could install, and the first twelve closes each came with a version number I verified here. When releasing became manual, “closed” and “installable” split apart, and nothing in this repo noticed, because nothing here reads the tracker. The gate reads the pinned version, and the pinned version is green.

That is the same failure the first log was about: a signal that reads as healthy and is trusted unread. The first time it was a coverage number. This time it was a closed issue. By the measure that matters here, a fix counts when this site’s gate runs on a version that contains it. On that measure, 12 of the 16 issues are done, three are merged and waiting for a release, and one is open.

The open issue is about plain JavaScript

The sixteenth issue is 37 days old. On August 31 I wrote a spec for a cross-post exporter, and its implementation is plain .mjs with types written as JSDoc @typedef. check does not read those, so a spec whose code is plain Node cannot satisfy its own Data Model, and the result was types (0/10). That branch has not merged, so nothing on this site waits on the fix. It is still the one piece of friction from this site that has not changed the tool.