handoff · supply-order

消耗品の補充発注ライン — 現在地と、これから

2026-08-11 ／出先セッションが作った PR #87 を家側で検証したところまで。残りは大竹さんの2アクションだけで Ready→マージに進める状態。

現在地

NOW

「発注のあと」だけが自動化されていて、「何をどれだけ買うか」は手作業だった

既存ライン: 注文履歴CSV → order-import-amazon → 発注台帳GSheet → Slack通知

発注後（台帳記帳・通知）は既に仕組み化済み。手前の「口述メモ → 施設の定番品を思い出す → カゴに入れる」が毎回人の記憶頼りだった
PR #87 がその手前を埋めた。設計の要は「定番品マスタを人が手入力しない」 — 過去の発注履歴そのものを定番品マスタとして使うので、商品の切替・廃番は次の発注で自動追従する
辞書 SoT/operations/supply_ordering.md の表をスクリプトが直接パースする。表を直せば即反映（コード側に写さない）
あわせて AI社員 Stuart（Steward＝蔵と物資と帳簿を預かる人）を新設し、発注系スキル4本を Frank から移管。境界は「減るか、据え置かれるか」
ただし PR #87 はドラフトのまま＝main に未着地。家側 Claude は draft PR を勝手に ready/merge しない運用

↓

直近やったこと

JUST NOW

web-inbox でキュー2件を処理し、PR #87 の Windows 実害2件を直して push した

2026-08-11 ／ BLADE_STLTH_TMK ／家側検証セッション

済思考ログ（PR #83）は処理済みへ。フック配線・showThinkingSummaries: true・thinking 記録あり・cp932 化けなし・memory 正本とミラー一致を実測。DELL 側の登録スクリプトだけ未実施
済cart.py が Windows(cp932) で起動しなかったのを修正 — 出力の絵文字で UnicodeEncodeError。main() 内だけ stdout を UTF-8 化（モジュールトップでやると import 側の二重ラップ事故になるため）
済build_catalog.py の生成物が毎回汚れるのを修正 — generated_from が Windows で data\order_history\... になり Linux 生成物と差分。as_posix() 固定。修正後は再生成しても diff ゼロを実測
済上記2件を 82137f25 として PR ブランチへ push（main には入れていない）
済cp932 selftest（agent_name_inject.py --selftest 全7名OK・Stuart 1,314字/44%）、カタログ再生成（施設10 / 品目89 / ASIN156）を家側で実働確認
待カート投入URLの実挙動は未検証。家側 Claude からのアクセスが買い物カゴ操作として権限で弾かれた（出先セッションでは Amazon に到達できず、という理由で未検証だった。理由は違うが結果は同じ）
済main の _inbox/WEB_QUEUE.md に検証状況を残した（6cc9e13e）。学び1件を memory feedback_worktree_push_blocked_by_merged_handoff に追記

↓

次の一歩

① カート投入URLを1回開く（Amazon Business ログイン済みブラウザ）。カゴに入るか／発注が押されないかだけ見る。
https://www.amazon.co.jp/gp/aws/cart/add.html?ASIN.1=B09YV12L66&Quantity.1=1
（南房総のハンドソープ詰替 ×1。効かなければ Chrome MCP 相乗りでのカゴ投入へ切替＝skills/supply-order/SKILL.md §罠に代替手順あり）
② ティッシュケース ×2 の銘柄決定（南房総に実績なし）。tower B07DX5VZGD ¥2,300 ／ RIN蓋付き B00F9PIMOM ¥2,966（どちらも逗子葉山＝Atelier の採用品）。Claude 側の推奨は tower（蓋なしで軽く Harbor の設え寄り）。決めて南房総で1回発注すれば、辞書を直さなくても次回から定番として引ける
③ PR #87 を GitHub 上で Ready → Squash merge（家側 Claude は draft PR を強行しない。session_close_merge_guard と auto classifier の両方に止められる実績あり）
④ マージ後に git pull → /web-inbox でキューの supply-order エントリを処理済みへ。WEB_QUEUE.md は merge 時に conflict する見込み（main 側でキューを整理済みのため）。conflict は「待機中の1件をブランチ側から拾い、処理済み欄は main 側を採る」で解ける
⑤ DELL 側で1回: python scripts/hooks/ensure_userpromptsubmit_hooks_registered.py（settings.json はマシン固有で git 同期されないため BLADE の結果が伝播しない）
⑥ 実運用の初回は「南房総に口述で頼む → 出た URL を開く → 発注 → 翌月 order-import-amazon でCSVを落として build_catalog.py」まで一周させると、カタログが自己更新する設計が効いているか確認できる

