miniml/.eval/wave2_bull_rebuttal.md

A minimal, embeddable semantic data modeling language for generating SQL queries from YAML model definitions. Inspired by LookML.

# WAVE 2 — THE BULL (rebuttal)

## The strongest opposing claim I must confront
Not the Bear's traction numbers (I already conceded those). The claim that actually threatens my thesis comes from the **Principal Engineer** and **Security Auditor**: MiniML's AST-based injection validation — which I cited in Wave 1 as "real code rather than marketing," my single strongest FOR-point — is **dead code**. `validateAstSafety` only runs inside `if (Array.isArray(ast))`, but `node-sql-parser.astify` returns an object for a single statement, so the allowlist never executes, and `SESSION_USER()` (a non-allowlisted function) passes the WHERE validator. [Verified independently — this is measured, not another agent's opinion.]

## Steel-man
In its strongest form: a semantic layer for LLMs competes almost entirely on *trust the guarantee*. My Wave 1 bull case rested on three legs — (1) the category thesis is now industry consensus, (2) the TypeScript/MCP-native seat is open, (3) the safety mechanism is genuinely implemented. If leg 3 is hollow, then MiniML at this moment offers the *same* "confident wrong/unsafe output" risk profile as a raw wrapper for the specific class of non-allowlisted functions, while advertising the opposite. A reviewer who runs one probe finds it, and the discovery poisons trust in every other claim. That is a direct hit on the differentiation half of my thesis, not a peripheral bug.

## Refutation / where it nets out
I can defend the *thesis* but not the *current artifact*, and I have to move.
- What survives: the regex layer (`performBasicSafetyChecks`) still blocks subqueries, DDL/DML, and comments — I confirmed `IN (SELECT …)` is rejected. So this is a broken allowlist, not an open SQL-injection hole. The architecture (LLM out of the SQL path, deterministic compile) is untouched by this bug and is still correct and still vindicated by dbt's 2026 benchmark (98–100% vs 84–90%). [SOURCED — dbt benchmark, Wave 1]
- What breaks: my "real code not marketing" point is falsified as of the shipped version. The safety claim is *aspirational code* with a one-line defect — closer to the "mcp" keyword situation than I admitted. Two independent load-bearing promises (MCP server, AST allowlist) turn out to be present-in-claim, absent-in-execution. That pattern — advertised-but-not-real — is now the story of the project, and it's the Bear's story, not mine.

This doesn't kill the thesis. It kills my *timeline optimism*. A project whose flagship safety control has been inert for 13 months through a 9-month dormancy, with tests green the whole time because they never asserted the control runs, is not a project on the cusp of converting a hot market — it's a promising prototype whose author's available bandwidth is the binding constraint (the Portfolio Manager's point, which I now weight more heavily).

## Updated viability score: 42/100 (was 58)
Moved by −16 on measured evidence: the dead-code validation (−12) falsifies my strongest differentiation claim, and the pattern of advertised-not-shipped features (−4) recalibrates my read of execution velocity. I hold above the kill cluster because the thesis is genuinely vindicated and every defect is genuinely cheap to fix — but I can no longer argue this is a "double down today" at 58. It's a "the bet is real, the horse hasn't left the gate, and the jockey is part-time."

## What would move me back up
The same crux as Wave 1, now with a correctness rider: within 90 days, does the author ship an MCP server, **fix and add a regression test proving the AST allowlist runs**, fix the two date bugs, and actually launch? Yes → 60+. Continued silence → converge toward the panel's low-30s.