getxuui/present - 在xuui中呈現

在 xuui 中呈現 (Present in xuui)

將當前對話中的工作轉換為一個可運行、可審查的 xuui 研究。交付的是一個經過驗證的本機 URL、一段關於設計問題的簡短說明，以及值得審查的差異點。交接完成後，持續傾聽使用者的審查意見。

保持在 xuui 中

xuui 是這項工作的呈現表面。一旦設計進入 xuui，就持續在那裡呈現它。

• 當另一個技能或工作流程也正在進行時，使用其選擇方向的方法，但將這些方向構建為 xuui 變體。切勿構建其選擇器、應用程式內部的切換器或單獨的預覽頁面。
• "在整個頁面中顯示"、"在網站中" 或 "在上下文中" 意味著一個更大的 xuui 研究：圍繞設計渲染周圍的頁面或佈局，並包含相同的變體。
• 僅在使用者要求實現或交付某個方向時才更改實際應用程式。保留研究，以便選擇保持可審查性。

解析要呈現的內容

將請求的 UI、參考資料或最近的工作作為簡報。忠實地呈現現有的實作。當簡報要求提供替代方案時，讓它們的差異回答設計問題；根據簡報和有用的比較來選擇數量。僅在對話和工作區使主題不明確時才提問。

從當前專案中找到研究工作區：一個已安裝的工作區包含 xuui.studies.ts 和一個本機 xuui 依賴項。閱讀該版本的 README、docs/authoring.md 和導出的型別，以及附近的註冊文件。使用已安裝的 CLI，而不是將較新的 alpha 版本下載到現有工作區中。一個 xuui 原始碼檢出則改用 examples/studies.ts、src/xuui/model.ts 和 src/xuui/parameters.ts；閱讀那裡 CONTEXT.md。不要通過從已安裝的技能向上遍歷來推斷使用者工作區。

alpha 版本在獨立工作區中呈現已註冊的 React 元件。如果需要新的工作區，請執行 npx --package @getxuui/[email protected] xuui init <directory>，然後使用其鎖定的安裝。對於來自其他程式碼庫的工作，檢查其令牌、相鄰 UI、響應式約束、提供者和資料。調整相關元件和必要的依賴項，而不要默默重新設計它。當隔離會扭曲審查時，包含一個上下文包裝器，並揭露模擬資料或不可用的後端行為。

構建探索框架

當請求替代方案時，說明設計問題，命名主要變量，並說明哪些保持不變。規劃能夠回答該問題的方向。以匹配的內容、有意義的狀態、視口寬度和比例開始它們。不要為忠實呈現現有設計的請求生成替代方案。讓簡報和有用的比較決定數量。

註冊研究

將設計及其適配器放在研究註冊旁邊，遵循現有的研究。將研究添加到中央註冊表，或者當工作探索相同的問題時，擴展現有的相關研究。

• 使用產品術語 study、variant、canvas、layer 和 guide。使用 defineStudy 註冊一個研究，並列出其 variants。
• 為每個變體提供一個在所有已註冊研究中唯一的、穩定的、描述性 ID。當推進一個應該保持可審查性的方向時，添加一個新的 ID。保留先前的實作；共享一個可變元件不會凍結其歷史。
• 為每個變體撰寫有用的名稱、描述和理由。
• 註冊普通的 React 元件。xuui 提供導航、平移、縮放、檢查、比較和評論；研究提供設計及其所需的提供者或資料。
• 限定研究的 CSS 範圍，使其無法重新設定工作室導覽或無關變體的樣式。為設計提供有意義的尺寸；沒有設定大小的包含區塊的百分比寬度可能會在畫布上崩潰。
• 當 DOM 本身提供的圖層名稱無用時，添加 data-xuui-layer-name。

暴露狀態和控制項

側邊欄顯示變體聲明的控制項，審查者對渲染的任何內容進行評論。選擇與設計匹配的控制項類型：

