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

id	type	title	status	decided	deciders	related
RMGR-ADR-005	architecture-decision-record	Owner-task interfaces for cross-repository adoption	accepted	2026-08-22	Bernd Worsch repo-manager	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.