==========================================================================
 zsystem.jp 作業記録 2026-07
==========================================================================

--------------------------------------------------------------------------
2026-07-01〜07-02  厚木事業所 印刷進行予定表(ellio) 工程会議資料EXCEL取込準備・
                   businessRawdata列コメント付与・packageqty用途調査
--------------------------------------------------------------------------

【背景・目的】
  - 厚木事業所(興国運輸)の印刷進行予定表(ellio/printschedule)関連作業の準備。
    エリオから金曜の工程会議で配布される週間予定EXCEL(工程会議資料)を新規に
    取り扱い、進行予定表に載っていない情報(出荷予定日等)を抽出。将来のシャーリング
    週間予定立案につなげる。

【業務背景の整理・ドキュメント化(ellio/CLAUDE.md 追記)】
  - 商流: 大日本印刷(DNP)→大日本エリオ(元請/鋼板印刷=化粧鋼板)→出荷先は日立
    (エレベータ)・三菱電機(冷蔵庫)等。興国運輸 厚木事業所がエリオ工場内で
    入荷/保管/ピッキング/印刷ライン投入/梱包出荷/シャーリングを請負。
    部門=シャーリング部門/梱包部門。
  - 進行予定の入手経路3種(週間EXCEL/前々日/システムPDF)と鮮度順(前々日>工程会議>PDF)、
    工程会議資料の位置づけ、businessRawdata.orderno複合キー等を追記。

【工程会議資料EXCELの解析】
  - ファイル: ~/Downloads/1L・2L工程会議資料0706-0710.xlsx
    (1L=47件, 2L=49件, 組込日7/6〜7/10)
  - 表示メインシート「○ライン抽出製造用本確回数」が対象。
    「差し替え依頼資料…」「…(2)」シートは hidden(非表示)。
  - 「進行予定表に無い情報」= AI出荷日(出荷予定日)・Jシャー CD 等を抽出。
    出荷日記法: 単一日 / 分納(日付(数量)) / 朝出 / '-'=出荷予定なし=大分出荷品。
    鋼材入り日/GC入り日/LM入り日(AF/AG/AH)は当該資料では空。

【businessRawdata との突合(PDFに無い行の特定)】
  - orderno複合キー = 受注NO-行NO(2桁)-印刷NO(2桁) を組み立てて突合。
  - EXCEL 96行中 88行=登録済 / 8行=未登録(=PDFに無い行)。7/10(金曜)に集中。
    うち1件(38085761-01-02 JR東海)は既存受注の新しい印刷回、他7件は完全新規。
  - タイムラグにより遠い曜日ほど未登録になりやすいことを確認。

【businessRawdata 全77列に日本語コメント付与(本番DB スキーマ変更)】
  - UIラベル(printschedule.html)・工程会議EXCEL見出しを根拠に全77列のコメント案を作成、
    ユーザー承認後に実行。
  - SHOW CREATE TABLE の定義(型/NULL/デフォルト/auto_increment/timestamp自動更新
    /utf8_bin)を完全保持し COMMENT のみ追加する単一 ALTER TABLE で一括付与
    (テーブル再構築1回)。総行数 59,480 で不変=データ影響なし。
  - ★文字化けトラブルと対処: 古い mysql クライアント(Distrib 5.0.92)は既定 latin1
    接続のため、初回は日本語コメントが二重エンコードで化けた。
    --default-character-set=utf8 で全列付け直し、格納バイトをHEXで正しいUTF-8と
    一致することを確認して解消。
    → 教訓: zsystem.jp の mysql CLI で日本語を書き込む際は
       mysql --default-character-set=utf8 (または冒頭 SET NAMES utf8)を必須とする。

【新規列・梱包数フィールドの検討(いずれも保留)】
  - 工程会議EXCELの businessRawdata に列として無い情報(S GC色名/T作業回数(本確)/
    U前回作業ライン/V前回作業日/W製造評価/X色調評価/Y前回作業に対して/
    Z色評価コメント/AH LM入り日)は、シャーリング週間予定の整形方針が固まるまで
    カラム追加を保留。
  - 「梱包数」フィールド追加案件: 形式は double で確定。ただし既存 packageqty
    (varchar10,COMMENT梱包数)と重複問題があり、当初は別名の新規double列追加の意向。
    → 判断のため packageqty の用途を調査(下記)。

【packageqty(businessRawdata)の登録状況・用途調査】
  - 登録状況(全59,480行): 空''=7,890 / '0'=42,838 / 実値(1以上)=8,752。
    値は1〜24の小整数(文字列格納)。7/2・7/3の直近受注にも入力あり=現役。
  - 書込元: printschedule/index.php:148 writeInfo() の手入力 UPDATE 1箇所のみ
    (進行予定表画面の「梱包数」入力欄 packageqtyfield → pacqty)。
  - 用途:
      (1) printschedule/index.php で進行予定表に表示(indicationqty2)。
      (2) skidorder/index.php で divisioncode='O'(大分出荷品)を対象に、
          packageqty を数値として使用($packageqty+20 で木材=スキッド副資材の
          必要数オプション算出、加算、比較)。=梱包数を基準にスキッド用副資材の
          発注数を計算する実業務用途。
  - 注意: arrival/invoice.php:217 の packageqty は loadinglog テーブル(トラック積載
    情報)の別カラムで businessRawdata とは無関係。
  - 所見: packageqty は varchar だが skidorder で完全に数値扱い=意味的には既に
    「数値の梱包数」。新規double列は用途が重なる可能性があり、方針を再検討中。

【メモリー(auto-memory)】
  - project_ellio_printschedule_newcols.md: 上記カラム追加保留案件・梱包数(double確定
    だがpackageqty重複問題)を記録。

【本作業でのファイル/DB変更】
  - DB(本番 ellio): businessRawdata 全77列に COMMENT 付与(データ変更なし)。
  - ローカルのみ: ellio/CLAUDE.md に業務背景・工程会議資料の取り扱いを追記
    (サーバー転送なし)。
  - サーバーへのファイルデプロイ(scp/rsync)は無し。

【残課題】
  - 梱包数: 新規double列を追加するか / packageqty を数値型化して転用するか /
    既存で足りるか、の最終方針決定。
  - 工程会議EXCELの新規列群の扱い(シャーリング週間予定の整形)。
  - zsystem.jp/CLAUDE.md の MySQL 節へ「日本語書込は --default-character-set=utf8
    必須」を追記するか(未実施)。

────────────────────────────────────────
2026-07-02 productmaster: letip を ellio に合わせてコード同期（デプロイ 2026-07-02）
────────────────────────────────────────
目的/背景:
  letip/productmaster と ellio/productmaster の差異確認の結果、ellio 版にのみ
  入っていた改善2点が letip 版に未反映だったため、コード部分のみ letip へ反映。
  sqlite3（fieldlist/listtarget＝顧客別の表示項目設定）は顧客ごとに内容が
  異なるため対象外（letip 独自設定を維持）。

変更ファイル（letip/productmaster/）:
  - index.php: writeProduct() の登録失敗時クリーンアップを追加。
      新規登録時に作る仮行(PDCode='insert_temp')について、直後の UPDATE が
      失敗した場合に該当行を DELETE し残骸を防止。失敗時はエラー文言を返して return。
  - master.js: 検索パラメータのエンコードを encodeURI → encodeURIComponent に変更
      （& = + 等も確実にエスケープ＝堅牢化）。
  - master.html: 変更なし（元々 ellio と一致）。

確認: php -l OK、ellio と全コードファイル md5 一致。
デプロイ: scp（2026-07-02）。sqlite3 は転送しない。

────────────────────────────────────────
2026-07-02 productmaster: 登録編集画面でSizeキャプション(=カラムコメント)を編集可能化（ellio→letipへ展開・デプロイ 2026-07-02）
────────────────────────────────────────
目的/背景:
  サイズの順序表記が事業所(ellio/letip)ごとに異なるため、登録・編集画面上から
  Sizeフィールドのキャプション（= ProductDistributeTable.Size カラムのCOMMENT）を
  書き換えられるようにする。従来キャプションはカラムコメント読み取りのみで固定だった。

変更（ellio/productmaster/ で開発 → letip/productmaster/ へ同一コードをコピー展開）:
  - index.php:
      * switch に mode 'writeSizeComment' を追加
      * readInputForm(): Size のときだけキャプションを角丸グレーのボタン
        <span class=captionbutton onclick='editCaption()'> に切替（他フィールドは不変）
      * writeSizeComment() 新設: INFORMATION_SCHEMA から現在の型属性
        (varchar(32)/utf8_bin/NOT NULL) を読み、保持したまま
        ALTER TABLE ProductDistributeTable MODIFY COLUMN Size ... COMMENT '...' を発行。
        値は mysqli_real_escape_string でエスケープ。Size専用。
  - master.html: .captionbutton クラス（角丸グレー#ccc/hover#09e8）＋編集ダイアログ
        #captionarea（入力欄 maxlength=80＋登録/キャンセル）を追加
  - master.js: editCaption()/saveCaption()/closeCaption() を追加。
        保存成功時はボタン文言を即時更新し、findProductList() で一覧ヘッダーも再描画。

注意: 「登録」は本番テーブルへの ALTER(DDL)。ログインチェック済み管理画面内・Size専用・型保持。
確認: php -l OK、ellio と letip でコード全一致(md5)。sqlite3 は対象外。
デプロイ: scp（2026-07-02）ellio・letip 各3ファイル。

────────────────────────────────────────────────────────
2026-07-02  ellio/arrival/arrivalrecord/ 新規作成（鋼材入荷実績の一覧表示）

目的・背景:
  厚木事業所で受け入れた鋼材（アルミ・ステンレス含む）の入荷実績を、
  年月指定で一覧表示・CSV出力する画面が必要になった。
  名称は「受け入れ方向」を踏まえ arrivalrecord とし、ディレクトリ構成上
  ellio/arrival/ 配下に新設。ellio/arrival/materialplate/ をベースに作成。

内容（新規3ファイル / ベース=materialplate）:
  - index.php:
      * actualtable を年月(YYYYMM)で絞り込み一覧表示。
      * 年月セレクタは actualtable に実在する年月を新しい順に最大24ヶ月生成。
      * 並びは ActualCode 昇順のシンプルなフラット表示
        （materialplate の素材種別グルーピング/ブランク化は廃止）。
      * 列: 日付(ActualCode先頭8桁=入荷日) / 鋼材規格 / 目付 / 仕上 / サイズ /
        数量 / パックNO / 梱包NO / コイルNO / 加工日 / 納入元 / 納品書番号 /
        受注番号(actualtable.actualOrderNo = 投入実績の受注番号)。
      * 受注番号が複数受注にまたがる場合（actualOrderNo カンマ区切り）は
        画面は改行表示、CSVはカンマのままダブルクォートでエスケープ。
      * getStocklistCSV モード追加: BOM付きUTF-8・Content-Disposition で
        日本語ファイル名(入荷実績YYYYMM.csv)。表示SQLと同一の絞り込みを共有。
      * materialplate の不要コード（発注入力フォーム/メール取込/欠落header.html
        参照/未定義のrebuildBuyingPrice等）を除去。
  - stocklist.html: materialplate のスタイルを流用しつつ発注入力系UIを削除、
        上部バーに年月セレクタ＋CSV保存ボタン＋検索、納品書画像ビューは維持。
  - stocklist.js: 一覧取得/検索/納品書画像(dblclick)/CSV保存にスリム化。

