⚙️ Vault運用

2026-08-14_作業ログ

最終更新 2026年08月17日／ 90_Meta/Claude作業ログ/2026-08-14_作業ログ.md

00:53 - /handoff 実行（全テーマ）

このセッションで扱ったテーマ（全部・すべて HP CRM = ~/dev/hp-crm / 本番 https://hp-crm-64l.pages.dev/ ）

HP CRM 作業ログ/時間編集の刷新 — システム作業 — ver39〜49で本番反映済み
HP CRM 収益モデル（デモ/コンペ¥5,500・入金予定）— システム作業 — ver46/56
HP CRM 作業ページ統計＋カレンダー — システム作業 — ver47
HP CRM フォント（游ゴシック→最終 Zen Kaku Gothic New）— システム作業 — ver48→ver55
★URL引っ越し発覚＋デプロイ基盤修正 — システム作業/重要 — 旧hp-crm.pages.dev→新hp-crm-64l.pages.dev（SCALEアカウント・D1同期）。deploy.sh/dev.shのnodeパスとアカウントID修正
HP CRM 目標ページ用語平易化＋受注数（制作のみ）— システム作業 — ver52/53
HP CRM タスクページ全面刷新 — システム作業 — ver53（締切グルーピング/次の締切/検索/完了ドロワー/双方向）→ver54（カテゴリ化+Enter廃止）→ver57（クリック編集）
HP CRM コンペ運用（提出・受注/失注ボタン・失注のみ¥5,500）— システム作業 — ver54/55
HP CRM 案件管理を制作案件のみに — システム作業 — ver55
★データ消失＋同期修正 — システム作業/重要 — 作業ログが端末間同期で消える問題。まるごと上書き→ID単位マージ(mergeSync)に。48分ログ復旧・3時間ログは復元元なし
HP CRM 入金予定ページ新設 — システム作業 — ver56（5案の①最重要）

テーマ別の詳細（正本は git + リポ直下CLAUDE.md。現在 ver57）

現在地: ローカル・origin・本番すべて ver57。全機能実機検証済み。
URL変更（最重要）: 本番は https://hp-crm-64l.pages.dev/ （株式会社SCALEアカウント 9c601cdb…）。旧 hp-crm.pages.dev は別アカウント(c4e34068…)で D1 作れず引っ越し済み＝legacy-redirect。デプロイは bash ~/dev/hp-crm/deploy.sh（SCALEアカウント明示・dist/のみ公開・creoトークン付けない）。node は /Applications/ChatGPT.app/Contents/Resources/cua_node/bin（Codex.app→ChatGPT.app改名）。
データ同期: 5キー(works/todos/tasks/goalplan/worklogs)を Cloudflare D1 で端末間同期。同期は functions/api/data.js の PUT を ID単位マージ(mergeSync)に修正済み＝別端末が古い一覧で保存しても作った記録が消えない。トレードオフ=削除は伝播しにくい。
収益モデル（確定版）: 案件制作=初期費用×取り分(フロー)＋月額×取り分(ストック)。デモ制作=常に¥5,500。コンペ=受注/失注ボタンで判定し「失注のときだけ¥5,500」。すべて月末締・翌月末払いで入金予定ページに反映。
除外ルール: 制作一覧KPI/一覧=コンペ除外。案件管理=制作案件のみ。目標の受注数=制作のみ。収益=コンペは失注のみ。

このセッション全体の大串FB（重要）

コンペは受注確定でない→制作一覧/収益/受注数に入れない。受注したら自分で案件制作に登録。失注時だけ¥5,500。
タスクは案件名でなくカテゴリ(案件/コンペ/デモ/その他)。Enterで追加しない(ボタンのみ)。クリックで編集。
フォントは最終的に Zen Kaku Gothic New。
同期でデータ消失は絶対NG→マージ方式に。

保留（5案の残り）

②目標に「今のペースでの着地見込み」を追加（進捗率・残り件数・受注数は接続済）
③案件の停滞検知（最終更新から14日動いてない案件を炙り出す）
④ホーム（ログイン直後1画面・今日の締切/超過/未入金/停滞を各3行）
⑤コンペ勝率・投下時間（作業タブと連携・1コンペ平均時間/勝率/受注1件あたり投下時間）

01:10 - HP CRM 目標ページ「今のペースでの着地見込み」（保留5案の②）

実装（ver58→60・本番 https://hp-crm-64l.pages.dev/ で実機確認済み）

