DB（データベース）を使わずJSONで管理しているため、項目の定義表を唯一の正（スキーマ）とします。
項目を追加・変更するときは、必ずこの定義に従い・ここを更新します。
🔒 鉄則（ぜったいルール）
- 1項目 = 1つの意味。1つの表示ラベル = 1つの項目。
同じ表示ラベル（例「発生日時」）を別の項目に使わない。
- 項目を足す前に、コード内で同じ表示ラベルと同じ項目名を検索して、既存とぶつからないか必ず確認する。
- 自動でつく項目（IDや投稿日時など）と人が入力する項目を混同しない。
- 項目を変えたら、server.py 先頭の定義表とこの画面を必ず更新する（コードと説明をズレさせない）。
💬 概念・用語の共通認識
- 発生日時の既定値
- 新規作成時に現在日時が入っているのは入力支援（楽にするため）であって、固定値ではない。実際に発生した日時に自由に変更してよい。
- ソフトデリート（削除＝非表示化）
- タスク・議事録の「削除」は完全消去ではなく非表示化。更新ログ・記録を残すため、画面には出ないがデータには残る。タスクは タスク → 🗑 削除済みタスク から、議事録は「🗂 非表示も表示」から、いつでも元に戻せる。完全削除（物理削除）は今後この設定タブに用意する予定。
- 議事録の完全削除（2段階目）
- 誤って登録した議事録だけは、編集画面の最下部（折りたたみ）からパスワード付きで完全削除できる。本文ごと消えて戻せない。パスワードは admin_config.json で管理者が設定（未設定なら完全削除は無効）。議事録を消してもタスクは連動して消えない。
- 後勝ち（あとがち）
- 同じタスクを複数人が同時に編集して保存すると、最後に保存した内容で上書きされる（競合の警告は出ない）。同時編集は避ける。
- 空欄を許す項目
- 発生日時・期限は空でもよい。必ず必要なのはタスク内容だけ。
- 議事録番号「#1」
- タスク名の先頭の「#1」は議事録（番号1）との紐づけ印。議事録を削除しても番号は振り直さない（紐づけがズレないため）。
※ 新しい小さなルールや言葉の意味は、認識を揃えるためここに随時書き足していく。
📝 タスク（tasks.json）
| 項目名 | 意味 | 形式 | 入力者 | 画面の表示ラベル |
|---|
code | 管理番号（不変・重複なし） | A001 / B001 / G001… | 自動 | 管理番号 |
task | タスク内容 | 文字列 | 人 | タスク内容 |
detail | 詳細・補足 | 複数行文字列 | 人 | タスク詳細 / 詳細（補足・メモ） |
assignee | 担当者 | メンバー名（空=未定） | 人 | 担当者 |
area | 区分（空/無し=事務所、'倉庫'=倉庫） | '' / '倉庫' | 自動（kindから） | （非表示。表示先タブの振り分けに使用） |
occurred_at | 発生日時（＝作成日時） | 例 2026-06-11T13:05 | 人 | 発生日時（新規時は現在日時を既定表示） |
deadline | 期限 | 例 2026-09-01（空可） | 人 | 期限 |
progress | 進捗 | 0%〜100% | 人 | 進捗 |
id | 一意ID | 自動採番 | 自動 | （非表示） |
deleted / deleted_at | 削除フラグ・削除日時 | true / 日時 | 自動 | （非表示・記録保持のためのソフト削除） |
⚠️ タスクの日時は occurred_at に一本化しています（「発生日時＝作成日時」は同じ意味）。旧 created_at は廃止。新規作成時に未入力なら現在日時を自動で入れます。古いタスクは空欄の場合があります（一覧では「—」表示）。
🔖 管理番号(code)：先頭の文字で由来を表します。A=議事録からAI抽出 ／ B=議事録画面で手入力 ／ G=進捗・一覧から追加 ／ W=倉庫のスポットタスク。番号は由来ごとに 001 から連番。一度付いたら変わりません（タスクの状況が変わっても不変）。削除済みの番号も再利用しないので重複しません。倉庫タスク（area=倉庫）は事務所の進捗・一覧には出ず、倉庫タブだけに表示されます。
💬 リクエスト（requests.json）
| 項目名 | 意味 | 入力者 |
|---|
author | 投稿者 | 人 |
text | 本文 | 人 |
created_at | 投稿日時 | 自動 |
done | 対応済みフラグ | 人 |
※ リクエストの created_at（投稿日時）は、タスクの発生日時とは別物です。混同しないこと。
📅 議事録（meetings.json）
| 項目名 | 意味 |
|---|
seq | 議事録番号（連番・自動）。タスク先頭の「#1」と紐づく |
title / date / partner | 件名 / 日付 / 相手先 |
url / memo / body | URL / メモ / 原本本文 |
deleted / deleted_at | 非表示フラグ・非表示にした日時（ソフト削除。自動付与） |
🗑 議事録の削除は2段階。通常は「🚫 非表示」（ソフト削除＝復元可・seqも変わらない）。完全削除はパスワード必須で編集画面の奥からのみ（誤登録の取り消し専用・本文ごと消えて戻せない）。議事録を消してもタスクは連動して消えない（「#番号」で緩く紐づくだけの独立レコード）。
📝 フリースペース（freespace.json）
| 項目名 | 意味 | 形式 | 入力者 | 画面の表示ラベル |
|---|
title | タイトル（必須） | 文字列 | 人 | タイトル |
body | 本文（自由記述） | 複数行文字列 | 人 | 内容 |
author | 作成者 | メンバー名（空可） | 人 | 作成者 |
created_at | 作成日時（作成時に確定・以後不変） | 例 2026-07-27 13:40 | 自動 | 作成日 |
updated_at | 更新日時 | 例 2026-07-27 15:02 | 自動 | 更新（作成日と違うときだけ表示） |
deleted / deleted_at | 削除フラグ・削除日時 | true / 日時 | 自動 | （非表示・ソフト削除） |
📝 タスク → フリースペース。議事録にもタスクにもならない共有メモを、誰でも自由に書き留める場所です。新しいメモが上に並びます（並びの基準は created_at。編集しても順番は動きません）。必須はタイトルだけ。長い本文はカード内で折りたたまれ「▼ 全文を表示」で開きます。削除はソフト削除＝ページ内「🗑 削除済みを表示」から復元可。
⚠️ 本文の表示ラベルを「内容」にしているのは、リクエストの text（表示ラベル「本文」）とラベルを衝突させないためです（鉄則1）。
🏢 社外案件（anken.json）
| 項目名 | 意味 | 形式 | 入力者 | 画面の表示ラベル |
|---|
code | 案件番号（不変・重複なし） | C001 / C002… | 自動 | 案件番号 |
client | 受注元（必須） | 文字列 | 人 | 受注元 |
title | 受注内容（必須） | 文字列 | 人 | 受注内容 |
category | 案件種別（自由入力。過去の入力が候補に出る） | 例：別注／AI・DX | 人 | 案件種別 |
occurred_on | 発生日（受注した日・日付のみ） | 例 2026-07-31 | 人 | 発生日（新規時は今日を既定表示） |
deadline | 納期 | 例 2026-08-20（空=未定） | 人 | 納期 |
stage | ステージ（種別に依らず共通5段階） | 受注／仕様確定／進行中／納品準備／完了 | 人 | ステージ |
next | 次の一手 | 短文 | 人 | 次の一手 |
amount | 金額（任意） | 文字列 | 人 | 金額（編集画面のみ・一覧には出さない） |
memo | メモ | 複数行文字列 | 人 | メモ（編集画面のみ） |
updated_at | 更新日時（内容を編集するたび自動更新） | 例 2026-07-31 15:00 | 自動 | 最終更新（編集画面に表示） |
id / deleted / deleted_at | 一意ID・削除フラグ・削除日時 | 自動 | 自動 | （非表示・ソフト削除） |
🏢 タスク → 社外案件状況。社外から受注した案件（ぶんぶんチョッパー別注・AI/DX受託など）を、表＋納期タイムライン（発生日→納期の横棒・赤い縦線=今日）で見える化します。並びは納期が近い順（未定は最後）。完了・削除済みは既定で非表示（ページ内のチェックで表示）。行クリックで編集。バーの色：青=通常／黄=納期7日以内／橙=納期超過／緑=完了。
⚠️ ラベルの使い分け（鉄則1）：「案件種別」はリンクタブの「種別（kind）」と衝突させないための別ラベル。「発生日」（日付のみ）はタスクの「発生日時（occurred_at）」とは別項目。「納期」はタスクの「期限（deadline）」とはラベルを分けた別項目。「案件番号（C001…）」はネタ帳プレスの「案件ID（01…）」とは別物。「次の一手」はネタ帳プレスと同じ意味なので同じ言葉を使っています。
👥 メンバー一覧（担当者の値）
個人アカウント ／ 全員（全社共有）／ その他（外部）／ 未定（担当未決・空欄の正規化先）。※デモのため架空のアカウント名です
📦 倉庫業務（事務所タスクとは別系統）
事務所＝一回きりのタスク／倉庫＝毎日繰り返す定常業務、という性質の違いから別構造。記録第一：すべての操作に「誰が・何時に」が自動で付き、日次ログとして永久保存されます（事故・クレーム時に遡れる）。倉庫メンバーは事務所メンバーとは別リストです。
| ファイル | 中身 |
|---|
warehouse_members.json | 倉庫メンバー（name / leader=班長）。将来のシフト管理用に勤務条件を足せる構造 |
warehouse_routines.json | 定常業務テンプレート：toC工程（毎日）／toB工程（fba_only=FBA案件のみの工程）／随時作業ボタン。リーダーメニューで編集 |
warehouse_log.json | 日次記録（日付ごと）：toC＝工程チェック＋件数 ／ toB＝案件ごとの工程チェック ／ 随時作業＝やった記録（誰・何時・メモ） |
📐 業務の3分類：①毎日必ず回る流れ（toC）＝自動生成のチェックリスト ／ ②発生したら回す流れ（toB）＝「＋toB出荷」で案件ごと起票（1日複数件OK・宛先メモ・FBAなら個別ラベル工程が出る）／ ③随時の単発作業（検品・梱包準備・B品整理・在庫調整・棚卸）＝ボタンを押すだけで記録（メモ任意）。一回きりの仕事はスポットタスク（W番号）で起票。
⚠️ やらないこと：Accessとの連携（在庫調整・棚卸は「やった記録」だけ。Accessのデータには触れない）／在庫数の管理／販売チャネルAPI連携。工程名の変更をすると過去ログは旧名のまま残ります（歴史的事実として正しい）。
🗓 勤務表（warehouse_shifts.json）
🗓 勤務表 → シフト作成。毎月の条件を入れると、倉庫5人のシフト案を3つ作ります。案を選んで手直しし、確定してA4横で印刷します。生成は shift_engine.py（外部通信なし・AIは使わない）。データは月をキーにした辞書で、月ごとに独立しています。仕様の正本は docs/SPEC-shift.md。
| キー | 意味 | 形式 | 入力者 | 表示ラベル |
|---|
conditions | 勤務条件（メンバー条件／全体ルール／重み） | {members,rules,weights} | ユーザー | 勤務条件 |
holidays_extra | 追加の休業日（お盆・年末年始） | ['YYYY-MM-DD'] | ユーザー | 全員の休業日 |
holidays_off | 祝日だが出勤する日 | ['YYYY-MM-DD'] | ユーザー | 祝日の打ち消し |
office_days | 事務所勤務（紙のグレーの帯） | {氏名:[日付]} | ユーザー | 事務所勤務 |
day_off | 休み希望（販売グループもここ） | {氏名:[日付]} | ユーザー | 休み希望 |
early_leave | 早退希望。その時刻が終業になる | {氏名:[{date,time}]} | ユーザー | 早退希望 |
busy | 繁忙期（4日週の同時人数の上限を外す） | [{from,to,label}] | ユーザー | 繁忙期 |
drafts | シフト案3つ（得点・注記・内容・集計） | [{id,label,score,notes,diff,assign,summary}] | 自動 | 案A／案B／案C |
confirmed | 確定シフト（手直し後の内容） | {assign, at} | 自動 | 確定済み |
🔤 assign の値（assign['YYYY-MM-DD'][氏名]）：off＝休み ／ office＝事務所勤務 ／ 15・16・17＝その時刻まで勤務（始業は各人の条件）。早退希望の日は分単位が入ります（例 14:30）。土日祝・休業日はキーごと持ちません。
🎨 休みの2種類：どちらも off で、day_off に載っているかどうかで区別しています。画面では 休み希望による休み＝濃い色＋太字、シフトの都合の休み＝薄いグレー。CSVでは 休(希望) と 休。早退希望の日は終業時刻を表示して破線の下線を引きます。早退希望を出した日は出勤日として固定され（休むなら休み希望に書く）、16時より前に帰るので15〜16時のカバー要員から自動で外れ、実働時間も短く数えます。同じ日を休み希望と早退希望の両方に指定するとエラーになります。
👤 1人ぶんの条件（conditions.members[]）：氏名／区分／始業／終業（複数可＝生成時にどれかを選ぶ）／休憩(分)／勤務日数のきまり（交互・範囲・原則すべて・固定）／週上限(時間)／月上限(時間)／月上限(日数)／A／B／自動。上限はすべて「未満」で判定し、空欄＝制限なし。A＝この印どうしが同じ日に2人以上休まないようにする人。B＝この印の人だけで15〜16時をカバーする日を避けたい人。自動のチェックを外すと自動生成せず、休み希望だけ反映します（販売グループ）。
🔒 必ず守ること（破る案は作りません）：休み希望／週の勤務日数（交互4-3など）／週の実働上限（20時間未満）／月の上限日数／毎営業日に倉庫が2人以上／毎営業日に15〜16時のカバーが1人以上（事務所勤務の日は倉庫にいない扱い）／「4日の週」は同時2人まで（繁忙期の週は外す）。
🎚 なるべく守ること（減点）：区分Aの人が同じ日に2人以上休む／同じ日の16時終業が3名超／月曜と5・10のつく日が薄い／勤務日の偏り／16時終業の人による偏り／区分Bの人だけが15〜16時をカバーしている日。3案の違いはこの重みの振り分けから生まれます（条件モーダルのスライダーで調整可）。
⚠️ 保証しないこと：労働基準法・社会保険（106万／130万の壁）の適合判断はしません。「週20時間未満」等は入力された数値を守るだけです。給与計算・実績（遅刻/早退/欠勤）の記録もしません（実績は印刷した紙に手書き）。手直しでルールを破ったセルは色で知らせますが、保存は止めません（班長の判断が優先）。祝日は自動判定（振替休日・国民の休日を含む）、お盆と年末年始だけ手入力します。
📦 在庫（inventory.json）
📦 倉庫 → 在庫。倉庫の Access 在庫管理から、1日1回13時に指定した25品の在庫数を吸い出して並べるだけのページです。閲覧専用＝この画面から在庫数は変えられませんし、Accessには一切書き込みません。
| キー | 意味 | 形式 | 入力者 | 表示ラベル |
|---|
generated_at | mdbから取得した日時 | 'YYYY-MM-DD HH:MM:SS' | 自動 | 在庫データ：◯◯ 時点 |
source | 取得元（出どころの記録） | 文字列 | 自動 | （非表示） |
count | 件数 | 整数 | 自動 | （非表示） |
items[].id | 商品ID（不変。名前は変わりうる） | 数字12桁の文字列 | 自動 | 商品ID |
items[].name | 商品名（毎回mdbから取り直す） | 文字列 | 自動 | 商品名 |
items[].qty | 在庫数＝スタート在庫＋入庫−出庫 | 整数／null | 自動 | 在庫数 |
items[].found | mdbで見つかったか | bool | 自動 | ※Accessで見つかりません |
🧾 表示ルール：並び順は inventory/watch_items.json に書いた順（在庫数順にも名前順にもしません）。マイナス在庫は赤字でそのまま出します（0に丸めない＝棚卸しのズレを隠さないため）。25件しかないので一覧に検索欄は作っていません。
➕ 商品の増やし方（2026-08-05追加）：画面の「＋ 表示する商品」から、商品名の一部を打って候補から選ぶだけです（12桁の商品IDを転記する必要はありません）。検索が読むのは inventory/products.json＝毎日の取得のついでに書き出した全商品カタログ（38,266件・約4MB）なので、何回検索してもAccessには届きません。追加すると一覧の末尾に付き、在庫数は次の取得まで ―＋「※次の取得で入ります」になります（すぐ見たいときは「🔄 今すぐ取得」＝約7秒）。並べ替えだけは watch_items.json を直接編集します。
🚧 混同しないこと：「ダッシュボードは書き込まない」という鉄則の対象は Access(mdb) であって、watch_items.json ではありません。あれはこちら側の設定ファイルなので画面から書き換えて構いません。守る一線は「mdbに書かない」の1つだけです。
🚨 鮮度の警告：取得日が今日でなければ、右上の「在庫データ：◯◯ 時点」を赤にして失敗を明示します。バッチが死んでいるのに古い在庫数が平然と出続けるのが、この構成で唯一の実害あるバグです。取得に失敗しても inventory.json は書き換えません（前回の値がそのまま残る）。
⚠️ 保証しないこと：リアルタイムではありません（13時以降の入出庫は反映されないので、発注・受注の最終判断はAccessの最新値で）。在庫数の正しさそのもの（実棚と合っているか）も保証しません。引当・予約・入荷予定は考慮しません。複数チャネル（Amazon/楽天/Shopify）の在庫連携は対象外です。
🔧 取得のしくみ：PowerShell のバッチが mdb をローカルにコピーしてからコピーの方を読みます＝元ファイルへの書き込みが物理的に起こりません。実行は毎日1回の定期タスク。取得に失敗した日は前回の値を残したまま、画面の鮮度表示を赤にして知らせます。
🗒️ その他
home.json | 🏠ホーム：連絡事項（notices: 日付自動・追加/削除）／いつも意識すること（reminders: 1行1項目）／リンク集（links: 名前|URL）。「今日のようす」は保存せず既存データからその場で集計 |
notes.json | 進捗カード下部のメンバー別メモ |
neta.json | 投稿ネタ帳（手入力）。チャネル別（インスタ/X/TikTok/プレスリリース/note）にタイトル・メモ・状態（案/作成中/投稿済）を貯める。削除はソフト削除＝「💡 ネタ→🗑 削除済みネタ」から復元可（物理削除は今はしない。いずれ設定タブに用意）。「💡 ネタ」タブ→左ナビで表示。
プレスリリースのみ追加項目（2026-07-09）：case_id（案件ID・2桁ゼロ埋め。値がある＝採用済み、空＝在庫）／stage（制作状態。※statusの表示ラベル「状態」と衝突しないよう「制作状態」）／next（次の一手）。pressページだけ2カラム表示＝左：ネタ在庫（新しいほど下・採用ネタは緑バッジ「採用 #NN」で残す）／右：制作パイプライン表（case_id昇順） |
knowledge_storage.json | 社内データの保存場所メモ（手入力・全員が追加）。データ名／保存場所（パス・URL）／種別（NAS・ローカルPC・クラウド・共有サーバー・その他）／メモ／登録者／更新日。削除はソフト削除＝ページ内「🗑 削除済みを表示」から復元可。「🔗 リンク」タブ→左ナビ「保存場所」で表示（左ナビは今後のリンクページを足せる器）。※2026-08-05に表示名を「📚 知識」→「🔗 リンク」に改称。内部id（know_storage）とファイル名（knowledge_storage.json）は据え置き |
tv_ingredients.json | サブフォルダ tv-shokuzai/ が書き出すTV食材データ（NHK番組表→Claude抽出）。こちらは読み取り専用 |
tv_watchlist.json | 民放の巡回リスト（番組名＋Xアカウント）。TV食材→民放 の「✏ 巡回リスト」から編集。fetch_x.py が実行のたびに読む |
tv_minpo.json | 民放の放送予定（番組公式Xの予告投稿→Claude抽出）。run_minpo_update.py が書き出す。読み取り専用。番組表サイトのスクレイピングはしない（規約違反のため） |
tv_history.json | 放送履歴の蓄積（NHK・民放の更新時に自動追記・消えない）。source(nhk/minpo)で「NHK過去」「民放過去」ページに振り分け表示。初期データはスプシ履歴から取り込み済み |