A coding suggestion I wanted to test was simple: when line-by-line review becomes a slog, generate an artifact that makes a change easier to understand and trust. One concrete version is to ask a separate agent to write a black-box validator before the implementation agent changes the code. The validator should define observable behavior without being steered by the eventual implementation.

I tried that on Fsdb, an F# database server targeting observable MySQL 8.4 behavior. Then I kept working for several more rounds before judging the experiment. This is a report on what happened, rather than a claim that one workflow won.

The two workflows

Fsdb already had a fairly demanding development loop. For a compatibility gap, we probe MySQL 8.4, turn the observed behavior into a focused regression, implement the change, run the full suite and relevant differential lane, review the diff, and update GAPS.md. For performance work, we also measure the suspected bottleneck before accepting an optimization. The implementation and its focused test ordinarily come from the same working loop.

The proposed variation kept those checks and added independent authorship before implementation. A separate agent would write a validator against the public behavior first. The implementation agent would have a proof to satisfy, not just its own newly written test. That distinction matters: “produce a useful proof artifact” was already normal for Fsdb; “have another agent define it before seeing the fix” was the experimental step.

The test task was a repeated embedded prepared lookup. The validator used the public Db API to check that a prepared query handled changing parameter values, SQL NULL, missing rows, and the database selected when the statement was prepared. It passed on the old code. The implementation then cached the function registry while its session inputs stayed unchanged, and the same validator passed afterward. A separate regression covered changing database, generated-ID, and time-zone values. Review caught a cache-lifetime risk and changed the stored functions to capture only the values they needed; that catch came from implementation review, not uniquely from the independent validator.

The same-host A/B record used that validator's workload for five alternating 500-call trials. Reused PreparedCommand.QueryValues moved from 94.9 to 67.5 µs per call and from 321,621 to 131,993 allocated bytes per call. That is strong evidence for the cache on that workload. It does not tell us whether independent authorship made the implementation faster or safer than the ordinary process would have.

What the subsequent work added

I waited through real work rather than comparing two prompts in isolation. One later one-hour-plus window contributed 20 commits covering spatial reference systems, UTM transforms, geographic topology, and cleanup. Its MySQL oracle findings caught substantive mistakes: the NAD27 same-datum transform initially took an unnecessary round trip through WGS 84, and a shared-meridian polygon boundary was initially classified incorrectly. Focused regressions changed both implementations. The window ended with 3,377 passing tests and a 139-case, 18,222-step MySQL 8.4.11 contract run whose nine differences were the already documented identifier-case configuration signatures. No independent pre-change validator was authored in that window.

The next twelve commits, from 10:51 to 12:07 Oslo time on 11 October, extended materialized correlated equality and range lookups, proved a composite probe reduced residual work, and profiled the point-lookup path.

A project-backed stage profile corrected an interpretation error: the warmed text handler reuses a cached parsed statement, so a separate parser timing cannot be added to every handler call. A candidate shortcut for no-hint statements failed to improve measured latency and was removed. A same-fixture prepared profile then compared cached text and reused prepared handling. Runtime allocation tracing identified avoidable warning-suppressed coercion for exact integer index probes and full defaults-map reconstruction for single global-variable reads. The resulting integer-probe change saved about 3.4 KiB per call, and the global-variable change saved a further 10.4 KiB per call on that fixture. The separate short process runs did not establish a latency gain for either change.

That window used benchmarks, a trace, a focused consistency test, self-review, the full suite, and MySQL differential contracts. It ended at 3,385 passing tests. The pinned MySQL 8.4.11 run again covered 139 cases and 18,222 steps, with exactly the same nine case-and-step differences as the preceding run. The latest run's manifest path and method are recorded with the benchmark. The composite-probe test was a proof, but it was not written by a separate agent before the implementation.

