spec: converse.md — RECOMMENDED tuning defaults, identity-gated response mode, pure updated_session channel

[JarbasAl]

🤖 Auto-generated by Claude Fable 5 (claude-fable-5) via Claude Code — NOT human-reviewed. Verify before acting. Cross-spec citations were model-verified against dev source; behavior-change sections need owner judgment.

Consistency pass over converse.md (OVOS-CONVERSE-1), in two groups.

1. PR-original fixes

• Tuning values demoted from mandates to RECOMMENDED defaults with rationale: §2.1 list cap (10), §3.2 TTL (600 s, applied when unconfigured), §4.2 per-owner poll timeout (0.5 s).
• §4.1/§5.2 — response-mode delivery gated on the §2.2 identity invariant against the post-prune converse_handlers; a pruned or unrecognised holder is never delivered to.
• §4.4 — "done" removal on a null return no longer mutates the inbound session in place; the PIPELINE-1 §4.2 channel discipline holds without exception.
• §4.1 — parallel polling upgraded to SHOULD (the poll sits on the serial critical path).
• Match slot map named slots per PIPELINE-1 §4.1.
• §5.2 — dispatch payload reduced to the standard PIPELINE-1 §7.1 shape.
• §5.4 — global-stop interaction corrected: the stop plugin re-stamps itself via uniform §3.1 activation.
• §4.2 — the poll boolean's field name is protocol-specific (result here).
• OVOS-SESSION-1 cited by its canonical title; CHANGELOG entry now points at §5.4, not §7.

2. Audit additions

Behaviour-relevant (implementers must read):

• §4.2 — the ping MUST be derived via reply from the inbound utterance Message (MSG-1 §5.2). Previously unspecified; a plugin that emitted a bare Message would drop context.session and lose satellite routing.
• §4.2 — aggregate poll ceiling added alongside the per-owner timeout. A deployment MUST set any PIPELINE-1 §4.4 match-phase bound for this stage at or above it, otherwise the poll is killed mid-collection on every utterance.
• §4.2 — malformed/foreign/late pong rule: mismatched, unsolicited and late pongs are ignored; missing or non-boolean result ⇒ false; first valid pong per owner wins.
• §4.1 step 3 — selection restated as first claimer in recency order (head-first per §2.1) instead of "highest activated_at", with the equal-timestamp tie-break resolved toward the entry nearest the head (PIPELINE-1 §7.1), and an explicit sequential/parallel equivalence statement.
• §2.1/§3.2 — a present, non-expired response_mode holder is exempt from TTL pruning and cap eviction. Without this, the 10-entry default cap could strand a live response window.
• §4 — a deployment SHOULD load at most one converse plugin; multi-plugin behaviour is explicitly unspecified.
• §3.2 — two optional decay triggers: MAY prune after N consecutive poll timeouts (RECOMMENDED 3), and SHOULD remove an owner on ovos.skill.deregister (INTENT-4 §8.4).
• §4.4 — response_mode_held dropped (unreachable); timeout marked plugin-synthesised and never on the wire.

Editorial / consistency:

• §2.2/§4.1/§5.2 — an expired response_mode entry is modelled as inert: it changes no routing decision, and is cleared by the plugin on its next claiming match or by the orchestrator when it commits any updated_session. No plugin mutation exception is created.
• §4.4 — the "done" pending removal is re-derived from the next poll round rather than remembered, so §9.2's no-cross-utterance-state rule stays intact.
• §5.4 — the duplicate stop-clears-response_mode rule deleted; OVOS-STOP-1 §6.1 cited as its owner.
• §2.1 — identifier charset stated once (§2.2 and §4.2 now cite it); "removed by a stop" → targeted stop.
• Intro — OVOS-SESSION-2 default-session citation corrected §6 → §5. §1 scope now lists §6. A See also section added, matching the sibling specifications.

Dependency

The §4.1 tie-break cites PIPELINE-1 §7.1, where the equal-activated_at "nearest the head" rule is defined once for the whole family. That sentence lands in the PIPELINE-1 PR, which merges before this one.

[coderabbitai]

Warning

Review limit reached

@JarbasAl, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 36 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 48e718a2-dacf-4975-ad3f-c49ace9f2285

📥 Commits

Reviewing files that changed from the base of the PR and between 1d3622b and c27fcd3.

📒 Files selected for processing (2)

• CHANGELOG.md
• converse.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch spec/converse

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}