- バージョン: v0.7
- ステータス: MVP-0〜3 実装済み。MVP-2/3 すり合わせは
docs/mvp2-mvp3-alignment.md。本番構成は Vercel Hobby + Turso（DEC-04）。README: webapp/README.md
- 親文書:
docs/requirements.md（要件定義書 v0.4 / L3 ツール要件）docs/continuation-system.md（継続機構設計書 — 本アプリはこの外骨格の実装である）docs/happiness-framework.md（幸福整理書 — 記録項目・レビュー内容の出典）- この文書の役割: 継続機構（通知 3 本 + ランブックカード 5 枚 + 記録置き場 + 復帰ポイント）を Web アプリと通知で実現するための要件を固める。実装技術の最終決定は行わないが、要件から導かれる技術制約は明記する。
0. 決定事項と設計の最上位原則
0.1 決定の記録
継続機構設計書 §3 では「初期はノーコード、摩擦が実測されるまでツール化しない」としていたが、本人の意思決定により ツール化（Web アプリ + 通知）を前倒しで実施する。この決定を DEC-01 として記録し、L3 の「現時点では実装しない」の注記を無効化する。
ただし前倒しに伴うリスク（作ること自体が目的化し、運用が始まらない）への対策として、本文書は MVP を極端に小さく区切る（§10）。MVP-0 は「日次 1 行 + 通知 1 本」だけであり、それが 2 週間実運用されてから次を作る。
その後の確定事項:
- DEC-02: HP/MP の 5 段階ラベル文言を確定（§3.1.1）。
- DEC-03: 日次通知は毎朝 7:10（目覚ましのタイミング＝既存アンカーの直後）に確定。これに伴い日次記録の意味を「1 日の振り返り」ではなく「今朝の始動状態の計測」と定義する（§3.1.2）。
- DEC-04: 本番デプロイは Vercel Hobby（無料）+ Turso（無料）+ Vercel Cron。常時稼働プロセスは不要。Hobby Cron の時刻精度は ±59 分であり、実際の通知は「毎朝ちょうど 7:10」ではなく「7 時台のどこか」になる。本人の合意により、この精度で十分とする（目覚まし直後の厳密性より、運用の単純さを優先）。
- DEC-05〜11: MVP-2/3 のすり合わせ結果。詳細は
docs/mvp2-mvp3-alignment.md。要約: 週次=土曜午前15分・点検+発見1行、通知は日次Cron相乗り、月次=両方薄く、四半期=較正+意味+主活動+汎用能力+編集+エクスポート。
0.2 最上位原則（全要件に優先する）
| ID |
原則 |
| PR-1 |
アプリは外骨格であり、本人の記憶・意志・監視をあてにしない。 通知が唯一の駆動源であり、本人がアプリを「見に行く」ことを要求する機能を作らない（SRE 的プッシュ型。E3） |
| PR-2 |
日次 30 秒・週次 15 分・月次 15 分・復帰 60 秒の時間予算を超える体験を作らない。迷う UI は時間予算違反である |
| PR-3 |
責めない・数えない・急かさない。 ストリーク、未達表示、督促文言、空白期間の強調は実装禁止（L3-03/05、CON-03） |
| PR-4 |
データは本人のもの。 いつでも全量エクスポートでき、アプリを捨てても人生の記録は残る（L3-06） |
| PR-5 |
低刺激・予測可能な UI。 画面遷移・文言・レイアウトは毎回同じ。アニメーション・ポップアップ・不意の変化を最小化する（CON-01） |
1. スコープ
1.1 やること（本アプリが実装する外骨格の部品)
| 外骨格の部品（設計書 §3） |
本アプリでの実装 |
| 通知 3 本（日次・週次・月次） |
プッシュ通知 + フォールバック（§6） |
| ランブックカード 5 枚 |
アプリ内カード画面（本人が文面を編集可能） |
| 記録置き場 |
アプリ内 DB（日次ログ・レビュー記録） |
| 復帰ポイント（毎月 1 日） |
「おかえり通知」+ 復帰フロー画面 |
1.2 やらないこと（非スコープ。四半期レビューでのみ再審議可）
| ID |
非スコープ |
理由 |
| NS-01 |
ストリーク・連続日数・達成率・カレンダーの空白強調 |
PR-3 |
| NS-02 |
タスク管理・TODO リスト・目標管理機能 |
本システムの計画は「環境調整」であり、やることリストを持たない（L2-10） |
| NS-03 |
SNS 機能・他ユーザーとの比較・共有フィード |
P8（比較の摂取制限）。エスカレーション第 2 段（人間の安否確認）はアプリ外の人間関係で行う |
| NS-04 |
AI による自動アドバイス・コーチング |
メタプロセスの判断は操縦者の仕事（M-04）。集計までがアプリの仕事 |
| NS-05 |
ゲーミフィケーション（レベル・バッジ・ポイント） |
外発的報酬への置換は内発的動機を損なうリスク。自己承認（「よし」）で足りる設計 |
| NS-06 |
複数ユーザー向けの一般公開サービス化 |
利用者は本人 1 名。汎用化は要件を歪める |
| NS-07 |
ネイティブアプリ（iOS/Android）開発 |
Web + PWA で要件を満たせる見込み（§6）。満たせないと実測されたときのみ再審議 |
2. 利用者とユーティリティシナリオ
利用者は本人 1 名。ただし本人には状態が複数ある（同じ人間でも別ペルソナとして設計する）:
| ペルソナ |
状態 |
アプリに求めるもの |
| P-A 平常の被操縦者 |
HP/MP 普通。夜、疲れている |
通知から 30 秒で終わる。考えさせられたくない |
| P-B 消耗した被操縦者 |
HP 低。画面を見るのもつらい |
数字 2 つタップだけで満点で終われる。責められない |
| P-C 週末の操縦者 |
週 1、15 分だけメタ認知に使える |
今週の事実が集計済みで出てくる。書くのは 3 行 |
| P-D 帰ってきた人 |
数日〜数ヶ月の空白の後 |
説明を求められず、60 秒で復帰完了できる |
| P-E 四半期の設計者 |
3 ヶ月に 1 回、仕組み自体を見直す |
カード文面・通知時刻を編集できる。データを俯瞰・エクスポートできる |
主要シナリオ（受け入れテストの原型）
- S1 日次: 朝 7:10（目覚ましの直後）に通知が届く → タップ → HP を 5 択、MP を 5 択でタップ（今の状態） → （任意）昨日の味わいを 1 語入力 → 保存 → 完了画面（「よし」）。通知タップから保存まで 30 秒以内、必須操作はタップ 3 回以内。
- S2 縮退日次: S1 と同じだが、HP/MP のタップ 2 回 + 保存だけで終了。味わいはスキップ。それでも完了画面は満点扱い。
- S3 週次: 土曜 10:00 に通知 → 週次カードが開く → 今週の HP/MP と味わい語が自動集計表示 → 3 問に各 1 行回答 → G6 チェック 1 問 → 完了。15 分タイマーがカード内にあり、鳴ったら途中保存で終了できる。
- S4 月次: 第 1 土曜に通知 → 人生満足度・気分を 0–10 で入力 → 先月の HP/MP 傾向が自動表示 → Yes/No チェック 3 つ → 完了。
- S5 復帰: 空白期間の後にアプリを開く（または毎月 1 日の「おかえり通知」から）→ 復帰カードが表示 → 今日の 1 行だけ書く → 復帰完了。空白日数の表示・理由入力の要求は行わない。（任意で「きっかけの事実 1 行」欄が畳まれて存在する）
- S6 四半期: 1/4/7/10 月の第 1 週末に通知 → 四半期カード → メタプロセスの手順表示 + 3 ヶ月データの俯瞰 → カード文面・通知設定の編集 → 完了。
3. 機能要件
3.1 日次記録（FR-REC）
| ID |
要件 |
優先度 |
| FR-REC-01 |
HP（1–5）と MP（1–5）を各 1 タップで入力できること。数値の意味の凡例（OQ-01 の 5 段階定義）を選択肢自体に短く併記する |
MUST |
| FR-REC-02 |
味わい（自由テキスト 1 行）を任意入力できること。未入力でも保存でき、未入力を示唆する警告・色・アイコンを出さない |
MUST |
| FR-REC-03 |
保存完了時に短い承認表示（例:「よし」）を出すこと。E2 の祝い手続きの実装。派手な演出は不要、毎回同じでよい |
MUST |
| FR-REC-04 |
任意の自由メモ欄（複数行）を折りたたみ状態で提供すること。開かなければ存在感がないこと（L3-02） |
SHOULD |
| FR-REC-05 |
同日 2 回目の入力は上書きでなく追記（最新値を当日値として採用）とし、「もう記録済みです」等のブロックをしないこと |
SHOULD |
| FR-REC-06 |
過去日の入力・修正が可能であること。ただし UI 上で空白日を埋めることを促さないこと |
SHOULD |
| FR-REC-07 |
記録は端末オフライン状態でも入力・保存でき、オンライン復帰時に同期されること（記録時点の電波状況に依存させない） |
SHOULD |
3.1.1 HP/MP 5 段階ラベル（初期値・確定 DEC-02）
選択肢に併記する凡例の初期値（FR-REC-01 / FR-SET-03 の初期データ）。設計方針: ①本人の語彙（操縦者/被操縦者・縮退運転・外骨格）で書く ②3 を「ふつう」に置き、普通の日が中央に来るようにする ③低レベル側のラベルに「それでいい」という許可を埋め込み、低い数字を選ぶこと自体が自己批判にならないようにする（CON-03）。
HP（被操縦者の体力・気力）— 今、体はどれくらい動きそう?
| 値 |
短ラベル |
併記する補足 |
| 5 |
うずうず |
エネルギーが湧いていて、動きたい |
| 4 |
好調 |
いつもより攻められる |
| 3 |
ふつうに動ける |
通常運転 |
| 2 |
低め |
決まったことをこなせれば十分 |
| 1 |
回復が仕事 |
今日は休むこと自体が任務 |
MP（操縦者の判断余力）— 今、頭はどれくらい決められそう?
| 値 |
短ラベル |
併記する補足 |
| 5 |
冴えている |
設計・見直しに使える余力がある |
| 4 |
余裕あり |
新しい判断もできる |
| 3 |
ふつうに選べる |
通常運転 |
| 2 |
判断は控えめ |
今日はルーチンで回す |
| 1 |
判断しない日 |
外骨格に任せる。それが正解 |
このラベルは本人が編集可能（FR-SET-03）であり、四半期カードでの見直し対象に含める。
3.1.2 記録タイミングの意味論（確定 DEC-03）
日次記録は朝 7:10、目覚ましの直後に行う。これにより:
- HP/MP は「今朝の始動状態」の計測である。振り返り（昨日どうだったか）ではなく計器の読み取り（今日をどのモードで走るか）であり、低い値はその日の縮退運転を正当化する情報として機能する（例: MP2 なら「今日は判断を減らす日」と朝の時点で決まる）。
- 味わい 1 語は昨日の分を書く（朝の時点で「今日の味わい」はまだ存在しないため）。
- 日付境界は暦日どおり（0:00）でよい。就寝前記録で必要だった深夜境界（27 時方式）は不要になった（OQ-W3 解決）。ただし記録時刻を就寝前に変更した場合に備え、境界時刻は設定項目として残す。
3.2 通知（FR-NTF）— 本アプリの心臓部
| ID |
要件 |
優先度 |
| FR-NTF-01 |
日次・週次・月次・四半期・毎月 1 日（おかえり）の定期通知を送れること。実装上の駆動は日次 Cron 1 本への相乗りとする（DEC-05）。別 Cron は作らない |
MUST |
| FR-NTF-09 |
土曜の日次 Cron 発火時に週次入口を提供すること（DEC-07/10）。日次と同じ7時台。通知は1通にまとめて入口を列挙してよい（OQ-M2） |
MUST |
| FR-NTF-10 |
毎月第1土曜の日次 Cron 発火時に月次入口を提供すること（DEC-09）。四半期月（1/4/7/10）の第1土曜は四半期入口も提供すること（DEC-11） |
MUST |
| FR-NTF-02 |
通知文言はランブックカードの文面と連動し、本人が編集可能であること。デフォルト文言は設計書 §5 のカード文面を使う |
MUST |
| FR-NTF-03 |
通知タップで該当フロー（日次入力 / 週次カード等）に直接遷移すること（ホーム画面を経由させない） |
MUST |
| FR-NTF-04 |
「まだ記録していません」「◯日空いています」等の督促・欠損言及の通知を実装しないこと。通知は常に「入口の提供」のみ（L3-05） |
MUST |
| FR-NTF-05 |
記録が無い日があっても通知の文言・頻度・トーンが変化しないこと（何事もなかったように来る） |
MUST |
| FR-NTF-06 |
通知チャネルは多重化すること: 主チャネル（Web Push）+ 副チャネル（メール等）。主チャネルの購読が切れたことをシステムが検知した場合のみ、副チャネルで「通知の再設定の入口」を 1 回だけ送る |
MUST |
| FR-NTF-07 |
通知の送信履歴（送った/失敗した）をシステム側で記録すること。外骨格の駆動源が止まっていたことに、四半期レビューで気づけるようにする |
SHOULD |
| FR-NTF-08 |
おかえり通知（毎月 1 日）は、直近に記録があってもなくても同じ文面で送ること（「動いていれば無視してよい」と文面に含める） |
MUST |
3.3 ランブックカード（FR-CRD）
| ID |
要件 |
優先度 |
| FR-CRD-01 |
週次・月次・四半期・復帰の 4 カードをガイド付きフローとして提供すること。週次の手順初期値は docs/mvp2-mvp3-alignment.md §2.3（DEC-08）、月次・四半期は同 §3 |
MUST |
| FR-CRD-02 |
カードの文面（手順・質問文・[ ] 内の個人設定）を本人が編集できること。編集導線は四半期カードと設定画面からのみ出す（日常の画面に「編集」を見せない） |
MUST |
| FR-CRD-03 |
週次カードに 15 分タイマーを内蔵し、タイマー終了時に「途中保存して終了」を提示すること。途中終了でもそのセッションを完了として記録する |
MUST |
| FR-CRD-04 |
週次カードの冒頭に、今週の HP/MP の一覧と味わい語のリストを自動表示すること（L3-04）。復帰のきっかけ1行があれば併記する |
MUST |
| FR-CRD-05 |
各カードは「HP が低い日の縮退手順」（週次 = 眺めるだけ、または眺め+発見）を内蔵し、冒頭で「フル / 縮退」を選べること |
MUST |
| FR-CRD-06 |
カード完了時、次回の予定（次の通知日時）を 1 行表示すること |
SHOULD |
| FR-CRD-07 |
週次の「発見1行」はスキップ可能であること。環境調整1つは本体とし、空で完了しようとした場合は確認を1回だけ出す（ブロックして責めない。OQ-M3） |
MUST |
| FR-CRD-08 |
週次に協働アクション・成長進捗・満足度スコアを置かないこと（月次/四半期へ分離。DEC-08） |
MUST |
3.4 復帰フロー（FR-CBK）
| ID |
要件 |
優先度 |
| FR-CBK-01 |
最終記録から一定日数（既定 4 日、設定可能）空いた状態でアプリを開いた場合、通常のホームではなく復帰カードを表示すること |
MUST |
| FR-CBK-02 |
復帰カードは「今日の 1 行」の入力だけで完了すること（60 秒以内）。空白期間の日数・期間の明示、理由の必須入力を行わないこと |
MUST |
| FR-CBK-03 |
「きっかけの事実 1 行」欄を折りたたみで提供し、入力された場合は次回の週次カードの手順 3（環境調整）に自動で表示すること（E8 の学習ループの実装） |
SHOULD |
| FR-CBK-04 |
復帰完了時に、通知購読の生存確認を行い、切れていれば再設定を 1 タップで促すこと（復帰カード手順 4 の実装） |
MUST |
| FR-CBK-05 |
復帰イベント（復帰した日付）を記録すること。これが AC-01（復帰できた回数）の計測データとなる。表示は累計回数のみ（「◯回目の脱落」ではなく「復帰 ◯ 回」） |
MUST |
3.5 可視化・集計（FR-VIS）
| ID |
要件 |
優先度 |
| FR-VIS-01 |
月次カード用に、先月の HP/MP の分布・平均を自動集計して表示すること（AC-02） |
MUST |
| FR-VIS-02 |
すべての可視化は積み上げ型（記録があった日の値・累計・リスト）とし、欠損日をグレーアウト・赤字・空白マスで強調する表現を使わないこと。時系列表示は記録がある日だけを詰めて並べる方式を既定とする（L3-03） |
MUST |
| FR-VIS-03 |
味わい語の一覧（ただ並べるだけ）を表示できること。読み返し自体が savoring になる（幸福整理書 W5 月次） |
SHOULD |
| FR-VIS-04 |
四半期カード用に、3 ヶ月分の HP/MP・満足度・気分・復帰回数を 1 画面で俯瞰できること |
SHOULD |
| FR-VIS-05 |
日常のホーム画面にはグラフを常設しないこと。可視化はカードの文脈（週次・月次・四半期）でのみ表示する（PR-1: 見に行かせない） |
SHOULD |
3.6 設定・データ所有（FR-SET / FR-DAT）
| ID |
要件 |
優先度 |
| FR-SET-01 |
初回セットアップウィザードを提供すること: 記録時刻（アンカー）→ 週次曜日・時刻 → 通知許可 → 最初の 1 行入力、の 4 ステップで、設計書 §9 の 30 分セットアップを 10 分以内に短縮する |
MUST |
| FR-SET-02 |
通知時刻・曜日・縮退しきい値（FR-CBK-01 の日数）・カード文面を設定画面から変更できること |
MUST |
| FR-SET-03 |
HP/MP の 5 段階それぞれの意味テキスト（OQ-01）を本人が定義・編集できること |
SHOULD |
| FR-DAT-01 |
全データ（日次ログ・レビュー回答・復帰イベント・カード文面・設定）を JSON および CSV で 1 操作でエクスポートできること（L3-06） |
MUST |
| FR-DAT-02 |
エクスポートに認証以外の前提条件（課金・回数制限・申請）を設けないこと |
MUST |
| FR-DAT-03 |
インポート（エクスポートした JSON の復元）ができること。移行・作り直しの自由を保証する |
SHOULD |
| FR-SEC-01 |
利用者は本人 1 名。認証は単一ユーザーの簡易な方式でよいが、記録は人生ログでありセンシティブなため、URL を知っているだけではアクセスできないこと |
MUST |
4. 画面構成（情報アーキテクチャ）
画面は最小 6 つ。日常的に触るのは①だけであり、②〜⑤は通知経由でのみ到達する（PR-1）。
| # |
画面 |
到達経路 |
内容 |
| ① |
今日の 1 行（ホーム） |
日次通知 / 直接アクセス |
HP 5 択、MP 5 択、味わい 1 行（任意）、保存。折りたたみメモ |
| ② |
週次カード |
週次通知 |
FR-CRD-03/04 のガイド付きフロー |
| ③ |
月次カード |
月次通知 |
S4 のフロー |
| ④ |
四半期カード |
四半期通知 |
S6 のフロー + カード編集 + データ俯瞰 |
| ⑤ |
復帰カード |
条件表示（FR-CBK-01）/ おかえり通知 |
S5 のフロー |
| ⑥ |
設定 |
①の隅の控えめな導線 |
FR-SET 群、エクスポート |
UI 原則（PR-5 の具体化）:
- 全画面で同一の静的レイアウト。モーダル・トースト・バッジ・赤い点を使わない。
- 文言は常に同じ（日替わりの励ましメッセージ等を実装しない。予測可能性が安心である。CON-01）。
- 色数・動きを抑えた低刺激デザイン。ダークモード対応（SHOULD。起床直後の暗い部屋での利用と、疲労時の刺激軽減のため）。
5. データモデル（概念レベル）
| エンティティ |
主な属性 |
備考 |
| DailyLog |
date, hp(1-5), mp(1-5), savor(text?), memo(text?), created_at |
1 日 1 レコード（最新優先）。date はローカルタイムゾーン基準 |
| ReviewSession |
type(weekly/monthly/quarterly), started_at, completed_at, answers(json), degraded(bool) |
途中終了も completed 扱い + degraded フラグ |
| ComebackEvent |
date, gap_trigger_note(text?) |
復帰回数の計測源（FR-CBK-05） |
| CardTemplate |
type(daily-notification/weekly/monthly/quarterly/comeback), body(text), version, updated_at |
文面の編集履歴を残す（M-01 と同型: 過去の自分の設計が一級の記録） |
| Settings |
daily_time, weekly_dow+time, monthly_rule, quarterly_rule, comeback_threshold_days, hp_scale_labels, mp_scale_labels, channels |
|
| NotificationLog |
type, scheduled_at, sent_at, status |
FR-NTF-07 |
- タイムゾーンは本人の生活圏（Asia/Tokyo）固定で開始してよい（NS-06: 一般化しない）。
- 「日付の境界」は既定で暦日どおり（0:00）とする（DEC-03: 朝 7:10 記録のため境界問題は発生しない）。記録時刻を就寝前に変更した場合のために、日替わり境界時刻（例: 27 時 = 午前 3 時）を設定項目として残す。
- Settings の既定値: daily_time = 07:10、hp_scale_labels / mp_scale_labels = §3.1.1 の表。
6. 通知の技術要件と制約（要件レベルで固定する事項）
通知は本システムの単一障害点になり得るため、要件段階で制約を明示する。
| ID |
要件・制約 |
| NT-01 |
主チャネルは Web Push（PWA）とする。iOS では PWA をホーム画面に追加した場合のみ Web Push が利用可能という制約があるため、セットアップウィザード（FR-SET-01）にホーム画面追加の手順を必ず含めること |
| NT-02 |
通知はクライアントを開いていなくても駆動すること（ローカル通知だけに依存しない）。実装は常時稼働プロセスでも、1 日 1 回の外部 Cron（Vercel Cron 等）でもよい。DEC-04 により本番は Vercel Cron を採用（常時稼働プロセス不要） |
| NT-03 |
副チャネルとしてメール通知を実装すること。用途は ①本人が主チャネルにメールを選んだ場合の定期通知 ②Web Push 購読の失効検知時の再設定案内（FR-NTF-06）に限る |
| NT-04 |
補助として、週次・月次・四半期・おかえり日の ICS（カレンダーファイル）を出力できること（SHOULD）。カレンダーは本人の既存の生活インフラであり、アプリ障害時の最後の砦になる |
| NT-05 |
通知許可が拒否/失効している状態をアプリ起動時に検知し、①の画面に静かな 1 行（バッジや警告色を使わない）で再設定導線を出すこと |
7. 非機能要件（NFR）
| ID |
要件 |
| NF-01 |
速度: 通知タップから①画面の操作可能まで 3 秒以内（モバイル回線）。S1 全体で 30 秒以内を実測で満たすこと |
| NF-02 |
可用性: 個人利用のため高可用性は不要。ただし障害・メンテでアプリが開けない場合に備え、記録はオフラインで受け付けて後送できること（FR-REC-07 と同根） |
| NF-03 |
データ保全: 日次の自動バックアップ。人生ログの消失は本システム最大の被害である。四半期カードに「エクスポートを 1 回行う」を手順として含める（人力の最終バックアップ） |
| NF-04 |
プライバシー: 記録内容を第三者サービスの分析・学習に供しないこと。アクセス解析を入れる場合も記録本文を送らないこと |
| NF-05 |
運用コスト: 個人の趣味インフラとして維持できる構成にすること（目安: 無料枠〜月数百円。維持費が「やめる理由」にならないこと） |
| NF-06 |
保守性: 本人が四半期レビューの時間内で文言・設定を変えられること（コード変更なしで CardTemplate と Settings を変更可能に）。コード自体も本人の学習領域（G4）と接続するため、過度に複雑な構成を避ける |
| NF-07 |
アクセシビリティ: タップターゲットは大きく（疲労時の精度低下前提）、必須入力はゼロ〜2 タップ。文字サイズ変更に追従 |
8. 制約由来の UI/文言 禁止事項リスト（実装時のレビュー用チェックリスト)
実装・レビュー時に機械的に検査できる形へ、既存要件を変換したもの。
9. 受け入れ基準（アプリとしての Acceptance Criteria）
| ID |
基準 |
検証方法 |
| TA-01 |
S1（日次）が通知タップから 30 秒以内・タップ 3 回以内で完了する |
実機で計測 |
| TA-02 |
S5（復帰）が 60 秒以内で完了し、空白への言及が画面上に一切ない |
実機 + §8 チェックリスト |
| TA-03 |
通知 5 種が設定時刻に届く。1 週間の試験運用で日次通知の到達率が実用水準（欠落に本人が気づかない程度）である |
NotificationLog と実機で確認 |
| TA-04 |
Web Push を意図的に失効させた場合、副チャネルで再設定案内が 1 回だけ届く |
手動試験 |
| TA-05 |
エクスポートした JSON から全データが復元できる |
ラウンドトリップ試験 |
| TA-06 |
§8 の禁止事項リストが全項目パスする |
レビュー |
| TA-07 |
運用受け入れ（最重要）: MVP-0 リリース後 2 週間、本人の実生活で日次ループが回る（欠損があっても復帰できていれば合格。AC-01 と同基準） |
実運用 |
10. 段階リリース計画（MVP 分割）
「作ること自体が目的化して運用が始まらない」リスク（§0.1）への対策として、各段階は前段階の運用実績を着手条件とする。
| 段階 |
内容 |
含む要件 |
着手条件 |
実装状況 |
| MVP-0 |
日次 1 行 + 日次通知 + 簡易設定 + エクスポート |
FR-REC-01〜03, FR-NTF-01〜05（日次分）, FR-SET-01（短縮版）, FR-DAT-01, NT-01/02/05 |
— |
実装済み |
| MVP-1 |
復帰フロー + おかえり通知 + 副チャネル |
FR-CBK 群, FR-NTF-06/08, NT-03 |
MVP-0 を 2 週間実運用（TA-07） |
実装済み（着手条件を前倒し。理由: コードは書けるが実運用実績は時間経過でしか得られず、機能自体は実運用と並行して先行実装しておいて損はないため） |
| MVP-2 |
週次カード + 週次通知（Cron相乗り）+ 週次集計 |
FR-CRD（週次分）, FR-NTF-09, FR-VIS 週次分。手順は DEC-08 |
すり合わせ済み（docs/mvp2-mvp3-alignment.md） |
実装済み（/weekly、Cron相乗り） |
| MVP-3 |
月次・四半期カード + 可視化 + カード編集 + インポート |
FR-CRD 残り, FR-NTF-10, FR-VIS, FR-DAT-03, DEC-09/11 |
すり合わせ済み。日次ループ実運用と並行して前倒し実装 |
実装済み（/monthly /quarterly、可視化、インポート） |
この順序の意図: 最も頻度が高く・最も壊れやすい日次ループと復帰経路を先に固め、低頻度で高価値のレビュー系を後回しにする。逆順（立派なダッシュボードから作る）は本システムの失敗パターンである。
注記: 着手条件（前段階の実運用実績）は、あくまで「本人がその機能を本当に必要とするか」を実運用で確かめてから作る、という無駄な実装を避けるためのガードだった。MVP-1 はガードを外れて先行実装したが、これは「実運用実績が貯まるのを待つ理由がコード実装側には無い（実運用は時間経過でしか進まない）」という判断による例外であり、MVP-2/3 についても同様の理由があれば前倒しを検討してよい。ただし §0.1 の本質的リスク（作ること自体の目的化）は変わらないため、日次ループ自体の実運用検証（TA-07）は引き続き優先する。
11. 技術方針（確定: DEC-04）
| 層 |
選択 |
理由 |
| ホスティング |
Vercel Hobby（無料） |
Next.js と相性が良く、HTTPS 自動、Cron 付き。常時稼働プロセス不要 |
| Cron |
Vercel Cron（1日1回、10 22 * * * = 07:10 JST 狙い） |
Hobby は ±59 分精度。本人合意により十分（DEC-04） |
| DB |
Turso（libSQL、無料枠） |
SQLite 互換で Prisma のマイグレーションを流用できる。サーバーレスでも消えない |
| Push |
Web Push（VAPID） |
変更なし |
| 認証 |
単一パスワード（iron-session） |
変更なし |
| ローカル開発 |
SQLite ファイル（prisma/dev.db） |
TURSO_* 未設定時は従来どおり。worker.ts はローカル検証用の任意オプション |
12. 未決事項
- ~~OQ-W1: HP/MP 5 段階のラベル文言の初期値~~ → 解決（DEC-02）: §3.1.1 で確定。
- ~~OQ-W2: 日次通知の既定時刻とアンカー~~ → 解決（DEC-03）: 毎朝 7:10、アンカーは目覚まし。
- ~~OQ-W3: 日替わり境界時刻の既定値~~ → 解決（DEC-03 の帰結）: 朝記録のため暦日どおり（0:00）。境界時刻は設定項目として残す。
- OQ-W4: 副チャネルのメールアドレス / 送信元ドメインの用意（任意。SMTP 未設定でもアプリは動く）
- ~~OQ-W5: ホスティング先・ドメイン~~ → 解決（DEC-04）: Vercel Hobby + Turso。ドメインは
*.vercel.app のままで開始してよい。
- OQ-W6: 復帰しきい値（FR-CBK-01）の既定 4 日は適切か（出張・繁忙の通常パターンと衝突しないか。CON-04）
改訂履歴
| 版 |
内容 |
| v0.1 |
初版。継続機構設計書の外骨格を Web アプリ + 通知で実装するための要件を定義。決定 DEC-01（ツール化前倒し）を記録し、MVP-0〜3 の段階リリース計画と着手条件を設定 |
| v0.2 |
DEC-02（HP/MP ラベル文言の確定、§3.1.1）と DEC-03（日次通知 7:10・目覚ましアンカー・朝記録の意味論、§3.1.2）を反映。OQ-W1〜W3 を解決。これで MVP-0 の実装着手に必要な決定はすべて揃った |
| v0.3 |
MVP-0 を実装（webapp/ ディレクトリ、Next.js + Prisma/SQLite + Web Push）。TA-01〜TA-06 は本リポジトリ内で確認済み。TA-07（2 週間の実運用実績）は未実施。実装詳細・セットアップ手順は webapp/README.md を参照 |
| v0.4 |
MVP-1 を実装: 復帰フロー（FR-CBK-01〜05、ComebackCard）、おかえり通知（FR-NTF-08、毎月1日）、メール副チャネル（NT-03、SMTP 未設定時は no-op）。復帰回数の積み上げ表示（FR-CBK-05）を設定画面に追加 |
| v0.5 |
DEC-04: 本番を Vercel Hobby + Turso + Vercel Cron に確定。常時稼働プロセスを不要化。/api/cron/tick（CRON_SECRET 保護）と Turso アダプタ、scripts/migrate-turso.mjs を追加。Hobby Cron の ±59 分精度を本人合意として記録 |
| v0.6 |
DEC-05〜11: MVP-2/3 すり合わせを docs/mvp2-mvp3-alignment.md に固定。週次=点検+発見1行、Cron相乗り、月次=両方薄く、四半期=6手順必須。FR-NTF-09/10, FR-CRD-07/08 を追加 |
| v0.7 |
MVP-2/3 を実装: 週次/月次/四半期カード、Cron相乗り通知、積み上げ可視化、JSONインポート、weeklyDow 設定。ReviewSession を本格利用 |
| v0.8 |
概念リテラシー: G1〜G8・主活動・四半期のアプリ内説明、オンボーディングに「この期の置き方」、ホームの薄い意識づけ（既存ユーザーは後追いセットアップ） |