operating-coordharnesslisted

# Operating CoordHarness Use one `coord.db` as lifecycle authority. Treat dashboards, native clients, sidecars, documentation, and memory as projections or evidence; none may silently change lifecycle state. ## Start from the smallest truthful context 1. Resolve the coordinated project root and database explicitly. Do not infer a database from an unrelated checkout. 2. Run `coord preflight` when available; otherwise inspect `coord board` and the exact work item before loading broad project context. 3. Claim an existing assignable item before substantive work. If new work is genuinely required, create it with an acceptance condition and concrete `done_signal` before claiming it. Read [references/lifecycle.md](references/lifecycle.md) for the lifecycle, handoff, review, and completion-proof contract. ## Keep parallel work bounded The orchestrator owns the durable claim. Give each subagent a non-overlapping objective and file scope; record its bounded result under the parent instead of minting misleading peer ownership. Use typed handoff when responsibility moves between actors, and optimistic concurrency when the row may have changed. ## Separate agent turns from durable processes Use tracked jobs for long CPU, GPU, build, indexing, or local-model work. A job publishes compact liveness and progress; its command body, prompts, stdout, credentials, and source text do not belong in the sidecar or board. Read [references/jobs.md](references/jobs.md) before laun