注意: 受注番号は actualtable.actualOrderNo を直接表示（ActualResult等への
      JOINは不要）。materialplate が取得していた 'orderno' カラムは実在せず
      正しくは actualOrderNo だった点に留意。
確認: php -l OK。ローカル php -S + 実DB(ellio) で一覧/CSV/複数受注番号の
      改行・エスケープを動作確認。PHP5.3非対応構文は未使用。
デプロイ（2026-07-02）: scp 3ファイル → /Users/zadmin/Sites/ellio/arrival/arrivalrecord/

2026-07-02（追記）  ellio/arrival/arrivalrecord/ index.php 改修

  1) 一覧・CSVのヘッダ「受注番号」→「投入実績」に変更（列の実体は
     actualtable.actualOrderNo のまま。呼称を投入実績に統一）。
  2) 検索窓の入力が受注番号形式（8桁-2桁-2桁, 例 38089668-01-01）の場合、
     選択中の年月に関わらず actualtable 全体を actualOrderNo で部分一致検索し
     結果表示する分岐を arrivalQuery() に追加。形式に一致しない語は従来どおり
     選択年月内で複数カラム横断(productcode/productname/packno/lotno/stockno/
     sendfrom/arrivalno/actualOrderNo)の LIKE 検索。
  確認: php -l OK。ローカル php -S + 実DB で、受注番号完全形→全期間ヒット、
        非該当語→年月内限定 を確認。
  デプロイ（2026-07-02）: scp index.php のみ（html/js は変更なし）。

2026-07-02（追記）  ellio/menu/index.php にメニュー項目追加

  入荷処理セクション(g-arrival)の末尾に「鋼材入荷実績」
  （go("/arrival/arrivalrecord/")）を追加。原板納入指示明細書の次に配置。
  デプロイ（2026-07-02）: scp ellio/menu/index.php のみ。

2026-07-02（追記）  ellio/arrival/arrivalrecord/index.php にログイン権限追加

  materialplateベースのため未認証だったが、冒頭に LoginCheck("100") を追加。
  ポータルメニュー(menu)と同じ権限100に揃える。AJAX/CSVは同一オリジン＋cookieで継続。
  デプロイ（2026-07-02）: scp index.php のみ。

2026-07-03（追記）  ellio/arrival/arrivalrecord/index.php に残数列を追加

  背景調査: 「残鋼材か使い回しpacknoか」の判別可否を検証。
    - pack.actualcode が正規キー（regist.phpのSETACTUALCODEで入荷時に必ずセット）。
    - 在庫中の鋼材pack 22件は全てactualcode保持・未移動＝packno一致。actualcode結合なら
      使い回し新入荷（別actualcode）に誤ヒットせず、在庫中の残数を一意特定可能。
    - pack.actualcodeは在庫packでユニーク（1入荷=1在庫pack行）。
  実装:
    - arrivalQuery の両SELECTに
      (SELECT SUM(pk.qty) FROM pack pk WHERE pk.actualcode=AT.actualcode AND pk.locate!='') as remainQty
      を追加。表示・CSVに「残数」列（数量の右）を追加。
    - 残数の意味: 空欄=在庫なし / 数量>残数=残鋼材 / 数量==残数=満数在庫。
    - 表示のみ: 投入実績あり かつ 数量==残数 は「カンバン未クリア(実質残0)」の疑いとして
      残数を color:#ccc グレー表示（$rawOrderno!='' && $remain==$qty）。CSVは生値のまま。
  確認: php -l OK。実DBで残鋼材(75→25)/満数(231)/在庫なし(空)/グレー判定を確認。PHP5.3構文OK。
  デプロイ（2026-07-03）: scp index.php のみ。

2026-07-06（追記）  ellio/printsequence/index.php 「進行予定表から選択」タブで完了済みを除外

  目的/背景: 投入順序(printsequence)正式版の「進行予定表から選択」タブは、印刷完了
    (printCompleted=1)の受注も一覧に表示されていた。開発版(printsequenced)では既に
    printCompleted=0 で除外済み。正式版も未完了のみ表示に揃える。
  実装: readPrintSchedule() のメインSQL(index.php:338)に AND printCompleted=0 を追加。
    期間ロジック($date下限)等その他は変更なし（最小変更）。
  確認: php -l OK。実DB(today-3=2026-07-03起点)で件数比較。
    1ライン 69→65（完了4件除外）/ 2ライン 84→71（完了13件除外）で意図どおり動作。
  デプロイ（2026-07-06）: scp ellio/printsequence/index.php のみ。

2026-07-10（追記）  ellio/dispatchmng/ 配車管理システム 新規作成・初回デプロイ

  目的/背景: 厚木事業所(興国運輸)向け「配車管理表」システムを新規構築。トラック1台ごとの
    入庫〜受付〜積込/荷降〜退場の時刻記録・荷待/荷役時間・積載率管理が目的（仕様書=
    ~/Desktop/厚木事業所/配車管理/配車管理記録.xlsx「システム概要」シート）。
  新規テーブル(ellio DB, InnoDB/utf8_bin・本番DBに作成済):
    - dispatch: 配車管理表本体（仕様書A〜R列＋phone/shipping_no/nonyusaki_addr等）。
      出荷予定表PDF（テキスト貼付）の取込先。
    - carrierMaster: 配送業者 車両・ドライバーマスタ。岡田運輸37台=写真③（車番/ナンバー/
      運転手/車種/最大積載量）、他84台=配車管理記録Excel(2026.4-6月)抽出。計122台/25社。
  ファイル(4ファイル構成): index.php / dispatchmng.html / dispatchmng.js / style.css
    （dispatch.sql/carrier.sql はDDLドキュメント＝サーバー転送対象外）
  主な機能:
    - 出荷予定表PDF取込→dispatch（出荷指示番号=businessRawdata.orderno、質量/納期日等をパース）。
    - 配車管理表: 会社名/氏名/車番を編集コンボボックス化。会社→所属ドライバー→車番と候補連動、
      氏名ユニークで会社自動補完、確定でフォーカス連鎖。行ダブルクリックで編集ダイアログ。
    - 新規登録/編集ダイアログ（配達日/納入先/荷重量/配送業者/車番/氏名/電話/特記）。iOS準拠ボタン。
  既知の未解決: フォーカス移動時のプルダウン自動オープン。showPicker()+前フィールドblurで対応したが
    実機で氏名側が未オープンの報告あり＝要継続調査（将来カスタムドロップダウン化も検討）。
  確認: php -l OK。ローカル(php -S + 実ellio DB)で取込202件・各コンボ絞込・新規/編集保存を検証。
  デプロイ（2026-07-10）: scp ellio/dispatchmng/{index.php,dispatchmng.html,dispatchmng.js,style.css}。
    DB(dispatch/carrierMaster/phone列)は同一本番DBに作成済のため移行不要。

2026-07-10（追記）  ellio/menu/index.php 配車セクション追加

  目的: ポータルメニューに配車管理システム(dispatchmng)への導線を追加。
  内容: 資材セクションの下に新セクション「配車」を追加。項目=
    「配車管理（開発中）」→go("/dispatchmng/") ／「現場入力（まだ動作しません）」
    （リンク未実装・項目名のみ、画面は後日作成）。
  デプロイ（2026-07-10）: scp ellio/menu/index.php のみ。

2026-07-13  ellio/dispatchmng/index.php 便削除エラー修正

  背景: 配車便編集ダイアログから便を削除しようとすると「削除エラー:」（メッセージ空）が出て
    削除できない（ID:745で発覚。実際はID固有でなく全件で失敗）。
  原因: deleteTrip() が未定義関数 fetchRow() を呼んでいた。fetchRow の定義は別ディレクトリ
    ellio/dispatch/index.php にあり、dispatchmng/index.php では未定義。呼び出しで PHP 致命的
    エラー→空応答(500)となり、JS(dispatchmng.js:263)が空応答を受けて「削除エラー:」を表示していた。
  修正: 該当1行を、既に取得済みの $mysqli を使うインラインクエリ
    （mysqli_query + num_rows>0 判定 + fetch_assoc、fetchRow と同挙動・PHP5.3互換）に置換。
  確認: php -l OK。
  デプロイ（2026-07-13）: scp ellio/dispatchmng/index.php のみ。

2026-07-13（追記）  ellio/dispatchmng 出荷依頼日(積込日)の取込・保存を追加

  目的: 出荷指示書の「出荷依頼日」＝トラック積込日を保存する。各明細の「納期日」は
    トラックが納入先に到着する日で、両者は別物（宵積み等で日が異なる）。従来は納期日
    (shippingschedule.nouki / dispatch.dispatch_date)しか保存しておらず、積込日は未保存だった。
  発見: 出荷依頼日は出荷指示書の各ページヘッダ「出荷依頼日 YYYY年 MM月 DD日」にあり、
    ページ（積込日ブロック）単位で切り替わる（指示書全体で1つではない）。
  変更:
    1) shippingschedule に ship_request_date DATE 追加（nouki の後）
    2) dispatch に ship_request_date DATE 追加（dispatch_date の後）
       ※ alter_add_ship_request_date.sql（NULL許容追加＝旧コード後方互換）
    3) index.php parseShippingSchedule: ページヘッダの出荷依頼日を追従取得し各明細へ付与。
       importSchedule: shippingschedule/dispatch 両INSERTに ship_request_date を組込み。
       （既存 dispatch 行のUPDATEは重量のみ＝依頼日は新規行のみ付与）
  確認: php -l OK。パーサーをオフライン実データ（依頼日=納期日/宵積みで別日/ページ跨ぎ）で検証、
    出荷依頼日が納期日と別に正しく取得・追従されることを確認。
  デプロイ（2026-07-13）: ①alter_add_ship_request_date.sql を本番ellio DBへ適用（DDL先行）
    → ②scp ellio/dispatchmng/index.php。
    ※既存取込済み行は ship_request_date=NULL、再取込で shippingschedule は充足。

2026-07-13（追記）  ellio/dispatch 現場打刻画面 トップバー高さを約2/3に縮小

  目的: dispatch/（現場打刻）画面のトップバー(.header)が高いため約2/3に縮小。
  内容(style.css・縦方向のみ、横幅/配置/色は据置):
    .header padding 10px16px→6px16px / .filters padding 4px→3px /
    .f-btn padding 6px18px→3px18px / .f-btn .n font-size 22px→15px /
    .f-btn .l margin-top 4px→2px。 高さ 約76px→約51px。
  確認: ローカルで表示確認済み(ユーザー確認)。
  デプロイ（2026-07-13）: scp ellio/dispatch/style.css のみ。

