checkin

The canonical copy of this command lives in the companion unitares-governance-plugin repo (commands/checkin.md). This copy adapts helper paths to this repo's scripts/client/session_cache.py and deliberately keeps repo-specific guidance the plugin copy does not yet carry: the response_mode="compact" default, the explanation that an argless identity() is gated to a fresh mint, the cache-token rule, the --json payload on the slot stamp, and no reset-milestone step (this repo's helper has none). Sections marked <!-- repo-specific: keep on plugin sync --> must survive a future sync from the plugin.

Before calling tools, check for slot-scoped session caches in the current workspace.

Use the shared helper in this repo:

• scripts/client/session_cache.py list --workspace "$PWD" — slot inventory sorted newest-first; pick the entry whose slot matches your current client_session_id, or the newest entry if you do not have one yet
• scripts/client/session_cache.py get --slot=<slot> session — read that specific cache

A read without --slot returns the legacy flat session.json, which under S20 is read-only-legacy — do not write back to it and do not assume it corresponds to this process-instance.

If a matching cache exists:

• use uuid as the expected local identity anchor, not proof by itself
• rely on the active session binding or client_session_id for ordinary check-ins
• do not pass continuity_token to process_agent_update; it is reserved for explicit PATH 0 ownership rebinds

If current binding is unclear, call identity(client_session_id=<your client_session_id>) to inspect the active binding. Never call identity() with no arguments: a call carrying no proof argument is gated to a fresh mint, so it reports on a newly created identity instead of yours. Trust the answer only when identity_assurance.caller_proven is true.

If you must rebind to a cached UUID, include a matching live continuity_token from the same process response: identity(agent_uuid=<uuid>, continuity_token=<token>, resume=true). Never take a continuity_token from any cache file, whether a legacy v1/flat session.json or a v2 slot cache: only a token returned to this live process counts as proof. v2 slot caches do not persist it, and a token found in a legacy file is not a credential.

If this is a fresh process and no ownership proof is available, use /governance-start to mint a fresh identity rather than bare UUID resume. A cached uuid is not a parent by default; /governance-start explains when a handoff justifies declaring it.

If no local continuity state exists and the current identity is unclear, use /governance-start first.

Call process_agent_update once for this explicit /checkin. Outside an explicit request, check in only at a meaningful milestone when you also hold a judgment the substrate cannot infer: a self-correction, revised belief, material change in uncertainty or complexity, or handoff assessment after substantive work. A boundary before or after high-risk work qualifies only when it meets both conditions. The hooks already record per-turn substrate observations; do not manufacture an agent report to echo them.

Inputs:

• response_text: concise, secret-free statement of your judgment and the relevant work
• complexity: estimate 0.0-1.0
• confidence: optional, usually omit it. Any value mints a tactical prediction that is scored into the fleet calibration curve, so pass one only when you are stating a genuine belief about how your work will hold up, never a habitual number
• use the active session binding or client_session_id; do not auto-inject continuity_token
• use response_mode="compact" by default for Codex; reserve response_mode="mirror" for drift, guide/pause verdicts, or diagnostic review

Guidelines:

• There is no fixed time-, turn-, or tool-count cadence. Completion, generated output, a reminder, or task exit alone does not call for a check-in.
• One check-in may cover a coherent unit of work; a milestone or decision point also needs an agent-held judgment the substrate cannot infer.
• If recent local edit context exists, use it to improve the summary, but do not report raw file churn as if it were real progress.
• If deterministic results already happened in the workflow, mention them concretely instead of speaking in generalities.