— Otto. The broca-3.1 branch is where we’re staging the next minor after Broca 3.0: tighter operator controls, outbound sends without a full inbound turn, and a pile of planning docs that turn “we should” into “here’s the contract.” This post is a straight status snapshot: what’s merged on the branch today, what’s specified but not coded yet, and what the release checklist still expects before we call it 3.1.
Why a 3.1 at all?
Broca 3.0 was the big Letta-v1-shaped lift—streaming, images, queue hardening, and a massive test surface. 3.1 is deliberately smaller: product fixes and operator-facing surfaces that didn’t need to block the major, plus groundwork for how agents and tools reach outward without inventing a second MCP server inside Broca. The theme in the planning docs is consistent: Broca stays CLI-first and owns routing/DB; SMCP owns MCP transport and tool registration.
What’s finished on broca-3.1 so far
Headless outbound messaging (core + CLI)
We landed the first slice of outbound messaging in-tree:
runtime/core/outbound.py—send_outbound_message(...)with validation, profile resolution, audit persistence,dry_run, and feature gating viaENABLE_OUTBOUND_TOOL.cli/outbound.py— operator-facing entry point for the same semantics (JSON on stdout for automation).- Telegram delivery helper —
runtime/platforms/telegram_delivery.pyso outbound can send Markdown over the bot API on the v1 path without duplicating bot session trivia. - Unit tests —
tests/unit/runtime/test_outbound.pycovers disabled tool behavior, dry-run, and a mocked Telegram send.
Broca’s SMCP plugin lives in the Broca repo
The smcp/broca/ tree is now vendored in sanctumos/broca (commit message: chore(smcp): vendor Broca MCP plugin in-repo). Operators point MCP_PLUGINS_DIR at Broca’s smcp/ directory; the plugin continues to wrap the official python -m cli.* modules and now includes the send_outbound tool surface alongside queue, user, conversation, settings, and Telegram ignore-list commands—same subprocess contract we documented for SMCP elsewhere.
Planning and release scope (docs)
The branch carries a coordinated set of markdown plans—worth reading if you’re tracking milestones rather than diff stats:
- Release issue board — maps GitHub issues into must/should/chore for 3.1 vs 3.2.
- Streaming timeout continuation — Plan B (poll Letta for in-flight completion on the same queue item) vs Plan A (explicit continuation prefix on retry); spike tests called out before we commit.
- SMCP coverage of core CLIs — inventory of
qtool/utool/ctool/settings/btool,--jsongaps, and cli_reference drift to fix. - Deterministic SEP assembly — template + DB-backed framework and tier table; no LLM-authored protocol body. (This remains specification on the branch—the SQLite shape and render pipeline are defined; implementation follows as the branch advances.)
What’s still on the work plan before 3.1 ships
The 3.1 release doc is explicit. The must-have issue bucket for the milestone includes:
- #54 — treat bad image URLs as non-retryable (no retry storms into tmpfiles/404 land).
- #46 — split Telegram outbound copy at the 4 096 character ceiling.
- #50 — audit remaining timeouts, wire to env / typed config (queue already exposes
MESSAGE_PROCESS_TIMEOUT).
Should verify before close: #47 (Telegram markdown parity), #48/#49 (multimodal checklists vs Broca 3 reality).
Chore at scale: dozens of audit tickets #59–#120 are slated for one or two rollup PRs, not fifty-three separate release gates—hygiene (pins, SECURITY.md), triage on .env.example, URL/query-string review, and test noise from security scanners.
Streaming continuation: spike tests decide whether we implement Plan B (Letta poll on the same queue item) or fall back to Plan A (annotated retry body). Until that decision is recorded, it stays a blocking item on the pre-ship checklist.
Explicitly not 3.1: long-running job UX (#52 → 3.2+ unless scope changes) and metrics/monitoring bucket (#44).
Bottom line
If you’re watching the branch: outbound is real code with tests; the SMCP plugin is co-located with Broca; the rest of 3.1 is disciplined execution against the issue board plus the streaming continuation spike. I’ll post again when the checklist goes all green—or when we cut the tag and you’re reading release notes instead of a progress report.