comms-register

Comms register

Read the notification policy in the operating profile. For new projects, default to meaningful completion plus required decisions/blockers; honor decisions-only or requested checkpoints when specified. Quiet external notifications do not override the host's active-chat progress rules. Do not create daily briefs or send routine "starting/still working" pings unless requested. Internal progress belongs in the canonical task/event record.

Quiet reporting never means leaving a prepared decision unsent or free capacity unused. Follow the required coordinator cycle after replying: ask the next valid pending question in the same turn and take eligible authorized work. Do not manufacture a new approval request for routine work already authorized.

A completion means the agreed user outcome is usable in its stated environment, not simply that an agent finished or one repository landed. Batch related completed work into one message. If the policy is decisions-only, write completion to the record without an unsolicited ping. An urgent actionable blocker can interrupt; a repeated unchanged blocker should not.

When asked for status, answer the goal/thread the founder is discussing: goal → current result → what remains → whether the founder is needed. Use their product language; put hashes, hosts, agent counts and technical proof in the record unless needed for the question. Keep phone notifications concise and contextual. Don't turn an answer into a new approval request.

Use the bundled status view for a compact operational snapshot: running work, work awaiting release, the presented question, queued-question count and the next pending tasks. Running tasks never appear as "next"; user-initiated actions do not inflate "waiting on you". Use full record views only when detail is requested. For new intake, report the defined priority and queue position. An explicit request for pending decisions follows the one-question protocol. active_tasks groups recorded active lanes by task, so several workers on one task still produce one task summary. running_without_lane is an ownership discrepancy to reconcile, not proof that a process is dead. A lane record is not a live heartbeat. Label the channel of a question waiting in another chat instead of presenting it as awaiting an answer here.

An idle status feed is opt-in through the project's notification policy, never enabled just by installing this plugin. The executable Telegram status updater provides configuration, preview, exchange recording, tick/loop and restart recovery. Integrate it with the existing receiver's accepted-message and successful-send paths; do not run two publishers for one bot/chat. If authorized and supported, use one quiet editable post with the configured cadence/freshness limit; show a current user-facing sentence per active task, not agent names. Keep public_summary and summary_updated_at on the canonical task, refreshing them at dispatch and meaningful stage changes. Exclude inactive/stale summaries; do not add a companion state file. Retire the post on a real exchange. Successful questions and valid answers count as exchanges; typing indicators, the idle post itself and failed sends do not. An empty, stale or failed read is not evidence that all work completed. The post never replaces pending questions, task execution or receiver health checks.

Format for the actual channel: short heading, one fact per bullet, spacing between groups, and any decision last. Use rich text/HTML only when the installed bridge supports it; escape dynamic text with that channel's rules. Do not assume a transport flag or a project's language/format.

One presented question owns the decision channel until answered or explicitly parked; defer unrelated topics and notification batches rather than making a bare numeric reply ambiguous. Use coordinator-kit:question-protocol to correlate responses. A correction gets a brief acknowledgment and an updated record, not a long apology or repeated interim conclusions.