spec: OVOS-FALLBACK-1 — poll semantics, pong correlation, registry liveness

CHANGELOG.md

@@ -537,6 +537,74 @@ version 2: its `{{ … }}` sequences become substitution points, and its
   OVOS-PIPELINE-1 §5.3, session registry → OVOS-SESSION-1 §2.2,
   `ovos.intent.unmatched` → PIPELINE-1 §9.3) and OVOS-SESSION-1 cited by
   its canonical title.
+- §6.1 — the poll is the decision point (no second round, unlike
+  OVOS-COMMON-QUERY-1), so the 0.5 s RECOMMENDED ceiling is stated as
+  calibrated for local evaluators and a model-backed stage MUST configure
+  a ceiling above its own evaluation latency. A fallback skill SHOULD
+  cache its ping-time evaluation keyed `(session_id, utterance)`, reuse it
+  at dispatch, and discard it when a new utterance arrives
+  (OVOS-COMMON-QUERY-1 §5.2). The stage collection ceiling is defined —
+  `pool_size × per-poll ceiling` sequentially, one window for the
+  broadcast form — and a deployment MUST set the stage's match-timeout
+  bound at or above it (OVOS-PIPELINE-1 §4.4, the OVOS-COMMON-QUERY-1
+  §2.1 pattern). Acknowledges that OVOS-STOP-1 §4.1 additionally caps its
+  ceiling at 1 s where this specification does not.
+- §6.1 — the pong gains a REQUIRED `utterance` echo (the first candidate)
+  and round correlation: a pong whose `utterance` or session does not
+  match the poll in flight MUST be discarded, one round-trip per
+  `(skill_id, utterance)`. Absence of the field is tolerated as a legacy
+  producer (SHOULD accept); a present, non-matching value never is.
+- §6.1 — the ping's reply derivation rationale corrected: the derivation
+  is `reply` because the queried skill always answers, so the query must
+  arrive response-ready — session propagation is common to every
+  derivation and does not discriminate. The pong likewise MUST be derived
+  through the reply derivation, so it reaches the plugin wherever the
+  skill runs. Dotted form cited to OVOS-MSG-1 §2.1.1.
+- §7 (new note) — a fallback dispatch is a fresh activation: `fallback`
+  is a reserved intent_name whose `session.active_handlers` push is NOT
+  suppressed, per the per-row rule in the OVOS-PIPELINE-1 §7.3 registry.
+  This is what makes a running fallback skill stoppable (OVOS-STOP-1) and
+  lets a conversational fallback take the next utterance
+  (OVOS-CONVERSE-1).
+- §5 step 1 — equal registered priorities MUST be ordered
+  deterministically; ascending `skill_id` is RECOMMENDED. Registration
+  arrival order is not an acceptable tie-break.
+- §5 step 2 / §8.2 — range bounds are inclusive; configured ranges SHOULD
+  partition the priority space with the last stage open above; a skill in
+  no range is never queried and SHOULD be logged at WARN. The range
+  filter applies after the preference order, so
+  `session.fallback_handlers` orders the pool but never admits a skill
+  into a stage.
+- §3.2 — deregistration is keyed by `context.session.session_id`, never
+  by `Message.data` (OVOS-INTENT-4 §11.3), and a deregistration whose
+  payload `skill_id` differs from `context.skill_id` MUST NOT be honoured.
+  Added to the §10 MUST list.
+- §3.5 (new) — registry liveness: a skill SHOULD deregister on orderly
+  shutdown; the plugin SHOULD honour `ovos.skill.deregister`
+  (OVOS-INTENT-4 §8.4) for the session in `context`; the plugin MAY evict
+  after N consecutive poll timeouts and MUST re-admit on re-registration.
+  Eviction is availability, not access control.
+- §3.3 / §8.1 — the default-response-skill rule moves to §8.1, its
+  normative home, and §3.3 becomes purely descriptive. The catch-all
+  guarantee comes from placement (last entry of
+  `session.fallback_handlers`, or the last stage's range), not from
+  registering at the number 100 — priority is an unbounded integer.
+  Added to the §10 deployment SHOULDs.
+- §3.4 — the "available to all sessions" claim now cites
+  OVOS-INTENT-4 §11.1 for keying and §11.2 for inheritance.
+- §8.1 / §8.2 — corrected: only the low-confidence catch-all fallback
+  stage SHOULD follow the persona stage; `fallback_high` and
+  `fallback_medium` MAY precede it, interleaved with intent-matching
+  stages by priority range, per §8.2. The §8.2 example pipeline is
+  restored to
+  `stop_high, converse, intent_high, fallback_high, intent_medium,
+  fallback_medium, common_query, persona, fallback_low`, aligned with
+  OVOS-PERSONA-1 §10's `common_query` → `persona` ordering, so the
+  confidence-tier interleaving from §8.2 is no longer lost to a
+  blanket persona-first placement.
+- §1, §4 — one session field (`fallback_handlers`); access control reuses
+  the OVOS-PIPELINE-1 denylists. Poll-wait wording unified across §6.1
+  and §10.
 ## OVOS-CONVERSE-1 — Active Handlers and Interactive Response
 
 ### 2