6.1 KiB
id, type, title, domain, repo, status, owner, topic_slug, planning_priority, planning_order, created, updated, state_hub_workstream_id
| id | type | title | domain | repo | status | owner | topic_slug | planning_priority | planning_order | created | updated | state_hub_workstream_id |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| STATE-WP-0049 | workplan | Workplan Execution Queue and Activity-Core Handoff | custodian | state-hub | finished | codex | custodian | medium | 49 | 2026-05-23 | 2026-05-23 | dd06578f-20b3-4473-bab3-8810eae29f39 |
STATE-WP-0049 - Workplan Execution Queue and Activity-Core Handoff
Goal
Create a controlled way to prioritize, sequence, parallelize, and schedule ready/active workplans, while keeping State Hub responsible for observable state and leaving autonomous execution orchestration ready to move to activity-core.
Context
Changing a workplan from proposed to active can mean several different
things: start coding now, put it at the top of a queue, run in parallel with
other work, or wait for a human-selected launch window. State Hub should model
that intent cleanly without becoming an unbounded task factory.
The likely long-term split is: State Hub stores and exposes queue state, priorities, dependencies, and handoff records; activity-core owns schedules, automations, and agent dispatch.
T01 - Define Queue Semantics
id: STATE-WP-0049-T01
status: done
priority: high
state_hub_task_id: "b69e3c7d-46be-4e88-b039-7aa82d653b53"
Define execution queue states, ordering fields, concurrency hints, and launch modes for workplans. Include at least manual, queued, scheduled, immediate, sequential, and parallel intent.
Done when queue semantics are documented without overloading lifecycle status.
Result 2026-05-23: added execution semantics for manual, queued,
scheduled, launching, paused, completed, and cancelled execution
states; manual, queued, scheduled, and immediate launch modes; and
sequential/parallel concurrency modes. The /execution/semantics endpoint
exposes the vocabulary and boundary notes.
T02 - Separate Lifecycle From Execution Intent
id: STATE-WP-0049-T02
status: done
priority: high
state_hub_task_id: "4f48b4d4-7232-4e36-b4a2-03aaef684ab4"
Design schema/API changes so status remains the canonical lifecycle field and
execution intent lives in separate planning/execution fields.
Done when active no longer has to imply "dispatch a coding agent right now."
Result 2026-05-23: added separate execution intent fields on workstreams:
execution_state, launch_mode, concurrency_mode, queue_rank,
execution_group, and scheduled_for. Lifecycle status remains unchanged
when execution intent is updated.
T03 - Add Prioritized Workplan Stack
id: STATE-WP-0049-T03
status: done
priority: high
state_hub_task_id: "9237b778-4c83-4ebe-942e-79bae29aaa45"
Implement a prioritized stack or queue view for candidate workplans using planning priority, planning order, dependencies, readiness, blockers, and optional concurrency grouping.
Done when a human can choose what starts next from a clear ordered list.
Result 2026-05-23: added /execution/workplan-stack, a dependency-aware
ordered queue view using execution state, planning priority, queue rank,
planning order, lifecycle status, and workstream/task blockers.
T04 - Add Launch Request Records
id: STATE-WP-0049-T04
status: done
priority: medium
state_hub_task_id: "a8366495-fd66-436e-b423-e24c3ffadbc9"
Introduce a durable launch-request or handoff record for "please start this workplan" events, including requested actor, mode, priority, repo, branch preference, and whether immediate agent pickup is desired.
Done when UI/API actions can request implementation without losing intent in a plain status patch.
Result 2026-05-23: added durable workplan_launch_requests records and
POST /execution/launch-requests. Launch requests capture requested actor,
mode, priority, repo, branch preference, immediate pickup, notes, and metadata
while updating execution intent separately from lifecycle status.
T05 - Define Activity-Core Boundary
id: STATE-WP-0049-T05
status: done
priority: high
state_hub_task_id: "2ebf5186-9a92-476a-ac62-3588cc51fb31"
Document which responsibilities belong in State Hub and which should move to activity-core. State Hub should expose state and requests; activity-core should own scheduling, wakeups, and agent dispatch when available.
Done when the boundary is explicit enough that implementation can proceed in State Hub now without trapping orchestration there permanently.
Result 2026-05-23: the execution semantics service defines State Hub as the state, ranking, and durable handoff owner, while activity-core owns schedules, wakeups, agent dispatch, and request execution once available.
T06 - Dashboard Controls
id: STATE-WP-0049-T06
status: done
priority: medium
state_hub_task_id: "7d1c9ec7-8130-4f26-92ae-754c6f28ea48"
Add dashboard controls for queue ordering, launch mode, parallel/sequential intent, and manual versus immediate pickup.
Done when a user can move a workplan into the queue without accidentally starting work, or explicitly request immediate pickup when desired.
Result 2026-05-23: added the dashboard Workplan Queue page with queue rank, launch mode, sequential/parallel intent, execution group, save, and request controls. Workstreams link to the queue page.
T07 - Handoff And Scheduling Tests
id: STATE-WP-0049-T07
status: done
priority: medium
state_hub_task_id: "f819907b-0409-411e-82d1-564c2d543f86"
Add tests for queue ordering, launch-request creation, dependency-aware eligibility, and the State Hub/activity-core boundary contract.
Done when execution intent can evolve without contaminating lifecycle state.
Result 2026-05-23: added API tests for semantics, execution-intent updates, dependency-aware queue ordering, and launch-request creation. The tests pin that lifecycle status remains separate from execution intent.
Acceptance Criteria
- Workplan lifecycle status is separate from execution intent.
- A prioritized workplan stack supports sequential and parallel pickup.
- UI/API actions can request immediate or deferred work explicitly.
- State Hub remains the state and handoff layer; activity-core remains the natural owner for scheduling and agent dispatch.