Model writes DB migrations without reading source data structure first, causing repeated schema gaps

Open 💬 0 comments Opened Jul 7, 2026 by patrickadamsprofessional

Summary

When asked to migrate data from a blob/file store to a structured database table, the model repeatedly writes the migration SQL and sidecar table code without first reading the full source data structure (the actual JSON files, UI components, or schema definitions that define what fields exist). This causes the migration to omit fields, which the user then has to discover through broken behavior and bring up again — sometimes 4-6 times for the same data type.

Observed failure pattern

  1. User asks to migrate a data type (e.g. journal entries) to a proper DB table
  2. Model writes CREATE TABLE with only the fields it can infer from context (e.g. id, user_id, timestamp, date, title, body, tags)
  3. Model deploys and considers the task complete
  4. User discovers missing fields (rfc, sleep_log, symptoms, diagnosis_links) through broken UI behavior
  5. Model acknowledges the gap as "on me" and repeats the pattern on the next data type

This happened in the same session with:

  • Medicationsdose_unit, frequency, prescriber, quantity_dispensed, days_supply, last_fill_date all missing initially
  • Journal entriesrfc, sleep_log, symptoms, diagnosis_links still missing after migration was declared complete

Root cause

The model does not enforce a prerequisite step before schema work: read the actual source data (EFS JSON file, local journal.json, UI component props, JSON schema file) and enumerate every field before writing any SQL. It relies on inference from context and prior conversation, which is incomplete.

Expected behavior

Before writing any CREATE TABLE, migration SQL, or sidecar upsert function, the model should:

  1. Read the authoritative source data (actual JSON file or schema) to get the complete field list
  2. Show the user the enumerated fields and confirm before writing SQL
  3. Block on this step — not proceed to writing code until the source has been read in the same turn

Suggested fix / hook opportunity

A PreToolUse hook or guardrail that detects Write calls to migrations/*.sql or sidecar table code and checks that the same turn included a Read of the relevant source data file. If not, block with: "SCHEMA WORK BLOCKED: read the source data structure first."

Impact

Real patient data with missing fields in production. Requires repeated correction sessions. User frustration from having to re-raise the same gap multiple times.

View original on GitHub ↗