Assistant: codex Assistant-Model: gpt-5.6-sol Assistant-Session: 01a028de-e2c8-7732-8521-46a7fc5db82f
2.8 KiB
| id | type | title | updated |
|---|---|---|---|
| ACTIVITY-WP-0029-T04 | contract | Execution queue boundary | 2026-08-18 |
Execution queue boundary
Replaces State Hub /execution/* as the place callers look for when work
should fire. It does not move workplan files, task lifecycle, or ITC
Task Model types into activity-core.
What activity-core owns
| Surface | Meaning |
|---|---|
Temporal Schedule + POST /activity-definitions/{id}/trigger |
When an ActivityDefinition fires |
POST /ops-runs/claim and complete/fail/heartbeat |
Claimable ops run for that fire (ACT-ADR-005) |
GET /execution/semantics |
This contract |
port.schedule (hub-extension 0.1) is the hub-core outbound port that
asks activity-core to wake a schedule or accept a launch of an
ActivityDefinition. activity-core implements the receiving side.
What activity-core does not own
| Concern | Owner |
|---|---|
| Workplan / task files and their status | The repo (ADR-001) |
| Work-record index and C-rule consistency | repo-manager (port.work) |
| Task / Commitment / TaskState vocabulary | info-tech-canon Task Model |
| Assign / track / close a development task | issue-core / work records |
| Policy publication | policy-nexus |
Workplan execution_state rows on State Hub |
retiring; do not re-home as hub tables here |
A workplan being active is a lifecycle fact in the repo file. An
ops_run being open is an automation fire. Those are different planes
(ACT-ADR-005). Mapping State Hub POST /execution/launch-requests onto
“create a workplan execution row here” would collapse them again.
The bounded-operation registry in ACT-ADR-007 is a separate, code-reviewed
maintenance exception. It neither consumes this queue nor turns an ops_run
into a workplan task.
Replacement for State Hub routes
| State Hub route | Replacement |
|---|---|
GET /execution/semantics |
GET /execution/semantics on activity-core (this contract) |
POST /execution/launch-requests (workplan) |
Do not send here. Queue the workplan in the repo file; use an ActivityDefinition + ops_run if the work is a recurring/ops fire |
GET /execution/launch-requests |
GET /ops-runs |
GET /execution/workplan-stack |
repo-manager work index / hub-core projection — not this API |
PATCH /execution/workplans/{id}/intent |
Edit the workplan file; repo-manager indexes it |
Callers that still hit /execution/* on activity-core for workplan ids get
410 with replacement_ref pointing at the table above.
Semantics payload
GET /execution/semantics returns:
activity_core_owns— schedules, triggers, ops_run claim/completeactivity_core_does_not_own— workplan files, task lifecycle, C-rulesreplacements— map from retired State Hub paths to current surfacesport—port.schedule(consume; do not invent the hub-core side here)