# AGENTS.md

> Canonical AI policy for this repo.

## Project

`ccd-guide` is the continuity kernel and reference CLI for Continuous Context Development. It owns project/profile locality, session state, handoff, recovery, escalation, execution gates, checkpoint/handover/radar, thread capsules, policy projection, and CCD1 prompt surfaces while leaving harness lifecycle facts to Lifeloop or external adapters.

## Position in the nantobv stack

CCD is the continuity kernel above Lifeloop's lifecycle substrate.
The local boundary is documented in
[`docs/rfcs/0009-post-slimdown-ccd-shape.md`](docs/rfcs/0009-post-slimdown-ccd-shape.md)
and [`specs/skill-sync-distribution/body.md`](specs/skill-sync-distribution/body.md).
Lifeloop's matching source-file ownership decision is coordinating
context, not a live CCD enforcement dependency.

## Coding Standards

- Read `MEMORY.md` before deep implementation work.
- Keep docs, templates, skills, and CLI behavior aligned; if one changes, update the paired surfaces in the same task or explain why not.
- Prefer small, reversible Rust changes. Add new crates only when the standard library or a simple script is not enough.
- Favor deterministic, machine-readable behavior. Agent-facing commands should fail closed and explain the reason.

## Architecture Rules

- `AGENTS.md` is the canonical repo policy. Runtime-specific instruction files such as `CLAUDE.md`, `GEMINI.md`, and `.claude/CLAUDE.md` are user-owned, maintainer-authored files, not generated derivatives.
- CCD does not write to model instruction source files (`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, ...) except for explicit maintainer-requested policy edits to those files.
- Exception: when the user or maintainer explicitly invokes `claude-adversarial-review`, the invocation is standing authorization to send the skill-selected diff/files for that review scope to Claude. This authorization is limited to the review-only Claude Code runner described by the skill and does not authorize unrelated external transmission, broader repository access, destructive actions, or persistent cross-harness policy projection.
- `ccd skills install` installs CCD's canonical skill bundle into a confirmed active harness native skill layout, or into the harness named with `--harness`. CCD owns the skill content, not ongoing cross-harness alignment; known harnesses without confirmed skill layouts must fail closed rather than receiving invented directories. Lifeloop may surface harness-change install prompts or read-only divergence evidence, but CCD does not enforce projections after install.
- Level 1 templates, `ccd attach`, `ccd doctor`, and the shipped skills must describe the same workflow; if one changes, sync the others.
- `ccd` commands are agent-facing interfaces, so overwrite protection, conservative path handling, and predictable output are first-order requirements.
- Public CLI or template behavior changes require regression coverage in `tests/cli.rs` and doc updates where the behavior is surfaced.

## Workflow

- Plan before implementing. Name the files you expect to touch and why.
- Probe before commit. Run the smallest deterministic check that can fail for the change you made.
- Run `git status` and `git diff --minimal` before any commit.
- Stage explicit paths. Never use `git add .`.
- Show the diff to the human before committing. Wait for approval unless the human has already explicitly delegated commit/push authority for the current task.

## Testing

- Run the smallest check that proves the change.
- For Rust or template behavior changes, prefer targeted `cargo test` coverage in `tests/cli.rs`.
- For repo-policy changes, run `cargo run -- doctor --path .`.
- If you skip a check, say why.

## Safety

- No secrets in docs, code snippets, generated files, or committed history.
- Stay within the declared task scope.
- Ask before touching deployment, publishing, auth, billing, or data-migration paths.
