Expand description
The POST /v1/issues dispatcher — see enhance::EnhanceApplication.
EnhanceApplication — the dispatcher for the POST /v1/issues
path.
The entry point (POST /v1/issues) only does IssueStore.create —
a synchronous enqueue. The actual dispatch is drained by a
consumer loop calling tick():
POST /v1/issues ──→ IssueStore (queue)
↓
consumer loop (tokio::spawn) ── tick() ──┐
↓
IssueStore.pop_pending + EnhanceSettingStore.get
↓
BPStore.read_head(setting.blueprint.id) (fetched on use)
↓
TaskLaunchService.launch(...) (engine bind + attach + start_task)Current scope:
- Engine task-completion →
Issue.update_statusis a carry. - Setting
VersionSelector(Fixed/Latest/SemverReq) is a carry — today we always useBPStore.read_head. - The agent-selection convention is
setting.blueprint.agents.first().name.
Structs§
- Enhance
Application - The
POST /v1/issuesdispatcher — enqueues viaApplication::handle, drains viaEnhanceApplication::tick/EnhanceApplication::run_forever. - Enhance
Application Config - Configuration parameters for
EnhanceApplication. - Enhance
Application Input - Input to
EnhanceApplication::handle— thePOST /v1/issuesrequest body once decoded. - Tick
Outcome - Result of a single
tick.task_idis gone — the flow-eval path runs many steps to completion instead of being tied to a single task id, so the entirefinal_ctxis the result. Outcomes are checked throughstatus.
Enums§
- Enhance
Application Error - Failure modes of
EnhanceApplication::tickand the internaldispatch_onestep it wraps.