↓

遠い未来

FAR

「減るもの」を人が覚えていなくても切れない状態へ

口述 → カゴ → 発注 → CSV → 台帳 → Slack が1本の線になる。人が押すのは「発注」の1回だけ（金銭・不可逆なのでそこは人に残す）
Stuart が「減るもの」全体の担当として育つ。発注前（何を買うか）・発注後（いくらだったか）の両側を持つので、施設別の消耗品原価が自然に見えるようになる
次の段は頻度の学習 — 履歴に「前回いつ何個」が全部あるので、「南房総のハンドソープはそろそろ」を先に言える。在庫を見ずに切らさない、が最終形
Collection ごとのグレード（SoT/brand/amenity_grades.md）を守ったまま自動化する。間違えるより止まるを実装で担保しているのがこのラインの品質の核

引き継ぎ情報

ファイル・URL・コマンド

種別	パス / URL	用途
PR	github.com/tmkcln/Claude_tmk/pull/87	本体。ドラフト。Ready→Squash merge は大竹さん
ブランチ	`claude/facility-supply-ordering-7xxgqc`（tip `82137f25`）	出先3コミット＋家側の Windows 修正1コミット
SoT	`SoT/operations/supply_ordering.md`	施設辞書・品目辞書・解決の優先順位。先に読む。表を直せば即反映
SoT	`SoT/operations/amazon_order_routing.md`	配送先の正本。施設辞書の「Amazon配送先名」列と一致させる
SoT	`SoT/brand/amenity_grades.md`	実績が無い品を新規選定する時のグレード規定
AI社員	`SoT/agents/stuart.md` / `SoT/agents/roster.yaml`	Stuart のカード。発注系スキル4本を Frank から移管済み
スキル	`skills/supply-order/SKILL.md`	実行フロー・判断の癖・罠（カート投入が効かない時の代替を含む）
スクリプト	`scripts/supply_order/cart.py`	口述 → カート投入URL。`--json` で機械可読
スクリプト	`scripts/supply_order/build_catalog.py`	履歴CSV → 定番品カタログ生成。生成物は手で編集しない
生成物	`data/supply_catalog/catalog.json`	施設10 / 品目89 / ASIN156（1〜7月のCSVから生成）
コマンド	`python scripts/supply_order/cart.py --text "南房総ハンドソープシャンプー"`	口述をそのまま渡す。改行でも一行でも通る。語尾の数字が数量
コマンド	`python scripts/supply_order/build_catalog.py`	新しいCSVを落とした後に回す
コマンド	`python scripts/hooks/ensure_userpromptsubmit_hooks_registered.py`	DELL 側で1回（thinking-recall の残作業）
キュー	`_inbox/WEB_QUEUE.md`	main 側に検証状況を記載済み。マージ後 `/web-inbox` で閉じる
カルテ	claude.ai/code/artifact/29f32bfe…	出先セッションが作った判断用カルテ（一過性）

残課題・既知の論点

カート投入URLの実挙動が唯一の未検証点。gp/aws/cart/add.html は Amazon の標準形式だが、Amazon Business アカウント側の挙動は実機でしか分からない。ここが通らないと「カゴまで1手」が成立しない
WEB_QUEUE.md はマージ時に conflict する見込み。main 側でキュー整理を進めたため。rebase で先回りして潰すのは禁じ手 — pre-push の handoff-guard が main 側の memory/feedback*.md を検出してブロックし、force push も権限で弾かれて二重に詰む（2026-08-11 実測。memory feedback_worktree_push_blocked_by_merged_handoff）
カタログは1〜7月分のCSVからしか作られていない。8月以降の発注は未反映
軽井沢の Forest Retreat 軽井沢（母屋）と ＶX軽井沢1（Core）は同一住所で CSV上は判別できない（辞書に注記あり）
数量は口述どおりで在庫を見ていない。「足りているか」は現地の目でしか分からない、という前提のまま
他施設の実績は候補提示のみでカゴに入れない実装。Collection ごとにアメニティのグレードが違うため（Signature の品を Harbor に流すとブランド設計が静かに壊れる）

減るものを、誰も覚えていなくても切らさない。人が押すのは最後の「発注」の1回だけにする。