p-PP: discord対応
うまくいかないのではないかと思っているから、LLMがなければ実装に着手しなかった機能
大方針
LLMを使い倒す
しかしコンテキストが明らかに無駄な部分のフィルターの部分は決定論的に行う
例：普段やらなくていいタスクまで/suggestの候補にわたしてしまうと金も時間もかかり結果の精度も落として最悪
妥協
「複雑」な分析はこのソフト上ではやらない
「複雑」の基準は？→gpt-5-miniでできないことは複雑
LLMの進化によって、勝手にこの基準が上がる事を目論んでいる
データの最適化は必要な時だけ行う（例えば1日に1回だけ実行）
超短期の緊急タスクはスコープ外
複雑ではないはず（超短期で複雑なら達成困難なため）。自分でやるほうが早いだろう
開発コマンド
謎プロセスが動いている
$ lsof -ti:8787 | xargs kill -9
アプリの不満
検索が弱すぎる
discordのチャットでテキストとして返す必要もあるしインクリメンタルに検索できない
根本的にできないことを頑張るのは悪手なので、やらない。検索がしたい場合は管理ツールを使う
/suggestでいい感じにタスクを渡してくれる事によって長期目標に向けて歩めるということがこのアプリのコアであり、他のアプリでできないことだ
AIによって人間を長期目標にガイドしている
cf. 通常LLMを使うときは人間がガイドする
TODO
ルーチンタスクの取り扱い
タスクの検索
/task機能
管理ツールからやるほうがいい？
✅タスク追加
✅更新
削除
/task ゴールA機能
ゴールAの次にやるべきタスクと達成基準が示される
完了したら完了になる
すべてのタスクが完了したらゴールがcompletedになる
気分じゃない時にタスクガチャを引き直したい
p-PP: /suggestで 締め切りが近いタスクを表示する
締切を忘れたくない
優先度は低い（妥協の範疇）
よく使いそうだから、別コマンドにしたほうがいいな.../deadlineコマンドの実装
と思ったけどベストはやっぱり/suggestで、それに与えられたことをやっていくとできちゃうのがいい。コマンドを使い分けたくない。めんどくさい。
締め切りが近いとコアタスクに出やすくなるとかがいいか？
緊急度=（タスクの重さ/残り時間）を定義しよう
締切がないタスクは残り時間が無限だから緊急度が上がらない。正しい
タスクの重要度は緊急度に寄与しなくて良さそう
締切が近いタスクは「妥協」するわけだから、そこは無視してもいいのかも。 迷う。
GoalはProjectに変更したい
Taskの集合がProject
Taskはsub taskを持つことができる
半分実施
コード分割
2. src/routes/oops-hatch-dashboard.ts (1929行):
懸念点: ダッシュボードのルーティングファイルですが、1つのファイルに多数のルートとハンドラが集中しているようです。
提案: 機能や関心事に基づいてファイルを分割する。例えば、ユーザー管理、タスク管理、設定などの機能ごとにルーターを分け、メインのファイルではそれらをインポートしてまとめる形が考えられます。
3. src/services/taskStorage.ts (1277行):
懸念点: taskStorageという名前からタスクの永続化が責務と思われますが、ファイルサイズが大きいため、ビジネスロジックや複数種類のデータ操作など、過剰な責務を抱えている可能性があります。
提案: TaskRepositoryのような、より責務の明確なクラスやモジュールに分割する。データの種類や操作（例: TaskQueryService,TaskCommandService）に応じてファイルを分けることも有効です。
2025-10-04
✅APIの鍵設定
受け入れのテストが面倒
QA向けのagentを作成
ブラウザを利用したテストを追加
認証後のページのテストをするためには認証を突破する必要がある
Firebaseにはエミュレーターが用意されている。Authenticationも存在する
https://gyazo.com/2c855f911e6efa2c35a57a3a84ae111b
ローカルのエミュレーターが使えるようになった
2025-10-02
✅上部にはタスク数・ゴール数・ポラリス数を出すようにしたい
フィルターの数はボタンUIの右側に控えめに出すようにしてほしい
/taskで
✅タスク分割して複数のタスクが生まれたらgoalを自動で作って紐付けて欲しい
✅スレッド内だとそのタスクについてコンテキストが引き回される
✅スレッド内で/taskでタスクを更新するときにうまくいっていない
taskIdがundefinedになってる
/taskで複雑なタスクを投げた時にコンテキストが引き継がれないも名代について設計を相談したら、フォローアップが必要な場合にスレッドを作成し、既存のスレッド機能の中ではコンテキストが引き継がれるのでそれを使うという適切な設計提案をしてきた。良い。
できた
https://gyazo.com/1875954c4c1f20a25696f89e595b9fef
内容に沿った非常に柔軟なプログラムができつつある。LLMはこのような用途にドンピシャだ。
APIの旧実装を削除したらダッシュボートが使えなくなり再実装するはめになった
アイコンが気に食わなくなってきたかも。アイコンのキャラと発言が合ってない
Aniのようにキャラクター路線にするか、HALのような人工的な路線にするか
多くの人が間違いを許せるのは可愛い人形キャラクターだろうな
✅ログアウトボタンが消えた
✅Poralis /goalsがない
✅編集の保存はできる？
✅締め切り間近なタスクの表示
✅検索機能が聞いてない
noteの中に意図しない構造があることが発覚
愚直にやったら141件のデータでスコア計算に0.5sもかかって全然動かなかった
https://gyazo.com/59f20da3e8ea3aca297df0541a84cc39
2025-10-01
✅/suggestで maintenanceが出ていたはずなんだけど普通にデフォルトの時間30分ぐらいのタスクが3つsuggestされてしまう
dashboardにログイン機能を実装中
https://gyazo.com/50845a6edb4038a4248c4a15835b6c86
このダッシュボードは普段使ったら「負け」
2025-09-27
✅直接データを編集できるeditorが欲しい
https://gyazo.com/f68ac6bc0ce00fabb64b7d6c3da6efa2
18:30 editorで編集してバックアップする運用ができた
2025-09-26
決定論的なフィルタはデータベースを使うのが扱いやすい良いため、データベースに格納することにした
jsonがわかれているのをここまで作成したモデルで表現する設計検討
2025-09-25
新しいアーキテクチャで/suggestできるようになった
✅TaskとPorarisが混在しているので分ける必要がある
discordでまともに動かすために、当初の予定でやらないと思ったことをやるはめになっている。気軽さが失われている。
LLMに全部任せるのが気軽で良かったのに前処理をするはめになっている
機械的処理は決定論的にできる最小限で、あとはLLMに丸投するのが正しい
2025-09-24
機械的に決定できるところとLLMにまかせる協会を作った
例えばidの生成は機械的に処理するようにした
これによって新規のデータ形式にする必要があった
OpenAI Batch APIを使ってgpt-5-nanoで新規のデータ形式に変換した
2025-09-22
複雑になってきたのでアーキテクチャを整理する必要がある
新機能を載せるま絵に機能を整理する
linterを入れたらanyが爆発したので地道に直させる
formatter/linterをいれる細かく大規模に書き換えられた時に差分が見やすくて便利
Claude Codeは実装で使うので、実装中はタスク管理システムを運用させられないという悩みがある
どこに保存するか？
discord botのようにdiscord対応させる
コマンドは
モデルはgpt-5 miniを利用する
聴講が必要な場合は手元でChatGPTでバラしてから入れることを想定する
Storage per Durable Object 10 GB
十分すぎる
バックアップは手元ダウンロード
バックアップのためのエンドポイントも作成する
タスク操作
/task message <内容> タスクを追加
/goal （北極星の確認・更新）
バックアップ/復元
/backup export 全データをJSONでダウンロードリンクにして返す
/backup import <file> JSONをアップロードして復元（管理者限定）
最小構成なら
/task add, /task list, /task done, /task suggest, /goal set, /backup export
だけでも実用に耐えると思います。
流れユーザー入力を受ける
botの役割
その文字列をそのまま gpt-5 に渡す
gpt-5には「自然言語をYAML編集に変換する」プロンプトを与えておく
出力は JSON か YAML Patch 形式に制約して返させる（structured outputs）
gpt-5はタスクを分析し、以下のようなyamlを返す
code:yaml
{
"action": "add",
"file": "core_tasks.yaml",
"task": {
"title": "レポートを書く",
"deadline": "2025-09-19",
"priority": 1,
"status": "未着手",
"duration_min": 90,
"category": "司法試験"
}
}
Botがこれを受け取って core_tasks.yaml を編集する
Botの編集処理
該当するYAMLファイルを読み込み
指定位置に追記／更新
ファイルを保存
JSONLにしても良さそうだな
JSONやyamlは全部読み込まないと構造不明
実装経過
機能拡張のためにアーキテクチャを検討して変更した。丸一日かかった。
次はドメインを確定させていく
不定形のタスクデータがプログラムを構造化する際に障害になっている
必ず必要なデータとオプショナルなデータに分けて、LLMが自由に扱える情報はオプショナルなデータ（例えばノート）に押し込める方針でドメインを確定させていく
スレッド作成時にJSONの詳細を出すようにした（gpt-5-nanoが整形している）
https://gyazo.com/13e3214dfa54e3c06277301fdf91a63f
/taskでタスクの更新をできることを確認
idをLLMが適当に作らせるのではなくnano IDで生成するように変更。既存データをmigration
不定形のJSONを扱う部分はすべてLLMに任せる方が良さそうだ
不定形のデータを扱えるのがタスク管理システムとして珠玉の部分だが、これを構造的に扱おうとすると大変な上に、どうしても良さが消えてしまう。だからすべてLLMに任せる
基本的な実装が進んだ
設計思想
Single Source of TruthはDO上のデータ
タスクなしの場合は捏造せずに、なしが表示される
https://gyazo.com/fdbcd10ab079598db28c62f155105774
GitHub上のJSONLから初期化ができる
DO上JSONLをExportができる
個人的な応答をする際にはEPHEMERALフラグを使う
他人にチャットが見えなくなる
データバックアップの流れ
/initを叩くとdata/jsonlが読み込まれる（初回）
discordで編集処理
以下のコマンドでdata/jsonlに保存される
$ opr node scripts/convert-export-to-import.js
固定値がかえるようになった
https://gyazo.com/71e180f110be1b20aa051c3f23a501d4