2026-07-14 ellio/dispatchmng ほか: 日付カラム改名（名称と意味の一致）＋出荷日移行の準備
  背景: 当初 納期日を出荷日として取り込み dispatch_date と命名。後から出荷日(出荷依頼日=積込日)を
    ship_request_date として追加したため、両フィールドが「出荷日」に見え混乱していた。
    名前とデータの意味を一致させる。
  改名: dispatch_date(実体=納期日)→delivery_date / ship_request_date(実体=出荷日)→dispatch_date /
    shippingschedule.nouki(納期日)→delivery_date に統一。挙動は不変(純粋な改名)。
  対象: ellio/dispatchmng/index.php・dispatchmng.js、ellio/dispatch/index.php(現場打刻)、
    ellio/dispatchmngold/index.php・dispatchmng.js、dispatch.sql/shippingschedule.sql 定義。
    新規: alter_rename_date_columns.sql / backfill_dispatch_shipdate.sql / verify_migration.sql。
  デプロイ（2026-07-14 フェーズ1=改名カットオーバー）: ライブDBで CHANGE COLUMN 実行＋5コードを個別scp。
    実行前バックアップ _backup_dispatch_ss_20260714_2354.sql(実績12行)取得済み。非破壊(dispatch削除せず)。
  残(ユーザー指示待ち): フェーズ2 出荷予定表PDF再取込で shippingschedule.dispatch_date(出荷日)充填 →
    フェーズ3 dispatch.dispatch_date を(納期日+納入先)でbackfill → 元↔後をid基準で照合。
  フェーズ2/3 完了（2026-07-15 未明）: shippingschedule を DELETE→出荷予定表PDF(709行)を CLI(php56)で
    importSchedule 実行(parsed107/ssInserted107/matched13/mismatches無)→ shippingschedule.dispatch_date(出荷日)
    107件充填。dispatch.dispatch_date を (delivery_date+content) で backfill(18件更新)。実績のある2画面外の
    2行(id727 07-16日立/id737 07-15荻生=実績無)は現PDFに該当グループ無く出荷日NULLのまま。
    照合(verify_migration, id基準): 行集合一致/納期日不変/実績完全不変(差異0)/出荷日18充填/backfill妥当(差異0)。
    実績12行の時刻・天候・備考すべて無傷を確認。非破壊で完了。

2026-07-15 ellio/dispatchmng + dispatch: 配車画面の基準日を「積込日(出荷依頼日=dispatch_date)」に切替
  背景: 改名後も画面は納期日(delivery_date)基準のままで出荷依頼日が出ず「以前のまま」に見えた。
    配車の実態はトラック来場=積込日なので、画面・打刻の基準を積込日に統一。
  変更: dispatchmng/index.php の screen系(readDispatch/readRecordJson/listDates/dispForm-max/
    insertDispatch/insertTrip/deleteTrip/updateDest/listAssignedTrucks/readTripJson)の日付軸・グループキーを
    delivery_date→dispatch_date に(行範囲442-768の取込parse/importScheduleは納期日ベース維持で除外)。
    dispatchmng.js doInsertのパラメータを dispatch_date に。dispatch/index.php(現場打刻)の一覧フィルタ・
    天候一括・打刻時刻の日付ソースを dispatch_date に。旧残骸2行(id727/id737)は事前削除。
  検証(CLI/実DB): listDates=積込日一覧(07-13〜07-16 計18)。readRecord 07-13 に LIXIL石下(納期07-14)等が並び
    打刻時刻も正表示。デプロイ(2026-07-15): scp dispatchmng/index.php・dispatchmng.js・dispatch/index.php。

2026-07-15 ellio/dispatchmng: 出荷予定(shippingschedule)テーブルの表示・編集UIを追加
  ヘッダーに「出荷予定」ボタン新設(出荷予定PDF取込の左)、新規登録ボタンを右へ移動。
  出荷予定モーダル: 出荷日範囲で shippingschedule を一覧、全項目インライン編集(変更で自動保存)・行追加・行削除。
  index.php: listSchedule/updateSchedule(フィールドホワイトリスト)/insertSchedule(手動行はMANUAL-仮orderno採番)/
  deleteSchedule を追加。dispatchmng.html(ボタン並替+モーダル)、dispatchmng.js(open/load/render/save/add/delete)、
  style.css(.schedule-table/.sch-in)を追加。CLI/実DBで list(107)/insert/update/delete を検証(テスト行は削除)。
  デプロイ(2026-07-15): scp index.php・dispatchmng.js・dispatchmng.html・style.css。
  出荷予定編集: 数量/重量の列幅を58pxに縮小、サイズ列を min180px に拡大。デプロイ(2026-07-15): scp dispatchmng.js/style.css。

2026-07-15 ellio/dispatchmng: 配送マスター(carrierMaster)の表示・編集UIを追加
  ヘッダー「配車管理記録」の左に「配送マスター」ボタン新設。モーダルで carrierMaster を一覧・全項目
  インライン編集(会社/車番/車両ナンバー/運転手/車種/最大積載/稼働(checkbox)/表示順/備考)・行追加・行削除。
  index.php: listCarrier/updateCarrier(ホワイトリスト)/insertCarrier(手動行は NEW-xxxx 仮車番)/deleteCarrier。
  dispatchmng.html(ボタン+モーダル)、dispatchmng.js(open/load/render/save/add/delete)。CSSは.schedule-table流用。
  CLI/実DBで list(122)/insert/update(会社・稼働)/delete を検証(テスト行は削除)。
  デプロイ(2026-07-15): scp index.php・dispatchmng.js・dispatchmng.html。
  配送マスター: 会社名フィールドに datalist(companyList)を付与し、便編集画面と同じプルダウン＋補完を有効化。デプロイ(2026-07-15): scp dispatchmng.js。
  出荷予定編集: 列幅再調整(前段の58pxは狭すぎたため)。色を62pxに縮小し、その分を数量/重量に振り分け80pxに拡大。デプロイ(2026-07-15): scp dispatchmng.js/style.css。[commit 987e9b4]

2026-07-15 ellio/dispatchmng: 出荷予定エディタに「配車へ反映」ボタンを追加（出荷予定↔配送予定の整合手段）
  背景: 出荷予定編集はカードの荷量(ライブ集計)には即反映されるが、配車便(dispatch)の作成/weight保存値/
    出荷日は自動同期されず、日付・納入先変更や行追加で便とズレ得る。取込Step3相当を手動実行できるようにした。
  index.php: reflectDispatch アクション＋reflectToDispatch()。表示中の出荷日範囲の shippingschedule を
    (納期日,納入先)でグループ化し dispatch を upsert（便が無ければ作成／1便は重量再集計／出荷日は全便追従／
    2便以上は重量不触／実績・時刻・トラック割当は一切不変／孤立便削除はしない）。
  dispatchmng.html(出荷予定モーダルに「配車へ反映」ボタン)、dispatchmng.js(reflectDispatch, 反映後reloadDispatch)。
  検証(CLI/実DB, 架空09-09データ): reflect1=便作成(inserted1)/reflect2=更新(updated1,冪等)、後片付けで本番無変更。
  デプロイ(2026-07-15): scp index.php・dispatchmng.js・dispatchmng.html。
  出荷予定画面にも「CSV保存」ボタンを追加(配車管理記録と同様)。編集中の値を反映するためDOM入力値からBOM付きUTF-8/CRLFでダウンロード。列=出荷日/納期日/受注NO/納入先/規格/色/サイズ/数量/重量/工場備考。デプロイ(2026-07-15): scp dispatchmng.js/dispatchmng.html。

2026-07-15 ellio/dispatchmng: 配車管理記録の「対象月」を、記録がある年月のプルダウン選択に変更
  従来の <input type="month">(任意月)から、記録が存在する年月のみの<select>に。空月を選べなくする。
  index.php: listMonths アクション(dispatch.dispatch_date の DISTINCT YYYY-MM を新しい順)。dispatchmng.html:
  input→select。dispatchmng.js: openRecord で listMonths を取得しoption生成(現在月が無ければ最新月を選択)→loadRecord。
  検証: listMonths=2026-07。デプロイ(2026-07-15): scp index.php・dispatchmng.js・dispatchmng.html。
  配送マスターの並び順を会社名順に変更(listCarrier ORDER BY company, car_no。sortnoは並びから外す)。空欄の新規行は先頭。デプロイ(2026-07-15): scp index.php。
  出荷予定/配送マスターの行削除ボタンの🗑絵文字を Google Material Icons「delete」のインラインSVG(currentColor継承・外部フォント不要)に変更。ホバーで赤。デプロイ(2026-07-15): scp dispatchmng.js/style.css。

2026-07-23 ellio/dispatchmng: 配車管理記録に「滞在分」列を追加（退場列の右）
  目的: トラックが受付到着してから退場するまでの構内滞在時間を一目で把握できるようにする。
  仕様: 受付到着(F)→退場(I)の差分を分で表示。両方入力済みのときのみ数値、片方でも空なら「—」。
    日跨ぎ(退場<受付)は+24h補正。DB非依存の表示専用列(wait_time/work_timeのようなDB保存はしない)。
  dispatchmng.html: 退場thの直後に<th class="num">滞在分</th>を追加。読込中行colspan 19→20。
  dispatchmng.js: hmToMinutes()/stayMinutes()ヘルパー追加。行描画で退場セル直後に滞在分セル挿入。
    空/読込中/エラー行のcolspan 5箇所を20へ。CSV出力にも退場の右へ「滞在分」列を追加。
  CSSはクラスベース(.num)で列順依存なし→変更なし。
  検証: node構文チェックOK、列数整合(HTMLヘッダー/行描画/CSVヘッダー/CSV値=全20列)、
    stayMinutes単体(15:15→17:30=135/9:00→9:45=45/日跨ぎ23:30→0:15=45/未入力=—/同時刻=0)全て期待どおり。
  デプロイ（2026-07-23）: scp dispatchmng.html・dispatchmng.js。

2026-07-23 ellio/dispatchmng: 配車管理記録テーブルの「内容（納入先）」列の罫線崩れを修正
  症状: 内容（納入先）列だけ罫線が太い/ズレて見える。
  原因: セルが<td class="dest">で描画されるが、汎用.dest(style.css:389 カード用)が
    display:flex;flex-direction:column を当てており、当該tdがテーブルセル表示モデルから外れ、
    border-collapse の罫線が他セルと揃わなくなっていた（今回の滞在分列追加とは無関係の既存不具合）。
  修正: .record-table td.dest に display:table-cell; vertical-align:middle; を追加してflexを打ち消す。
    汎用.dest(カード用)には非干渉。style.cssのみ変更。
  デプロイ（2026-07-23）: scp style.css。

