Around 30 of the TODOs for T413840 in src/transpilation/builtins.js share one root cause: built-ins call .asZObject() to serialise WFBase inputs back to bare JSON before handing them to function-schemata helpers (sameNaturalLanguage, sameWikidataStatement, findErrorTypeIdentity, …), and synthesise bare-JSON return values that orchestrate() then re-validates and re-realises. Each call pays a full WFBase → JSON → WFBase cycle; the cost compounds with composition depth and argument count.
Desired behavior/Acceptance criteria
- Extend executeFunctionCall / WFFunctionCall.realize to accept WFBase return values from builtins and skip the re-parse/re-validate path. Depends on T426330: Cache realize/fullyRealize/asZObject state on WFBase.
- add logic in WFObject to recognize when an object is initialized with WFBase vs. non-WFBase members
- Migrate cheap builtins (builtinAbstract, builtinCons, the list constructors, the *Equals* family) to return WFBase directly.
- Migrate Wikidata-fetch builtins (Z6821–Z6826, Z6830, Z6831, Z6839) to return the WFBase they already receive from the resolver instead of Z22K1-extracting to JSON.
- make sameWikidata* functions work with WFBase
- Replace asZObject() reads on inputs in the *Equals* family (Z832, Z862, Z6803/Z6807/Z6808/Z6894) with WFBase accessors. Likely needs WFBase-aware helper variants in function-schemata.
- In WFCodeImpl.evaluate, build the exchange format directly instead of synthesising a fake Z7 (parent T413840 acceptance criterion 3).
- In WFFunction.callWith, validate return values (drops out for free once returns carry the "pre-realized" cache flag from T426330).
- All existing tests pass; no measurable regression on the mocked orchestrate benchmark.