Task Pipeline

TaskPipeline is a small tick-driven workflow runner. Each named step returns a StepResult, and the pipeline advances only on SUCCESS.

Step statuses:

• SUCCESS: advance to the next step.
• WAIT: start a tick delay before running the same step again.
• RETRY: keep the same step without adding a delay.
• RESET: return to the first step and clear delay.
• FAILED: stop advancement until caller resets or handles failure.

Interaction result bridges:

• StepResult.fromInteraction(result): preserve legacy behavior; SUCCESS becomes SUCCESS, every other status becomes FAILED.
• StepResult.fromInteractionPaced(result): retry only PACED.
• StepResult.fromInteractionTransient(result): retry the SDK default transient set for paced actions, temporarily missing/hidden targets or widgets, and bank/deposit-box/production interfaces that are not open yet.
• StepResult.fromInteractionRetrying(result, statuses...): retry the exact caller-provided statuses.

Diagnostics:

• currentStepTicks() counts ticks spent on the current step, including delay ticks.
• currentStepAttempts() counts executions of the current step body.
• Both reset when the pipeline resets, advances to a new step, or completes.

Example:

TaskPipeline pipeline = TaskPipeline.create()
    .step("open-bank", () -> StepResult.fromInteraction(BankActions.openNearest()))
    .step("withdraw-runes", () -> StepResult.fromInteraction(BankActions.withdraw(561, 100)));

StepResult result = pipeline.tick();
if (result.getStatus() == StepStatus.FAILED) {
    log.debug("Pipeline failed at {}: {}", pipeline.currentStepName(), result.getMessage());
}
if (pipeline.currentStepTicks() > 20) {
    log.debug("Pipeline has been on {} for {} ticks",
            pipeline.currentStepName(), pipeline.currentStepTicks());
}

Workflow Builders

CombatWorkflowBuilder and ProductionWorkflowBuilder translate domain concepts like "eat below 50%" or "attack target" into StepHandler chains (they extend AbstractWorkflowBuilder; build() returns a StepHandler, not a TaskPipeline). Use a builder to assemble a standard loop, then append custom steps for script-specific logic. See combat-and-prayer.md, production-workflow.md, and banking.md.

StepContext is the shared mutable context passed through builder-produced steps. It stores label positions and caller-defined values:

• getLabels() returns the label map used by label(...) and jump(...).
• put(key, value), get(key), contains(key), and remove(key) manage step-local state.
• clearValues() removes caller-defined values while leaving labels intact.

Keep keys stable and narrow to the workflow that owns them. Prefer typed service callbacks for domain data; use StepContext for cross-step scratch state such as a selected target, timeout flag, or last observed count.

Timing helpers:

• TickDelay tracks a single countdown.
• Cooldowns tracks named countdowns.

Both are deterministic and covered by unit tests.

TaskPipeline Execution Model

The TaskPipeline runs sequential steps, managing delays, retries, and errors on each tick: