核心原則

服務頁教材合約的責任是把「某個服務是什麼」寫成「讀者能學會什麼」。服務頁可以討論 PostgreSQL、SQLite、MongoDB、Redis、Kafka、Kubernetes、Okta 或 k6，但文章目標應是教讀者理解該服務承擔的系統責任、服務對象、操作語意、失敗訊號與替代邊界。

服務頁教材合約把 vendor profile 升級成可教學的單篇文章。Vendor profile 描述功能、價格、適用場景與競品；服務頁教材還要讓讀者取得一個可遷移的心智模型，讀完後能把同一套判讀方式帶到相鄰服務。

這份合約約束的是教學功能，不約束章節模板。Go 目錄提供的是討論細節、漸進教學、操作判讀與邊界意識的成熟度參照；Backend 服務頁要達到同等教學深度，但 SQLite、MongoDB、PostgreSQL、Redis、Kafka 或 Okta 的章節順序可以完全不同。

WARP 分析摘要

面向內容
Anchor這次決策錨點從「服務清單是否完整」上移到「Backend 服務頁是否已達教材層級」。
Step 0現有資料足以判斷：Backend vendor index 已完整，但服務頁正文成熟度不均；Go 目錄提供單篇教材成熟度參照。
Widen選項有三種：統一章節模板、完全自由撰寫、定義教學功能合約。第三種能保護教學深度，也能保留服務差異。
Reality Test抽樣 Redis、Kafka、Kubernetes、Okta 接近成熟教材；PostgreSQL、SQLite、MongoDB、k6 需要依服務對象重設教學路線。
Prepare若缺少合約就批量補正文，服務頁容易回到產品介紹、選型摘要或容量分析，教學完整度會持續漂移。

反向驗證：章節統一會傷害服務頁。Go 目錄的價值是提供成熟教材的功能檢查，Backend 服務頁仍依自己的服務責任、讀者對象、案例壓力與操作比例安排標題。

情境

Backend 已完成總體教學設計、checkout episode map、vendor index audit 與各分類服務順序同步。下一步評估時，讀者提出更高標準：每個服務的探討內容與教學量級，應接近一篇成熟技術教材，讓選型摘要與 vendor backlog 成為教材材料。

這個標準指向教學深度，而不是統一章節。SQLite 服務的讀者可能在意 embedded state、local-first、測試資料與低操作成本；MongoDB 服務的讀者可能在意 document shape、schema governance、index 與 transaction boundary。兩篇都要達到成熟教材深度，但學習路線應由服務對象決定。

這個提醒揭露了三種不同完成度：

完成度訊號風險
索引完成服務存在於 vendors/_index.md，有類型與撰寫批次只證明有入口，尚未形成教材
大綱完成服務頁有定位、目標、操作、進階、排錯、案例與路由骨架可以開寫，但仍需檢查段落深度
教材完成每段能教讀者判讀服務責任、操作訊號、替代邊界與失敗模式可作為長期教材單篇交付

服務頁若只停在第一層，讀者會看到很多服務名稱；若能到第三層，讀者會理解服務能力如何在 production system 中承擔責任。

服務頁教材功能合約

教學功能先於章節格式

服務頁教材合約約束的是功能而不是格式。成熟服務頁要具備學習目標、核心概念、操作形狀、判讀訊號、替代邊界、案例回寫與下一步路由；這些功能可以出現在不同標題、不同順序與不同敘事密度中。

教學功能可變形態
學習目標可以是「本章目標」、開場學習成果、或讀法段
核心概念可以是服務定位、服務對象、資料形狀、流量形狀或控制面責任
操作形狀可以是 CLI / API、schema 設計、工作流、平台操作或治理流程
判讀訊號可以是 metrics、logs、query、事件、audit trail、cost signal 或人工流程訊號
替代邊界可以是同類服務比較、相鄰分類路由、或規模 / 組織能力分界
案例回寫可以是公開案例、反例、規模對照或 checkout episode

章節名稱要服務該服務的學習路線。SQLite 可以先談「正式狀態能否在單機成立」，MongoDB 可以先談「document shape 與 schema governance」，PostgreSQL 可以先談「SQL baseline 與 transaction」，這三篇不應被壓成同一套段落順序。

學習目標要先於服務介紹

服務頁開頭要先說讀者讀完後能做什麼判斷。產品名稱與服務定位很重要，但學習目標決定文章是否是教材。

成熟服務頁至少要回答：

  • 讀者能辨識這個服務承擔哪類 backend 責任。
  • 讀者能知道這個服務解哪種壓力，承擔哪種操作成本。
  • 讀者能用訊號判斷服務健康、退化或失配。
  • 讀者能知道何時改走相鄰服務。

概念段要建立服務專屬心智模型

