PIPELINE-1: required_slots backstop, reserve fallback/common_query, listen field

Consolidates the PIPELINE-1 companion edits previously bundled into the
union-slots (#56), FALLBACK-1 (#39), COMMON-QUERY-1 (#40) and AUDIO-1 (#38)
feature PRs into a single one-file change to ovos-pipeline-1.md.

- §6.1/§6.2 — orchestrator backstop for required_slots (INTENT-3 §5.3):
  the orchestrator treats a Match as declined if any required slot is
  absent. Second line of defense behind engine-side enforcement.
- §7.3 — reserve intent_names "fallback" (FALLBACK-1 §6.3) and
  "common_query" (COMMON-QUERY-1 §3). COMMON-QUERY-1 asserted the
  reservation but never registered the row; this closes that gap.
- §9.6 — add the OPTIONAL listen field to ovos.utterance.speak; the
  output-side behaviour is owned by AUDIO-1.

All additions are backwards-compatible. PIPELINE-1 is already V2 (its
namespaced topics replace the pre-spec names); these refinements do not
change the class, so the Version stays 2. Adds the missing PIPELINE-1
CHANGELOG section.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: JarbasAl

CHANGELOG.md

@@ -97,3 +97,25 @@ tool does not recognize the token and cannot expand the template.
   the rejecting topic. File paths never cross the bus — INTENT-2 locale
   files are a producer-side authoring convenience expanded inline by
   the skill loader before emission.
+
+## OVOS-PIPELINE-1 — Utterance Lifecycle and Pipeline
+
+### 2
+
+The spec is at compatibility class **V2**: its namespaced utterance-layer
+topics (`ovos.utterance.handle` entry, the §7 dispatch / §9 topic family)
+replace the pre-spec status-quo names, so a V0 component is not
+wire-compatible without migration. The following are backwards-compatible
+additions consumed by the in-flight pipeline-plugin specs, recorded here
+per the 1-file-1-PR rule:
+
+- §6.2 — orchestrator backstop for `required_slots` (INTENT-3 §5.3):
+  after a plugin returns a Match, the orchestrator MUST treat the match
+  as declined if any required slot is absent. Second line of defense;
+  the engine enforces `required_slots` primarily during `match()`.
+- §7.3 — reserve two further intent_names in the registry: `fallback`
+  (OVOS-FALLBACK-1 §6.3) and `common_query` (OVOS-COMMON-QUERY-1 §3).
+- §9.6 — add the OPTIONAL `listen` field to the `ovos.utterance.speak`
+  payload: when `true`, the output stage re-opens the user input channel
+  after delivery. The output-side behaviour is defined by the output-path
+  companion spec.

ovos-pipeline-1.md

@@ -593,6 +593,7 @@ ovos.utterance.handle                    ← entry (§9.1)
    │         continue   # any plugin-side updated_session is discarded
    │
    │     orchestrator-backstop denylist check (§5.3/§5.4)
+   │     orchestrator-backstop required_slots check (§6.2)
    │     if filtered:  continue
    │
    │     session = match.updated_session or session   # §4.1, §4.2
@@ -673,6 +674,24 @@ consecutive-exception threshold. A dropped plugin behaves as if
 absent; recovery is a deployment concern. The threshold and scope
 (per-session or process-wide) are deployer-configurable.
 
+**Orchestrator backstop for `required_slots`.** After a plugin
+returns a `Match`, the orchestrator **MUST** verify that the match's
+slot map contains every slot listed in the intent's `required_slots`
+(INTENT-3 §5.3). The orchestrator obtains this information from the
+same registration data the plugin consumed — in-process, this is
+available from the plugin's compiled state or from the orchestrator's
+own manifest (INTENT-4 §10). If any required slot is absent, the
+orchestrator **MUST** treat the match as if the plugin had declined
+and continue iteration to the next plugin. This check operates
+after the `blacklisted_skills` / `blacklisted_intents` backstop
+(§5.3, §5.4) and uses the same observable semantics: no bus event
+is emitted; it is observable only as a non-match.
+
+The primary obligation to enforce `required_slots` still lies with
+the engine during `match()`. The orchestrator backstop is a
+second line of defense against engine bugs or plugins that do not
+implement the rule.
+
 ### 6.3 Plugins do not see each other's matches
 
 A plugin receives the same utterance every other plugin in the
@@ -895,6 +914,8 @@ Reservations currently in force:
 | `converse` | OVOS-CONVERSE-1 §4 | a converse plugin's claim that `<skill_id>` (an active handler) wants this utterance — the orchestrator dispatches `<skill_id>:converse` and the owner's converse handler runs |
 | `response` | OVOS-CONVERSE-1 §5 | a converse plugin's signal that `<skill_id>` (the response-mode holder) is to receive the awaited utterance — the orchestrator dispatches `<skill_id>:response` and the owner's response handler runs |
 | `stop` | OVOS-STOP-1 §4 | a stop plugin's claim that `<skill_id>` (an active handler) should cease activity — the orchestrator dispatches `<skill_id>:stop` and the owner's stop handler runs |
+| `fallback` | OVOS-FALLBACK-1 §6.3 | a fallback plugin's claim that `<skill_id>` (a registered fallback handler) is willing to handle the utterance — the orchestrator dispatches `<skill_id>:fallback` and the handler runs |
+| `common_query` | OVOS-COMMON-QUERY-1 §3 | a common-query plugin's self-addressed match (`Match.skill_id` is the plugin's own `pipeline_id`) — the orchestrator dispatches `<pipeline_id>:common_query` and the plugin's bundled handler speaks the answer it selected during `match` |
 
 This specification fixes only the registry mechanism (reservation
 listing); the per-name semantics are owned by the reserving
@@ -1130,6 +1151,7 @@ audio-capable deployment.
 |-------|------|----------|---------|
 | `utterance` | string | yes | The natural-language response string. |
 | `lang` | string | no | BCP-47 tag of the response language. When absent, the output stage resolves language from the session per OVOS-SESSION-1 §3.2. |
+| `listen` | bool | no | When `true`, the handler expects a follow-up utterance after this response is delivered; the output stage re-opens the user input channel once delivery completes. Absent or `false` means no follow-up is expected. The output-side behaviour this triggers is defined by the output-path companion specification. |
 
 **Derivation and session propagation.** A handler **MUST** derive each
 `ovos.utterance.speak` emission from the dispatch Message (§7) it