ver58: 目標ページの「現在地」直下に 今のペースでの着地見込み セクションを新設。
稼働開始月を activeMonths から逆算（2026＝稼働5ヶ月＝8月開始／通年の年は1月）→ 今日までの経過稼働月数を日割りで算出
今のペース＝今年の受注数（制作のみ）÷ 経過月 → ×稼働月数＝年末の着地見込み件数
併記: 見込みの年間収益（自分）／目標達成に必要なペース（残り月数であと何件）／達成率バー／判定バッジ
ガード: 稼働7日未満は判定せず必要ペースのみ表示／稼働1ヶ月未満は「ブレます」注記
gRevenueFor(y,units) は既存 gYearRevenue と同じ式で件数だけ差し替え＝既存関数は無改修（退化防止）
ver59: 実機で「稼働14日・受注1件 → 148%＝達成ペース」と誇大に出たため、稼働1ヶ月未満は判定バッジを 「参考値（稼働1ヶ月未満）」 に落とす補正。
ver60: サイドバー左下のver表示が ver57のまま止まっていた（手書きのため更新漏れ）。→ boot() で先頭の HPCRM-VER コメントから自動取得する方式に変更＝今後はマーカーを更新するだけで画面のverも追従。

実機の実測値（2026-08-14 01:10時点）

今のペース月2.2件／年末の着地見込み 11.1件（目標7.5件・148%）／見込み年間収益（自分）¥304,464（目標 ¥206,250）／必要ペース月1.4件／判定「参考値（稼働1ヶ月未満）」。2027・2028ページには出ないことも確認（当年のみ表示）。

学び（technical tip）

画面に出すver番号を手書きすると必ず更新漏れる → 正本（先頭のVERマーカー）から実行時に読ませる。コメントノードは document.documentElement.innerHTML には入らない（<html> の外にあるため）ので、document.firstChild から兄弟をたどって nodeType===8 を拾う。
Cloudflare Pages は デプロイ直後30秒ほど旧HTMLがエッジキャッシュに残る。?cb=乱数 を付けて数回ポーリングして ver 一致を確認してから「反映済み」と言う。
インラインJSしかない単一HTMLでも、<script> を抜き出して node --check にかければデプロイ前に構文エラーを機械検出できる。

保留（5案の残り）

③案件の停滞検知（最終更新から14日）／④ホーム（今日の締切/超過/未入金/停滞を各3行）／⑤コンペ勝率・投下時間

01:35 - HP CRM 保留5案の残り3つ（③停滞検知・④ホーム・⑤コンペ勝率）

実装（ver61→62・本番 https://hp-crm-64l.pages.dev/ で実機確認済み）

③停滞検知: 案件に updated スタンプを追加（wTouch() を 工程トグル／案件詳細の保存／受注・失注ボタンの3経路で押す）。既存データにはスタンプが無いため wLastActive() が受注日→作成日にフォールバック。未完了かつ14日以上動いていない案件を stalledWorks() で抽出→制作一覧に「停滞」ブロック（クリックで案件詳細）。
④ホーム新設（view-home・ログイン直後の初期表示に変更）: 「今日の締切／超過／未入金／停滞」を各3行＋「他N件」＋遷移リンク。締切はタスク（未完了）＋案件（納期あり・完了前）を統合。滞留判定は agingWorks() に切り出して入金予定ページと共用（二重実装を避けた）。
⑤コンペ勝率・投下時間: 作業ログの各行に案件ひも付けselectを追加（種別ごとoptgroup／削除済み案件を指していたら自動で外す）。コンペ制作ページに勝率／件数内訳（受注・失注・未確定）／投下時間合計／1コンペ平均／受注1件あたりを表示。
ver62: セレクトの位置が作業時間の桁数でズレたので作業時間に min-width ＋右寄せ。

実機確認（2026-08-14 01:35時点）

ホーム＝今日の締切0件／超過1件（株式会社ack工業・3日超過）／未入金0件／停滞1件（株式会社ロードマップ・55日・最終更新6/19）。コンペ統計＝1件・未確定1・勝率「—」。作業ログ1件をコンペに一時紐付け→投下時間19分・1コンペ平均19分と正しく集計されることを確認し、紐付けは元に戻した（残り0件）。

注意点（次に触る人へ）

停滞の「最終更新」は、まだ一度も触っていない既存案件では受注日が使われる（updated が無いため）。一度でも工程トグル／保存／受注失注を押せば実態に合う。
コンペの投下時間は作業ログ側で案件を選んで初めて集計される（過去の記録は未紐付け）。