I rechecked the conclusion against the next nine commits, through the later status-counter pass. The SQL-mode reparse measurement found about 1.1 KiB less allocation per prepared call, while its separate-process after run was slower; it cannot establish a latency improvement. The shared planner-set measurement found about 5.1 KiB less allocation per call and likewise did not establish a latency gain. MySQL probes then guided four regex-compatibility commits and two wire-byte status commits. A two-connection oracle check showed that FLUSH STATUS also resets the other live connection's session byte counters, prompting a second implementation pass and regression. The oracle record captures that correction. No second independent pre-change validator was authored. A subsequent status-counter probe also checked which values survive FLUSH STATUS, with the same 3,387 tests passing after the change. These nine commits add evidence about the ordinary loop, not a second A/B trial.

Two more commits extended that ordinary loop. The aborted-client change used a live connection regression to distinguish an abnormal established-client disconnect from a failed handshake. A view-dependency profile then found an unnecessary view-catalog expansion on physical-table reads. Its final paired trials measured about 1.2 KiB less allocation per cached-text call and 1.8 KiB less per reused prepared call. The separate short process runs do not establish a latency gain. Neither task used an independent pre-change validator.

The next sql_select_limit investigation adds another useful distinction between a proof and a complete compatibility claim. Native MySQL probes established that the variable caps top-level SELECT, UNION, and selected metadata SHOW results, while leaving nested and mutation-source queries alone. A focused regression now covers those paths, prepared execution, FOUND_ROWS(), assignment diagnostics, and column metadata when a SHOW result is empty. The oracle also exposed an EXPLAIN difference. Follow-ups now reflect the implicit limit in top-level SELECT plans and plain-branch UNION plans, including their JSON hierarchy and audited, explicitly limited derived SELECTs. Mergeable or lateral derived sources, derived set operations, expression subqueries, MySQL cost details, and exact ANALYZE presentation remain open. The full suite passed 3,389 tests after those changes. This is another example of the existing oracle-and-regression loop revealing a boundary; it is not a new independent-validator trial.

A later same-host hot-path comparison checked whether that session-limit lookup taxed ordinary point reads. The first helper added about 152 bytes per cached text call and 120 bytes per reused prepared call against a pre-limit baseline. A simpler F# path reduced those measured differences to about 36 and 52 bytes per call, respectively, with all 3,389 tests passing. The process runs did not establish a latency change. This is another measured correction from the ordinary loop, not another independent-validator trial.

I checked the report again after the next regex-property change. A native MySQL 8.4.11 probe distinguished accepted ASCII and Basic_Latin property spellings from a .NET spelling that MySQL rejects. The recorded cases became a focused regression; the full suite reached 3,390 passing tests. This adds another concrete oracle-derived compatibility correction, but no independent pre-change validator. A further native EXPLAIN probe found that MySQL puts correlated scalar projection subqueries under select_list_subqueries and uncorrelated ones under optimized_away_subqueries within the owning SELECT or UNION branch. A second native probe corrected the first regression's placement of correlated subqueries: MySQL attaches select_list_subqueries to the query block, not the table. The corrected implementation covers audited simple projection cases in both single SELECTs and UNION branches; 3,391 tests pass. Further clause probes placed audited dependent scalar WHERE subqueries under the scanned table, HAVING and ORDER BY subqueries under their operation wrappers, and projected scalars under grouping, ordering, or duplicate removal when those operations own the result. Another probe and regression now cover audited ordering around grouping, including a case where the traditional Fsdb row omitted MySQL's scalar-order filesort. An audited DISTINCT query ordered by its single projected scalar alias or ordinal now places the sort and temporary table under duplicate removal, matching MySQL. Subsequent probes also placed independent order scalars under grouping or duplicate removal, and kept dependent projection-plus-WHERE and projection-plus-HAVING scalars under their separate owners. Other DISTINCT/ordering forms, multi-clause combinations, and mixed derived/scalar plans remain open. This is another oracle-to-regression iteration, not a new independent-validator trial.

The next allocation investigation used a Release point-lookup runner and an EventPipe allocation sample to locate a plausible source of fixed handler cost. Moving two synchronous execution-limit scopes to thread-local storage reduced measured allocation by 4,734 bytes per warmed text call and 3,834 bytes per reused prepared call on that fixture. The trial data and caveats show that short-run latency drift prevents a speed claim. A new concurrent-session regression checks that distinct GROUP_CONCAT and CTE recursion limits stay isolated; the full suite passed 3,394 tests. This was another profile, fix, and regression round in the ordinary workflow, with no independently authored pre-change validator.

