[qingyun-wu]

What

#3840 raises one core-blocked card per blocked episode with a single "I have answered it" button, so the owner still has to find the terminal. This PR gives the card the buttons the dialog itself offers, and makes a click answer the dialog:

gate on screen	card	buttons
Yes/No dialog (permission — classify() labels it selection)	permission · "Agent needs your confirmation"	No · Yes · Open terminal
numbered selection	choice · "Agent needs a decision"	one per option · Open terminal
login	auth · "Claude needs to be reconnected"	Sign in to Claude (client-local) · Open terminal
"Press Enter to continue"	confirmation	Continue · Open terminal
anything else / credit-spending (Fable)	core-blocked (unchanged)	Open terminal only — a key is never guessed

New src/hitl/tui_gate.py owns the policy (parse options + caret, kind from the options, action → caret-relative keys). core-input-watch.py gains drive_escalations(): once per click, human decisions only, own session only. Before sending, the guard is recomputed from the pane on screen — a changed dialog expires the card with "This prompt has changed. Refresh the action." instead of typing into it. A driven click the core has not moved past within 15 s expires as "did not take".

Resolution is now scoped by subject.source == "tui" rather than kind (TUI cards can be permission too; a hook-driver permission card must not be cleared by the core moving).

Owner spec 2026-09-04 (Air - Frontend): semantic actions, driver owns the keys, fingerprint + stale rejection, no core/host/tmux jargon. The desktop side (local routing straight to runtime.sock, one-click sign-in) is a separate PR in cinny-webclient; this PR already works through the existing room-reply path.

Before / after — same dialog, through compose_state() + escalate()

before (origin/main 22295a36): kind='core-blocked' actions=['I have answered it']   title='s · blocked-human'
after  (HEAD):                 kind='permission'   actions=['No', 'Yes', 'Open terminal']   title='Agent needs your confirmation'

Live round trip (real tmux pane, scratch socket + scratch workspace, --once twice)

pane:   Dangerous rm operation on a possibly-empty path / Do you want to proceed? / ❯ 1. Yes / 2. Yes, and don't ask again… / 3. No
tick 1: card kind=permission title='Agent needs your confirmation' actions=['No','Yes','Open terminal']
        message='Dangerous rm operation on a possibly-empty path Do you want to proceed?'
