Plan Kanban work

1. Read the project instructions and relevant product code from the integration or feature worktree. Read existing task/spec metadata through the canonical controller; do not assume .juno_task/plan.md exists.
2. Produce one concise PDR covering the goal, current behavior, scope, exclusions, risks, dependencies, acceptance criteria, and focused tests. Draft it in a fresh external file; do not place it in the product tree or a task body.
3. Preflight yy ledger --help and yy ledger artifact --help. Capture the PDR as a local immutable report Artifact Record with task/request provenance, then verify its ID, digest, size, retention, retrieval, and history. If the artifact API is unavailable, stop with the external draft intact and request an upgrade; never fall back to product docs/, task bodies/responses, new .juno_task/specs, or direct store edits.
4. Split only when pieces can be implemented and validated independently. Concurrent tasks must have explicit path ownership and dependencies.
5. Create tasks through routed yy ledger commands. Put concise durable requirements and acceptance criteria in each task body, record the PDR artifact ID in supported task fields/provenance, and relate follow-ups instead of reopening archived IDs.
6. Product documentation is only documentation shipped with the product. Never create controller-private tasks, ledger, state, artifacts, objects, specs, or receipts inside a product or feature worktree.
7. Do not start implementation, create worktrees, push, deploy, or mutate production unless the user separately asks.

Use --id, not legacy --ID, for Kanban mutations. Return the task IDs and a short dependency/order summary.

Retrieve the PDR by ID

Preflight yy ledger get --help; use yy ledger get RECORD_ID -f json to read back a known PDR without guessing its storage type. If installed get is task-only, use yy ledger record get RECORD_ID -f json after checking native help; stop for an upgrade if unavailable. New PDRs remain artifact/report (artifact_ IDs on supporting runtimes); historical document/pdr remains readable. Existing IDs remain unchanged: do not invent pdr_ or rewrite stored references.

Unknown IDs require bounded record search --projection summary --limit 20, not trial-and-error typed gets. Exact reads include hot/archive in the selected project; cold discovery needs explicit scope. Metadata/history alone is not byte round-trip proof. Verify included text or explicitly retrieve local/inline bytes with --content --max-content-bytes N (64 KiB default, 16 MiB maximum). Check exit status and digest/size; never download external payloads implicitly. If exact-byte retrieval is unavailable, retain the draft and request a compatible runtime.

User-facing Record results

After creation, update, discovery, or handoff, report the Record kind/profile, actual immutable Record ID, and actual Ledger slug from the returned Record or a native get readback. Never invent a slug from the title or confuse it with the ID. If the selected API omits a field, say it is unavailable rather than fabricate it. IDs remain authoritative for relations and lifecycle operations; slugs aid discovery.

$ARGUMENTS