保留5案 → 全部完了（①入金予定 ver56／②着地見込み ver58-59／③停滞 ver61／④ホーム ver61／⑤コンペ勝率 ver61）

01:58 - HP CRM 収益/入金の用語と整合（ver63）＋停滞基準の説明

①収益ページから英語用語を全廃（大串FB「MRRという用語を使わない。フロー・ストックもなし。日本語で書く」）

MRR→毎月続く月額／フロー（初期）→初期費用（1回きり）／ストック（月額）→月額（毎月続く）／継続件数→続いている件数／MRR明細→毎月続く月額の明細。案件管理ページのMRRカード・案件モーダルの「課金開始日・MRR起点」→「月額が始まる月」も同時に日本語化。※画面表示のMRRはゼロ（残るのはコード内のコメントと関数名だけ）。

②収益ページと入金予定ページの「今月の入金」が合わない件 → 原因は数字ではなく見せ方

計算はどちらも monthRevenue(前月) で元から一致（実測どちらも ¥22,000）。ズレて見えたのは、収益ページが「その月の売上（¥7,500）」を大きく出していたのに対し、入金予定ページは「その月に入る額（¥22,000＝前月の売上分）」を出していたため。
対応: 収益ページの入金セクションの主役を「その月に入るお金」に変更し、売上は右側に「入るのは9/30」と添える形に。→ 両ページで同じ数字が主役になった。
入金明細を全ての月に追加: monthRevenueRows() を新設して売上を案件1行ずつ（初期費用／月額／デモ制作／コンペ（失注））に分解し、合計は必ずこの行を足して作る方式に変更＝画面ごとに集計がズレない構造にした。入金予定ページは8ヶ月すべてに内訳、収益ページも入金セクションに内訳を表示。

③停滞の判定基準（大串の質問「ロードマップはちゃんと動いてるのに、どこを見て停滞？」）への回答

見ているのは案件の最終更新スタンプ(updated)だけ。ver61で入れたばかりなので既存案件にはまだ無く、その場合 wLastActive() が受注日（ロードマップ＝6/19）にフォールバックする。だから「55日停滞」と出た。
作業ログ・タスク・入金の動きは一切見ていない（作業ログは案件ひも付けが任意のため）。
スタンプが押されるのは 工程チェックのトグル／案件詳細の保存／受注・失注ボタン の3つだけ。ロードマップは工程が動いていないので押されていない。
→ 改善案を提示済み（A: スタンプが無い案件は停滞判定しない／B: 作業ログの最終作業日も最終更新に含める／C: 日数を変える）。大串の選択待ち。

学び

同じ概念に2つの数字（売上と入金）があるとき、ページごとに主役が違うと「バグに見える」。計算が合っていても見せ方で不一致に見えるので、主役の数字を全ページで揃える。
合計と明細は明細を先に作って合計はそれを足す（別々に計算しない）。ズレの再発を構造で防げる。

02:35 - HP CRM 収益ページ合体・サイドバー整理（ver64〜67）

ver64 サイドバーの並び＋フォント

並びを ホーム／管理／制作／ツール／目標 に変更（目標を最下部）。フォントを Noto Sans JP に変更 → ver67で Zen Kaku Gothic New に戻した（大串FB「フォント元に戻して」）。

ver65 売上と入金を名前で区別

大串「今月の入金は22000じゃないの？」＝01が「今月／自分の収益」という名前で売上¥7,500を大きく出していたのが誤読の原因。→「今月の売上（お金が入るのは翌月末）」「今月入るお金（入るのは先月の売上分）」に改名。金額計算は変更なし。

ver66 収益管理＋入金予定を「収益」1ページに合体（大串の相談→合体で合意・名前は「収益」）

合体理由: 同じ数字（今月入るお金¥22,000）を2ページが別々に持っていた／月ナビも二重／売上と入金は並べて見ないと意味がわからない。
上部に「入金／売上」切り替えタブ（初期＝入金）。
入金: ①今月入るお金＋内訳 ②これから入るお金（前1〜後6ヶ月・各月に明細）③滞留
売上: ①今月の売上 ②月次推移 ③毎月続く月額の明細
旧cashflowページは撤去し、中身を cfMonthListHtml() / cfAgingHtml() に切り出して移設。ホームの未入金リンク先も revenue に変更。

学び