Subsequent commits extended the EXPLAIN oracle work to audited mixed-clause plans, derived-source predicate subqueries, and scalar subqueries inside materialized derived sources and UNION branches. The regressions were split by plan shape so a failure identifies the broken relationship. These changes narrow the earlier mixed-plan caveat; they do not make EXPLAIN generally complete. Two further same-host allocation measurements found that synchronous handler scopes could avoid some AsyncLocal allocation while public scopes retained their task-flow behavior. On the fixed point-lookup fixture, the variable/time-zone scope change saved 6,480 bytes per warmed text call and 6,184 per reused prepared call; the later function-database scope change saved another 1,424 and 3,204 bytes per call, respectively, against its own immediate baseline. Concurrent-session and delayed-task regressions cover the key isolation boundary. The full suite reached 3,402 passing tests. Short-run latency drift does not justify a speed claim. These are separate measurements at successive revisions, not a controlled A/B comparison of development workflows.

One further measured change skipped temporary session decoration when the stored-function catalog was empty. It saved about 1.2 KiB per warmed text call and 1.0 KiB per reused prepared call on the same fixture, while the 3,402-test suite still passed. Populated catalogs kept the existing behavior. This adds another ordinary-loop data point, not a workflow comparison.

I revisited the report after the next six commits, through the audited REGEXP diagnostics. Two successive allocation profiles measured another 964 and 1,253 bytes less allocation per reused prepared call, respectively, against their own immediate baselines. The stored-function change also measured 1,521 bytes less per warmed text call. The short latency trials still do not establish a speed gain, and these successive measurements should not be added into a single controlled result. MySQL probes also refined supplementary-character behavior in negated POSIX classes and Unicode properties, then pinned down several malformed-pattern error codes and positions. The full suite reached 3,406 passing tests; the 139-case, 18,237-step contract run retained the same nine documented identifier-case differences. These rounds strengthened the ordinary workflow's evidence, but added no independent pre-change validator.

I rechecked once more after six more commits. MySQL-oracle probes refined possessive REGEXP quantifiers, letter escapes, and the Any Unicode property. The charset work then moved from valid binary-literal decoding to invalid-byte behavior in CONVERT ... USING: UTF-8, UTF-16, UTF-32, ASCII, UCS-2, and incomplete lead bytes in eight legacy multibyte families now have audited value-and-warning cases. The finding record also keeps the single-byte codec boundary explicit. The newest focused regression failed before the fix, and all 16 new MySQL comparison steps passed afterward. The full suite reached 3,414 passing tests; the 139-case, 18,294-step contract run still had exactly the same nine identifier-case differences, with no new mismatch. This strengthens the ordinary loop's compatibility evidence, but is still not a second independent-validator trial.

The next seven commits make the charset finding more specific. A full high-byte sweep of the 25 supported single-byte charsets showed that MySQL preserves source bytes even where decoding reports an invalid character; Fsdb now keeps those bytes and matches the audited warning sets. Follow-up probes separated source decoding from target encoding, checked conversions of already encoded strings, and established how CAST(... AS CHAR CHARACTER SET ...) retains its target charset and handles a character or byte width. The CONVERT finding and CAST finding now record those boundaries. The full suite reached 3,423 passing tests; the 139-case, 18,347-step contract run still had only the same nine documented identifier-case differences, and the five new binary-CAST steps passed. This changes the breadth of the compatibility evidence, but the workflow comparison still has just one independently authored pre-change validator.

One subsequent correction found another boundary: MySQL rejects an unknown charset before evaluating CONVERT ... USING or CAST(... CHARACTER SET ...), including NULL input and an unchosen IF branch. Fsdb's focused regression now covers that timing. All four new differential steps passed; the 139-case, 18,351-step run retained the same nine identifier-case differences, and the full suite reached 3,424 passing tests. This is another ordinary-loop correction, not a second trial of the independent-validator workflow.

