Lane priority admission

Lane WIP limits normally admit work purely on arrival order, with no notion of priority: a P0 fix can queue indefinitely behind ordinary-priority work already holding a lane’s WIP slots. Priority admission (WU-3546) is the policy that lets a qualifying priority displace the lane’s single lowest-priority active claim instead of waiting — but only when a caller explicitly turns it on.

Caution

Priority admission ships disabled by default. Strict, arrival-order WIP enforcement is unchanged unless a caller passes priorityAdmission: { enabled: true } to the scheduler. There is no workspace.yaml key for this yet — it is a constructor option on TaskScheduler, consumed programmatically, opt-in end to end.

Enabling it

import { TaskScheduler } from '@lumenflow/runtime';

const scheduler = new TaskScheduler({
  lifecycleAuthority,
  taskSpecLoader,
  laneWipLimits: { 'Framework: Core Lifecycle': 2 },
  priorityAdmission: {
    enabled: true, // default: false -- conservative, byte-identical to pre-WU-3546 behaviour
    overridePriorities: ['P0', 'P1'], // default when enabled and omitted
  },
});

overridePriorities defaults to ['P0', 'P1']: only those priorities may ever trigger a displacement, and only when enabled is explicitly true.

What displacement does — and never does

When a qualifying candidate arrives at a lane that is at its WIP limit, the scheduler selects the single lowest-priority active claim in that lane and displaces it via the same scheduler_task_released event kind used for a voluntary release. The event’s reason names both the displaced task and the admitting task, plus the deciding policy name (priority-wip-override-v1), so the event doubles as the auditable record and the coordination signal delivered to the displaced owner.

Displacement is never destructive:

• The displaced claim is released, not cancelled — it remains claimable again once lane capacity allows.
• This layer never touches worktrees, commits, or filesystem state, so it cannot discard in-flight work it has no access to.
• Ordinary-priority admission behaviour is completely unchanged when no high-priority work is waiting, or when the policy is left at its default (enabled: false).

Why this exists

During INIT-091 wave 0, a P0 trunk-corrupting defect sat in status ready and undispatchable for hours because its lane was at its WIP limit, held by two ordinary-priority WUs from unrelated initiatives. The only available remedies were manual: raise the lane’s WIP limit by hand in shared workspace.yaml, or preempt another session’s claim directly — neither safe for an agent to do autonomously. Priority admission gives lane admission a priority dimension so that emergency-priority work has a governed, audited path around a WIP ceiling, without a human editing shared config under pressure.

Related

• Capacity + integrity — the broader capacity and contamination/stall detectors this admission policy sits alongside.
• Lanes — the WIP=1 lane model this policy adds a priority override to.