同じ数字を2ページが持つと必ず「合わない」と言われる。数字が正しくても、ページごとに主役が違えばバグに見える。→ 1ページに寄せてタブで切り替えるのが正解だった。
大串は相談を投げてくることがある（「合体させたほうがいいかな」）。このときは理由つきの推奨＋構成案を出して意思決定してもらう形が通る。

02:55 - HP CRM アイコン設定と名前変更（ver68〜69）

favicon を新規設定（それまで未設定＝Chromeのデフォルト表示だった）＋サイドバーのアバターを文字「大」から同じ画像に差し替え。画像は大串がInstagram（hyoga｜インクたらし屋さん）から保存したカビゴンのイラスト（736×736 JPEG・~/Downloads）。dist/ には index.html しか置かない方針のため、data URIで埋め込み（favicon 64px／apple-touch-icon／アバター 96px）。
サイドバーの名前を「大串勇輝」→「SAKI」に変更。
ver表示を boot() 内 → 読み込み直後に移動（ログイン画面では静的テキストの古いverが出ていた）。

学び（落とし穴・重要）

sips -Z 64 in.jpg --out out.png は拡張子を変えるだけで中身はJPEGのまま。data:image/png;base64, に載せると宣言と中身が食い違う（先頭が iVBOR でなく /9j/ なら JPEG）。sips -s format png を必ず付ける。ver68で踏んでver69で修正。
チャットに貼られた画像はファイルとして取り出せない。実ファイルが要るときは保存場所を聞く（今回は ~/Downloads に保存済みだった）。
Cloudflare Pages はデプロイ直後、ブラウザ側キャッシュが数分残る。?クエリ を変えても同じタブだと古いHTMLが出ることがある。新しいタブで開き直すのが確実。

03:05 - HP CRM 収益モデル修正（ver70・収益モデルの確定版が変わった）

デモ制作／コンペ（失注）の¥5,500を「案件全体の収益」に入れない（大串FB「自分だけの収益だから」）。クライアントへの請求ではなく自分がもらうフィーなので、案件全体（グロス）には計上しない。

実装: monthRevenueRows() で gross:0 / self:5,500 にし selfOnly:true を付与。明細の右下は「案件全体 ¥0」ではなく 「自分だけの収益」 と表示。
影響（実測）: 8月の案件全体の売上 ¥15,500 → ¥10,000／2026年間累計（案件全体）¥165,500 → ¥160,000。自分の売上 ¥7,500 は変わらず。

収益モデル（最新・ver70時点）

案件制作 = 初期費用×取り分＋月額×取り分（案件全体にも計上）
デモ制作 = 常に¥5,500・自分だけ（案件全体には入れない）
コンペ = 失注のときだけ¥5,500・自分だけ（受注は案件制作に登録して収益化）

03:15 - HP CRM アイコンを「ME」に変更・丸く切り抜き（ver71）

元画像 ~/Desktop/_.jpeg（375×375・黒の「ME」ロゴ）を中央正方形で切り出し → PILで円形アルファマスクをかけ、favicon 64px／apple-touch-icon 180px／サイドバーのアバター 96px を data URI で埋め込み。サイドバーのアバターは border-radius:50% にして真円表示。ver68〜70のカビゴンから差し替え。

学び（画像加工まわり・このMacの環境）

PIL（Pillow 11.3.0）が使える。ImageMagick（magick/convert）は無い。丸切り抜き・アルファ合成はPILでやる。
円形マスクは 目的サイズの4倍で描いてから縮小するとギザギザが出ない（ImageDraw.ellipse はアンチエイリアスしないため）。
検証は目視だけでなく 四隅と中心のalpha値を見る（四隅0・中心255なら正しく丸い）。
ユーザーの「デスクトップにある」は ls ~/Desktop で出ないことがある（表示は出ていてもFinder経由等）。mdfind -onlyin ~ 'kMDItemContentTypeTree == "public.image" && kMDItemFSContentChangeDate >= $time.now(-10800)' で最近の画像を拾うと早い。

03:40 - HP CRM 月額は「公開した月」から発生（ver72〜73）＋アイコン仕上げ

収益モデルの変更（大串FB「月額はサイトを公開してから発生するもの」）