I revisited the finding after five more commits. MySQL probes established that typed CONVERT shares the audited CAST target behavior, explicit BINARY(n) casts use byte widths, and national, legacy, and combined character modifiers have distinct warning and collation rules. The last round overturned the CAST finding's remaining “outside this audit” note: MySQL accepts CHAR ASCII BINARY and CHAR BINARY UNICODE, and the modifier order determines warning order. A failing focused regression preceded the fix; the final finding record now states both accepted and rejected forms. The full suite passed 3,432 tests. All six new cast comparison steps passed in the 139-case, 18,381-step MySQL 8.4.11 contract run, whose nine differences were the same documented identifier-case signatures. This adds a concrete correction to the ordinary workflow sample, but no new independent pre-change validator. It does not change the workflow verdict.

I rechecked that verdict after five more CAST commits. MySQL 8.4.11 probes showed that CAST and typed CONVERT accept a narrower target grammar than column declarations, retain CHARACTER(n) widths, and validate precision, scale, packet-sized widths, and negative widths at different stages. The CAST target finding records the supported forms and diagnostic order; the gap record keeps the remaining conversion boundary open. Focused regressions and a 3,437-test suite passed. The latest 139-case, 18,432-step differential contract retained the same nine identifier-case differences, while the six new negative-width steps passed. This changes the detailed compatibility result, but it supplies no second independently authored pre-change validator and therefore does not change the workflow comparison.

The next five CAST commits sharpened that finding again. The MySQL oracle distinguished negative target precision, unsigned character widths, DECIMAL range clamps and warnings, and DOUBLE versus FLOAT text overflow. In the last round, a focused regression first failed because Fsdb omitted a DOUBLE conversion warning; the implementation and new differential steps then matched MySQL. The revised CAST finding records these narrower outcomes and keeps other conversion contexts open. The full suite now passes 3,441 tests. The 139-case, 18,487-step contract has the same nine identifier-case differences and no new mismatch. This adds evidence that the ordinary oracle-and-regression loop keeps correcting its own findings. It still supplies no matched trial or second independent pre-change validator.

I checked the finding again after ten further CAST commits. The oracle exposed cases the earlier CAST summary had left open: finite text beyond .NET's decimal range, the high-exponent conversion boundary, non-ASCII digits in numeric prefixes, and different warning rules for introduced, computed, and stored binary values. A cleanup commit then classified binary sources by origin rather than by a list of function names. The last probe showed that text warning previews stop at NUL, while binary warnings escape that byte. The revised finding records the audited boundaries and still marks general wide DECIMAL values and other source expressions as open. The full suite passed 3,449 tests. The 139-case, 18,571-step MySQL 8.4.11 contract run had the same nine documented identifier-case differences and no new mismatch. These rounds strengthen the evidence for the existing oracle loop; they do not create another independent-validator trial.

I checked the result again after three more commits. The MySQL oracle exposed a distinction between text and binary warning previews, then clarified how YEAR casts normalize temporal and binary sources. Focused regressions and differential cases accompanied the fixes. The latest completed full suite passed 3,456 tests; its 139-case, 18,663-step MySQL 8.4.11 contract run retained the same nine identifier-case configuration differences and no new mismatch. A subsequent TIME-cast fix began with a failing regression for invalid text, partial text, and overflow. The completed 3,457-test suite passed, and all 14 new value-and-warning steps passed in the 139-case, 18,677-step MySQL contract; the same nine configuration differences remained. A follow-up matched five more leading- and trailing-space warning cases, including warning order when both truncation and a superfluous delimiter apply. The 3,457-test suite passed again, and all 24 audited TIME value-and-warning steps passed in the 139-case, 18,687-step contract run. The nine configuration differences were unchanged. These checks sharpen the compatibility result. They still do not create a second independent pre-change validator or change the workflow conclusion.

A further TIME delimiter round used MySQL probes to separate one- and two-space internal delimiters from three spaces before trailing junk, and to distinguish a clock-time prefix from a numeric prefix. After a small parser cleanup, 3,457 tests passed. All 38 audited TIME value-and-warning steps passed in the 139-case, 18,701-step MySQL contract; the same nine identifier-case differences remained. This is more evidence that the ordinary oracle loop can refine a finding. It still does not supply a matched workflow trial.