2026-07-23 ellio/dispatch: 現場打刻の天気ボタンにOpen-Meteo(気象庁モデル)の現在天気を自動反映
  目的: 「今の天候」ピルを手動選択に頼らず、現在の実況で自動更新する。
  情報源: Open-Meteo current(weather_code)＋models=jma_seamless、厚木の緯度経度(35.4436,139.3622)。
    ブラウザから直fetch(鍵不要/CORS*)。旧サーバーPHP5.3はTLS1.2不可のためサーバー経由は採らずクライアント側取得。
  天気コード変換: 0,1→晴 / 2,3,45,48→曇 / 51-67,80-82,95-99→雨 / 71-77,85,86→雪。
  取得: 初回＋30分ごと＋日付変更時＋スリープ復帰(focus/visibility)時。
  手動優先(期限付き): 人がピルをタップすると其の選択をタップから1時間尊重(自動更新で上書きしない)。
    1時間経過後は自動追従に復帰(1分ポーリングで失効判定し30分fetchを待たず切替)。日跨ぎで手動は無効。
    「自動に戻す」ボタンは設けない。手動確定はlocalStorageにタップ時刻(epoch ms)を日付単位で保持。
  表示: 天候欄に出典ラベル追加。自動中「気象庁 14:15 晴（自動）」/手動中「手動選択中（あと約N分で自動…）」。
  変更: dispatch.js(主)/dispatch.html(#weather-src span)/style.css(.weather-src)。index.php・DB変更なし。
    天候値は従来どおり打刻POSTのweatherパラメータでスナップショット保存。ES5準拠(旧タブレット対応)。
  配信/無停止確認: index.phpがdispatch.html+dispatch.jsをインライン展開、CSSは?date("His")で毎回キャッシュバスト。
    サーバーAPI(mode)/DB無変更のため、旧タブレットは再読込まで従来動作を継続、新機能は自然なリロードで有効化。
  検証: node構文OK、weather_code変換19ケース一致、旧シンボル残存なし/新シンボル整合。
  デプロイ（2026-07-23）: scp dispatch.js・dispatch.html・style.css。

2026-07-24 ellio/dispatch: 入荷受付フローに「最大積載kg」入力を追加（便ごとmax_load記録＋マスタ補完）
  目的: 入荷受付(現場タップ)時に dispatch.max_load を確実に記録し、carrierMasterの未登録max_loadも補完する。
  dispatch.html: ドライバー氏名をRequired化。最大積載kg入力(#maxLoadBox/#maxLoadBtn/#maxLoadVal)を追加。
  dispatch.js: arrCtxにmaxLoad/needsMaxLoad追加。テンキー(openNumpad)で入力。updatePlateNextDisabled()で
    会社名・氏名・最大積載の充足時のみ「打刻画面へ」を活性化。ヒット時max_load>0は自動採用(入力不要)、
    未登録(0)は赤表示＋入力要求。手入力/クイック業者はmax_loadもRequired。
  index.php createArrival: max_load受領→dispatchにINSERT。carrierMasterヒット時は補完、
    ヒット済でmax_load=0なら入力値を書き戻し補完(既存非0は上書きしない)、未ヒットはaddToMaster時のみINSERT。
    lookupCarrier/INSERT列(max_load)整合。
  style.css: 最大積載ボタンの装飾(.plate-in.max-load)。
  互換性: 新JS(max_load送信)は旧index.phpで無害、新index.phpは旧JS(未送信)で従来動作＝前方後方互換。
  検証: PHP構文OK/JS構文OK/openNumpad4オプション対応/DB列(dispatch.max_load,carrierMaster.max_load,updated_at)存在/
    参照ID存在/ヒット時arrCtx.carrier設定/INSERT列VALUES15列整合。全シナリオ動作整合を確認。
  デプロイ（2026-07-24）: scp dispatch.js・dispatch.html・index.php・style.css。

2026-07-27 ellio: 配送先(納入先)マスターを customertable に新設・投入 ＋ 作成日/更新日カラム追加（Phase A）
  背景: 配送管理の納入先は dispatch.content の自由入力で、配送先マスターが存在しなかった。補完基盤として整備。
  スキーマ: customertable に created_at/updated_at (DATETIME NULL) を追加（carrierMaster慣例に踏襲, AFTER sourceTimestamp）。
  マスター方式: 発送元(type='発送元')と並列に type='納入先'。delivercode=配送先コード、customerName=名称、
    dataSource='DISPATCH_CONTENT'、created_at/updated_at=NOW()。
  投入: dispatch.content の status='出荷' distinct から seed（入荷=発送元は除外）。コード付34＋コード無2＝計36件。
    DNPエリオ大阪工場の表記ゆれ(全角/空白)は1件へ名寄せ。delivercode(コード付)/customerName(コード無)で冪等化。
  文字コード: HEX検証で raw UTF-8 統一を確認済→ mysqli_set_charset utf8 で投入。投入後もHEX再検証OK(化けなし)。
  記録: ellio/dispatch/customertable_destination.sql に ALTER＋実INSERT＋ロールバックDELETEを保存(再現/監査用)。
  ロールバック: DELETE FROM customertable WHERE type='納入先' AND dataSource='DISPATCH_CONTENT';
  実施: 本番DB(zsystem.jp:3306, zadmin)へ直接接続で実行済み。ファイル転送は不要(DB作業のためコード配信なし)。
  次(Phase B・未着手): dispatchmng 新規/編集ダイアログの納入先欄を datalist 補完化(listDestinations)＋未登録時 upsertDestination(確認して登録)。

2026-07-27 ellio: customertable に走行距離カラム driving_distance_km を追加
  用途: 拠点(厚木/興国運輸)→納入先の片道 道路走行距離。配車計画等での利用を想定。
  命名: 「走行距離」の英語定番は driving distance(道路距離)。running distance は和製英語で誤読のため回避。
    単位を列名に埋め driving_distance_km（DECIMAL(6,1)・片道・NULL可）。COLUMN COMMENT='拠点からの片道走行距離(km)'。
    緯度経度(latitude/longitude)が既存のため、将来 距離APIで自動算出→本列へ格納する運用に載せやすい。
  文字コード: COMMENTも含めHEX検証で raw UTF-8 を確認(2026-07-11のコメント化け事故の教訓に従いmysqli_set_charset utf8で実行)。
  記録: ellio/dispatch/customertable_destination.sql に ALTER を追記。
  実施: 本番DB(zsystem.jp:3306, zadmin)へ直接接続で実行済み。転送不要。

2026-07-27 ellio: 配送先(納入先)の走行距離・座標・住所を投入（driving_distance_km 他）
  出発地: DNPエリオ愛川(神奈川県愛甲郡愛川町中津4013)。
  手法: 各納入先の住所をWeb調査(サブエージェント)→国土地理院GSIジオコーダで座標化→OSRMで道路距離(driving)。
    ※当初Nominatim(OSM)は日本住所/郵便番号の精度が低く誤り多発(府中→岡山等)→GSIに切替で解決。
  投入: type='納入先' 36件中 35件に driving_distance_km(片道km)・latitude/longitude(double)・address(GSI正規化住所)をUPDATE。
    updated_at=NOW()。距離昇順で 0.0km(拠点同一=DNPエリオ東京工場)〜770.6km(三和広島/安芸高田)。
  保留: 639103101 岩谷鋼業=コード郵便番号(奈良県大和郡山市今国府町)と実在確認が食い違い所在地未確定→NULLのまま(後日確認)。
  文字コード: address含めHEX検証で raw UTF-8 確認(化けなし)。mysqli_set_charset utf8 で実行。
  記録: ellio/dispatch/customertable_destination.sql に UPDATE(35件)を追記。列型 latitude/longitude=double, address=varchar(255)。
  実施: 本番DB直接接続。転送不要。

2026-07-27 ellio: customertable に走行時間カラム追加＋分・確度を投入
  driving_time_min (INT, COMMENT'拠点からの片道走行時間(分)') を driving_distance_km の後に追加。
  納入先36件: 走行時間(分)を35件に投入(OSRM所要)。sourceField に住所比定の確度を「確度：高/中/低」で全36件記載(高27/中8/低1)。
  岩谷639103101(保留)は時間NULL・確度：低のみ。文字コードはsourceField含めHEX検証 raw UTF-8確認。
  記録: customertable_destination.sql に ALTER+UPDATE を追記。実施は本番DB直接接続、転送不要。

2026-07-27 ellio/dispatchmng: 配車管理記録に「走行km」列を追加（積載率の右）
  目的: 各便の納入先までの片道走行距離を記録表に表示。配送先マスター(customertable type='納入先')の
    driving_distance_km を突合表示（表示専用・DB書込なし）。
  突合: readRecordJson で 納入先マスターの delivercode→距離 / customerName→距離 マップを構築。
    各行content から (コード) を正規表現抽出しコード優先、無ければ名称完全一致、無ければ null(—)。
  index.php: readRecordJson に距離マップ＋各行'distance'付与。
  dispatchmng.html: 積載率thの右に「走行km」th追加、読込中行colspan 20→21。
  dispatchmng.js: 積載率セルの右に距離セル、colspan5箇所→21、CSVに「走行km」列追加。CSSは.num流用で変更なし。
  検証: PHP/JS構文OK、列数21整合(HTMLヘッダー/描画td/CSVヘッダー)、実データ突合=出荷35件ヒット/入荷5件は—/岩谷保留—。
  既知: 記録側「㈱ＤＮＰエリオ　大阪工場」(全角表記)はマスター名寄せ後名称と不一致で—(コード無しゆえ取りこぼし・許容)。
  デプロイ（2026-07-27）: scp index.php・dispatchmng.html・dispatchmng.js。

2026-07-27 ellio/dispatchmng: 配車管理記録の走行km表示を四捨五入・整数化
  表示とCSVで Math.round(Number(r.distance)) に変更（例 146.7→147）。DBのdriving_distance_kmはDECIMAL(6,1)のまま保持（表示専用の丸め）。
  dispatchmng.js の描画セル・CSV値の2箇所のみ修正。
  デプロイ（2026-07-27）: scp dispatchmng.js。

2026-07-27 ellio: 配送先マスターの住所・距離を shippingschedule 公式住所と照合・再ベース
  発見: shippingschedule.nonyusaki_addr に納入先の公式住所あり(コード付34件)。これを正として全照合。
  更新: コード付34件の address を公式住所に統一→GSIで座標化→OSRMで距離/時間を再計算→sourceField='確度：高'。
    多くは±0.1km(元値も妥当)。意味ある差: 原田港湾(海岸通→山下町279-1 5号上屋 35.6→37.5)、イトーキ関東第2(番地2288判明 106.5→108.8)、
    三菱電機静岡(146.7→145.3)、原伸梱包(135.0→134.4)。岩谷639103101は住所判明(奈良県大和郡山市今国府町411番地7)で保留解除=436.8km/325分・確度高。
  結果: 納入先36件すべて距離あり(=code無2件含む)。確度：高35/中1(=code無のDNPモビリティ三芳のみ中、shippingschedule対象外)。
    code無2件(DNPモビリティ三芳/DNPエリオ大阪)はshippingscheduleに無く現状維持。
  文字コード: address HEX検証 raw UTF-8確認(化けなし)。記録: customertable_destination.sql に UPDATE(34件)追記。本番DB直接、転送不要。

2026-07-27 ellio/dispatchmng: 配車管理記録の走行km表示ルール変更（1km以下は小数点1桁）
  表示・CSVとも: 1km超は四捨五入で整数、1km以下は toFixed(1)（近すぎる場所で0や過剰丸めを避ける）。
  例: 0.6→0.6 / 1.0→1.0 / 1.4→1 / 146.7→147。該当実データ=DNPエリオ東京工場(0.6km)。DB値は変更なし(表示専用)。
  dispatchmng.js の描画セル・CSV値の2箇所修正。デプロイ（2026-07-27）: scp dispatchmng.js。

2026-07-28 ellio/film: 入荷処理をパレット単位のまとめ登録に変更（カンバン付け替えを廃止）
  背景/目的: 入荷～入庫は時間スパンが短く、現物へのカンバン付け替え（MOV 003→037）が手間に見合わない。
    現場了解のもと zsystem の原則（工程変更＝カンバン付け替え）から意図的に外れ、
    予定pack(003xxx)に「パレットNo」と「入荷数」を書いた状態を入荷済みと判定する方式へ変更。
  変更点:
    ・registArrival（MOV 003→037）を廃止 → registArrivalPallet（SETPROPAT locate + differenceQty）
      037xxx帯は pack を作らず、パレットの札としてのみ使用（locate の値。工程番号ではない）。
    ・入荷UIをパレット単位のまとめ登録へ: パレットNo → 左の予定リストをタップ → 数量 → 明細へ追加(繰返)
      → 「入荷登録」で1パレット分を一括送信。明細は数量欄の下に1行ずつ、同一予定は上書き、個別削除可。
    ・分納対応: 入荷数<予定数なら残りを受ける行を003帯から自動発番して分割（3分割以上可）。
      invoiceno を親子で共有、子は qty=0（予定数・残数・区分は親のみ）。親の直下に隣接表示。
      二重発番防止 hasOpenPlanRow()。残数=親qty－グループ全行のdifferenceQty合計。
    ・カラムの役割変更: JITdate=入荷予定日 / arrivaldate=入荷実績日(入庫時に刻む) /
      differenceQty=入荷数 / locate=パレットNo。qty は double NOT NULL のため子行は 0 で「空」を表現。
    ・②リストを12→14列（パレットNo・入荷数を追加）。選択行を全体強調。日付基準を JITdate に。
      区分判定を tasklog走査(calcPlanRemain)から differenceQty 基準へ変更＝1クエリ化で軽量に。
    ・④入庫: 先頭にパレットNo欄を新設 → listPlanByPallet でそのパレットの予定を一覧 → タップで選択。
      「入荷P.No」は画面表記のみ据え置き、中身は003xxx（帯チェック 37000-37999 → 3000-3999）。
      MOV は 003→040/044（qty=1）。入庫残 = 入荷数 － 003→040/044 MOV合計（calcStoreRemain）。
  DB移行: UPDATE pack SET JITdate=arrivaldate, arrivaldate='0000-00-00 00:00:00'
      WHERE packno BETWEEN '003000' AND '003999';  （既存30件。コード転送と同時に実施）
  調査で判明した訂正: SPEC.md の「ellio は zgrouplist.flag5 が全工程で空欄」は誤り。
    実際は フィルム入荷予定003=仕入在庫 / フィルム仮置き037=仕掛在庫 / フィルム保管040-044=良品在庫 が
    設定済みで在庫自動集計が駆動していた。よって今回のトレードオフは実影響あり＝
    037(仕掛在庫)は常に0、003(仕入在庫)は予定数のまま残る（良品在庫040/044は入庫時に正常計上）。
    SPEC.md §8 を訂正し §10 に本変更を追記。トレードオフ整理は
    ~/Downloads/film_入荷カンバン付替省略のトレードオフ_2026-07-28.md に別途作成。
  E2E: 本番ellio DBで実施し全項目合格（予定登録→JITdate/arrivaldate、パレット入荷→locate/differenceQty、
    分割発番、残0で分割せず、リスト親子表示、パレット照会、入庫MOVと実績日、differenceQty非流出、
    予定側qty不変、入庫残）。テストpack(003045-047,044901-902)と各ログ・commandlogを完全削除し
    EF00086 の StockQty/EAqty を再計算して復元。
  デプロイ（2026-07-28）: scp index.php / form.html / index.js / film.css ＋ 上記移行SQL。

2026-07-28 ellio/film: パレットNo入力後のEnterでフォーカスが進まない不具合を修正
  現象: ③入荷でパレットNoを入力してEnterしても次の項目へカーソルが移らない。
  原因: onPalletScan() が stripPacPrefix() のバリデーションのみで focusField() を書いていなかった
    （他フィールドはEnterで次へ送っている中、パレットNoだけ抜けていた）。
  修正: ③入荷 パレットNo→入荷予定P.No へフォーカス送り。④入庫にも同一の抜けがあったため
    パレットNo→（一覧描画後）入荷P.No へフォーカス送りを追加。いずれも直接スキャン運用も受けられる。
  デプロイ（2026-07-28）: scp index.js のみ。

2026-07-28 ellio/film: ③入荷の数量入力をテンキー（現場打刻と同じUI）に変更
  目的: タブレット運用でOSソフトキーボードが出ると入力しにくいため、現場打刻（ellio/dispatch/）と
    同じテンキーパネルに統一する。
  実装: dispatch/ のテンキー（printschedule 由来の設計）を film へ移植。構造・挙動は同一で
    配色のみ film のライトテーマ（アクセント #2f6fcb）に合わせた。
    ・数量欄を readonly + inputmode="none" にしてOSキーボードを抑止、tap/focus で openQtyNumpad()
      → 予定選択後に数量欄へフォーカスが移る流れでそのままテンキーが開く。
    ・キー配列 7-9/4-6/1-3/0 ＋ 消去・◀︎・「明細へ追加」。×/背景タップ/Esc で閉じる。
    ・パネル内に「予定P.No ○○／予定残 ○本」を表示（numpad-sub）して誤入力を防ぐ。
    ・タブレット対策は CSS touch-action:manipulation のみ。touchend での preventDefault() は
      使わない（Android Chrome が後続の synthetic click をキャンセルし押せなくなる既知の罠。
      dispatch.js のコメントに記録あり）。
  ①入荷予定タブの数量は従来どおり（今回は③入荷のみ対象）。
  デプロイ（2026-07-28）: scp form.html / index.js / film.css。

2026-07-28 ellio/film: テンキーが表示されない不具合の修正（3点）
  現象: ③入荷の数量欄をタップしてもテンキーパネルが出ない。
  修正1（本命）: openQtyNumpad() に「入荷予定が未選択なら開かない」ゲートを入れていたため、
    数量欄を先にタップすると赤メッセージが出るだけで何も起きないように見えた。
    未選択でもパネル自体は開き、注記（※入荷予定が未選択です）を numpad-sub に出す方式へ変更。
    数量の妥当性判定は従来どおり onAddArrivalItem() 側に任せる。
  修正2: .numpad の inset:0 を top/right/bottom/left:0 の個別指定に変更。
    inset ショートハンドは古いWebView/Safariで未対応＝position:fixed 要素が潰れて不可視になるため。
    （既存の .pbadge.shC::before も inset を使っており正常描画されているので可能性は低いが予防的に）
  修正3: readonly な input は端末により click/focus が発火しないことがあるため、
    arr_qty に touchend でも openQtyNumpad を張る保険を追加（preventDefault は呼ばない＝
    後続の synthetic click を殺さない。二重発火は numpadIsOpen() ガードで無害化）。
  デプロイ（2026-07-28）: scp index.js / film.css。

2026-07-28 ellio/film: ③入荷の明細を入荷予定リストへ仮反映（登録ボタン前でも見えるように）
  目的: パレットに積んだ内容を「入荷登録」を押す前に予定リスト上で確認できるようにし、
    積み間違いをその場で気づけるようにする。
  実装: renderPlanList() で未登録明細（arrItems）を重ねて描画。
    ・パレットNo列＝入力中の arr_pallet の値、入荷数列＝明細の数量を表示（親行・分割された子行とも）。
    ・未保存であることを示すため 行に .row-prov（淡いオレンジ背景）、セルに .prov
      （オレンジ・斜体・点線下線）を付与。
    ・残数と区分(◯▲■)も仮の値で連動させる（入荷数だけ動いて残数が据え置きだと数字が合わないため）。
      残数セルにも .prov を付けて未確定であることを明示。
    ・明細削除（removeArrivalItem）とパレットNo再入力（onPalletScan）でも loadPlanList() を呼び、
      仮反映の取り消し・追従を行う。登録後はサーバーから読み直して通常表示に戻る。
  デプロイ（2026-07-28）: scp index.js / film.css。

2026-07-28 ellio/film: ④入庫の選択状態キープ＋入庫登録ボタンの新設（即時書き込みをやめる）
  目的1: パレット内の入荷一覧をタップして詳細を出したとき、どれを棚入れ中か分からなくなるため
    選択行を色でキープする。
  目的2: 入庫P.Noをスキャンした瞬間に MOV が走って書き込まれてしまい、読み間違いの取り消しができない。
    「入庫登録」ボタンを押すまで書き込まない方式に変更する。
  実装:
    ・renderPalletList() を引数なし再描画に対応（palletRows を保持）。選択中の入荷P.Noと一致する行に
      .item-sel（青反転）を付与。selectPalletItem / 登録後の reloadPalletList でも選択を維持。
    ・onStoreStPacknoScan() を「storeBadges に溜めるだけ」に変更（同一P.Noの二度読みは拒否）。
      バッジに × を付けて個別取り消し可、読取本数を st_count に表示。
    ・onRegistStore() を新設＝溜めた入庫P.Noをまとめて送信。入力欄に残った未確定P.Noも取り込む。
      登録後はバッジをクリアし、ラック図・入庫残・パレット内一覧の残数を更新（選択はキープ）。
    ・PHP に RegistStoreBatch()（mode=registStoreBatch）を新設。stpacknos=カンマ区切りを受け、
      1本ずつ MOV 003→040/044（qty=1）＋属性 SETPROPAT。帯外は個別にエラー収集して継続。
      既存の RegistStore()（1本用）は互換のため残置。
  検証: php -l / node --check、ローカルでバリデーション応答を確認（帯外・空リストとも書き込み無しで拒否）。
  デプロイ（2026-07-28）: scp index.php / form.html / index.js / film.css。

2026-07-28 ellio/film: ④入庫でパレット上の商品を棚図に強調＋在庫クエリに保管帯の絞り込みを追加（バグ修正）
  機能追加（依頼）: 入庫タブでパレットNoを入力しパレット上の入荷一覧が出た時点で、
    それらと同じ商品が棚のどこにあるかをラックチャートで強調する。棚入れ先を決める際に
    「同じフィルムがどこに固まっているか」を見えるようにするのが狙い。
    ・SearchStock() に productcodes（カンマ区切り）を追加＝混載パレットの複数商品を一括検索。
      既存の productcode 単一指定は互換維持。
    ・highlightPalletProducts() を新設。強調は検索タブと同じ（マス=hlsearch／バッジ=hl）。
    ・onStoreLocateScan() は clearHighlight() をやめ clearTargetHighlight()（オレンジのみ解除）に変更。
      商品の強調を消さずに棚入れ先と重ねて表示する。
    ・loadRackData(alsoTable, done) にコールバックを追加。入庫登録後の再描画で強調を張り直す。
  バグ修正: 2026-07-28 の入荷仕様変更で 003xxx（入荷予定）にも locate（パレットNo）が入るように
    なったため、GetRackData() / SearchStock() の条件が locate!='' だけでは
    「まだ棚に入っていないパレット上の現物」を在庫として拾っていた。
    （例: EF00021:003008@037101 が検索結果に混入）
    両方に packno BETWEEN '040000' AND '044999'（フィルム保管＝良品在庫の帯）を追加。
    棚図の描画は locateToCell() がパレットNo形式を解釈できず捨てていたため絵は崩れていなかったが、
    検索タブの在庫一覧と「全在庫 N本」の件数には混入していた。
  検証: 修正後 searchStock から003帯が消え、getRackData は135件すべて040/044帯。
  デプロイ（2026-07-28）: scp index.php / index.js。

2026-07-29 ellio/film: ④入庫でパレット上の商品を色分けし、自動ラックの同種商品も同色に
  目的: パレットに複数種類の商品が載っているとき、どれをどこへ入れるかを最初に検討できるよう、
    パレット一覧の行頭に商品ごとの色サンプルを付け、自動ラック上の同種商品バッジを同じ色で塗る。
  実装:
    ・renderPalletList() で商品コードに出現順で色番号を割り当て（palletColorByCode、8色で循環）。
      行頭に .item-chip + .chipN の色サンプルを追加。同一商品が複数行でも同じ色。
    ・highlightPalletProducts() のバッジ強調を .hl 固定から .hlcN（商品別の色）に変更。
      パレット由来でない場合（色未割当）は従来の .hl にフォールバック。
    ・clearHighlight() を正規表現で .hl / .hlcN をまとめて除去する方式に変更。
    ・CSS: .chip0-7 / .pbadge.hlc0-7 を定義（橙/青/緑/紫/赤/濃橙/青緑/茶）。
      円筒バッジ shC は本体透明で ::before の円が色を持つため .pbadge.shC.hlcN::before を個別指定。
      縦長バッジ shV は本体に色が乗るので追加指定不要。
    ・棚のマス自体は従来どおり水色枠（1マスに複数商品が入るため色はバッジ側で表現）。
  デプロイ（2026-07-29）: scp index.js / film.css。

2026-07-29 ellio/film: パレットNo/packno入力のLOC接頭語対応＋入荷パレットNoの自動割り当て
  変更1（接頭語）: stripPacPrefix() が除去する接頭語に「LOC」を追加（従来はPACのみ）。
    パレットNoの札はロケ扱いのため LOC 付きで刷られている場合があり、PAC/LOC どちらを読んでも
    通るようにする。対象は本関数を使う6フィールド（③入荷のパレットNo/入荷予定P.No、
    ④入庫のパレットNo/入荷P.No/入庫P.No、入庫直接のPackNo）。小文字・前後空白も許容。
    除去後に6桁数字でなければ従来どおりクリア＋エラー。ロケ欄は対象外（指示範囲外のため）。
  変更2（パレットNo既定値）: 現場から「カンバンを読むより指定された札を使う方が楽」との意見。
    入荷タブを開いた時と登録後のリセット時に、037帯で未使用の最小番号を自動で入れ、
    フォーカス＋全選択にする（指定札を使うならEnter、別の札ならそのままスキャンで上書き）。
    ・PHP に NextPalletNo()（mode=nextPalletNo）を新設。
    ・「使用中」の判定は2つ: (1)その番号が packno として実在する（旧方式の工程カンバン=恒久的に不可）
      (2)その番号をロケに持つ入荷予定に未入庫の現物が残っている（入庫残>0）。
      (2)により棚入れが終わればパレットは再利用される。
    ・JS に loadNextPalletNo() を追加し switchTab('arrival') と resetArrivalForm() から呼ぶ。
  現状メモ: 037帯には7/23作成の工程カンバンが6件実在（037001,002,003,009,011,012）。
    パレット番号はその隙間から埋まる。混在を避けたい場合はパレット専用帯（例037100〜）の
    採用を要検討（未実施）。
  デプロイ（2026-07-29）: scp index.php / index.js。

2026-07-29 ellio/film: パレットNo発番のルール変更（開始037001／ロケ使用のみで判定）
  変更1: 開始番号を 037000 → 037001（札を1番から起こすため 037000 は欠番）。
  変更2: 「使用中」の判定から「その番号が packno として実在する」条件を外し、
    ロケ（パレット）として使われているかどうかだけで判定するよう変更。
    ＝入庫残>0 の入荷予定がその番号をロケに持っていれば使用中、棚入れが終われば解放・再利用。
  結果: 7/23作成の工程カンバン（037001,002,003,009,011,012）は判定から除外されるため、
    次の発番は 037001。パレットNoと工程番号で同じ番号が同時に存在し得る状態になる。
    システム上は格納先が別（locate と packno）なので処理は正しく動くが、番号だけでは区別がつかない。
    現物の札で見分ける運用とするユーザー判断。
  デプロイ（2026-07-29）: scp index.php。

2026-07-29 ellio/dispatchmng: 納入先マスター管理画面を追加（Phase B含む）＋走行km補完UI
  ① 納入先入力の補完(Phase B): 新規/編集ダイアログの納入先欄#nf_contentをdatalist(destList=配送先マスターtype='納入先')化。
     値は「名称(コード)」形式でdispatch.content互換→走行km突合が効く。未登録入力時はconfirmで配送先マスタに追加(add_dest→upsertDestination)。
     backend: destinationOptions()/[DESTOPTS]注入, upsertDestination(), insertDispatchにadd_dest処理。
  ② 納入先マスター画面: ツールバーに「納入先マスター」ボタン＋#destOverlay(配送マスターと同型のインライン編集)。
     編集列=名称/コード/住所/走行km/走行分＋削除(＋行追加)。全操作type='納入先'スコープ(発送元・他行不干渉)。
     backend: listDestMaster/updateDestMaster(ホワイトリスト)/insertDestMaster/deleteDestMaster。
     確度(sourceField)列は当初入れたが「取込時指標で不要」との判断で画面から削除(DB列は発送元用に保持)。
  検証: PHP/JS構文OK、CRUD通し(実DB, テスト行掃除)、type='納入先'スコープガード動作、列数整合(dest=6列)。
  補足: 距離自動再計算は本画面非搭載(本番PHP5.3がGSI/OSRM=TLS1.2不可)。住所編集後の距離は手入力or当端末で一括再計算。
  デプロイ（2026-07-29）: scp index.php・dispatchmng.html・dispatchmng.js。

2026-07-29 ellio/film: 自動ラックチャートで9Vの縦長バッジが縦1/3に短く描画される不具合を修正
  現象: 現場で本日登録を行ったところ、一部のT5が棚図で縦に短く表示された。
  原因: 縦長バッジ(shV)は shV-row 内で align-self:stretch により棚セルの高さいっぱいに伸ばす設計だが、
    stretch は cross-size が auto のときしか効かない。bs11 は height 未指定なので伸びる一方、
    bs9 は横置き9B/9C用に height:calc((100%-3px)/3) を持つため高さが固定され、縦1/3になっていた。
    T5には11V(EF00166/170/171/172)と9V(EF00173/174)があり、9Vが棚に入るのが今回初めてで表面化した。
  修正1（高さ・報告された症状）: .shV-row .pbadge.shV に height:auto を追加し stretch を有効化。
  修正2（幅・同原因で潜在していたずれ）: shV-row の幅を一律「本数/11」で算出していたため、
    9Vが本来の cell幅/9 ではなく cell幅/11 の細さで描かれていた（太い品ほど大きく描く規約と矛盾）。
    ・JS: 太さ別に本数を数え、行幅 = (n9/9 + n11/11) × cell幅 に変更（1超は棚幅で頭打ち）。
    ・CSS: .shV-row .pbadge.bs9{flex-grow:11} / .bs11{flex-grow:9}＝収納数の逆比。
      これで混在棚でも1本あたりの幅が 9V=cell幅/9、11V=cell幅/11 になる。
  検算: 11Vのみ/9Vのみ/混在(9V×3+11V×4=実棚00100704相当)の全ケースで1本あたり幅が理想値と一致。
  デプロイ（2026-07-29）: scp index.js / film.css。

2026-07-29 ellio: 履歴ビュア（ellio/packviewer/）を新設＋filmの検索タブからダブルクリックで開く
  目的: フィルムの在庫リストから、その現物がどの工程をどう流れてきたかをすぐ確認できるようにする。
  1) ellio/packviewer/ を新規作成（letip/packviewer/ の複製）。index.php + find.php の2ファイル。
     letip版からの変更2点:
     ・P.No判定を strlen($uc)===5 → 数字6桁の正規表現に変更。
       letip の packno は5桁だが ellio は6桁（全555件が6桁）。そのままだと ellio のP.Noが
       個品番号として扱われ、uniquecodetable を空振りしてからのフォールバック動作になっていた。
     ・Z入力ボタンのリンク先を zsystem.jp/letip/ → zsystem.jp/ellio/ に変更。
       ※ellio/index.php は pid / sendsrcpackno を解釈しない（letip にのみ実装あり）ため
         packno の自動入力は効かない。受け口を追加すれば有効になる旨をコメントで明記。
     依存確認: 参照テーブル（pack/packlog/packlogindex/person/ProductDistributeTable/
     uniquecodetable/zgrouplist）は全て ellio に存在。require の階層も letip と同じ。
     DBはURL第1セグメントから自動解決。個品番号は ellio で未使用(0件)＝実質P.No検索専用。
     動作確認: 040053 で工程遷移（003027→003048→040053）と属性変更履歴・作業者名まで正しく表示。
  2) film の検索タブ：在庫リストの行ダブルクリックで履歴ビュアを別タブに開く（openPackViewer）。
     URL は ../packviewer/index.php?uniquecode=<packno>。packviewer 側は uniquecode があると
     読み込み時に自動検索するため、渡すだけで結果が出る。単クリックの既存動作は変更なし。
     行 title に案内を表示。
  デプロイ（2026-07-29）: ellio/packviewer/（新規ディレクトリ・2ファイル）＋ ellio/film/index.js。

