Coordinate an Atrinik project

Own one authorized parent and its acceptance criteria through delivery and integration. Launch and manage workers yourself; do not ask the user to relay messages, launch chats, or exchange commits. Create a persistent goal only on explicit request. Automatic skill selection is not write authority.

Establish authority and readiness

Read atrinik-multi-repo-workspace, the live atrinik-issue-delivery entry, and the operator protocol. Writing leaves load the issue preparation/ledger procedure for their own exact coordinate; retain proven session handles instead of rereading unchanged procedures on each dispatch. Verify the live parent, repositories, existing children/PRs, dependency graph, acceptance and authorized tracking operations before initialization. Reconcile native relationships and prose; neither alone proves completeness.

Use the supported canonical Linux coordinator. Inventory all existing leaf ledgers, containers and worktrees before claiming anything. Dirty candidates, existing PRs and foreign sessions remain external, not new implementations. The project record schedules work; it never grants worktree/ledger reuse. Keep issue delivery and legacy program delivery unchanged as fallbacks; do not migrate their state or reinterpret their program authority field.

Run the ready graph

Use python3 -m atrinik_workspace.project_delivery, never hand-edit its state. Inspect actual runtime worker capacity and existing open workers; a requested 16 slots is not proof. Reserve ready disjoint lanes before spawning. Record the actual returned worker ID, exact entry mode/coordinate and attempt immediately. If spawning fails or its outcome is uncertain, reconcile before retrying.

Each writing worker explicitly invokes $atrinik-issue-delivery for its one selected issue or PR. It completes the existing authenticated genesis, inventory, safe dedicated worktree binding and exact-coordinate gates before edits/tests. Never share a writing worktree or credential/cache namespace. An existing PR needs explicit PR-mode authority; do not adopt it as new issue work. Reserve shared files/resources; subdivide only when ownership permits. Use additional read-only workers for exploration, tests and independent review; count them against actual capacity. Fill available capacity with useful ready work; do not impose an arbitrary low worker cap. Limit heavy builds separately using measured resource contention.

Use compact task packets with exact ownership, base/head, paths, acceptance, container/ledger handles, validation commands, and granted/pending/rejected authorization; omit inherited conversation when raw task evidence suffices. Choose models per task: capable reasoning for architecture or security-sensitive review, an efficient coding model for bounded implementation/tests, and a lighter model for deterministic extraction. Preserve output quality and independent review; expand context or model when needed. Use an available capable model when a preferred model is unavailable; report the fallback. Every worker reads applicable mandatory instructions, including read-only extractors with a narrow task-source scope. Run waits, JSON extraction and repetitive I/O in tools/scripts. Use the operator protocol's snapshot output to keep CAS documents out of model messages. Process and tooling diagnostics never gate scheduling or require routine reporting.

Route findings to the owning worker, reuse it for fixes, and keep independent ready lanes moving. Workers deliver through final-head validation and fresh whole-diff review, not merely PR creation or one green run. Verify their live leaf-ledger/report and remote head evidence before recording results; worker prose alone is not acceptance. Integrate through owned PR branches, with ordinary commits and refreshed base/head evidence; never force-push or bypass leaf gates.

Maintain scoped tracking and finish

Routine local fixes, tests, reviews, commits, ordinary pushes and necessary in-scope PR deliveries need no repeated approval when project delivery is authorized. Coordinator tracking is separate from leaf permissions: use the journal only for authorized assignment, owned progress comments, native links, dependencies, bounded missing-child creation and existing Project Status. Preserve human text; never force reparent, unassign others or duplicate issues.

After observed merges, refresh parents/dependants, invalidate stale integration evidence, update tracking, and run newly unblocked lanes. Retain one canonical closing PR per leaf; parent references are non-closing until all requirements are fulfilled. Readiness is not merge authority. Stop for merge/deployment approval, unavailable authentication, uncertain ownership or expanded scope; continue unaffected work first. Never bypass policy or copy credentials.

Close a parent only with explicit closure authority, fresh complete graph/PR observations and criterion-by-criterion terminal evidence. Otherwise hand off the exact remaining closure action. Report delivered PRs and heads, acceptance, remaining gates, external owners, recovery root and next runnable lanes. Do not claim completion while only child counts or PR status look finished.

For unchanged bound targets on reconnect, use the public revalidate-current-targets-cas exact-tuple proof in the issue-delivery ledger protocol; saved safety fields or generic CAS are not live lease proof.