Make scheduler concurrency adaptive instead of fixed-only

[iKwesi]

Problem

The scheduler currently uses conservative fixed concurrency defaults, including a low max_concurrent_tasks ceiling. That is safe, but it does not yet adapt based on actual overlap risk, touch-set confidence, or task isolation quality.

Why it matters

A system that claims disciplined orchestration should be able to raise or lower concurrency based on evidence instead of relying only on a fixed bootstrap ceiling.

Proposed solution

Add adaptive concurrency policy for the conservative scheduler.

The scheduler should be able to scale concurrency based on signals such as:

• touch-set overlap confidence
• uncertainty level
• shared mutable asset detection
• artifact/contract isolation quality
• historical evidence that a task class is safe to batch

Acceptance criteria

• Scheduler policy can vary concurrency based on evidence-backed safety signals.
• Unsafe or uncertain task groups still serialize conservatively.
• Resulting batch decisions remain deterministic and explainable.
• The policy contract documents how adaptive concurrency interacts with existing max_concurrent_tasks defaults.

Related phase

Future / Research

Related subsystem/component

scheduler / execution policy

Related artifacts or commands

scheduler; policy config; buildContextPack; task execution batches