 Leo
|
0686d39fa1
|
pending-changes：兩個真缺口提案（引擎條件邊／recipe payload+response+binding）
來源＝頂層 CP arcrun-usable 逐步查證。依 leo「照 SDD 做事、照 CP 排順序」，
CP 不得自帶任務 ⇒ 這兩件必須進 SDD 才能做，先走 pending-changes 等 confirm（D35）。
缺口①引擎條件邊：if_control 回 {result,branch} 但 cypher-executor grep ON_TRUE|ON_FALSE=0
⇒ 用了零件仍得寫 code 判斷＝「全變成 code」的根。Arcrun#5 於 07-04 發現至今未修。
SDD 查證：7 個字面命中全是「部署分支」等別義，條件邊本身完全沒設計過。
缺口②recipe 缺 payload/response 層：schema 只有 {canonical_id,endpoint,method,auth_service}
⇒ telegram_send 自述「body 帶 chat_id+text」但存不住 body ⇒ 只能繞過 recipe 寫進 workflow。
要補 body_template／response_map／auth:binding 三層。SDD 查證 17 命中全是別的 payload。
|
2026-07-30 22:06:48 +08:00 |
|
 uncle6me-web
|
646e689b65
|
confirm(CP2-F): 二～四刀拆分過裁（leo 授權技術裁決）；四題答定（手寫驗證/arcrun-api/排程於 A 線後）
|
2026-07-24 18:11:10 +08:00 |
|
|
uncle6me-web
|
ab8e07201f
|
proposal(CP2-F): cypher 二～四刀拆分提案——bundle 528KB 實測解剖＋引擎留原地方案（待 leo confirm）
偵察實測（wrangler dry-run＋sourcemap byte 歸因，非推測）：
- 現碼 11,050 行／bundle 528.1KB——頂層 CP2-F 記載（15,446 行/748KB）是第一刀前舊數，提案 §0 更正
- zod 佔 130.6KB（24.7%），只服務兩條入口驗證鏈＝最大單一減重點
- 引擎真身僅 ~180KB，其餘 ~350KB 是管理/前端 API 面
方案：引擎留 cypher-executor 原地（webhook 觸發 URL 外部焊死、零改動），
新開 arcrun-api 收管理面；三刀漸進、每刀獨立回退；13 顆 SVC binding 不動。
依 D35 只寫 proposal 停下，不動 code、不部署。
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
2026-07-24 15:37:51 +08:00 |
|
|
Leo
|
1b687fedb0
|
fix(mcp): 解掉三個把人推去寫零件的誤導入口（leo 2026-07-21 拍板）
leo：「刪掉，技術者才會寫 component，在 Arcrun repo 寫一條如何 contribute
指向另一個 repo 就好。」
實測病灶：總管想寫「定期打 API 然後通知」的 workflow（Python 約 10 行），
問 foreach_control 怎麼用 → MCP 回傳 TinyGo 寫 WASM 零件教學（白名單/syscall/
contract schema）＝完全另一件事，40 分鐘未完成。
三處修正：
1. search_components 搜不到時的話術——原本建議 publish_component（把「我找不到」
翻譯成「你去造一個」，方向完全相反）。改為導向正確順序：語意搜尋知識庫→
auth-recipe list/scaffold→acr parts（http_request 能打任意 API）→acr list，
並明說 registry 可能是空的（已知問題），搜不到≠沒有這能力。
2. registry.ts 停用 publish_component / get_component_guide 兩個註冊
（檔案保留，只是不對 AI 暴露）。
3. 新增 CONTRIBUTING-components.md：三層責任分工（平台通用能力／熱門預鋪 recipe／
冷門誰用到誰開發）、什麼時候才真需要新零件、真要貢獻走 PR 的流程。
typecheck 通過。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
2026-07-21 16:42:51 +08:00 |
|
|
雲端總管
|
a73de77a7f
|
docs(sdd): P-2026-07-19 confirmed——pending-changes 移入已裁決、artifact-sharing tasks 增補 Phase 1.5（bundle/譜系/訂閱/多源/self-check）
|
2026-07-19 06:43:38 +00:00 |
|
|
雲端總管
|
ffd50e7510
|
docs(sdd): pending-changes 收 P-2026-07-19 proposal——artifact-sharing 增補 bundle/譜系/訂閱/多源（leo 對話定調，正式 confirm 待明示）
|
2026-07-19 06:28:28 +00:00 |
|
|
uncle6me-web
|
7bd7b4b26a
|
SDD 生命週期鐵律遷移：單一活性制度上線（portal-auth=active，其餘 paused/draft）
- 鋪檔（自 system-dev-template v1.15.0）：SDD-LIFECYCLE.md＋pending-changes.md
＋sdd-guard.sh（覆蓋舊版，加單一活性檢查）＋sdd-check.md＋sdd-active-check.sh
- settings.json PreToolUse（Write|Edit|MultiEdit）掛上 sdd-guard.sh
- 全部 SDD design.md 掛 frontmatter：portal-auth=active（現行 portal 線，
#61 demo 四件套剛 merge）；artifact-sharing=draft（零任務動工）；
其餘 16 份＝paused（皆有未完成任務，無明顯死件，不硬 close）
- CLAUDE.md 加「SDD 生命週期鐵律」段（指向 SDD-LIFECYCLE.md＋濃縮五條）
＋SDD 速查表改以 frontmatter status: active 為現行判準
- 驗證：sdd-active-check exit 0（恰 1 份 active）；guard pipe-test code 檔
exit 0 帶現行 SDD 提示；反向測試（造 2 份 active）guard exit 2／check exit 1 全擋
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
2026-07-17 17:03:16 +08:00 |
|