Work by Ali AlQattan

Inside Vox

Several coding agents share one microphone and speaker. If each client owns audio, reconnects and overlapping turns can interrupt a reply or leave recording work behind.

I built the personal macOS runtime, MCP adapter, audio lifecycle and controls. The public page describes the product; using it requires a local installation.

MCP clients → persistent local runtime → one FIFO operation gate → capture and playback → local Whisper and Kokoro services. The runtime owns cancellation and state; an agent host can reconnect independently.

Queue competing turns instead of rejecting them. A second call from the same agent is still a competitor. Waiting is bounded, and cancellation drains queued work so it cannot unexpectedly speak later.

6 September 2026, source e7dba3e: 35 lease and configuration tests passed. A separate run of the real OperationGate produced the transcript below. This exercise used timed tasks, with no microphone, speech model or cloud call.

The terminal exercise proves queue ordering. The separate speech sample demonstrates local synthesis and file transcription, not microphone capture, speaker playback or a complete MCP session. Speech inference stays on the Mac. Optional phone mode transports audio between the paired phone and Mac; it is not an assertion that audio can never leave the machine. Source remains private.

agent A: entered
agent A: released
agent B: entered
agent B: released
PASS: the second caller entered only after the first released.

Inside room

With agents in several tmux windows, a permission request or a finished run is easy to miss. I wanted that information on the pane label, window tab and status bar I already use.

I built the scanner, writer and agent hooks for my own terminal workflow. The source remains private; this page exposes the design and a bounded verification record.

Agent hooks and process observations → scanner rows → writer state → stored tmux options → pane labels, window tabs and the bar. A short finished state distinguishes a completed turn from ordinary idle time. Failed reads keep the last known state briefly.

Treat all agent-provided labels as untrusted input. tmux expands formats, so a title can become executable syntax. The writer strips control and expansion characters and escapes hashes before storing display fields; unknown tools cannot choose their own attention colour.

6 September 2026, source a51c969: tests/test-said.sh passed 83 assertions. The suite checks report identity, state transitions, hostile labels and rendered formats using fixtures and an isolated tmux server. The selected output below comes from that run.

This is a recorded test demonstration with synthetic agent reports, not a recording of live client work. State depends on what hooks and processes reveal; the chrome is a useful signal, not proof that an agent’s answer is correct.

ok   a hash in a title is doubled, so tmux prints it instead of running it
ok   a style in a title cannot paint a fake needs-you
ok   a dollar is dropped, so source-file cannot leak the environment

test-said: 83 passed, 0 failed

Inside Payments QA Framework

A successful browser message does not prove that a transfer changed the correct balances. I wanted one reproducible example that checks the interface, API and system of record together.

I built the test framework and its fictional Ledgerline application as a personal engineering example. It is separate from my employer’s payment systems and uses synthetic accounts.

Gherkin scenarios → step definitions → page objects, HTTP client and read-only SQLite reader → Ledgerline. The runner starts its own application and waits for health before tests begin. CI retains reports and failure screenshots.

Read the ledger without allowing the assertion layer to write it. Check conservation of the total balance as well as individual accounts. This catches a class of errors that a green toast alone cannot reveal.

The public repository contains the runnable application, tests, CI workflow and recorded browser demo. On 6 September 2026 the latest three GitHub Actions runs were successful. The architecture link explains local and remote test environments.

Ledgerline is a simulation, not a bank integration or evidence of production payment volume. Remote environments without the local database skip ledger steps, so their coverage differs from the local suite.