Logic Probe Data

Successor: dsh-model-everything. Its counterpart skill is model-everything-datamodel, over model_datamodel_verify. Load that one when both plugins are installed; this skill stays accurate for logicprobe_datamodel_verify.

An unverified data model fails later. Model the schema and the migration, run them, and it becomes clear. Check every data claim before you act on it.

Methodology

Phase 1: Enumerate Data Claims

Read the document fully. Extract every verifiable data-model claim:

• Entity/table/collection names and fields
• Field types, nullability, defaults, unique constraints
• Relationships / foreign keys / referential integrity
• Data invariants ("always", "never", "must", "guaranteed")
• Migration claims ("rename field", "drop column", "backfill", "non-breaking")
• Copy/migration mappings ("source.a → target.x")

Phase 2: Verify Against the Model or Codebase

For each claim, run the relevant verification:

• Entity/field names: compare against actual schema, API contract, or code types
• Constraints: check declared required, unique, nullable, min/max, enum
• Relationships: check target entity/field exists and onDelete is coherent
• Migration: build BEFORE/AFTER DataModelV1 and check migration coverage

Phase 2 Trigger: Escalate to Data Model Verification?

Escalate immediately if the document contains ANY of:

• Schema/migration changes: added/removed/renamed fields, entities, constraints
• Data invariants: "all rows must", "counts must match", "no orphans", "never null"
• Copy/migration mappings: source-to-target field maps
• Before/after data-model equivalence claims: "non-breaking", "behavior preserved"
• Refactoring that changes field types, nullability, uniqueness, or relationships

Data Model Verification Pipeline

Document claims → Extract DataModelV1 → Runtime check:
  ├── DSH + `logicprobe_datamodel_verify` tool available → build DataModelV1 → call tool → structured report
  └── No engine available → Manual Verification Mode (references/data-model-guide.md)

Refactoring variant:
  Extract BEFORE DataModelV1 + AFTER DataModelV1
    → Run pipeline on AFTER model (DS/DA checks)
    → Compare BEFORE vs AFTER (DD1-DD4)
    → Flag any invariant that held in BEFORE but fails in AFTER

The DataModelV1 shape is in references/data-model-schema.md: entities, fields, keys, relationships, invariants, boundary checks, and the optional before/mapping/copy/migration/backup blocks. Those field names are the tool contract. A hand-written model that disagrees with them is rejected, not guessed at.

Checks

DS — Data structure

DA — Data adversarial probes

DD — Before/after data regression

Every # in these tables is a report field, not a name. Write what the check found for the reader (「回滚与备份不对称」), in their language; keep the id for a report field quoted verbatim, a baseline diff or a test name. The full rule is under "Writing the Answer" in the logicprobe skill.

Extraction Rule

Before writing any verification code, output a data-model table:

Entity   | Field      | Type    | Required | Unique | Nullable | Notes
---------|------------|---------|----------|--------|----------|-------
User     | id         | uuid    | yes      | yes    | no       | PK
User     | email      | string  | yes      | yes    | no       |
Order    | userId     | uuid    | yes      | no     | no       | FK -> User.id

Show this table to the user and ask for confirmation before generating the harness. The #1 failure mode is extracting the wrong data model.

Exception: If the runtime reports logicprobe interaction=auto, do NOT call ask_user_question. Instead: (a) cite evidence for every extracted entity/field/constraint, (b) round-trip the filled model back into a table and compare it with the extraction table, and (c) mark the report UNCONFIRMED.

When NOT to Escalate

Skip data-model verification when:

• The document makes no data-behavioral claims (pure API listings, file paths, numeric constants)
• The change is purely cosmetic (display names, comments)
• The data model is trivial (single entity, no constraints, no migration)
• The claim is purely structural (file paths, type names) — Phase 2 grep verification is sufficient

Non-Goals

• Not a SQL migration executor (Flyway/Liquibase/Atlas territory)
• Not a runtime data-quality platform (Great Expectations/Soda territory)
• Not a general array/object/file-content modeling engine
• Not a replacement for Atlas/Squawk/Buf/Oasdiff — it is the design-time plan verifier that sits before them