Changelog — Features

What landed

• TAB-626 — Real-life fully isolated from CLI (the redesign). The original Path D plumbing reused the Code-mode CLI bridge with a realLifeMode flag. After two weeks of Phase 6 polish that boundary started leaking — Code-mode hooks bled into RL sessions, Code-mode response chrome appeared in RL Telegram cards. The redesign extracts a dedicated persistent-cli-bridge.ts for RL with its own session registry, prompt template (no Code-mode preamble), and streaming pipeline. Boundary B3 (UI chrome) and B4 (learned patterns) are now structurally enforced, not just convention.
• TAB-640 — Production smoke-test fixes. Three classes of bugs caught in the first wave of real-user RL testing:
  • Mid-spawn race — RL session got registered AFTER its first hook fired, so the bridge briefly treated it as a non-RL Code session. Fixed by registering at spawn intent, not at spawn confirm.
  • Response card frame — first RL response card's frame dropped because the placeholder bubble swallowed the formatting.
  • Placeholder UX — the "thinking..." card position was wrong (above the approval cards instead of below). Fixed alignment.
• TAB-641 — Stop-hook diagnostic instrumentation. Added trace-level logging across the entire stop-hook session-id flow. Caught two bugs that had been lurking since v2.3.130 (the cross-session contamination next bullet) and provided the data needed for TAB-642 + TAB-643.
• TAB-642 + TAB-643 — Cross-session contamination fix. The Code-mode interactive hook would fire mid-RL turn and pollute the RL Telegram chat with Code-mode auto-allow toasts. Fixed via TAB-642's blanket !isDelegate early-return, then refined by TAB-643's instrumentation and (later) TAB-645's RL-active gate.

Why these matter

Real-life mode is now production-ready as an isolated workflow. The Phase 6 architecture (TAB-629–TAB-633) couldn't fully eliminate Code-mode chrome leakage without TAB-626's deeper isolation. Combined with TAB-640–TAB-643's bug-fix sweep, the system is stable enough for early-access RL users.

What this unblocks

The follow-up wave (v2.3.139–v2.3.141) layers voice + UX polish on top of this isolation. Without TAB-626's clean separation, every UX polish would have had to manually re-validate Boundary B3 / B4 invariants — instead, those are now structural, so polish work focuses on the user-facing surface.

Tests

Two adversarial review rounds applied to the TAB-626 redesign. The Phase 8 review (TAB-635) re-validated the entire RL surface end-to-end after redesign. Production smoke-test fixes from TAB-640 each got dedicated regression coverage. Total tests added: ~85.

What landed

