Using One Connect

Insights, reports and release

Overview, reports and analytics derived only from recorded events, and a release cockpit that takes merged work out through ordered, individually approved steps.

Insights in the top bar opens a drawer with four tabs. Everything in it is read from the project's event log and state; nothing calls a model, and gaps are shown as gaps, never as success.

Overview#

/insights shows the project at a glance: every agent with its status and Now/Next, what is waiting on you, release gates and infrastructure, open alerts, the state of shared context, and a One Ask box.

Brief and reports#

/reports (also on a paired phone) has:

• Brief: each agent's Now/Next, questions waiting on you, alerts, work in flight and recent handoffs.
• Timeline: what happened, in order.
• Morning report: what changed since you last looked, built only from evidence.
• Standup: an exportable summary.

Each claim shows its basis (recorded by One Connect, agent-reported and unverified, or counted from events) and links the event numbers, commands and SHAs behind it. Missing check results, deploy evidence or release events are stated as gaps. The same reports are available from /api/reports/brief, /timeline, /morning and /standup.

Analytics#

/analytics covers:

• Agent activity: runs, idle time, remaining subscription capacity, recorded input and output tokens and cost where providers report them, unread messages, and agents not on their newest available model.
• Work pipeline: issues by lifecycle state, and how many are verified Done with both merge and acceptance evidence.
• Evidence and coordination: team messages and acknowledgements, and pending approvals and Decisions.
• Shared context: One Ask queries and the source characters supplied to answers.

Token figures are labelled as estimates unless a provider reported them. Context sizes are retrieval measurements, not proof of token savings.

Release cockpit#

/release takes merged work out to production through an ordered release plan. Each step has an owner, an exact target and environment, a command, a check and a rollback, and can be one of:

push, pr, ci, migration_dry_run, backup, migrate, env_flags, deploy, verify_routes, device_qa or custom.

• New release plan starts from a merged work item. Add, reorder and edit steps, then Save plan.
• Steps run strictly in order. A step cannot be skipped; a later one waits on the earlier step.
• Approve this step creates a Decision bound to the exact step, target, environment and command. Changing any of them invalidates the approval. Outward actions (push, pull request, backup, migrate, env flags, deploy, custom, migration dry run and route verification) need the second confirmation.
• A step turns green only with fresh verification of that exact action. A human attestation is labelled as such and never substitutes for verification.
• Request rollback approval runs the step's rollback, whose own check verifies the restored state.
• If a write is interrupted, the step becomes uncertain and is never repeated. Inspect interrupted write checks the effect without re-running it.

Agents can read the plan with get_release_status but can never approve or skip a step.

Code host and infrastructure#

The cockpit reads, never writes, through connectors you configure under Settings → Project and policies and activate in Connectors:

A production branch without protection on the code host raises a loud warning. Live calls happen only after activation with a host and scopes. Unchecked results are never shown as healthy: a read that has not happened is unavailable. With finding_issues: rule, problems found by these probes are filed as issues; by default (manual) you file them yourself.

Agents can read infrastructure state with get_infra_health, which covers Docker, local Postgres, hosting and migration drift; they cannot change it.