Orkes

PASS consensus from 3 PASS.

The guide provides setup, one complete Python file, a run command, expected output, verification, and troubleshooting. The quickstart hub routes to Connect to Conductor and then to first-worker, which gives the greetings/greet example in six languages plus a durability check and a troubleshooting list, so the path to Hello Conductor is unambiguous when entered from /content/quickstart. The Hello Conductor quickstart is a single page with prerequisites, install, worker code, workflow code, execution, and verification steps in one sequential guide.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

Task scope and rate-limit zero behavior are documented, but concurrentExecLimit=0 behavior is not stated. Rate-limit semantics are exact and zero-valued behavior is stated for rateLimitPerFrequency, timeoutSeconds, and pollTimeoutSeconds, but concurrentExecLimit is the one field on the same table with no documented zero behavior even though API responses return concurrentExecLimit: 0, and its scope is only described as across all workers on a different page. The task-definition schema clearly documents rateLimitPerFrequency (default 0 = no limit), rateLimitFrequencyInSeconds, and concurrentExecLimit (default 0 = no limit). Values are consistent across task-definition and task-lifecycle pages; zero disables the constraint.

FAIL consensus from 1 PARTIAL, 2 FAIL.

The docs identify saturation but omit a client backoff schedule and disagree on whether the response can be 400. The cause, the maxQueueSize default of 1000, and the PULL_WORKFLOW_MESSAGES drain path are documented, but no page gives a backoff algorithm, a Retry-After header, a retry ceiling, or a delay, and the architecture page contradicts this one by saying the same condition can return HTTP 400. The error-handling page covers retry strategies (FIXED, EXPONENTIAL_BACKOFF, LINEAR_BACKOFF) for failed tasks but never mentions what happens when a task queue reaches capacity or how to detect/backoff from a 429. The rate-limits page shows how to prevent overload but not how to recover from it.

PASS consensus from 3 PASS.

The GitHub path connects a shared secret to verified delivery, automatic workflow start, and execution inspection. The guide gives the seven routes, a verifier table naming the exact verification input and challenge behavior per provider, secret-reference configuration, and both the start and WAIT_FOR_WEBHOOK resume delivery modes, and a separate cURL tutorial walks the full create-invoke-verify-resume loop end to end. The webhook integration page documents creating webhooks (UI + API), six verifier choices (HEADER_BASED, SIGNATURE_BASED, HMAC_BASED, SLACK_BASED, STRIPE, TWITTER, SENDGRID), idempotency-key configuration, and both start-workflow and resume-WAIT_FOR_WEBHOOK delivery modes.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The example matches name, version, input, and returned ID, but the dependency keeps an unresolved VERSION placeholder. The official Java SDK page ships a structurally complete worker, workflow, and execution example, but its dependency coordinate is the literal placeholder VERSION, and its client model (ApiClient plus OrkesClients, WorkflowExecutor(apiClient, 100), startWorkflow with a StartWorkflowRequest) does not match the quickstart's Java tab for the same greetings workflow (ConductorClient.builder(), WorkflowExecutor(client), four-argument positional startWorkflow), so completing it requires picking between two incompatible bootstraps. The Java SDK page provides a 60-Second Quickstart with install coordinates (Maven/Gradle), a GreetWorker implementing the Worker interface, a Main.java that builds and registers the greetings workflow, and execution instructions.