diagnose

The canonical copy of this command lives in the companion unitares-governance-plugin repo (commands/diagnose.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 explanation that an argless identity() is gated to a fresh mint, the cache-token rule, the list_process_bindings() section, and the --json payload on the cache refresh. Sections marked <!-- repo-specific: keep on plugin sync --> must survive a future sync from the plugin.

Start by inventorying 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
• scripts/client/session_cache.py get --slot=<slot> session — read a specific cache

A read without --slot returns the legacy flat session.json, which under S20 is read-only-legacy — surface it only as a lineage candidate, never as the current process's identity.

If continuity state exists:

• treat uuid as a local identity anchor and lineage candidate
• ignore any continuity_token field in the cache; it is never proof

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.

Do not verify by bare UUID resume. If you need to test ownership of a cached UUID, call identity(agent_uuid=<uuid>, continuity_token=<token>, resume=true) only when this live process holds a matching token returned to it by the server.

If no proof-owned UUID rebind is available, call identity(client_session_id=<your client_session_id>) to inspect current binding. Never call identity() with no arguments: with no proof argument the call is gated to a fresh mint and reports on an identity it just created, so read identity_assurance.caller_proven before trusting the result.

If you have no client_session_id, report the identity as unknown and suggest /governance-start, which declares the cached uuid as a parent only for a deliberate handoff from an exited process.

Then call get_governance_metrics for the current agent using the same continuity data. This reads and interprets the available state; it does not advance EISV through a new check-in. Use verbosity="standard" or verbosity="full" when the source or lifecycle details needed for the diagnosis are absent from the compact view.

Call health_check() only when system health, not agent state, may be part of the issue.

Display:

• whether identity was proof-resumed, freshly created, or created with lineage
• identity_status
• bound_identity
• session_resolution_source
• continuity_token_supported
• identity_assurance
• deprecation warnings
• whether continuity looks strong or weak
• E, I, S, V with primary_eisv_source and available timestamp/freshness labels
• coherence with its producer and role (coherence_source / coherence_role, or nested coherence.source / coherence.role)
• risk score with risk_score_source when returned
• verdict with verdict_source / verdict_resolution_source when returned
• write_gate, including any applied hold and its available recovery or expiry information; distinguish it from an inferred recommendation
• next_action, memory_suggestions, and recovery_hint when present
• summary or mode/basin if available
• which fields come from behavioral assessment or ODE feedback, as identified by the response; label missing provenance as unknown

The policy_evaluation and enforcement blocks belong to assessment-bearing check-in responses, not this metrics read or a receipt-only retry. Do not infer an enforcement posture from a bare verdict. Use the returned write_gate for the current lifecycle restriction. A high-risk reading is a reason to inspect its inputs and relevant task evidence; an applied hold follows its recovery contract even when the reading's interpretation is disputed.