A generic function declaration referenced before it is checked resolves to any, so its arguments get no contextual type. Zod core hits this at core/api.ts:1696, where _superRefine (declared at 1692) calls _check<T>((payload) => ...) and function _check<O> is declared at 1718: payload reports a false TS7006. The explicit <T> is irrelevant — a later-declared generic called with no type arguments behaves the same, and moving the declaration above its use clears it. A non-generic forward reference already works.
Cause: checkSourceFile never pre-computes signatures for top-level statements (precheckFunctionSignatures runs only inside function bodies), and the on-demand fallback ensurePlainFunctionSignature returns null for any function with type parameters, so resolveValueDeclInStmt falls through to any. The same fallback feeds functionDeclValueTypeForNamespaceMerge and the namespace-member lookup. TypeScript hoists declarations and resolves signatures lazily, so declaration order does not matter.
A first attempt simply computed the generic signature on demand (popping the type-parameter scope the signature pass pushes). It was measured and rejected: adversarial review showed the on-demand path runs while the caller's narrow scopes are still on the stack, so the callee's signature can bind the caller's type parameters, and the polluted signature is then cached on the HIR and reused (a false TS2345 for type T = {tag:string}; function f<T>() { g({tag:"x"}) } function g(x: T) {}, clean in tsgo). It also crashed the pinned Zod run and broke 15 checker tests. Only part of an overload set is registered by a forward reference as well, which can turn today's silent any into a false TS2554/TS2345/TS2769.
The direction worth measuring is pre-computing top-level function signatures in checkSourceFile — the way function bodies already do it — so the signature is resolved in a clean scope rather than at the use site. Gate any candidate on the unchanged Zod core shard plus both unit suites.