# CCD Radar — Extended Details

Load this reference on material findings, fallback paths, detailed evaluation rules, or when the compact skill instructions are insufficient.

## Detailed Evaluation Rules

### Bucket status mapping

Map each `evaluation` bucket's `status`:
- `review_required` / `manual_review` → inspect if it maps to blocker, acceleration, or policy issue
- `no_change_detected` / `no_cli_signal` / `clean` → default to `none`, override if session delta warrants
- `needs_review` → inspect evidence and classify explicitly
- `ready_to_commit` / `ready_to_push` → use for wrap-up guidance

### Session delta edge cases

If `session_delta.status` is `no_active_session`:
- Do not treat as error or switch into broad repo exploration
- If `session_boundary.action` is `continue` with no drift → report nothing active, stop
- If `session_boundary.action` is `refresh`/`stop` → keep follow-through narrow and CCD-owned

### Behavioral drift

If `behavioral_drift.status` is `needs_recalibration`, treat as material even when other buckets look clean. Use `signals`, `evidence`, `recommended_corrections` to drive findings and drafted correction.

Also treat `work_stream_decay.status` of `warning`/`critical` as material repetition signal.

### Fast-path rules

Fast path applies only when:
- Every `behavioral_drift.signals` entry is `aligned` or `no_signal`
- `evaluation.wrap_up.status` is `aligned`

Any `drift` signal — including `handoff_references_resolved` (paths no longer exist) and `handoff_issue_references_fresh` (commits reference issues in handoff) — forces full rewrite via `ccd handoff write`.

### Operator-invoked close-out

Treat operator-invoked close-out as authorized only when the newest user turn literally names `$ccd-radar`. If the skill was loaded by description match, checkpoint wording, inspection wording, or context pressure, do not clear unless the user explicitly asks to close out.

Before clearing after a clean-close helper refusal, verify clean state from the original `ccd handover` JSON, not from the refusal reason. Required preconditions:
- `candidate_updates.handoff` and `candidate_updates.memory` are empty.
- `execution_gates.unfinished_count` is `0` or execution gates are absent/missing.
- `behavioral_drift.status` is `aligned` or `no_signal`, and every drift signal is `aligned` or `no_signal`.
- `evaluation.next_step.status` is `no_change_detected` or `no_cli_signal`.
- `evaluation.wrap_up.status` is `clean` or `aligned`.
- `escalation.blocking_count` is `0`.

If any precondition is false or missing, treat it as a material finding: surface the concrete unresolved item and ask at most one question. Do not clear.

If every precondition is true, write the handoff for the current completed state, then clear session state. This is operator-authorized close-out, not a warning. After both write and clear succeed, do not mention `session_boundary`, `continue`, `close_clean`, helper refusal, or manual fallback in the final brief.

Surface helper refusal or fallback details only when they change operator action:
- candidate handoff, memory, recovery, or gate decisions remain unresolved
- material findings require a choice
- any CLI write or clear operation failed
- the user asked for diagnostic detail

### Context health

- If `degradation_risk_pct` is absent, avoid percentile claims
- If `band` is `risky`/`critical`, recommend wrapping up soon
- If `operator_symptoms` includes repeated suggestions or missed constraints, treat as strong evidence

### Recovery

When `recovery.status` is `loaded`:
- Prefer `checkpoint` for "what was I about to do?"
- Use `working_buffer.summary_lines` only as bounded recency context
- Do not treat recovery as durable memory or project truth

If CLI predates schema version `8` and omits `recovery`, treat as absent (not error).

### Memory

Treat `candidate_updates.memory` as deterministic promotion-review input only. Do not auto-write upward memory.

### Session mode

If `session_state.mode` is `research`, bias draft toward compact implementation-oriented handoff.

## Material Findings Prompt

Only entered when findings are classified as material. Skip on clean evaluations.

**Priority-affecting (blockers, acceleration):** state what was discovered, recommend action, ask developer to confirm.

**Policy drift:** state drift with evidence, draft proposed update, flag as important decision.

**Behavioral drift:** do not use the phrase "behavioral drift" in default brief. Translate to concrete continuity repair needed. Ask only the missing choice.

If `handoff_references_resolved` carries `provenance: inherited_from_startup`, frame the stale path references as inherited cleanup. Do not ask for recalibration unless Radar reports current-session handoff-reference drift.

## CLI Unavailable Fallback

If CLI is unavailable:

1. Resolve active profile from `CCD_PROFILE` or `main`.
2. Resolve attached workspace:
   - Walk up from `.` for `.ccd.toml`
   - If marker declares `substrate = "directory"`, use directory workspace
   - Otherwise, check `git rev-parse --is-inside-work-tree`
   - If neither works, report close-out blocked
3. Inspect native handoff state through resolved substrate:
   - Git: `git rev-parse --git-path ccd` → `profiles/<profile>/state.db`
   - Directory: `~/.ccd/workspaces/dir_<sha256>/profiles/<profile>/state.db`
4. Collect delta evidence from available substrate signals
5. Treat as evaluation-only; do not manually edit native handoff state

## Handoff Write Details

Canonical handoff lives in `state.db::handoff`. CCD no longer emits `handoff.md` to disk: `ccd handoff export --path .` prints Markdown to stdout. Do not rely on markdown export as runtime truth.

To persist recovery: `echo '{"origin": "compaction", "checkpoint": {...}, "working_buffer": {...}}' | ccd recovery write --path .`

**Critical rule:** the handoff must describe what is true now and what to do next. It is not a session log.
