Skip to content

clikae v0.21.0 — two tabs, two screens

Choose a tag to compare

View all tags
@cverorg cverorg released this 13 Aug 02:59
· 132 commits to main since this release
v0.21.0
3d9c2d2

Two tabs, two screens

Reported and reproduced the same day: open clikae claude work, then from the
board resume a different past session on that tank — and both tabs showed the
same thing.

The tmux session was named after the tank alone, so the second launch found one
already running and attached to it. The --resume <sid> went nowhere, because
nothing was started to receive it. Before the tmux layer existed, that command
would have started a second engine; this was a regression it introduced.

Measured before touching anything, with a stub engine on two ptys:

before   STARTED args=[]                       <- one engine
         ck-codex-repro: SCREEN args=[]        <- one screen, twice

after    STARTED args=[]
         STARTED args=[resume SESSION-TWO]     <- two engines
         ck-codex-repro:            SCREEN args=[]
         ck-codex-repro-3723925944: SCREEN args=[resume SESSION-TWO]

A session is now keyed on what was asked for. A bare clikae <engine> <tank>
means "take me to my tank" and keeps the stable name — walking away and coming
back has to land in the same place. Anything after -- means "run the engine
with THESE arguments", which a session started with different ones cannot
satisfy, so a short digest of that argv is appended.

Identical requests still collide on purpose: resuming the same session id twice
returns you to that conversation, which is the answer you wanted.

A second waiter, found by Linux

clikae wake promises one waiter per session. The guard matched the window name
exactly — and the waiter renames its own window to carry the countdown
(wake 13h38m). Seconds after it started, the guard stopped recognising it, so a
second limit would have attached a second waiter, and two of them would have
typed go into the same pane, minutes apart, into a conversation that had
already resumed.

CI on Linux won a race macOS had been losing quietly. The honest reading of that
red was not "this test is flaky on Linux" — it was "this test is watching the
right promise, and the promise is broken." The new test starts from the renamed
state instead of racing to it, so it fails on any machine.

The CLI surface is checked against the family's design system

signet is CVER's design system for
plain-text terminal output. clikae was the one tool never wired to it — its own
SPEC says so — so the board could drift and nothing would go red. CI runs its
linter on every push now.

The first honest run reported 25 violations across 12 files. An earlier run of
mine reported zero, and that was a broken invocation rather than a clean repo:
violations go to stderr and a pipeline ate them. Worth saying out loud, because a
lint that reports nothing looks exactly like a tidy codebase.

Twenty are fixed here, in two groups:

  • Thirteen printed a status glyph next to a badge that already said the same
    thing     — log_done " ✔ …" prints [ DONE ] and then a tick. One state, two
    vocabularies, which is what a closed badge set exists to stop. Two of them were
    added the day before by the same hand that ran the lint.
  • Seven were a marker inside help text, now words. One of those was first
    reworded wrongly — Never: in front of a sentence that is a caveat, not a
    prohibition — and a test asserting on that sentence caught it.

Five are kept, and named in the check rather than hidden. They are the
selection cursor ❯. signet's roles table decides a [x] / [ ] checkbox
("is this one chosen?") and has no cursor ("where are you?"), and by its own
first ruler those are different jobs — a row can be under the cursor without
being chosen. The linter flags it only because U+276F falls inside the emoji
block it scans; nobody decided the mark was wrong. Reported upstream, and not
changed unilaterally: the SPEC itself says "Change the look, never the keys."

The exception matches the cursor itself, not a file and line, so it cannot
silently widen — a second glyph riding along on the same line still fails. Proven
in three directions before being trusted: a new emoji anywhere goes red, a second
glyph on a cursor line goes red, a clean tree stays green.

The ref is pinned, never main. Following a neighbour's HEAD would hand them
the power to turn this repo's CI red. Bumping the pin is how clikae says which
version it conforms to, which makes drift news instead of a surprise. The wrapper
also runs the linter's own self-test before trusting a clean verdict — it arrives
over the network, so "did it stop checking" is a real question.

brew upgrade clikae · CHANGELOG

Assets 2
Loading