Messaging and automatic operation

​

Sovereign messaging

Each environment owns an outbound messages repository. It publishes its messages there. Authorized peers read that repository and publish replies from their own outbound repositories. Git hosting permissions control access; a sender or recipient name inside a message does not grant it. This lets each environment retain ownership of its own outbound history while sharing the specific work another environment needs.

​

A useful development exchange

The intended workflow is a bounded task followed by implementation, an independent review of the exact candidate commit, and either correction or acceptance. Each handoff needs enough information to identify the work: This is a conceptual checklist, not a published message schema for 0.1.0a3. An execution record’s input_messages field can hold State references. That field alone does not publish, deliver, read, or acknowledge a message.

​

What a schedule contributes

A scheduler starts a process at a time. An operational worker also needs a way to find eligible work, avoid overlapping executions, apply a finite budget, persist progress, and recognize completed work after restart. For a future scheduled workflow, useful acceptance evidence would include a real timed launch under the intended account, working authentication, one completed task, a tested stop control, and a fresh-process continuation without repeating completed work. An idle check should not require a model call. Those are readiness criteria, not features provided by this release. The synthetic alpha utilities are not hourly workers. See current capabilities and environment setup before relying on an automated workflow.

​

Public reference

Public architectural overview, Execution record.