工程「公開設定」チェック（またはステータスが公開設定以降）で 公開日 publishedAt を自動記録。月額はその月から計上＝入金はその翌月末。今月の売上欄には公開月の分が入る。
初期費用は従来どおり課金開始日の月に1回きり（billingStart は「初期費用の計上月」に位置づけ変更）。
未公開なら月額は立たない（ver72ではフォールバックを残していて「未公開でも月額が立つ」穴があり、ver73で修正）。
既存案件は起動時に1回だけ補完（created/orderDate が 2026-08-14 より前かつ月額ありのみ → 公開日＝課金開始日）。ロードマップは金額そのまま（実機で今月入る¥22,000／今月の売上¥7,500／月額明細 2026.07〜が変化なしと確認）。
⚠️ 公開日を消すのは工程「公開設定」を外した時だけにした（通常の保存で消えると月額が丸ごと飛ぶため）。

アイコン

ME を 1.2倍に拡大した円に（1.35倍は文字が切れるので不採用）。サイドバー左上とログイン画面のロゴも「HP」からMEの丸に統一。

学び

ロジックの検証は実データを触らずNodeで。index.html から対象関数だけ正規表現で抜き出して node で走らせると、パターン別の結果表が一瞬で作れて安全（今回これで「未公開でも月額が立つ」穴を出荷前に発見）。
仕様変更で既存データの金額が動くときは、フォールバックで誤魔化さず「移行時に値を書き込む」。フォールバックは新規データにも効いてしまい別のバグになる。移行は日付で線引き（created < 仕様変更日）。
自動で付くフラグは、消える条件を最小に。「保存したら消える」は事故になる。

03:55 - HP CRM 金額を税込で統一（ver74）

大串FB「全部税込で統一。これから自分で案件やデモを入力する時も税込にする」。

案件モーダルの入力欄を 「初期費用（円・税込）」「月額（円・税込）」 に（placeholder も 110000／11000）。収益ページ・案件管理ページ・目標ページの前提に 「金額はすべて税込」 を明記。
消費税の計算機能は持たない（入力値をそのまま集計）。税抜/税込フラグも作らない＝運用で税込に統一するだけ。
デモ制作／コンペ（失注）＝ ¥5,500（税込・取り分なし） のまま。
データ修正: 株式会社ロードマップを税込に更新（初期費用 100,000→110,000／月額 10,000→11,000）。取り分20%なので 自分は初期¥22,000・月額¥2,200。公開日 2026-07-31 は保持されたまま。
検算（実機）: 8月に入るお金 ¥24,200（内訳初期¥22,000＋月額¥2,200／案件全体¥121,000）、8月の売上 ¥7,700（デモ¥5,500＋月額¥2,200）。

収益モデル（最新・ver74時点）

金額はすべて税込で入力・表示
案件制作 = 初期費用×取り分（課金開始日の月に1回）＋月額×取り分（公開した月から毎月）
デモ制作 = 常に¥5,500・自分だけ（案件全体には入れない）
コンペ = 失注のときだけ¥5,500・自分だけ

04:05 - HP CRM ロードマップの実データ修正（コード変更なし）

大串FB「ロードマップは税込の状態で100000で自分のお金も20000」「六月に案件受注して七月に受け取ったから反映」。

項目	値
初期費用	¥100,000（税込） → 自分 ¥20,000
月額	¥11,000（税込） → 自分 ¥2,200
受注日	2026-06-19（元から）
初期費用の計上月	2026年6月（`billingStart` 2026-06-19）→ 月末締翌月末払いで 7月末入金
入金日	2026-07-31（受け取り済み）
公開日	2026-07-31 → 月額は7月分から（8月末入金）

検算（実機）: 7月末入金 ¥20,000（6月の売上＝初期費用）／8月末入金 ¥2,200（7月の売上＝月額）／9月末入金 ¥7,700（8月の売上＝月額¥2,200＋デモ¥5,500）。

※日付の粒度は推定で入れた箇所あり: 入金日は「7月に受け取った」から 7/31（月末） とした。実際の入金日が違えば案件詳細で直せる。

04:15 - HP CRM 料金体系を変更：案件全体は税抜・自分の取り分は22%（ver75）

大串FB「これから受注するものは収益全体は税抜で入力する。だから自分の取り分は案件全体の収益の22%になる。全体15,000なら自分3,300／案件200,000なら自分44,000」。

22% ＝税抜20% ＋消費税＝自分が受け取る税込額（税抜の20%に消費税を乗せた額）。

