71 lines
2.9 KiB
Markdown
71 lines
2.9 KiB
Markdown
|
---
|
||
|
|
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.
|