Messaging and finite work

​

Sovereign messaging

Each environment owns and serializes its outbound messages. Authorized peers read that configured ref or repository and publish replies from their own outbound location. Owner-write and peer-read endpoints are separate. Sender/recipient names inside content never grant access or execution authority. Messages carry bounded metadata and exact State references. Publication is a normal explicit non-force push followed by verification. Failed and uncertain effects remain distinct and are not retried automatically.

​

One finite tick

The work-cycle tick admits one Instance, reads explicitly permitted sources, selects at most one allowlisted task, records a durable claim before dispatch, optionally checkpoints explicit memory, publishes a correlated reply, and saves reader progress. Accepted STOP, unresolved claims, uncertain effects, and terminal persistence failures remain barriers; restart does not redispatch them. The development handler composes a bounded implementer and exact-commit reviewer. Every coding attempt receives an isolated branch/worktree. A confirmed stopped ordinary failure is preserved and is terminal for that task, but it does not halt unrelated authorized work or create retry/repair authority.

​

Scheduling and usage

The source archive includes a finite Windows launcher and disabled Task Scheduler template. It does not install or enable a task. Native provider-app heartbeats may consume a model turn before local repository code can determine that an inbox is idle. Every Instance run should save available usage through its configured environment/session profile. Missing optional task, launcher, or provider-turn links remain unknown; they do not erase known Instance observations. Token counts and account allowance are separate evidence. Read the Instance operating model, messaging contract, and work-cycle contract.

​

How we coordinate work in practice

A person and a coordinating assistant prepare a bounded assignment; a project agent reads it, works on its own branch, and publishes a report. The coordinator inspects the referenced change and records acceptance or a specific follow-up. Follow the tutorial. A shared GitHub coordination folder is a practical handoff channel. It should not be confused with automatically invoking the native message API or polling an inbox. Manual kickoff remains valid when a verified worker is not active. User documentation is maintained centrally: workers supply implementation evidence, exact commands, checks, and limitations; the documentation owner reconciles those reports into public guides. Private operations and raw sessions stay out of public documentation.