The next source-type correction began with a regression showing that Fsdb returned zero for CAST(b'1' AS TIME) where MySQL returns NULL and warning 1292 for the underlying byte. Bit and hex literals and stored BIT/VARBINARY columns now match the audited values and escaped-byte diagnostics. The 3,457-test suite passed; the 139-case, 18,715-step MySQL contract retained only the same nine identifier-case differences. This adds a real ordinary-loop correction, but still no second independent-validator trial.

That probe also led to a finding correction: MySQL's NUL warning preview depends on whether the source result is binary or text, not whether the expression is a literal or computed. Binary CONCAT escapes control bytes; a text result stops its preview at NUL. A focused regression failed before the fix. The TIME-cast logic was then moved into a named helper, 3,457 tests passed, and all eight new comparison steps passed in the 139-case, 18,723-step MySQL contract. The same nine identifier-case differences remained. The correction sharpens the compatibility finding, but does not change the workflow comparison.

The next CHAR byte-assembly fix replaced Unicode-character construction with MySQL's binary bytes. A pre-change regression showed HEX(CHAR(128)) returning C280 instead of 80; it now also covers integer wrapping, rounding, NULL arguments, and downstream TIME warnings. The full suite passed 3,458 tests. Direct returned bytes and all new CHAR comparisons passed in the 139-case, 18,730-step MySQL contract, which retained the same nine identifier-case differences. This strengthens the ordinary-loop sample, but still provides no matched comparison of development workflows.

I rechecked that finding after the following CHAR text-argument change. MySQL treats a string argument as an integer prefix: CHAR('1.5') produces byte 01 and warning 1292, whereas numeric CHAR(1.5) rounds to byte 02 without that warning. The regression checks ordered warnings, invalid and binary text, and signed or unsigned overflow before 32-bit byte assembly. The full suite passed 3,459 tests. I inspected the latest 139-case, 18,734-step contract manifest from that round: all four new value-and-warning steps passed, and its nine nonpassing steps are the same documented identifier-case signatures (eight result mismatches and one oracle-contract drift). CHAR(... USING charset) and other source domains remain open. The new evidence refines the compatibility finding, but it still comes from the ordinary oracle-and-regression workflow.

I re-investigated the finding after seven further CHAR commits. The earlier note that CHAR(... USING charset) was open is now outdated: MySQL probes and regressions cover its audited byte decoding, coercibility, and invalid-byte warnings. Other rounds pinned down binary warning previews, BIT and numeric overflow, stored DOUBLE warnings, and JSON conversion values and diagnostics. The latest round found a real planner boundary: Fsdb initially evaluated CHAR(payload) on all rows before applying a descending top-N order, so its warning rows disagreed with MySQL. A failing regression led to deferred projections for a small set of pure expressions, followed by a separate grouped-row warning fix. All six new ordering and grouping comparison steps pass. The full suite passes 3,465 tests; the 139-case, 18,771-step MySQL 8.4.11 contract retains only the same nine documented identifier-case signatures. The revised CHAR finding still marks other source forms and more complex plans as open. This changes the compatibility details and confirms the ordinary workflow caught another error; it adds no second independent pre-change validator or matched workflow trial.

I re-investigated the CHAR finding after eight further commits. MySQL probes exposed two limits in the previous summary. JSON values coming through UNION and CTE sources had lost their JSON type in Fsdb, and an expression view labeled the CHAR conversion warning with its exposed alias instead of the defining JSON function. Both produced failing regressions before their fixes. The intervening rounds also checked more JSON-returning builtins, JSON mutation sources, and computed numeric overflow. The revised finding now records direct, expression, and UNION view behavior while leaving deeper view nesting, user-defined JSON origins, and more complex plans open. The full suite passed 3,472 tests. The latest 139-case, 18,819-step MySQL 8.4.11 contract passed all 11 new view steps and retained exactly the same nine documented identifier-case differences as the preceding 18,808-step run. This changes the compatibility finding and demonstrates another correction by the ordinary loop. It still adds no independently authored pre-change validator.

