The original guide read as "myschema is the MySQL counterpart to
pistachio" and carried a lot of historical baggage from that
framing — explicit pistachio / pingcap-vs-vitess comparisons,
"inherited from pistachio" pointers in workflow / conventions, and
implementation notes that referenced the long-gone pingcap parser
(`TiDBStrictIntegerDisplayWidth`, `Length = -1`).

Rewrite the affected sections so the guide stands on its own:

- "What this is" describes the tool and its three subcommands
  directly; vitess is mentioned as the parser of record without the
  "we migrated from pingcap" history.
- The old "Why vitess (and not pingcap/tidb/pkg/parser)" section
  becomes "Parser quirks worth knowing" — same actionable bullets
  (vitess select-list shape, CREATE INDEX → AlterTable, CURRENT_TIMESTAMP
  paren handling, bareword default wrapping) without the comparison
  preamble or binary-size before/after.
- "Coverage vs. pistachio" → "Coverage". "Not yet implemented
  (intentional v1 cuts; would mirror pistachio)" → "Not yet
  implemented (intentional v1 cuts)".
- WITH CHECK OPTION bullet now attributes the limitation to vitess's
  AST (matches the actual code), not pingcap's.
- Database-name remap entry describes the proposed `-m old=new` flag
  on its own terms.
- "Inherited from pistachio. Apply the same discipline here:" /
  "Inherited from pistachio. The MySQL-specific bits sit at the
  bottom." preambles are removed; the workflow / conventions stand
  as myschema's own.
- Code conventions: `TiDBStrictIntegerDisplayWidth` reference removed
  (no longer used; MySQL 8.0+ + vitess naturally agree on integer
  type names). Index Length note now describes vitess's `*int`
  shape, not pingcap's `Length = -1` sentinel.

CLAUDE.md is a symlink to AGENTS.md so both files reflect the
change.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Two valid nits:

- Spell out the full module path for the MySQL driver
  (`github.com/go-sql-driver/mysql`) instead of the short
  `go-sql-driver/mysql` so a reader landing on the guide can
  match it against `go.mod` directly.
- The "bareword default wrapping" bullet listed ENUM / SET / CHAR /
  temporal as if normalizeColumnDefault were type-aware for the
  non-empty case. It isn't — for non-empty defaults it parses
  `SELECT <def>` and wraps anything vitess sees as a `*ColName`,
  regardless of the column's declared type. Rewrite the bullet to
  describe the actual code path (type-agnostic for non-empty,
  type-aware only for the empty-string special case via
  columnTypeAllowsEmptyStringDefault).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Switch "serialise" → "serialize" in the "What this is" intro to
match the existing "the serialized output is deterministic" comment
in model/table.go. AGENTS.md still has UK-spelled "normalise" in a
few places, but normalising every spelling difference is out of
scope for this docs PR — keep the change narrow to the one Copilot
flagged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

do drift

Previous wording claimed "Integer display widths don't surface from
either side on MySQL 8.0+, so no explicit stripping is needed."
That's wrong, and Copilot caught it. Verified against the live
docker-compose MySQL 8.0:

- catalog (`information_schema.COLUMNS.COLUMN_TYPE`) strips the
  display width — `INT(11)` stored in DDL surfaces as `int`.
- vitess preserves whatever the user wrote in desired SQL —
  `INT(11)` round-trips through `sqlparser.String` as `int(11)`.

myschema doesn't normalise either side, so `INT(11)` in desired SQL
shows up as a `MODIFY COLUMN` drift on every plan. The right
mitigation is on the user side: write the bare type name (`INT`,
`BIGINT`, …) in desired SQL.

Rewrite the bullet to call out the asymmetry directly and mention
the `ZEROFILL` exception (MySQL preserves it in `COLUMN_TYPE` —
verified to come back as `int(5) unsigned zerofill` — so it is
round-trip-safe as long as the implicit `UNSIGNED` is also written).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

case

Previous wording said the empty-string default was the *only*
type-aware path in `normalizeColumnDefault`. That was true at one
point but PR #34 added a second type-aware branch: a fixed-width
`BINARY(N)` column with `DEFAULT ''` surfaces from MySQL as the
literal two-character string `"0x"` (independent of N), and the
catalog rewrites that sentinel back to `''` when the type-name
starts with `binary`.

Restructure the bullet into a short three-case list (non-empty
type-agnostic / empty-string type-aware / BINARY(N) "0x" type-aware)
so the docs match the code.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

arises

Previous wording said "the catalog returns 0", which implied MySQL
itself reports a literal 0 for indexes without a prefix length. It
doesn't — `information_schema.STATISTICS.SUB_PART` is NULL in that
case. The catalog loader scans it into a `*int`; when nil it leaves
`model.IndexPart.Length` at the struct zero-value (0). vitess's
`IndexColumn.Length` is the symmetric `*int` on the parser side.

Reword the bullet so it describes both sides as `*int` carrying nil
for "no prefix", and call out that the equal-at-0 comparison is the
result of the struct default — not a quirk of MySQL's response.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>