本期間の前半（8/8〜8/16）は厚木事業所がお盆休みで稼働がなく、本番データが動かない作業（調査・設計・検証）が中心。稼働再開は 8/17（月）で、出荷予定・配車・投入実績の3系統すべてで一致している。コミットは zsystem.jp 28件＋tokyo-express.net 1件。8/21 時点で本番未反映のものは、運転日報の「作業開始1分丸め」1件（別作業と競合のため保留）。
commit a00db05（コミットは8/7、デプロイは8/11）
RG-S10-G2 の形式で持たせた。varchar(32)・最大4工程・同一機種の重複は不可。commit 7a2fa4a 現場からの不具合報告に対応。取込時に区分が欠落する経路を補完した。
commit 06d80ee 中板（成り品）が未生成の受注も候補に出し、先に組み込めるようにした。
commit 9991e83 コード6本＋schema系3本を scp、DB移行 alter_shearMachine_chain.sql 投入済み。
C RG S0 S8 S10 G0 G3 G2 R4。うちタブを持つ実機は7種（C・RG・S8・S10・G3・G2・R4）。R4＝4尺。S0／G0 は実機ではなく「S機だが機種未定」「G機だが機種未定」の総称コード。タブは持たせず、S8/S10 の候補に S0、G3/G2 の候補に G0 を混ぜる。別名展開は S8→S8,S0 ／ S10→S10,S0 ／ G3→G3,G0 ／ G2→G2,G0。COALESCE(NULLIF(FIND_IN_SET…))）と PHP（chainPos()）で探索順を必ず揃えること。ずれると候補の工程と組込の工程が食い違う。S は S0 の意味として変換。旧 4尺 は実データ0件のため R4 に置換。shearCompilerRoughInfo.machineNAME（〜2025-03-31）。2022年以降も動いているのは RG/S0/C/S10/G3/G2/S8、停止済みは R4(〜2019-10)/G0(〜2019-05)/G1(〜2017-10)。G1 はマスタから除外。旧システムの processNO は最大2で、3工程以上は今回の拡張が初。compilerParamList.machine に G3-G0 RG-G0 があり、ハイフン連鎖は旧システム由来の記法と判明した。C-C は保存拒否。validMachine() に S0 が無く、該当シートが開けない・該当行が候補から黙って消える。実際に数十分その状態になった。なお ellio/scheduler/index.php も同じ列を読む（shearRank() がチェーンをそのままラベルにするため4工程だと長くなる）。data-machine は書くだけで誰も読まないので動作影響なし。
commit 58a541a 第3セグメントが印刷NOではないと確定したことによる修正（詳細は3章）。
横軸＝日時／縦軸＝機種（L1 L2 C RG G0 G2 G3 S0 S8 S10）のSVGガント。NOTES.md が「最終目的」と書いているシャーリングスケジューラの2024年版プロトタイプにあたる。
commit f0a2994 ローカルには存在せず /Users/zadmin/Sites/ellio/scheduler/ が真実源だった。rsync で取得し、手を入れる前の状態をコミットして基準にした。
commit ae117f5 / 6387660 17:34 デプロイ。4ファイル名指しの scp（全ツリー rsync は無関係な未コミット変更を巻き込むため使わない）。送信前にサーバー側 md5 がベースラインと4/4一致することを確認し、送信後も md5 4/4一致・chmod 644・index.php.spellbak と resources/ の無傷を確認した。
index.php：実体の無い switch case 8件・受付担当者読み込み・空関数 cal()／main.html：onload='Init()'・施設利用申込書フォーム・カレンダー画面・常に空だった受注No.欄／main.js：editField() registReserveForm() 等／style.css：#facilityApplicationForm ほか。dispForm() はページを開くたび SELECT * FROM workshift を投げていたが ellio.workshift は存在しない。本番 PHP 5.x では警告止まりだが PHP 8 では 500（mysqli_sql_exception）になる。ローカル PHP 8.4 で削除前=500／削除後=200 を実測した。commit e4c880e 候補38件を出荷日順に表示し、能力超過の12件を赤表示。ドラッグでの割付は無効（未実装）。
| テーブル | 用途 | 最終データ |
|---|---|---|
TimeLineIndex | 予定セル（readTimeline） | 2025-03-31（17,326行） |
shearingLogDetail | シャーリング実績（getActualData） | 2025-04-01（C=7,993行／RG=5,262行） |
tasklog の LINEPROC1/2 | 印刷ライン投入実績（getActualLine） | 稼働中（2026-08-07まで） |
＝今日の日付で開くと印刷ラインのレーンしか描画されない。さらに TimeLineIndex に書き込む口はアプリ内に存在しない（書き込み役だったはずの registreserve/updatereserve は実体の無い switch case で、上記で削除した）。この画面を復活させるのか shearplan 側へ寄せるのかは判断待ち。
残件：実績バークリックで dispActualInput 未定義で落ちる／検索タブ不動作／割付登録未実装。
2026-08-11 に本番DBで実測。scheduler の出荷予定トレイ設計のための調査。
出荷指示番号 (受注NO-行NO-印刷NO 8桁-2桁-2桁) は誤り。shippingschedule の第3セグメントは businessRawdata の印刷NOと別体系である。commit c34d7c7 でコメントを訂正した。38097034-01 は businessRawdata に -01 の1行だけ（指示枚数720／AI列 8/3(360)、8/17(360)、）だが、shippingschedule は -01〜-06 の6行・各120枚（最後だけ119）。8/3 に3行=360枚、8/17 に3行=359枚でAI列の分納内訳と枚数が一致。＝1回の印刷720枚を出荷側が120枚ずつ6明細に割っている。38095414-02 は印刷2本（各600枚）に対し出荷側は5明細（200/200/204/400/206）。created_at 順に 01→05 と採番される。dispatch）の話である。58a541a で受注NO-行NOに修正済み。created_at は新しい (orderno, dispatch_date) の INSERT 時のみ設定され、以後の同期は updated_at しか触らないため「その出荷日を初めて把握した日」として使える。dispatch に7便あるのに shippingschedule には0行。過去の記録ではなく「先行きの作業セット」として扱う必要がある。shippingschedule 出荷日 8/6→8/17、dispatch 配車便 8/7→8/17、tasklog LINEPROC 投入 8/7 が最後。3系統で一致するため取込漏れではない。出荷日は月〜金のみ。納期日＝出荷日+1 が 607/717（85%）。commit d1ad53e ellio/printschedule/printschedule.js を scp（md5一致・644確認）。
背景：㈱DNPエリオ 生産管理部から連絡指示書 No.26-001（2026-08-18発行）。進行予定表に「通板数」「コメント」「納入日」が追加され、鋼板についてのみ自動表示される（アルミ・ステン・クレリオは対象外）。実施日は 2026-08-24 以降の発行分から、完全反映には1週間ほどのズレがあり、しばらく新旧が混在する。
現状調査（改修前）
businessRawdata.feedingqty。ソース内に「通板」という語は1件も無く、呼称が違うだけ。storeLine() は指示数(index0)・取数(index1) しか読んでおらず、通板数を読む行は存在しない。＝現状 feedingqty は 100% 手入力（入力経路は一覧の情報入力ポップアップ writeInfo と編集フォーム writeFullInfo の2つだけ）。feedingqty の用途：printschedule/index.php:397 と scheduler/index.php:327 で「0でなければ指示枚数の代わりに使う」＝重量計算の基準、printsequenced/index.php:679 で通し残数の初期値（パック引当の基準）。numberofplates←通板数／packagetypeinternal←鋼板／packagetype←納入日／divisioncode←保護P となり全滅する（テストで再現確認済み）。方針（ユーザー承認済み）：現行 storeLine()（V1）は1行も触らず温存し、新様式用 storeLineV2() を併設。貼付テキスト全体に「通板」があるかで様式を自動判定して振り分けるため、利用者の操作は不要。通板数は feedingqty へ自動取込するが、空欄行では送信自体をしないので既存の手入力値を潰さない。コメント・納入日・保護P は格納先未定のため当面DBには書かず、位置ズレ防止のためパースだけ行いログに出す。
実装の要点：storeLineV2() の読み方を「n番目固定」から「素材KBで前後分割＋注文サイズを右端アンカーに右から確定」へ変更した。理由は (1) コメントは自由文でスペースを含み得るため位置固定では原理的に読めない、(2) 鋼板のみ通板数が付く＝同一ファイル内でも行ごとに列数が変わる、の2点。前半のトークン数 3個＝通板数あり／2個＝なし で吸収し、後半は 区分(K/O) → 梱包C → 納入日(m/d) → 保護P の順に右から確定する。
検証：実物の新様式PDFが未着のため、連絡指示書の添付サンプル9行から合成データを作り、ローカルに node のテストハーネスを作って確認（サーバー・DBには一切触れていない）。V1×旧様式＝従来どおり／V2×新様式(鋼板)＝通板数を正しく取得／V2×アルミ(通板数なし)＝feedingqty未送信／V2×コメント入り(スペース含む)＝OK／V2×梱包Cなし＝OK／V2×旧様式＝正しく読める。
未決事項：コメント・納入日の格納先（businessRawdata へのカラム追加は保留方針が継続中）。保護P は filmtype 列が既存だが ellio/film/ の需要側連携と絡むため別途判断。
commit 50273f6 shearspec.js と edit.php（JSキャッシュ対策で ?v=20260807j→?v=20260819a）を scp。
指示：丁数が増えると図の中の寸法記入が小さくなるため、原本と同じく図の中は記号（W／L／D）だけにし、実際の値は図の右の凡例へ出したい。
buildSVG を直接動かして確認（DOMはスタブ）。id=13 実データ相当（221×466 を24丁 / 4×6）→記号表記に切替、凡例に 221/466/(515.7)。6丁（700×400・大板2110×810）→セルに余裕があるため従来どおり数値表記。commit 3876230 → b8fb650 → 2aaa071 → 56ce9d1（4段階で調整）
本番との md5 照合により、上記4件が本番反映済みであることを確認済み（8/21 時点）。
commit 8cde954
なぜ：carrierMaster は 1車番＝1ドライバー固定だが、実運用では同じ車に別の人が乗る。マスタの氏名がそのまま実績に記録されていた。
実データが示したこと（調査）
carrierMaster は当面触らない方針とした。実装
listDrivers(company, car_no)：carrierMaster ∪ dispatch実績。並びは「この車番の実績 → 乗務回数 → 直近日」。listCompanies() も同様（利用回数 → 直近日 → 登録台数）。createArrival はサーバー側が driver_name 空のときだけマスタで補完する実装のため、選んだ氏名を送れば勝つ（サーバー変更不要）。compositionstart/compositionend + e.isComposing）。出すと「もり」のまま登録される。踏んだ不具合：車番を打ち直してマスタ未登録に落ちる経路に初期化が無く、前の車の会社・ドライバーが残っていた。lookupCarrierAndRender の miss 分岐に setCompanyName('')、applyCarrier に clearManualFields() を追加して解消。
commit ec1ea92（事務所側 dispatchmng）
commit 8ae8d78 / cc3a5a4
editCompany / editDriver をボタン＋hidden input 化。保存経路（saveTripEdit → updateTripInfo）は不変。_pickTarget（'arrival'|'tripedit'）で出し分け。ピッカーが他ダイアログの背面に隠れる問題を z-index で修正。pack / tasklog / packlog / packlogindex / personlog / ABCpack。packlogindex の罠：writeDB は毎回 logid 712272〜712275（2024-09-05 feederinspector 由来・packno空のゴミ packlog 4行）への参照行も一緒に張る。各384件の被参照があり共有なので packlog 側は絶対に消さない。新規packを消すとき logid レンジだけで packlogindex を削ると孤児4行が残るため、indexid または createtimestamp で当日分を特定して消した。~/Documents/zsystem_backup/20260808_film_rollback/*.sql（mysqldump --where・--default-character-set=latin1 --skip-set-charset で生バイト保存）。scratchpad は揮発するので使わない。flag5='良品在庫' ではないため StockQty に影響せず、再計算不要。子行を消すと packno は nextPacknoInRange で再利用される（歯抜けなし＝仕様どおり）。commit ece22f2 / b11261f / 784ca8c（＋1eddd5f は 2026-06-08 分の取りこぼしコミット）
salesmansrecords.memo varchar(255)。TEXT は不採用（絵文字不可・列幅を広げない方針）。.memo-view に幅を注入する方式。メモ本文の太字をやめ、メモ行の上罫線を2pxの区切り線にした。commit bcbbd2f / 029a5cf 営業マン選択時のみだったダウンロードボタンを、全体・店舗の画面にも出した。
発端：宮原康さん・2026年7月23日の回収（「手すり／メルシー／回収／23日」ダイアログ）でバディーⅠ本体が −0 と表示される。
結論：Zシステムのバグではなく、TZ4 の元データが0。
ROUND(z_withdrawal_details.subtotal_price / 10)。同じダイアログの「たちあっぷ CKA-13」は TZ4 で 3300 → 画面 330 と正しく出ており、計算式も同期も正常。同期は letip/tz2shippings.php（cron 10分毎）が TZ4 の値をそのまま写すだけ。biz_action_details（z_* は輸出用コピーで id 共通）も 0。id 4253965 (munit 8700) / 4253974 (munit 7698) とも unit_price=0, price_without_tax=0, subtotal_price=0。＝「Zに渡されていない正しい金額が隠れている」のではない。tax_percentage も判別に使え、バディー本体は 10（課税品＝金額が付く前提）なのに金額0。本当に無償の付属品（専用I型ストッパー）は 0 で区別できる。範囲（2026-04以降。z_deliveries は 2026-04-15 以降しかない点に注意）：金額0の回収明細は292行。うち「同商品コードが他で金額を持つ」116行を証拠の強さで分類すると、強3行（同じ人・同じ個体で納品時に金額あり）／中52行／弱61行。
判断待ち：表示側で補うか。 z_product_types.unit_point（単位数マスタ）はZにも来ており z_munits.org_product_type_id から引ける（id 590 バディーⅠ ノーマルタイプ＝330）。金額0の292行のうち83行が unit_point>0 で埋まる（25,460単位）。ただし置き換えには使えない：マスタに単位数があるのは 9,684商品中1,699のみで、金額ありの818行で subtotal/10 == unit_point が一致するのは265行だけ、524行はマスタ側が0。「金額0のときだけマスタで補う」フォールバックなら成立するが、TZ4・請求と数字が乖離する。未実装・ユーザー判断待ち。
別件：納品側クエリは dd.result_cd = 1 で絞るが、回収側は result_cd も direction_cd も絞っていない。実データは 回収=1/0 が1090行・0/1 が20行、納品=1/1 が1299行・1/0 が403行と極性が逆に見える。列コメント未設定で意味を確定できず、20行の扱いは要確認。
再現・調査の道具一式は ~/Downloads/tz4回収金額0_調査20260814/ に README 同梱で保存（letip_query.php／tz4_query.php＝TZ4はIP制限のため zsystem.jp 上で実行／一覧CSV生成）。
照合順序の作業（11章）からインデックス要否の検討として派生した調査。
letip/new.php:859（コメント「リザーブ情報があれば適用 2005.7.24」）が packno をキーに1行 SELECT し、受注番号・商品コード・所有者コード・使用区分を pack 作成直後に流し込む仕組み。最古データ 2005-07-23 とコメント日付が一致。読み込み箇所は全6箇所、JOIN は1つも無くすべて WHERE packno='...' の単一行検索。旧版は引き当て後に DELETE していたが new.php では削除が消えており、2005年から53,573行溜まり続けている。INSERT INTO packreserve / UPDATE packreserve がサーバー上のどこにも無い（Webルート全体・共通PHP・cron 7ジョブ・トリガー・ストアド・全サイトの new.php 等を確認）。しかし 2026-08-10 13:02 まで書かれている。log_bin=ON）。実文は insert packreserve(...) と INTO を省いた書き方で、Web側のPHPは一貫して insert into のため書き手が別系統であることの決め手になった。この綴りの違いのせいで grep "into packreserve" では永遠に見つからない。packreserve と ActualTable が秒単位で一致（13:02:25）し、commandlog には 13:02 の記録が無い＝Web操作ではない。書き手は現場クライアント機の Xojo アプリが zsystem.jp:3306 へ直接接続して入荷実績を登録し、同時に packreserve へ1行予約している。GetArrivalCode() は countertable の帯先頭値＋カウンタを足すだけで zgrouplist.endno（帯の終端）を見ておらず、上限チェックも折り返しも無い。実際 2026年分の packno は 90,295〜90,556 で、帯 46000〜49899（幅3,900）を4万番以上オーバーし、zgrouplist に 90000〜94999 の定義は無い。＝2026年発行分は全件が未定義帯で引き当て発火ゼロ。idx_packno のみ追加した。副産物として「書き込み元不明ならバイナリログを見る」を手順化した（mysqlbinlog --start-datetime=… /var/mysql/mysql-bin.0003NN。zadmin は admin グループなので sudo 不要。1GB/日で9世代程度、秒単位で絞れば十分速い。接続元ホストは記録されない）。
commit c97ab16
EXPLAIN で type=ALL / key=NULL なら真っ先にこれを疑う。businessRawdata.orderno だけ utf8_general_ci、結合相手（tasklog shippingschedule timeLineIndex shearingLogDetail 等）は全部 utf8_bin。ellio/scheduler の getActualLine が 6.6秒 → 0.64秒（約11倍）になった。utf8_general_ci が bin より寛容なのは ASCII英字の大小文字だけで、全角/半角・ひらがな/カタカナ・末尾空白はどちらも同じ扱い＝日本語データでは実質差がない。bin のデメリットは「英字を含む検索が厳密になる」「ORDER BY がコードポイント順になる」の2点だけ。a.col = b.col 形式を全抽出 → 346件・ユニーク83件 → JS由来を除くと実際の結合キー列名26種 → information_schema と突合）。結果、ellio の結合キーは全て utf8_bin（または数値）に揃った。残った非-bin 列32個は 0行テーブル11個・ソース参照0のログ表・LIKE検索のみの列で、いずれも実害なし。possible_keys にすら出ない：pack.packno = packlogindex.packno（36,181,751行 / 2.2GB）が type=ALL, possible_keys=NULL。実害の代表は letip/raw/index.php:484 の履歴検索が3,618万行フルスキャン。対応時期の相談が必要。実機は Mac mini Mid 2010 / メモリ4GB / 2コア / Mac OS X Server 10.6.8。調査時点で連続稼働141日。
/var/log/secure.log に1行も残らない（Timeout before authentication は0件）＝ sshd が起動しきる前に死んでいる。CPU負荷 0.26・ディスク26% で、メモリ以外は余裕がある。/private/var/vm/swapfile0〜7（計4.2GB）が全て「今」のタイムスタンプで現在進行形。ssh.plist が inetdCompatibility 方式で接続のたびに launchd が sshd を新規 fork する。Apache と MySQL は常駐済みなので影響を受けない。この非対称が症状の説明になる。mdutil -a -i off → mdutil -E / → launchctl unload -w …mds.plist。overrides.plist に Disabled=true が入り再起動後も無効。効果は mds/mdworker 4→0、空きメモリ 10〜34MB → 71〜76MB、スワップ55MB解放。サービス影響なし。ただし SSHタイムアウトが直ったかは未確認（計測窓で元の失敗が再現しなかった）。sshd_config の Kerberos/GSSAPI を no に（毎ログインで失敗ログが出ている）／コンソールに Navicat 110MB と Activity Monitor が起動しっぱなし／cron の */10 が tz2shippings.php と z_munits.php を同時起動（空きページが2,778まで落ちる瞬間あり）＝数分ずらす／再起動／メモリ8GB増設（Mid 2010 の上限）。★調査で SSH を連打すると失敗するため、リトライは「MARKER_OK を grep して成否判定」する形で書くこと（2>&1 するとエラー文字列が出力に混ざり、単純な非空判定だと1回目で誤って抜ける）。
commit 16657a3 対象は drive/index.php のみ。
背景：当初は最終拠点の出発（帰庫登録）で業務終了＝アプリ終了だったが、有料道路の入力忘れが多発したため帰庫後もアプリを終了せず退勤ボタンを押せるようにした。しかし運転日報には帰庫後の作業を表す行がなく、その時間が「待機」に落ちていた。
調査（詳細は ~/Downloads/運転日報_退勤時刻調査_20260819.txt）
writeEnd は最終拠点の departureTime にサーバー時刻を書く＝帰庫登録操作の時刻。truckCourseSlips に時刻列がないため、DBだけでは両者を区別できないのが本質的制約。report.js:640-663）。仕様：退勤時刻＝最後の業務入力時刻。帰庫登録の後に有料道路・給油・備考が入力されたら「帰庫後作業」行を1本作る（到着時刻＝帰庫登録時刻で固定／出発時刻＝最後の入力時刻で上書き更新）。recalc() は sitename=='休憩' 以外を作業時間に加算するので集計側の改修は不要。
実装：calcWorkTime()／touchPostArrivalWork()／setCourseEndTime() を追加し、writeTollway/writeSlip/writeMemo/writePhotoMemo から呼ぶ。writeLogout は endTime を上書きしない。帰庫登録前の入力では何もしない。
検証：本番テーブルは読むだけにし、複製した zztest_* に対してテスト。実ファイルから関数を抽出しテーブル名だけ差し替えるハーネスを作成し、PHP側23件PASS／JS側47件PASS／FAIL 0。実データ4便で 拘束＝運転+作業+休憩+待機 の恒等式が成立し、運転時間・休憩時間は不変であることを確認（2171 拘束08:03→07:42・待機00:21→00:00 ほか）。
デプロイ：本番の drive/index.php・drivesheet.js・drivesheet.html を md5 照合した結果、5/28 のコース変更機能は既にデプロイ済みで git だけが遅れている状態だった＝本番に入る差分は今回の変更のみ。走行中の便を避けて 2026-08-20 06:00 に実行予約し、06:03 完了（事前md5確認 → 転送 → 照合 → 本番 php -l OK）。スクリプトは md5照合・退避・失敗時の自動切り戻し付き。
truckCourse id=2171 の endTime/totalTime を 15:57/08:03 → 15:36/07:42 に更新してしまった。2026-08-20 ユーザー判断により復旧せずそのままとした（結果的に今回の新仕様で出る値と同一のため実務上の不整合はない）。ハーネスには置換漏れ（FROM/UPDATE/INTO/JOIN ＋ 本番テーブル名）を検出する安全弁を追加済み。デプロイスクリプトで踏んだ点2件：(1) zsh は bash と違いクォートしない変数を単語分割しないため ssh $SSHOPT が全体で1引数になり publickey 認証に失敗する（配列＋"${SSHOPT[@]}" に修正）。(2) tokyo-express.net への ssh が時々 No route to host で瞬断するため、接続失敗（255）とリモートコマンドの失敗を区別してリトライする rssh()/rscp() を追加（接続不能では切り戻さない）。
要望：到着をタップしてから作業開始をタップするまでに分を跨ぐと、作業開始が到着の1分後になる。この1分は作業時間にも運転時間にも入らず待機の端数として残る。差が1分なら作業開始を到着時刻に合わせてほしい（報告例：2026-08-17 Z4 栃木夜便 2174 ⑥小山 到着02:16／作業開始02:17 → 待機00:01）。
原因：report/index.php の作業時間＝出発 −（作業開始があればそれ、なければ到着）、運転時間＝次の到着 − 前の出発。つまり「到着〜作業開始」の区間はどちらにも属さず、拘束時間の残差＝待機に落ちる。以前「原因未調査」としていた待機1分の端数はこれだった。
実装：snapWorkStartTime($arrivalTime,$workStartTime) を追加（差がちょうど1分なら到着時刻を返す。0時跨ぎは mod 1440。未着・空・逆順は何もしない）。writeDeparture() の書き込み前に丸める（作業開始はクライアントの localStorage に保持され、出発タップ時に初めてサーバーへ届くため）。
検証：境界値12件（差0/1/2分・23分・0時跨ぎ・逆順・未着・空・不正時刻）全PASS。report.js の recalc を実ファイルから抽出し 2174 の本番実データで比較：変更前 拘束09:17／運転05:57／作業02:23／休憩00:56／待機00:01（画面と完全一致）→ 変更後 作業02:24／待機00:00。運転・休憩・拘束は不変。
影響範囲：2026-04-01 以降の 到着→作業開始 の差の分布は 0分3,152件／1分20件／2分3件／3分2件／4分1件／5分8件。丸め対象は1分の20件のみ。既存データへの遡及適用はしていない。
drive/ と report/ をリファクタ中。drive/postwork.php が新設され HHMM2V/calcWorkTime/courseID2name/帰庫後作業の処理が移動、drive/index.php と report/index.php の双方から require_once されている。本番の drive/ に postwork.php は存在しないため、drive/index.php を単独でデプロイすると fatal error になり運転日報の登録画面が全面停止する。今回の変更だけを切り出してコミットすることもできない。→ ユーザー判断待ち。前提の発見：管理用CSVの「差異」は truckCourse に保存済みの集計値から計算しており（totalTime − totalDriveTime − totalWorkTime − totalRestTime）、レコードから再計算していない。つまり workStartTime を直すだけでは画面は1行も変わらず、集計値 totalWorkTime も併せて更新する必要がある。
zzfix0821_snap（対象15レコード）／zzfix0821_course（対象13コースの集計値）を作成。truckCourseRecords.workStartTime = arrivalTime に更新（15件）。対象は 2026-08 かつ orderNo>0 かつ MOD((workStart-arrival)/60+1440,1440)=1。truckCourse.totalWorkTime を丸めた件数×1分だけ加算（13コース）。~/Downloads/運転日報_時間異常_作業開始1分丸め_比較_20260821.pdf（A4横4ページ）。切り戻しは退避テーブルから復元可能。| 件 | 状態 |
|---|---|
| 運転日報「作業開始1分丸め」のデプロイ | 実装・検証済み。別セッションのリファクタ（drive/postwork.php 新設）と競合しており単独デプロイ不可。切り出し方をご判断いただきたい |
| TZ4 回収の単位数0 を表示側で補うか | マスタ unit_point で83行は埋まるが、TZ4・請求と数字が乖離する。未実装 |
| letip の照合順序（結合キー約105列・4種混在） | 未着手。3,618万行の履歴検索が全表走査。対応時期の相談が必要 |
| printschedule の「コメント」「納入日」の格納先 | businessRawdata へのカラム追加は保留方針が継続中。保護P は filmtype 列と film 側連携の絡みで別途判断 |
| scheduler（2024年版プロトタイプ）の扱い | 予定データが2025年で停止し書き込み口も無い。復活させるか shearplan に寄せるか |
truckCourse id=2171 の endTime/totalTime をテスト事故で書き換えた（8/20）。ユーザー判断により復旧せず。新仕様で出る値と同一。dispActualInput 未定義で落ちる／検索タブ不動作／割付登録未実装。drive/index.php・report.js の対象関数を実ファイルから切り出し、テーブル名だけ zztest_* に差し替えて実行する。★置換漏れ検出の安全弁（FROM/UPDATE/INTO/JOIN ＋ 本番テーブル名の走査）を必ず入れること（今回それが無く本番1行を書き換えた）。getActualLine が30秒タイムアウトするため、本番の応答を保存し、レンダリング済みHTMLの main.js 読み込み直後に getDataCallback をフィクスチャ返却へ差し替える。--headless=new --virtual-time-budget=25000 --dump-dom で DOM を吸い出し描画数を数える。buildSVG（DOMはスタブ）。サーバー・DBに触れずに済む。chmod 644 と巻き添えファイルの無傷を確認。全ツリー rsync は無関係な未コミット変更を巻き込むため使わない。mysqlbinlog --start-datetime=… --stop-datetime=… /var/mysql/mysql-bin.0003NN。grep で表名を探す前にこちらを見る（INSERT INTO を前提に grep しない／Web の PHP に無い＝書き手がWeb層とは限らない）。zzfix* に退避し、集計値は算術で更新、そのうえで画面側の再計算結果と一致することを確認する。zsystem.jp（28件）
| # | 日時 | ハッシュ | 件名 |
|---|---|---|---|
| 1 | 08-10 17:46 | 1eddd5f | salesreport: 地図エリアと罫線の作り直し（2026-06-08 分の取りこぼし） |
| 2 | 08-10 17:46 | ece22f2 | salesreport: 営業マン用の「メモ」行を追加（1日単位・自由文） |
| 3 | 08-10 17:56 | b11261f | salesreport: メモ本文の太字をやめる |
| 4 | 08-10 23:10 | 784ca8c | salesreport: メモ行の上の罫線を 2px の区切り線にする |
| 5 | 08-11 16:51 | f0a2994 | ellio/scheduler: サーバー現物をそのまま取り込み（ベースライン） |
| 6 | 08-11 17:19 | ae117f5 | ellio/scheduler: コート予約システムから流用した残骸を削除 |
| 7 | 08-11 17:24 | 6387660 | ellio/scheduler: changeMode() に未配線であることの注意書き |
| 8 | 08-11 23:35 | 58a541a | shearplan: 出荷予定の突合を受注NO-行NOに直す |
| 9 | 08-12 00:35 | c34d7c7 | dispatchmng: 出荷側 orderno 第3セグメントの誤った列コメントを訂正 |
| 10 | 08-12 17:36 | bcbbd2f | salesreport: 営業マン選択時に CSV ダウンロードボタンを出す |
| 11 | 08-12 17:50 | 029a5cf | salesreport: CSV ダウンロードを全体・店舗の画面でも使えるように |
| 12 | 08-12 21:27 | c97ab16 | ellio: orderno 系5列を utf8_general_ci → utf8_bin に統一 |
| 13 | 08-13 02:33 | e4c880e | ellio/scheduler: 出荷予定トレイを実装（表示のみ） |
| 14 | 08-13 02:38 | 927b409 | shearplan: NOTES.md 第9章（完了・持ち越し・多工程・出荷予定の突合） |
| 15 | 08-16 18:49 | 8cde954 | ellio/dispatch: 入荷受付のドライバー・運送会社を候補選択に変更 |
| 16 | 08-17 03:06 | ec1ea92 | ellio/dispatchmng: 配車情報を「会社→車番→ドライバー」の順に |
| 17 | 08-17 22:49 | 8ae8d78 | ellio/dispatch: 打刻中の再編集ダイアログも候補選択に |
| 18 | 08-17 23:18 | cc3a5a4 | ellio/dispatch: 会社・ドライバーのピッカーを他ダイアログより前面に |
| 19 | 08-18 23:31 | 7a2fa4a | shearplan: 工程会議資料取込で区分(K/O)を補う（現場報告の不具合） |
| 20 | 08-19 15:17 | d1ad53e | ellio/printschedule: 新様式対応パーサーを併設 |
| 21 | 08-19 15:18 | 875fd0b | worklog: printschedule 新様式対応の記録 |
| 22 | 08-19 15:32 | 50273f6 | ellio/shearspec: 多丁取りの切断図を記号表記（W／L／D＋凡例）に |
| 23 | 08-20 02:26 | 06d80ee | shearplan: 成り品がまだ無いものも候補に出し、組込を可能にする |
| 24 | 08-20 16:31 | 3876230 | ellio/shearspec: 対角線を枠の右下へずらし、補助線で元の角と結ぶ |
| 25 | 08-20 16:35 | b8fb650 | ellio/shearspec: 対角線のずらす向きを法線にして補助線を直角に |
| 26 | 08-20 16:41 | 2aaa071 | ellio/shearspec: ずらし量を対角線長に対する割合にする |
| 27 | 08-20 17:00 | 56ce9d1 | ellio/shearspec: ずらし量に「小さい方の成分」の下限を入れる |
| 28 | 08-21 22:37 | 9991e83 | shearplan: 優先度を単一機種から工程チェーンへ（最大4工程） |
tokyo-express.net（1件）
| # | 日時 | ハッシュ | 件名 |
|---|---|---|---|
| 1 | 08-20 06:04 | 16657a3 | drive/: 帰庫後の入力を「帰庫後作業」行として記録し、退勤時刻を最後の業務入力時刻に |
コミットを伴わない作業：ellio/film のテスト入荷ロールバック（8/8・DB作業）／出荷予定データの調査（8/11）／packreserve の調査と idx_packno 追加（8/13）／TZ4 回収単位数0の調査（8/14）／zsystem サーバーのメモリ調査と mds 停止（8/14）／運転日報 8月実績のデータ修正（8/21）。