generated from coulomb/repo-seed
181 lines
6.1 KiB
Markdown
181 lines
6.1 KiB
Markdown
---
|
|
id: STATE-WP-0049
|
|
type: workplan
|
|
title: "Workplan Execution Queue and Activity-Core Handoff"
|
|
domain: custodian
|
|
repo: state-hub
|
|
status: finished
|
|
owner: codex
|
|
topic_slug: custodian
|
|
planning_priority: medium
|
|
planning_order: 49
|
|
created: "2026-05-23"
|
|
updated: "2026-05-23"
|
|
state_hub_workstream_id: "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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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
|
|
|
|
```task
|
|
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.
|