Milestones and Labels

Current product outcomes and migration dispositions are indexed in Product roadmap. level:epic marks an outcome container with native sub-issues; do not count parent and child as separate delivery. DRAFT-M0–M7 remain open. MIG-1/2/4 are closed for scoped technical delivery; MIG-3 is superseded and MIG-5 deferred, not passed. MIG-0 remains open.

Milestones and labels

Milestones identify migration gates. Project Status shows delivery state, Priority shows urgency, and Acceptance records a separate decision. Do not duplicate those fields with phase, status, or priority labels.

Migration milestones

Milestone	Included work	Completion boundary
MIG-0 Preservation verified	M0 — Preservation	Source, history, tags, signatures, WIP, links, and preserved evidence have an inventory and verified preservation records.
MIG-1 Signed import and governance	M1 — Signed bootstrap; M2 — Snapshot import	The new repository has its own signed baseline and the approved source snapshots are imported with explicit provenance.
MIG-2 Unified CI and canonical docs	M3 — CI; M4 — Canonical documentation	Required checks operate on the new repository; current documentation ownership and preserved links are reconciled.
MIG-3 SDK and distribution verified	M5 — SDK release	Versioned SDK artifacts and their isolated consumer checks satisfy the defined release scope.
MIG-4 Cutover and legacy archives	M6 — Cutover and archive; T1	The source-of-truth cutover is accepted; old Platform/Solutions repositories are archived only after all preservation and cutover gates pass.
MIG-5 Identity-aware layout	M7 — Layout transition; T2	The subsequent internal layout transition passes its separate identity, compatibility, and qualification gates.

M8 — Follow-up boundary improvements continues after this migration sequence without a fixed migration milestone. It does not silently expand MIG-5 into a redesign of the application engine, storage semantics, or all extension APIs.

Milestones start open with no due date. Their order expresses dependencies, not promised delivery dates. T1 is the repository cutover checkpoint; T2 is the later layout checkpoint. A successful T1 does not imply T2 has completed.

Priority

Priority	Meaning
P0	Immediate preservation, integrity, or continuity risk; interrupts planned migration work.
P1	Required to pass the next migration gate or unblock its critical dependency.
P2	Planned work that is useful but does not currently block the next gate.
P3	Deferred improvement, exploration, or follow-up with no current gate dependency.

Priority does not authorize a destructive action or bypass a check. A blocked P0 item still records the required decision or dependency.

Type labels — exactly one

Label	Use
bug	A demonstrated behavior that violates the expected contract.
enhancement	A new or expanded supported capability.
documentation	Documentation content or navigation as the primary output.
question	A bounded question requiring an answer or decision.
type:refactor	Internal restructuring with explicit behavior and identity impact checks.
type:maintenance	Repository, dependency, configuration, or delivery upkeep.
type:verification	Producing or independently checking evidence against stated claims.

Area labels — one or two

Label	Scope
area:core	Authority, durable state, admission, uncertainty, and recovery.
area:contracts	Normative contracts, schemas, bindings, and compatibility.
area:sdk	Consumer APIs, generated libraries, templates, and SDK artifacts.
area:adapters	Device/native integration and extension interfaces.
area:workflows	Process authoring, compilation, and execution packages.
area:operator	Operator applications and their user-facing flows.
area:distribution	Installers, images, package sets, and release assembly.
area:governance	Contribution policy, CI enforcement, and repository administration.
area:evidence	Provenance, preservation, acceptance records, and evidence indexing.

Optional gate and risk labels

• risk:identity — The change may affect contract, compiler, validator, driver, package, artifact, or stored-operation identity. The issue must name the affected identities and required checks.
• gate:acceptance — An explicit maintainer acceptance checkpoint applies. Set Acceptance to Pending until the decision is recorded, and retain the label after acceptance for traceability.

These 18 labels are the managed vocabulary. Existing auxiliary defaults such as duplicate, good first issue, help wanted, invalid, and wontfix may remain; they do not replace the required type label. Keeping a label available is not a statement that a migration item is suitable for a new contributor.

Product sprints — 2026-10-07

DRAFT-M0 through DRAFT-M7 are product acceptance milestones defined by docs/48_draft_product_milestones.md; MIG-* retains migration meaning. Never transfer migration completion into product acceptance.

The Project's Sprint iteration field has a three-day cadence. Sprint 1 (October 7–9) contains only DRAFT-M0–M1 issues #13–#18. Future product work and issues #10–#12 remain unscheduled backlog. Iteration dates are planning windows, not milestone due dates, release commitments or expanded authorization.

Use Size XS/S/M/L/XL for provisional relative complexity and uncertainty. Split L/XL before Ready. Keep Priority in the existing P0–P3 field, Status in the existing workflow field and Acceptance separate. Do not introduce duplicate sprint/status/priority labels. By Ready, retain one type label, one or two area labels, an owner, milestone and explicit acceptance criteria.

See Project workflow and the Sprint planning view for WIP, review, retrospective and carryover rules.

Hierarchy is separate from work type

Use exactly one hierarchy label on current product work: level:goal, level:epic, or level:task. These do not replace bug/enhancement/type:* labels. A Task may be an enhancement, bug, verification or maintenance change. An Epic groups Tasks; a Milestone marks acceptance; a Sprint schedules Tasks. The product goal is #25. See Product roadmap for the live hierarchy and role definitions.