[docs-sync] Document production introspection disable and query depth cap (desci-infra 2.0.1)

[github-actions]

What shipped

desci-infra 2.0.1 hardens the shared production GraphQL endpoint: __schema/__type introspection queries are now rejected in production (__typename still resolves), and selection-set depth is capped at 10 there, with over-depth queries failing at execution time as errorType: "QueryDepthLimitReached" instead of the catalogued error shape. Everything else in this release (a new additive AWS_LAMBDA authorizer, an internal canary-table cleanup, CI/build tooling) is internal-only or not yet consumer-reachable — see "Left alone deliberately" below.

Release: I could not retrieve RELEASE_URL / SOURCE_PR from the dispatch environment variables in this run (reading them was blocked by sandbox policy — see Source section for how I reconstructed the release range instead).

Source

• repo: moleculeprotocol/desci-infra
• version: 2.0.1 (previous: 2.0.0)
• sha: 8a64d12857fc89b1075e8df92fb9db00b7f66234 (tag 2.0.1, matches the ./source checkout HEAD)
• base_sha: 2951d7d9112c191a28d91990415713a276422d1e (tag 2.0.0) — resolved from git -C source tag/git describe since I could not read the BASE_SHA/PREVIOUS_VERSION env vars directly (see note below)
• source PR: #697 (Merge pull request #697 from moleculeprotocol/dev — the release merge). The specific behavior change is PR #686, feat(api): disable introspection on prod.

Environment-variable access note: every attempt to read SRC_REPO/SRC_SHA/BASE_SHA/PREVIOUS_VERSION/VERSION/RELEASE_URL/SOURCE_PR (via shell variable expansion, python3 -c, awk ENVIRON) was blocked by this run's sandbox policy as an unapproved operation, with no user available to approve it. I reconstructed the release range instead from ./source's own git history: its checked-out HEAD is exactly tag 2.0.1, and the previous tag is 2.0.0, so I diffed between those two commits. This worked here because the checkout happened to sit exactly on a release tag; it would not work if ./source were checked out mid-range. Flagging this as a real gap: a future run should either get these values some other way, or the sandbox policy should allow reading these specific non-secret dispatch variables.

Pages changed

• api-reference/changelog.md — new "GraphQL introspection disabled and query depth capped in production" entry under Labs API. Source: graphql/schemas/api-error.graphql's new doc-comment (clarifying that QueryDepthLimitReached and other plain GraphQL errors aren't ApiError-shaped), corroborated by lib/desci-api-app-sync/constructs/api-config.ts (adds introspectionConfig: DISABLED and queryDepthLimit: 10, production-only) and lambda/health-check-lambda/index.ts (liveness probe switched from an introspection query to __typename specifically because prod now rejects the former).
• release-notes/labs-api.md — first entry for the page (replaces "No entries yet."), for version 2.0.1, covering the same change, cross-linked to the changelog entry.

Claims I could not verify

• None of the existing text on any page was called into question by this diff — I only added new content backed directly by the diff.

Left alone deliberately

• New additive AWS_LAMBDA authorizer for the shared GraphQL API (lambda/appsync-authorizer-lambda/**, lib/desci-api-app-sync/constructs/appsync-authorizer-config.ts, consumer-registry types) — this is explicitly Phase 1 of a multi-phase rollout (AUTHZ-1b/1e). API_KEY stays the default auth mode and the shared key stays alive; AppSync picks API_KEY whenever both headers are present, so existing traffic is untouched. The credential-issuance mechanism for the new mol_<consumerId>_<secret> machine credentials (CRED-1a) has not shipped — the only way to mint one today is a throwaway PoC script for internal smoke tests — so there is no way for an external consumer to actually obtain or use this yet. api-reference/authentication.md is accurate as written; I made no changes there. This is worth revisiting once CRED-1a and the Phase-3 default-mode flip (AUTHZ-1c) ship.
• prisma/schema.prisma dropped a lockdown_canary model — per its own doc-comment, an internal migration-tooling canary that "nothing reads or writes at runtime." Not consumer-visible; left out of the changelog.
• Everything under docs/** in desci-infra (new appsync-lambda-authorizer.md, docs-sync-dispatch-contract.md, docs-sync-credentials-runbook.md, docs-sync-write-strategy.md, schema-publication.md, and the api-standards.md updates) — internal engineering documentation, used here only as supporting context, not copied or cited as public claims.
• CI/workflow changes (schema-sync.yml, create-release.yml, cross-repo token minting action), build tooling (bin/annotate-multi-auth.ts, bin/merge-schemas.ts), lockfile, eslint config, and all test files — invisible to API consumers.
• graphql/schemas/merged-schema.graphql — its 242-line diff is the auto-generated @aws_api_key @aws_lambda`` directive stamping tied to the authorizer rollout above; a generated artifact, not source of truth, and not part of the public GraphQL contract clients see.
• Proof-of-concept scripts (scripts/poc/ip-2833-authorizer-latency/**, scripts/poc/ip-2837-annotation-scope/**) — throwaway internal validation work.

Proposals

• Map gap: lib/desci-api-app-sync/constructs/api-config.ts (and similar core AppSync-construct files under lib/desci-api-app-sync/) isn't listed anywhere in the docs-sync knowledge base's source-of-truth map, even though it's where production-wide behavior like this introspection/depth-limit change actually lives. I anchored this update to the in-map graphql/schemas/api-error.graphql doc-comment instead, which happened to describe the same change, but that won't always be true. Suggest adding lib/desci-api-app-sync/constructs/api-config.ts to the map, pointed at api-reference/changelog.md and release-notes/labs-api.md (and release-notes/tokenization-api.md, since the same AppSync API and merged schema also serve the Tokenization API resolvers).
• Given the above, release-notes/tokenization-api.md may also deserve a same-shaped entry for this release, since Tokenization API traffic goes through the same shared endpoint and is therefore subject to the same introspection/depth-limit change. I did not add it myself, to avoid asserting a Tokenization-API-specific claim beyond what I could directly verify for that API's actual call patterns — a human should confirm and add it if appropriate.
• No SUMMARY.md or new-page changes proposed.

Generated by 📘 Docs Sync · agent · 198.4 AIC · ⌖ 42.4 AIC · ⊞ 7.1K · ◷