Project Workflow

Project workflow

Use RobotTransformation — Sprints to track a concrete result, its dependencies, verification, and any required maintainer acceptance. The issue holds the work record; the project provides its current delivery state.

Item contents

Each actionable issue states the problem, bounded scope, expected output, dependencies, completion checks, and preservation constraints. Record the current source revision and link any relevant historical evidence. Add an assignee when work starts. A dependency is resolved by its stated result, not just by closing its issue.

By Ready, a work item has exactly one type label, one or two area labels, a priority, and an acceptance value. Pull requests meet the same label rules before review. Migration work also has one milestone. Use Milestones and labels for the vocabulary.

Status

Status	Meaning and transition condition
Backlog	Recorded work that has not met the entry conditions for execution.
Ready	Scope, dependencies, owner, and completion checks are clear; required inputs are available.
In progress	An assigned contributor is actively producing the scoped output.
Review	A concrete output and its verification record are available for review. Acceptance may still be pending.
Blocked	A named dependency, failure, or decision prevents the next required action. Record the unblock condition and owner.
Done	The scoped output is delivered, required checks pass, and any required acceptance is recorded as Accepted.

A failed check returns work to In progress when the assignee can fix it, or Blocked when an external dependency or decision is required. Rejected acceptance does not become Done. Reopen a Done item if new evidence invalidates its completion claim, retaining its earlier result and reason for reopening.

New items start as Backlog / P2 / Pending. Triage may adjust priority and may set Not required only after documenting why no separate acceptance checkpoint applies.

Acceptance field

Value	Use
Not required	No separate maintainer acceptance checkpoint applies to this task. Ordinary review and verification still apply.
Pending	A required acceptance decision has not been made.
Accepted	The authorized maintainer explicitly accepted the named output and scope; link that decision.
Rejected	The maintainer did not accept the submitted output. Preserve the rejection and its evidence.

Use gate:acceptance when this separate checkpoint applies and retain the label after the decision for traceability. If the checkpoint is removed, record the rationale and update both the label and Acceptance field. Acceptance and Status are different fields: completing a build or merging a PR does not automatically change Acceptance. An agent's precheck cannot accept a task on the maintainer's behalf. Do not automatically mark Accepted or Done when a PR merges, CI passes, or an issue closes. Acceptance applies to its named revision or artifact; a new identity does not inherit an earlier acceptance, and an earlier rejection remains recorded.

Source contribution path

After the signed bootstrap and snapshot-import gates establish the repository baseline, product changes use the repository's GitFlow and checked PR route. New commits retain truthful author DCO signoffs and verified signatures. Required source-repository checks apply to the exact proposed head. Release or cutover work additionally meets its issue's explicit gates.

Before closing an issue, link the delivered commit or artifact, summarize checks actually run and their environment, identify unverified scope, and record required acceptance. A planning issue can be Done when its approved planning output is delivered; this does not mark the implementation it describes as complete.

GitHub Wiki is a separate repository. A wiki commit does not satisfy the source repository's PR, DCO, signature, CI, release, or acceptance checks. Wiki changes may improve guidance but cannot revise product contracts or certify implementation.

Project views

View	Purpose
Current sprint	Current iteration only, grouped by Status.
Sprint planning	Product work grouped by Sprint; assign owner, Priority, Size and milestone.
Product backlog	Product issues with no Sprint, awaiting refinement and scheduling.
Acceptance queue	Review items with Pending or Rejected acceptance.
Product roadmap	Native timeline grouped by milestone; only assigned Sprint dates are plotted.
Migration history	Preserved MIG work, separate from product sprints.

Views present the same items. Do not create duplicate issues for another view. Automatic acceptance and automatic archival remain disabled.

Daily use

1. Select Ready work whose dependencies are satisfied.
2. Set In progress and keep edits inside the issue's scope.
3. Attach the reviewable output and measured verification; move to Review.
4. Resolve review findings and obtain acceptance when required.
5. Move to Done only when the issue's own completion conditions are met.

Preserve incomplete, failed, and rejected attempts. Do not manufacture a passing result by replacing a held operation or changing the accepted scope without recording the decision.

Three-day sprint policy — 2026-10-07

Three-day planning cadence; accountable owner: jack0682. Sprint dates are planning windows, not release deadlines or authorization to expand scope.

Sprint 1: October 7–9, 2026

