Skip to content

v1.9.0 — .dz/ dual-read config resolution

Latest

Choose a tag to compare

@ivndev001 ivndev001 released this 05 Sep 13:49
· 2 commits to main since this release
b3dc019

Added

The per-repo config is read from .dz/ui-debugger/ui-debugger-mcp.json first, falling back to the root .ui-debugger-mcp.json. A repo that has consolidated its agent config under .dz/ now boots the tool instead of reporting no project config. The two-candidate order lives in one place, CONFIG_CANDIDATES in src/config/load.ts, reached through resolveConfigPath(cwd) by every read and write.

Resolution is fail-fast in both directions: .dz/ wins when both files exist, and a bad .dz/ copy raises ConfigError rather than silently falling through to the root file. A fresh init writes to .dz/ when the repo already has that directory, and to the root file otherwise.

This is the release the platform side of the .dz/ migration waits on (developerz-ai/developerz.ai#2964). Until now a consumer pinned to @latest got 1.8.0, which knows only the root path.

ActResult.navigated, plus a note on the step that caused it, fed by a new optional adapter method. A full-document load wipes in-page state and nothing on screen distinguishes that from a click that did nothing, so the driver used to read a reloaded page as an unchanged one.

Fixed

  • biome.json no longer carries "!**/tmp" in files.includes. That pattern matches the absolute path, so a checkout under /tmp/... or any workdir with a tmp component matched at the path root and biome pruned the entire tree before reaching the repo.

Changed

  • The post-submit proof-of-signin settle wait is now bounded by NAVIGATION_SETTLE_MS (5 s) instead of taking the whole login budget.

    Known issue. The changelog entry for this attributes the repo's red CI to that wait. That attribution is wrong and is corrected in #70: the same test hangs identically with the cap in place, a DEBUG=pw:api trace shows the wait resolving 8 ms after the click, and an isolation run reproduced the hang on the pre-change tree. The cap also has a cost in the other direction, since capWait only shortens and no config knob raises it: a login whose navigation commits between 5 s and 30 s is now reported as "the login did not take. Check the credentials and the field keys" for credentials that are correct. Tracked as a follow-up; use an expect on the persona to keep the full budget in the meantime.