2026-07-29 ellio/film: 在庫リストのサイズ列を現物値に変更＋棚図で特定の縦長バッジだけ細くなる不具合を修正
  【1】サイズ列の表示元を商品マスタ→現物(pack)に変更（ユーザー指摘: 040040は長さ950で登録済みなのに
    在庫リストが1000と表示）。
    原因: SearchStock()/GetRackData() が pdt.Size（ProductDistributeTable）のみをSELECTしており、
      pack.width/height/length を取得していなかった。長さは端数ロール（1000m品の950m等）があるため
      商品コードの特定キーから外してある設計＝マスタSizeでは現物の長さを表現できない。
    対応: 両クエリに pack.width/height/length を追加し、addPackSize() で size_l/size_t/size_w を付与。
      pack側が未設定の古いデータのみ pdt.Size を分解してフォールバック。
      mkSizeTd() を行オブジェクト受け取りに変更（従来のSize文字列渡しも後方互換で受ける）。
      GetRackData のソートも pdt.Size 順 → pack.length,pack.width 順に変更（表示と並びを一致）。
    副次的発見: 040000-040002 もマスタ1000に対し現物800だった＝端数ロールが見えていなかった。
  【2】040040(9V)だけ棚図で幅が細い不具合を修正。
    原因: 同じ棚を指す locate 表記が2種類混在（'00100804' と '01-08-04' が共に レーン1-列8-段4 に解決）。
      縦長バッジ用の shV-row を locate文字列 をキーに作っていたため、1つのセルに shV-row が2つできていた。
      幅指定は querySelector('.shV-row') で先頭1つにしか当たらず、残りは幅未指定＝内容なりに潰れて細くなる。
      高さはCSS(height:auto+stretch)で決まるため先の修正で両方直っており「高さは直ったが幅だけ細い」
      という症状になっていた（ブラウザキャッシュではなくコード側の問題）。
    対応: shVRowByLoc のキーを locate文字列 → セルID に変更し、表記の違いを吸収。1マス1行を保証。
    調査: 表記が重複しているセルは (1,8,4) の1件のみ。locate表記の統一（8桁 or ハイフン）は
      データ側の課題として残置（今回は未実施）。
  デプロイ（2026-07-29）: scp index.php / index.js。

