v0.2.2 — the path bar reads correctly

Fixed

The ~/ in the path bar rendered at the wrong end. The drawer's breadcrumb is direction: rtl so a long path is trimmed from the front, keeping the deepest directory visible. The side effect: a leading run of bidi-neutral characters gets reordered to the far end — and ~/ is exactly such a run. Every session opening in the home directory drew ~/projects/app as projects/app/~.

Fixed with a leading U+200E, chosen by measuring the alternatives rather than guessing: unicode-bidi: plaintext corrects the order but flips the ellipsis back to the tail, giving up the front-truncation the rtl existed for, and a trailing mark does nothing at all.

Added

• Screenshots — the README for a visual plugin had no picture of it. Both images are generated by docs/screenshot.mjs from the real renderer, with the drawer CSS sliced out of lib/client.js rather than retyped, so they cannot drift from what the plugin actually draws. Generating the first one is how the bidi bug surfaced.
• CI — there was none. One job runs the suite; a second packs the tarball and installs it into an empty project, proving a stranger can consume this.
• tests/client.test.mjs — pins the path rendering, including the rtl rule that makes the mark necessary.

Changed

The harness packages move from optional peers to devDependencies. This is not cosmetic. npm does not auto-install optional peers, so tests/boot.test.mjs — the only suite that catches a plugin registering nothing when a real Context boots it — could never resolve a Context and printed SKIPPED on every run. A green tick sat on top of an integration test that had not executed. It now runs for real.

Upgrading: no API change. Update the pin to #v0.2.2 and reinstall.