docs/schemas/abstract-schema.md is 321 lines, the largest dedicated page of any peripheral surface, documenting an entry point (src/abstract.ts) that is 30 lines of re-export.
The implementation it appears to describe is not the entry. use-abstract-form.ts (475 lines) and abstract-schema-factory.ts (957 lines) are core: every Zod useForm delegates to useAbstractForm, and both files sit in the eager closure of a bare useForm. Deleting the entry would remove 30 lines of re-export and zero implementation.
The entry should stay. dist/index.d.mts already imports AbstractSchema from ./abstract.mjs and the type appears in 7 positions inside the published useForm config types, so removing the subpath would strand a type that every consumer's cmd+K lands on but that they can no longer name or import. That is worse DX than today for zero bytes.
What is disproportionate is the page. 321 lines of prose documents a ~30-method SPI (getSlimPrimitiveTypesAtPath, entryKeyKindAtPath, getUnionDiscriminatorAtPath among them) that no third party is going to implement correctly, and that no non-Zod adapter exists for. Every line of it is a promise to keep, and the page is a standing drift liability against an interface that changes whenever the two first-party adapters need it to.
Proposal: trim to a reference section that says what AbstractSchema is, why v3 and v4 parity is one core with a real contract rather than two adapters that happen to agree, and where the authority lives. docs/reference/custom-adapters.md and the adapter source already carry the rest.
Found in the 2026-09-18 feature audit (main@b4a64ef9, eager baseline 33,204 B gz). Every byte figure is a measured ablation, not an estimate.
🤖 Generated with Claude Code
https://claude.ai/code/session_01PnAVwFjpvKQNppAMkSvoiH
docs/schemas/abstract-schema.mdis 321 lines, the largest dedicated page of any peripheral surface, documenting an entry point (src/abstract.ts) that is 30 lines of re-export.The implementation it appears to describe is not the entry.
use-abstract-form.ts(475 lines) andabstract-schema-factory.ts(957 lines) are core: every ZoduseFormdelegates touseAbstractForm, and both files sit in the eager closure of a bareuseForm. Deleting the entry would remove 30 lines of re-export and zero implementation.The entry should stay.
dist/index.d.mtsalready importsAbstractSchemafrom./abstract.mjsand the type appears in 7 positions inside the publisheduseFormconfig types, so removing the subpath would strand a type that every consumer's cmd+K lands on but that they can no longer name or import. That is worse DX than today for zero bytes.What is disproportionate is the page. 321 lines of prose documents a ~30-method SPI (
getSlimPrimitiveTypesAtPath,entryKeyKindAtPath,getUnionDiscriminatorAtPathamong them) that no third party is going to implement correctly, and that no non-Zod adapter exists for. Every line of it is a promise to keep, and the page is a standing drift liability against an interface that changes whenever the two first-party adapters need it to.Proposal: trim to a reference section that says what
AbstractSchemais, why v3 and v4 parity is one core with a real contract rather than two adapters that happen to agree, and where the authority lives.docs/reference/custom-adapters.mdand the adapter source already carry the rest.Found in the 2026-09-18 feature audit (
main@b4a64ef9, eager baseline 33,204 B gz). Every byte figure is a measured ablation, not an estimate.🤖 Generated with Claude Code
https://claude.ai/code/session_01PnAVwFjpvKQNppAMkSvoiH