2026-07-29 ellio/film: 縦長バッジの幅を棚によらず一定に修正＋棚ロケをハイフン区切りで記録
  【1】同じ9Vでも棚によって幅が違う（実測 1-8-4=65.20px / 1-7-4=66.42px）。
    原因: 幅を flex の配分（flex-grow 11:9）に任せていたため、棚の本数構成とバッジ間余白の
      総量によって1本あたりの取り分がずれた。行幅に余白分を上乗せしても解消しなかった
      （計算値 66.0/54.0 に対し実測 67.34/52.19 と一致せず、配分方式では合わせ込めないと判断）。
    対応: 配分をやめ1本ごとの幅を収納数から直接指定する方式へ変更。
      CSS: .cell .shV-row .pbadge.bs9{width:calc(100%/9 - 1px)} / .bs11{width:calc(100%/11 - 1px)}
           .shV-row{justify-content:flex-end} ／ .pbadge.shV は flex:0 0 auto に変更。
           横置き用の .cell.tier4 .pbadge.bs9 を確実に上回るよう5クラス指定も併記。
      JS: shV-row の幅計算（本数/収納数の合計）を廃し calc(100% - 2px) 固定に簡素化。
    実測（ヘッドレスChromeで計測）: 修正後は 1-8-4(9V×5)と 1-7-4(9V×4+11V×3) の両方で
      9V=64.98px・11V=53.00px と完全一致。-1px はバッジ間の隙間ぶんでピッチは棚幅の1/9・1/11。
  【2】棚ロケの表記をハイフン区切り「1-8-4」に統一して記録する（ユーザー決定）。
    背景: カードキーの読み取り値に8桁形式('00100804')とハイフン形式('01-08-04')が混在し、
      同じ棚が別表記で記録されていた（先の shV-row 二重生成バグの遠因）。
    対応: normalizeLocate() を追加し、棚ロケを書く3か所で必ず変換。
      RegistStore / RegistStoreBatch / RegistFilm。'00100804'→'1-8-4'、'01-08-04'→'1-8-4'、
      ' 02-10-01 '→'2-10-1'。解釈できない文字列はそのまま返す。
      ※パレットNo（003帯の locate に入る6桁）は通さない＝変換すると壊れるため。
    既存データ: 8桁形式22マス／ハイフン形式4マスが残存。一括変換は未実施（要判断）。
  デプロイ（2026-07-29）: scp index.php / index.js / film.css。