概念段的責任是建立讀者能帶走的模型。Redis 頁不只教 Redis command，還要教「可重建副本如何保護 origin」；Kafka 頁不只教 topic，還要教「event log、consumer progress 與 replay window」；Kubernetes 頁不只教 YAML，還要教「workload lifecycle、readiness、traffic 與 rollback contract」。

服務專屬心智模型要貼近服務對象。SQLite 面向小型正式狀態、local data、edge 與測試資料；MongoDB 面向 document model、聚合查詢、索引與 schema governance；PostgreSQL 面向 SQL baseline、transaction、query boundary 與 schema evolution。三者同屬 database，教學路線仍可完全不同。

操作段要服務判讀

操作段的責任是讓讀者理解日常決策形狀。指令、設定、console 或 CLI 範例可以存在，但每個例子都要回到訊號、風險或下一步判斷。

較穩定的操作段功能包含：

操作面教學責任
最短判讀路徑讓讀者快速判斷是否該考慮這個服務
日常操作形狀說明服務平常怎麼被維護、監控與調整
失敗快速判讀說明異常發生時先看哪些訊號
Evidence route說明哪些結果要交給 observability / gate

替代邊界要讓服務回到能力地圖

服務頁要寫「何時改走其他服務」。這段把服務放回能力地圖：正式狀態回 database、可重建副本回 cache、durable replay 回 queue、traffic lifecycle 回 deployment、release evidence 回 reliability、identity control 回 security、協作交接回 incident。

案例回寫要提供情境壓力

案例回寫的責任是讓服務頁有真實壓力來源。案例要提供流量形狀、資料形狀、組織能力、失敗代價或回退路徑；案例只停在「某公司使用 X」時，對教材幫助有限。

沒這樣做的麻煩

服務頁會變成產品百科

產品百科容易累積功能、版本、價格與競品資訊，讀者可以查到很多答案，但仍難以建立系統責任模型。服務頁教材合約要求每個資訊都回到教學責任。

統一模板會抹平服務對象

統一模板會把同分類服務壓成相同讀法，讓服務對象消失。SQLite、MongoDB、DynamoDB、PostgreSQL 都在 database 分類，但它們回答的讀者問題不同；用同一套章節順序處理，會讓 embedded state、document model、access pattern 與 SQL transaction 的差異變成表格欄位，而不是學習路線。

內容會被選型語氣帶走

選型語氣會問「什麼情境選 X」，但教材還要問「X 在系統中承擔什麼責任」。只寫選型，讀者能做局部選擇；補上教材合約，讀者能理解整個 backend 能力地圖。

大量服務頁會產生完成錯覺

服務頁數量增加會帶來覆蓋感，但覆蓋不等於完成。125 個服務頁如果只有入口與摘要，仍是素材庫；每篇具備學習目標、操作判讀與案例回寫後，才是教材。

跟其他抽象層原則的關係

原則關係
#130 教材目標先於決策框架#130 定義教材的上位目標；本卡把上位目標落到「單篇服務頁」的教學功能合約。
#131 教材完整性要用讀者旅程驗證#131 用讀者旅程檢查系列完整性；本卡用單篇教材合約檢查服務頁是否能獨立教會一個服務能力。
#132 貫穿式案例是服務教材的教學骨架#132 提供跨模組案例主線；本卡要求每篇服務頁能回寫至少一段 case route 或明確標示案例缺口。
#97 Metadata surface 要納入寫作 review 範圍服務頁教材合約也要檢查 title、description、heading、index entry 與下一步路由，避免正文與入口語意不一致。
#126 寫作 review 是多軸完整性服務頁 review 要同時看教材目標、服務責任、操作訊號、案例回寫、metadata surface 與跨模組路由。
#122 Cadence 同質化是模板的隱形維度本卡補服務頁的結構層防護：教學功能要完整，章節順序要依服務對象與責任形狀調整，避免批量服務頁同質化。

判讀徵兆

訊號該做的事
服務頁只有定位、適用場景與競品比較補本章目標、操作形狀、排錯判讀與案例回寫
服務頁內容很豐富，但缺少清楚學習路線依服務對象重排 heading
排錯段只有常見錯誤列表改成「訊號 → 判讀 → 下一步路由」
案例段只列公司名稱補案例提供的壓力、失敗代價或回退條件
服務頁讀完仍不知道下一步讀哪裡補上游概念、平行服務、下游 artifact 與 case route
批量服務頁都套同一標題但失去分類語言回到分類責任調整段落順序
同分類服務頁看起來像同一篇文章換名詞重新辨識每個服務的讀者對象、服務責任與操作語境

核心原則：服務頁完成的標準是讀者能透過單篇文章學會一個服務能力。成熟服務頁要同時提供學習目標、概念模型、操作判讀、替代邊界、案例回寫與下一步路由。