🤖 Auto-generated by Claude Fable 5 (claude-fable-5) via Claude Code — NOT human-reviewed. Verify before acting.
The audio-in spec migrates the listener's sleep/wake surface, but it names no wake-request topic: recognizer_loop:wake_up has no spec successor. A spec-only listener (one that binds nothing outside the spec namespace) can therefore never be woken programmatically — a skill or automation that put the listener to sleep has no sanctioned way to wake it again, short of the wake word itself.
Found during the naptime skill's migration gate, where the two migrated topics matched audio-in.md §6.3/§6.4 verbatim and cross-version wire compat held — the gap is in the spec surface, not the implementation. Proposal needed: either a canonical wake-request topic in the audio-in namespace (with the usual MIGRATION_MAP twin from recognizer_loop:wake_up), or an explicit statement that waking is wake-word-only and the legacy topic dies with its deprecation horizon. The former matches how every other sleep-adjacent topic was handled.
The audio-in spec migrates the listener's sleep/wake surface, but it names no wake-request topic:
recognizer_loop:wake_uphas no spec successor. A spec-only listener (one that binds nothing outside the spec namespace) can therefore never be woken programmatically — a skill or automation that put the listener to sleep has no sanctioned way to wake it again, short of the wake word itself.Found during the naptime skill's migration gate, where the two migrated topics matched audio-in.md §6.3/§6.4 verbatim and cross-version wire compat held — the gap is in the spec surface, not the implementation. Proposal needed: either a canonical wake-request topic in the audio-in namespace (with the usual MIGRATION_MAP twin from
recognizer_loop:wake_up), or an explicit statement that waking is wake-word-only and the legacy topic dies with its deprecation horizon. The former matches how every other sleep-adjacent topic was handled.