Work In Progress

このプロジェクトで現在進行中の作業と、過去のスナップショットを記録する。

現在の状況

平面B 2つ目のモジュール「ASCユーザー動向 異常検知」が完成（検知フローまで検証済み）。 departments/asc-user-trend/。設計は 検知=Codex / 通知=Claude の分業:

• 毎朝 launchd → run-detect.sh → Codex CLI（ヘッドレス・ChatGPT定額・gpt-5.5） がASC MCPで主要8アプリ取得→baseline参照→判定→logs/verdict.json(構造化)＋logs/report-latest.md(人間用)
• verdict=OK → 終了（Claude起動せず＝課金ゼロ）／ANOMALY → run-notify.sh(Claudeヘッドレス)→dedup→LINE「秘書」push
• 狙いはコスト: 毎日の重い分析はCodex定額に逃がし、Claudeは異常日のみ通知で起動
• 検証済み: codex CLIのChatGPT定額認証、ASC MCP疎通(APP_COUNT=42)、検知ドライラン（Codexが誤検知を全自力回避しverdict=OK、Claude未起動、Codex 157,810トークン/Claude 0）
• 既存流用: dedupは crashlytics-dedup を usertrend:asc: 名前空間で、LINEは「秘書」@593gsoyu

残タスク（You側手作業）:

• cp .env.example .env してLINE/dedup実値（DEDUP_SECRETはLambda env と同値）を投入
• com.assistant.asc-user-trend.plist を ~/Library/LaunchAgents/ に置いて launchctl load
• ANOMALY→通知の枝は未検証（実値.env＋実際の異常が必要。Crashlyticsで実証済みの同一curl経路）。verdict.jsonを異常入りに差し替え bash run-notify.sh で確認可

GA4ユーザー動向はペンディング（departments/ga4-user-trend/、READMEのみ）:

• ga4認証はADC失効→サービスアカウント鍵に移行済み（SA ga4-mcp@ichirokisanuki.iam.gserviceaccount.com、鍵~/.config/gcloud/ga4-mcp-sa.json）。SA認証は成功
• ただし監視対象プロパティ 211701453 へのSA閲覧者付与がYou権限的に今すぐ不可。SAは別アカウントの 172625023(7ちゃんねる)にのみ権限あり
• 再開条件: ①211701453にSA付与 or ②172625023へ対象変更／③CodexへGA4データ経路を追加（ASCと同様にMCP/スクリプト）

直近の学び（ハマりどころ）:

• ASC/GA4はローカルstdio MCP → クラウドルーチンから叩けない。無人化はローカルlaunchd＋ヘッドレスCLIで作る
• 無人運用にADC（ユーザーOAuth）は失効するので不可。サービスアカウント鍵にする
• ヘッドレスCodexは codex exec --output-schema ... -o file で構造化結果をファイル受け渡しでき、検知→通知の2段分業に向く
• ASCの get_sales_report はapp_id指定でも集計JSONに加え生TSV（最大295行/日）が付随。プロンプトで「TSVは無視・集計だけ使う」と明示。全アプリ版は81KBで巨大
• ASCの直近日集計は未確定で後から積み増される→「急減」誤検知に注意（確定日で評価）

詰まっていること: GA4の対象プロパティ(211701453)へのSA付与権限。ここが取れるまでGA4はペンディング。

---

過去のWIPアーカイブ

（新しい「現在の状況」を書く前に、古いものをここに追記でアーカイブする。新しいものが上）

2026-06-15 20:30 時点のスナップショット

平面B 初の稼働モジュール「Crashlytics監視」が本番稼働＋重複防止まで完成。クラウドルーチン（trig_012AaxgZwX2w61dWAYRNo3Ph）→ Gmail検知 → 重複チェック → LINE push まで全自動。LINE疎通(200)・dedupストア(curl)疎通済み。重複防止構成: DynamoDB crashlytics-dedup + Lambda + API Gateway（96sql32j6i.execute-api.ap-northeast-1.amazonaws.com）、コードは departments/crashlytics-watch/dedup-store/。次の候補は「朝のカレンダー＋アプリ売上プッシュ」だったが、実際にはユーザー動向異常検知に着手した。

2026-06-15 18:30 時点のスナップショット

平面B 初の稼働モジュール「Crashlytics監視」が本番稼働入り。クラウドルーチン → Gmailでアラート検知 → LINE push まで全自動で疎通確認済み（HTTP 200）。重複防止は未着手。

