Bring the event-driven architecture branch up to date with main (98
commits) and reconcile the rewrite with features that landed after it
forked: eager inbox delivery (awslabs#251), the OpenCode poller, env-var
forwarding (awslabs#259), memory curation (awslabs#254/awslabs#262), CORS auto-derive (awslabs#261),
DNS host validation (awslabs#124), and the self-send guard (awslabs#24).

Highlights:
- Providers adopt the async initialize() + get_status(buffer) contract;
  copilot_cli/opencode_cli converted; kiro keeps colour-only ANSI
  stripping so carriage-return-redraw permission prompts aren't misread
  as idle.
- Event-driven InboxService.deliver_pending with the awslabs#251 eager gate and
  message-sender attribution; OpenCode poller retained as a status-driven
  method; the watchdog (PollingObserver/LogFileHandler) is removed.
- terminal_service.create_terminal is async (FIFO + StatusMonitor wiring);
  session_service.create_session, flow_service.execute_flow, the API
  endpoints, and `cao flow run` updated to await.
- memory_service curated path and the flow CLI fixed to the new contract.

Full unit suite green (1908 passed); black + isort clean.

Resolve four review comments on PR awslabs#273:

- InboxService.run() ran deliver_pending() synchronously inside the
  asyncio consumer loop, blocking it on DB + tmux I/O and starving the
  StatusMonitor/LogWriter consumers. Offload delivery via
  asyncio.to_thread, matching the threading discipline documented for
  the event bus and the existing OpenCode poller.
- Event-driven deliveries were started without a PluginRegistry, so they
  skipped PostSendMessageEvent hooks. Thread the registry through
  run() -> deliver_pending so status-driven deliveries get the same
  plugin attribution as the immediate and OpenCode-poller paths.
- FifoManager.stop_reader() early-returned when no in-memory reader was
  tracked, never unlinking the FIFO. Retention cleanup after a restart
  (empty _readers) would leak *.fifo files unbounded. Always best-effort
  unlink the FIFO; only log when a reader was actually stopped.
- Docs claimed StatusMonitor falls back to a generic shell-prompt pattern
  before init; _detect_status returns UNKNOWN until a provider registers.
  Correct the docs to match.

Adds regression tests for the registry threading, the to_thread offload,
and the stale-FIFO unlink.

Reconcile the event-driven inbox rewrite with awslabs#265 and awslabs#266, which just
landed on main and edit the same files:

- inbox_service.py: keep the event-driven InboxService, but apply awslabs#265's
  ordering — mark messages DELIVERED before send_input so output echoed
  back through the FIFO/StatusMonitor pipeline can't re-enter
  deliver_pending and double-deliver a still-PENDING message (awslabs#164). Add
  awslabs#266's reconcile_orphaned_messages as a method that routes stale
  PENDING receivers back through deliver_pending (awslabs#131).
- api/main.py: keep the event-bus consumers + OpenCode poller; add awslabs#266's
  inbox_reconciliation_daemon task (start + cancel). Drop awslabs#266's watchdog
  PollingObserver wiring — the event bus replaced it here.
- constants.py: keep both INBOX_POLLING_INTERVAL and awslabs#266's
  INBOX_RECONCILE_INTERVAL/GRACE; reword the comments off the watchdog.
- tests: adapt awslabs#265's ordering regression and awslabs#266's reconcile + lifespan
  tests to the event-driven class API (deliver_pending, status_monitor,
  the singleton's bound method); drop the watchdog LogFileHandler tests.

Full unit suite green: 1958 passed, 1 skipped.

The newest Kimi CLI (the "Kimi Code" rebuild) replaced the ✨/💫 emoji
prompt with a boxed input area ("── input ──"), an "agent (<model> ●)"
status bar, a "context: N%" usage footer, and a braille-spinner working
indicator ("⠧ Thinking… Ns · N tokens"). The legacy detector keyed on the
emoji prompt, so it never observed IDLE and every Kimi terminal timed out
at init — this was the failure flagged on awslabs#273 (now confirmed to be a
Kimi-side TUI redesign, not a regression from the event-driven refactor).

get_status now detects the new TUI (gated on the new status/footer markers
so legacy emoji builds are unchanged):
- READY = status bar / context footer present with no live spinner.
- PROCESSING vs READY is decided by POSITION (last braille spinner line vs
  last ready-chrome line), so stale spinner frames lingering in the 8KB
  rolling buffer don't pin a finished turn at PROCESSING.
- COMPLETED vs IDLE latches on a "•" bullet (a turn produced output); the
  welcome banner / update nag have none, so a fresh terminal reads IDLE and
  avoids a premature-completion race when the first task is sent.

Adds regression tests driven by real captured raw pipe-pane buffers
(idle / processing / completed) of the new TUI.

Also enables Claude <-> Kimi cross-provider e2e:
- examples/cross-provider/data_analyst_kimi_cli.md (provider: kimi_cli).
- TestCrossProviderClaudeToKimi / TestCrossProviderKimiToClaude.
- Fix the cross-provider test helper to resolve the worker's provider from
  its profile (the add-terminal endpoint treats an explicit provider param
  as authoritative, which silently suppressed the profile override).

Verified on real CLIs (kimi 1.47.0 + claude 2.1.x) against a cao-server
built from this branch:
- TestKimiCliHandoff (2) + TestKimiCliAssign (3): pass.
- Claude->Kimi and Kimi->Claude cross-provider assign: pass.
Full unit suite green (2202 passed); mypy / black / isort clean.

…on event-driven pipeline

Under tmux capture-pane, a TUI that redraws over its boot screen hides
"Initializing..." and the MCP-init line — Kiro's TUI -> --legacy-ui
fallback path also calls StatusMonitor.reset_buffer when retrying so
the rolling buffer stays clean. Yolo mode does NOT take that fallback
path: it forces --legacy-ui directly at launch, so its rolling FIFO
buffer keeps the boot bytes forever even after kiro has redrawn over
them and the actual interactive prompt is showing below.

Until now get_status returned PROCESSING unconditionally whenever
TUI_INITIALIZING_PATTERN matched anywhere in the buffer. Yolo
sessions therefore reported PROCESSING for the entire session and
wait_until_status({IDLE, COMPLETED}) timed out — kiro yolo e2e
went from passing to 0/11 under the new event-driven pipeline (awslabs#273).

Make Check 0 position-aware: only return PROCESSING from a matching
TUI_INITIALIZING_PATTERN when no real ``[agent] >`` idle prompt
appears AFTER the last init match. The new-TUI placeholder
("Ask a question or describe a task") is intentionally NOT counted
as a real idle prompt because the new TUI renders it during boot;
that pre-existing test
(test_tui_initializing_yields_processing_despite_idle_placeholder,
issue awslabs#211) still passes.

Update test_mcp_server_init_yields_processing — its old fixture
asserted boot-line + "[developer] !>" should yield PROCESSING, but
real captured Kiro logs show the [developer] prompt only renders
AFTER init completes, so the assumption was incorrect. Replace the
fixture with the actual placeholder text Kiro shows during boot,
and add test_mcp_server_init_with_post_init_prompt_yields_idle to
lock in the post-init redrawn-stale case (the yolo failure mode).

Verified end-to-end: kiro e2e (yolo, --legacy-ui) 0/11 -> 11/11.

… flap

PR awslabs#273's event-driven pipeline derives status from a rolling 8KB FIFO
buffer fed to per-provider get_status(). TUI redraws (status-bar
refreshes, cursor positioning, footer repaints) keep emitting bytes
for seconds AFTER the agent settles, eventually evicting the
idle/response markers from the 8KB window. Without latching, status
flaps rapidly between IDLE/COMPLETED and PROCESSING/UNKNOWN, and both
wait_until_status (server-side) and the e2e tests' HTTP polling miss
the brief ready windows — causing codex 60s init timeouts, gemini 240s
init timeouts, and completion-timeout failures.

StatusMonitor now refuses two downgrades once a ready status latches:
  - ready -> PROCESSING/UNKNOWN (typical buffer-eviction flap)
  - COMPLETED -> IDLE (codex's user-marker evicts before assistant's,
    so last_user is None and provider falls back to IDLE, silently
    overwriting COMPLETED)

notify_input_sent() arms a one-shot revert gate so the latch releases
when external input legitimately starts a new processing cycle:
  - terminal_service.send_input / send_special_key (runtime input)
  - each tested provider's initialize() before its launch keystrokes
    and bypass/trust prompt acknowledgements

codex get_status now also handles the "long response evicted the user
marker" case directly: when last_user is None, scan above the TUI
footer for an assistant bullet and return COMPLETED instead of IDLE
(was returning IDLE forever, which the COMPLETED->IDLE block above
would otherwise cement as an off-by-one defence).

gemini_cli now declares extraction_tail_lines = 5000 so its existing
extraction_retries (3 x 10s) actually fires. The escalating-fetch path
(200/500/1000/5000) ran each step once with no inter-step waits, so
Ink-TUI redraws still rendering at extraction time fell through to
[PARTIAL RESPONSE], leaving the TUI footer in the output and tripping
the "? for shortcuts not in output" assertion.

E2E results on PR awslabs#273 with these changes:
  codex      10/12 passing (1 pre-existing extraction issue, 1 xfail)
  claude     12/12
  gemini     12/12
  kiro       11/11

…e thread-safe

Two hardening fixes to the sticky ready-status latch (PR #1):

1. Arm semantics: notify_input_sent()'s one-shot arm was consumed by ANY
   new ready latch, including a ready→ready downgrade flap (COMPLETED→IDLE
   when a large paste evicts the response markers, WAITING_USER_ANSWER→IDLE
   after a permission keystroke). Consuming the arm there blocks the
   genuine PROCESSING that follows, so the terminal reads ready while the
   agent is busy — and InboxService delivers on IDLE/COMPLETED, so a queued
   message could be pasted mid-response. The arm is now consumed only by a
   PROCESSING transition or a genuine non-ready→ready (init-style) latch.

2. Thread safety: the latch decision is a read-modify-write sequence
   (read armed → decide transition → consume arm) executed on the asyncio
   consumer, while notify_input_sent()/get_status()/clear_terminal() run on
   FastAPI threadpool, inbox delivery workers, and the cleanup thread.
   Guard StatusMonitor state with a lock (provider regex analysis and
   bus.publish stay outside it). Also covers the pre-existing Copilot
   review comments about unsynchronized _buffers/_last_status access.

Adds a latching state-machine test suite (12 cases) pinning blocked
downgrades, arm consumption, flap survival, and event publication.

Real failure from the supervisor-handoff e2e: mid-turn, Claude shows an
interim completion summary from an earlier thinking phase, then keeps
working — '● Calling cao-mcp-server… (ctrl+o to expand)' with a live
'✢ Misting… (33s · ↑ 332 tokens)' spinner and a '⎿ Tip: …' hint line
between the spinner and the input box. Two gaps combined into a false
COMPLETED, which the StatusMonitor ready-latch then pinned until the next
input, so the e2e test extracted mid-flight output:

- _boxless_completion_tail treated ANY completion summary after the last
  separator as a finished turn. It now requires that no live spinner
  (glyph + gerund + ellipsis) renders after the summary — an interim
  summary followed by a fresh spinner keeps the turn PROCESSING.
- The new-TUI box-spinner check looked only at the single line directly
  above the input box; '⎿ Tip:' hint lines and blanks render between the
  live spinner and the box, hiding it. The check now walks up to 4 lines,
  skipping ⎿ continuation lines and blanks.

Regression tests reproduce both shapes (fail pre-fix) plus a guard that a
summary with no following spinner still reads COMPLETED.

The newest 'Kimi Code' TUI renders user messages as ✨-prefixed prompt
lines (no ╭─ input box), responses as • bullets, and a '── input ──' rule
plus status bar as footer. extract_last_message_from_script() preferred
the last ╰─ box-end as the response anchor — which in the new TUI matches
decorative boot banners (Kimi welcome box, FastMCP server banner) ABOVE
the conversation — and only stopped at a bare idle prompt, which the new
TUI never renders. Result: the 'response' was sliced from the boot screen
and ran to end-of-capture (raw spinner frames, status bar), failing the
supervisor-assign e2e.

- Anchor on the LATEST marker (box-end vs prompt-with-input) instead of
  box-first: the response always follows the last user input, whichever
  marker style rendered it.
- Stop the response at the new-TUI footer: the '── input ──' rule or the
  status-bar/context-footer line, in addition to the bare idle prompt.

Fixtures are ground truth from a live Kimi Code session.

- LogWriter: open log files with explicit encoding='utf-8',
  errors='replace' — a non-UTF-8 platform locale (POSIX/C) would raise
  UnicodeEncodeError on the first unencodable chunk and stop log
  persistence for that terminal.
- EventBus.set_loop: accept Optional[loop] (test fixtures already call
  set_loop(None)); publish() now guards against the loop being closed
  during shutdown instead of raising RuntimeError from a FIFO reader
  thread draining its last chunks.
- BaseProvider.get_status docstring: soften the strip_terminal_escapes
  'should' to MAY with an explicit note that kiro_cli intentionally
  preserves raw \r for permission-prompt detection and must not be
  'fixed' to comply.

The 'except Exception swallows CancelledError' comments are intentionally
NOT addressed: since Python 3.8, asyncio.CancelledError derives from
BaseException, so those loops do not swallow cancellation.

Kimi (v1.20+) launches via 'cd <temp_dir> && kimi --agent-file
<temp_dir>/agent.yaml', writing the system prompt — including the
injected skill catalog — to <temp_dir>/system.md. The catalog is no
longer in the CLI command string, and the full-screen Kimi Code TUI
clears the visible screen on startup, so asserting against raw tmux
scrollback always failed. Parse the temp dir from the launch command
(capture-pane -J so soft-wrapped lines can't split the path mid-token)
and assert against system.md on disk — same pattern as the existing
gemini GEMINI.md branch.

…de TUI

The newest TUI renders the live spinner BETWEEN the '── input ──' rule and
the status bar, and repaints the status bar with every frame — so the
spinner-vs-ready-chrome position compare read 'ready' mid-turn whenever a
full footer repaint was the freshest chunk (measured: one supervisor turn
flapped completed↔processing 29 times in a 57KB stream). The StatusMonitor
ready-latch then pinned the first false COMPLETED ~130ms after dispatch,
so supervisor flows extracted mid-flight output (supervisor-assign e2e).

Detection now uses signals validated by replaying captured live streams:

- Live-spinner lines: braille/moon glyphs (incl. tool-call lines like
  '⠹ Using handoff({…})'), EXCLUDING boot chrome ('⠧ MCP Servers: 0/1',
  '⠋ Loading configuration...') which legitimately shows braille while
  idle at the welcome screen.
- In flight when a live spinner is within the freshest 15 lines OR renders
  after the last '•' bullet (covers chunk boundaries where streamed
  thinking text temporarily pushed the spinner out of the tail).
- Dispatch grace: 5s after send_input() (mark_input_received now stamps
  the dispatch), bridging the paste→first-spinner-frame gap.
- Rendered-pane confirmation: a ready-looking chunk boundary mid-turn is
  byte-identical to one at real completion (stale spinner ~21 lines back,
  bullets 2-3 from the end in BOTH), so when the stream says ready
  post-dispatch, confirm against the rendered pane — tmux's compositor has
  resolved every in-place redraw, so a visible spinner is live, not stale.

Also raises the e2e SUPERVISOR_COMPLETION_TIMEOUT 300→600s: a kimi worker
alone takes ~3m20s on the report-template handoff; 300s only looked
sufficient while the false early COMPLETED was masking the real duration.

E2E (live agents): kimi supervisor handoff + assign_and_handoff now pass;
kimi handoff x2, send_message, skills unaffected and green.

…or/NotebookEdit

The allowed-tools e2e caught restricted agents escaping their restrictions
live: a reviewer (no Bash/Write) created the forbidden file anyway — first
'via a delegated subagent that ran the write through a shell command'
(Task), then on retry via 'the Monitor tool' (background shell scripts).

CAO computes --disallowedTools as (tool universe - allowed natives), and
claude_code's universe only contained Bash/Read/Edit/Write/Glob/Grep — so
the execution-capable tools outside it were never disallowed. Gate them by
privilege equivalence:

- execute_bash now maps Bash, BashOutput, KillShell, Task (subagents run
  with their own full toolset), and Monitor (runs arbitrary shell scripts).
  Anything these can do, Bash can too, so profiles allowed execute_bash
  lose nothing.
- fs_write now maps NotebookEdit alongside Edit/Write (.ipynb writes).

Known limitation: this is enumeration against an evolving toolset — each
new execution-capable Claude Code tool needs adding here. A deny-by-default
mechanism upstream would be the durable fix.

E2E (live, herdr backend): all 4 TestClaudeCodeAllowedTools pass, including
the two that previously demonstrated the escape.