新規案件の既定を 取り分率22%・初期費用200,000（税抜） に。取り分率が未入力のときの既定も22。
入力欄を 「初期費用／月額（円・税抜）」、取り分率欄に「税抜額の22%＝受け取る税込額」の注記。
収益／案件管理／目標ページの説明を 「案件全体は税抜・自分の取り分は22%」 に統一。
目標プランの前提も更新（1件＝初期¥200,000（自分¥44,000）＋月額¥15,000（自分¥3,300）／取り分率22%）。目標プランは未保存でコードの既定値を使っていたため即反映。2026年の自分の年間収益（目標）＝¥391,875。
既存案件は据え置き（ロードマップ＝税込¥100,000・取り分20%）。7月末入金¥20,000・8月末入金¥2,200が変わっていないことを実機で確認。

注意（次に触る人へ）

税込20%の案件（ロードマップ）と税抜22%の案件が混在する。案件ごとに shareRate を持っているので計算は正しく出るが、一覧で見比べるときは前提が違う点に注意。

収益モデル（最新・ver75時点）

案件制作（これから）= 税抜で入力し、自分は22%。初期費用は課金開始月に1回・月額は公開した月から
案件制作（既存・ロードマップ）= 税込入力・取り分20%
デモ制作 = 常に¥5,500（税込・取り分なし・自分だけ）
コンペ = 失注のときだけ¥5,500（同上）

14:55 - MEロゴの背景透過＋CRMアイコンに反映（ver76）

透過PNGの作成（大串の依頼：黒い文字の輪郭に沿って切り抜き）

~/Downloads/ME_logo_transparent.png（375×375）と ME_logo_transparent_trim.png（289×296・余白を詰めた版）を作成。
- 手法: 輝度235以上→完全透明／25以下→完全不透明／間は元の濃さのままアンチエイリアスを保持。色は黒に固定（中間色に白が残ると白フチになるため、濃さはアルファで表現）。
- 検証: 不透明部分のRGB最大値0（＝白の混入なし）／四隅アルファ0／赤・白・グレーの3背景で目視。
- 描き直し・補正は一切なし。元の黒画素をそのまま使用。

「文字の内側の抜けを白に」→ ①（現状のまま透明）で確定

調べたところ このロゴには完全に囲まれた抜けが1つも無い（白領域は全部つながって1つ＝Mの谷もEの隙間も円の外まで通じている）。そこで4案（現状／弱く塞ぐ／強く塞ぐ／円の内側を全部白）を画像で並べて提示 → 大串は ①現状のままを選択。

CRMアイコンに反映（ver76）

透過ロゴから作り直して5箇所（favicon 64／apple-touch 180／アバター 96／サイドバー左上ロゴ 128／ログイン画面ロゴ 128）を差し替え。ロゴが円の直径の78%に入り、以前より大きくきれいになった。白い丸に乗せたバッジ形式（黒一色の透過のままだとダークUIやタブで沈むため）。

学び

「切り抜き」は連結成分を数えてから話す。囲まれた領域が本当に存在するか（外周に接しているか）を先に調べると、実現できない指示を早い段階で見抜ける。
仕様が競合したら、文章で聞かずに候補画像を並べて出す。今回「アウトラインに沿って」と「内側を白に」が両立しなかったが、4案を1枚にして送ったら番号1つで即決した。
白背景の除去は 二値化ではなく「輝度→アルファ」にするとアンチエイリアスが残って自然。ただし色は黒に固定しないと白フチが出る。

15:10 - HP CRM タスクページに「今日やること」（ver77）

大串FB「1日の初めに今日やることをまとめたいから、タスクページに今日やることを入れられるようにして」。

タスクに todayAt（YYYY-MM-DD） を持たせ、各タスク行の 「今日」ボタンで出し入れ。
ページ最上部に 今日やることボックス：完了数（0/2件）・進捗バー・優先度→締切順。完了ぶんも消さずに残す（進み具合が見えるように）。
追加フォームに「今日やる」チェック → 追加と同時に投入。
「締切が今日・超過のものを入れる」ボタンで一括投入（朝にまとめる用）。
日付が変わると自動で外れる（todayAt !== 今日）＝毎朝作り直す運用。前日のやり残しは持ち越さない。

実機で投入／一括投入／解除／進捗表示を確認し、テストで入れた分は元に戻した（todayAt付きは0件）。

設計メモ

「今日やること」を別リストにせず、既存タスクにフラグを付ける方式にした。二重管理にならず、完了状態も締切バッジもそのまま使える。日付を保存しているので「いつの今日か」が判定でき、日付が変われば自動で空になる。

2026-08-15 09:25 - HP CRM ★削除が復活するバグを修正（ver78〜79）

ver78

