訓練決定由資料支持，而資料仍由你控制
Pacevera is a Fitness Decision Engine, not a fitness data connector and not an AI coach.
Pacevera 是一個訓練決策引擎：把你今天原本排定的訓練，和當下的身體證據放在一起，產生一個看得懂、追得回理由的決策。
你繼續使用熟悉的 AI；資料留在你的控制範圍，Pacevera 只負責把目前狀態轉成今天能執行的調整。
這份文件講的是這個產品是什麼、往哪裡走——給利害關係人與一般觀眾看的方向。三種部署形態、五層決策、證據語彙與出處治理，是同一個方向的四個切面。
「你昨天練得重，今天建議做 Zone 2 輕鬆跑。」
「今天原定做高強度間歇，建議調低強度。」
這也是與一般健身工具的根本差異：它們通常直接回覆建議；Pacevera 會先檢查資料與原定課表，再決定今天是否需要調整。
我們要解決的問題
每個新對話都可能重新開始：昨晚睡了多少、這幾週累積了多少負荷、今天原本排了什麼，都要靠你再次交代。問題不是缺少另一個儀表板，而是今天的課表要不要照做，以及如果不照做要改成什麼。
「今天輕鬆跑」聽起來合理，但它沒有回答：原本排的是什麼？哪個訊號改變了答案？
穿戴資料與儀表板可以告訴你發生了什麼，卻不一定能把它轉成具體、可以照做的課表調整。
你需要的是能使用證據的決策層，不是再交出一份長期健康資料庫。
把一個訓練決定說清楚
同一個人、同一天；差別不是 AI 換了一句話，而是今天的資料改變了原定訓練。
為什麼：準備程度只有 48，近期資料也顯示恢復不足。輸出同時標示依據、信心與缺少的訊號，不把不確定性藏起來。
資料如何進入決策
決策鏈要能開始，證據得先進到「今天該練什麼」那句對話裡——而這段路上的每一步，不是每一步都由我們走。而且同一條路在桌機與手機上長得不一樣：桌機今天就走得通，手機還沒有。誰負責哪一步，決定了哪一種形態先能出貨。
| 步驟 | 做的人 | 桌機（今天） | 手機 |
|---|---|---|---|
| 開 Claude 對話 | Anthropic | ✓ 已存在 | ✓ 已存在 |
| Claude 連上 Pacevera | 我們 | ✓ 桌面版擴充功能 v0.5.1（本機連線） | — 手機目前只有遠端入口，尚未完成 |
| 取得 Apple Health／Garmin 資料 | AI 使用的應用程式權限與各家授權 | — 不在我們手上（今天走匯出檔或口述） | — 不在我們手上 |
| 資料送進決策工具 | 我們 訓練資料格式 | ✓ 已完成 | ✓ 同一份實作 |
| 五層決策 | 我們 訓練決策引擎 | ✓ 已完成，見下 | ✓ 同一份實作 |
v0.5.1 目前可用的資料來源是匯出檔、使用者口述、使用者日誌，或由 AI 整理後送進工具的資料；Pacevera 不保存 Apple／Garmin 的登入憑證。未來由使用者授權自己的本機連接器或私人入口，AI 每次只取得回答當前問題所需的最少資料與結果。完整健康歷史與登入憑證不應由每個 AI 服務各自保存。
遠端連線完成後，Apple Health 與 Garmin 的資料也不會自動出現。下一步要先建立本機私人引擎，定義連線權限、登入憑證保存、訓練紀錄保存與刪除方式，再談手機入口。遠端連線解決的是接觸面，不是資料主權。今天可用的匯出檔、使用者口述與使用者日誌，未來接上連接器後仍然有效。
先服務誰
Pacevera 的第一批使用者不是泛用健身大眾，而是已經在使用 AI、手上有 Apple Health、Garmin 或相近穿戴資料，卻不願再把資料搬進另一個平台的認真訓練者。他們最先要解決的不是「再看一個儀表板」，而是今天原本的課表要不要照做。
「我今天該照課表做嗎？如果不該，具體改成什麼？」
Pacevera 不是健康資料儀表板，也不是另一個 AI 教練。
三種使用形態
底下的決策鏈在三種形態裡是同一份實作，差別只在它跑在誰的機器上、證據怎麼進來、誰付錢。這不是三個階段，是三種使用者處境——遠端服務上線不會取代桌面版；由使用者控制的私人部署，也不是遠端服務的下一版。
形態 1 · 本機桌面版
跑在使用者自己的電腦上 · 今天就能使用
今天就能裝的那一個。使用者在 Claude Desktop 安裝一顆 .mcpb，走 stdio，整個決策計算發生在他自己的機器上。證據來自他手上的匯出檔，或他自己說的話——由 Claude 整理成參數傳進來。
✓ 可用
公開預覽 · 已有本機安裝方式可供評估
形態 2 · 使用者控制的私人環境
跑在使用者、教練或機構自己控制的環境
連接器、資料、長期紀錄、訓練計畫、決策引擎與規則都留在使用者控制的環境。這個形態讓「換模型不歸零」與資料不離開你的控制範圍同時成立，也是未來教練、隊伍與企業部署的地基。
第二階段 · 進行中
本機匯入與當日決策已可運作；待建：durable 紀錄的備份／匯出／刪除 · 連線權限 · 私人環境驗收
形態 3 · 遠端服務
手機連回私人引擎，或使用只處理當次問題的遠端服務
手機先以受控方式連回使用者或機構的私人引擎。若未來提供 Pacevera 遠端服務，只能承諾最少資料、只處理當次問題、不保存完整歷史；不能把它描述成「資料不離開你的電腦」。
第三階段 · 目前暫停
授權 · HTTPS · 資料遮蔽 · 隱私政策 · 端到端測試與付費需求全部成立才上線
形態 1 與形態 2 都把計算放在使用者控制的環境；形態 3 可能只是通往私人引擎的受控入口，也可能是只處理當次問題的遠端服務。兩條資料流必須在使用者連線前清楚標示，不能共用同一句隱私承諾。
安裝與試用
形態 1 今天就能安裝。整段安裝沒有帳號、沒有 API 金鑰、沒有任何設定欄位——因為 Pacevera 不去拿你的資料，就沒有東西需要授權。
pacevera.mcpb從 發布頁 取得。單一檔案，內含可直接執行的服務與整份規則庫。
v0.5.1 · sha256 5c400ac45c5204e5d495be5b89f703bce91615252fbd144e53aabbf67252ddc5
shasum -a 256 pacevera.mcpb，比對 官方 MCP registry 上該版本的 fileSha256——那串指紋存在一個我們不能單方面改寫的地方。我們仍對發布檔負責；Registry 的 fileSha256 則提供一個可獨立核對的外部指紋。而且 v0.1.0 起的每一版都保留不覆蓋，先前驗過的那顆今天仍然驗得過。
拖進去就好。沒有設定畫面——這個擴充功能沒有宣告任何 user_config 欄位，因為它不需要知道你是誰。
裝好立刻有 11 個工具可用：7 個決策工具、3 個佐證工具（證據涵蓋、決策說明、結果回報），加上一個當日預覽。不需要先匯入資料：你自己講的話就是有效資料，匯出檔也是。下一節有六則可以整段複製的問法。
Node 22.5 以上另有一個本機計畫決策工具；低於該版本時它不會出現，其餘工具照常運作。
也在官方 MCP registry 上架，識別碼 io.github.henryyeh182/evidra。Anthropic 的 MCPB 目錄審查中。這裡介紹的是本機桌面版公開預覽；本機私人引擎的資料生命週期、遠端連接器與帳號能力都還沒完成，不在這份預覽的承諾範圍內。
實際試問
裝好之後貼上去就會跑。底下每一則的輸出都是引擎實際產生的，並且由測試釘住——這份頁面寫的數字若和程式不一致，測試會紅。證據樣本與完整輸出在 examples/README.md。六則走完 keep、adjust、advance、substitute、defer 五種型別；第 2 與第 3 則同樣是 adjust，放在一起是因為觸發它們的證據完全不同。
01 · 零設定，只用嘴巴講
我昨天跑了 80 分鐘，感覺蠻累的，昨晚睡了 6 小時。今天課表排的是 VO₂max 間歇 60 分鐘，我還該照做嗎？
重點是它沒有改課表。 keep 也是決策——「檢查過了，可以執行」，不是「沒事發生」。而且它老實說信心低：四個恢復訊號只有睡眠一個。一句「今天照練」配上「我只看得到這些」，才是完整的答案。
02 · 只有 Strava——零恢復訊號
這是我最近四週的 Strava 訓練紀錄（附檔）。今天排的是 Threshold Repeats 60 分鐘高強度，該照跑嗎？
Strava 不量 HRV、不量睡眠。它有的是每一場訓練的負荷——這樣就足以做出決策。再追問「1.4 是誰定的」，會拿到 Gabbett 2016、同時載入的反對意見，以及一句「1.4 兩個發表數字都不是，是我們挑的」。
03 · 只有 Garmin——廠商複合分數當一等證據
這是我今天的 Garmin 數據（附檔）。今天排 Tempo Run 50 分鐘高強度。
和第 2 則對照著看：同樣是 adjust、同樣降一級，理由卻完全不同（負荷爬太快，或是今天恢復不良），而且這次信心是高。Body Battery 是 Garmin 自己算的分數，Pacevera 不重算它——錶在手腕上，它整合了我們看不到的訊號。
04 · 只有 Oura——沒有訓練負荷，一樣做得出決策
這是我今天的 Oura 數據（附檔）。今天排了低強度的間歇 60 分鐘，我感覺很好，可以加強度嗎？
這則是往上調，不是往下。 決策不是只會叫你少練——證據支持就往上加。信心仍然低，因為 Oura 不算訓練負荷、所以我們也不算：拿時長乘強度標籤湊一個數字很容易，而那條曲線之後會變成一句「今天減量」。
05 · 傷病替代——硬過濾，不是建議
我膝蓋不舒服，今天的深蹲能換成什麼？我有槓鈴、深蹲架跟啞鈴。
回傳的理由裡有一句 “Movements contraindicated for knee were hard-filtered out: Front Squat.” Front Squat 器材齊備、動作模式也對，唯一的問題是它在目錄裡帶著 knee 這個禁忌標籤——所以它不是被扣分排到後面，是根本沒有進候選名單。器材列到深蹲架是有意的：Front Squat 要槓鈴加深蹲架，少一樣它就會先被器材篩掉，那一次替代就成了器材問題而不是傷病問題。器材不缺，剩下的理由才只有膝蓋，而被剔除的那一個會被指名寫出來。模型可以被說服繞過安全規則，確定性的過濾器不會。
06 · 只有 Whoop——把課表拿走，不是調軟
這是我今天的 Whoop 數據（附檔）。今天排的是 VO₂max 間歇 60 分鐘高強度，我還是照做嗎？
這則和前面五則的差別在「改了什麼」。 前面最多動兩三個欄位；這一則 focus、type、durationMinutes、intensity、exercises 五個全動，連做什麼動作都換掉。adjust 是把課表調軟，defer 是把課表拿走換成別的——兩者是不同的決策型別，不是程度差異。而且信心是高：Whoop 不量壓力，那一格缺著，但四個恢復訊號有三個加上廠商自己的 recovery 分數都在——證據足夠時它照樣敢把一整堂高強度課取消。
第 1 則沒有附任何檔案，第 5 則也沒有。「先匯入資料」不是使用 Pacevera 的前提——問「今天練什麼」而手上沒有課表時，它會回這是「請給我建議」的問題，不是「請調整既有課表」的決定。
並且不編一個出來。引擎自己講得出這條界線在哪。
完整決策流程
產品終局包含資料、健康狀態、決策引擎、規則、可解釋的理由與持續學習與使用入口六個責任；對使用者可見的一次使用，則濃縮成下面五層，且不可跳層。以下走完一次真實的判定——一位半馬訓練者，昨天跑了 80 分鐘 RPE 8，今天排定 VO₂max 間歇。
目前的資料由工具接收，Pacevera 不保存來源服務的登入憑證。未來本機私人引擎會讓使用者直接授權自己的連接器，保存可重新計算的紀錄，再只把當次所需結果交給 AI。兩種路徑都不要求 Pacevera 建立集中健康資料庫。
個人基線取代族群平均。這位使用者的 HRV 中位數是 48——用教科書的 52 當基準，他每天都會被判成恢復不良。
恢復分數只用當下夠新的訊號計算，權重在有效訊號之間重新正規化——缺的不用中性值填補，而是列進 signalCoverage.recovery.missing 或 signalCoverage.training.missing 並下調信心。
這位使用者不戴錶睡覺，睡眠訊號永遠是空的。系統照樣做得出決策，並在輸出裡寫明「缺少 sleep、stress，信心下調」——不會把沒量到當成睡得好。
決定是要達成的方向（降低今天強度）；今日執行是具體變更（從原定訓練到今天怎麼做）。分開的理由：同一個意圖，在不同器材、時間、傷病下會落成不同的 Action。
決策型別有五種：keep（照原定執行，也是決策）· adjust · substitute · defer · advance。規則各自提出降幅、取最大值，所以順序不影響結果，每條觸發的規則都留下理由。
每條理由都指得回具體訊號值。這份紀錄離開 Pacevera 之後仍然看得懂——三個月後回頭查「那天為什麼把強度降下來」，答案還在。
決策升級
決策型別不是固定的——它跟著證據走。同一位使用者隔天再問一次：昨天那場 95 分鐘 RPE 9 之後，HRV 掉到 33（個人基線 48）、Body Battery 只剩 24。這次引擎不是調降強度，而是把整堂課換掉。
7 / 27 準備程度 50
7 / 28 準備程度 25
換課就要連動作一起換。 若只改標題而留著原本的 Tempo Run，這份紀錄會自相矛盾——使用者看到「恢復課表」卻配著「節奏跑」。換上的是徒手、低衝擊的動作，因為準備程度低的日子往往伴隨關節限制。
五種決策型別都是決策，包含 keep——照原定執行同樣要附上證據，不是「沒事發生」而是「檢查過了，可以執行」。
把不同來源的資料整理成同一套說法
Garmin 叫 sleepTimeSeconds，Apple 發 HKCategoryTypeIdentifierSleepAnalysis 區間，Google 的匯出檔把本地午夜寫成 UTC，Strava 的 CSV 有五組同名欄位、單位各不相同，WHOOP 的訓練負荷是自家的 0–21 分。這些方言不該有任何一個抵達決策規則。新增一家＝加一張映射表，下游一行不動。
| Canonical signal | Apple | Garmin | Strava | Oura | WHOOP | |
|---|---|---|---|---|---|---|
| sleep_duration_hours | ✓ | ✓ | ✓ | — | ✓ | ✓ |
| hrv_ms | ✓ | ✓ | — | — | ✓ | ✓ |
| resting_hr_bpm | ✓ | ✓ | ✓ | — | ✓ | ✓ |
| vendor_readiness | — | ✓ | — | — | ✓ | ✓ |
| body_battery | — | ✓ | — | — | — | — |
| 每場訓練的負荷 | ✓ | ✓ | ✓ | ✓ | — | ✓ |
廠商自己算好的複合分數（準備程度、Body Battery、WHOOP strain）當作重要資料收進來，不忽略重算——裝置在手腕上，它整合了我們看不到的訊號。
最後一列的那個「—」值得看一眼：Oura 不算訓練負荷，所以我們也不算。拿時長乘上強度標籤湊一個數字出來很容易，而且沒有人看得出來——但那條負荷曲線之後會變成 ACWR、變成疲勞、變成一句「今天減量」。沒量到就是沒量到：那場訓練列進 signalCoverage.training.missing，不計入疲勞，信心跟著下調。
六家都有解析器了，但成熟度要分兩種講。 Apple、Garmin、Google、Strava 是照真實匯出檔寫的——哨兵值、空陣列、欄位缺漏這些事，都是在真檔案上才發現的。Oura 與 WHOOP 是照兩家自己的 OpenAPI 文件寫的（2026-08-07），還沒對過任何一份真實回應：規格說得對，不等於實際回傳長那樣。把「已經設計好」與「已經驗過」分開講，是這個產品該有的樣子：表上多一個勾很容易，收回來很難。
每支錶有它原生的主力 App——Apple Watch 對 Apple Health、Garmin 對 Garmin Connect、Pixel Watch 對 Google Health。其餘都是同步副本。而 Apple Health 與 Google Health 既是來源也是目的地：別家的 App 同樣往裡面寫。所以「這筆資料來自 Apple Health」講的是它從哪匯出，不是誰量的。
只看「有沒有 HRV」，會得到「有」——然後把課表建在一個這個人早就不再產生的訊號上。所以每一筆讀數都帶著誰寫的與最後一次是什麼時候，一路送到工具輸出。這也讓「缺」分得出種類：Garmin 的 HRV 欄位整整 330 天都回同一個哨兵值，不是因為錶測不了，是因為要連續戴著入睡才會建立——而那份匯出裡有效睡眠只有 4 天。「你的錶做不到」是死路，「連續戴著睡就會有」是可以行動的；會回報訊號缺的系統，該說得出是哪一種。
每一組來源都能產出決策，差別在用什麼證據做，不在夠不夠格。系統對缺漏的處理是把權重在有效訊號之間重新正規化，並如實回報信心——不是等湊齊了才開始工作。
| 使用者手上有的 | 決策依據 | 能做出的決策 |
|---|---|---|
| 只有 Strava | 訓練負荷 ATL / CTL / TSB | 依負荷曲線調整強度與量 |
| 只有 Apple Watch | HRV · 靜息心率 · 活動 | 依恢復訊號與肌群疲勞調整 |
| 只有 Garmin | Body Battery · recovery time · 負荷 | 依廠商複合分數與負荷調整 |
| 只有 Oura | 睡眠 · HRV · 靜息心率 · 準備程度 | 依恢復狀態調整（無負荷曲線） |
| 只有 WHOOP | 恢復訊號 ＋ 每場 strain | 恢復與負荷兩側都有 |
| Garmin ＋ Apple Health | 上述全部 ＋ HRV | 同樣的決策，信心更高 |
多接一家不會讓決策從「做不到」變成「做得到」，只會讓同一個決策的信心提高。這也是為什麼產品的價值不以連接器數量衡量。
資料與規則出處
決策靠的是門檻：準備程度低於 60 就降低強度，ACWR 高過 1.4 就減少訓練量。真正的問題是那些數字是誰決定的。Pacevera 把每一條門檻連同它的出處存成資料，決策回傳時一併帶出來——包括「這個數字沒有出處」這件事本身。
EVD-R-006 外部定義的量
原文寫的是 0.8–1.3 為 sweet spot、≥1.5 才是 danger zone。1.4 兩個都不是，它是我們挑的——這句話就寫在規則自己的限制欄位裡。引用 Gabbett 卻不引用批評他的人，才是會被查出來的破綻。
EVD-R-002 我們自己組的分數
readiness 是我們用自己挑的權重組出來的分數。沒有任何一篇研究用過這個分數，所以它的門檻永遠不可能有出處。空的 sources 是誠實的狀態，不是還沒填完。
十二條規則裡有十條是後者。規則庫載入時會結構性擋下「在自創分數的門檻上掛真實論文」這個動作——不是寫在規範裡靠人自律，是掛了就啟動失敗。把一篇真論文貼到一個自己發明的數字上，是這種產品能犯的最嚴重的錯。
這個欄位是強制的，理由很直接：到目前為止每一筆引用都與門檻有落差，落差要寫出來，不能等讀的人自己發現。每筆引用另外必須帶一個「讀到什麼程度」的標記，值不合法或漏填都會讓規則庫載入失敗。
primary_full_text_verified 數字是在原文裡讀到的abstract_verified_full_text_not_read 書目與引句對過摘要，本文沒讀abstract_verified_full_text_paywalled 同上，且本文在付費牆後numbers_from_secondary_sources 數字來自二手摘要，尚未確認citation_not_read_in_full 舊值，新引用不再使用unverified 沒有人查過這筆引用以下記錄這次覆核實際改變了什麼，以及驗證機制抓到的問題。
2026-08-07 覆核了三條規則的出處，結果是一升兩降：Gabbett 那條對到開放原文，升級；另一條原本寫著「VO₂max 兩到三週掉 4–7%」，查下去兩份摘要都沒有這個數字、原文在付費牆後，整段撤掉而不是換句話寫。覆核會撤回東西，那正是它有在運作的證據。
同一天把這個欄位改成強制之後，立刻翻出一筆從來沒有人查證過的引用——它躲過了那次覆核，而在欄位還是選填的時候，「沒查過」與「沒東西好講」在輸出上長得一模一樣。它現在標著 unverified，並且寫進那條規則的限制欄位裡。一個機制的價值，看它有沒有抓到自己人。
2026-08-08 又一次。這個欄位原本只強制 sources 與 supportingLiterature，反對意見那一欄是刻意豁免的——理由寫在規則庫自己的說明裡：反對意見不是我們主張的東西。但它仍然是「某篇論文主張了什麼」的宣稱，而讀的人不會分。豁免收掉的當下，EVD-R-006 那兩筆反對意見一筆都沒過：一筆有三個子句，其中一句摘要裡沒有、也追不到那篇；另一筆連標題都沒有、對不到單一文獻，而且它是一篇 editorial、根本沒有摘要——所以「兩筆都取自已發表摘要」這句話，對後者從一開始就是假的。兩筆都下修，撤掉的原文留在各自的驗證區塊裡，不是靜靜刪掉。同一個形狀的錯，第二次被同一個機制抓到。
這些變更背後的原則，是讓「已經做出決策」與「只是查詢狀態」保持可區分，並讓每個決策都能回到相同的證據鏈。
v0.4.0 起，決策依據已經不是單一工具專用的欄位。會做決策的四條路徑——今天課表決策、產生計畫、預覽／提交計畫變更、動作替代——都會回傳同一種可追溯理由：哪條規則生效、由哪個引擎處理、引用與限制在哪裡。只查詢目前狀態的工具不帶這項理由，因為它還沒有把原定課表改成今天的執行方案。已經做好與還沒做好分開講，這條紀律現在也套到每一項工具上。對外版本資訊固定顯示產品、決策引擎與目前啟用的規則版本；舊 libraryVersion 只作相容欄位，不再獨立進版。
版本保證
改動計畫走兩階段：先預覽差異與版本憑證，沒有有效憑證的確認動作一律拒絕；preview 之後計畫若已變動，commit 會因版本不符而失敗，而不是覆蓋掉別的改動。
模型可以被說服、被繞過；確定性的檢查不會。傷病禁忌也是同一類保證——它是硬過濾，不是給模型參考的建議。同樣的紀律也套在發布上：下載者可以計算 pacevera.mcpb 的 SHA-256，和官方 MCP registry 上該版本的 fileSha256 比對；那串指紋存在一個我們不能單方面改寫的地方。我們仍對發布檔負責；Registry 的 fileSha256 則提供一個可獨立核對的外部指紋。v0.1.0 起的每一版也都保留不覆蓋，先前驗過的那顆今天仍然驗得過。
往哪裡走
AI 沒有這個人的 HRV、睡眠、42 天訓練史。除非經過授權層，它永遠拿不到。
它知道 CTL 的公式，但沒有資料、也沒有執行那條 42 天的縱向運算。
模型可以被說服繞過安全規則；確定性過濾器不會。傷病硬過濾與兩階段寫入都屬此類。
每筆讀數帶著誰寫的、最後一次是什麼時候。它分得出「這個訊號還在」與「這個訊號兩年前就停了」——而那兩件事在原始資料裡長得一模一樣。
每條門檻連著它的出處，沒有出處的會被標成沒有出處，程式擋著不讓它假裝有。GPT-6 講得出運動科學，講不出「這個數字是誰定的、第幾版、誰反對過」。
近期先把已完成能力發成公開預覽，再用 pacevera.com 驗證誰真的需要它；之後才把同一顆引擎擴成完整的私人資料環境、手機入口與團隊治理。
桌面版公開預覽已發布；接著完成 pacevera.com：展示真實訓練變更、三種隱私模式、版本透明、安裝入口與 3–5 位目標使用者訪談。
本機匯入與當日決策已可運作；還要完成 durable 紀錄的備份／匯出／刪除、連線權限、資料連續性與隱私驗收，讓換模型不歸零成為可見能力。
先做受控的私人連線，再依上線條件決定是否提供遠端服務；最後加入團隊權限、私有部署、系統介面與團隊試用。
今天走得通的資料路徑仍是匯出檔、使用者口述與使用者日誌。Oura／WHOOP 解析器尚未對過真實回應；遠端連接器與手機入口都是未來能力。產品頁只說已驗證的事，下一步不當成現成功能。
Pacevera
Which rule fired, which values triggered it, what was missing, and which version of the engine and rule library produced it.
Install for Claude Desktop
本頁決策鏈的數值皆為引擎實際輸出，非示意：準備程度 50、腿部疲勞 92、CTL 33.8 / ATL 34.6 / TSB −5.8、ACWR 1.02、HRV 個人基線 48（40 筆樣本）。決策為 adjust / reduce_today_intensity，執行方式為高強度間歇 60 分鐘，強度由高調低。
這份文件的角色：對外敘事正本，同時是未來產品頁的原型——講產品是什麼、往哪裡走、怎麼裝、怎麼試、為什麼難被取代。工程面的內容在 docs/fitness-mcp-implementation-plan.md，不重複寫在這裡；兩份衝突時，以那份的現況表為準。
對照日期 2026-08-14。本頁是給利害關係人與一般觀眾看的產品說明與使用旅程原型；公開預覽的安裝入口仍以實際發布狀態為準。本機私人引擎的資料生命週期、遠端服務與帳號能力都必須等各自的發布與隱私檢查完成後才能對外宣稱。可複製的示範問題與資料範例在 examples/README.md，每一則的輸出都由測試釘住。產品策略與下一階段的取捨見 docs/pacevera-product-strategy.md；本頁是未來 pacevera.com 網站的敘事原型，不是工程執行清單。