RR Development Delegation Model - joeroberts/release-radar GitHub Wiki
This page records the operating model for developing Release Radar independently of the RR product harness. Updated October 5, 2026. Historical plans do not override current owner direction.
Status: The coordinator/task structure below is owner-directed. Role boundaries and review triggers restate the current repository rules. Details explicitly marked Proposed or Unresolved are not approved policy and must not be silently enforced.
Terms and scope
- Coordinator: the main Codex task that works with the owner, delegates and integrates results.
- Role task: a separate, persistent Codex task for Delivery Management, Senior Software Developer or a specialist, CI/CD, QA, Reviewer/Auditor, Chief Architect or another needed role. It is not a subagent or a GitHub sub-issue.
- Subagent: a worker used inside a role task's workflow. It does not replace that role task.
- Ticket: the GitHub issue that owns the authorized scope, acceptance criteria, status and results. No work happens without a ticket.
This model governs how RR is developed. It does not register RR in its own harness, require RR execution transitions, or change the workflow RR provides to other projects.
Coordinator boundary
The coordinator owns owner communication, scope clarification, selection of the needed roles, assignments, sequencing, resolution of conflicting results and delivery follow-through. It may inspect tickets and results, retrieve relevant context and record agreed decisions directly.
The coordinator delegates implementation, builds, independent verification and architectural assessments to the appropriate role tasks. It does not spawn subagents, substitute its own review for independent review, or bypass a role task because direct execution seems faster. Recording an explicit owner instruction is not an architectural decision.
Assignments carry only the owner's existing authorization. Neither the coordinator nor a role task may expand scope, grant itself external permissions, or convert a proposal into an accepted requirement. Unresolved owner choices are surfaced as specific questions.
Role ownership and invocation
Click a role name below to open its reusable task prompt. When initializing a task, use that prompt together with the ticket-specific assignment described below. The prompt defines role behavior; it does not grant additional authority or configure the model by itself.
Use the roles justified by the ticket's work and risks; do not create a full committee for every ticket.
Senior Software Developer is the existing Developer responsibility. Senior CI/CD Engineer succeeds Build, and Delivery Management succeeds Delivery; older references in repository instructions retain those same ownership and authorization boundaries. The former Build and Delivery pages are retired compatibility links, with their prior definitions retained in Git history. Reviewer/Auditor extends the existing independent Reviewer responsibility to a bounded completion audit; it is one role, not another approval tier.
These Wiki definitions are current RR role guidance and authoring inputs for future skills, not evidence that skills have been implemented or installed. A reusable role skill must package its own responsibilities, method, inputs, outputs and boundaries in SKILL.md and relative supporting resources; it must not fetch a Wiki role prompt to learn how to perform the role. Project-specific facts, decisions, ownership and authorization still come from the target project's governing sources. Loading a role skill does not configure a model, create a task or grant authority.
| Role task | Owns and returns | Invoke when |
|---|---|---|
| Coordinator | Owner communication, bounded assignments, sequencing, integration of results and delivery follow-through. Does not spawn subagents. | Main coordinating task for authorized ticket work. |
| Delivery Management | Ticket state, dependencies, acceptance tracking and handoffs. Succeeds Delivery; no implementation, test or CI/CD ownership. | Delivery state and handoffs need management. |
| Senior Software Developer | Application and tooling implementation, coherent refactoring and correction of implementation defects. Coordinates with QA and Reviewer/Auditor. | Authorized code or tooling changes are required and no specialist is the better entry. |
| Senior macOS Native Software Developer | Native SwiftUI/AppKit implementation and diagnosis within Developer ownership; QA and CI/CD retain their responsibilities. | Substantive native macOS interaction, state, scene/window, accessibility or runtime work. |
| Senior Frontend Software Developer | Browser implementation and diagnosis within existing web contracts; QA and CI/CD retain their responsibilities. | Substantive browser interaction, client state, responsive or accessibility work; no automatic hosting/deployment. |
| Senior CI/CD Engineer — GitHub | Workflow/check/runner/artifact configuration, builds, packaging and authorized release/install delivery. Succeeds Build; no application implementation or test-case ownership. | Pipeline, build, packaging or explicitly authorized delivery work. Documentation-only changes do not trigger an app release. |
| QA | Owns test design, test code/fixtures and execution against acceptance criteria; returns observed outcomes, reproducible defects and untested limitations. | Behavior changes need focused verification. Product changes use relevant mock projects; UI work includes runtime/design comparison. |
| Reviewer/Auditor | Independently reviews the actual candidate and audits the agreed block against its acceptance criteria and relevant evidence. Returns Required, Optional and Out-of-scope findings, criterion dispositions and an explicit result. Must not be the implementer. | Material implementation/documentation review and claimed completion of an agreed bounded work block; no review of reviews or per-tool-call gates. |
| Chief Architect | Decisions about affected architecture and boundaries; a recommendation, rationale, alternatives and impacted contracts. | Public contracts, persistence schemas, accepted architecture decisions or cross-component boundaries are affected. Also escalate a specific unresolved architectural conflict, including proposed coupling of RR development to its product harness. Routine edits and established designs do not need this role. |
| Feature Architect | Complete bounded feature design, component/state/data-flow responsibilities, coherent slices and acceptance seams within established system boundaries. | A feature needs design; a named public-contract, persistence or cross-component decision goes to Chief Architect. |
| Senior DBA | Database diagnosis/design and explicitly assigned application-owned schema/query/migration implementation, with integrity, compatibility and recovery evidence. | Concrete database work; owner/live data and mutation need explicit authority, and only Release Radar writes its SQLite store. |
| UX | User-facing workflows, guidance, errors, accessibility and presentation findings. | Those user-facing properties change. |
| Security / Privacy | Findings about authorization, owner data, credentials, external content, destructive actions or other affected security boundaries. | The change touches those risks; ordinary Markdown editing alone is not a trigger. |
| TPM | Dependencies, ordering and scope tradeoffs. | Initial delivery sequencing or a material scope/dependency change needs assessment. |
When a reusable role method is delivered and actually discovered, the
assignment names its entry point and exact source revision in addition to the
RR role prompt. The delivered chief-architect, feature-architect,
senior-software-developer, senior-qa-engineer, ux-architect,
senior-frontend-software-developer,
senior-macos-native-software-developer,
senior-software-security-engineer, senior-ci-cd-engineer, and senior-dba
entry points correspond to their matching rows above. The delivered
senior-python-developer entry point is a specialist method under the existing
Senior Software Developer / RR-Role-Developer row, not a separate RR role.
These entry points package portable working methods; they do not replace the
project-specific role definitions, configure a model, create a task or grant
authority. If an assigned entry point is unavailable, report the expected
source and discovery location rather than claiming invocation or reconstructing
the package from this table. Add other role entry points here only after their
own source delivery and discovery are verified.
Reviewer is a separate role task from implementation. QA tests behavior; Reviewer assesses the delivered changes. Do not make them repeat the same checks merely to obtain two approvals. One qualified Reviewer task may cover multiple concrete review risks. Reviewers identify Required, Optional and Out-of-scope findings; only Required findings block. Successful checks and reviews are terminal unless a concrete defect or changed candidate requires the affected check again. Do not review a review.
A GitHub “delivery task” means a bounded sub-issue, not assignment to Delivery Management. Assign implementation to Senior Software Developer or its explicitly selected specialist, test code and execution to QA, and pipelines/build/package/install delivery to CI/CD. DBA implementation is an explicitly assigned specialization of Developer ownership, not permission to edit the RR store. CI/CD may configure CI to run QA-owned tests; QA owns their design and acceptance results.
When an agent presents an agreed block as complete or ready for handoff, Reviewer/Auditor compares the actual candidate and evidence with that block's expected outcome. Existing successful checks are reused with attribution. The result identifies met, unmet and unverified criteria without creating a second QA pass or a review of the review. A completed block does not by itself complete its issue or epic.
Task continuity
Role tasks remain available until their ticket closes. Reuse the same role task for follow-up, corrections and clarification on that ticket. A completed response or idle task is not the end of its ticket assignment. Waiting for the owner, a dependency or a legitimate blocker does not authorize replacement or forced continuation.
The coordinator carries relevant owner corrections to affected role tasks and ensures they use current scope and acceptance criteria. A correction repeats only the affected implementation and checks; it does not restart the entire delivery process.
If a role task exhausts useful context or becomes unavailable before ticket closure, the coordinator may replace it. Preserve a concise handoff, link the predecessor and successor, and notify the owner. Do not rotate healthy tasks unnecessarily.
Closure and replacement
Ticket completion depends on the requested outcome, relevant direct checks, required independent review and the authorized delivery endpoint. A role's finished response does not by itself close the GitHub ticket. Existing authorization boundaries still govern closing issues, publishing, merging and releases.
Keep role tasks through ticket closure, then archive them without deleting their history. The coordinator creates fresh successors when the next ticket needs those roles. Delivery Management records the final outcome, useful evidence and limitations on the ticket; the coordinator coordinates closure and handoff.
Unresolved: whether to restore archived role tasks or create new ones if the same GitHub ticket is reopened. Do not guess that edge case.
Commits, review and PR delivery
Keep commits manageable and coherent. When the owner has authorized PR delivery and merging, request Copilot review, address its feedback and the independent Reviewer’s Required findings, and merge only after required reviews and checks are green. Recheck the affected candidate after corrections. Then proceed to the next ticket in dependency order.
Address feedback with a fix or an evidence-backed response; do not silently ignore it. A pending, failed, skipped or unavailable required check is not green. If Copilot review is unavailable, report the blocker rather than pretend another review satisfies the request. This sequence does not itself grant merge, release, credential or repository-settings permissions.
Progress snapshot
Keep one replace-in-place snapshot of the current outcome, active ticket links, material blockers and next action. Maximum: 60 lines and 6,144 UTF-8 bytes; exceeding either limit is a violation. Count LF-terminated lines plus one final nonempty unterminated line; an empty file has zero lines. Count the raw UTF-8 file bytes, including line terminators. Do not split the file or add diaries/archives as a workaround. GitHub owns work/results; the Wiki owns lasting standards.
Subagent boundaries inside role tasks
Role tasks may use subagents for bounded work within their assignment. The role task remains accountable for their scope, integration and reported result. Subagents inherit the original ticket, constraints and authorization; they cannot authorize more work or external actions.
Keep write ownership separate to avoid concurrent edits to the same files. An implementer cannot serve as its own independent reviewer. Subagents must not create additional approval layers or require recursive review. The coordinator receives the accountable role task's result rather than treating an unexamined subagent claim as completion.
Assignment and result handoffs
Use the existing task messages and GitHub ticket; no separate brief or report file is required. Release Radar development does not create repository task-brief files: the owning GitHub issue and delegated role prompt are the assignment, and ticket-owned implementation plans live in the Wiki.
An assignment identifies:
- Ticket URL, intended outcome, acceptance criteria and explicit exclusions.
- The role's bounded responsibility, dependencies and authorized endpoint.
- Relevant source/specification links and the working branch/worktree where applicable.
- For every displayed or produced consequential value, its source, freshness, failure behavior and owner. An unresolved property remains a named design input and is carried in the assignment before dependent implementation.
- Direct checks and independent review justified by the actual risk.
- The actual model/effort selected under current repository policy; a written profile alone does not configure a task.
A result identifies:
- What changed or was decided, with canonical artifact or change links.
- Checks actually run and their outcomes, including failures or skipped checks.
- Required defects, blockers, unresolved choices and material limitations.
- What the coordinator needs to do next, if anything.
Keep handoffs concise and current. Do not copy entire histories, produce per-turn diaries or claim checks passed without evidence. GitHub owns current work/results; the Wiki owns lasting standards; progress remains a small current snapshot.
The acceptance-verification method defines the consequential-value questions
and later evidence expectations. Issue preparation obtains and records the
inputs, the Coordinator assigns them, and the Developer consumes them or
surfaces the unresolved design input. This handoff contract does not move issue
creation, acceptance verification or implementation into another role.
For issue hierarchy and metadata, see the GitHub Issue Standard. Consulting that standard is mandatory when creating a GitHub issue, not for every task.