The Frontier
The Frontier is the ever-evolving set of actionable, filed work items that Yoke can move through their workflows. It connects your strategy to the work agents can pick up, advance, and deliver. The Frontier dashboard page is a view of that work, not the definition of the concept itself.
From strategy to the Frontier
Strategy documents hold the rolling plan, including ideas not yet filed. Filing an item gives that work a workflow, requirements, and a durable identity. Non-terminal items remain part of the work Yoke must account for, including items waiting on dependencies or decisions.
Completed and cancelled work retain their history. They no longer compete for staffing as unfinished work. See Strategy docs and Workflows and work items.
Dependency graph and edges
Blockers and dependents
A dependency edge connects a dependent item to a blocking item. It explains both when the dependent must wait and what the blocker must achieve. Edges can cross projects, so an application change can wait for an API change without losing that relationship between separate backlogs.
Start, merge, and finish conditions
| Gate point | Meaning |
|---|---|
| Activation | Wait before starting implementation |
| Integration | Work may proceed, but merging must wait |
| Closure | Work may proceed, but completion must wait |
| Coordination only | Record an independent relationship without a lifecycle wait |
The satisfaction condition can require a workflow stage, a recorded merge, or completed delivery to a named environment. The rationale explains why the edge exists. Use the actual relationship rather than a generic blocked note when another item is the obstacle.
Chains, unblocking value, and cycles
An item may unlock several downstream items. Longer chains reveal where a delay will propagate. A circular chain can leave every item waiting for another; Yoke refuses dependency edits that would create an unsatisfied cycle and reports existing deadlocks for resolution.
Your agent can inspect an item's edges and their reasons. Dependency reference
Readiness and waiting
Readiness combines the item's pinned workflow, required gates, dependencies, approvals, blocks, freezes, and work ownership. An unfinished item is not necessarily assignable right now.
For example, an item may be ready to implement while an integration edge still prevents its merge. An item with finished code waiting only for that merge has no implementation step to staff. Read the reason and the gate point before assigning more work.
Claims protect existing ownership. A stopped or unresponsive worker needs recovery or a handoff, not a second agent silently taking the same assignment. Gate reference
Scheduler and ranking
The scheduler ranks eligible work using priority, dependency relationships, current progress, and capacity. It aims to advance useful work while avoiding conflicting assignments and exceeding work-in-progress limits.
The next action comes from the item's pinned workflow. A scheduling result should therefore name both the work and the step it can take. A high-priority item with an unmet gate still needs its blocker resolved. Scheduling reference
Advancing the Frontier
Steering
A steering session maintains the working plan and coordinates execution across available sessions and machines. It files work, staffs it, follows delivery, and brings decisions to you. Steering and fleet control
Charge
Use /yoke charge when you want an agent to pick up assignable work directly. It reads the ranked Frontier, presents the available work, and dispatches through the item's workflow. Charge dispatch
Feed
Use /yoke feed to refresh stale items and dependency facts or turn strategy work into filed items. Feeding changes the recorded work and its relationships; charging advances the work selected from that set.
The Frontier dashboard page
The page shows Waiting, On hold, Ready, In progress, Release, and Done (24h) work.
Waiting lays out unsatisfied dependencies in columns. The first column shows work holding other items up; later columns show how many dependency steps separate the work. Cards explain whether an item is waiting to start, merge, or finish. Coordination-only relationships do not appear as blocking edges. The graph keeps the full chain, including items whose home is another section. Those items appear as smaller outlined Reference cards showing their home, activity. Their reference link jumps to the home card, and they never increase the Waiting count.
Every item has exactly one home section. Counts include only home cards. On hold shows a freeze, block, missing spec or halted work that needs direction. Ready shows unclaimed work available to advance. In progress separates Working from Waiting, from the server session status. Session chips use Working, Waiting and Ended consistently with Sessions; a process exit does not change the status. Cards show one plain next-action sentence, with the raw diagnostic detail behind (i); chips do not repeat intent or reasons. Release shows items at their workflow's delivery stage; Done (24h) shows work finished in the last 24 hours and older finished blockers referenced by a live dependency, each with its actual finishing time. Its See more... link always opens Items for the current scope, even when nothing finished in the window. Release and Done include delivery state and the relevant run.
Project filters retain related items across dependency chains, including items from other projects. Open a card to inspect blockers, dependents, and the item's full context. Dashboard details
Who acts next
Session and item rows carry next_actor with actor, reason and since.
The session card information disclosure shows its next actor and waiting reason.
Item cards omit next-actor text. JSON and named-field CLI reads retain it. Pending
decisions take priority, followed by unmet dependencies, CI and release runs.
A decision resolves its audience to active people, including organization roles
inherited by the project. An empty audience names the steering owner and asks
for audience repair. The state time comes from the obligation, never a heartbeat.
Older servers may omit this projection; clients keep their existing state display.