Repository navigation
0.9.3 — the architecture check stops flagging your build output
The architecture check looked at your dist/ folder. Bundled output is full of files importing each other — that is what bundling does — so the check found import loops that exist in nothing you wrote, and stopped the gate. Then it told you only that there was a loop, never which files. One project hit this five times and spent two weeks looking in the wrong place.
Nothing to do on upgrade, unless you keep hand-written source in a top-level build/, out/ or target/ — those directories are no longer checked for import loops.
What stopped being scanned
dist, coverage, .next, .nuxt, .output, .svelte-kit and .vite, anywhere in the tree — a monorepo package or a front end keeps its bundle one level down. And build, out and target at the top level only, since those three are ordinary source directory names often enough that skipping them deeper would hide your own code. Output under apps/*/out or packages/*/build is still scanned.
Checks that used to stop the gate now pass. To scan everything exactly as before, put a pattern that matches nothing in a .madgerc at your project root:
{ "excludeRegExp": ["$^"] }If you already set excludeRegExp — in a .madgerc, in package.json, or as a madge_excludeRegExp variable — this release changes nothing for you. madge replaces exclusions rather than merging them, so cladding only supplies its own when you have none. Your rules stay the only ones in force.
When a loop does stop you, you get the files
The whole message used to be:
The code has an import loop or crosses a layer boundary the design forbids
The file list existed the entire time. It went to one stream while the message was built from the other, and what survived was cut at 200 characters. It now prints under that sentence, four lines at a time, with the rest in clad check --json.
Given only the old sentence, every agent we handed it to "fixed" the gate by deleting its own build output.
The review packet shows when a requirement was rewritten
clad report now compares each acceptance criterion against its earlier version and marks it new, rewritten, removed or unchanged, along with the entry's status change.
This closes a blind spot. Reword a requirement to match the code you just wrote and the spec and the code agree — so every drift check passes, and nothing is reported. The packet is where that becomes visible.
Added
- Acceptance-criterion changes in
clad report, with each entry's status transition and any change in the requirement's EARS pattern. - Declared tests marked as changed, unchanged, or missing from disk. It grades nothing — whether a test really checks its criterion is not something a tool can decide.
- The packet names the commit it compared against: the merge base, which on a branch that forked a while ago is not the tag you passed it.
Fixed
- Criteria are compared on
actionandresponseas well as the statement. Leaving out the obligation itself hid 31 rewrites in cladding's own history. - A review range that forked earlier no longer charges the base branch's commits to it.
- The EARS rules ship with the package.
docs/is not published, so nothing you install said which trigger word each pattern needs. The table is in the generatedAGENTS.mdnow, with an example per pattern. - Spec entries have a documented language — English by default, following the entries already in your spec where you have them. Only
when,while,ifandwhereare fixed, and only as the first word of a condition. - The review packet described itself as having four sections while printing six.
Known limits
/etc/madgercand Windows path resolution were not exercised.
Full changelog: v0.9.2...v0.9.3