# Initiative Brief: Deferred Work and Roadmap Lifecycle ## Motivation Large initiatives often reveal additional work that should not be completed within the current initiative. Common reasons include: * The work is outside the initiative brief. * The current effort intentionally establishes only a scaffold or foundation. * Further implementation should wait until the scaffold has been exercised. * Product or architectural direction is required before proceeding. * The work is valid but would create inappropriate scope expansion. Orchestrator can currently identify and defer such work, including a rationale and checkpoint for revisiting it. However, deferred planning items remain unresolved and can prevent an initiative from reaching `COMPLETED` even after assessment has determined that all brief criteria were delivered. The current escape mechanisms do not accurately represent the situation: * Force-closing effectively records valid future work as waived. * Retracting implies that the item should no longer be considered valid. * Leaving planning open causes an otherwise delivered initiative to remain indefinitely in an executing state. At the same time, simply discarding the information loses valuable knowledge about future capabilities, partial scaffolding, architectural intent, and the conditions under which further work should be reconsidered. Orchestrator needs a durable lifecycle for this information. --- ## Constraints - Do not redesign the entire Orchestrator planning model unless required to support this lifecycle. - Do not introduce a separate unrelated project-management system. - Reuse existing initiative, planner, assessment, repository, workspace, and persistence abstractions where sensible. - Preserve existing force-close, retract, or waiver functionality where it remains semantically useful. - Do not make all roadmap items mandatory scope for future initiatives. - Do not require completion of deferred roadmap work before an originating initiative can complete. - Do not duplicate a single cross-repository roadmap concern into multiple repository records solely because multiple repos are affected. - Avoid destructive migration of existing planning or initiative history. - Prefer backward-compatible evolution of existing state where practical. --- ## Expected behavior - Establish a Durable Roadmap Model — Orchestrator must support a durable representation of anticipated future work. The initial storage implementation may be Markdown-backed if that is the most appropriate fit with the existing repository/planning architecture, but roadmap items must be represented with enough structure that Orchestrator can reliably identify, reconcile, and update individual entries. Each roadmap item should have a stable identity. At minimum, preserve: - stable roadmap item ID - title - current status - description or intended capability - reason it was deferred or recorded - origin/provenance - relevant repository, workspace, or platform scope - checkpoint or conditions under which the work should be revisited - any known existing scaffold or partial implementation - related capabilities/components where known - creation/update history sufficient for reconciliation - relationship to a later initiative if promoted into implementation Do not reduce roadmap entries to unstructured TODO bullets. --- - Support Multiple Roadmap Scopes — Do not assume that every roadmap item belongs exclusively to one repository. Orchestrator initiatives frequently span multiple repositories and platform concerns. The roadmap model must allow an item to be associated with an appropriate ownership scope, such as: ```text repository workspace platform ``` Equivalent terminology is acceptable if another abstraction already exists in Orchestrator. A repository-specific capability may live with that repository. A cross-repository workspace or platform capability should not need to be duplicated into several repo roadmaps merely to satisfy repository ownership. The planner should determine the most appropriate available scope based on the architecture and affected components. --- - Make `DEFERRED` a Valid Planning Disposition — A valid deferred item must no longer block initiative completion once it has been durably captured. The semantics should distinguish at least: Deferred — The work is considered legitimate future work but is intentionally outside the current initiative. It remains active in roadmap state. Waived — The work has consciously been determined not to be required or pursued. Waiving should not be used merely because an item is outside the current initiative. Retracted / Withdrawn — The deferred/planned item itself is no longer considered valid, was created incorrectly, or should otherwise cease to exist as anticipated work. Exact status names may align with existing Orchestrator terminology, but these meanings must remain distinct. --- - Add a "Defer and File" Lifecycle — Provide a normal completion path whereby an initiative's deferred item can be: - classified as legitimate follow-on work; - associated with the appropriate roadmap scope; - created or reconciled against an existing roadmap item; - recorded with its rationale and checkpoint; - marked durably captured for the originating initiative; and - treated as resolved for purposes of closing current planning. Once all non-delivered planning items have valid terminal dispositions for the current initiative, planning must be closable. An initiative that has received a delivered assessment should therefore be capable of reaching `COMPLETED` while roadmap items originating from it remain active future work. This should not require a force-close. --- - Preserve Initiative Provenance — Do not remove or overwrite deferred-work evidence from the initiative after it has been filed into the roadmap. The system should support both questions: - What future work is currently anticipated? - What work did this particular initiative discover and defer? The initiative should retain enough information to identify: - the original deferred item; - its rationale; - its checkpoint; - the roadmap item to which it was filed or reconciled; and - its final disposition within the initiative. The roadmap should reciprocally record the originating initiative where applicable. --- - Consult Roadmap State During Planning — Relevant roadmap state must become an input to planning new initiatives. The planner should inspect roadmap items whose scope or capability appears relevant to the initiative being planned. The roadmap is not merely archival. However, roadmap consultation must not cause automatic scope expansion. The planner should reason about each relevant item and determine whether it is: - incorporated into the new initiative; - partially incorporated; - still deferred; - adjacent but outside scope; - superseded by the initiative's proposed architecture; - already satisfied by existing implementation; or - unrelated after closer inspection. A roadmap item's existence alone must not make it a requirement of a new initiative. --- - Record Roadmap Reconciliation During Planning — Planning should provide evidence that relevant known roadmap items were considered. A planning artifact or equivalent structured state should be able to express reconciliation such as: ```text RM-014 — Deeper suggestedActivities semantics Relevant: yes Disposition: incorporated Reason: this initiative now defines activity-driven Composer behavior RM-021 — Confirmation policy management UI Relevant: adjacent Disposition: remains deferred Reason: administrative policy surfaces remain outside this initiative ``` Exact presentation is implementation-dependent. The key requirement is that roadmap consideration and disposition must be inspectable rather than occurring as invisible planner behavior. --- - Prevent Duplicate Roadmap Items — Roadmap filing and future planning must reconcile against existing roadmap state before creating new entries. If Orchestrator rediscovers substantially the same future capability, it should prefer updating or linking to the existing item rather than creating another independent entry. Stable IDs should make exact relationships explicit once established. Semantic matching may be used to identify likely duplicates where no explicit relationship exists, but Orchestrator should preserve distinctions when similar-looking items represent genuinely separate concerns. --- - Support Promotion Into Future Initiatives — When a future initiative intentionally takes on a roadmap item, establish a durable relationship between them. For example: ```text roadmap item: status: planned promoted_to: <initiative-id> ``` Equivalent representation is acceptable. The new initiative should know that the capability originated as known roadmap work. Promotion should not erase the roadmap record. --- - Reconcile Roadmap State During and After Delivery — Roadmap maintenance must not stop when an item is incorporated into an initiative. When implementation or assessment establishes that roadmap work has been completed, superseded, or otherwise resolved, update its roadmap status accordingly. Useful states may include concepts such as: - candidate / deferred - planned - in progress - delivered - superseded - withdrawn / no longer relevant Do not introduce unnecessary workflow complexity merely to support a large status vocabulary. Use the smallest state model that accurately represents the lifecycle. What matters is that stale roadmap entries do not remain indefinitely presented as anticipated future work after reality has changed. --- - Preserve Revisit Checkpoints — The checkpoint or trigger for reconsidering deferred work is important planning information and should be treated as first-class data. Examples: - evidence of stable usage of the current scaffold; - an operator decision; - product direction on interaction semantics; - completion of a prerequisite capability; - observed demand or usage behavior. Prefer a concrete `revisit_when`, `checkpoint`, or equivalent field over generic language such as "do later." The planner should retain checkpoints when filing deferred items and consider them when evaluating roadmap relevance in future initiatives. --- - Preserve Existing Scaffold Information — Where follow-on work has already been partially scaffolded, stubbed, contracted, or otherwise represented in the current implementation, record that information with the roadmap item when reasonably available. For example: ```text Existing scaffold: - suggestedActivities exists in the workspace contract. - Current implementation supports basic landing behavior. - Parameterized activity semantics are not defined. ``` This information should help future planning avoid rediscovering implementation history through repository archaeology. Do not require exhaustive code analysis merely to file a roadmap item. --- - Keep the Roadmap Focused — The roadmap should represent meaningful anticipated product, capability, architecture, or implementation work. It should not become a general dumping ground for: - trivial cleanup; - minor cosmetic defects; - incidental TODOs; - temporary debugging notes; - implementation details already adequately represented by current initiative tasks. The planner should use reasonable judgment about whether an item represents meaningful future work worthy of durable roadmap memory. Existing issue/defect/task mechanisms should continue to handle concerns better suited to those systems. ---