2026-06-15 17:50 時点のスナップショット

骨組み完成（git/GitHub連携・CLAUDE.md設計記述・.devnotes雛形）。中身は未実装。

次の候補:

• 平面Bの最初の1機能を通す: 朝にGoogleカレンダーの今日の予定＋App Store Connectのアプリ売上を iPhone へプッシュ（/schedule＋dev-timer）
• 着手前に Calendar / App Store Connect / 会計 MCP の接続状況を確認する

詰まっていること: 特になし（設計フェーズ完了）。

ロードマップ

今週

• 平面B 初の稼働モジュール「Crashlytics監視」を本番稼働（クラウドルーチン→Gmail検知→LINE push、疎通200確認）
• Crashlytics監視の重複通知を解消（AWS DynamoDB+Lambda+API Gatewayで通知済みID管理）
• ASCユーザー動向 異常検知を構築（検知=Codex定額 / 通知=Claude異常時のみ、検知フロー検証済み）
• asc-user-trend を本番投入（.env実値＋launchd登録）＋ANOMALY→通知の実弾確認【You手作業】
• GA4プロパティ211701453へSA ga4-mcp@… を閲覧者付与（権限取得待ち）→ ga4-user-trend 実装
• 平面Bの次の機能候補: 朝のカレンダー＋アプリ売上を iPhone/LINE へプッシュ

今月

• スケジュール管理部門・お金管理部門の知識ストアと定期ジョブを整備
• 承認フロー（重要操作は必ず人間が承認）の作法を固める

今四半期

• 会社運営部門（週次レビュー）・QOL向上部門（献立・嗜好提案）を追加
• 平面A（各アプリのQA/セキュリティ サブエージェント＋知識ストア）を1つ試作し、平面Bと役割分担を確認

いつか

• 外から話しかける入口（LINE等）の検討
• 各部門の知識ストアの自動キュレーション（古い知見のドロップ自動化）

意思決定記録

このプロジェクトで下した重要な意思決定を記録する。 最新が上に来る。

---

2026-06-15 ユーザー動向異常検知は「検知=Codex / 通知=Claude」の分業にする（コスト最適化）

背景: 当初はClaudeヘッドレス（claude -p）が毎日 全アプリ取得→判定→通知まで全部やる設計でドライランも成功した。ただ毎日の重い分析（8アプリ×複数日のMCP取得＋判定）をClaude課金で回し続けるのはコスト的にもったいない。Youの希望は「重い分析はCodex(ChatGPT定額)に逃がし、Claudeは異常時だけ通知」。

決定: モジュールを2段分業に再設計。①launchd→run-detect.sh→Codex CLI（ヘッドレス・ChatGPT定額・gpt-5.5） が検知＆レポート（--output-schemaで構造化JSON logs/verdict.json ＋人間用 logs/report-latest.md）。②verdictがANOMALYのときだけ run-notify.sh→Claudeヘッドレスが dedup→LINE push。平常日はClaudeを一切起動しない。CodexにASC MCPを使わせるため ~/.codex/config.toml に [mcp_servers.app-store-connect] を追記（Claude側設定を転記）。

理由: 検証で codex CLI(0.139.0)が ~/.codex/auth.json のChatGPTログイン（定額・APIキー従量ではない）で動くこと、codex exec --dangerously-bypass-approvals-and-sandbox が無人でASC MCPを叩けること（APP_COUNT=42）、-oで結果をファイル受け渡しできることを確認済み。検知ドライランではCodex 157,810トークン消費に対しClaude 0トークン（verdict=OKでClaude未起動）。代替案だった「全部Claude」「全部bash（curl）通知」より、コスト（定額側に重い処理）と品質（通知はClaudeが整形・dedup）のバランスが良い。検知と通知の責務分離にもなり、原則①(単一窓口＋承認)とも整合（通知＝人へのプッシュはClaude、書き込みはLINEのみ）。

2026-06-15 ユーザー動向異常検知はローカル定期実行（launchd）で作る。GA4認証はサービスアカウント鍵に移行、GA4は一旦ペンディング

背景: ユーザー動向検知の監視対象は App Store Connect（売上・DL）と GA4（アクティブユーザー・継続率等）。Crashlytics監視はクラウド/scheduleだったので当初それに倣おうとしたが、app-store-connect も ga4 も ~/.claude.json のローカルstdio MCPで、クラウドルーチン環境では起動できないと判明。さらにローカルga4 MCPは認証が invalid_grant: Token has been expired or revoked（ADC=ユーザーOAuthの失効）で死んでいた。