タスクページの検索欄「／で検索…」を削除（入力ハンドラ・「/」ショートカット・未使用CSSも撤去）。

ver79 ★重要：削除したタスクが復活する

症状（大串FB）: タスクを消す → 別ページへ → 戻ると復活。
原因: サーバー functions/api/data.js の mergeSync が 「incoming に無いID＝別端末で作った分」とみなして残す仕様（ver54で「別端末の記録が消える」対策として入れたもの）。削除して保存しても、次の pull でサーバーの控えが戻ってきていた。同一端末でも必ず起きる。
対処＝削除記録（トゥームストーン）:
クライアント: setItem 横取りの中で保存の前後のIDを見比べ、消えたIDを hpcrm.tombs.v1 に控える（各機能の削除コードは無改修）。PUT の body.deleted で毎回送る。
サーバー: store の __tombstones__ 行に蓄積し、マージ後とGET返却前に必ず除去。90日でパージ。
→ 「作った記録を消さない」マージの利点は維持したまま、削除だけ伝播する。
あわせてタスクページの「次の締切」欄を削除（大串FB）。

検証（本番で実際に再現→修正確認）

テスト用タスクを作成→サーバーに20件で保存されたのを確認→削除→サーバーも19件に→別ページ往復→復活しない→リロード（サーバーから取り直す経路）→復活しない。Nodeでもロジック単体を検証（別端末が古い一覧を送ってきても削除は復活せず、その端末の新規は守られる）。

学び

「消えないようにする」設計は、そのままだと「消せない」になる。マージ方式にしたら削除記録（トゥームストーン）はセットで必要。
削除の伝播は クライアントとサーバーの両方に手を入れないと直らない。片方だけ直すと直ったように見えて再発する。
差分検知は保存処理の入口（setItem横取り）に置くと1箇所で済む。削除ボタンが何箇所にあっても拾える。

2026-08-16 09:40 - HP CRM デモ制作に「完成」ボタン（ver80・収益モデル変更）

大串FB「デモ制作は5,500円だけど、完成したら収益が発生する。デモ制作ページに完成ボタンを入れて。完成ボタンを押したらその次の月に収益が入るように」。

デモカードの右下に 完成トグル。押した日を completedAt に記録（表示「完成 8/16」）。もう一度押すと取り消し。
収益は 作成月 → 完成月 の計上に変更。入金はその翌月末（月末締翌月末払い）。未完成のデモは計上しない。
コンペ（失注）は従来どおり作成月に計上（今回は変更なし）。

実機検証

未完成の状態 → 9月末入金 ¥2,200（デモ分が消える）／完成を押す → 9月末入金 ¥7,700（内訳に「株式会社VOID デモ制作（完成）¥5,500 自分だけの収益」）→ 取り消しで元に戻る。テストで押した完成は元に戻した。

影響

株式会社VOID は工程「トップページ制作」＝未完成だったため、これまで8月の売上に入っていた¥5,500が外れた。完成を押した月に計上される（正しい挙動）。

収益モデル（最新・ver80時点）

案件制作（これから）= 税抜入力・自分22%。初期費用は課金開始月に1回／月額は公開した月から毎月
案件制作（既存ロードマップ）= 税込・取り分20%
デモ制作 = 完成した月に¥5,500（自分だけ・未完成は計上しない）
コンペ = 失注のときだけ¥5,500（作成月・自分だけ）

2026-08-16 09:50 - HP CRM コンペの失注は「押した月」に計上（ver81）

大串の確認「コンペは受注・失注ボタンで失注になったら5,500円反映、受注になったら何もしない。でOK？」→ 仕様はその通りだが、計上月が「作成月」だったズレを指摘して、大串の指示で「押した月」に変更。

受注/失注を押した日を outcomeAt に記録。失注はその月の売上＝入金は翌月末。
押した日が無い古いデータだけ作成月にフォールバック。
案件詳細の状態表示を「失注 → ¥5,500を8月の売上に計上（入金は翌月末）」に。
受注は何も計上しない（案件制作として登録して収益化）／未確定も計上しない。

実機検証: 8/13作成のコンペを 8/16 に失注 → 8月の売上に¥5,500（9月末入金 ¥7,700）→ もう一度押して未確定に戻すと消える。テストで押した分は未確定に戻した。

収益モデル（最新・ver81時点）

