Unstable API shape and naming normalization errors (12 tasks)

1. What the model wrote:

   • Used { name: '...', public: true } in many table definitions where the schema expected only the table name metadata.
   • Preserved camelCase table names like categoryStats, damageEvent, orderDetail instead of normalized snake_case names like category_stats, damage_event, order_detail.
   • In one case used orderDetail as the table name instead of order_detail.

2. What was expected:

   • table({ name: 'account' }, ...)
   • table({ name: 'category_stats' }, ...)
   • table({ name: 'damage_event', public: true, event: true }, ...)
   • table({ name: 'order_detail' }, ...)

3. What the error says:

   • "Error: Invalid token: InvalidSignature"
   • The scorer failures were schema parity / describe failures, indicating the generated schema did not match the golden schema.

4. Why this happened:

   • The model likely overgeneralized from the guidelines and inferred a public: true flag for normal tables, even when the expected schema omitted it.
   • It also appears to have missed the benchmark’s naming convention for physical table names, especially snake_case normalization for multiword identifiers.
   • This suggests confusion between TypeScript symbol names and persisted table names.

5. Affected tasks:

   • t_031_unique_constraint
   • t_029_filter_and_aggregate
   • t_028_cascade_delete
   • t_024_event_table
   • t_025_optional_fields
   • t_014_elementary_columns
   • t_015_product_type_columns
   • t_018_constraints
   • t_030_two_table_join
   • t_019_many_to_many
   • t_012_spacetime_product_type
   • t_022_view_basic

6. AI guidelines gap:

   • The guidelines appear not to clearly distinguish when public: true is required versus omitted.
   • They also do not strongly emphasize canonical table-name normalization rules for benchmark schemas, especially camelCase-to-snake_case mapping.

Incorrect reducer/view body APIs and collection idioms (6 tasks)

1. What the model wrote:

   • const matchingOrders = [...ctx.db.order.category.filter(category)];
   • const existing = ctx.db.categoryStats.category.find(category);
   • ctx.db.categoryStats.category.update(...)
   • ctx.db.customer.id.find(...)
   • return [...ctx.db.announcement.active.filter(true)];

2. What was expected:

   • for (const o of ctx.db.order.category.filter(category)) { ... }
   • ctx.db.categoryStats.category.delete(category);
   • const c = ctx.db.customer.id.find(o.customerId);
   • return Array.from(ctx.db.announcement.active.filter(true));

3. What the error says:

   • Schema parity and reducer behavior checks failed; the benchmark reports "Error: Invalid token: InvalidSignature" for these tasks, and the join/view tasks also failed publish/schema validation.

4. Why this happened:

   • The model mixed incompatible query/update patterns, likely combining idioms from JavaScript arrays with SpacetimeDB indexed iterators.
   • It used find/update on an index path that the expected solution handled via delete-then-insert or direct indexed lookup.
   • It also wrapped iterators with spread where the benchmark expected Array.from(...) or direct iteration.

5. Affected tasks:

   • t_029_filter_and_aggregate
   • t_030_two_table_join
   • t_022_view_basic
   • t_021_multi_column_index
   • t_018_constraints
   • t_019_many_to_many

6. AI guidelines gap:

   • The guidelines likely did not clearly specify the canonical patterns for indexed iteration, upsert, and view materialization.
   • More explicit examples for filter(...), find(...), delete(...), and Array.from(...) would likely have prevented these API mismatches.

Aggregate query implementation mistakes: upsert, delete-then-insert, and count/sum logic (4 tasks)

1. What the model wrote:

   • const orderCount = matchingOrders.length;
   • const totalAmount = matchingOrders.reduce((sum, o) => sum + o.amount, 0n);
   • const existing = ctx.db.categoryStats.category.find(category); if (existing) { ...update... } else { ...insert... }
   • ctx.db.author.id.delete(authorId); without a clear explanation of cascade handling.
   • In several places it used seed data or reducer logic that did not reflect the intended benchmark pattern.

2. What was expected:

   • Manual iteration with accumulator variables:
     • let totalAmount = 0n; let orderCount = 0;
     • for (const o of ctx.db.order.category.filter(category)) { totalAmount += o.amount; orderCount += 1; }
   • Upsert via delete-then-insert:
     • ctx.db.categoryStats.category.delete(category);
     • ctx.db.categoryStats.insert(...)

3. What the error says:

   • The scorer reported parity failures for the aggregate task, indicating the reducer’s behavior and schema interaction were not aligned.
   • The benchmark logs again show "Error: Invalid token: InvalidSignature" during parity/sql checks.

4. Why this happened:

   • The model tried to implement a generic CRUD upsert instead of the benchmark’s exact delete-and-reinsert semantics.
   • It also used reduce(...) on the filtered iterator, which may not be the expected idiom for this SDK or for the benchmark’s schema-parity expectations.

5. Affected tasks:

   • t_029_filter_and_aggregate
   • t_028_cascade_delete
   • t_018_constraints
   • t_030_two_table_join

6. AI guidelines gap:

   • The instructions likely under-specified benchmark-required patterns for aggregation and upsert.
   • A concrete “delete existing row then insert replacement” example would have been helpful.

Sum/product type construction and table row encoding mismatches (4 tasks)

1. What the model wrote:

   • const Shape = t.enum('Shape', { circle: t.i32(), rectangle: Rect });
   • ctx.db.result.insert({ id, value: { tag: 'circle', value: radius } });
   • ctx.db.result.insert({ id, value: { left, right } });
   • a: { tag: 'circle', value: 10 }
   • b: { tag: 'rectangle', value: { width: 4, height: 6 } }

2. **