docs: 寫下本站實際的部署路徑

[hoshimoe]

README 的部署段寫著「dist/ 靜態檔，直接由 nginx 服務」。
本站不落在任何節點上，所以那句話會把下一個人送到錯的地方去找。

事項：workspace todo/sr-web-與-hoshivel-web-的部署路徑.md
（「查清楚並寫下來」）。workspace#126 已經把倉庫這一側的盤查寫進 workspace；
這條 PR 是它沒做的那一半——把結論寫進程式碼倉庫。同一份事項也改了
sr-web 與 hoshi-deploy。

查到的

證據
hoshi-deploy 的七個節點、六個服務	沒有 hoshivel-web
CI（.github/workflows/ci.yml）	只跑 npm ci ＋ npm run build，沒有部署步驟
package.json / package-lock.json	沒有 wrangler
wrangler.jsonc	assets.directory: ./dist，由 Cloudflare 那一側讀

結論：產物是 dist/，由 Cloudflare 建置與服務，倉庫這一側沒有任何一步推送
產物。README 改成寫出這件事。

原本那句「不得加入 SSR adapter、server／hybrid output、Node runtime 或容器
產物」保留——它仍然成立，而且在靜態託管下更成立。

兩個 commit

1. README 的「部署」段改寫成實情。
2. .hoshi-build.yaml 的註解不再指名「Cloudflare Pages」。
   那句話在這個倉庫、sr-web 與 hoshi-deploy 的清單檔頭各有一份複本。
   不落在節點上是對的；產品名沒有查證過——wrangler.jsonc 是
   assets.directory 的形狀，不是 Pages 專案的 pages_build_output_dir。
   拿掉一個查不到的產品名，和換成另一個產品名是兩件事，前者不需要等
   主控臺的答案。

沒有動的

release 那份四行說明指的 production 分支兩個 origin 都沒有
（workspace#126 查到的）。修它要先知道今天實際怎麼觸發部署，所以留著，
記在事項的未完成項裡——把一份壞掉的說明換成另一份沒查證的說明不是修好。

連帶的判斷

不納入 inventory。 判準是「由不由節點的 nginx 服務」，答案是否。連帶地
hoshivel.com 不進 origin 憑證的 SAN 集合。理由記在 workspace
decisions/infrastructure/兩個公開前端由-Cloudflare-服務.md。

驗證

npm ci ＋ npm run build（＝ 16/16 測試 ＋ astro check ＋ astro build，
33 頁）全綠，改完 .hoshi-build.yaml 之後重跑一次仍全綠。
hoshi check 回報「設定沒有問題」。

[hoshimoe]

關掉：被 #41 完整取代，而且 #41 是對的。

這條 PR 的作法是「Cloudflare 那一側查不到，所以把查不到的產品名拿掉」。
#41 拿到了主控臺的答案——Cloudflare Pages，從 main 部署——所以
「Cloudflare Pages」本來就是對的，拿掉它是退步，不是修正。

兩處這條 PR 判斷錯的地方，#41 都做對了：

• .hoshi-build.yaml 的產品名：這條 PR 拿掉它；答案來了之後那是對的名字。
• release：這條 PR 說「要先知道今天實際怎麼觸發部署才修得動，所以留著」。
  部署寫成實際的那一個：Cloudflare Pages，從 main #41 知道了，於是直接刪掉——它描述的 production 分支流程已經不存在。
  留著一份壞掉的說明並不比刪掉它安全。

workspace 的事項也已經閉環，結論在
decisions/infrastructure/兩個靜態站由-Cloudflare-Pages-從-main-部署.md。

---

Generated by Claude Code