DRAFT-M0–M1 only: select/configure/save/reopen the material alignment and regrasp Task, execute through the existing RX simulation runtime, and inspect results on the same graph. Issues #13–#18 form this sprint. M2+ remains uncommitted backlog. A three-day window does not postpone the requested overnight technical handoff.

Views

• Current sprint: sprint:@current, grouped by Status.
• Sprint planning: executable product tasks, grouped by Sprint; assign scope, owner, Priority and Size.
• Product backlog: product issues without a Sprint.
• Acceptance queue: Review items with Pending/Rejected acceptance.
• Product roadmap: grouped by milestone; only assigned Sprint dates are plotted. Future dates remain unset.
• Migration history: preserved migration work.

Workflow and WIP

Backlog → Ready → In progress → Review → Done. Blocked requires a concrete dependency and unblock condition. Keep at most two implementation items and one integration/verification item In progress. Record executing agent, host, exact source revision and evidence separately from the human owner.

Ready: user outcome, bounded scope, dependencies, test criteria and authorized environment are clear. Split L/XL work before Ready. Done: implementation, applicable checks, evidence and handoff are complete; required owner acceptance is explicit. Merge/CI does not imply acceptance. USER_ACCEPTANCE_PENDING stays Review / Acceptance Pending. Never use issue closure to imply CP2 acceptance.

Planning fields

Priority: P0 active integrity/custody/security incident; P1 blocks the agreed sprint outcome; P2 normal planned work; P3 optional. Size: XS/S/M/L/XL, provisional relative complexity and uncertainty, not hours. Milestone is the acceptance outcome; Sprint is the planning window. Current six items: P1, five M and one S. Future scope stays unscheduled until refined and authorized.

Three-day routine

Plan: select authorized work, state a sprint goal and assign Sprint/owner/size. Daily: record evidence, blocker and next action. Review: demonstrate the actual user workflow and negative cases. Retrospective: record one improvement and carry unfinished work explicitly. Do not invent velocity before completed sprint data exists.

Automation

New/updated open repository issues flow into this project and new items start in Backlog. Sprint assignment, owner acceptance and completion are deliberate. Auto-close, Done-on-close, Done-on-merge and auto-archive remain off.

Preserved work

PR #6 is Blocked/parked reference for #12. Issues #10–#12 start from current develop when scheduled; selectively reuse reviewed code with exact commit provenance. Do not merge the stale M5 governance overlay. Preserved Mac: no product build/test, Docker operations or product server. Use isolated Linux. Preserve original CP2 IDs, UNKNOWN and resource custody. No replay-to-green, relaxed deadlines/authority/completion, or canned UI success. No M2+, official release or physical operation authorized by board setup.

Sources: docs/48_draft_product_milestones.md and docs/implementation/draft_m0_m1_execution_plan.md. Repository · Workflow guide · Milestones and labels

Goal, Epic and Task

The final goal is recorded in #25 and Project README. Use native Goal → Epic → Task relationships, with level:* labels distinct from work type. Keep the parent outcome out of sprint estimates and delivery counts. Milestones are acceptance checkpoints, not hierarchy levels; Sprint planning contains executable tasks. Goals & epics and Product roadmap expose the larger purpose.

Keep tracking current — ongoing owner instruction (2026-10-07)

Project synchronization is part of every work session and handoff. Before starting, reuse the existing task and confirm its parent, owner, scope and planned Sprint. At start, record the executing agent/host and branch. At meaningful progress or failure, link exact source/PR, actual checks, negative results, limits and next action. Mark Blocked only with a concrete dependency and unblock condition. At handoff, reconcile the issue, PR and Project to the same actual state.

Review means a concrete candidate and evidence are available, not that it is merged or accepted. Required owner acceptance stays Pending; no automatic Done/Accepted on CI or merge. Record carryover explicitly, preserve original IDs/evidence and update parent Epic/milestone only against their own criteria. Never change another active task's state without checking current evidence.

If a connector lacks Project permission, use the authorized GitHub UI. If updates cannot be applied, record the exact pending fields on the issue/PR and report the gap; never silently claim synchronization or broaden credentials. The issue holds scope/evidence, the PR holds source changes and the Project summarizes their state.

Repository Projects already links to Project 10. Goal #25 is pinned in Issues. PR #40 proposes durable README/CONTRIBUTING/PR-template counterparts; it is not claimed merged by this policy update. See tracking task #39.