Parent: #758 · Related: #548, #754
core/api.ts:1732 and :1745 report a false TS7006 on inst in
const ch = new checks.$ZodCheck({ check: "describe" });
ch._zod.onattach = [ (inst) => { ... } ];The array literal and the assignment are not at fault: Home types the imported value checks.$ZodCheck as any, and TypeScript reports TS7006 for a callback contextually typed by any too (verified against tsgo). The value export is dropped in packages/ts_program/src/declaration_graph.zig (if (!entry.value_ptr.*) continue;): a value whose declared type is unsupported is not published at all, while type-space exports are published with projection_only = true. $ZodCheck's graph reaches leaves program_schema.zig rejects (Set<string>, Record<string, unknown>, typeof version, a this-typed "~standard" member, and self-cycles), so checks.$ZodCheck becomes any, new gives any, and _zod.onattach is any.
Publishing unsupported value exports as projection-only would fix it, but that is the approach measured and rejected in #754 (+38 identities: 30 TS7006 in core/compile.ts, plus TS2322/TS2345/TS2559), and it would reach all 104 core.$constructor<...> exports. A context-only variant along the lines of #751/#754 — lowering the projection solely where a member is read or a contextual type is needed, leaving the receiver any — is the direction worth measuring. Any candidate must be A/B-gated on the unchanged Zod core shard before landing.