決定: 実行はクラウドではなく Mac上のローカル定期実行（launchd＋ヘッドレスCLI） にして、既存のローカルMCPをそのまま再利用する。GA4認証は失効するADCをやめ、サービスアカウント鍵に移行（SA ga4-mcp@ichirokisanuki.iam.gserviceaccount.com を ichirokisanuki プロジェクトに作成、鍵 ~/.config/gcloud/ga4-mcp-sa.json を600・git管理外で配置、analyticsdata/analyticsadmin API有効化、~/.claude.json のga4 credsをSA鍵に差替）。ただしSAを監視対象プロパティ 211701453 に閲覧者付与する操作がYou権限的に今すぐできないため、GA4ユーザー動向モジュールは一旦ペンディング（departments/ga4-user-trend/ はscaffoldのみ）。ASC側を先に完成させる。

理由: クラウドルーチンはローカルプロセス(stdio MCP)を起動できず、ASC/GA4を叩く手段が無い。MacのlaunchdならローカルMCPをそのまま使え、秘密情報もローカル.env（git管理外）に置けて取り回しが良い（制約はMac起動中のみ発火＝許容）。GA4のADCユーザーOAuthは設計上失効する（同意画面テストモードの7日失効や取り消し等）ので無人運用に不向き。サービスアカウント鍵なら人間の再ログイン不要で実質失効しない。SA認証自体は成功を確認したので、残るプロパティ付与権限が取れ次第GA4を再開できる状態にした。

2026-06-15 ステートレスなクラウドルーチンの重複防止は外部ステートストア（AWS DynamoDB+Lambda+API Gateway）で実装

背景: Crashlytics監視は時間窓方式（検索窓2.5h / 実行2h毎）のため、同じ日次トレンドメールが窓の重なりで複数回LINE通知されていた。Gmailコネクタは読み取り専用でラベル既読管理ができず、ルーチン自身もステートレスなので、ルーチン内だけでは重複を消せない。

決定: 「通知済みのGmailスレッドID」を外部ストアに記録して照合する方式を採用。AWS（個人アカウント776364707178 / 東京）に DynamoDB（PK=id, TTL=ttl, オンデマンド）+ Lambda（x-api-keyヘッダ検証）+ API Gateway HTTP API（GET/POST /seen） を構築。ルーチンは対象スレッドごとに GET で照会し、未通知のものだけLINE送信、送信成功後に POST で記録する。コード・デプロイ手順は departments/crashlytics-watch/dedup-store/。

理由: 候補案は ①そのまま許容 ②窓を狭める ③外部ストアで厳密dedup。Youが③を選択し、ストア先として DynamoDB/API Gateway を指定。DynamoDBはネイティブTTLで「通知済みID」を3日で自動失効でき肥大化しない。API Gatewayのエンドポイント（*.execute-api.<region>.amazonaws.com）は環境の既定許可リスト *.amazonaws.com にマッチするため、エグレス追加の手間が小さい（確実を期して明示追加もした）。DynamoDB直叩き（SigV4署名）はbashで面倒かつAWSキーをルーチンに置く羽目になるため、間にLambdaを挟み共有シークレットヘッダ方式にした。重複防止キーはGmailスレッドIDで一意・安定。dedupの記録は必ずLINE送信成功後（失敗時は次回再送できるよう未記録）。

2026-06-15 クラウドルーチンの外部HTTP送信はNetwork access=Customで送信先ドメインの許可が必須

背景: Crashlytics監視ルーチンを実行したところ、メール検知・本文生成までは成功するのにLINE送信だけ HTTP 403 で失敗した。クラウド実行環境のNetwork accessが既定の Trusted（パッケージレジストリ/GitHub等の既定許可ドメインのみ）で、api.line.me が外部送信の許可リストに無かったため。

決定: ルーチンが使う環境のNetwork accessを Custom にし、Allowed domains に api.line.me を追加（「既定の一般パッケージマネージャ一覧も含める」にチェックして既定リストを併用）。これで再Runは HTTP 200 となり本番経路が開通した。

