Buda vs Kiro：Software Spec 不是團隊執行手冊
Requirements、design、tasks、code、tests 與 pull request 都完成時，一個 feature 很容易被視為「完成」。Kiro 擅長把 software chain 做清楚。真正困難的是 handoff：product、support、content、operations 應收到哪些 evidence？誰接受各自結果？
本文追蹤一個 feature 穿過這條 boundary，不做 generic feature checklist。
跟著一個 Feature 走過 Kiro
Kiro 官方定義是一套覆蓋 IDE、CLI、Web 與 Mobile 的 unified agent harness。Repository 裡的 .kiro/ 能讓 steering、Specs、custom agents、Hooks、permissions、MCP 和 Skills 跨 surface 延續。IDE/CLI 通常操作 local codebase；Web/Mobile 可連接 managed cloud sessions。
Kiro Web 有 collaborative、Spec、autonomous modes，可規劃、修改 code 並建立 PR/MR。官方明確說 Kiro 不會自動 merge，結果進入 default branch 前仍由人 review。因此不能把 Kiro 寫成 IDE-only、single-agent 或沒有 human review。
一份 Spec 用 requirements、design、tasks 組織 feature 或 bug。Requirements 記錄 user stories 與 acceptance criteria，design 記錄 architecture，tasks 拆成 executable units；dependency 允許時可按 waves 平行執行。
它回答的是 engineering question：idea 如何變成可 review、可 merge 的 software change？Artifacts 緊貼 repository，steering/Hooks 約束規範，permissions 控制 tool calls，branch/PR 保留 implementation evidence。
標出精確 Handoff
PR accepted 後，公司仍要決定哪些 behavior 能宣布、哪些 screenshots/docs 與 production 一致、誰需要 update、明天和下週要跑什麼 check、每份 deliverable 由誰接受。
這些工作引用 repository evidence，但主要 objects 已變成 brief、source files、browser findings、approved messages、reports 和 scheduled follow-ups。
Buda Agent Workspace 對應這段流程。每個 Agent 有 persistent Drive 與 cloud computer，使用 chat、browser、terminal、files、Git、preview，也能從 Channels 收件、調用 Skills、按 Automations 執行。Functional owner 審核 visible artifact，不必接手 engineering session。
Engineering Done 是 tests pass、acceptance criteria met、review complete、PR merged。Operating Done 是 docs 符合 production、support language approved、launch assets verified、owner accepted、scheduled checks assigned。
分開兩個定義，developer 不必成為所有 business artifact 的 approval desk，non-engineering agents 也不繼承多餘 repository authority。
逐欄檢查 Release Packet
Handoff 應包含 accepted PR/commit、shipped behavior、acceptance evidence、known limits、approved screenshots/files、downstream owners、review rules 和 dates。Kiro 負責 software evidence，Buda Agents 負責 docs、support material、launch coordination 與 scheduled checks。
記錄每個 Artifact 的歸屬
| Decision | Kiro | Buda |
|---|---|---|
| Primary lifecycle | Idea 到 reviewed software change | Request 到 reviewed business outcome |
| Core artifacts | Requirements、design、tasks、branch、PR/MR | Sources、working files、reports、content、operations package |
| Context anchor | Repository 與 .kiro/ | Agent Drive、Sessions、Skills、Space resources |
| Execution surfaces | IDE、CLI、Web、Mobile、local/cloud sandbox | Cloud workspace、browser、terminal、files、Git、Channels |
| Human gate | Tool permissions 與 merge 前 review | Consequential downstream action 前的 functional review |
| Natural owner | Developer / software team | Product、content、support、operations owner |
Specs、steering、Hooks、code intelligence、local/cloud execution、PR delivery 是中心時，Kiro 更直接。它也有 custom agents、sub-agents、MCP、Skills、permissions 和 Web automations。評估時要查看 plan、repository provider、region 與各 surface availability。
不同 Agent roles 要跨日持續、處理 non-code files/websites、從 Channels 收件，並把不同 artifacts 交給不同 reviewers 時，Buda 更適合。差異是 organizational continuity，不是更高 autonomy。
Kiro Rollout 前的專屬問題
Kiro只是IDE coding assistant嗎？
不是。官方文件包含 IDE、CLI、Web、Mobile、cloud sessions、custom agents、sub-agents、MCP、Skills、Hooks、permissions 和 automations。
Kiro有cloud agents與human review嗎？
有。Kiro Web 在 managed sandbox 執行並建立 PR/MR；Kiro 不自動 merge，default branch 前由人 review。
Kiro能處理non-code work嗎？
能 web search、tool calls 和 automation。判斷點是 accepted output 與 responsible reviewer 屬於 software lifecycle 還是另一個 function。
不要讓 Merged 等於 Launched
從一個 release 開始。Kiro 證明 software change，Buda 協調後續 operations。保持 least privilege、explicit handoff 與 human acceptance。