2026-07-29 ellio/packviewer: 履歴ビュアで連続する情報変更を1ブロックにまとめて表示
  現象/要望: 同じパックに対する SETPROPAT が属性ごとに1件ずつログ化されるため、
    「日時＋工程名＋情報変更バッジ＋元パック番号＋作業者」が変更項目の数だけ繰り返され読みにくい。
  対応: buildHistoryLog() を、描画前に表示単位（セクション）を組み立てる方式へ変更。
    結合条件（すべて満たす場合のみ1セクションに統合）:
      ・情報変更(SETPROPAT/SETPROP)が連続している
      ・同じパック（pn一致・空でない）
      ・タイムスタンプが秒まで一致（異なれば別操作として区切る）
    結合時は見出し（タイムスタンプ・工程名・情報変更バッジ）と区切り線を出さず、変更内容の行だけ追加。
    2件目以降の「元パック番号」「作業者」は繰り返しになるため除外（先頭の1回のみ残す）。
    工程遷移(MOV)は従来どおり独立したセクションとして区切られる。
  確認: 040053 で同一秒内の8項目が1ブロックに集約され、時刻の異なる情報変更は分割された
    （見出し数 12→14 は秒違いを区切った結果）。
  デプロイ（2026-07-29）: scp ellio/packviewer/find.php。

2026-07-31 ellio/shearspec: シャーリング寸法指定書マスタ 新規作成
  目的/背景: 厚木事業所のシャーリング寸法指定書（製品の設計図でもある指示書）を紙運用から
    システム登録へ移行する。過去分（2000年〜）は年式でフォーマットが異なり手書きも多い。
    今後の運用では作業時にタブレットで指定書を参照したい、という要件がある。
  検討経緯: 過去8枚（2000/2007/2013/2015/2020/2023/2024/2026年）を読み取り項目を棚卸し。
    切断図の持ち方を「切断線の絶対座標」ではなく【2軸セグメント方式】に決定。
      巾方向・長方向をそれぞれ {種別(製品/捨て代/端材), 寸法, 本数} の列で表現し、
      size=NULL は「残り自動」（大板寸法から端材を逆算）。格子の交点が製品セル。
      → 取数・落とし代・対角の自動算出と整合チェックが成立する。
      → 切断順序は持たない（どちらの軸を先に切るかは shearcompiler が決める領域のため）。
    実物8枚のうち7枚がこの方式で再現可能なことを HTML プロトタイプで確認済み。
  役割分担の決定: shearspec = 何を切るか（寸法指定書＝設計情報）
                  shearcompiler = どう切るか（機械割当・工程展開・能力/コスト算出）※今後別途
  キー: シャーCD ＝ 指定コード ＝ businessRawdata.shearID と同一体系（ユーザー確認済）
  保持しない項目: 承認・作成（押印）、生産管理課 → 入力負担に対し価値が薄く、原本画像で確認する
  過去分の取込方針: Claude で読み取り → 人間が確認する方式（案2）。
    項目単位に ocr_value / final_value / confidence / source / verified を持つ。
    source='inferred'（他文書からの推測）は確認するまで確定値として扱わない。
    ※検討中に p2(2023 YKK AP 転用材) の領域指定を p1 から推測で補完してしまい、
      「人間が原本を見ても読み取れない値が入る」問題が判明したことによる措置。
  既存資産の扱い: ellio DB に camelCase の shearCompiler 系（shearCompilerIndex 14,560件ほか）が
    存在するが、切断位置・machineName・status は全件空、最終更新 2025-03-31、参照コードなしの
    休止状態。今回は一切触らない。データ移行も行わない（ユーザー判断）。
  作成テーブル（2026-07-31 本番 ellio に作成済）:
    shearspec / shearspec_segment / shearspec_region / shearspec_field
  作成ファイル: index.php(一覧) edit.php(登録・編集) view.php(帳票表示・タブレット閲覧)
    ajax.php(API) shearspec.js(切断図エンジン) shearspec.css schema.sql
  主な機能: 大板・シャーリング・取数からのレイアウト逆算（丁取り構成の候補提示）、
    セグメント合計/取数/製品寸法の検算、落とし代と対角理論値の自動算出、
    原本スキャン取込（PDF→pdftoppm でページ毎PNG）、帳票プレビューとA4横印刷。
  デプロイ（2026-07-31）: scp ellio/shearspec/ 一式。

2026-07-31 ellio/menu + ellio/shearspec: メニュー導線追加とログイン認証の適用
  目的/背景: 寸法指定書マスタを厚木事業所ポータルから開けるようにする。あわせて他の
    シャーリング系画面と認証レベルを揃える（当初 shearspec は認証なしで公開されていた）。
  menu/index.php: シャーリンググループの末尾に「寸法指定書（開発中）」を追加。
    menu/CLAUDE.md の規約どおり相対URL go("/shearspec/") を使用
    （絶対URLだと HTTPS→HTTP のダウングレードでリファラーが落ち、cookie自動ログインが切れる）。
  shearspec: index.php / edit.php / view.php の3ファイルに LoginCheck("100") を追加。
    ajax.php には入れない（fetch がログインフォームHTMLを受け取って壊れるため）。
    ellio/film/index.php と同じ方針＝画面表示時のみ認証、ajax処理では呼ばない。
  デプロイ（2026-07-31）: scp ellio/menu/index.php、ellio/shearspec/{index,edit,view}.php。

2026-07-31 ellio/shearspec: 過去分8件の登録と、表示画面の廃止・一覧操作の変更
  過去分8件の登録: プロトタイプで読み取った実物（2000/2007/2013/2015/2020/2023/2024/2026年）を
    id 11〜18 で登録。原本スキャン（幅1600px PNG）を images/11〜18/p-1.png に配置。
    全件 intake_type=1（AI読取）・verified=0（未確認）。
    判読困難・推測の項目は shearspec_field に出所つきで記録:
      id12(YKK AP) 領域指定=inferred(source_ref=11、原本から範囲が読めないため切断図には未登録)、
      id12 巾方向セグメント/シャーCD=low、id15・id16 検査小断=low、id11 発行日の手書き訂正=medium。
    ※id 1 に空レコード（画面からの保存試行分）が既にあったため、衝突回避で 11 開始とした。
  表示画面(view.php)の廃止: 編集画面に帳票プレビューと印刷（帳票／切断図のみ）があり重複するため削除。
    edit.php の「帳票表示」ボタン、index.php の「表示」ボタン、CSS の .view-wrap を除去。
  一覧の操作変更: 「表示」「編集」ボタンを廃止し、行のダブルクリックで編集画面を開く方式に変更。
    行に cursor:pointer とホバー色、フィルタバーに操作説明を追加。
  デプロイ（2026-07-31）: scp ellio/shearspec/{index.php,edit.php,shearspec.css}、サーバー上の view.php を削除。

2026-07-31 ellio/shearspec: 原本スキャンのAI読み取り（Mac mini ローカルLLM）を追加
  背景: 過去分の登録を人手のみで行うのは負担が大きい。Mac mini 上の Ollama(qwen2.5vl:7b) が
    SSHリバーストンネル経由で zsystem.jp から呼び出せることを確認したため組み込む。
    経路は既存の OCR 基盤と同じ（zs → 127.0.0.1:11500 → ocr.php → Ollama）。
    構成の詳細は Dropbox/www/macmini/ollama-ocr.md を参照。
  対象: 現行フォーマット（大日本印刷）のヘッダ項目28種のみ。切断図は読み取らず人が入力する。
    寸法線と数値の対応付けが必要で難易度が高いため、当面は対象外とする（ユーザー合意済）。
  実装: ajax.php に mode=ocr を追加。カラム名をキーにしたJSONを返すようプロンプトで指定し、
    「読み取れない項目は空文字。推測で埋めない」を明示。結果は shearspec_field に
    ocr_value として記録し（verified=0）、shearspec.intake_type=1 を立てる。
    画面側は「AIで読み取り」ボタン。**空欄の項目にのみ反映**し入力済みの値は上書きしない。
    反映箇所は背景色（薄黄）で示し、原本と照合してもらう。プルダウンは候補一致時のみ反映。
  APIキー: /Users/zadmin/ollama-ocr-apikey.txt（web root外, 644）に配置。リポジトリには含めない。
  実測: p7（積水ホームテクノ 2026-06-19）で7項目すべて正答、37秒（qwen2.5vl:7b）。
  デプロイ（2026-07-31）: scp ellio/shearspec/{ajax.php,edit.php,shearspec.js}。