理由: LINE push は api.line.me への外部HTTP送信が必須で、Trustedの既定許可には含まれない。一方 Gmail等のMCPコネクタ経由の通信はAnthropicのチャネルを通るため許可リスト不要（だからメール検知は通っていた）。今後クラウドルーチンから新しい外部API（会計・売上等）を叩く際は、同様に環境のCustom許可リストへドメイン追加が必要になる——再発しやすい罠として記録。なお設定はWeb UIの環境編集ダイアログでのみ変更可能（RemoteTrigger APIの対象外）。

2026-06-15 Crashlytics監視を平面Bの最初の実装として通した（→LINE通知）

• 決定: Firebase Crashlytics のアラートを /schedule クラウドルーチンで検知し、LINE に push する仕組みを構築。assistant プロジェクト初の稼働モジュール（平面B）。
• 構成: クラウドルーチン（2h毎 8-22時JST）→ Gmailコネクタで firebase-noreply@google.com のアラートメールを検索 → ベロシティ(緊急)/増加傾向(日次トレンド)を仕分け → LINE Messaging API を curl で直接 push。
• 情報源は Gmail: Crashlytics/Firebase の生APIは大掛かり（サービスアカウント/BigQuery）。Firebaseが確実にメールを送ってくるので、Gmail（接続済みコネクタ・クラウドルーチンから利用可）から拾う方式を採用。
• 通知先は LINE 単独: dev-timer/ntfy は経由しない。「assistant 自身が取りに行って自分でLINEに知らせる」自己完結を優先（Youの要望）。dev-timer は follow-up リマインダ用途のまま据え置き。
• LINE は Messaging API（公式アカウント「秘書」 @593gsoyu）: LINE Notify は2025/3末で終了済みのため Messaging API 一択。
• 秘密情報の置き場所: クラウドルーチンはローカルのファイル/環境変数を使えないため、LINEチャネルアクセストークンと userId はルーチン定義のプロンプト内にのみ埋め込む（アカウント専用・非公開）。git には入れない。リポジトリの departments/crashlytics-watch/ にはプレースホルダ版のひな形だけを置く。
• 重複防止は時間窓方式: Gmailコネクタが読み取り専用スコープ（ラベル付与不可）のため、ラベルでの既読管理は不可。検索窓2.5h（実行2h毎）で、取りこぼし回避を優先し軽微な重複通知は許容。
• ルーチンID: trig_012AaxgZwX2w61dWAYRNo3Ph（管理: https://claude.ai/code/routines ）。

2026-06-15 プロジェクト名は assistant

• 当初 life-os 案だったが、素直で秘書の総称として馴染む assistant を採用。

2026-06-15 部門は「2平面」に分けて実装する

• 決定: 8部門を一律にサブエージェント化せず、平面A（サービス系=受動的チェック=サブエージェント）と平面B（自分・会社系=能動的先回り=定期実行＋MCP＋プッシュ）に分ける。
• 理由: サブエージェントは呼ばれて初めて動く受動的な仕組みで記憶も持たない。スケジュール/お金のような「向こうから先回りしてくる」用途には不適。プリミティブが根本的に違う。
• 本プロジェクトの担当範囲: 平面Bのみ。平面A（QA/コードレビュー/セキュリティ）は各アプリリポ側に置く。
• 「開発」部門は作らない: それはメインのClaude本体そのものなので部門化しない。

2026-06-15 「社長＋各部署」会社経営モデルは採らない／単一窓口＋承認

• 決定: 部門は持つが、Youは単一窓口（このアシスタント）にだけ話しかけ、そこから各部門へ振る。重要な書き込み・送信は必ず人間の承認を挟む。
• 理由: 上坂氏が会社経営モデルを作って捨てた教訓——自律性を上げるほど人間の介在余地と検証が消える。

2026-06-15 「精度が上がる」は自動学習ではなく明示的な書き戻し（知識ストア）

• 決定: 各部門に知識ストア（永続ファイル群）を持たせ、承認した学びだけ追記する。RAG的に読み込んで精度を出す。古いものはドロップして肥大化を防ぐ。
• 理由: サブエージェント/アシスタントはステートレス。モデルは学習しない。「溜まって賢くなる」の機構は明示的な書き戻しでしか成立しない。

開発日誌

このプロジェクトでの作業を時系列で記録する。 最新のエントリが上に来る。

---

2026-06-15 ユーザー動向異常検知を「Codex検知 / Claude通知」型で構築（asc-user-trend）