I checked the finding again after seven further commits. The earlier open question about deeper view nesting is narrower now: audited nested, star, mixed-projection, and joined views preserve the JSON function's warning name. The latest MySQL probes exposed a more precise boundary. A mergeable derived query preserves the underlying column or function name through an alias, while a materialized derived query, limited view, or TEMPTABLE view uses its exposed alias. Fsdb initially treated those sources alike; focused regressions and native comparison steps now cover the distinction. Joined warning row numbers remain an observed mismatch, and other view shapes and complex plans remain unaudited. The full suite still passed 3,472 tests. The latest recorded 139-case, 18,864-step MySQL 8.4.11 contract has 18,855 passing steps and the same nine documented identifier-case differences. It adds useful compatibility evidence, but no second independently authored validator or matched workflow comparison.

I rechecked the result after the next thirteen commits. The keyless-insert load test found that eight Fsdb writers achieved only 1.35× the one-writer rate, while MySQL reached 2.54× on the same workload. Those rates compare an in-memory Fsdb with durable MySQL, so they are a scaling signal rather than a fair absolute-throughput contest. A proposed candidate fast path did not improve the eight-writer result and was removed. A narrower document-index shortcut reduced allocation on a direct storage fixture, but the wire benchmark did not establish a throughput gain. The measurements and retention checks make the performance finding useful without converting it into a workflow comparison.

The compatibility result changed more materially. A fresh MySQL oracle check found two costed, mixed-type join result mismatches that the older nine-difference summary did not include. The physical access path can change which joined text value owns the numeric IN filter; the existing transfer covers explicit join order or a MATCH owner, but not these costed plans. The gap remains open. Separate oracle-led regex rounds added ASCII and Unicode hex-digit, join-control, bidi-control, regional-indicator, and emoji-modifier properties, with failing regressions and matching differential steps. The supplementary-property finding also records a low-surrogate false match exposed by the new regression. These rounds refine regex coverage, but no independent pre-change validator was authored. The contract at that point had 139 cases, 18,880 steps, and eleven known differences: the earlier nine identifier-case signatures and these two costed-join mismatches. The full suite passed 3,478 tests. This corrected the compatibility count at that point without changing the workflow conclusion.

The next join fix then closed both new result mismatches. Fsdb now chooses the smaller unindexed source first for the audited two-table numeric-IN equality join when the other source has a matching index. That choice also determines which text key receives the numeric filter; an index on the other source leaves the original owner in place. The regression failed before the fix and now covers one and two label rows plus the competing-index counterexample. The pinned finding and contract record from that round show 139 cases, 18,882 steps, and nine remaining differences, exactly the earlier identifier-case signatures. The full suite still passed 3,478 tests. Other costed join shapes remain open. This is a meaningful compatibility correction produced by the ordinary oracle-and-regression loop, but it is still not a matched workflow trial.

A wider fresh-table matrix then found a new boundary. With three names rows and three unindexed labels rows, MySQL returns both matching IDs; Fsdb still returns one. Two-name/two-label and competing-index controls show why a blanket row-count rewrite would be wrong. A follow-up closed two other singleton-source mismatches, while leaving this equal-cardinality case open. That round's 139-case, 18,895-step MySQL contract had ten known differences: the original nine identifier-case signatures and this one costed-join result mismatch. All 3,478 tests passed. This revision changes the compatibility finding again, but it still gives no matched evidence that one development workflow is better overall.

A subsequent native MySQL recheck made that remaining mismatch more precise. On fresh three-by-three tables, ordinary SELECT repeatedly returns both IDs, while EXPLAIN ANALYZE for the same SQL reports one actual hash-join row. Forcing the primary index also changes the ordinary result to one ID. Disabling block nested-loop execution does not remove the two-ID result. The native oracle script now checks these paths separately. The ten-difference count remains valid for the maintained ordinary query contract; the plan instrumentation is evidence about an execution-path inconsistency, not a resolution of the result mismatch. This strengthens the case for checking the public result directly, but still does not provide another independent-validator trial.

The next connection check qualified that finding further. The connection that created and filled fresh tables kept returning two IDs; a second connection returned one, after which the first also returned one. MySQL showed the same TREE plan before and after. The maintained long-lived-connection contract still records ten differences, but an unconditional join rewrite to match its two-ID result would disagree with the other connection history. This changes the implementation decision, not the workflow verdict: the sample still lacks a second independently authored pre-change validator.

