Pull-Based Kanban Orchestration

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Two workers share catalog batches. Teaching T1 has passed prerequisites/acceptance, T2 is blocked. Reading then writing owner separately lets both claim T1. Actual atomic claiming is needed, not a Markdown promise.

Mechanism

Define ready and use concurrent-safe state/revision/owner claiming in one operation. Only successful owners edit assigned scope. No ready work means wait, not skip dependencies. Release/handoff with actual result and current ownership; verified completion alone satisfies downstream gates.

Bad example

Both edit T1 after separate reads, and take blocked T2 without prerequisite/owner-revision checks.

Good example

Atomically claim teaching T1 only when ready and revision matches. The winning owner edits assigned files; another selects other ready work or idles. T2 stays blocked. Record validation/gaps and release/handoff under current ownership without turning termination into acceptance or stale claims into replacement rights.

Why the change matters

Readiness identifies possible work; ownership identifies its executor. Atomic claiming binds both at one instant, limiting duplicate and premature edits while preserving recovery responsibility.

Observable expectation

Concurrent T1 claims yield one winner; T2 cannot be claimed. A replaced owner survives a stale release. Verified results precede downstream readiness.

Read-then-write files/owner labels do not prove safety; no real queue is started.

Limits

Leases/crash/timeout policy need explicit design; expiry does not establish absent effects. Markdown can display state but needs separate claiming enforcement. Provenance remains unconfirmed.