2026-07-31 ellio/shearspec: AI読み取り失敗時の原因表示と自動リトライを追加
  現象: 画面から「AIで読み取り」が2回とも「AI読み取りが失敗しました」で終わる。
    一方 curl（urlencoded/multipart どちらも）・同時2本実行では再現せず全件成功。
    ラッパーログでは該当時刻の接続が2秒で終了しており、推論に入る前に
    ラッパーまたは Ollama が即エラーを返したと判断（APIキー一致・画像サイズも上限内は確認済）。
  対応: 原因が画面から分からなかったのが問題なので、
    - ラッパー/Ollama の error・detail と HTTPコードをそのままメッセージに出す
    - HTTP 401/0/502 に応じた対処ヒントを添える（キー不一致/トンネル未確立/Ollama側エラー）
    - 一時的失敗（モデル読み込み中など）に備えて2秒間隔で最大2回試行する
  デプロイ（2026-07-31）: scp ellio/shearspec/{ajax.php,shearspec.js}。

2026-07-31 ellio/shearspec + macmini/ocr.php: AI読み取り失敗の原因＝コンテキスト長超過を修正
  原因: Ollama の既定 num_ctx=4096 に対し、画像トークン＋28項目のプロンプトが 4924 トークンとなり
    exceed_context_size_error（HTTP400）。ラッパー ocr.php が options を渡しておらず既定のままだった。
    ※私のcurl検証では通っていたが、これは画像の解像度差でトークン数が上限付近に揺れていたため。
  対応:
    - /Users/menou/ollama-ocr/ocr.php: options.num_ctx を送るよう変更。既定 8192（2048〜32768で
      呼び出し側から指定可）。ラッパー再起動（launchctl kickstart）で反映済み。
      ※このラッパーは ocrtest とも共用。既定引き上げは他用途にも有利で副作用は追加メモリのみ。
    - ellio/shearspec/ajax.php: num_ctx=8192 を明示送信。
    - Dropbox/www/macmini/ollama-ocr.md にAPI仕様とトラブルシュートを追記。
  デプロイ（2026-07-31）: scp ellio/shearspec/ajax.php（ocr.php は Mac mini ローカルのため転送不要）。

2026-07-31 ellio/shearspec: AI読み取りを非同期実行（バックグラウンド＋ポーリング）へ変更
  現象: 画面から実行すると fetch が "TypeError: Load failed"（Safari）で落ちる。
    サーバー側は Apache Timeout 300 / max_execution_time 0 で余裕があり、curl では成功するため、
    HTTPS前段で長時間の接続が切られていると判断（推論に20〜90秒かかる）。
  対応: 実処理をCLIへ分離し、ブラウザは短い通信の繰り返しで済ませる。
    - ocrlib.php を新設（プロンプト・JSON整形・Ollama呼び出し・保存を共通化）
    - ocrjob.php（CLI専用）を新設。exec() でバックグラウンド起動。
      zcommon.php はURLパスからDB判定するためCLIでは使えず、mysqli で直接 ellio に接続する。
    - ajax.php: mode=ocr を廃止し mode=ocrStart / mode=ocrStatus に分割。
      ジョブ状況は shearspec_field の予約行 field_name='__ocr_job__'（running/done:…/error:…）で受け渡す。
    - shearspec.js: 3秒間隔でポーリング（最大5分）。経過秒数を表示。
  デプロイ（2026-07-31）: scp ellio/shearspec/{ajax.php,shearspec.js,ocrlib.php,ocrjob.php}。

2026-07-31 ellio/shearspec: AI読み取りでシャーリングサイズが空になる問題を修正
  現象: 28項目のプロンプトだと shear_t/shear_w/shear_l が空で返る（大板サイズは取れる）。
  切り分け: シャーリングサイズだけを聞く単独プロンプトでは正しく読めた（0.45/1050.0/2252）。
    → モデルの能力ではなく、項目数が多いプロンプトでの欠落。大板とシャーリングは値が近く
      （p7: 0.45x1050x2290 と 0.45x1050.0x2252）、大板側を答えた時点で満たされたと解釈している疑い。
  対応: 項目の説明に位置の手がかりを追加。
    「『シャーリングサイズ』という別の見出しの枠にある3つの数値のうち◯番目」「大板サイズとは別の欄」
    「大板サイズの長より小さい」等。あわせて末尾に「別々の欄です。必ず両方とも読み取ってください」を追記。
  検証: p7(積水)/p8(日本フネン)/p3(三菱電機) の3枚で大板・シャーリング・取数の7項目すべて正答。
  デプロイ（2026-07-31）: scp ellio/shearspec/ocrlib.php。

2026-07-31 ellio/shearspec: AI読み取り後にユーザー・寸法欄が旧式の見た目に変わる不具合を修正
  現象: 「AIで読み取り」の結果を反映した瞬間、ユーザー欄と寸法欄の入力欄だけ
    ブラウザ標準（古いWindows風）の枠線になる。読み取り前は正常。
  原因: edit.php の入力欄22個に type 属性を書いておらず（class="num"/"mini" のみ）、
    CSS の input[type=text],input[type=number],... というセレクタが当たっていなかった。
    素の外観のまま表示されていたところへ JS が style.background を直接指定したため、
    ブラウザ標準の外観（-webkit-appearance）が外れて枠線だけの見た目に変わった。
  対応:
    - CSS: セレクタを input:not([type=checkbox]):not([type=radio]):not([type=file]) に変更し、
      type 未指定の入力欄も対象に含める。appearance:none を明示（select は menulist を維持）。
    - JS: style.background の直接指定をやめ、.ai-filled クラス付与に変更。
      クラス側で背景（薄黄）と枠色を定義し、他のスタイルは維持されるようにした。
  デプロイ（2026-07-31）: scp ellio/shearspec/{shearspec.css,shearspec.js}。

2026-07-31 ellio/shearspec: 画面表記を「指定コード」に統一、右上の保存ボタンを削除
  名称: 寸法指定書の原本上の欄名に合わせ、画面表示を「シャーCD」→「指定コード」に変更
    （edit.php のラベル、index.php の一覧見出しと検索欄の説明、帳票プレビューの項目名）。
    DBカラム名 shear_cd は変更しない。edit.php の入力欄右に
    「＝シャーCD（businessRawdata.shearID と同一体系）」の補足を1箇所だけ残した。
  保存ボタン: 左下カードに保存・削除があるためヘッダの保存ボタンを削除し一本化。
    原本スキャン取込時の自動保存は内部で saveAll() を呼ぶため影響なし。
  デプロイ（2026-07-31）: scp ellio/shearspec/{edit.php,index.php,shearspec.js}。

2026-07-31 ellio/shearspec: 基本情報から「伝票No」欄を削除
  調査: 伝票Noは原本に実在するが 2000年版（大日本エリオ）のみ。左上に緑刷りで「伝票№30034」と印字。
    2007年以降のDNPエリオ版・現行の大日本印刷版には欄そのものが無い（サンプル8枚で確認）。
    複写式伝票の通し番号（p6右下に「③加工業者控」）と見られ、寸法や製品の識別子ではない。
  対応: 新規登録では常に空欄になるため入力欄を削除。カラム slip_no は将来のために残す。
    ※ajax.php の strFields からも slip_no を外した。画面に欄が無いと送信されず、
      保存のたびに既存値（id16=30034）が空で上書きされてしまうため。
    帳票プレビューの伝票No表示、JS側の参照も削除。
  デプロイ（2026-07-31）: scp ellio/shearspec/{edit.php,ajax.php,shearspec.js}。

2026-07-31 ellio/shearspec: slip_no（伝票No）を完全に削除
  理由: 現行フォーマットに存在せず新規登録では常に空になる項目のため、カラムだけ残すと
    「これは何か・使ってよいのか」を後から判断できず迷いの元になる（ユーザー判断）。
  実施:
    1. 削除前に唯一の保有値を退避。id16（コクヨ2000年版）の source_note へ
       「／伝票No.30034（用紙左上の印字。2000年版のみの項目）」を追記。
       原本画像 images/16/p-1.png にも写っているため情報自体は失われない。
    2. ALTER TABLE shearspec DROP COLUMN slip_no（本番 ellio で実行済み・存在しないことを確認）
    3. schema.sql からカラム定義を削除、ajax.php の除外コメントも削除
    ※画面・JS側の参照は同日先行して削除済み。
  デプロイ（2026-07-31）: scp ellio/shearspec/{ajax.php,schema.sql}。

2026-07-31 ellio/shearspec: 帳票プレビュー上部の項目配置を原本に合わせる
  目的: 現場が原本と見比べたときに混乱しないよう、欄の並びを実物どおりにする。
  変更: 1段目を「工場 → ユーザーコード → 指定コード → ユーザー名 → 寸法公差 → 対角線公差
    → 柄方向指定 → 担当営業部 → 営業担当者名」の順に変更（従来は指定コードが左端だった）。
    ユーザーコードと指定コードは原本では隣接した1つの枠のため、.pair でくくって余白なしに。
    枠線が二重に見えないよう2つ目を margin-left:-1px で重ねている。
  デプロイ（2026-07-31）: scp ellio/shearspec/{shearspec.js,shearspec.css}。

2026-07-31 ellio/shearspec: 帳票のユーザーコード／指定コードが縦並びになる不具合を修正＋キャッシュ対策
  現象: 前回の配置変更後、帳票でユーザーコードと指定コードが縦に積まれた。
  原因: 2欄を <div class="pair"> でくくり横並びは CSS(.rep .pair{display:flex}) 側に任せていたため、
    ブラウザが古い shearspec.css を使っている状態では ただの div となり block 配置＝縦並びになった。
  対応:
    - JS 側で <div class="pair" style="display:flex"> とインライン指定し、CSSに依存しない形にした。
    - 再発防止として index.php / edit.php の CSS・JS 読み込みに ?v=20260731a を付与（キャッシュ無効化）。
      今後スタイルや挙動を変えたときはこのバージョン文字列も更新する。
  ペンディング事項（memory へ記録: project_shearspec_elio_standard_split）:
    エリオ規格とエリオ仕様が1つの文字列に合体してしまう。原本は枠が桁数で分かれているが、
    qwen2.5vl も Claude も切り分けできない（指定コード0005で確認）。当面ペンディング。
  デプロイ（2026-07-31）: scp ellio/shearspec/{shearspec.js,index.php,edit.php}。