Review: TypeScript prior art

Fact-check review: notes/research/06-ts-prior-art.md

Review of: TypeScript prior art.

VERDICT: ACCEPT-WITH-FIXES

Reviewer: independent fact-checker, 2026-10-01. I re-fetched every source named below on 2026-10-01. Local paths are under /Users/svallory/work/mesh/scratch/ash-src/.

Why REJECT and not ACCEPT-WITH-FIXES

The Wasp headline is real, and the post is quoted accurately. The health numbers are mostly right. But the three sections the brief calls most important (criteria 3, 4 and 5) contain false claims that a designer would act on:

1. Authorization push-down. The document says Keystone, Payload and CASL check authorization in process and filter in memory. That is wrong: all three push the filter into the database query. It also says Hasura uses Postgres RLS (row-level security) and that PostGraphile generates RLS policies. Both are false.
2. Expression-to-SQL. The document gives “negative results” for TS-lambda-to-SQL, proxy capture and Function.toString parsing without having searched. At least five shipped TypeScript libraries do exactly this (Tinqer, Typhex, lambdaorm, Orange ORM, jsmql). Tinqer even ships row-filter policies. The document also describes ZenStack’s SQL lowering as “compile time”, but it happens at run time, per query, as a Kysely plugin. And it says nothing about TypeScript 7.0 shipping no compiler API, which the mesh plan’s “TS AST to SQL compiler” depends on.
3. Emitters. The document says Wasp commits its generated code to the repo. It does not: the output goes to .wasp/out, which Wasp’s own starter .gitignore excludes. The Wasp checksum manifest is presented as “the cheap, correct way to make a committed generated tree safe”, but the code does not do that. TypeSpec’s emitter-framework is described as an “IR transform pipeline”. It is a 0.x library of Alloy JSX components for rendering code. TypeSpec’s IR-transform package is mutator-framework. Prisma 8, a contract-first TypeScript rewrite that calls itself “AI-agent friendly by default”, is missing entirely.
4. LLM angle. The summary says Wasp’s benchmark is “the one published quantitative benchmark” and uses it as support for “a DSL agents have no training data for is a liability”. But the benchmark repo shows the Wasp app was written in the custom .wasp DSL (main.wasp), not TypeScript. Even with the DSL it used about 38% fewer tokens than the Next.js app. So the only quantitative evidence in the document points the other way from the summary’s conclusion. Convex’s public eval suite and leaderboard, a second quantitative source, were also missed.

---

Error table

Severity: high means a design decision would go wrong if taken from the document. Medium means a materially wrong or unsupported fact. Low means cosmetic or stale.

---

Check 2: Wasp, verbatim

2a. “5 Years and $5M Later: Inventing a New Programming Language for Web Development Was a Mistake”

URL correct: https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake. Header: “May 13, 2026 · 19 min read · Matija Sosic, Co-founder & CEO @ Wasp”. Page footer: “Last updated on Sep 30, 2026”. The post exists, and every quotation in the research document matches the text.

Key passages, verbatim:

• “My twin brother and I started it back in 2021 when we went through Y Combinator, and raised over $5M in total.”
• “Five years in, we realize it was a mistake. Creating a new language makes sense for certain problems and domains, but in this case, it wasn’t a fit and brought us more trouble than it was worth.”
• “…why we’re replacing our custom language with TypeScript, while Wasp itself stays the same under the hood.”
• TL;DR: “Developers resonated with the problem Wasp was solving, but the language was a tough sell. “Lang” in the name made them think our aim was to replace JavaScript (it wasn’t) and were skeptical of how it’d work with their tooling.” / “Many developers loved Wasp once they gave it a try. But getting them to try it out was the hard part.” / “Adoption still grew, but as we kept pushing towards 1.0 we realised the “language” concern wasn’t going away. Also, maintaining a good IDE experience for a custom language proved to be way harder than expected.” / “It turned out having a custom language wasn’t Wasp’s core value. It was maintaining a high-level specification of the entire full-stack app, making it easier to reason about for both humans and AI.” / “We decided to replace Wasp’s config language with TypeScript. It is “only” an interface change, while everything else stays the same.”
• On tooling: “We ended up developing our own language server and a VS Code extension for it, but since Wasp used Prisma’s DSL as an embedded language and had many references to React & Node.js files, we still only reached 80% of where we wanted to be.”
• On ergonomics: “Finally, the ergonomics we aimed for with the language didn’t turn out to be as important as we thought. Developers are perfectly happy using TypeScript, a language they are familiar with, even if it requires a few extra lines and braces.”
• Section heading: “Language was never the moat. It’s having a high-level understanding of your entire app at compile time.”
• “We only swapped the “front end” of the compiler, or how you define a high-level app spec in Wasp.”
• On the TS SDK: “Every editor works out of the box. Developers can use conditionals, loops, and imports … Splitting the spec across multiple files becomes trivial.”
• On AI, the only AI-specific claims: “With AI and developers reviewing generated code less frequently, this became even more valuable…” and “We repeatedly hear from developers using Wasp that it is the stack that works best with AI”. These are anecdotal.

