---
id: STATE-WP-0049
type: workplan
title: "Workplan Execution Queue and Activity-Core Handoff"
domain: infotech
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.
