Request 來源分散
Slack 有意圖,Linear 有優先序,GitHub 有 code truth,卻沒有同一個地方解釋工作本身。
有人工閘門的 AI teammate
Cory 保留 Slack 與 Linear intake,起草正確 workflow,等待核准,再記錄 GitHub PR 證據。
範例治理 request
同一個 request 被解讀、核准、執行、審閱,最後留下可重用證據。
Slack 入口
從討論串、plan、repo 脈絡與 non-goals 起草 scope
意圖解讀
核准閘門
必須有人核准範圍,dev run 才能開始。
有界執行
保留決策與 workflow 證據
證據已連結目前 intake 從 Slack 或 Linear 開始;GitHub 保留 code 與 PR truth。
核心問題
軟體團隊早就有訊號。真正困難的是判斷 request 的意思、誰能核准,以及交付後哪些證據要留下。
Slack 有意圖,Linear 有優先序,GitHub 有 code truth,卻沒有同一個地方解釋工作本身。
模糊需求在 scope、non-goals、風險與 approval 可見前,就被送進 coding run。
決策理由、blocker 歷史、驗證與 review evidence 常困在聊天紀錄或 PR comment。
頁面保留深色 mint 品牌,但降低重複 card grid,加入 evidence 與 risk 狀態色,並把 hero 轉成 durable workflow state。
01
把 design variance、motion、density 調成 B2B control plane,而不是複製高動效 template。
02
Hero visual 改成 assignment、contract、evidence、handoff 狀態,而不是通用截圖。
03
Mint 保留品牌主訊號,amber 表示 approval 或 pending,rose 表示風險。
04
Hero、nav、final section 使用一致的 workspace 與 workflow 行動,不互相搶語意。
流程
Cory 把 intelligence 與 governance 分開。Agent 負責起草與執行;control plane 擁有狀態、核准、audit 與長期知識。
01
在語意判斷前,先保存 Slack 討論串或 Linear issue 的原始訊號。
原始脈絡不會丟失。
02
Cory 判斷討論串需要 plan 還是討論、起草 scope、提出 repo 脈絡,並把不確定性顯示出來。
人類審閱草稿,而不是填空白表單。
03
高風險工作必須有明確 non-goals、範圍與驗證期待,才能繼續。
副作用是有意識的決策。
04
Coding agent 收到已核准的 contract,回報 progress、blocker、branch 狀態與 checks。
交付過程仍可審閱。
05
決策、runbook 與可重用脈絡可以成為 workspace 的治理式 KM candidate。
下一個 request 不必從零開始。
Code as agent harness
商業價值來自 code-backed coworker harness:assignment intake、workflow contract、受權限控管的 action、artifact、evidence,以及可修復 blocker。
CTO
知道 agent 做了什麼、哪些證據無法驗證,以及哪個 state 擁有答案。
PM
在工程時間開始前,先審閱被解讀後的 job、non-goals 與 approval 邊界。
Engineering lead
Coding agent 收到有 owned paths、驗證期待與 handoff evidence 的 contract。
Founder / COO
決策與 artifact 不會困在 Slack thread,下一個 request 可以繼承脈絡。
01
把 request 轉成 outcome、source of truth、assumptions 與 ask-first boundaries。
02
定義 stage、允許的 side effects、approval gate 與 repair path。
03
保存可檢查結果、commands、branch state、review findings 與 public preview。
04
把缺少的 evidence 回報成可修復狀態,而不是假裝工作完成。
目前邊界
官網描述目前已上線的 MVP:Slack 討論串規劃、人工核准、PR 交接與脈絡式討論。更完整的 request taxonomy 在上線前都屬 roadmap。
先計畫
MVP 已上線具體程式需求會先變成有 acceptance criteria、non-goals 與 repo 脈絡的 plan,才會開始 coding run。
人工閘門
MVP 已上線Cory 等待 plan approval,再把有界工作交給 coding agent,並記錄 branch、驗證與 review handoff 證據。
討論
MVP 已上線當團隊需要判斷而不是新 implementation ticket 時,架構與需求問題會留在 conversation path。
Roadmap
Post-MVPMulti-shape routing 與 governed knowledge promotion 屬於 v0.2 方向,這裡不把它包裝成目前 execution capability。
Ideal customer profile
Cory 適合已經使用協作工具與 agent,但需要一個治理式 system of record 來管理工作流動的組織。
CTO / Platform owner
不用重讀 log,就能看出哪些工作等待中、卡住、執行中或可 review。
PM / Product lead
在工程開始前先審閱 scope、non-goals 與 clarification。
Engineering lead
接收有 approval state、repo context、驗證期待與 evidence 的有界工作。
Founder / COO
讓 shipped work 背後的決策,在 thread 結束後仍可被團隊使用。
價值主張
Cory 把混亂協作轉成受治理的工作,同時讓人類繼續對長期決策負責。
Request 先變成有歧義、context 與 non-goals 的結構化草稿。
團隊在任何副作用前先核准正確的工作形狀。
Durable action 需要明確閘門,並留下 audit evidence。
Runner 收到有界 contract,而不是自己猜 policy。
Evidence、rationale 與 runbook 可以進入治理式 workspace memory。
未來 request 繼承脈絡,不必從聊天紀錄重新挖。
這次 implementation 保留 CSS motion,GSAP 留到下一步用 isolated client leaf 實作 pinned workflow stack。
目前
只動畫 transform 與 opacity,讓 signed-out page 保持 server-rendered 並尊重 reduced motion。
GSAP
ScrollTrigger 只用在 assignment 到 contract 到 evidence 敘事,並需要 cleanup 與 reduced-motion fallback。
Guardrail
Hero、evidence、blocker motion 必須說明 hierarchy、transition 或 state,其餘保持靜態。
安全下一步是用 Cloudflare Pages 放 static marketing preview。Node control plane 仍維持現有 runtime,直到 API routes、auth、Postgres 與 runner orchestration 都驗證完成。
Pages
使用 branch previews、可快取 assets 與 rollback 來承載 public site slice。
R2
轉換成公開安全素材後,再存放 public images 或短 demo media。
Workers
先用於 redirects、public artifact proxy 或 webhook guard,再評估 app runtime。
Data
未經獨立架構決策,不用 KV 或 D1 取代 durable workflow state。
用 Cory 工作台解讀 request、協調 approval,並讓 evidence 留在工作本身。