The researcher’s paraphrase “the spec was the value and the language the tax” is a fair summary of “Language was never the moat”, but the word “tax” does not appear in the post. Mark it as a paraphrase. The stated reasons are positioning/adoption, IDE tooling cost, and low value of the syntax ergonomics. Not one reason concerns LLMs or training data.

What Wasp looks like now, from primary sources:

• The spec is main.wasp.ts, called the “Wasp Spec” since 0.24.0, importing @wasp.sh/spec. @wasp.sh/spec is on npm: 0.25.0, 80 downloads/week. Example from the post: app.page('LoginPage', { component: { importDefault: 'Login', from: '@src/pages/auth/Login' } }); app.route('LoginRoute', { path: '/login', to: loginPage }); app.query('getTasks', { fn: …, entities: ['Task'] }); app.job(…); export default app;
• Removal timeline: TS config preview in 0.15.0. DSL file reading removed by PR #4334 (merged 2026-06-22). DSL parser removed by PR #4369 (2026-06-25). Language server removed (PR #4335, listed in the v0.25.0 notes). v0.25.0 (2026-07-27) rejects main.wasp with the hard error quoted in table row #18.
• Pipeline now: Haskell analyzeWaspTsFile runs a Node script against main.wasp.ts, receives JSON declarations, and merges them with entities parsed from schema.prisma (waspc/src/Wasp/Project/WaspFile/TypeScript.hs). AppSpec, the Generator monad, FileDraft and the checksum sync are unchanged. Output still goes to gitignored .wasp/out.
• Kept: the Haskell compiler and its AppSpec IR, all generators, Prisma’s schema.prisma for the data model, the wasp CLI, wasp studio (and wasp show spec --json in the unreleased 0.26.0 changelog).

2b. “Next.js vs Wasp: 40% Less Tokens for the Same App”

URL correct: https://wasp.sh/blog/2026/03/26/nextjs-vs-wasp-40-percent-less-tokens-same-app. “March 26, 2026 · Vince Canger, Developer Relations @ Wasp”.

