站點鍛造

Site Forge

<execution_context> 階段 0 會決定模式：

• auto (快速)： 盡可能由你自行完成。在唯一的計劃/審核關卡（階段 3）之後，一路執行到底，不再詢問。僅使用你能免費自行製作的媒體（jina；若有的話使用 MCP/Higgsfield）。如果某個步驟受阻、需要互動或失敗——請跳過它，繼續進行，並在結尾處將其列在「已跳過 / 日後升級」清單中。傾向於直接發布。
• full (最佳品質)： 互動式。每當一個選擇會顯著影響結果時就提問，並使用最佳的免費媒體，即使需要使用者處理（使用 Google/Gemini 處理圖片，使用 Flow 中的 Veo 3.1 Fast 處理影片——給使用者精確的提示，由他們生成並提供檔案）。受阻的步驟 → 請他們介入。

兩種模式共通：

• 🟢 自動：在獲得批准後，探索環境、設計、編寫程式碼、提取影格、執行 ffmpeg、進行本地預覽，以及部署。
• 🟡 兩種模式下都有兩個強制關卡：(1) 建置前的階段 3 計劃，以及 (2) 部署本身——每次部署前都必須立即詢問，一次都不能少。 對一次部署的批准絕不代表對下一次部署的批准。預設為本地預覽。
• 🔴 絕對禁止：編造虛假的憑證/金鑰；未經免責聲明就發布使用者標記為未經核實的主張；將使用者的機密輸入到表單中。 </execution_context>

0. 在執行任何其他動作之前，先選擇 PROFILE。 閱讀 references/design-profiles.md，並用一句話說明："Profile: creative-portfolio. 允許彎曲 display-size 上限、serif 禁令、scrim 下限、conversion furniture。Craft floor 保持不變。" 預設值是 local-service；creative-portfolio 適用於攝影師、設計師和藝術家；personal-agency 是 Adam 自己的設定檔。Profile 決定了 Adam 的哪些美學規則生效——craft floor 絕不能彎曲，因此 16px 正文、4.5:1 對比度、44px 觸控目標、reduced-motion、結構化資料、十六個社交標籤以及安全標頭，無論需求或參考網站如何，都必須適用。選錯 profile 會導致一個商業網站卻套用了作品集的照片效果。

1. 首先閱讀 references/page-composition.md（這是設計感頁面與空洞頁面的區別所在），然後在任何標記語言之前，呼叫 frontend-design（若已安裝 → 直接使用；否則請閱讀 references/frontend-design.md——這是完整的技能，按原樣捆綁，因此即使離線你也能獲得其完整指導）。

2. 呼叫 design-taste-frontend。 用一句話說明其設計解讀（"將此解讀為：<頁面類型> 給 <目標對象>，使用 <調性> 語言..."）並設定三個旋鈕。使用 taste-skill 自身的預設值和預設集。唯一例外：其在 MOTION_INTENSITY > 5 時解鎖的 perpetual-motion 功能保持關閉——沒有脈衝、閃爍、浮動、打字機效果或無限循環。在靜態建置中跳過其 React/Tailwind 堆疊章節。

3. Impeccable 已在運行：其鉤子在每次寫入時觸發。其命令是階段 7 的關卡。

然後使用 references/aesthetics.md 作為主題/字型/版面推導的輔助工具。 這是防止內容同質化的關卡，也是最大的品質槓桿。致力於一個大膽、針對特定需求的設計方向：

• 一個清晰的美學風格，精確執行；一個獨特的字型搭配（絕不使用 Inter/Roboto/Arial）；一個以 CSS 變數呈現的協調調色板。
• 結構——包含哪些區段、層級為何、一個令人難忘的亮點——從需求中推導而來。不要重複上一個網站的外形。
• 哪些功能適合，哪些應該排除（請參閱參考資料地圖）。一個簡單的需求可能不需要使用任何複雜效果；一個旗艦級專案則可能使用多個。 編寫一個 3–5 行的設計簡報，帶入後續的計劃。

Impeccable 的鉤子在每次寫入時觸發。 在其結果出現時立即處理，而不是最後一次性處理——每個結果要麼被修正，要麼被明確歸類為誤報並說明原因。絕對不要為了跳過修正而內聯壓制規則；壓制需要 Adam 的確認。在大約 6 次編輯後，它會安靜下來以避免干擾，這就是為什麼階段 7 的審計是一個獨立且嚴格的關卡。

