さっきのメッセージを読み返したら、本当は3つの違う問題が混ざっていた。混ざったまま「ダッシュボード設計」を進めても永遠に決まらないので、まず分解する。
この順で1つずつ解く。
これは事実。Telegramの吹き出しは長文に向かない。完了報告、調査結果、設計提案、どれもスマホの細い画面で延々スクロールするのは苦行。健人が「HTMLで書いて」と言ったのはここに対する叫び。
→ 答え: HTMLで書く。これは plan-viewer の領分。
完了報告も自動でHTML化して plan-viewer に流せば、Telegramには「完了。詳細はこちら↓」のURLだけ残せる。現行 report-done-v2.sh の発展形でできる。
ここが本質。私が今まで作ろうとしていた mini-apps-ui は、突き詰めると「ジョブ管理画面」だった。
ジョブ管理で健人が実際にやることを列挙する:
つまりTelegramで全部できている。GUIで「カードがズラっと並ぶ」必要があるかというと、毎日見るほどの頻度ではない。
→ 答え: ジョブ管理専用GUIはほぼ不要。Telegramコマンドの拡張で十分。
健人の直感は正しい。ただし「コンテキスト圧迫」の懸念は別問題。
私(秘書セッション)はコンテキストにジョブ全件を抱えなくていい。必要な時だけ sqlite3 でクエリする運用が既にできている(/jobs /status /wait はそう動いてる)。だからGUI無くしても秘書のコンテキストは膨らまない。
逆に、健人が「今こんなジョブがある」を一望したい瞬間は確かにある。それはTelegramで /jobs を叩けば私がリストを返す。リスト形式で十分なら、GUIは過剰。
→ 答え: 秘書の能力で代替可能。GUIにする必然性はない。
3つの答えを統合するとこうなる。
| 用途 | 担当 |
|---|---|
| 報告/レポート/調査結果/設計案を読む | plan-viewer (改良版) |
| ジョブの承認/質問回答 | Telegram (現行のInline Keyboard) |
| ジョブ一覧/進捗確認 | Telegramコマンド (/jobs /wait /status) |
| 緊急対応/相談 | Telegramチャット (現行) |
mini-apps-ui は「ダッシュボード」という看板を下ろし、廃止する。代わりに plan-viewer をカードタイムライン化して読み物配信に集中させる。
これで健人が見るべきもの全部が plan-viewer 1箇所に集まる。Telegram MenuButtonタップ → plan-viewer が開く運用。
Day 1: 既存 plan-viewer index.html を「カードタイムライン」UIに書き換え。アイコン+タイトル+時刻+typeバッジ。
Day 2: report-done-v2.sh を改造、完了報告を md ファイル化 → ~/plans/ に書き出し → 既存の convert-plan.sh が自動でHTML化 → index.html に登録される導線を確認。
Day 3: 既読管理(localStorage)、フィルタ実装、Telegram MenuButton から開く動線確認。mini-apps-ui の廃止は最後。動作確認してから止める。
ジョブ管理GUIは作る必要がなかった。健人が言いたかった「ダッシュボード」の正体は「読み物プラットフォーム」だった。plan-viewer を主役に据え直すのが正解。
mini-apps-ui は廃止、plan-viewer をカードタイムライン化、完了報告はHTML自動生成 → URL のみTelegram。これが筋。
進める?