A later prepared-variable coverage pass added 46 table-backed, nested-query, and CTAS steps. All matched MySQL; the prepared CTAS retained a BIGINT column after a decimal reassignment. The full contract grew to 139 cases and 18,941 steps, with the same ten known differences, and 3,478 Fsdb tests passed. This narrowed an API compatibility gap without adding a second independent-validator trial.

A follow-up mutation contract added 21 prepared UPDATE, DELETE, and INSERT SELECT steps. Each matched MySQL on affected rows and stored values after decimal, text, and NULL assignments. The contract now has 140 cases, 18,962 steps, and the same ten differences; the Fsdb suite still passes 3,478 tests. This extends the audited behavior but does not change the workflow comparison.

A Greek-script regex fix then closed a real property-name mismatch. A regression failed with error 3685 before the change; separate MySQL and fsdb full-scalar scans agreed afterward on all 518 case-sensitive and 520 case-insensitive Greek members. The two new differential steps passed, bringing the contract to 140 cases and 18,964 steps with the same ten differences; 3,479 tests passed. These reusable oracle artifacts were created in the ordinary fix loop, not by a separate agent before implementation, so they strengthen the compatibility claim without supplying a second workflow trial.

A subsequent Greek Script_Extensions check found a related distinction: MySQL includes 13 shared marks and symbols beyond its case-sensitive Greek Script set. Independent full-scalar MySQL and fsdb scans now agree on all 531 case-sensitive and 532 case-insensitive extension members. A focused regression failed before the fix, and both new differential steps passed afterward. The contract reached 140 cases and 18,966 steps with the same ten differences, while 3,480 tests passed. This adds another reusable oracle proof to the ordinary fix loop; it still does not constitute a second pre-change validator trial.

I re-investigated that result after the next eight commits. The same MySQL-oracle method found that a Unicode block is not necessarily a script: Han, Latin, Cyrillic, Arabic, and Devanagari needed their own scalar membership and ScriptExtensions sets. Separate full-scalar scans of pinned MySQL 8.4.11 and Fsdb now agree on each audited set and its SHA-256 digest, including case-insensitive mode. The work also added the variation-selector property and refactored shared range construction and aliases. The latest finding records 3,486 passing tests and a 140-case, 18,978-step differential run with the same ten documented differences. Those numbers supersede the Greek-only snapshot above. The scans are strong evidence for the enumerated properties, but they were produced inside the ordinary fix loop; separate scan programs do not by themselves make an independently authored _pre-change validator. Other ICU properties and the costed-join mismatch remain open.

What this comparison can measure

The evidence supports narrow conclusions. The prepared-lookup validator existed before the cache, checked externally visible behavior, survived the code change, and doubled as a repeatable benchmark workload. The ordinary workflow also produced oracle cases, failing regressions, differential manifests, and measurements that caught errors and rejected an unhelpful shortcut. We can inspect those artifacts and reproduce specific claims.

We cannot infer a general productivity or correctness advantage from commit counts. The work items differed, the independent-validator condition had only one task, and the experiment did not assign comparable tasks to each workflow. Review minutes, agent cost, defects found only by the independent validator, and escaped defects were not collected consistently. A later green suite is evidence about the tested behavior, not proof that every untested behavior is correct.

A stronger comparison would predeclare which kinds of changes get an independent validator, then run several comparable tasks in each condition. It would record validator-writing time, implementation and review time, defects caught before merge, follow-up failures, and whether the resulting proof was reusable. Until then, the independent approach is best treated as a selective technique for a claim that is hard to assess from ordinary tests and a diff.

Results

The measured A/B trials compare Fsdb before and after the cache change; they do not compare development workflows. The subsequent compatibility and performance rounds broaden the ordinary workflow sample, but still provide no second independent pre-change validator or matched workflow trial.

Result: Keep the existing MySQL-oracle and failing-regression loop as the default for Fsdb. Use an independently authored, pre-change validator when the public behavior or performance claim is difficult to judge from the implementation and ordinary tests. The experiment shows that this can produce a valuable proof; it does not show that it is generally better than the old process.