Deno

PASS consensus from 2 PASS, 1 PARTIAL.

The CLI tutorial creates code, authenticates, deploys it, and says the deployment returns a live URL. The getting-started guide walks the whole path from organization to first build, but it says "Mono-repos (repositories where the application lives in a subdirectory) are not yet supported" while the Builds reference documents an "App directory" option that is "Useful for monorepos", so an agent cannot tell whether a subdirectory app can be deployed. The path is unambiguous: create an organization, click '+ New App', configure the repo and build settings, and deploy. The getting-started guide and apps reference describe the same sequence of steps.

PARTIAL consensus from 3 PARTIAL.

The limits page says 512MB, while the builds reference says 768MB by default and 4GB on Pro. The page filed under "Policies & Limits" contains no numeric quota, no overage rule, and a future-tense promise about a date ten months past, so plan quotas and overage pricing are only obtainable from the marketing pricing page outside the docs; build timeout, build memory, runtime memory, and regions are documented but the build-timeout maximum contradicts the CLI reference. Plan quotas live on the pricing page (deno.com/deploy/pricing not docs.deno.com). Runtime memory default 768 MB, max 4 GB on Pro. Build memory defaults to 3 GB, can increase to 4 GB on Pro. The builds reference page says build timeout max is 15 minutes on Pro, but the CLI reference page lists allowed values up to 30 minutes, a direct contradiction. Region counts are spread across three pages: the main Deploy page says '2 regions', the migration guide names 'us and eu', and the CLI allows 'us, eu, global'. No single page assembles all limits.

PASS consensus from 3 PASS.

The migration guide links the timeout to legacy serve() and covers entrypoint and dependency upgrades. The migration guide names the symptom, the cause, the corrected code as a diff, and the third-party-dependency case, so diagnosis and repair need no cross-referencing, though the warmup timeout duration itself is never stated. The migration guide explicitly names the legacy std serve() as the cause, explains the warmup timeout symptom, and provides the exact fix: replace serve() from std/http with Deno.serve(). It even warns about transitive dependencies importing the old function. Recovery is complete from the docs alone.

PARTIAL consensus from 1 PASS, 2 PARTIAL.

The docs provide the trigger and payload, but no expected sender or verification rule for Deno-originated events. The four event names, the full TypeScript payload type, and a runnable GitHub Actions workflow are all on one page, but no Deno page states who is authorized to dispatch these events or whether client_payload can be forged by any other actor holding repository dispatch rights, so the trust boundary has to be established from GitHub's documentation instead. The apps reference documents all four event types, provides the full TypeScript payload interface with app, organization, and revision fields including git SHA and preview_url, and gives a complete GitHub Actions workflow example that receives deno_deploy.build.routed. The trust boundary is clear: events are sent by Deno Deploy to the linked repository.

PASS consensus from 3 PASS.

The minimum Deno.serve example returns a Response and matches the migration guide's required API. The same minimal handler appears in the API reference, the HTTP server guide, and the migration diff, and the Deploy runtime reference confirms Deploy "starts the application using the configured entrypoint and waits for the HTTP server to start", so the example is deployable as written. The main docs page and the migration guide both use Deno.serve with a handler returning a Response object. The API reference confirms that Deno.ServeHandler consumes a Request and returns a Response. The example matches current deployment guidance on both the new Deploy platform and the runtime docs.