單頁 vs 多頁。 單頁網站作為單一 index.html 發布。如果需求涵蓋不同的目標受眾或具有實質深度（例如一個包含患者/醫生/定價/關於等區段的商業網站，或一個帶有科學頁面的行銷網站），則值得製作一組多頁面——共享相同 chrome 的獨立 *.html 頁面。由於沒有建置步驟，共享區塊需手動複製，因此內容漂移是一個真實的 Bug：確保 <head>（包括無 FOUC 的主題片段）、nav、footer 和 <script> 標籤在所有頁面上保持位元組完全相同，並在部署前透過雜湊驗證。一個悄悄出現差異（不同字型、缺少切換開關、死連結）的頁面是典型的失敗。為每個頁面提供其自身的自我參照 canonical/og:url + <title>/描述，生成 sitemap.xml + robots.txt，並對任何私人/應用程式模擬頁面使用 noindex。如果頁面數量或共享區塊的大小使得手動複製變得脆弱，那麼一個微小的包含步驟（Node 串接，或 Eleventy/Astro）是合理的權衡——但僅當需求值得這麼做時；預設情況下應為無建置。

然後通過三項機械化關卡，它們都曾捕捉到真實發布的缺陷：

python3 <skill>/scripts/audit-seo.py        # SEO、本地 SEO、安全性。exit 1 表示 HIGH 嚴重性
python3 <skill>/scripts/check-crops.py      # 檢查 object-fit:cover 是否切到了主體
python3 <skill>/scripts/colour-system.py    # 全站每張照片採用統一的色調處理

並且在真實瀏覽器中點擊每個互動元素，斷言會發生狀態變化。常見問答、篩選列和地圖面板都曾以完整的標記、完整的 CSS 但完全沒有事件處理器的方式發布過：在原始碼中看起來沒有任何問題。使用 document.elementFromPoint 在控制項本身的正中心進行點擊，而不是使用 .click()，後者會跳過命中測試，並且即使控制項被完全遮擋也會通過。

如果感覺有任何卡頓，請進行 TRACE 追蹤，不要只是抽樣。 使用 performance_start_trace 然後捲動，再使用 performance_analyze_insight("ForcedReflow")，它會按檔案和行號指出有問題的函數。影格率抽樣的變異數有正負十個百分點，會誤導你去追查錯誤的目標。請參閱 scroll-performance.md。

設計堆疊關卡——硬性要求，部署前必須執行，沒有例外：

1. 執行 /impeccable critique（UX 審查），然後執行 /impeccable audit（無障礙、效能、響應式）。
2. 每個發現的問題都要修正，或明確歸類為誤報並說明原因。絕不內聯壓制。壓制需要 Adam 的確認。
3. 執行 taste-skill 自己的起飛前檢查清單（其第 14 節）。
4. 在 CSS 中搜尋 infinite 動畫和帶色調的 box-shadow，並將兩者都設為無效。這能捕捉到我們刻意覆蓋的那個 taste-skill 設定。

預設是 LOCAL。 在建置目錄中使用 python3 -m http.server 8080 預覽，並在此進行迭代。除非使用者當下要求，否則不要部署——Live URL 僅適用於付費客戶或排定的示範，且每次部署都會消耗 Netlify 額度（同一個網站的 38 次部署曾用盡一個月的免費額度，並迫使升級到付費方案）。將所有待處理的修正批次處理成每個審查輪次僅一次部署。

行動裝置的品質驗證將推遲到第一次實際部署時進行——這無法在本機完成，且自動化瀏覽器無法模擬真正的行動裝置視埠。計劃在示範時進行專門的行動裝置相容性檢查，而不是假裝在此之前就已驗證完畢。

絕對不要部署專案的根目錄。 netlify deploy --dir 不會遵守 .netlifyignore，而且一次根目錄部署曾將客戶的家庭地址和一個追蹤器的密碼發布到整個站點。每次都必須建立一個明確的發布目錄並驗證實際發布的內容：

python3 scripts/make-dist.py .        # 僅發布網頁檔案，不發布 .py/.md/package.json
netlify deploy --prod --dir dist
scripts/verify-published.sh <host> [owner-street-name]   # 必須輸出 "clean"；非零退出碼 = 洩漏

當使用者確實批准時，使用 scripts/deploy-netlify.sh（references/deploy.md）進行部署——Netlify 是最後才安裝的唯一項目；如果有表單，則啟用 Forms (ignore_html_forms) 及通知鉤子。 然後預設設定 Cloudflare Web Analytics（使用者通常會想要）：為已部署的主機名稱請求一個 beacon token，將該程式碼片段注入到 </body> 標籤之前，不要使用 SRI（Cloudflare 會輪換它——這是已記錄在案的例外），然後重新部署。在 auto 模式下，將其作為一個「需要使用者協助」的項目呈現，並附上確切的主機名稱。詳細資訊請參閱 references/deploy.md。 回報 Live URL、使用了哪些功能，以及（在 auto 模式下）「已跳過 / 日後升級」清單。

參考資料地圖

…

[為翻譯而截斷]