アーキテクチャ:

• クリーンアーキテクチャ(domain / usecase / repository / handler / infra)で管理APIを構成。依存方向の違反ゼロを go list で検証(handler→infraの直接参照0件、ドメイン層の外部依存0件・ORMタグなし)
• 層で括るか用途で括るかをバイナリ単位で使い分け — バッチは用途別パッケージに切り、必要なメソッドだけを利用側で定義するGo流のポート(consumer-side interface)で抽象化。教科書からの逸脱は理由とともにドキュメント化
• 単一ユーザーに右サイズした設計(初代のマイクロサービス・gRPC・Prometheus を「要件に対して過剰」と判断して撤去し、253ファイル・差し引き約7万行を削減)
• 縮退許容設計 — 「壊れない」より「壊れても翌日勝手に戻る」(Mac不在→エピソード欠番、無料API全滅→ローカルLLM、TTS障害→当日スキップ)
• 固定費ゼロ運用 — LLMは無料枠→ローカルのフォールバック、ホスティングは自宅Pi 5 + Cloudflare Tunnel
• プライバシー分界 — クラウドAPIに流すのは公開記事のみ、書籍・私的データはローカルLLM(Ollama)に限定
• 設計判断は決定ログ(D-xx / C-xx)として記録しながら開発

バックエンド:

• RSS / YouTube / ポッドキャストのマルチモーダル取り込み + 書籍PDFのRAG取り込み(Python + pgvector)
• 理解定着の学習ループ — 放送記事からクイズを自動生成し、spaced repetition(3段ラダー)で復習を翌朝の番組に注入
• トークン認証付きプライベートRSS配信(友人への限定配信、平文トークン非保存・404統一応答)
• セキュリティ実装 — HttpOnly Cookie JWT・SSRF防御・XFF詐称対策のレート制限
• テスト — 本体26,013行に対しテスト48,283行(162ファイル)。インターフェースを小さく保ち、モック生成ツールに依存せずテスト可能な構造を維持

フロントエンド:

• OpenAPI仕様からの型自動生成によるEnd-to-End型安全性
• ソース管理・トークン管理・アクセスログ・学習トラッカーのPWAダッシュボード

開発プロセス:

• Claude Codeのマルチエージェントオーケストレーション(親がタスク分解・裁定、実装エージェントとレビューエージェントを分離)で開発

• 並列評価によるパフォーマンス最適化
• サンドボックス実行による安全なコード評価
• フィードバックループによる自動修正・再評価
• 各フェーズの設計書・評価結果を自動でドキュメント化し、人間が最終判断できる状態を維持

アーキテクチャ:

• 単一のWebhookエンドポイントでメッセージ・参加・退出・フォローの各イベントを処理。CatLineBotが振り分けに徹し、LINEへの送信はLineReminderJob / LineWelcomeMessageJobへ委譲することで、Webhookの応答時間を外部APIに引きずられないようにしています
• SDK依存の局所化 — Line::Bot::V2::*に触れるのはLineMessagingだけに限定し、SDKのバージョン変更の影響範囲を1モジュールに閉じ込め(v1→v2移行もこの範囲で完結)
• 失敗への備え — 通信エラーはActiveJobのretry_onで指数バックオフ再送。処理できなかったイベントはErrorSanitizerで資格情報を伏せたうえで運用者へメール通知
• 独自レイヤーを増やさない設計 — Rails標準の語彙(モデル / concern / ジョブ)に収め、Fat ControllerとFat Modelの両方を回避

バックエンド:

• 認証をSorceryからRails 8標準のhas_secure_passwordへ移行し、Authentication(コントローラーconcern)とBruteForceProtection(モデルconcern)に集約
• punditによるポリシーベースの認可、rack-attackによるレート制限・ブルートフォース対策
• 可観測性 — /health(liveness)・/health/deep(DB + ディスク)・/health/ready(readiness)と、Prometheus形式の/metrics(本番はBasic認証)を提供

フロントエンド:

• Service Workerのキャッシュ戦略(cache-first / network-first / network-only)をStrategyRouterがリクエストごとに振り分けるPWA
• 戦略とマニフェストはconfig/pwa_config.ymlへ外部化しGET /api/pwa/configで環境別に配信、マニフェストはI18n対応で動的生成
• クライアント側のログ・メトリクスをPOST /api/client_logs / POST /api/metricsで収集

品質:

• SimpleCovで行・ブランチともに100%を必須化(下回るとRSpecが失敗終了)
• GitHub ActionsでRSpec(MySQL 8.0サービス)とRuboCopを実行し、mainへのマージでリリースを自動作成
• brakeman・bundler-auditによるセキュリティ監査