# What dogfooding changed in specdx

Sixteen of the 22 issues on the specdx tracker came from running it on this site, and they shaped the tool: declared artifacts, status-aware drift checks, an exit code for coverage it cannot assess. Fifteen are closed, eleven on the day they were filed. The record also shows where the loop broke: three Data Model fixes merged on August 23 have never been released, so this site's gate still skips type checks.

Published: 2026-10-07
Canonical: https://umar.codes/what-dogfooding-changed-in-specdx

## Revisions

- 2026-10-07 — Created from the specdx issue tracker, the npm release dates, and this repo's DECISIONS.md, read that day; check output from specdx 0.4.0-alpha.24 as pinned here.
- 2026-10-07 — Published two days before its Oct 9 slot, as a second post that day by owner decision; auto-drafted by the publishing run because no draft existed for the row.

---

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](/sdx) 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](/dogfooding-specdx) covered its first four days.
Read as release notes, the changes it forced look like this:

| Version | Released | What changed | What tripped here |
|---|---|---|---|
| 0.4.0-alpha.3 | Jul 27 | The config schema accepts all nine spec types, not six | `project-context`, a documented type, failed `validate` |
| 0.4.0-alpha.6 | Jul 29 | `check` says "coverage not assessed" and exits 3 | It reported 100% coverage on a site it could not read |
| 0.4.0-alpha.7 | Jul 29 | `pack` marks the sections it trims | A spec cut from 849 tokens to 342 arrived with no marker |
| 0.4.0-alpha.8 | Jul 30 | Specs can declare `artifacts`: file paths and named exports | The drift checker supported three frameworks; Astro was not one |
| 0.4.0-alpha.9 | Aug 3 | A planned file in a draft spec is pending, not an error | Declaring a cron job's planned file broke the gate |
| 0.4.0-alpha.11 | Aug 4 | The same rule for planned exports | The fix above covered files and missed exports |

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](/spec-driven-development) 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.