Module enhance 

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)
                      the drain stops waiting on this after
                      EnhanceSetting.ttl_secs                  (see the ceiling block below)

One tick is one epoch. EnhanceSetting.ttl_secs is not a ceiling on that epoch: it is a ceiling on how long the drain waits for one call — TaskLaunchService::launch — and nothing else. Two consequences, both load-bearing, both spelled out in the ceiling block in EnhanceApplication::dispatch_one:

• It bounds the wait, which is the thing it was built to bound. The knob exists so the Swarm can give up on an Operator that stopped answering (model §4.4 R5 places the bound in infra, not in the model), and that wait is an await point, so dropping the launch future releases it. It does not stop a worker already running in an in-process lane: those run in tokio::spawned tasks that this future does not own, and nothing in this repository fires the CancellationToken they select on. The drain is unwedged either way; the work may still be running behind it, which is what the reason text tells the operator to check before re-posting.
• It does not span the epoch. The store calls on either side of launch — setting_store.get, resolve_blueprint, bp_store.read_head, bp_store.write_new, log_store.append, and issue_store.update_status in both tick arms — are outside it and are bounded by nothing.

So the ceiling removes exactly one wedge — a patch-spawner whose call never returns — and leaves every other way to stall the single-threaded drain in place.

Current scope:

• Engine task-completion → Issue.update_status is a carry.
• Setting VersionSelector (Fixed / Latest / SemverReq) is a carry — today we always use BPStore.read_head.
• The agent-selection convention is setting.blueprint.agents.first().name.

Structs

EnhanceApplication

The POST /v1/issues dispatcher — enqueues via Application::handle, drains via EnhanceApplication::tick / EnhanceApplication::run_forever.

EnhanceApplicationConfig

Configuration parameters for EnhanceApplication.

EnhanceApplicationInput

Input to EnhanceApplication::handle — the POST /v1/issues request body once decoded.

TickOutcome

Result of a single tick. task_id is gone — the flow-eval path runs many steps to completion instead of being tied to a single task id, so the entire final_ctx is the result. Outcomes are checked through status.

Enums

EnhanceApplicationError

Failure modes of EnhanceApplication::tick and the internal dispatch_one step it wraps.