feat(handoffs): publish owner task interfaces

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a023c0-a0a3-7c03-b395-5a0d2757214d

docs/adr-005-owner-task-interfaces.md

@@ -0,0 +1,70 @@
+---
+id: RMGR-ADR-005
+type: architecture-decision-record
+title: "Owner-task interfaces for cross-repository adoption"
+status: accepted
+decided: "2026-08-22"
+deciders: ["Bernd Worsch", "repo-manager"]
+related:
+  - RMGR-WP-0010
+  - docs/owner-task-interface-contract_v1.md
+  - canon-work-record-types
+---
+
+# ADR-005: Owner-task interfaces for cross-repository adoption
+
+## Status
+
+**Accepted** (2026-08-22).
+
+## Context
+
+A producer can identify work that belongs in another repository before the
+owner has created a task for it. Sending only a prose request makes the next
+coding agent reconstruct the objective, inputs, constraints, and acceptance
+criteria. Keeping a duplicate waiting task in the producer workplan then makes
+two agents carry one todo.
+
+The fleet work-record registry is deliberately closed. An interface offer must
+therefore not become a new task-like lifecycle or a second backlog.
+
+## Decision
+
+1. A producer may publish an `OwnerTaskInterface`: a versioned, immutable
+   proposal containing the complete owner-ready objective, authoritative
+   inputs, deliverables, constraints, acceptance criteria, and verification.
+2. The interface is not a work record. It has no assignee or lifecycle status
+   and does not replace the target owner's workplan/task/decision.
+3. The target owner records `approved`, `amended`, or `rejected` in its own
+   authoritative work record. Approval cites the interface id and exact Git
+   revision. An amendment records the delta rather than silently changing the
+   imported meaning.
+4. Once the producer publishes and routes a complete interface, its handoff
+   task is done. Adoption and implementation are tracked only in the target
+   owner's work record; the producer does not retain a duplicate todo.
+5. Dependencies that still block producer-owned implementation remain normal
+   producer tasks. The interface pattern is only for work whose implementation
+   authority has crossed the repository boundary.
+6. Interfaces contain no credentials, secret values, mutable environment
+   state, or copied authority. They reference authoritative contracts and
+   evidence by stable path/id and revision.
+
+## Consequences
+
+- Owners can approve and use the supplied task specification directly.
+- Later agents do not need to recover intent from messages or re-plan the work.
+- Owner amendments stay explicit and auditable.
+- Work queues contain one implementation todo, in the repository that can
+  actually complete it.
+- Messages become routing notifications; they are not the only copy of the
+  implementation contract.
+
+## Rejected alternatives
+
+- **Duplicate tasks in producer and consumer workplans.** They drift and need
+  manual closure coordination.
+- **Prose-only messages.** They are useful routing evidence but too weak to be
+  an executable interface.
+- **A new `handoff-task` work-record kind.** The existing task, intake, and
+  decision kinds already own lifecycle; adding another would create a parallel
+  backlog ontology.