activity-core/docs/execution-queue-boundary.md

63 lines
2.7 KiB
Markdown
Raw Normal View History

---
id: ACTIVITY-WP-0029-T04
type: contract
title: Execution queue boundary
updated: "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.
## 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/complete
- `activity_core_does_not_own` — workplan files, task lifecycle, C-rules
- `replacements` — map from retired State Hub paths to current surfaces
- `port``port.schedule` (consume; do not invent the hub-core side here)