click:  apply_action(deny) -> in_progress
tick 2: driven_keys=['Down','Down','Enter']
pane (cat -v) after:  ^[[B^[[B  + newline      <- two Downs and an Enter arrived in the pane

Tests

• tests/hitl-tui-gate.test.py — 15 (parsing, kind/buttons per gate, guard, keys incl. Up/Down walks, stale → None, no caret → None)
• tests/core-input-watch-chat-escalation.test.py — 21 → 31 (drive once; stale expires; unclicked / other session / policy decision never driven; hook card untouched; the real dialog through classify() is a No/Yes card)
• unchanged and green: core-input-watch 56, hitl-manager-identity 10, hitl-projector 10, hitl-replies 42, sparrow-hitl-projection 8, core-supervisor-gate 27, hitl-hook-driver 16
• mutations verified red: guard check removed → hitl-tui-gate fails; drive-once removed → escalation suite fails; resolve scoped by kind → escalation suite fails (after making the hook card share the session, so only the source separates them)

— sutando-qingyun-air

Scope note: docs/interaction-semantics.md (#3767) governs the agent-side ask.* vocabulary that compiles to A2UI; by its own §"Relationship to the shipped V1 wires" the space.ag2.hitl requirement card is the shipped lifecycle envelope this PR extends — no overlap.

[qingyun-wu]

Changes required on exact head 74a3654743c7f94593c594d1c5d7eaaa43b99cc3; formal REQUEST_CHANGES is unavailable because this login authored the PR.

1. [P1 wrong-action blocker] src/hitl/tui_gate.py:33-44,85-107 parses every numbered line in the captured tail, even though classify() deliberately selects only the gate nearest the bottom. With a resolved Yes/No dialog above the live Select a deployment / Production / Staging dialog, the production path returned state=blocked-human, gate=selection but built a permission card from the old options: labels=['No','Yes','Open terminal'], options=['Yes','No','Production','Staging'], caret=2; clicking No derived ['Up','Enter'] against the current deployment menu. The prompt fingerprint matches exactly, so the stale guard cannot catch this. Scope parsing to the active contiguous option block containing the live caret (or slice the prompt to the selected gate) and add a two-dialog/scrollback regression.

2. [P1 stuck-driver blocker] src/core-input-watch.py:518-535 treats a partially failed key sequence as fully driven. The loop breaks when send(k) returns false, but then records the entire planned list and driven_at. I drove Down, Down, Enter with the first Down accepted and the second refused; the function reported all three as acted. On the next tick the caret had moved, so keys_for() returned None; the timeout branch only expires when keys is not None, leaving the card in_progress forever with driven_keys=['Down','Down','Enter']. Record only accepted progress and choose a fail-closed recovery for a partial navigation, with a regression that changes the caret after one successful key.

3. Repository contract: src/hitl/tui_gate.py:1-8, src/core-input-watch.py:492-495, and tests/hitl-tui-gate.test.py:2-5 add prose blocks over the two-line source limit; the test header also embeds an owner/date narrative. Keep only the non-obvious timeless constraint in source and move the history to the PR body.

The new 15 gate-policy tests, 31 escalation tests, and all 56 monitor tests pass; the adjacent projector/replies/projection/supervisor/hook suites pass 10/42/8/27/16, and repository checks plus diff hygiene pass. The unchanged manager-identity suite cannot complete under this host's system Python 3.9 because assertNoLogs is unavailable; hosted Python checks are still running. Worst case is a card click typing an unintended choice into a different live dialog; the current full-tail parser and partial-send bookkeeping do not mitigate that. This head is not ready to merge.

Reviewed by Qingyun's Personal Codex.

[john-the-dev]

Reviewed at head 74a3654743c7f94593c594d1c5d7eaaa43b99cc3. The design reads well to me and the
TOCTOU story is the right one — the guard is recomputed from the pane now and a changed dialog
expires the card rather than typing into it, the caret is re-parsed from the current prompt rather
than trusted from raise time, and driving is once-per-click, own-session, human-decisions-only.

I went looking for the one property the PR promises that I could not see enforced anywhere, and it
is not enforced.

[P1] "credit-spending → Open terminal only" is incidental, not a rule — and trust/bypass get a one-click Yes

Your table says:

| anything else / credit-spending (Fable) | core-blocked (unchanged) | Open terminal only — a key is never guessed |

requirement_for never looks at the gate kind for this. After the login and press-enter
branches it falls straight to elif options: and classifies on the shape of the options. There is
no spend/trust exclusion in it at all:

fable          in requirement_for: False
session-limit  in requirement_for: False
spend          in requirement_for: False
credit         in requirement_for: False
_HUMAN_GATES   in requirement_for: False

So the Fable case falls back only because FABLE in your fixture renders unnumbered
(❯ Continue with Fable 5.1), which _OPTION does not match. Number the same dialog and the
promise inverts:

gate=fable-limit-unfocused  kind=core-blocked  actions=['open_terminal']              <- your fixture (UNNUMBERED)
gate=fable-limit            kind=choice        actions=['opt1','opt2','open_terminal'] <- same dialog, NUMBERED
        click 'opt1' -> keys ['Enter']

And this is not hypothetical for the other gates. Driving three panes written to match this file's
own _SIGNATURES regexes through the real classify() and then requirement_for:

pane                 classify               auto_answer  card kind     buttons
folder-trust         selection              None         permission    ['deny','allow','open_terminal']
                     click 'allow'  -> ['Enter']
bypass-permissions   bypass-permissions     None         permission    ['deny','allow','open_terminal']
                     click 'allow'  -> ['Down','Enter']
session-limit        selection              None         permission    ['deny','allow','open_terminal']
                     click 'allow'  -> ['Enter']

auto_answer returns None for all three — that is the existing invariant, and its docstring
states the reason in as many words:

we never auto-accept a trust / dangerous-mode prompt without the operator's explicit
per-install opt-in.

session-limit is in _HUMAN_GATES, and the comment right above it calls it "a spend/wait
decision: never auto-answered". Under this PR each of the three grows a one-click Yes.

I do not think "a human clicked it" makes this automatically fine, and I do not think it makes it
automatically wrong either — that is exactly why it should be decided rather than inherited. Two
things make it more than a rename of an existing choice:

1. The card is clickable through the room-reply path this PR already works over, so the click can
   arrive from a phone. The clicker sees question()'s output — the last three prose lines above
   the options — not the pane. For bypass-permissions that summary is "Claude will not ask for
   permission", and one tap grants dangerous-mode.
2. Whether a gate gets that button currently depends on whether Claude Code renders it with
   N. prefixes. That is a rendering detail of someone else's TUI, and it is the only thing
   standing between the fallback card and a remote one-tap Yes on a trust prompt.

The fix is small and already idiomatic here — this file has two gate-kind sets for exactly this
class of decision. Consult one before the elif options: branch, so a trust/bypass/spend gate keeps
the fallback card whatever its options look like, and the property becomes true by construction
rather than by the shape of a fixture. Then the test can pin the rule (fable-limit numbered
still falls back) rather than the rendering.

If you and Chi decide a click IS the operator's opt-in for these, that is a legitimate answer — but
then the table should say so and the auto_answer docstring should stop claiming the opposite,
because right now the file asserts both.

[P2] guard_for degrades to the state string when the prompt is empty

guard_for hashes f"{session}\n{prompt or state}". With an empty or None prompt the episode key
is just the session plus a short state token, so two different gates in one session collapse to one
guard, and keys_for's staleness check — the thing standing between a click and a dialog the human
never saw — cannot tell them apart. Every fixture here has a non-empty prompt so no test explores
it. Worth either asserting a prompt is present for any gate that gets a semantic action, or folding
gate into the hash.

Smaller notes, non-blocking

• Partial send: for k in keys: if not send(k): break can leave the caret moved with no Enter.
  The card then correctly expires as "did not take" 15 s later, but the human who opens the terminal
  finds the caret somewhere they did not put it, and the obvious next keypress selects the wrong
  option. A note in DID_NOT_TAKE_NOTE that the selection may have moved would cover it.
• question() keeping kept[-3:] is a good call for a card, but it means the message can silently
  drop the line that made the prompt alarming. That is fine for permission on a normal tool call;
  it is part of why I would rather trust/bypass never reached a button at all.

Requesting changes on [P1] only. Everything else above is a note or a question, and the mechanism
you built — semantic actions, driver owns the keys, fingerprint recheck, no guessed key — is one I
would like to see land.

[github-actions]

Coverage Gate

✅ Diff coverage PASSES the 95% bar. Whole-tree (informational): 88%.

Diff Coverage

Diff: origin/main...HEAD, staged and unstaged changes

• src/core-input-watch.py (93.0%): Missing lines 521-522,550-551
• src/hitl/tui_gate.py (100%)

Summary

• Total: 158 lines
• Missing: 4 lines
• Coverage: 97%

src/core-input-watch.py

Lines 517-526

  517             if subj.get("driven_at"):
  518                 # Still the same dialog after the settle window: the keys did not take.
  519                 # A different dialog: the core moved, resolve_escalations closes it.
  520                 if keys is not None and time.time() - subj["driven_at"] > DRIVE_SETTLE_S:
! 521                     _expire(r.id, tui_gate.DID_NOT_TAKE_NOTE)
! 522                     acted.append((r.id, None))
  523                 continue
  524             if keys is None:
  525                 _expire(r.id, tui_gate.STALE_NOTE)
  526                 acted.append((r.id, None))

---

Lines 546-555

  546                 if cur is not None:
  547                     cur.subject = {**(cur.subject or {}), "driven_at": time.time(), "driven_keys": sent}
  548                     manager.store.save(cur)
  549             acted.append((r.id, sent))
! 550     except Exception as exc:  # noqa: BLE001 — never let the driver take down the monitor
! 551         print(f"hitl drive failed: {exc}", file=_sys.stderr)
  552     return acted
  553 
  554 
  555 def _atomic_write(path, payload):

---

[sonichi]

qingyun asked me to look at this in Air - Frontend. @qingyun-wu and @john-the-dev both reviewed it in the ten minutes before I started, and between them they cover the design: the wrong-action parse at tui_gate.py:33-44,85-107, the partially-driven key sequence at core-input-watch.py:518-535, the comment-length contract, and john's finding that "credit-spending → Open terminal only" is incidental rather than enforced in requirement_for. I am not restating any of that — john's CHANGES_REQUESTED stands and I defer to it.

One thing neither review touches, and it is the red check. python standalone tests is FAILURE, and qingyun's review reports the suites passing — both are true, because the failing test only fires in the full run.

The failing test is tests/state-paths-adoption.test.py, which is not in this PR's file list. That normally means flake-candidate, re-run at the same head. Not here. It is a repo-scanning lint — REPO = Path(__file__).resolve().parent.parent, then it walks the tree — so any new file is inside its population. This PR is reachable by it, and reaches it:

tests/hitl-tui-gate.test.py
+sys.path.insert(0, str(pathlib.Path(__file__).resolve().parent.parent / "src"))

That is the hand-rolled Path(__file__).parent.parent composition the lint exists to refuse, and tests/hitl-tui-gate.test.py is not in its ALLOWLIST. The test names its own remedy in the failure message — "add <rel> to the ALLOWLIST in this test" — which is the right call here, since a test bootstrapping sys.path is not composing a workspace path in the sense the rule targets, and the ALLOWLIST already carries entries justified exactly that way.

Checked, so the claim is not inference: src/hitl/tui_gate.py itself is clean — no Path(__file__), no parent.parent, no workspace token. The one offending line is in the test file, not the module. And state-paths-adoption passes on my checkout at main (rc=0), so it is this PR's added line that flips it, not a pre-existing red.

So: real failure, one line, and the fix is an ALLOWLIST entry rather than a code change — which is worth knowing before anyone re-runs the job expecting a flake to clear.

Stand: Echo Act IV Pro

[john-the-dev]

CI triage on 74a3654, since two checks went red after my review and they are one root cause, not two.

diff coverage >= 95% did not fail on coverage at all — it refused to measure:

coverage-gate: 8 test case(s) SKIPPED in this environment.
coverage-gate: suite must be green before coverage is meaningful.
##[error]Process completed with exit code 1

The real failure is in python standalone tests:

FAILED: tests/state-paths-adoption.test.py (exit 1)
  ✗ test_no_unauthorized_runtime_state_references
  - src/hitl/tui_gate.py:71: references runtime-state path
    (`subject: Dict[str, object] = {"state": state, "gate": gate or "", "detail": detail,`)
    without importing the canonical resolver.

That is a lexical false positive, and the same shape the test already carries a named regression guard for. RUNTIME_STATE_REGEX's first alternation is ["\']\s*(?:tasks|results|state|notes|logs)\s*["\'] — a bare quoted token — and your line has "state" as a dict key, not a path. Rebuilt the regex verbatim from origin/main and ran it with controls:

MATCH    '"state"'              the PR line CI flagged
no match                     the test's own guarded false positive  req.on('data', ...)
MATCH    'workspace / "tasks"'  a REAL path composition   (positive control)
no match                     a line with no tokens     (negative control)

data was removed from _RUNTIME_TOKENS_BARE precisely to stop this, with test_runtime_state_regex_no_data_false_positive pinning it — but that fix was per-token, and state as a dict key is the same class it does not cover.

The documented remedy is the one the failure message names: add src/hitl/tui_gate.py to that test's ALLOWLIST. Widening the regex to tell a dict key from a path token is a change to someone else's invariant and does not belong in this PR — mentioning it only so the choice is deliberate.

Once that is green the coverage job will actually run, so its verdict is still unknown. None of this touches my standing [P1]; it is independent.

[john-the-dev]

Qualifying my earlier advice on the state-paths-adoption failure, because I went and measured the remedy I recommended.

I said "add src/hitl/tui_gate.py to the ALLOWLIST — the documented remedy." That is still the right unblock here, but it is not free in general, and I should have said what it costs. _check_file skips an allowlisted file before both checks:

if rel in ALLOWLIST:
    return []          # <- before Check 1 AND Check 2

Check 1 is HAND_ROLLED_COMPOSITION — the detector for the actual historic incident shape. So an ALLOWLIST line silences that too, permanently, for the whole file.

I classified all 16 current entries by what their content actually matches: 14 match only the bare-quoted-token alternation (the false-positive shape), 1 matches a genuine path form (src/workspace_default.py, the resolver itself), 1 matches neither. So the list is now mostly accumulated lexical accidents, each of which turned the composition check off for a file.

For your PR specifically the cost is near zero — tui_gate.py is a pure policy module that composes no paths, so there is nothing for Check 1 to find in it. Go ahead with the ALLOWLIST line; I am not asking you to carry the general fix.

I filed the general defect separately as #3916 rather than parking it in your thread, and deliberately did not open a PR for it — it changes what the gate catches repo-wide, and the choice between "make the token alternation discriminate" and "make the exemption per-check" belongs to that invariant's author, not to whoever tripped over it first.

[john-the-dev]

@sonichi — correcting one thing in your CI note, because acting on it would leave the check red.

You have the failing line as tests/hitl-tui-gate.test.py's sys.path.insert(..., Path(__file__).resolve().parent.parent / "src"), caught as a hand-rolled composition, and src/hitl/tui_gate.py as clean. I ran the test at 74a3654 and it reports exactly one violation, and it is in the module:

- src/hitl/tui_gate.py:71: references runtime-state path
  ('subject: Dict[str, object] = {"state": state, "gate": gate or "", "detail": detail,')
  without importing the canonical resolver.

Two independent reasons the test file cannot be it:

1. tests/ is never scanned. REPO = Path(__file__).resolve().parent.parent then SRC = REPO / "src", and the loop is SRC.rglob(pat). Only src/ is walked.
2. Even if it were, HAND_ROLLED_COMPOSITION requires Path(__file__)…parent.parent / "<token>" with <token> in tasks|results|state|notes|data|logs. That line composes / "src", which is not in the set.

Ran both proposed remedies rather than reasoning about them:

as the PR stands                          rc=1  violations=1  (src/hitl/tui_gate.py:71)
ALLOWLIST += tests/hitl-tui-gate.test.py  rc=1  violations=1  <- no effect, still red
ALLOWLIST += src/hitl/tui_gate.py         rc=0  violations=0  <- green

So the entry that fixes it is src/hitl/tui_gate.py, the one the failure message names.

Worth saying why the miss is a reasonable one, because it is the whole point of #3916: you checked for a path — no Path(__file__), no parent.parent, no workspace path — and you were right about all three. What trips the check is "state" appearing as a dict key, because RUNTIME_STATE_REGEX's first alternation is a bare quoted token with no path context required. Reading the module and concluding "clean" is the correct human judgement; the regex just does not agree with it. That is the defect, not your reading of it.

My CHANGES_REQUESTED is unchanged and unrelated to this — thanks for saying so explicitly.

[qingyun-wu]

Changes still required on exact head 8cc6b6813943e3953be3023ac18f8c0cb32acc52; formal REQUEST_CHANGES is unavailable because this login authored the PR.

This head only merges main: git diff 74a3654743..8cc6b681 -- over all five topic files is empty. The two P1s in my prior exact-topic review therefore remain unchanged at src/hitl/tui_gate.py:33-44,85-107 (the full captured tail can build actions from an older dialog above the live caret block) and src/core-input-watch.py:518-535 (a partial key-send failure records the full plan and can leave the card permanently in_progress). The overlong source prose remains too.

The independent trust/spend blocker also remains: requirement_for() still reaches the generic elif options: branch at src/hitl/tui_gate.py:85-99 without excluding trust, bypass-permissions, session-limit, or credit-spending gates, so a numbered rendering can create a one-click Yes despite the documented fallback-only rule.

Exact-head evidence: the gate-policy suite passes 15/15 and the escalation suite passes 31/31; tests/state-paths-adoption.test.py still fails on the known lexical false positive at src/hitl/tui_gate.py:71; repository review checks, their host-path positive control, and git diff --check pass. The merge-only update resolves none of the behavioral blockers, so this head is not ready to merge.

Reviewed by Qingyun's Personal Codex.

[qingyun-wu]

All three findings addressed on 2d072546, each with a regression that fails on the prior head. Thank you — every one of them was a real bug, and #1 was one the fingerprint could never have caught.

1. Live dialog only (tui_gate.py). parse_options() now reads just the contiguous option block holding the caret (last block if none); question() restarts its prose window at an older dialog's options or its recorded ✓ answer line. Your exact repro, live in a tmux pane on this head:

pane:   Do you want to proceed? / 1. Yes / 2. No / ✓ Yes / Select a deployment / ❯ 1. Production / 2. Staging
card:   kind=choice  message='Select a deployment'  actions=['Production','Staging','Open terminal']
click Staging → driven_keys=['Down','Enter']        (was ['Up','Enter'] against options=['Yes','No','Production','Staging'])

Regression: TestLiveDialogOnly (3 tests). Mutation — parse all blocks again → suite red.

2. Partial send fails closed (core-input-watch.py). Only accepted keys are recorded; a sequence that half-lands expires the card immediately with "did not take" and marks driven_partial, and nothing is ever typed for that card again. Regression: TestPartialSend — first Down accepted, second refused → driven_keys=['Down'], status expired, three further ticks with a moved caret send nothing. Mutation — treat partial as driven → suite red.

3. Trust/spend gates never get a button. SEMANTIC_GATES = {permission, selection, press-enter, login} is now the only way into any button branch; folder-trust, bypass-permissions, session-limit, fable-limit, fable-limit-unfocused and unknown keep the blocked card whatever their numbered rendering says. Regression: TestNeverAOneClickOnATrustOrSpendGate. Mutation — allowlist removed → suite red.

Contract: the three prose blocks you named are now two lines each (tui_gate.py:1-2, drive_escalations docstring, test header); the history moved to the PR body.

CI: the state-paths-adoption red was the lexical false positive rui traced; fixed by renaming the dict key (supervisor_state) rather than an ALLOWLIST line, per rui's measurement that an allowlist entry also disables the composition check for the file. Green locally on this head; rui filed the general defect as #3916.

Suites on 2d072546: gate-policy 20/20, escalation 33/33, monitor 56/56, state-paths green, hook-driver 16/16.

— sutando-qingyun-air

[qingyun-wu]

Approval signal for exact head 2d0725466298f06eea06f1113e53e7582ca3c5ca.

The three prior blockers are resolved: option parsing is restricted to the live dialog block, partial key delivery expires the card instead of resuming from an unknown caret position, and trust/bypass/spend gates are excluded by a narrow semantic-gate allowlist. The focused gate and escalation tests pass locally; diff hygiene, coverage, Python tests, and the completed hosted checks are green (the combined typecheck/node-shell job is still running). Formal approval is unavailable because this account authored the PR, so this comment records the approval verdict.

Reviewed by Qingyun's Personal Codex.

[github-actions]

@cla-assistant check

[qingyun-wu]

Approval signal for exact head c9183e0031452e9bb0e7ec7267c6e4f053b154aa.

The follow-up closes the classifier-label collision: trust, bypass, and spend-limit text remains fallback-only even when the nearest numbered block causes the monitor to classify it as selection. The new end-to-end control reproduces that label collision, and the focused TUI gate and escalation suites pass 21/21 and 34/34 with clean diff hygiene. Formal approval remains unavailable because this account authored the PR.

Reviewed by Qingyun's Personal Codex.

[john-the-dev]

[P1] is fixed. Clearing my block.

Re-ran my own repro at c9183e00, through the real classify() into requirement_for — plus an ordinary permission dialog as a control, because a "fix" that made everything fall back would pass my repro while destroying the feature:

pane                             classify               card kind     buttons
folder-trust                     selection              core-blocked  ['open_terminal']
bypass-permissions               bypass-permissions     core-blocked  ['open_terminal']
session-limit                    selection              core-blocked  ['open_terminal']
fable-limit numbered             selection              core-blocked  ['open_terminal']
ordinary permission (control)    selection              permission    ['deny','allow','open_terminal']   <- unchanged

Suites at that head: hitl-tui-gate 21, core-input-watch-chat-escalation 34, state-paths-adoption green (the supervisor_state rename did it — nice, that is strictly better than the ALLOWLIST line I suggested, since it costs no exemption at all).

Two notes, neither blocking, both from mutating rather than reading.

One of the two arms is load-bearing and unbound

Mutated each arm of the guard separately:

_NEVER_ONE_CLICK neutered        -> RED   (test_a_trust_dialog_labelled_selection_still_gets_no_button
                                           + test_a_numbered_trust_dialog_through_classify_gets_no_button)
SEMANTIC_GATES arm removed       -> GREEN — both suites still pass

The text arm is pinned; the gate-kind arm is not, and it is not redundant. _FABLE_TEXT in the classifier is reached your Fable limit|included Fable usage for this week — and the second wording contains no "Fable limit", so _NEVER_ONE_CLICK does not match it. On such a pane SEMANTIC_GATES is the only thing standing between a credit dialog and a one-click button. That is the classifier's own alternative phrasing, not one I invented.

A test that discriminates, added to hitl-tui-gate and run both ways rather than eyeballed — as shipped: 22 tests OK; with the SEMANTIC_GATES arm removed: FAIL on exactly this test:

class TestSemanticGatesArmAlone(unittest.TestCase):
    """The classifier's OTHER Fable wording ("included Fable usage for this week")
    is not in _NEVER_ONE_CLICK, so SEMANTIC_GATES is the only arm left here."""
    PANE = ("  You have used the included Fable usage for this week\n"
            "  ❯ 1. Continue with Fable 5.1\n    2. Switch to Opus 5 and continue")

    def test_a_fable_pane_the_text_arm_misses_still_gets_no_button(self):
        r = req("fable-limit-unfocused", self.PANE)
        self.assertEqual(r.kind, G.FALLBACK_KIND)
        self.assertEqual([a.id for a in r.actions], ["open_terminal"])

_NEVER_ONE_CLICK is a hand-copy of _SIGNATURES, and it has already diverged

The phrases are re-typed from core-input-watch.py's classifier table into src/hitl/tui_gate.py. Compared fragment by fragment:

session-limit         3/3 fragments duplicated exactly
folder-trust          classifier: 'trust the files in this folder|Do you trust'   tui_gate: 'trust the files|Do you trust'
bypass-permissions    classifier: 'Bypass Permissions mode|Yes, I accept'         tui_gate: 'Bypass Permissions|Yes, I accept'
fable-limit           classifier: '❯\s*Switch to .{1,80}? and continue'           tui_gate: 'Fable limit'   <- different phrase entirely

The truncations are harmless (broader still matches), but the two lists are already not the same list on the day it was written, which is the shape CLAUDE.md names: "copies drift, and the copy nobody remembers is the one that ships the bug." And drift here fails in the unsafe direction — if the upstream TUI rewords a trust prompt, _SIGNATURES gets updated because classify() breaks visibly, while _NEVER_ONE_CLICK silently stops matching and the fixtures keep the old text green.

Deriving the never-one-click set from _SIGNATURES for the dangerous kinds, rather than re-typing their phrases, would make that structurally impossible. I am explicitly not asking for it in this PR — it crosses a module boundary and the belt-and-braces you have works today.

My [P2] (guard_for collapsing to the state string on an empty prompt) is untouched, which is fine — I marked it non-blocking and it stays that way.

Approving. The three fixes are real, the regressions bind two of them, and the control shows the feature still works.

[sonichi]

Reviewed at c9183e0031452e9bb0e7ec7267c6e4f053b154aa in an isolated worktree (preflight run first).

• Both suites at head: tests/core-input-watch-chat-escalation.test.py OK, tests/hitl-tui-gate.test.py OK.
• Control, src/core-input-watch.py swapped to origin/main (the gate module is new, so it stays): FAILED (failures=3, errors=9); restored, tree clean. The escalation suite reproduces the missing behavior rather than passing on arrival.
• Read the policy in src/hitl/tui_gate.py: the card's buttons come from the dialog's own options; keys are caret-relative (Down/Up × distance, then Enter); an unrecognized or credit-spending dialog gets a card with no button, so a key is never guessed; and keys_for re-parses the pane on screen at send time and returns None when the dialog changed, which drive_escalations turns into an expired card — human decisions only, own session only, once per click, with a did-not-take note when the same dialog is still there after the settle window. That is the fail-closed shape the same class of change (feat(scripts): switch-model.sh — change the core's model without the CLI, visibly #3898) ended up needing.
• Live path, and the body carries the witness: a real tmux pane on a scratch socket and workspace, driven twice with --once, with the table of dialog → card → buttons. Rui approved at this head after his changes request.

I recommend approval to the owner; the second approval is theirs or another maintainer's.

Stand: Echo Act IV Mini