• TAB-629 — Stop-pass card suppression. Real-life sessions no longer surface the Code-mode [Reply][Wait Quietly][Stop] chrome. RL is request/response — the user is waiting for an answer, not orchestrating a long-running task — so the stop-pass card was visual noise. Bridge now returns empty 200 on RL stop classification.
• TAB-630 — Routing. Real-life messages route to a dedicated workflow path instead of going through the plan-module's branched code. Cleaner separation, fewer "is this RL or Code?" branches scattered through the orchestrator.
• TAB-631 — Dedicated message handler. New rl-module.ts owns RL message lifecycle: receive → spawn → render. Replaces the four if isRealLifeMode branches in plan-module.ts. Same Boundary B3 / B4 invariants enforced (RL chrome stays in RL, RL approval state stays out of the Code engine's learned patterns).
• TAB-632 — Slim card layouts. New approval-card templates designed for RL: minimal header, action verb + target, single line of metadata. Three variants — response, read approval, write approval. Mirrors the brevity Telegram users expect in conversation, not the full Code-mode chrome.
• TAB-633 — Read/write classifier + per-topic policy. Tool calls classified as read (low-stakes, often auto-approved) vs write (always asks). Approval policy is now scoped per Telegram topic — a heavily-trafficked Gmail topic builds its own learned-pattern set independent of a quieter Calendar topic. Boundary B4 enforced: RL learned patterns never leak into the Code-mode ApprovalEngine's pattern store.
• TAB-635 — Cross-phase safety review. Two adversarial review rounds applied across Phases 1–6, fixing 9 CRITICAL+HIGH findings around the RL-vs-Code session boundary.

What this fixes for users

Real-life mode goes from "works but every interaction has Code-mode UI chrome" to "feels like a clean Telegram chat with a smart assistant." Tap an approval card on Gmail and you see the recipient list and subject preview, not the file-path-and-line-number widget designed for Bash commands.

Tests

Comprehensive RL test coverage added across the new rl-module.ts, the slim-card renderers, the read/write classifier, and the per-topic policy store. Adversarial review × 2 round each on Phases 5–8. Total RL-side coverage now mirrors the Code-mode suite.

What changed (TAB-591)

• New HOOK_IF_FILTERS env var. JSON object mapping tool-event name → permission-rule string. Example: HOOK_IF_FILTERS={"PreToolUse":"Bash(git *)","PermissionDenied":"Edit(*.ts)"}. Empty / unset → no filters (bit-identical settings.json output to the pre-TAB-591 version).
• Tool events only. Filters are honored on PreToolUse, PermissionRequest, and PermissionDenied — the events the CLI evaluates if against. Filters targeting SessionStart, Notification, etc. are dropped at parse time with a startup warning.
• Defence-in-depth validation. Empty / whitespace / non-string values rejected. JSON keys are case-insensitive but case-collision (e.g. {"pretooluse":"A","PreToolUse":"B"}) surfaces a duplicate key warning instead of silent last-wins. Filter strings capped at 256 characters. Object.create(null) filter maps and hasOwnProperty bracket access prevent Object.prototype pollution from leaking into settings.json.
• Five-line startup observability: filteredEvents info-log lists active filters, plus four warn lines for parseError / unknownEvents / nonToolEvents / invalidEntries, plus a "set-but-no-filters-active" warn when HOOK_IF_FILTERS was non-empty but every entry dropped.

The CRITICAL bug caught pre-ship

Turn 1 adversarial review found that the initial implementation placed the if field at the matcher-entry level (sibling of matcher and hooks). The CLI silently accepts misplaced fields as unknown properties and never evaluates them — every filter would have been a runtime no-op while every positive observability signal (config accepted, filteredEvents log, if key visible in settings.json) lied about it being active. The CLI v2.1.85 docs place if INSIDE the inner hook object (sibling of type / command / timeout).

All 16 of the initial tests had passed because they encoded the wrong contract — the classic "tests pass ≠ feature works" trap. Fix landed before commit: moved if into the inner hook object, added negative tests asserting the entry does NOT have its own if key, rewrote the test-file invariants comment block (which had locked in the wrong layout in plain English alongside the assertions).

Turn 2 fresh-eyes review surfaced 1 MEDIUM (the stale comment block above) and 3 LOW findings (.env.example gap, silent-all-dropped blind spot, prototype pollution surface) — all fixed pre-ship. Final state: 0 CRITICAL / HIGH / MEDIUM open, 144 / 144 relevant tests pass, tsc --noEmit clean.

What changed (TAB-590)

• Transient vs persistent classifier. Reasons matching a curated regex set (network timeouts, rate-limit responses, file-locked errors) classify as transient → retry. Anything else classifies as persistent → no retry, model sees the denial and adapts.
• Never-retry gate for git writes. git commit, git push, git merge, and git rebase always prompt the user regardless of denial reason. Combined with the existing ALWAYS_PROMPT_COMMANDS and DANGEROUS_COMMANDS lists, this prevents the model from looping retries on operations that touch shared state.
• Two retry caps with TTL eviction. Per-tool-use cap (PERMISSION_DENIED_MAX_RETRIES, default 2 — meaning 3 total attempts) plus a session-level secondary cap (PERMISSION_DENIED_SESSION_CAP, default 10) that defends against the unverified scenario where the CLI assigns a fresh tool_use_id for every retry. Both maps are FIFO-evicted at 10 minutes.
• Kill switch. Set PERMISSION_DENIED_RETRY_ENABLED=false to disable the feature entirely while preserving observability (every decision still logs).
• Telegram throttling. A single denial rarely needs notifying; a flurry of identical denials means something is wrong. The retry-decision messages are throttled per (sessionId, reason-hash) so the user sees one summary instead of N duplicates.

Adversarial review

Two pre-ship rounds caught 2 HIGH (session-level cap, Telegram throttle), 5 MEDIUM, 3 LOW. All fixed before commit. 35 unit tests cover classification, never-retry gate, both caps, kill-switch behavior, wire-format correctness, malformed-JSON tolerance, and reason-string truncation at the size limit.

Installer Performance (TAB-587)

• Dot-source replaces subprocess cascade — Each install phase previously spawned 3-4 separate PowerShell processes via nsExec::ExecToStack, and every spawn incurred a 3-5s cold-start penalty on constrained machines. install.ps1 is now refactored to dot-source all lib scripts (detect-claude.ps1, place-hooks.ps1, register-hooks.ps1, set-codepulse-home.ps1) and call their exported Invoke-*Body functions directly within a single PowerShell process. All NSIS invocations also gained -NoProfile -NoLogo to shed profile-load overhead.
• Live progress streaming via ExecToLog — nsExec::ExecToStack (which suppressed all output until the process exited) is replaced with nsExec::ExecToLog, so NSIS now receives stdout lines as they are emitted and the progress bar no longer freezes for multi-second stretches.
• FirstRunWizard phase labels — FirstRunWizard.tsx gains rotating phase labels and an elapsed-seconds counter during the service-start wait so users can see what's happening instead of staring at a silent spinner.

QR Pairing UX Polish (TAB-584)

• Fixed 5s sleep replaced with a 250ms poll — receive_token used to sleep a flat 5 seconds before checking whether the Telegram bot had stored the user_id, making fast phones on reliable networks wait 4-9 unnecessary seconds at the critical first-impression moment. A 250ms poll (up to 25 iterations, 6.25s ceiling) now exits the instant user_id is confirmed — typical resolution is under 1 second.
• Telegram reply and structured diagnostics — A "Pairing confirmed — CodePulse is ready" message is dispatched from the same handler once the token is processed, so the "Starting..." button no longer looks frozen. Structured log lines with elapsed-ms were added to receive_token so diagnostics captures the full resolution timeline.

QR Pairing Mobile Compatibility (TAB-583)

• HTML meta-refresh replaces the 302 redirect — Mobile in-app WebViews (iOS Safari in-app, Android Chrome Custom Tabs, Telegram's own browser) silently swallow HTTP 302 redirects to non-HTTP schemes and third-party deep links. The receive_token endpoint now returns a 200 HTML page containing <meta http-equiv="refresh" content="0; url=t.me/BOT?start=SESSION"> plus a visible "Open Telegram" fallback link. Meta-refresh is universally honored, and a server-side page was preferred over JavaScript because some corporate MDM profiles block JS in WebViews.
• Immediate Telegram Welcome reply — The bot now fires a "Welcome — pairing successful" message the moment the token is validated, so users on mobile get in-Telegram confirmation without needing to switch to Telegram Desktop.

QR Pairing Production Hardening (TAB-510 — TAB-482 Phase 6)

• Windows Firewall rule provisioned by the installer — The NSIS installer now adds an inbound TCP allow rule named "CodePulse QR Pairing" scoped to $INSTDIR\codepulse-panel.exe, eliminating the undifferentiated first-run OS firewall dialog. The uninstaller removes the rule as Step 2 of 6 so the path reference is still resolvable at teardown time. A new check_firewall_rule Tauri command surfaces a gold-styled warning banner if the rule is missing, and fails open on unexpected netsh exit codes to avoid blocking pairing over a diagnostics misread.
• Multi-NIC ranking replaces first-interface selection — local_ip() gave way to a ranked enumeration via list_afinet_netifas() with is_usable_lan rejecting loopback, link-local, Docker bridges, and all IPv6, and lan_preference_rank ordering 192.168.x > 10.x > other private > Tailscale CGNAT > WSL2/Hyper-V. Tiebreakers use a u32-packed numeric IP value for reboot-stable ordering. A grey "Trouble connecting?" hint appears when more than one candidate is detected.
• StrictMode retry race fixed — unmountedRef is now reset to false inside the useEffect setup on each mount. Previously, React StrictMode's mount-unmount-remount cycle could leave the flag permanently true, silently killing every retry attempt in PairingCard.

QR Pairing — First Working Release (TAB-482 Epic)

• LAN HTTP server and QR generation (TAB-506) — An axum server binds to the machine's primary LAN IP (not 0.0.0.0) and serves a nonce-bound HTML form. The pairing URL is rendered as an SVG QR code via fast_qr. Bot-token submissions are validated against the nonce using a timing-safe compare, and a monotonic session_epoch re-verify eliminates the TOCTOU race between status check and state commit.
• Telegram polling and user_id capture (TAB-507) — After the phone POSTs the bot token, a background task long-polls getUpdates until the /start message is received and captures the sender's user_id automatically. The service is stopped before polling begins to avoid a 409 Conflict and is restarted on every exit path. Bot tokens are scrubbed from reqwest error messages before logging, closing TAB-470's support-log exfiltration vector.
• .env write, service restart, and token event (TAB-508) — finalize_pairing writes TELEGRAM_BOT_TOKEN, TELEGRAM_CHAT_ID, and TELEGRAM_ALLOWED_USERS to .env via an atomic tmp+fsync+rename sequence, merges rather than overwrites the allowed-users list to preserve co-admin setups, and restarts the service with the new credentials. Only a masked token ever crosses the IPC boundary.
• React PairingCard UI (TAB-509) — A 777-line component covers the four visual states (starting, waiting_for_token, waiting_for_user, complete) and is wired into both FirstRunWizard (first-time setup) and Configuration (re-pair), behind a <details> fallback so the existing manual form stays available. Gold brand styling throughout, shared Spinner/Checkmark primitives extracted to Icons.tsx.

QR Pairing Scaffold (TAB-505)

• Foundation for the QR pairing epic — Adds the fast_qr and axum dependencies, introduces the pairing.rs module, and registers three Tauri command stubs (start_pairing, receive_token, cancel_pairing) that return Err(...) placeholders. This is a preparatory release — the user-visible pair-in-30-seconds QR flow arrives in v2.3.106 once Phases 2-5 are wired in.