選択肢が増える、型が変わる、自由文が関連になる。人が画面を理解できても、定期タスクは古い対応表で読み書きしているかもしれません。明確なエラーだけでなく、提出できても意味が違う更新があります。
現在のschemaを読み、タスクと利用先を照合して、読み取り、限定提案、業務結果の順に確認します。
値の変更と構造の変更を区別する
一件の値変更はそのデータと利用先に影響します。型、選択肢、関連先の変更は複数タスクの解釈を変え得ます。Basesには項目、記録、ビューがあり、型は検証や表示、差分の扱いに関わります。
表示名、識別子、型、選択肢、関連先を別々に読みます。表示名の変更からslug変更を決めつけず、名前の確認だけで型の変化を見逃さないようにします。
実際の依存先を列挙する
使う項目の識別子、型、必須条件、選択肢、単複、関連先、JSONの構造を記録します。Skill、指示、インポートスクリプト、API対応表、報告書、AirAppのどこに仮定があるか調べます。
必要なら構造変更確認Baseに概要、対象、担当者、依存箇所、読み取り結果、提案、受入結果を残し、Docで定義を共有します。これは調整の初期設計です。自動で全依存を発見したりコードを移行したりはしません。既存の管理記録があれば再利用します。
書く前に読み取りの解釈を確かめる
「現在のschemaと旧指示を読み、不一致の項目、型、選択肢、関連を列挙する。既存記録を読み、目的の結果への対応を説明する。未知状態や不足は個別報告し、まだ書き込まない」と依頼します。
欠値、複数関連、新しい選択肢など実在する分岐を選びます。取得成功だけでなく意味が保たれるかを確認します。未知状態を古い既定値へ黙って変換する規則は修正が必要です。
JSONを解析できても互換性は未確認
Field TypesではJSONとYAMLが提出やマージ前に解析できることを要求します。構文エラーは防げますが、下流の必須キー、単位、出所、正しい関連先までは保証しません。
構文解析、現在の項目対応、業務規則の三層を確認します。有効JSONでも必要なキーがない場合があり、有効な選択肢も旧ルールが誤解する可能性があります。必要な構造条件と判断はスクリプトやSkill、受入基準へ明示します。
限定提案と利用先の検証を行う
対応表と指示を修正し、認可された少数の実レコードにChangeRequestを作ります。現在値、提案値、理由、保持項目を見せ、無関係な全表更新に広げません。
マージ後に正式レコードを読み、依存する報告書、書き出し、アプリも確認します。利用先ごとの結果と未完項目を残します。古い待審査提案も現在構造で再確認し、schemaやコード自体の本番変更には別途適切な権限と認可を使います。
確認したルールで段階的に再開する
schema、対応表、業務規則、主な利用先が一致してから段階的に再開します。使う規則の版、範囲、確認結果、未確認分岐を残し、後続タスクが新しい指示を実際に読むことを確かめます。
名称変更で全タスクを書き直しますか。 実依存を確認して対象だけ直します。一件成功なら全件大丈夫ですか。 分岐と利用先も必要です。管理Baseの新設は必須ですか。 いいえ。構造差、提案、責任者、受入結果を追えることが重要です。