• Compared: “We compared the two frameworks on the same feature prompt in the same app: Vercel’s SaaS Starter.” Wasp converted that starter to Wasp themselves (“we took Vercel’s official SaaS starter app in Next.js and converted it to a Wasp (React, Node.js, Prisma) app”).
• Agent and models: Claude Code. “same models (Opus for planning and implementation, Haiku for exploring)”. Pricing table: “Opus 4.6 | $5.00 | $25.00 | $0.50 | $6.25”. The protocol pins CLAUDE_CODE_SUBAGENT_MODEL=claude-haiku-4-5-20251001 (https://github.com/vincanger/token-compare-nextjs-wasp/blob/main/code-generation-test.md).
• Task: a single “Team Announcements” feature (data model, two operations, a page, navigation, an activity type). The prompt is framework-neutral.
• Runs: one session per framework (plan plus implementation). No repetitions and no variance reported.
• Numbers (post table): cost $2.87 vs $5.17 (“44% cheaper”); total tokens 2.5M vs 4.0M (2,505,796 vs 4,049,413; “38% fewer”); API calls 66 vs 96 (“31% fewer”); tool uses 52 vs 66 (“21% fewer”); files read 12 vs 15; output tokens 5,416 vs 5,395 (“~same”); duration 14.9m vs 15.0m; cache creation $1.32 vs $2.82; cache read $1.09 vs $1.71. The researcher’s §5 table matches the post. The summary bullet mislabels two rows (error #2).
• The key fact the document misses: the Wasp app in the published comparison repo uses main.wasp, the custom DSL (app saasStarter { wasp: { version: "^0.21.0" }, … auth: { userEntity: User, … onAfterSignup: import { onAfterSignup } from "@src/auth/hooks" …). The blog’s illustrative snippets show main.wasp.ts, but the measured code base used the DSL.
• Methodological weaknesses:
  1. n=1 per arm; no variance.
  2. Vendor-run; the vendor did the conversion and chose the feature.
  3. No correctness or quality outcome is reported. The protocol says to “verify the app compiles and the feature works”, but the results do not say whether either implementation passed.
  4. Internal inconsistencies:
     • The README reports output tokens Next.js 5,416 / Wasp 5,395, the reverse of the post.
     • The README says 45% cost reduction; the post says 44%.
     • The post’s prose gives cache creation as “$2.15 vs $0.97” and cache read as “$1.14 vs $0.67”, which do not match its own table ($2.82/$1.32, $1.71/$1.09). This is probably main-agent vs subagent accounting, but it is unexplained.
  5. The headline “~70% higher token efficiency (output per token)” is a ratio derived from the same single run.
  6. A confound acknowledged by the vendor: “Claude has seen far more Next.js training data (advantage: Next.js)”.
  7. The Wasp codebase is ~40% smaller by design, so the experiment measures context size, not framework semantics.
  8. Repo: 0 stars, last push 2026-03-25; nobody independent has reproduced it.

---

Check 3: LLM evidence (criterion 5)

Verified as cited: the Wasp post and benchmark (above), and the Convex tagline. The tagline is verbatim on https://www.convex.dev/: “All gas, no breakages. Convex is the reactive backend platform that keeps up with you and your agents.”

Missed, for structured or schema-first stacks helping agents:

• Convex Evals, 2025-03-19 (https://stack.convex.dev/convex-evals): seven categories (fundamentals, data modeling, queries, mutations, actions, idioms, clients). Guidelines “increase the success rate of AI writing Convex code by about 20%” (Claude 3.7 Sonnet, GPT-4o). There is a public leaderboard with no-guidelines vs with-guidelines tracks (https://www.convex.dev/llm-leaderboard/no-guidelines) and an eval repo (https://github.com/get-convex/convex-evals). Note: this measures guideline/context effects on a TS API, not DSL vs TS.
• Convex Chef model comparison, 2025-04-28 (https://stack.convex.dev/chef-model-exploration).
• Prisma 8 markets itself as “AI-agent friendly by default”, ships per-version agent skills and a machine-readable contract JSON “consumable by tools and agents” (https://github.com/prisma/orm, ARCHITECTURE.md). These are design claims, not measurements.
• ZenStack: posts exist but they are not benchmarks. “Code as Doc: Automate by Vercel AI SDK and ZenStack for Free” (https://zenstack.dev/blog/code-as-doc) argues LLMs handle declarative schema better than imperative code for docs generation. “How to Build AI Agents…” is at https://zenstack.dev/blog/ai-agent. The researcher wrote “not found”; replace that with these URLs and their dates, labelled as qualitative vendor claims.

Missed, for the cold-start / low-resource concern:

• Wu et al., “A Survey on LLM-based Code Generation for Low-Resource and Domain-Specific Programming Languages”, ACM TOSEM 2025 (https://arxiv.org/abs/2410.03981). It covers 111 papers and concludes DSL/LRPL generation “remains a critical challenge” and that there is no standard benchmark.
• Cassano et al., “Knowledge Transfer from High-Resource to Low-Resource Programming Languages for Code LLMs” (MultiPL-T), revised 2024-09-22 (https://arxiv.org/abs/2308.09895). It reports measurable gains for low-resource languages from synthetic training data.
• Chand et al., “Leveraging LLMs for Multi-File DSL Code Generation: An Industrial Case Study”, 2026-04-27 (https://arxiv.org/abs/2604.24678). On 7B models, fine-tuning gives the largest gains and one-shot in-context learning gives “smaller but consistent improvements”.

Missed, against a simple “less training data = worse” reading:

• AutoCodeBench (Tencent Hunyuan, 2025-08; https://arxiv.org/abs/2508.09101): Elixir, a niche language, scored highest of 20 languages in its reported results. This is a general-purpose language, not a DSL, but it weakens “training-data volume decides”. The reported numbers come via secondary write-ups; the researcher should read the paper’s table before citing figures.
• Wasp’s own benchmark ran on the custom DSL and still came out cheaper (check 2b).

Net: the document’s “exactly one benchmark” and “no independent evidence” are wrong. Its conclusion that Wasp proves DSLs hurt agents is not supported by any source. What the sources support: context size drives agent token cost (Wasp, n=1); curated guidance raises pass rates by about 20% (Convex); DSL code generation is a known research problem, eased by examples or fine-tuning (survey, Chand 2026).

---

Check 4: Expression-to-SQL approaches (criterion 3)

ZenStack v3, confirmed with corrections.

• The IR is a closed 10-kind union (zenstack/packages/schema/src/expression.ts:1-69; ?, !, ^ are the some/none/every collection predicates). It comes from ZModel, not from compiling TypeScript.
• Mechanism: PolicyPlugin implements onKyselyQuery, and PolicyHandler (a Kysely OperationNodeTransformer) rewrites each Select/Insert/Update/Delete node at run time. ExpressionTransformer maps IR kinds to Kysely nodes (@expr('binary'), @expr('member'), …).
• Writes: pre-create and pre-update checks, plus a post-update re-read with id-matching. Updating id fields under post-update policies is unsupported (policy-handler.ts:378).
• Calls: functions are resolved from a registry and throw at run time if not implemented (expression-transformer.ts:744-754).
• Fix: “compile-time” applies only to ZModel → IR. Lowering to SQL happens on every query at run time.

Approaches the researcher did not search, found:

Callback-plus-builder APIs worth naming in the table: Drizzle relational where: (t, { eq }) => eq(t.id, 1) and Convex .filter(q => q.eq(q.field('x'), 1)).

Non-TS precedents the section should cite briefly: C# LINQ expression trees, Scala Quill, and Python Pony ORM. I did not re-verify these and did not count them as findings; the researcher must source them before citing.

Platform constraint the section omits: TypeScript 7.0 (2026-07-08) “does not ship with an API”; a new, different API is expected in 7.1; the 6.0 API is available as @typescript/typescript6 (https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/). Any build-time arrow-function compiler, mesh’s included, must pick TS 6 API, another parser (oxc, as Tinqer does; or SWC/Babel), or wait for 7.1.

What the evidence shows about limits. Every lambda-to-SQL library above either:

• loses closures, so values must go through explicit params (runtime toString: Tinqer, lambdaorm, Typhex runtime mode), or
• needs a compiler hook to capture them (Typhex transformer).

None has meaningful adoption. The largest, Orange ORM, uses builder methods rather than JS operators.

---

Statistics comparison

I re-checked 26 profiled projects plus 7 extras (the brief asked for at least 12).

Totals: 33 projects checked. 25 fully match, 8 have at least one wrong field. By field: about 95 fields checked, 10 wrong or missing (Wasp, Payload, Encore, NestJS and Hasura release dates; Encore package; Convex downloads; Amplication activity; Effect attribution; Zero repo). Stars and download counts are reliable. Release dates are not: the researcher often took pushed_at as the release date.

Citation sample statistics

Sampled: 43 citations (32 URLs/API endpoints, 11 local paths). Supports: 34. Partial: 7. Does not support: 2. Dead links: 0.

• Partial (number right, attached claim wrong):
  • api.github wasp-lang/wasp (release date)
  • payloadcms/payload (date)
  • encoredev/encore (date)
  • nestjs/nest (date)
  • hasura/graphql-engine (date)
  • zenstack/README.md:29-49 (no “zod-inspired”/“superset”)
  • npm effect downloads (v3 window credited to v4)
• Does not support:
  • the npm downloads endpoint for convex: it returns 1,788,402, so the doc’s “not found” is wrong
  • typespec/packages/emitter-framework/src/typescript/lib.ts:1-40: it shows a diagnostic catalogue, but is used to support “an IR transform pipeline”, which the package (Alloy JSX components, 0.21.0) contradicts
• Supports (verified verbatim or by value):
  • Both Wasp posts (all §5 quotes match; the §5 table matches)
  • wasp.sh banner “100% TypeScript”
  • convex.dev tagline
  • GitHub stars for zenstack, remult, redwoodjs/sdk, keystone, convex-backend, adonisjs/core, doug-martin/nestjs-query, stalniy/casl, platformatic, amplication, graphile/crystal, typespec, Effect-TS/effect, trpc, middleapi/orpc, instantdb, geldata/gel
  • npm figures for zenstack, @zenstackhq/orm, payload, @casl/ability
  • zenstack/packages/schema/src/expression.ts:1-69; expression-validator.ts:86,240,245; README.md:52-56,59-63
  • wasp/waspc/src/Wasp/Generator.hs:16-36; Generator/FileDraft.hs:37-66; Generator/WriteFileDrafts.hs:35-61 (mechanism correct; the “committed” claim built on it is not)
  • typespec/.../library.ts:64; types.ts:2925
  • effect/.../SqlModel.ts:1-31; Statement.ts:670-701 (line counts 362/181/415/520/1,593/464 exact)
• Uncited claims found: Wasp roles, Hasura RLS, PostGraphile-generated RLS, Triplit/Instant/Zero semantics, Keystone/Payload in-memory filtering, Amplication entity-model plugins, “since 2022”, Rails admin.

Acceptance criteria

Other rule breaches:

• Word count is 9,037, above the 3,000–6,000 target.
• Analysis appears in fact sections (row #44).
• Many claims are labelled “from general knowledge”, which _rules.md rule 2 forbids unless marked. Several are not marked: Hasura RLS, PostGraphile, Keystone/Payload in-memory.

Required fixes, in priority order

1. Rewrite §3: add the check 4 table; correct the ZenStack mechanism; add the TS 7.0 API constraint; delete the false negative results.
2. Correct authorization push-down everywhere: Summary bullet 8, §1.5, §1.6, §1.10, §1.11, §1.13, §3.2, §3.5, the §3.7 table, §2 table, §7 #6 and #7. Use the sources in rows #8, #10, #11, #37 and #39.
3. Rewrite §1.14 and §3.5 for Triplit (filters), InstantDB (CEL) and Zero (no permission system; TS queries and mutators).
4. Fix Wasp: auth (none), output gitignored, DSL removed in v0.25.0, Wasp Spec package. Retract “adopt the checksum manifest for committed code” or rebase it on what the code actually does.
5. Fix §4: TypeSpec emitter-framework vs mutator-framework, getSourceLocation, Prisma 7 generator-helper plus the Prisma 8 contract IR.
6. Fix §5 and the Summary: correct the metric labels; state that the benchmark ran on the .wasp DSL with n=1 and no correctness outcome; add the Convex evals, ZenStack posts, Prisma 8 and the academic sources; move all inference to the analysis section.
7. Fix Effect (since 2024 in @effect/sql; downloads are v3) and the health dates listed above.
8. Add the missing projects listed under criterion 1, and fill the “known complaints” and “backing” fields.

---

Round 2 re-verification

Reviewer, 2026-10-01. Checked the revised 06-ts-prior-art.md (10,631 words, with ## Revision log (round 2)) against primary sources, re-fetched today.

New verdict: ACCEPT-WITH-FIXES. Every high row from round 1 is now correct at the source. The remaining problems are local:

• one false push-down claim (Casbin) that round 1 also missed;
• a wrong count in the Summary;
• one misquote;
• under-reported limits for the two libraries that matter most to mesh (Tinqer row filters, the Typhex subset);
• an unverifiable precedent (lambdaorm);
• some analysis still inside fact sections.

R2.1 Round-1 rows: status after revision

R2.2 Section 3, profile by profile

R2.3 Wasp, now facts only?

• §1.3: all seven quotes are verbatim against the post. The v0.25.0 removal (2026-07-27, PRs #4334/#4369/#4335, WaspFile.hs:36-42) is correct. The .wasp/out gitignore is correct. The benchmark description is correct: Vercel SaaS Starter, n=1 per arm, Opus/Haiku, the labels 31% = API calls and 21% = tool uses, the Wasp app in main.wasp (the DSL), and the inconsistencies.
• Residual conclusions are listed in R2.4 #8 and #9 (Summary line 30, §5.2 bullet 3).

R2.4 Still wrong: fix list

R2.5 Fresh citation sample (36, none checked in round 1)

Supports: 31. Partly: 4. Does not support: 1. Dead: 0.

• Supports:
  • Hasura permissions URL and quote
  • Triplit permissions.mdx:45-62 and the line-150 quote
  • Platformatic rules.md:55-81
  • X-PLATFORMATIC-ROLE (user-roles-metadata.md:16)
  • Typhex README:114-245 (lines 225, 245)
  • Typhex npm date
  • Tinqer package.json:22-24
  • Tinqer npm date
  • Orange README:711,723
  • Orange npm date
  • ZenStack policy-handler.ts:83-88
  • unpkg @effect/sql@0.12.0/src/Model.ts:605-612
  • Wasp ChangeLog.md:93-99
  • Wasp ChangeLog.md:610-612
  • Prisma ARCHITECTURE agent passage (lines 117, 124)
  • TS 7.0 quotes 1 and 2
  • @typescript/typescript6 6.0.2
  • oxc-parser 0.152.0
  • @swc/core 1.16.13
  • langium 4.4.0 and ZenStack’s use of it
  • https://www.convex.dev/llm-leaderboard (200; both tracks present)
  • https://zenstack.dev/blog/code-as-doc (200)
  • https://zenstack.dev/blog/ai-agent (200)
  • Supabase/Triplit quote
  • Gel quotes (“shutting down…”, “fully shut down on Jan 31 of next year”)
  • InstantDB quote and code
  • Zero quote
  • Keystone mutation-filter quote
  • Payload Query quote (casing aside)
  • @casl/prisma 2.0.2 date 2026-07-06
• Partly:
  • PostGraphile (meaning right, quote not on page)
  • Platformatic overview.md:8-16 (misquote)
  • AutoCodeBench (problem count right, “repository-level” unsupported)
  • lambdaorm npm page (the lambda syntax is shown; “parsed from source” cannot be verified)
• Does not support:
  • “the search performed is recorded in Sources”

R2.6 Content lost in the rewrite?

Nothing correct was lost from the project list:

• All 17 profiled sections remain.
• §1.18 gained Prisma 8, PocketBase, Medusa, LoopBack, Feathers, Blitz, Deepkit and Pothos, and dropped only the “TypeScript” row (its claim is now correctly handled in §3.8) and Zod’s weekly downloads.

The comparison table kept all round-1 columns (Declared in, Derives, Auth model, SQL push-down, Extension model, Codegen vs reflection, Generated code committed) and added “Hlth”. The only regressions are the Laravel health data (R2.4 #18) and jsmql’s npm figures, which were never present (R2.4 #19).

R2.7 Criteria after round 2

---

Round 3 final check

Reviewer, 2026-10-01. Checked the round-3 document (13,101 words, ## Revision log (round 3)) against primary sources. I cloned Tinqer at commit 41598b3 (2026-09-28) into /Users/svallory/work/mesh/scratch/ts-prior-art-review/tinqer.

Final verdict: ACCEPT-WITH-FIXES. No further revision round is planned. The document is reliable for design use when read together with the residual-error list below. Every substantive round-1 and round-2 error is fixed at source. What remains:

• one wrong description of how Tinqer reports unsupported constructs, the point that matters most for mesh;
• three markdown tables broken by round 3;
• a handful of small inaccuracies.

R3.1 Round-2 “still wrong” items

R3.2 Tinqer in depth: document statements vs source

R3.3 Known-complaints sample

I checked 41 issue citations across 37 projects: the 17 profiles plus the §1.18 table. All 41 exist, are open, and match the cited title and comment count.

• Profiles: zenstack #717, remult #570, wasp #1088, redwoodjs/graphql #8861, redwoodjs/sdk #632, keystone #8774, payload #7312, encore #1641, convex-backend #96, adonisjs/core #4510, nestjs-query #1538, casl #8, nest #1006, platformatic #5042, amplication #4654, hasura #9592, graphile/crystal #2564, triplit #196, instant #2546, typespec #2463, effect #6378, trpc #3297, orpc #1389.
• §1.18 table: casbin #710, prisma/orm #1798, drizzle #376, kysely #320, zod #475, pocketbase #159, medusa #8548, directus #7237, strapi #20870, loopback-next #2043, feathers #1337, blitz #586, deepkit #562, pothos #534, gel #3946, cerbos #2574, opa #6559, appsmith #1911.

The caveat is labelling (residual #7).

R3.4 Fresh citation sample (32, none checked in earlier rounds)

Supports: 30. Partly: 1. Does not support: 1. Dead: 0.

• Supports:
  • the 21 §1.18 and §1.14/§1.17 issue citations (prisma #1798 through orpc #1389)
  • laravel/framework stars
  • laravel/framework release
  • PocketBase API-rules quote
  • Medusa Data Model URL
  • jsmql 0 open issues
  • Wasp FileDraft.hs:3,26,45 (Writeable)
  • Tinqer README:509 (RETURNING)
  • Tinqer README:253 (“fails closed”)
  • Tinqer one contributor
  • Typhex one human contributor
• Partly:
  • parse-query.ts:22 (the line is 23)
• Does not support:
  • Typhex “1 open issue”: kalyvasio/typhex has 0 open issues and 3 open dependabot PRs; GitHub’s open_issues_count = 3 counts PRs.

R3.5 Did round 3 lose or break correct content?

No correct facts were lost. Round 3 broke formatting in four places, all listed as residuals #2-#5: the §1.18 and §2 table headers, the §3.8 table, a duplicated Summary line, and §5 ordering.

Residual errors (for readers)

Each entry gives the line in 06-ts-prior-art.md, what is wrong, and the correct fact with its source.

1. Lines 628-631 (also the “Unsupported →” cell of the Tinqer row at line 782): how Tinqer reports unsupported constructs.
   • Wrong: “unmappable AST nodes throw from the visitor — the guide’s examples show messages such as ‘UPDATE requires a WHERE clause…’”.
   • Correct: the visitor does throw specific errors, e.g. Unsupported AST node type: ${type} (packages/tinqer/src/visitors/index.ts:131) and Unknown identifier '${name}'. Variables must be passed via params object… (visitors/common/identifier.ts:59-62). But parseQuery wraps the whole parse in try/catch, logs with console.error("Failed to parse query:", error) and returns null (parser/parse-query.ts:153-159). The plan then throws a generic error, so the specific reason never reaches the caller except through console output:
     • “Failed to parse query” (plans/select-plan.ts:415-416)
     • “Failed to parse update builder or not an update operation” (plans/update-plan.ts)
     • the corresponding delete and insert messages
   • “UPDATE/DELETE requires a WHERE clause or explicit allowFullTableUpdate()/allowFullTableDelete()” is a SQL-generator safety check in the adapters (pg-promise-adapter/src/generators/update.ts:71, delete.ts:25; same in better-sqlite3-adapter). It is not an unsupported-construct report.
2. Lines 486-487 (§1.18) and 512-513 (§2): broken markdown tables.
   • The header rows have 5 and 10 cells but the delimiter rows have 4 and 9. GitHub-flavoured markdown does not render a table when the counts differ, so both appear as raw text.
   • Line 530 (Payload row): `boolean \ | Where` splits the cell. It should be `boolean \| Where`.
   • The data in these tables is correct.
3. Lines 768-769 (§3.8 parser table): malformed rows.
   • The 3xpr and “Hand-written parser” rows have 8 cells under a 4-column header; they were pasted from the §3.9 table.
   • Read them as: lambdaorm’s parser is the npm dependency 3xpr ^1.15.27, unverified because the build is obfuscated; jsmql uses its own hand-written parser and targets MongoDB.
4. Lines 30-32 (Summary): the token figures are printed twice. The facts are correct: 2,505,796 vs 4,049,413 total tokens.
5. Lines 875-919 (§5): structure.
   • §5.3 appears before §5.2.
   • The intro (line 877) still says “Two lists”; there are three: for (§5.1), neutral (§5.3), against (§5.2).
   • The content is correct.
6. Line 599: Typhex “1 open issue”. Correct: 0 open issues and 3 open dependabot PRs; one human contributor (kalyvasio, 49 commits) plus dependabot[bot] (gh api repos/kalyvasio/typhex/issues?state=open).
7. “Known complaints” cells (§1 profiles, §2 and §1.18 tables): many are feature requests or discussions, not complaints.
   • Feature requests or discussions: zenstack #717, wasp #1088, typespec #2463, trpc #3297, amplication #4654, nest #1006 (“Who is using Nest in production?”), kysely #320, pocketbase #159, pothos #534, appsmith #1911, opa #6559, cerbos #2574.
   • Every issue exists as cited, but read the column as “most-discussed open issue”. Not every cell names a defect.
   • The AdonisJS Lucid row (line 525) cites adonisjs/core#4510, which is a core-repo issue, not a Lucid one.
8. Line 636: autoParams cited at parse-query.ts:22. The line is 23.
9. Lines 432 and 534 (Zero complaints): “issues not searchable at rocicorp/zero (404)”. Zero’s issues live in rocicorp/mono, which is searchable. This is an omission, not a false fact.
10. Line 685: the [unverified] tag on LinqBox, sqlizer, ts-sql-query and LinqToTypeScript is unnecessary. I verified their stars and dates in round 1 (150★, 18★ / last push 2019, 318★, 157★).

Everything else I checked across the three rounds is correct as written.

Tinqer: verified account

How it works:

• Tinqer is a run-time LINQ-style SQL builder for PostgreSQL (pg-promise) and SQLite (better-sqlite3). You pass a builder arrow function such as (q, params) => q.from("users").where(u => u.age >= params.minAge).
• On every call it does queryBuilder.toString() (parse-query.ts:83) and looks the text up in an LRU parse cache (default on, 1024 entries, keyed on the source text).
• On a cache miss it parses the text with oxc-parser 0.150.0, takes the first statement’s expression, walks it with its own visitors into a QueryOperation tree, auto-extracts literals as bound parameters, and the adapter generates parameterised SQL.

Supported subset (README:560-572):

• === !== > >= < <= (plus ==/!= in code), && || !, + - * / %
• string .includes/.startsWith/.endsWith/.toLowerCase/.toUpperCase
• ?? and ?.
• array .includes (becomes IN)
• case-insensitive helpers, window functions, opt-in full-text search

Limits, documented:

• No closures. Outer variables must go through the params object (docs/guide.md:1749, README:598). An unknown identifier throws.
• Row filters (withRowFilters, (row, ctx) => …) apply to SELECT/UPDATE/DELETE, not INSERT. Every table needs a filter or null. Context is read only as ctx.key. A missing context fails closed.
• SQLite ignores RETURNING. Right and full joins are not supported.

Limits, from the code:

• Error reporting is poor. Specific parse or visitor errors are caught, logged to the console and turned into a generic “Failed to parse query” (parse-query.ts:153-159, select-plan.ts:415-416). There are no source spans.
• The top-level builder must parse as a single expression statement, and the visitor only handles ArrowFunctionExpression lambdas (parse-query.ts:103-115, visitors/index.ts:116). So builder functions transpiled from arrows to function (ES5 targets) would fail to parse. This is my inference from the code, not tested.
• Any tool that injects code into function bodies would make toString() return foreign identifiers that the visitor rejects; coverage instrumentation such as Istanbul is the obvious example. Also an untested inference.
• Static types come from TypeScript generics, but the check that matters runs only at run time. Code can type-check (for example, a closure variable) and still fail at run time.

Maturity: a one-person project (jeswin, 405 commits), 24★, 0 open issues, MIT, 8 npm versions from 0.0.21 (2025-10-28) to 0.0.28 (2026-09-28). Downloads per week: about 228 for core, 214 for the pg adapter, 243 for the SQLite adapter. It is a working, well-documented reference design for toString-based lambda-to-SQL with row-level policies, not a production precedent.