CCCC v0.4.33 Release Notes

v0.4.33 makes collaboration easier to see, easier to provision, and easier to run on current Python environments.

Mermaid diagrams can now become interactive message content instead of remaining raw code, integrators gain a supported contract for controlling how a Working Group starts, and CCCC moves its Python baseline forward to cover Python 3.11 through 3.14.

Diagrams Become Part of the Conversation

Fenced mermaid blocks in completed Chat and Inbox messages now render automatically as diagrams. This makes architecture sketches, state machines, flows, timelines, and other structured explanations readable in place without copying them into a separate editor.

Every diagram remains reversible. Use View source to inspect the original Mermaid definition, copy it through the normal code-block action, or return to the diagram. Click the rendered diagram—or use Expand—to open a large preview. The preview reuses the completed SVG rather than rendering the source a second time, so opening and closing it does not introduce a new interpretation of the diagram.

The renderer follows the active light or dark theme and redraws when the theme changes. Mermaid is loaded only when a supported message actually contains a diagram, keeping it out of the initial Web bundle. Other Markdown surfaces remain unchanged and continue to present Mermaid fences as ordinary source code.

Failure Stays Legible

Diagram rendering is deliberately progressive: the message content remains useful even when Mermaid cannot draw it.

Invalid definitions and diagrams beyond the supported source limit fall back to the original code with a clear status instead of leaving a blank or partially initialized surface. Canceled queued views are skipped before expensive rendering begins, so closing an Inbox or switching Groups does not make obsolete diagrams compete with the active conversation.

Flowchart image shapes are left as source. Mermaid waits for browser image decoding while drawing those shapes, which can stall later diagrams and introduce network-dependent behavior into message rendering. Ordinary text, nodes, edges, labels, and supported Mermaid diagram types continue through the normal rendering path.

A First-Class Group Preamble Contract

Provisioners and SDK integrations can now manage a Working Group's startup preamble through three daemon IPC operations:

• group_preamble_get reads the effective built-in or group-specific preamble.
• group_preamble_set creates or replaces a non-empty group override.
• group_preamble_reset removes the override and restores the built-in preamble.

The override replaces only the configurable preamble body. CCCC's fixed actor identity, routing rules, and protocol frame remain in place, preventing a product-specific startup boundary from accidentally removing the collaboration contract.

This is particularly useful for products that provision dedicated CCCC workcells and need actors to enter a known standby or initialization posture before receiving an authoritative mission. Integrations no longer need to know the on-disk CCCC_HOME layout or mutate prompt files directly.

Repeated provisioning is idempotent: setting the same content reports no change and does not rewrite the file. Preamble content is limited to 512 KiB after UTF-8 encoding, and oversized input is rejected before storage rather than being accepted and later truncated.

Preamble changes apply the next time the startup preamble is delivered; they are not injected into sessions that have already started. Start a fresh provider session when the new preamble must take effect immediately. group_reset creates a new Group and intentionally does not copy the old override, so provisioners should set the required preamble on the replacement Group before starting its actors.

Python 3.11 Through 3.14

CCCC now requires Python 3.11 or newer and formally supports Python 3.11, 3.12, 3.13, and 3.14.

Python 3.14 is the primary development, CI, packaging, and Docker runtime. Compatibility jobs continue to compile CCCC, exercise the CLI, and complete an MCP handshake on Python 3.11 through 3.13. Nightly serial coverage runs at both ends of the supported range.

The default Docker image now uses Python 3.14. Runtime cleanup was also tightened for Python 3.14 so context-manager cleanup does not accidentally suppress an exception raised by the protected operation.

Upgrade Notes

• Python 3.9 and 3.10 are no longer supported. Upgrade the environment to Python 3.11 or newer before installing v0.4.33.
• No group-ledger or shared-state migration is required.
• Existing Mermaid code remains stored as ordinary message text; rendering is a Web presentation feature and does not rewrite ledger events.
• Mermaid diagrams must still follow Mermaid's own syntax and composite-state rules. Unsupported or invalid definitions remain available through the source fallback.
• Existing group preamble files continue to work. The new daemon operations formalize management of the same group-level override rather than introducing a second storage mechanism.
• Existing running sessions keep the preamble they already received. Restart or create a new provider session to apply a changed preamble.

Why Upgrade

Upgrade to v0.4.33 if your teams exchange architecture or workflow diagrams in CCCC messages, if you build products that provision purpose-specific Working Groups, or if you want CCCC on the current Python 3.14 runtime while retaining a tested compatibility range back to Python 3.11.

The broader direction remains intentionally practical: richer collaboration where users can see the benefit, stable contracts where integrations need control, and less hidden behavior in the runtime beneath them.