## 設計判断の記録 ### 問題 - `DDNS_TIME`（チェック間隔）と `UPDATE_TIME`（keepalive 間隔）が 1 本の systemd タイマーに依存していた - 2本タイマー案（#53）は解決策として機能するが、systemd 側に複雑さを押し出す - 実機デバッグで「どちらのタイマーのせいか」の切り分けが困難 ### 決定: 常駐デーモンに変更する **理由** 1. 2 本の `time.Ticker`（goroutine）でチェックと keepalive を内部的に独立管理できる 2. ログが 1 プロセス・1 ストリームに集約される → デバッグが容易 3. `systemctl status dipper_ai` 一発で全状態確認 4. `install.sh` からタイマー動的生成ロジックが不要になりシンプルになる 5. `DDNS_TIME=1d, UPDATE_TIME=2m` のような任意の組み合わせが自然に動く **デメリットと受容** - 常駐プロセスになるためメモリを常時使用（DDNS クライアントの規模では無視できる） - oneshot より実装が複雑になる（goroutine/signal 管理が必要） ### 実装内容 - `internal/mode/daemon.go`: Daemon() 関数、2 本の ticker、SIGTERM ハンドリング - `systemd/dipper_ai.service`: Type=simple、Restart=on-failure - `systemd/dipper_ai.timer` 削除 - `systemd/dipper_ai-keepalive.{service,timer}` 削除（#53 成果物） - `scripts/install.sh`: タイマー動的生成ロジックを除去 - `internal/mode/update.go`: DDNS_TIME gate を除去（ticker が timing を担当）
設計判断の記録
問題
DDNS_TIME（チェック間隔）とUPDATE_TIME（keepalive 間隔）が 1 本の systemd タイマーに依存していた決定: 常駐デーモンに変更する
理由
time.Ticker（goroutine）でチェックと keepalive を内部的に独立管理できるsystemctl status dipper_ai一発で全状態確認install.shからタイマー動的生成ロジックが不要になりシンプルになるDDNS_TIME=1d, UPDATE_TIME=2mのような任意の組み合わせが自然に動くデメリットと受容
実装内容
internal/mode/daemon.go: Daemon() 関数、2 本の ticker、SIGTERM ハンドリングsystemd/dipper_ai.service: Type=simple、Restart=on-failuresystemd/dipper_ai.timer削除systemd/dipper_ai-keepalive.{service,timer}削除（feat(systemd): DDNS_TIME と UPDATE_TIME を独立した2本のタイマーで管理 (issue #52) #53 成果物）scripts/install.sh: タイマー動的生成ロジックを除去internal/mode/update.go: DDNS_TIME gate を除去（ticker が timing を担当）