Raised while testing v0.14.0: "I don't see the switcher between live and paper modes in the UI."
The switcher is absent on purpose, and that part is not a bug
render.js's session-chip docstring states it:
Display and navigation only. It never mutates. Switching profile or mode is a config-file edit plus a typed terminal ceremony with a runbook; there is no control here, no route behind one, and no capability added.
and, on why:
What their version attaches — an "Open Live Account" button on the paper banner — is a growth funnel wrapped around real money, and is refused here.
That holds, and #707 settled the general form of it: keel serve holds no venue credential, and state-changing actions live in the terminal. A control that flipped a deployment from paper to live from a browser would be the single most consequential write on the surface. Nothing in this issue asks for that control.
Worth noting that #704's title says "switcher chip" while what shipped is a display chip — which is very likely where the expectation came from. That is a stale title on a closed issue, not a missing feature.
The real gap: "which deployment am I looking at" is hover-only
modeBadge (keel/web/static/js/render.js:3030) puts the mode word in the badge and the identifying pair in a title attribute:
node.title = (config.db_path || "").concat(" · config ", config.config_path || "");with the comment:
The "where am I" half: one process serves one --db/--config pair, and naming both makes paper-vs-live confusion answerable at a glance instead of by asking the terminal.
title renders as a hover tooltip. There is no hover on a touch device. So on phones and tablets the "where am I" half is not merely inconvenient — it is unreachable, and the stated goal of answering paper-vs-live "at a glance instead of by asking the terminal" fails exactly where the terminal is least available.
This matters now rather than later because Phase B (#648, #656) is the mobile wedge: the whole point is an operator approving from a phone. An operator who cannot tell which database they are looking at is the wrong person to be approving anything, and on the target device today they cannot.
The mode word is visible on all devices. It is the --db/--config pair — the half that distinguishes two paper deployments, or paper-vs-live when both read confirm — that is hover-gated.
Also worth checking while in here
The badge is empty when the config cannot be read (if (!mode) clears it and drops the title). That refusal is right — an absent answer is not paper — but an empty pill is silent about why. Whether that reads as "no deployment" or as a rendering bug is worth deciding deliberately.
Suggested shape
- Surface the
db_path/config_path pair without hover: a tap-to-reveal on the chip, or on the session/status view where it does not cost header space.
- Keep it display-only. No route, no control, no capability row — the disjointness pin stays green.
- Do not replace the
title; keyboard and desktop users have it and it works there.
Acceptance
Raised while testing
v0.14.0: "I don't see the switcher between live and paper modes in the UI."The switcher is absent on purpose, and that part is not a bug
render.js's session-chip docstring states it:and, on why:
That holds, and #707 settled the general form of it:
keel serveholds no venue credential, and state-changing actions live in the terminal. A control that flipped a deployment from paper to live from a browser would be the single most consequential write on the surface. Nothing in this issue asks for that control.Worth noting that #704's title says "switcher chip" while what shipped is a display chip — which is very likely where the expectation came from. That is a stale title on a closed issue, not a missing feature.
The real gap: "which deployment am I looking at" is hover-only
modeBadge(keel/web/static/js/render.js:3030) puts the mode word in the badge and the identifying pair in atitleattribute:with the comment:
titlerenders as a hover tooltip. There is no hover on a touch device. So on phones and tablets the "where am I" half is not merely inconvenient — it is unreachable, and the stated goal of answering paper-vs-live "at a glance instead of by asking the terminal" fails exactly where the terminal is least available.This matters now rather than later because Phase B (#648, #656) is the mobile wedge: the whole point is an operator approving from a phone. An operator who cannot tell which database they are looking at is the wrong person to be approving anything, and on the target device today they cannot.
The mode word is visible on all devices. It is the
--db/--configpair — the half that distinguishes two paper deployments, or paper-vs-live when both readconfirm— that is hover-gated.Also worth checking while in here
The badge is empty when the config cannot be read (
if (!mode)clears it and drops thetitle). That refusal is right — an absent answer is notpaper— but an empty pill is silent about why. Whether that reads as "no deployment" or as a rendering bug is worth deciding deliberately.Suggested shape
db_path/config_pathpair without hover: a tap-to-reveal on the chip, or on the session/status view where it does not cost header space.title; keyboard and desktop users have it and it works there.Acceptance
--dband which--configthe running server is serving, without a terminalmodeBadgestill refuses to name a mode it cannot read