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.

docs/owner-task-interface-contract_v1.md

@@ -0,0 +1,92 @@
+---
+id: RMGR-CONTRACT-OWNER-TASK-INTERFACE-0001
+type: contract
+title: "Owner-task interface contract"
+version: "1"
+status: active
+created: "2026-08-22"
+updated: "2026-08-22"
+related:
+  - RMGR-ADR-005
+  - RMGR-WP-0010
+---
+
+# Owner-task interface contract v1
+
+An owner-task interface is a complete proposal that another repository can
+approve and adopt by reference. It transports implementation intent, not task
+lifecycle.
+
+## Required shape
+
+```yaml
+apiVersion: helixforge.repo-manager/v1
+kind: OwnerTaskInterface
+metadata:
+  id: helixforge.example.consumer-port.v1
+  title: Adopt the example consumer port
+source:
+  repo: producing-repo
+  workplan_task: PRODUCER-WP-0001-T04
+target:
+  repo: consuming-repo
+  owner_agent: consuming-repo
+approval:
+  dispositions: [approved, amended, rejected]
+  record_in: target owner work record
+task:
+  title: Adopt the example consumer port
+  priority: medium
+  objective: Consume the producer contract without copying its authority.
+  inputs:
+    - ref: producing-repo/docs/example-contract_v1.md
+      authority: producing-repo
+  deliverables:
+    - Implement the consumer adapter.
+  constraints:
+    - Do not infer missing identity.
+  acceptance:
+    - A contract fixture passes through the consumer boundary.
+  verification:
+    - make test
+```
+
+`inputs`, `constraints`, and `verification` are optional. The objective,
+deliverables, and acceptance criteria are mandatory and owner-ready.
+
+## Approval and adoption
+
+The target owner records one disposition in its existing workplan task or
+decision:
+
+```yaml
+interface_id: helixforge.example.consumer-port.v1
+source_revision: <Git commit containing the interface>
+disposition: approved  # approved | amended | rejected
+```
+
+This may be prose or structured metadata according to the target repository's
+existing convention. `amended` must cite the delta. The target task remains the
+only lifecycle-bearing implementation record.
+
+The source task is complete after the validated interface is committed and its
+owner is notified. A later producer task is warranted only if an approved
+amendment requires producer-side changes.
+
+## Discovery
+
+```bash
+rmgr owner-interface validate --path interfaces
+rmgr owner-interface validate --path interfaces --owner ops-warden
+```
+
+The command validates all interface files before returning their content. An
+owner filter matches either `target.repo` or `target.owner_agent`.
+
+## Authority and safety
+
+- The Git revision plus `metadata.id` pins the offered meaning.
+- Referenced records remain authoritative in their source repositories.
+- Interface files never contain secrets or mutable runtime observations.
+- An interface must not contain `status`, State Hub ids, or an assignee: those
+  would turn it into an unregistered work-record lifecycle.