• 平面B 2つ目のモジュールとして、アプリの売上・DL動向の異常検知ルーチンを作成。要件ヒアリング→3回の方針転換を経て着地
• 当初設計: Claudeヘッドレス全部入り（claude -pをlaunchdで毎朝起動→ASC/GA4取得→判定→LINE）。ドライラン成功（ASC取得8アプリ→曜日性判定→GA4 best-effortスキップ→異常0件でLINE無音）まで確認
• 判明した制約: app-store-connect も ga4 も ~/.claude.json のローカルstdio MCP。クラウド/schedule環境では起動できない（だからCrashlytics監視はGmailマネージドコネクタを選んでいた）→ ローカル定期実行（launchd）を採用
• GA4認証の修復: ローカルga4 MCPが invalid_grant: Token has been expired or revoked で死亡。原因はADC（ユーザーOAuth）の失効。無人運用には不向きなのでサービスアカウント鍵に移行（SA ga4-mcp@ichirokisanuki.iam.gserviceaccount.com 作成、鍵 ~/.config/gcloud/ga4-mcp-sa.json 600・git管理外、analyticsdata/analyticsadmin API有効化、~/.claude.json のga4 creds差替）。SA認証自体は成功したが、対象プロパティ 211701453 への閲覧者付与がYou権限的に今すぐ不可。SAは別アカウント配下の channel7-ios(172625023, ＝7ちゃんねる)にのみ権限がある状態 → GA4は一旦ペンディング
• 最終方針転換（コスト）: 検知＆レポートは Codex CLI（ヘッドレス・ChatGPT定額・gpt-5.5） に逃がし、Claudeは異常時のみ通知する分業に再設計。平常日はClaude課金ゼロ
• Codex土台の整備と検証: codex CLI(0.139.0)導入→Logged in using ChatGPT(定額)確認。~/.codex/config.toml に [mcp_servers.app-store-connect] を追記（Claude側設定を転記）。codex exec --dangerously-bypass-approvals-and-sandbox でヘッドレス疎通テスト→ ASC MCPのlist_appsを叩いて APP_COUNT=42 成功
• モジュール構成（departments/asc-user-trend/）: launchd→run-detect.sh→Codex検知(detect-prompt.md+detect-schema.jsonで構造化出力)→logs/verdict.json/logs/report-latest.md生成→verdict判定→ANOMALYのときだけ run-notify.sh(Claudeヘッドレス)→dedup照会→LINE「秘書」push→dedup記録
• 検知ドライラン成功: Codexが主要8アプリ×複数日をASC取得→baseline参照→曜日性/未確定データ/スポーツ日程連動の誤検知を全て自力回避→verdict=OK/anomalies=[]を出力→run-detectがOKを読んでClaude未起動（notify.log無し）。コストはCodex 157,810トークン（ChatGPT定額）、Claude課金ゼロ
• 対象は主要8アプリに限定（Vision Workout最重要ほか）。全42本中ロングテール約30本は<100/日でノイズ。全アプリ日次TSVは81KB/503行で巨大なので必ずapp_id指定
• dedup/LINEは既存流用: Crashlytics監視の crashlytics-dedup(DynamoDB,TTL3日)を usertrend:asc: 名前空間で共用、LINEは「秘書」@593gsoyu
• GA4側: departments/ga4-user-trend/ はペンディングscaffold（README）。再開条件（211701453へのSA付与 or 172625023へ対象変更、CodexへGA4経路追加）を明記
• 未検証: ANOMALY→通知の枝（実値.env＋実際の異常が必要。Crashlyticsで実証済みの同一curl経路）。本番投入（.env実値＋launchd登録）はYou側手作業
• 旧の Claude全部入り版 departments/user-trend-watch/（本セッションの未コミットWIP）は再構成に伴い削除

2026-06-15 重複防止を実弾テストで完全検証（窓を一時拡大→Run2回→復旧）

• dedupの「ルーチン→エンドポイント egress＋重複抑止」を実トラフィックで確認するため、検索窓内のFirebaseメールが0件だった状況を回避する形でテストを実施
• 手法: ルーチンの検索窓を一時的に 2.5h→6h（CUTOFF 9000→21600）に拡大し、約2.9h前に届いていたVision1の増加傾向メールを再び窓内に入れた
• Run A（窓6h）: Vision1ヒット → dedup照会 seen:false → LINE送信(1通) → dedup記録。DynamoDBに新規スレッドID 19ec9f7339edbc48 が入ったことで、ルーチン→Gmail／→LINE／→dedup POST(egress) の全経路が実弾通過と確認
• Run B（窓6h）: 同じVision1 → dedup照会 seen:true → 除外。LINE無音・DynamoDBも2件のまま増えず＝重複抑止が実際に効くことを実証
• テスト後、検索窓を本番の2.5h（9000）に復旧。一時設定は完全撤収
• 結論: 残っていた「ルーチン→dedupエンドポイントのegress」未確認リンクが潰れ、Crashlytics監視は本番稼働＋重複防止まで完全動作

