Update SDK pages

Author: tailor-docs-bot[bot]

docs/sdk/cli-reference.md

@@ -95,8 +95,17 @@ An annotation does not by itself fail a step: the step still fails on the CLI's
 is unchanged. Workflows that already echo their own `::error::` around the CLI keep working;
 those messages describe the workflow's own checks, which can fail even when the CLI succeeds.
 
-Annotations do not yet carry `file=`/`line=` source locations, and `generate` and `deploy` do not
-group their per-service progress.
+When the failure has a known source, the annotation carries it: `seed validate` reports the
+offending JSONL file and line, and a rejected config reports its file — or, when the config or a
+file it imports cannot be parsed, that file and the line it failed on. Locations are written
+relative to `GITHUB_WORKSPACE`; a file outside it is annotated without a location rather than with
+a path the runner cannot resolve.
+
+For a JSONL file containing a blank line, the annotation's line and the line printed in the report
+text differ: the annotation counts every line in the file, while the printed line counts only the
+records. The annotation points at the row as an editor numbers it.
+
+`generate` and `deploy` do not group their per-service progress.
 
 ## Common Options
 

docs/sdk/services/tailordb-migration.md

@@ -284,8 +284,12 @@ export default defineConfig({
 
 Migration files are versioned independently of the SDK package. This SDK writes format version `6` and reads versions `1` through `6`. It normalizes supported older formats in memory; it never rewrites applied migration files on disk. Format version `6` records renames of members inside nested fields (`memberRenames`); older SDK versions refuse to read it rather than deploying such a migration without the copy step.
 
+Supported histories also preserve the behavior of field hooks and validators saved by older SDKs, including access to the record and boolean validators with a separate error message. Legacy update hooks retain existing values for omitted fields; explicitly supplied values, including `null`, take precedence. This applies to both snapshots and diffs, including nested fields. Your existing migration files can remain as generated.
+
 If a future SDK can no longer replay an old migration format, re-baseline while using an SDK version that still supports the complete history, commit the new baseline, deploy it to every environment, and then upgrade the SDK. A file from a newer unsupported format instead requires upgrading the SDK first. The CLI rejects both cases with guidance rather than attempting a best-effort replay.
 
+The SDK used for this transition must read the old history and write a baseline format that the target SDK accepts. Keep that SDK version pinned until every environment has adopted the new baseline. File-format support does not guarantee compatibility for arbitrary imports in a custom `migrate.ts`; keep its dependencies pinned and test customized scripts when upgrading.
+
 There is no migration-file conversion command. Keeping applied files unchanged preserves the record of what ran, while `migration rebaseline` provides the escape hatch when the supported replay window changes.
 
 ## Migration Script Anatomy