案件制作（これから）= 税抜入力・自分22%／初期費用は課金開始月に1回・月額は公開した月から毎月
案件制作（既存ロードマップ）= 税込・取り分20%
デモ制作 = 完成を押した月に¥5,500（自分だけ・未完成は計上しない）
コンペ = 失注を押した月に¥5,500（自分だけ・受注/未確定は計上しない）
すべて月末締・翌月末払い＝売上の翌月末に入金

学び

「これでOK？」という確認は、仕様の答え合わせだけでなく“隣接するズレ”を点検する機会。今回は仕様自体は合っていたが、計上月がデモと揃っていない点を指摘して修正につながった。

2026-08-16 10:20 - HP CRM ★コンペは受注でも失注でも¥5,500（ver83・収益モデル変更）

大串FB「新事実。コンペ制作は受注でも失注でも5,500円入るらしい」。

従来: 失注のときだけ¥5,500計上 → 変更後: 受注/失注どちらでも¥5,500計上。
計上月は 受注/失注ボタンを押した月（ver81で入れた outcomeAt）。未確定は計上しない。
受注した案件の初期費用/月額は従来どおり「案件制作」に登録して別計上。二重計上ではなく、コンペの制作フィーと案件の売上は別のお金という整理。
明細ラベルは「コンペ（受注）」「コンペ（失注）」で区別。案件詳細の状態表示も更新。

実機検証: 受注を押す → 8月の売上に¥5,500（9月末入金 ¥7,700・明細「株式会社ack工業コンペ（受注）」）→ 取り消しで未確定に戻る。テスト分は未確定に戻した。

収益モデル（最新・ver83時点）

案件制作（これから）= 税抜入力・自分22%／初期費用は課金開始月に1回・月額は公開した月から毎月
案件制作（既存ロードマップ）= 税込・取り分20%
デモ制作 = 完成を押した月に¥5,500（自分だけ・未完成は計上しない）
コンペ = 受注/失注どちらでも押した月に¥5,500（自分だけ・未確定は計上しない）
すべて月末締・翌月末払い＝売上の翌月末に入金

未決（大串の相談中）

「デモ制作とコンペ制作を1ページにまとめた方がいいか」→ 分けたまま推奨で回答済み。決定待ち。

2026-08-16 10:40 - HP CRM デモ・コンペを1ページに統合＋タブ大型化（ver84）

大串の判断「タブ方式にする。収益と入金予定ページのタブ、画面の端から端までの大きいタブにして。デモとコンペも」。

サイドバーは「デモ・コンペ」1項目に（旧「コンペ制作」「デモ制作」を統合）。ページ上部の大きなタブで切り替え。最後に見ていたタブは dcType に保持し showView が democompe → dcType に解決。
工程（デモ4段／コンペ6段）・完成ボタン・受注/失注ボタン・コンペ統計（勝率・投下時間）は従来どおり種別ごとに動作。見出しは「デモ・コンペ制作」、新規ボタンは開いているタブに追従。
タブを画面幅いっぱいの大きなタブ（.seg / .seg-btn）に統一。収益ページの「入金／売上」も同じスタイルに（旧 .rev-maintabs 廃止）。実機で各ボタン462px＝横いっぱいを確認。

経緯（相談→決定）

「デモとコンペを一緒のページにした方がいいか」と相談があり、分けたまま推奨＋中間案としてタブ方式を提示 → 大串がタブ方式を採用。金額は同じ¥5,500でも、工程・勝率統計・収益の起点（完成／受注失注）が違うため、中身は分けたままタブで束ねる形が正解だった。

2026-08-16 11:00 - HP CRM 請求書発行ボタン（ver85）

大串FB「案件制作・デモ制作・コンペ制作それぞれの詳細に請求書発行のボタンを作ってほしい（発行したかしてないかごちゃごちゃになる）」。

案件詳細の最上部に 「請求書発行」ボタン。押した日を invoicedAt に記録し、「発行済み 2026/08/16（押すと未発行に戻せます）」と表示。もう一度押すと未発行に戻る。
3種別は同じ詳細画面（view-work-detail）なので1箇所の実装で案件制作・デモ・コンペすべてに効く。
「ごちゃごちゃになる」の解消には一覧で見えることが効くので、制作カードに「請求済 8/16」バッジ、案件管理の表に「請求書」列（未請求は強調表示・請求済は日付つき）も追加した。

実機検証: 3種別すべてでボタンが出ることを確認 → 発行を押すと詳細・カード・案件管理の3か所すべてに反映 → 取り消しで元に戻る。テスト分は未発行に戻した。