2026-06-15 Crashlytics監視の重複通知をAWS（DynamoDB+Lambda+API Gateway）で解消

• 同じ日次トレンドメール（Vision1）が検索窓2.5hの重なりで複数回LINE通知される問題に対処
• 原因: Gmailコネクタが読み取り専用でラベル既読管理ができず、ルーチンもステートレス。時間窓方式だと重複が避けられない
• 対処: 通知済みスレッドIDを外部ステートストアに記録して照合する方式を構築（重複防止キー=Gmスレッドid、TTL3日で自動失効）
• 構築物（AWS acct 776364707178 / 東京）:
  • DynamoDB crashlytics-dedup（PK=id, TTL=ttl, オンデマンド）
  • Lambda crashlytics-dedup（Node20, x-api-key検証, GET=照会/POST=記録）
  • API Gateway HTTP API（GET/POST /seen → Lambda）。エンドポイント 96sql32j6i.execute-api.ap-northeast-1.amazonaws.com
  • IAMロール（当該テーブルのGet/Putのみ）
• ルーチンのプロンプトを更新: 対象スレッドごとに dedup を GET 照会→未通知だけLINE送信→送信成功後に POST 記録。コードは departments/crashlytics-watch/dedup-store/
• 検証: dedupエンドポイントは curl 4テスト（seen:false→記録→seen:true→不正キー403）で全合格。ルーチン経由の実弾は、検証時に検索窓内のFirebaseメールが0件（Vision1は約25分前に窓を抜けた）だったため未通過。egressは許可リスト明示追加＋既定*.amazonaws.comで二重カバー。次の実アラートで全経路が通る
• 副次効果: Vision1メールが窓を抜けたことで、当初の重複スパムは自然停止

2026-06-15 Crashlytics監視ルーチンのLINE通知を本番疎通させた

• 新セッション（前セッションがバグったため）でLINE通知の疎通を再検証
• 切り分け結果:
  • 手元（ローカル）から api.line.me への直接 push → HTTP 200・LINE着信OK（トークン・userId・友だち追加すべて有効と確定）
  • クラウドルーチンからの push → 当初 HTTP 403。原因はクラウド実行環境のNetwork accessが既定 Trusted で、api.line.me が外部送信の許可リストに無かったこと（GmailはMCPコネクタ経由＝Anthropicのチャネルを通るため許可不要で、メール検知自体は通っていた）
• 対処: 環境のNetwork accessを Custom にし、Allowed domains に api.line.me を追加（既定リストも併用にチェック）→ ルーチン再Runで HTTP 200。本番経路開通
• メール検知（Vision1の増加傾向）→ 仕分け → 本文生成 → LINE push まで全自動で通ることを確認。assistant 初の平面B稼働モジュールが本番稼働入り
• 気づき: シェル変数に予約名 UID を使うとzshが代入拒否（failed to change user ID）。手元テストの初回失敗の原因はこれで、LINE側は無関係だった

2026-06-15 プロジェクト発足・設計骨組み

• intelligence-bank の上坂氏「フライデー」動画を起点に、人生運営アシスタント構想を立ち上げ
• プロジェクト名を assistant に決定（life-os 案から変更）
• 設計の根幹を CLAUDE.md と DECISIONS.md に記録（2平面・8部門・単一窓口＋承認・知識ストア=明示書き戻し）
• 中身（定期ジョブ・MCP接続・知識ストア）は未着手。次は平面Bの最初の1機能（朝のカレンダー＋アプリ売上プッシュ）が候補

assistant（人生運営アシスタント）

概要

Youの人生・事業を運営するための単一窓口アシスタント（秘書）。スケジュール・お金・会社運営・QOLといった「自分/会社系」の部門を束ね、定期実行で先回り通知し、ここ一箇所に話しかければ各部門に振り分ける。

サービス（各アプリ）のコードに対するQA・セキュリティ等のレビューは、各アプリリポジトリ側のサブエージェントが担当し、本プロジェクトには含めない。

セットアップ

（記入予定）

使い方

（記入予定）