• machine 用於設計的不同狀態以及在它們之間移動的事件：空、載入中、已載入和錯誤；關閉和開啟；表單或流程的步驟。審查者可以從側邊欄跳轉到任何狀態，並在 Play 模式下跟隨轉換，以便可以對每個狀態進行判斷和評論。以產品的方式命名狀態和事件。從 machine.value 渲染，並將設計的真實互動連接到 machine.send(event)，以便在 Play 模式下點擊時遵循相同的機器。
• state 用於設計所反應的獨立值，例如收藏切換或項目計數。
• props 用於值得比較的設計參數，例如文案、圓角半徑或寬度。

當設計具有超出快樂路徑的有意義狀態時，使用 machine 而不是呈現一個狀態來暴露它們。不要發明設計沒有的狀態。僅暴露會更改渲染設計的控制項，並檢查每個狀態是否都能渲染。請參閱已安裝的 docs/authoring.md 以了解確切的形狀。

將更改限制在請求的研究和呈現它所需的註冊。呈現請求不授權重新設計工作室本身。

完成意味著請求的設計從已註冊的變體渲染，並且其暴露的控制項可以正常工作。

運行和驗證

在已安裝的工作區中，使用 npx --no-install xuui dev；在原始碼檢出中，使用其套件腳本。首先檢查是否存在現有的預覽，如果它服務於預期的工作區則重複使用。不要干擾無關的進程。保持本地伺服器運行以供審查者使用，並使用實際列印的來源端口。

使用實際伺服器來源和已註冊的 ID 打開 URL：

• 聚焦變體：/?study=<study-id>&variant=<variant-id>
• 比較：相同的 URL 加上 &view=all

驗證渲染的變體身份，而不是將 HTTP 200 視為證明：未知 ID 會回退到現有研究。檢查 UI，在 Play 模式下執行重要的互動，並嘗試每個暴露的控制項。對每個方向應用相同的可用性標準：鍵盤訪問、可見的完整控制項焦點、可讀文字、適當的減少動畫、以及真實的內容、狀態和寬度。運行相關的專案檢查，並準確報告失敗或不可用的檢查。

使用隔離的測試儲存進行提交檢查。保留審查者的真實草稿評論和已提交的記錄完整。

完成意味著鏈接打開預期的設計，有意義的互動有效，並且審查邊界清晰。

交接

返回聚焦鏈接，並在有用時返回比較鏈接。用幾句話解釋要判斷的內容，並命名重要的限制，例如模擬資料。審查者使用 Play 進行互動，C 進行評論，以及 "提交審查" 進行交接。最後說您正在傾聽他們的審查，他們可以繼續聊天。

對於替代方案，添加一個小的表格，說明更改了什麼、每個方向何時適合以及其主要成本。說明審查的寬度和狀態。不要默默選擇一個贏家。當要求推進一個選擇時，在其原始來源上下文中驗證被推廣的設計，並保留其可審查的研究；保留舊的實作並添加穩定的 ID 以進行進一步的可比較工作。

傾聽反饋

交接後，等待審查而無需被詢問。

• 如果 xuui MCP 工具可用，使用研究的 studyId 調用 xuui_wait_for_review。每次調用在 50 秒內返回。使用返回的 knownReviewIds 再次調用它，直到審查到達或使用者要求您停止。
• 如果它們不可用，則工作區的 MCP 伺服器未連接。提議連接它，按照已安裝的 docs/mcp.md 操作，並說明主機是否需要重新啟動以載入它。在此之前，如果您的主機可以運行一個在完成時通知您的後台命令，則使用一個來等待 .xuui/reviews/ 中的新文件。否則，請使用者在提交時告訴您。

當審查到達時，完整閱讀整個套件，然後使用 xuui_acknowledge_review 確認它。確認意味著您已閱讀，而不是其請求已完成。瀏覽器草稿不是提交的反饋。根據評論採取行動：以新的 ID 創建新變體進行更改，驗證它們，交接新鏈接，然後再次傾聽。