線の反復と特殊サテンの設定を編集可能な正本へ追加する
リリース状況
未リリース。実装PR18は、最新mainの4タブ・見本タイル・アコーディオン・透明ボタン・名前直接編集と文字サテン（PR17/19/20）を統合した。製品464e6b83（App7c09b9b/Core9b26a7e）のCore1056件は失敗0、App705件は既存の実接続専用1skip以外に失敗なし（15.374秒）。独立レビューで見つけた最大文字の情報重複や固定操作の開閉不一致も修正した。最新UIの必要11導線を分割確認し、Releaseのarm64/x86_64も成功した。PR18はmainへ実マージ済み。GitHubのmerged=trueとmerge commit 9b44b6f9779c4fec5400a2a85e2509e1446a127f を再取得して確認した。本番配布は未確認である。
以下は各時点の検証・判断の履歴であり、過去sourceの成功を最新sourceの成功へ読み替えない。UI56では最新mainの名前・現在値・portrait適用・図案一覧と、文字反復/既存サテンの草稿・候補取消の2ケースが成功した。UI40で実保存した65/390針の文書を最新Coreで再生成し、旧期待針列の全座標/順序/色block/stopが変わらないことと、4形式の独立reader一致を確認した。旧UI実PESと最新CLI PESも同じSHAとなった。最新UIからの実出力は後述する別の検証範囲である。
目的と範囲
ユーザーの要望により、縫い方の種類と細かな設定を優先する。線全体の通過回数とひと針区間の奇数通過周期、E/S/Zigzagの実針、基準側・送り、中心下縫いの独立針長・通過回数が今回の承認範囲。輪郭/Zigzag下縫いと他高度設定は後続へ残す。
参照先はユーザー確認済みのInk/Stitch。公式資料と固定コミットを機能参考として調べたが、GPLコード・素材・書体・サンプルの転用や翻訳実装は行っていない。針単位の互換を宣言しない。
設計で判断したこと
- 「往復回数」では片道と往復が混同されるため「線全体を通る回数」とした。1回は片道、2回は行って戻る。各区間は奇数回を指定し、追加の補助移動なしで次へ進める。
- 全体反復の帰路は生成済みの基準針列の厳密逆順。図案の向きを反転する編集は針を再サンプリングするため、物理区間の位相を保持すると保証しない。複数文字輪郭もそれぞれ全反復を終えてから次へ移る。
- サテンの新方式は左右断面と送りを定義し、方式名だけを変えた同じ針列にしない。通常のnil設定は旧生成を維持する。
- 本縫いと下縫いの密度を分ける。旧中心下縫いbooleanと新詳細の二重有効化を避け、値を無効状態でも保持する。
- 生成針を編集正本へ置換せず、曲線・レール・実測筆圧を保持する。保存形式の昇格とclipboardを両機能の共存試験で確認する。
検証で学んだこと
- 新AppテストはUIを通らずモデルを生成する。初期描画モードを編集へ切り替え、必要な初期生成の完了を条件待機しないと、ガードが編集を拒否して機能失敗と誤認する。
- Undo後の草稿全体を比較すると、Redo用futureや選択状態など内部履歴の差も拾う。形・曲線・スタイル・筆圧など利用者に見える正本とRedo可能性を検証する。
- 常設フォームには非表示の無効フォームも存在する。同じAX識別子を全体検索せず、表示中・有効の作業面へ限定して操作する。
独立レビューから増えた検証
生成の針数や保存だけが成功しても、狙った経路を縫うことまでは保証できない。不等速の2本のレールでZigzagを作ると、両端の断面と幅比が同時に変わるため、その間は曲線になる。端点の直線を細かく分けるだけでは元の曲線には戻らない。独立した手計算例では0.25mmの差が見つかった。
修正では連続した経路を適応近似し、同じ弧長から針を選ぶ。近似に使った全節点を無条件に実針へ変えるのではなく、最大針長と曲線からの誤差、帯内性を満たす点を採用する。同じ形を2節点と21節点で渡したときの針数・座標一致も調べ、内部の分割数を利用者の密度へ混ぜない。
SM3: 表示位置と進行原点を別の座標として渡す
羽毛で左右の幅が非対称になると、実際の帯の中点が羽毛前の中心線からずれる。帯の中点を矢印の表示位置にも方向計算の原点にも使うと、短い水平線でも矢印が幅方向へ傾く。0.2mmの水平線に片側羽毛を付けた独立fixtureでは、旧原点による方向ベクトルへ約0.26149mmのY差が混ざった。左右両側へ異なる量を適用する羽毛と、複合Bezierの最初の0.001mm区間でも確認した。
Coreの表示用ヒントを4座標に分けた。leftとrightは実際に生成する帯の端、progressOriginは羽毛前の開始中心断面、forwardは同じ基準で最初に進む有効な次点である。中心線のoffsetは進行原点にも反映し、羽毛による端の偏りを方向へ混ぜない。
表示アンカー = (left + right) / 2
進行方向 = forward - progressOrigin
4座標をそれぞれ有限値と座標上限で検査する。ヒントのために全実針や全羽毛stationを生成せず、生成と同じ曲線分割と断面評価を、少数の隣接点だけ保持して使う。短線の接線は、元形状に基づく独立した水平の期待値で確認した。
SM4: 画面の左右と保存したレールの識別を分ける
canvasはY軸を反転せず、正のscaleで作品座標を描く。Yが下向きの座標で法線(-dy, dx)を使うと、+X進行では画面下へ向く。この既存の内部L/Rを、そのまま「進む向きの左・右」と表示すると意味が逆になる。
中心線から作る新E/S/Zigzagでは、次の独立期待を置いた。
| 中心線の進行 |
利用者にとって左になる位置 |
| 右へ進む（+X） |
上（Yが小さい） |
| 左へ進む（-X） |
下（Yが大きい） |
| 下へ進む（+Y） |
右（Xが大きい） |
中心線の新方式では、利用者の左を内部R、右を内部Lへ写像する。共通の写像を実針の基準側と表示ヒントへ適用し、Eの背骨、S/Zigzagの開始側、UIで選んだ基準側を一致させた。閉線でも内外へ読み替えず、鏡映後は変形後の進行を基準にする。
直2レール式のL/Rは保存された識別を表すため、同じ交換を行わない。鏡映でも保存したレールの識別を保つ。中心線の旧法線、保存済みの羽毛・offsetの生値、通常nilと明示normalの本縫いは維持した。新しい基準側の意味を直すために、過去の文書全体を変換する必要はない。SM3のprogressOriginとforwardも左右の入替対象にしない。
C0急角: 上限で拒否する例を成功例と分けて残す
左右の意味を検査している途中で、幅に対して短い急角の例が見つかった。正本は(20,20)から(20.4,20)へ0.4mm進む水平区間に、制御点(23,16)、(27,16)、終点(30,20)のcubicを接続したもの。接線が不連続なC0接続で、サテン幅は2mm、Eの送りは2mm、最大針長は10mmである。
この入力で新Eの中心線基準左、すなわち内部Rを選ぶ候補はlimitExceededで拒否される。共有work上限は2,000,000で、現在の利用者向け理由は「データ量が上限を超えています。」。候補の失敗時にはBezier正本、作品、Undo/Redo履歴を保つ。元のC0入力を拒否回帰として残し、左右の意味は接線が連続したC1の曲線で別に検査した。当該C0 fixtureの旧nilと明示normalは同じ78針で一致し、通常経路を悪化させていないことも確認した。
同じ独立reviewerによる限定判定は、共有上限でのこの拒否が仕様内というもの。「任意の急角に対応済み」「この形を新方式で必ず縫える」とは説明しない。具体座標、元の拒否ログ、正本・履歴保持の回帰は、アプリの docs/design/qa/2026-10-29-satin-methods/CORE-C0-BOUNDARY.md に残した。
コードの独立レビューと統合版の最終受入は分けて扱う。生成・表示・保存・通常UI・別readerの証拠をそろえ、最終の受入結果をQAへ記録する。
別作業のUI再設計へ合わせた統合
最終取得でmainに4タブとアトリエホームが入っていたため、旧6分類での操作成功を最終受入へ流用せず、新しいホーム・同じ編集面・縦画面の短い横スクロール列へ合わせた。新UIの共通スクロールに、従来の独立List画面をそのまま入れると高さの計算が競合する。入力Fieldsと適用・取消Commandsを分離し、共通の作業面と固定操作領域へそれぞれ配置した。
固定操作の親Groupに識別子を付けると、子の適用ボタンへ親識別子が伝わり、自動操作や読み上げの識別が壊れる例を実UIで検出した。実コンテナとchildren containで親子の識別を分けた。見た目にボタンがあることだけで、同じ操作へ安定して到達できるとは限らない。
上部の現在値も、新しい中心下縫い詳細より古いbooleanを優先していた。実Viewと共有する値helperを旧表示のまま抽出し、8テスト29assertの実行時失敗を確認して修正した。新方式では送り、通常サテンでは間隔、明示した中心下縫いはON/OFF・長さ・通過回数、線反復は実効周期を表示する。確定済み選択はselectedObject、作成中は実草稿を読み、未適用の選択設定や一時previewと混ぜない。各時点の確認済み件数と通常UIの証拠は履歴として保持する。最新の確定結果は先頭と末尾に記録する。
最新mainの視覚部品と数値草稿を合流する
a23efddb の共通部品へ合わせ、サテン方式は既存4模式図と日常語の WorkspaceChoicePicker タイルから直接選ぶ。基準側も模式図・名前・選択状態を併記し、中心線の進行基準と保存レールの識別を区別した。送り、本縫いの最大針長、中心下縫いの独立針長と通過回数は WorkspaceNumberField へ接続し、直接入力と大きな増減操作が同じ文字列草稿を更新する。途中の不正文字を有効値へ黙って戻さず、既存の値域検証、適用・取消・Undo、58ptの固定主操作を維持した。
合流時には、画面で非表示にした旧サテン間隔の不正文字が、新Eと明示中心下縫いへ切り替えても数値検証を塞ぐ経路があった。5assertの実行時赤を確認し、実際にその間隔を消費する通常方式、または新中心詳細がない従来中心下縫いの場合だけ、表示とparseの対象にする共通条件へ修正した。非表示の草稿文字は破棄せず、未確定のまま通常方式へ戻ると不正文字が再び現れ、適用を拒否する。反復K2と周期・針長数値、新Eと引き補正数値の同時適用、不正入力の保持と修正後の生成、保存正本と未適用草稿の分離もモデルの実操作で確認した。
SM7: 方向ヒントにも数値草稿のsnapshotが必要
数値草稿が導入されても、方向requestがstyleとサテン詳細だけを比較すると、引き補正やoffsetに「-」を入力した際にstyleが変化せず、旧ヒントが未適用草稿の方向として残る。選択設定と新規描画の両方で、0.20から「-」、0.50へ直す独立テストを追加し、旧requestの同一性・非throw・幾何不変による28assertの実行時赤を確認した。
修正では PathNumericDraft の値をrequestへcaptureし、実適用と同じ SatinExpressiveDraft → PathNumericDraft の順でstyleを解決する。入力文字だけの変更でもrequestが別値になり、旧ヒントを非表示にする。不正文字は解決時に理由付きで失敗し、修正後の新requestで断面を再計算する。取得済みrequestは後の入力へ追従せず、作品・描画草稿・revision・Undo/Redoを変えない。非同期へ渡す数値草稿と内部Entryには検査付き Sendable を付け、@unchecked へ逃がさなかった。新2テストは0.052秒で成功し、App final15の676件・skip1・失敗0にも含まれる。
視覚操作への移行では、非表示フォームの同一識別子、数値欄のフォーカス、慣性で移動する短い横面、固定操作を除外した可視領域の判定を個別に確認した。文字置換はnative欄の中央tapと既存文字数のDeleteを使い、値の完全一致を確認する。到達条件の完全表示・hittabilityは保持した。
SM8: 上部へ移した操作にも独立closeを維持する
最大文字では右の設定面が上部3段目へ移る。既存実装のcloseは狭い右面のheaderにだけあり、上部では周期1/3/5を設定しても独立して閉じられなかった。visual22の実失敗から、本文右端44ptを予約し同じ高さ内へ実44×44ptのcloseを配置した。追加headerで上部を伸ばさず、本文・固定適用へ重ならない。visual23では239.746秒で閉再開と周期保持、実58pt以上の適用、95針→Undo33針→Redo95針を確認し、同じ独立担当がコードと画像/AXの整合を解消判定した。
SM9: 共通アコーディオンへ可用寸法と環境を渡す
PR17の新UIを統合すると、外側は最大文字に合わせて列を広げても、アコーディオン内側だけ280ptへ戻る経路があった。実UIの見出しは188.5pt高、本文は80ptで、スクロールでは全体表示できない。rootで解決した列幅と高さを共通の環境値として渡し、内側も同じ寸法で列を組むようにした。さらに、UIHostingControllerで隔てたフォームへも寸法とcompact環境を明示転送する。SwiftUIの親へ設定した値が別のhosting rootへ自動で届くとは扱わない。
幅を直しても、最低84pt、最大文字112.5ptの方式タイルは55〜80ptの本文へ入らない。先行の最大文字テストで再現し、広幅では同じフォームと固定操作をAnyLayoutで左右へ組み、上部の高さを増やさず本文160ptを確保した。方式は模式図と名称の横配置、数値は名称・単位・入力・増減の横配置へ適応し、文字や操作領域を縮めない。portraitでは同じcompact操作を一行へ組み、本文を確保する。処理・失敗・候補の状態は通常の固定操作かcompactのcanvas共通位置の一方だけへ置く。
実UIの方式タイル84pt/本文160ptまで確認できたが、数値欄だけを中心へ寄せる試験では名前が画面外へ出た。完全表示のassertを外すのでなく、名称・入力・増減のunionをスクロール対象にした。書体の非対象設定は実際のアコーディオン操作で閉じ、入力を削らず対象へ進む。当該時点では縦横回転・固定3操作・閉再開・取消・適用/Undoを再検証対象にした。
UI38では最大文字の方式・数値行・固定3操作、縦横回転、閉再開、取消・適用・Undoが944.157秒で成功した。ただし画像の目視から、入力装飾と現在値の重なりが新たに見つかった。フレームの完全包含やAX値だけで、表示の読みやすさまで成功扱いにはしない。
SM10: 入力装飾も拡大した実幅を確保する
数値欄の「123」を固定38ptの左余白へ上乗せすると、最大文字では装飾幅が約79.74ptまで拡大し、実値「2」に重なった。文字欄のAaでも同じ問題がある。実UIWindowに置いたUITextFieldの文字領域をhost座標へ変換し、通常/最大文字、Aa/123、短い値・複数桁・不正途中値等の12組を実フォント幅＋8pt間隔と照合した。先行テストでは9assertが失敗した。
装飾をHStackへ移して実幅を予約し、実際のTextFieldとBinding、数値入力の意味を維持した。修正後の文字開始位置は最大文字のAaで71.5pt、123で98ptとなり、装飾と8pt以上離れている。隣接する±も拡大フォントでは44pt幅を越えて接触したため、共通iconと同じ20pt記号・44pt操作領域に揃えた。先行テストと操作欄の自然サイズ3件はすべて成功。同じ独立担当はコード解消と判定し、その後の実画像と入力操作の受入は、対象sourceを区別してQAへ記録した。
候補の経路と再生も同じ計画から読む
独立レビューでは、canvasの候補経路だけ新しくなり、赤い針位置マーカーと再生範囲は旧計画を使う差も見つかった。マーカーは停止中も表示されるため、再生していない場合も無害とは言えない。表示中の計画を一箇所で選び、作品・編集版・入力世代・選択・草稿が一致する候補だけを採用して、canvas・マーカー・再生範囲へ共有した。針数が同じでも座標が異なる候補では、計画全体の変更で再生位置を更新する。
一方、作品の保存・書き出し・文書針数・統計は確定済み正本を対象とする。候補へ暗黙に切り替えたり、針表示OFFで作品の針数を0にしたりしない。共通canvasには「未適用のサテン候補: X針／確定済みの作品: Y針」、確認タブの統計には「集計は確定済みの作品」と表示し、読み上げでも対象を区別する。候補と作品が同じ針数でも未適用であることを明示する。候補の表示OFFや変形プレビュー中はcanvas上の対象表示も隠し、古い候補を表示経路へ残さない。コード上で権威を分けることに加え、隣り合う情報の対象も画面で伝えるようにした。
固定操作領域の説明は、候補の存在とcanvasへの表示を別に扱う。「未適用のサテン候補: X針」だけを伝え、有効候補がある間は表示OFFや変形中でも説明を保持する。raw outputから「キャンバスに変更後の針を表示しています」と断定すると、表示状態や失効と食い違う。実View共通helperを旧動作のまま抽出し、既存8テストに期待を追加して14assertの実行時失敗を確認した後、表示計画と共通のsnapshot検証へ切り替えた。文書・revision・入力世代・source・選択・草稿の不一致、取消、失効後は説明を消す。この修正は最新App final15の676件・skip1・失敗0でも回帰確認した。
確認済みの保存・出力
旧UI40の保存・出力ケースでは、E・右基準・送り1.2mm・中心下縫い3.5mm/2通過を保存し、アプリ再起動後の設定と390針を確認した（507.513秒）。線反復の2通過も、Undo/Redo・保存再起動後の65針と設定を確認した（108.527秒）。同じ実行束に含まれる他ケースの結果とは分けて記録する。
この実UIで保存したPESは2030bytes、SHA256 6cb4e38176191095eb1a015516b7ea479f136d8756a4c4fde46a654ae992f68c。pyembroidery 1.5.1で全390針の順序・座標・色block・黒RGB・stop0/end1を照合し、同じCoreから生成したCLI PESともbyte一致した。保存文書からのCLI出力はPES/JEF/DST/EXPの4形式を独立readerで照合し、線反復の保存文書も65針で一致した。UIからのミシンファイル保存を確認したのはサテンPESであり、他形式のCLI照合とは区別する。DST/EXPのRGB非保持とJEFのtimestamp差も、全形式のbyte一致という説明へ置き換えない。原本・期待針列・reader結果・由来とSHAはアプリQAの ui40-output に記録した。
確認の限界
テスト・UI・Release・保存・出力はそれぞれのsourceでQAへ記録し、単一bundle全件成功とは言い換えない。物理Pencil、最低iPadOS17、試縫い、全VoiceOver/ダークの成功は未確認。未配布なので通常記事・SNS・アプリ告知は追加しない。
一次資料
SM11: 失敗の文章を図形と分け、現在の入力へ結び付ける
キーボードと最大文字が同時に使われた画像で、方向表示の失敗文が既存の操作説明へ重なっていた。図形overlayから文章を外し、失敗時だけ操作説明・復旧情報と共通の高さを制限した縦スクロールへ集約した。上と下の情報領域の合計は、画面全高でなく実際にcanvasへ割り当てられた高さ以内にする。最大文字ではfootnote相対の拡大率に従う1行高と上下16ptの余白を優先し、headerを残りへ制約する。エラー本文はfootnoteで短縮せず、長い内容の末尾までscrollで到達させる。
表示状態は対象・入力snapshotと一緒に保存し、現在のrequestに一致する結果だけを受け取る。入力の変更直後に古い理由を隠し、古い成功やclearが新しい失敗を消すことも防ぐ。この状態は編集正本やUndoへ入れない。実モデルの入力変更・遅延結果・正本不変、実UIScrollViewの高さとcontent overflowを新たに検証した。
実画面の切り取りとnative AX外形を混同しない
この情報欄を最大文字とキーボードで確認したUI43では、native UIScrollViewのAX外形が469.5ptでも、実際の切り取りと縦スクロールバーのtrackは47.5ptだった。外形はキーボード側のsafeareaまで広がっていた。画像とtrackを突き合わせ、テストの実viewport計測を直した。同じreviewerは47.5ptが実1行52.5078ptより低いことも指摘した。実UIFontの1行と余白を要求する先行赤から最低高を修正し、UIも最後の1行の帯全体が入ることへ強化した。修正後の全文末尾への実scrollと正常復帰は別に検証し、見えない場所があることを測定法だけで成功へ読み替えない。
途中では別のinstalled binaryが、テスト対象Coreに存在しないinitializerを要求する起動失敗もあった。クラッシュしたdebug dylibとDerivedDataのUUIDが異なることを確認し、インストール元を推測せず、専用SimulatorとDerivedDataへ隔離した。開始と終了の実installed executable/debug dylibをUUIDとSHAで照合し、検証対象sourceと実行成果物が一致することを記録した。
SM12/13: 情報の対象表示と物理方向を同じ場所に重ねない
候補を示す白帯は針数の誤認を防いでも、canvas上の進行矢印や左右の文字を覆うことがあった。既存headerへ候補/確定情報を移し、候補の出現と取消でcanvasの寸法を変えないようにした。通常は既存高で横scroll、文字拡大は高さを制限した縦scrollを使い、全文とUndoへ到達できる。
方向の文字も固定offsetでは拡大時に重なる。実際のText寸法を計測し、canvas内の決定的な有限候補から互いに離れる場所を探す。物理矢印と左右railを動かさず、移した文字だけ細いleaderで実位置へ結び付ける。未計測や安全配置が見つからない間は文字を隠して全文の理由をheaderへ出す。有限候補の失敗は、数学的に配置不可能だという証明ではない。表示の状態は現在requestへ限定し、編集正本や数値入力の生成失敗とは分ける。
実UIFont/Hostingの先行赤と幾何検査、通常/最大文字の実UIでsource/header/canvas分離と文字同士の非重複、回転・取消・Undo後の再計測を確認した。UI48の同値E候補は441針/確定441針でApply無効、UI46の変更Apply409針/Undo524針とは異なる受入として記録する。
最新mainの同番号schemaをpayload別に検証する
別作業の文字サテンもschema41を使うため、番号が同じことだけでは相互の対応を保証できない。線反復と文字サテンは各payloadの検査で41以上を要求し、特殊サテンを含む場合は42へmax昇格する。新共存回帰では3機能の挿入/clipboard貼付の全6順序、保存復元・Undo/Redo、旧nil生成、低schema拒否を確認対象にした。最新画面への統合後の結果と実マージは先頭のリリース状況へ反映する。
SM14/15: 最新mainの初期折畳みと固定操作を一緒に扱う
mainで撤去された機能は、新規featureファイルの排他guardにだけ参照が残ることもある。統合後の実compileで配色機能の参照を検出し、その条件だけを除いて他の排他ガードを保持した。
設定本文は初期折畳みでも、別の固定footerだけ常に表示されていた。既存UIの『閉じた設定に適用はない』を先行赤で確認し、線・既存サテン・文字反復それぞれの本文と固定操作を、同じ展開状態とBindingへつないだ。本文は既存のmounted childrenを保ち、閉じて入力草稿を作り直さない。サテンの候補・生成・失敗がある間は、閉じても状態と取消だけを残す。
一覧表示では上部タブが編集のままなので、タブだけを見たfooter条件では一覧に適用が残る。実際に表示しているdetailPanelも判定へ加え、directionも隠れた草稿を編集中とは扱わない。有効候補と選択正本は表示でき、入力と非同期状態は戻った時に再開できる。実UI56では名前/現在値/portrait適用/一覧が91.559秒、文字反復と既存サテンの初期footer不存在・草稿の閉再開・候補中の取消・取消後の空footer消失・同候補再生成が270.115秒で成功した。同じ独立担当も画像/結果から解消と判定した。
最新mainでの最終検証と実行成果物の同一性
最新の必要11導線はUI56の2成功、UI57の不変body6成功、UI59の3成功に分けて確認した。単一bundle全成功ではない。UI57は8中6成功・2fixture失敗で終了した。同時点で、ディスク上のtest bundleと実際に読み込まれたrunnerのUUIDが異なることを実プロセスのsampleで検出した。実App2imageは最新製品と一致したため、body/helperが不変の6ケースについて新Appの実traceだけを採用し、未実行の追加keyboard検査を成功へ含めなかった。原因の帰属は断定しない。
runnerだけを再導入し、制作Appと文書を保持したまま専用Simulatorを再起動した。追加検査を独立selectorへ移し、実loaded test/App・installed・derivedのUUIDと終了時SHAを照合したUI59は全3成功。独立した最大文字/keyboardケース271.865秒、特殊サテンの保存・実PES415.432秒、4タブ55.630秒である。実viewportはAX外形496ptでもkeyboard本体までの129ptでもなく、画像上のscroll track74pt。理由の初行・末尾・操作説明末尾の全字形へ到達し、訂正で情報欄が消えることを画像で確認した。残高headerの全操作到達まで保証したとは扱わない。
サテンの左右labelは、物理点を動かさずleaderで接続したため、labelの上下だけを物理側の期待値へ使えない。旧midY比較を訂正し、4labelのcanvas内包・相互非重複とCoreの物理左右fixtureを維持した。4タブは新mainの初期折畳みを実際に開くfixtureへ変更した。期待値を減らすのでなく、表示文字と物理幾何、実操作の役割を分けた。
最新の実保存文書はschema41の線反復K2/C1・65針、schema42のE/右基準/送り1.2mm/中心下縫いON・3.5mm・2通過/390針。UI59で実保存したPESも2030bytes、SHA256は旧出力と同じ 6cb4e38176191095eb1a015516b7ea479f136d8756a4c4fde46a654ae992f68c で、新Core CLI PESと一致した。実PES自体と両文書のCLI4形式をpyembroidery 1.5.1で全針座標・順序・色block・stop/end照合した。証拠はアプリQAのui59-outputに保持する。UI保存はPESのみで、独立jump比較やJEF timestampのbyte一致までは主張しない。
最終製品は464e6b83、試験9652f0e、証拠固定6952a99。Core1056件失敗0（77.567秒）、App705件は既存実接続専用1skip・失敗0（15.374秒）。Release5もactual exit0、両Simulatorアーキテクチャを確認した。同じ独立reviewerが全PR1/SM1〜15を解消と判定し、ローカル受入可・必須残件なし。生成ログ抜粋の空白警告だけ任意指摘として保存し、全差分無警告とは説明しない。