* bluebubbles: fall back unsupported reactions to love
iMessage tapback only supports love/like/dislike/laugh/emphasize/question.
Previously, `normalizeBlueBubblesReactionInput` threw when the input did
not map to one of those (e.g. a non-standard unicode emoji like 👀 used
to mean "seen, working on it"), which aborted the whole reaction request
and left the user with no feedback.
This splits the normalizer into a strict and lenient variant:
- `normalizeBlueBubblesReactionInputStrict` throws on unsupported input
and is used by validator-style callers (e.g. `resolveBlueBubblesAckReaction`
in monitor-processing.ts) that rely on the throw to detect misconfigured
ack reactions and skip them cleanly. This preserves the previous silent-skip
+ warn-once behavior for ack reactions configured with an unsupported
emoji.
- `normalizeBlueBubblesReactionInput` stays lenient and falls back to
`love` (or `-love` when removing) on unsupported input, so agent-driven
`sendBlueBubblesReaction` still produces a visible tapback instead of
failing the whole reaction request. Contract errors (empty input)
continue to bubble up.
`love` is chosen over `like` as the neutral default: `❤️` reads as a
general acknowledgment across chat norms, while `👍` carries an
agreement connotation that does not match the "seen, working on it"
semantic.
* CHANGELOG: note BlueBubbles reaction fallback
---------
Co-authored-by: Omar Shahine <10343873+omarshahine@users.noreply.github.com>
* test(agents): expect timing fields in killed-run outcome
Aligns the steer-restart killed-run test with the timing fields added to
subagent run outcomes in #68726. The production code now returns
startedAt/endedAt/elapsedMs alongside status and error on the error
outcome, but this test's toEqual still asserted only status+error, so it
has been failing on main since #68726 landed. Uses the same expect.any(Number)
matcher already in use a few lines below for the ended hook payload.
* test(gateway): register ops agent in sessions.create task-start test
The "sessions.create can start the first agent turn from an initial task"
test triggers the auto chat.send path by passing `task:`. After #65986
added a deleted-agent guard to chat.send, an unregistered `ops` agent
triggers the reject path and the auto-started run never happens, so
runStarted comes back false.
Register `ops` via testState.agentsConfig (matching the pattern already
used by other ops-agent tests in this file) so the guard lets chat.send
through and the first turn starts as expected.
---------
Co-authored-by: Omar Shahine <10343873+omarshahine@users.noreply.github.com>
* qa-lab: harden CI defaults and failure semantics for live lanes
* qa-lab: add unit tests for suite progress logging defaults
* qa-lab: cover malformed multipass summary edge cases
* qa-lab: share suite summary failure counting helper
* qa-lab: test allow-failures parse wiring and sanitize progress ids
* fix: note qa CI live-lane defaults in changelog (#69122) (thanks @joshavant)
Add a Matrix QA scenario that removes an observer from the running account group allowlist and verifies the existing gateway stops replying without relying on a channel restart.
The scenario disables generic config reload and defers restart during the probe so it specifically covers the Matrix handler per-message live allowlist read.
Add a qa-matrix contract scenario that sends a Matrix self MXID-prefixed
control command from an observer and expects no SUT reply. This captures the
regression fixed by the Matrix command precheck change.
* WhatsApp: harden auth persistence and backup recovery
* WhatsApp: model unstable auth state across runtime and setup
* WhatsApp: recover login and monitor startup from unstable auth
* Channels: surface auth stabilizing in status and health
* Gateway protocol: add channels.start surface
* Gateway: reconcile local channel runtime after CLI login
* Channels UI: reflect recovered login start state
* Changelog: note WhatsApp auth stabilization
* Gateway: fix lint in call test
