@midhunxavier/code-flow 0.0.0-stage → 0.1.0-preview.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (319) hide show
  1. package/LICENSE +21 -0
  2. package/README.md +141 -2
  3. package/bin/codeflow.mjs +8 -0
  4. package/bin/launcher.mjs +127 -0
  5. package/dist/remote-host.json +1 -0
  6. package/licenses/inter.txt +92 -0
  7. package/licenses/preact.txt +21 -0
  8. package/licenses/signals-core.txt +21 -0
  9. package/licenses/signals.txt +21 -0
  10. package/licenses/typescript-notices.txt +193 -0
  11. package/licenses/typescript.txt +55 -0
  12. package/licenses/uqr.txt +22 -0
  13. package/licenses/xterm-fit.txt +19 -0
  14. package/licenses/xterm.txt +21 -0
  15. package/package.json +34 -4
  16. package/public/assets/changes-62ZIEQSN.js +1 -0
  17. package/public/assets/chunk-2PZVOKID.js +1 -0
  18. package/public/assets/chunk-4D5IENEB.js +1 -0
  19. package/public/assets/chunk-5SARP5MU.js +1 -0
  20. package/public/assets/chunk-63YLZ3PR.js +1 -0
  21. package/public/assets/chunk-7FUHKF2M.js +1 -0
  22. package/public/assets/chunk-APQEVJ2K.js +1 -0
  23. package/public/assets/chunk-CGOZQMEZ.js +2 -0
  24. package/public/assets/chunk-J4VYS3KV.js +2 -0
  25. package/public/assets/chunk-L7TUCIYF.js +1 -0
  26. package/public/assets/chunk-SIHDWM2Y.js +154 -0
  27. package/public/assets/chunk-TEJVYIKC.js +1 -0
  28. package/public/assets/code-browser-VB2HGZSG.js +4 -0
  29. package/public/assets/filtered-tasks-ES5CP4KV.js +1 -0
  30. package/public/assets/interactive-browser-7F5ZXRUV.js +7 -0
  31. package/public/assets/join-project-6RTFHNCA.js +1 -0
  32. package/public/assets/main-65EW73SB.js +1 -0
  33. package/public/assets/project-invitations-view-GMPWGWYM.js +1 -0
  34. package/public/assets/settings-UB5Q4AQM.js +9 -0
  35. package/public/assets/styles-18792BB4.css +32 -0
  36. package/public/assets/team-server-wizard-2GLDWS6D.js +8 -0
  37. package/public/assets/terminal-IWAIM4DE.js +62 -0
  38. package/public/assets.json +1 -0
  39. package/public/bundle-meta.json +1 -0
  40. package/public/docs/.nojekyll +0 -0
  41. package/public/docs/accessibility.html +19 -0
  42. package/public/docs/acp-agents.html +117 -0
  43. package/public/docs/agent-containers.html +79 -0
  44. package/public/docs/api.html +1130 -0
  45. package/public/docs/app.js +342 -0
  46. package/public/docs/application-improvements.html +275 -0
  47. package/public/docs/architecture-explorer.html +19 -0
  48. package/public/docs/architecture.html +149 -0
  49. package/public/docs/auto-team.html +148 -0
  50. package/public/docs/automations.html +109 -0
  51. package/public/docs/checkpoint-review.html +37 -0
  52. package/public/docs/code-hosts.html +35 -0
  53. package/public/docs/code-intelligence.html +35 -0
  54. package/public/docs/configuration.html +346 -0
  55. package/public/docs/context-inspection.html +23 -0
  56. package/public/docs/coordinated-changes.html +28 -0
  57. package/public/docs/deferred-runs.html +25 -0
  58. package/public/docs/dependency-discovery.html +19 -0
  59. package/public/docs/documentation.html +84 -0
  60. package/public/docs/dynamic-teams-evaluation.html +174 -0
  61. package/public/docs/dynamic-teams-implementation-plan.html +882 -0
  62. package/public/docs/dynamic-teams-implementation-review-1.html +141 -0
  63. package/public/docs/dynamic-teams-plan-review-0.html +204 -0
  64. package/public/docs/extensions.html +42 -0
  65. package/public/docs/external-sources.html +96 -0
  66. package/public/docs/filesystem-policy.html +26 -0
  67. package/public/docs/filtered-tasks.html +44 -0
  68. package/public/docs/font-license.txt +92 -0
  69. package/public/docs/getting-started.html +143 -0
  70. package/public/docs/github-review-threads.html +26 -0
  71. package/public/docs/github.html +157 -0
  72. package/public/docs/help.html +69 -0
  73. package/public/docs/index.html +88 -0
  74. package/public/docs/installation.html +80 -0
  75. package/public/docs/launch-profiles.html +48 -0
  76. package/public/docs/maintenance.html +60 -0
  77. package/public/docs/memory-claims.html +31 -0
  78. package/public/docs/memory-storage.html +58 -0
  79. package/public/docs/notifications.html +39 -0
  80. package/public/docs/patterns.html +195 -0
  81. package/public/docs/performance-results.html +210 -0
  82. package/public/docs/performance.html +166 -0
  83. package/public/docs/project-conventions.html +22 -0
  84. package/public/docs/project-first-navigation-plan.html +587 -0
  85. package/public/docs/project-teams-implementation-plan.html +772 -0
  86. package/public/docs/project-teams.html +129 -0
  87. package/public/docs/provider-compatibility.html +20 -0
  88. package/public/docs/releasing.html +65 -0
  89. package/public/docs/remote-workers.html +64 -0
  90. package/public/docs/review-inbox.html +26 -0
  91. package/public/docs/run-storage.html +23 -0
  92. package/public/docs/runs.html +141 -0
  93. package/public/docs/search.json +1 -0
  94. package/public/docs/security.html +133 -0
  95. package/public/docs/shared-projects.html +31 -0
  96. package/public/docs/ssh-projects.html +60 -0
  97. package/public/docs/style.css +768 -0
  98. package/public/docs/task-reruns.html +30 -0
  99. package/public/docs/team-collaboration.html +412 -0
  100. package/public/docs/verification.html +22 -0
  101. package/public/docs/vscode.html +53 -0
  102. package/public/docs/worker-permission-verification.html +131 -0
  103. package/public/index.html +17 -0
  104. package/scripts/check-node.mjs +7 -0
  105. package/scripts/codeflow.mjs +55 -0
  106. package/scripts/computer-use.swift +64 -0
  107. package/scripts/pty.py +273 -0
  108. package/src/acp-connections.js +110 -0
  109. package/src/adapters/acp-presets.js +37 -0
  110. package/src/adapters/acp-types.js +0 -0
  111. package/src/adapters/acp.js +328 -0
  112. package/src/adapters/agent-tools.js +28 -0
  113. package/src/adapters/agy-auth.js +67 -0
  114. package/src/adapters/agy-isolation.js +242 -0
  115. package/src/adapters/agy-tools.js +45 -0
  116. package/src/adapters/agy.js +326 -0
  117. package/src/adapters/claude-stream.js +58 -0
  118. package/src/adapters/claude.js +282 -0
  119. package/src/adapters/codex-app-server.js +555 -0
  120. package/src/adapters/codex.js +311 -0
  121. package/src/adapters/errors.js +57 -0
  122. package/src/adapters/index.js +91 -0
  123. package/src/adapters/managed-permissions.js +37 -0
  124. package/src/adapters/model-discovery.js +100 -0
  125. package/src/adapters/process.js +433 -0
  126. package/src/adapters/team-tools.js +103 -0
  127. package/src/adapters/types.js +0 -0
  128. package/src/agent-browser.js +688 -0
  129. package/src/agent-computer.js +88 -0
  130. package/src/agent-container.js +155 -0
  131. package/src/agent-team-definitions.js +131 -0
  132. package/src/agent-tool-client.mjs +79 -0
  133. package/src/agent-tools.js +296 -0
  134. package/src/approvals.js +134 -0
  135. package/src/architecture.js +456 -0
  136. package/src/assets.js +44 -0
  137. package/src/automation.js +901 -0
  138. package/src/browser-files.js +293 -0
  139. package/src/browser-ownership.js +150 -0
  140. package/src/certificate-renewal.js +75 -0
  141. package/src/chat-family.js +25 -0
  142. package/src/chat-handoff.js +87 -0
  143. package/src/checkpoint-review.js +72 -0
  144. package/src/checks.js +303 -0
  145. package/src/code-host-git.js +102 -0
  146. package/src/code-hosts-api.js +99 -0
  147. package/src/code-hosts.js +482 -0
  148. package/src/code-intelligence-worker.mjs +452 -0
  149. package/src/code-intelligence.js +141 -0
  150. package/src/collab/api.js +365 -0
  151. package/src/collab/checkpoints.js +198 -0
  152. package/src/collab/connections.js +139 -0
  153. package/src/collab/host-execution.js +347 -0
  154. package/src/collab/hub-client.js +210 -0
  155. package/src/collab/link-api.js +229 -0
  156. package/src/collab/link.js +595 -0
  157. package/src/collab/model.js +496 -0
  158. package/src/collab/runner.js +1014 -0
  159. package/src/collab/store.js +1452 -0
  160. package/src/collab/terminals.js +361 -0
  161. package/src/collaboration-reviews.js +116 -0
  162. package/src/config.js +48 -0
  163. package/src/context-budget.js +14 -0
  164. package/src/context-inspection.js +204 -0
  165. package/src/context.js +154 -0
  166. package/src/conventions.js +283 -0
  167. package/src/coordinated-api.js +247 -0
  168. package/src/deferred-launch.js +82 -0
  169. package/src/deferred-runs.js +515 -0
  170. package/src/dependency-health.js +35 -0
  171. package/src/diff.js +43 -0
  172. package/src/docs-help.js +316 -0
  173. package/src/doctor.js +232 -0
  174. package/src/documentation-changes.js +20 -0
  175. package/src/engine.js +5258 -0
  176. package/src/env.js +44 -0
  177. package/src/execution-budget.js +8 -0
  178. package/src/experience.js +50 -0
  179. package/src/extensions.js +144 -0
  180. package/src/filesystem-access.js +107 -0
  181. package/src/filesystem-policy.js +238 -0
  182. package/src/filtered-task-limits.js +93 -0
  183. package/src/filtered-tasks-api.js +53 -0
  184. package/src/filtered-tasks.js +576 -0
  185. package/src/frame-policy.js +66 -0
  186. package/src/fs.js +57 -0
  187. package/src/git.js +626 -0
  188. package/src/github-review-threads.js +181 -0
  189. package/src/github.js +538 -0
  190. package/src/http.js +69 -0
  191. package/src/improve-settings.js +38 -0
  192. package/src/improve.js +187 -0
  193. package/src/integrations.js +373 -0
  194. package/src/integrity.js +259 -0
  195. package/src/journey-api.js +77 -0
  196. package/src/journey-replay.js +65 -0
  197. package/src/journey-store.js +97 -0
  198. package/src/journeys.js +60 -0
  199. package/src/json.js +81 -0
  200. package/src/launch-profiles.js +292 -0
  201. package/src/learnings.js +80 -0
  202. package/src/local-app-url.js +19 -0
  203. package/src/log.js +39 -0
  204. package/src/maintenance.js +335 -0
  205. package/src/memory-analysis.js +182 -0
  206. package/src/memory-claims.js +153 -0
  207. package/src/memory-sqlite.js +236 -0
  208. package/src/memory.js +552 -0
  209. package/src/merge-validation.js +58 -0
  210. package/src/model-catalog.js +239 -0
  211. package/src/model-research.js +91 -0
  212. package/src/notes.js +176 -0
  213. package/src/notifications.js +413 -0
  214. package/src/patterns/auto-team-model.js +230 -0
  215. package/src/patterns/auto-team.js +816 -0
  216. package/src/patterns/council.js +199 -0
  217. package/src/patterns/debate.js +188 -0
  218. package/src/patterns/findings.js +141 -0
  219. package/src/patterns/index.js +21 -0
  220. package/src/patterns/loop.js +158 -0
  221. package/src/patterns/pipeline.js +125 -0
  222. package/src/patterns/prompts.js +181 -0
  223. package/src/patterns/race.js +147 -0
  224. package/src/patterns/schemas.js +40 -0
  225. package/src/patterns/solo.js +46 -0
  226. package/src/patterns/supervisor.js +235 -0
  227. package/src/patterns/task-draft.js +29 -0
  228. package/src/patterns/task-review.js +45 -0
  229. package/src/patterns/tdd.js +231 -0
  230. package/src/patterns/team-strategies.js +67 -0
  231. package/src/performance.js +43 -0
  232. package/src/persistence-status.js +35 -0
  233. package/src/phone-sessions.js +96 -0
  234. package/src/preview-overlay.js +392 -0
  235. package/src/preview.js +230 -0
  236. package/src/privacy.js +23 -0
  237. package/src/project-report.js +22 -0
  238. package/src/project-team-budget.js +22 -0
  239. package/src/project-team-model.js +225 -0
  240. package/src/project-team-policy.js +42 -0
  241. package/src/project-team-store.js +234 -0
  242. package/src/project-team-usage.js +24 -0
  243. package/src/project-teams-api.js +43 -0
  244. package/src/project-teams.js +644 -0
  245. package/src/projects.js +290 -0
  246. package/src/provider-eligibility.js +9 -0
  247. package/src/readiness.js +98 -0
  248. package/src/remote-tls.js +66 -0
  249. package/src/remote-workers/bundles.js +198 -0
  250. package/src/remote-workers/client.js +332 -0
  251. package/src/remote-workers/durability.js +37 -0
  252. package/src/remote-workers/protocol.js +68 -0
  253. package/src/remote-workers/stdio.js +138 -0
  254. package/src/remote-workers/worker.js +304 -0
  255. package/src/remote.js +204 -0
  256. package/src/repo-config.js +201 -0
  257. package/src/repo-coordination.js +725 -0
  258. package/src/repo-tree.js +106 -0
  259. package/src/repository-identity.js +13 -0
  260. package/src/retention-policy.js +466 -0
  261. package/src/review-inbox.js +38 -0
  262. package/src/routing.js +49 -0
  263. package/src/run-analysis.js +111 -0
  264. package/src/run-cold-store.js +231 -0
  265. package/src/run-environment.js +15 -0
  266. package/src/run-history.js +91 -0
  267. package/src/run-log.js +160 -0
  268. package/src/run-permissions.js +111 -0
  269. package/src/run-projection.js +77 -0
  270. package/src/run-recovery.js +53 -0
  271. package/src/run-status.js +56 -0
  272. package/src/serve.js +138 -0
  273. package/src/server.js +2871 -0
  274. package/src/shared-access.js +103 -0
  275. package/src/shared-accounts.js +381 -0
  276. package/src/shared-api.js +239 -0
  277. package/src/shell.js +346 -0
  278. package/src/ship.js +344 -0
  279. package/src/slots.js +74 -0
  280. package/src/snapshot.js +388 -0
  281. package/src/source-context.js +17 -0
  282. package/src/sse-writer.js +70 -0
  283. package/src/ssh-projects/bootstrap.mjs +95 -0
  284. package/src/ssh-projects/config.js +45 -0
  285. package/src/ssh-projects/gateway.js +143 -0
  286. package/src/ssh-projects/manager.js +320 -0
  287. package/src/ssh-projects/team-autostart.mjs +93 -0
  288. package/src/ssh-projects/team-remove.mjs +69 -0
  289. package/src/ssh-projects/team-status.mjs +39 -0
  290. package/src/ssh-projects/transport.js +133 -0
  291. package/src/stats.js +139 -0
  292. package/src/store.js +544 -0
  293. package/src/stream.js +91 -0
  294. package/src/sweeps.js +241 -0
  295. package/src/tailscale.js +101 -0
  296. package/src/task-draft.js +23 -0
  297. package/src/task-team.js +164 -0
  298. package/src/team-evaluation.js +243 -0
  299. package/src/team-mailbox.js +160 -0
  300. package/src/team-memory.js +84 -0
  301. package/src/team-rerun-graph.js +15 -0
  302. package/src/team-reruns.js +130 -0
  303. package/src/team-scheduler.js +121 -0
  304. package/src/team-steering.js +21 -0
  305. package/src/team-template-store.js +98 -0
  306. package/src/team-templates.js +117 -0
  307. package/src/team-tool-client.mjs +79 -0
  308. package/src/team-tools.js +235 -0
  309. package/src/teams.js +0 -0
  310. package/src/templates.js +62 -0
  311. package/src/transcript.js +134 -0
  312. package/src/verification-integrity.js +27 -0
  313. package/src/verification.js +183 -0
  314. package/src/watch.js +195 -0
  315. package/src/work-queue.js +47 -0
  316. package/src/workflow-control.js +83 -0
  317. package/src/workspace-api.js +207 -0
  318. package/src/workspace-changes.js +61 -0
  319. package/src/workspace.js +146 -0
package/public/docs/dynamic-teams-implementation-review-1.html ADDED
@@ -0,0 +1,141 @@
1
+ <!doctype html>
2
+ <html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><meta name="description" content="Review 1: the dynamic teams implementation — code-flow guides and reference"><title>Review 1: the dynamic teams implementation · code-flow</title><link rel="icon" href="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI2NCIgaGVpZ2h0PSI2NCIgdmlld0JveD0iMCAwIDY0IDY0Ij4KICA8Y2lyY2xlIGN4PSIzMiIgY3k9IjMyIiByPSIzMCIgZmlsbD0iIzFlMWYxYSIgc3Ryb2tlPSIjM2Q0MDM2IiBzdHJva2Utd2lkdGg9IjIiLz4KICA8c3ZnIHg9IjE1IiB5PSIxNSIgd2lkdGg9IjM0IiBoZWlnaHQ9IjM0IiB2aWV3Qm94PSIwIDAgMjQgMjQiIGZpbGw9Im5vbmUiIHN0cm9rZT0iI2VjZWJlNCIgc3Ryb2tlLXdpZHRoPSIyIiBzdHJva2UtbGluZWNhcD0icm91bmQiIHN0cm9rZS1saW5lam9pbj0icm91bmQiPgogICAgPHBhdGggZD0iTTEyIDNsOSA1LTkgNS05LTV6TTMgMTNsOSA1IDktNU0zIDE3LjVsOSA1IDktNSIvPgogIDwvc3ZnPgo8L3N2Zz4K"><link rel="stylesheet" href="style.css"><script src="app.js" defer></script></head>
3
+ <body data-page="dynamic-teams-implementation-review-1"><a class="skip-link" href="#content">Skip to content</a>
4
+ <header class="topbar"><a class="brand" href="index.html"><img src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI2NCIgaGVpZ2h0PSI2NCIgdmlld0JveD0iMCAwIDY0IDY0Ij4KICA8Y2lyY2xlIGN4PSIzMiIgY3k9IjMyIiByPSIzMCIgZmlsbD0iIzFlMWYxYSIgc3Ryb2tlPSIjM2Q0MDM2IiBzdHJva2Utd2lkdGg9IjIiLz4KICA8c3ZnIHg9IjE1IiB5PSIxNSIgd2lkdGg9IjM0IiBoZWlnaHQ9IjM0IiB2aWV3Qm94PSIwIDAgMjQgMjQiIGZpbGw9Im5vbmUiIHN0cm9rZT0iI2VjZWJlNCIgc3Ryb2tlLXdpZHRoPSIyIiBzdHJva2UtbGluZWNhcD0icm91bmQiIHN0cm9rZS1saW5lam9pbj0icm91bmQiPgogICAgPHBhdGggZD0iTTEyIDNsOSA1LTkgNS05LTV6TTMgMTNsOSA1IDktNU0zIDE3LjVsOSA1IDktNSIvPgogIDwvc3ZnPgo8L3N2Zz4K" width="30" height="30" alt=""><strong>Code Flow</strong><span>Docs</span></a><button class="search-trigger" id="open-search">Search documentation <kbd>⌘ K</kbd></button><div class="top-actions"><a href="https://github.com/midhunxavier/code-flow">GitHub ↗</a><button id="theme" aria-label="Change color theme">Theme</button><button id="open-help" class="primary" hidden aria-expanded="false" aria-controls="help-panel">Ask code-flow</button><button id="menu" aria-label="Toggle documentation navigation" aria-expanded="false" aria-controls="sidebar">☰</button></div></header>
5
+ <div class="layout"><nav class="sidebar" id="sidebar" aria-label="Documentation"><section><h2>Get started</h2><a href="index.html" >Overview</a><a href="installation.html" >Install Code Flow preview</a><a href="getting-started.html" >Getting started</a><a href="patterns.html" >Team patterns</a><a href="acp-agents.html" >ACP coding agents</a><a href="help.html" >Ask code-flow</a></section><section><h2>Work with agents</h2><a href="runs.html" >Runs and workspace</a><a href="auto-team.html" >Team</a><a href="project-teams.html" >Project missions (preview)</a><a href="review-inbox.html" >Review inbox</a><a href="verification.html" >Verification and review</a><a href="github.html" >GitHub, review and shipping</a><a href="github-review-threads.html" >GitHub review threads</a><a href="task-reruns.html" >Selective task reruns</a><a href="deferred-runs.html" >Deferred runs</a></section><section><h2>Your workspace</h2><a href="configuration.html" >Configuration</a><a href="context-inspection.html" >Context and budgets</a><a href="project-conventions.html" >Versioned project conventions</a><a href="checkpoint-review.html" >Checkpoints and reversions</a><a href="launch-profiles.html" >Service launch profiles</a><a href="code-intelligence.html" >Code intelligence</a><a href="architecture-explorer.html" >Architecture explorer</a><a href="memory-storage.html" >Project memory</a><a href="memory-claims.html" >Semantic claim review</a><a href="coordinated-changes.html" >Coordinated changes</a></section><section><h2>Connect and collaborate</h2><a href="team-collaboration.html" >Team collaboration</a><a href="shared-projects.html" >Shared project accounts</a><a href="ssh-projects.html" >SSH projects</a><a href="remote-workers.html" >Remote agent workers</a><a href="code-hosts.html" >GitLab and Bitbucket code workflows</a><a href="external-sources.html" >Read-only external sources</a><a href="automations.html" >Automations and away mode</a><a href="notifications.html" >Outbound notifications</a></section><section><h2>Operate safely</h2><a href="security.html" >Security, subscriptions and caveats</a><a href="filesystem-policy.html" >Project filesystem policy</a><a href="agent-containers.html" >Agent containers</a><a href="filtered-tasks.html" >Filtered Docker tasks</a><a href="dependency-discovery.html" >Dependency discovery</a><a href="maintenance.html" >Backup and maintenance</a></section><section><h2>Build and extend</h2><a href="architecture.html" >Architecture and development</a><a href="api.html" >Local API and command-line client</a><a href="extensions.html" >Provider and workflow extensions</a><a href="provider-compatibility.html" >Provider compatibility</a><a href="accessibility.html" >Accessibility acceptance</a><a href="performance.html" >Performance</a><a href="run-storage.html" >Run storage</a><a href="documentation.html" >Documentation and GitHub Pages</a><a href="releasing.html" >Preparing a preview release</a><a href="vscode.html" >Code Flow for VS Code</a></section><section><h2>Engineering records</h2><a href="application-improvements.html" >Application improvement program</a><a href="project-first-navigation-plan.html" >Project navigation review and implementation plan</a><a href="dynamic-teams-evaluation.html" >Dynamic teams: implementation evidence and rollout decision</a><a href="dynamic-teams-implementation-plan.html" >Dynamic teams, workflows, messaging, and memory</a><a href="dynamic-teams-implementation-review-1.html" aria-current="page">Review 1: the dynamic teams implementation</a><a href="worker-permission-verification.html" >Live worker permission verification</a><a href="dynamic-teams-plan-review-0.html" >Review 0: Dynamic teams implementation plan</a><a href="project-teams-implementation-plan.html" >Standing project teams implementation plan</a><a href="performance-results.html" >Measured performance: 19 October 2026</a></section><a class="app-link" id="back-app" hidden href="/">← Back to app</a></nav>
6
+ <main id="content" tabindex="-1"><div class="breadcrumb">Documentation <span>/</span> Engineering records</div><article><h1 id="review-1-the-dynamic-teams-implementation">Review 1: the dynamic teams implementation</h1>
7
+ <blockquote>
8
+ <p>Engineering record. Status, measurements and decisions below describe the recorded implementation or review. For current usage, start with the <a href="index.html">documentation library</a>.</p>
9
+ </blockquote>
10
+ <p>Reviewed: commits <code>2cf0736</code> (Add dynamic agent teams with durable collaboration and scoped memory) and <code>dfd752d</code>, on top of <code>8cb3641</code>, together with the evidence document <code>dynamic-teams-evaluation.md</code>. About 8,600 lines across 80 files: the Auto team pattern and plan model, the event scheduler, the mailbox, the memory store, the live tool bridge and its adapters, the evaluation runner and rollout store, the UI, and the documentation.</p>
11
+ <p>Method: four independent read-throughs (runtime and scheduler; memory store and trust boundary; live bridge, adapters and credentials; evaluation, rollout and documentation claims) plus a UI pass. Suspected defects were reproduced with scripts or tests before they were counted. The evidence JSON was checked number by number against the document. Everything marked <strong>fixed</strong> below was changed in this review and is covered by a test; everything marked <strong>open</strong> is not.</p>
12
+ <p>Baseline before this review: typecheck clean, 416 of 416 unit tests passing, 17 browser tests passing. After: 420 of 420 unit tests, both browser suites, typecheck and the UI build pass. After merging <code>main</code> (the side panel, PR 13) and the fixes from the Codex review of PR 14: 475 of 475 unit tests, 19 browser tests.</p>
13
+ <h2 id="verdict">Verdict</h2>
14
+ <p>The implementation is more careful than most: identity, authority and provenance are derived by the server and never from model output; control state is journaled before it is acted on; schemas are closed; the test suite exercises crashes, replays and spoofing rather than object shapes. The trust boundary around project memory holds. Nothing reviewed lets an agent accept its own knowledge, borrow another member&#39;s session, or reach the application token.</p>
15
+ <p>Its failures are of calibration, not of design: several safeguards are sized wrong. A repository without a test command could never finish a run; deleting one memory erased every record of every run that had merely seen it; one shared cap let a looping member fill the memory store for every project; every live tool call rebuilt the whole mailbox from scratch; the provider inventory re-probed the CLIs on every scheduler event. All of these are fixed here. The evidence document is honest in tone but its numbers come from an uncommitted tree, its real trials overlapped in time, and its &quot;rollout gate&quot; gates a label rather than the feature. Those are now disclosed in the documents themselves.</p>
16
+ <p>Keep Auto team experimental and opt-in, as the evidence document already decides. Re-run the real trials from the committed runner before any beta claim.</p>
17
+ <h2 id="fixed-in-this-review">Fixed in this review</h2>
18
+ <h3 id="runtime-and-scheduling">Runtime and scheduling</h3>
19
+ <ul>
20
+ <li><strong>A repository without a runnable check could never finish.</strong> The final verification treated &quot;no configured check&quot; as an unresolved gap, so the team ended blocked, the run stopped with &quot;unresolved work&quot;, and every Resume spent a review invocation and blocked again. Now a complete, independently reviewed result in such a repository finishes as <code>completed</code> with <code>verification.check: &quot;unknown&quot;</code>, no pass/fail verdict, and nothing accepted into team or project memory. The UI shows &quot;Reviewed · no check ran&quot; rather than &quot;Verified&quot;. <code>src/patterns/auto-team.ts</code>, <code>ui/team-state.ts</code>, <code>ui/team.tsx</code>, test &quot;Auto team without a runnable check finishes reviewed but unverified&quot;.</li>
21
+ <li><strong>Provider inventory probed the CLIs on every scheduler event.</strong> <code>teamInventory()</code> ran <code>codex debug models</code> and <code>agy models</code> (a network fetch, 45 s timeout) at every wave and journaled the catalogs each time. Later observations now reuse the planning catalogs and refresh only availability and quota. <code>src/engine.ts</code>, <code>src/patterns/auto-team.ts</code>.</li>
22
+ <li><strong>A no-op coordinator revision was asked again until the coordination budget ran out.</strong> A revision that adds, reassigns, retries, answers or contracts nothing now ends the wave loop with the unresolved work listed. Test &quot;Auto team stops asking the coordinator once a revision changes nothing&quot;.</li>
23
+ <li><strong>User answers and teammate messages shared one JSON block</strong> labelled &quot;agent data unless origin=user&quot;. They are now separate prompt sections, the user&#39;s answers marked authoritative for the task and teammates&#39; messages marked as evidence. The member&#39;s own session handle and private checkpoint no longer appear in the assignment JSON. <code>src/patterns/auto-team.ts</code>.</li>
24
+ </ul>
25
+ <h3 id="memory-store">Memory store</h3>
26
+ <ul>
27
+ <li><strong>Deleting one memory cascaded through context references.</strong> <code>derivedFrom</code> records what was in a member&#39;s context, not text copied from it, so deleting a widely selected convention erased every checkpoint, contract and finding of every run that saw it, including user-accepted entries derived from them, and any run still citing it failed on its next write (&quot;Memory source was deleted&quot;). Deletion now redacts only the target; references to a tombstone inherit its origins instead of throwing. Reproduced before the fix with a scratch script. <code>src/memory.ts</code>, test &quot;deletion erases the entry&#39;s body; entries that saw it keep theirs&quot;.</li>
28
+ <li><strong>One global cap of 5,000 entries across all scopes and repositories</strong>, with private and team records never retired and no API to delete them. A few hundred runs, or one looping member, would make every Auto run fail at plan time with &quot;Memory limit reached&quot;. The project cap now counts project entries only; private and team records are capped at 512 per run; archiving a run with cleanup retires its private and team records. The store&#39;s own load-time validation used the same global count and would have refused to open the file. <code>src/memory.ts</code>, <code>src/engine.ts</code> (<code>archive</code>).</li>
29
+ <li><strong>Run-wide provenance unions overflowed the 128-reference limit</strong> and the overflow was fatal after verification had succeeded. Writes now cite the journaled selection of the task that produced them (stable across replays, which also removes a crash-idempotency hole in the pattern path), and the limit is 1,024. <code>src/patterns/auto-team.ts</code>, <code>src/team-memory.ts</code>, <code>src/engine.ts</code>.</li>
30
+ <li><strong>A user&#39;s edit silently accepted a proposal</strong>, including a tags-only edit of an untrusted one, contradicting &quot;the user must approve the exact revision&quot;. An edit now keeps a proposal a proposal unless the request says <code>accept: true</code>; an accepted entry the user edits is recorded as accepted by the user. <code>src/memory.ts</code>, <code>src/server.ts</code>, test &quot;a user&#39;s edit keeps a proposal a proposal unless they accept it&quot;.</li>
31
+ <li>Storage failures were returned as HTTP 400; they are 500 now. The unused <code>memoryPrompt()</code> helper, which rendered bodies unescaped into Markdown headings, is removed.</li>
32
+ </ul>
33
+ <h3 id="live-tool-bridge-and-adapters">Live tool bridge and adapters</h3>
34
+ <ul>
35
+ <li><strong>Every tool call rebuilt the mailbox overlay with one deep clone per pending command.</strong> Measured: 1,000 pending commands cost 1.8 s per call, 4,096 cost 36 s, all synchronous on the main thread and serialized ahead of every other member&#39;s calls and the scheduler&#39;s own drains. The overlay now clones once and applies commands in place, and each member turn may make at most 256 tool calls. <code>src/team-mailbox.ts</code> (<code>applyMailboxCommandInPlace</code>), <code>src/engine.ts</code>.</li>
36
+ <li>The client answered over-limit requests with <code>id: null</code>, leaving the CLI&#39;s request waiting until its own tool timeout; it now answers with the request&#39;s id. The credential file is deleted as soon as the client has read it. <code>src/team-tool-client.mjs</code>.</li>
37
+ <li>The capability TTL was clamped to 2 hours while a step may run 24; a failed listen was cached forever; the bridge was never closed at shutdown; an inactive grant answered 400 instead of 403. <code>src/team-tools.ts</code>, <code>src/server.ts</code>.</li>
38
+ </ul>
39
+ <h3 id="ui">UI</h3>
40
+ <ul>
41
+ <li>The run view&#39;s event sequence numbers (the manager&#39;s global counter) and the sidebar feed&#39;s per-start counter were gated through one map, so a run you had opened stopped updating in the sidebar and never announced that it needed you until a reload. The side panel change merged to <code>main</code> as PR 13 removed the run view&#39;s pushes into the list altogether: the list is the global feed&#39;s. The merge keeps that, so the run view&#39;s stream, including its hello snapshot, no longer touches the list. <code>ui/run.tsx</code>, <code>ui/state.ts</code>.</li>
42
+ <li>&quot;Waiting for you&quot; was shown for a team question regardless of run status, although the server accepts answers only while the run is running, and a crash left the flag set. The server clears it when it marks a run interrupted; the UI, phone view and inbox show it only for a running run, with the Resume instruction otherwise. <code>src/engine.ts</code> (<code>load</code>), <code>ui/team-state.ts</code> (<code>teamAwaitingAnswer</code>), <code>ui/run.tsx</code>, <code>ui/rail.tsx</code>, <code>ui/automations.tsx</code>, <code>src/remote.ts</code>.</li>
43
+ <li>The &quot;approve the plan&quot; preference was one shared key, so unticking it once for Plan → Build → Review dispatched Auto teams without their approval checkpoint. It is now remembered per pattern; the old shared choice still applies to manual patterns. <code>ui/state.ts</code>, <code>ui/composer.tsx</code>.</li>
44
+ <li>The open user question is now a card under the run header, like plan approval, instead of the last item in the message list. <code>ui/team.tsx</code> (<code>TeamQuestionCard</code>), <code>ui/run.tsx</code>.</li>
45
+ <li>The check-command detection could land in the composer field after the user had started typing into it (the browser test recorded <code>npm testnpm test</code> as the check); a late detection result now fills only a field nobody has touched. <code>ui/state.ts</code> (<code>loadCheck</code>).</li>
46
+ <li>Measurements polled the evaluation endpoint every 5 s while collapsed, which rebuilt the report from the whole journal each time; they load only while open. Delete in the memory panel is a two-step inline confirmation. The composer refuses an Auto team with fewer than 4 steps or an empty provider pool before the run exists. An invalid follow-up budget is explained next to the composer instead of only inside the collapsed budget disclosure; &quot;Revise goal&quot; is hidden during plan approval; the answer box has a visible label. The hello event of a run stream now always carries the snapshot.</li>
47
+ </ul>
48
+ <h3 id="evaluation-and-runner">Evaluation and runner</h3>
49
+ <ul>
50
+ <li><code>repairTurns</code> counted any step whose title matched <code>/repair|fix/</code>, including model-authored task titles; it now counts engine-titled steps only. <code>reportedTokens</code> omitted cache-read tokens. The &quot;avoidable barrier&quot; label is &quot;dispatch delay after an answer&quot;: every trial ran event-driven, so there was no barrier to avoid.</li>
51
+ <li>The rollout decision assessed only the reports a caller cited, so a caller could cherry-pick verified pairs to reach &quot;default&quot;. Eligibility is now judged over every real report in the store. <code>src/team-evaluation.ts</code>.</li>
52
+ <li>The runner created an empty temporary directory on every invocation even with <code>--out</code>; <code>--real</code> now requires <code>--confirm</code> and prints the maximum invocation count; the trial settings that differ from app defaults (approval off, <code>maxRepairs: 1</code>, <code>maxSubtasks: 2</code>, provider-default models) are written to <code>configuration.json</code>. <code>scripts/</code> is now typechecked. <code>scripts/evaluate-teams.ts</code>, <code>tsconfig.json</code>.</li>
53
+ </ul>
54
+ <h3 id="documents">Documents</h3>
55
+ <ul>
56
+ <li>README no longer headlines an experimental feature with one verified real run out of three as the product&#39;s primary flow; Auto team is presented as experimental and opt-in.</li>
57
+ <li><code>dynamic-teams-evaluation.md</code> now states where its numbers come from (an uncommitted tree, an older runner, source runs not committed), that the real trials overlapped in time, what the dispatch-delay figure is, and that the rollout stage does not gate availability. Test counts are reconciled (397 at trial time, 416 after the delivery review, 420 now).</li>
58
+ <li><code>dynamic-teams-implementation-plan.md</code>: &quot;validates the scheduling benefit&quot; is corrected to &quot;demonstrates the scheduling order&quot;; three measurement rows marked &quot;Captured&quot; are now &quot;Partly&quot; or &quot;Not captured&quot;; the rollout decision is described as a label.</li>
59
+ <li><code>auto-team.md</code>, <code>security.md</code>, <code>configuration.md</code>: <code>--strict-mcp-config</code> disables the user&#39;s and the repository&#39;s MCP servers in Claude team turns; members run as one user and the credential file is readable in the window before the client deletes it; deletion and edit semantics as implemented; the per-turn tool budget and per-run memory cap; the stage is informational.</li>
60
+ </ul>
61
+ <h2 id="open-findings-ranked">Open findings, ranked</h2>
62
+ <ol>
63
+ <li><strong>The real evidence is not reproducible and must be regenerated.</strong> The committed runner, a committed fixture task and recorded model identities are the minimum for a number anyone can check. Until then the evidence document supports exactly one claim: the feature runs end to end on real CLIs. Run <code>npm run evaluate:teams -- --real --confirm</code> from the committed tree, sequentially, and replace the JSON.</li>
64
+ <li><strong>The rollout stage does not change behaviour.</strong> Either make <code>beta</code>/<code>default</code> affect availability and the composer (and keep <code>CODEFLOW_AUTO_TEAM_ENABLED</code> as the kill switch), or rename the feature &quot;rollout record&quot;. A gate that gates nothing invites the wrong conclusion.</li>
65
+ <li><strong>Coordination budget is tight by construction.</strong> <code>min(4, floor(limit / 4))</code> coordinator calls include initial planning and every approval revision; two &quot;revise&quot; clicks at approval leave one call for the whole run. Consider <code>min(8, ceil(limit / 4))</code> or counting approval-driven replanning separately, then measure.</li>
66
+ <li><strong>Steering race.</strong> Fixed after the Codex review of PR 14. A Codex <code>turn/steer</code> that had not answered by the 2 s deadline was journaled as not accepted, so a message Codex did take was shown again in the next context. The deadline now records an unknown outcome; the CLI&#39;s answer is journaled when it comes and settles the outcome at the next drain; the message shows as <em>steering</em> meanwhile. An answer that never comes (a crash) leaves the message available to the next context under the same ID, as an interrupted acknowledgement always did. <code>src/engine.ts</code> (<code>steerTeamMessages</code>), the late-acceptance case of the steering test.</li>
67
+ <li><strong>Capability probes reran on every turn after an unknown result.</strong> Fixed after the Codex review of PR 14. An unknown result (a CLI missing or not signed in, an older Codex refusing <code>codex mcp get</code>, a probe that timed out) was evicted from the cache at once, so every Auto turn paid the serial probe stages again. It is now kept for two minutes, against ten for a settled result. The cache key still embeds a test hook. <code>src/adapters/team-tools.ts</code>, test &quot;an unknown capability probe is not repeated on the next turn&quot;.</li>
68
+ <li><strong>Bridge handler errors are returned verbatim</strong> (file paths, git errors). Whitelist domain errors as 400; everything else 500 with a generic message, logged server side. <code>src/team-tools.ts</code>.</li>
69
+ <li><strong>Git fan-out per prompt</strong>: up to 128 <code>merge-base --is-ancestor</code> calls per selection, run twice per <code>projectMemory()</code>. Memoize <code>(commit, head)</code> per run and build the query once. <code>src/team-memory.ts</code>.</li>
70
+ <li><strong>Memory editor after a 409</strong> keeps the stale revision; the only way out discards the draft. Refetch, rebase the revision, keep the typed fields. <code>ui/memory.tsx</code>.</li>
71
+ <li><strong>Reconnect handling is tested only through a pure helper</strong> with a scenario the server cannot produce. Add a server test for <code>Last-Event-ID</code> beyond <code>newest</code> and a client test for the three hello cases. <code>test/server-reliability.test.ts</code>, <code>test/team-ui.test.ts</code>.</li>
72
+ <li><strong><code>read_memory</code> results are frozen per attempt and arguments</strong> (intentional for provenance); new team proposals are invisible to an identical later call in the same attempt. Say so in the tool description.</li>
73
+ <li><strong>Answering a question after a restart requires Resume first.</strong> The UI now says so; a better flow would accept the answer while interrupted and deliver it on Resume.</li>
74
+ <li><strong>The team view is a dashboard at the top of the thread.</strong> The question card is now under the header; the remaining roster, workflow, coverage, messages and measurements should fold into one disclosure outside plan approval, with measurements and capabilities living in Insights.</li>
75
+ </ol>
76
+ <h2 id="what-to-avoid-next-time">What to avoid next time</h2>
77
+ <ul>
78
+ <li>A safeguard whose blast radius is &quot;everything that touched it&quot;: the deletion cascade over context references, the global memory cap across scopes and repositories, and the overlay rebuilt from scratch per call all protected one thing by endangering everything around it. Size a safeguard to the record it protects.</li>
79
+ <li>A gap nobody can close. If the team can do nothing about a condition (no test command, no reviewer quota), it must not become a blocking gap that every Resume pays to rediscover.</li>
80
+ <li>Probing external processes inside a loop. Catalog and version probes belong at plan time; a scheduler event should be a function of journaled state.</li>
81
+ <li>One JSON blob for text of different authority. User answers and teammate messages, or a member&#39;s private checkpoint and its public record, must not share a section.</li>
82
+ <li>A single preference key across patterns when one pattern makes the preference a safety control.</li>
83
+ <li>Evidence written from an uncommitted tree, trials run concurrently and called sequential, counts (&quot;11 focused tests&quot;) that match no file, and estimates labelled as measurements (&quot;avoidable barrier&quot;, &quot;repair turns&quot; by regex). The evidence document was candid everywhere except in these specifics, and those are what a reader checks first.</li>
84
+ <li>Calling a recorded label a gate. If a decision does not change what the software does, do not describe it as controlling rollout.</li>
85
+ <li>Headlining an experimental feature in the README before its own evidence supports it.</li>
86
+ </ul>
87
+ <h2 id="suggestions">Suggestions</h2>
88
+ <ul>
89
+ <li>Treat the three memory scopes differently in storage: project knowledge in the curated store; private checkpoints and team records in the run&#39;s own journal directory, deleted with the run. Most of the cap, GC and cascade problems disappear with that split.</li>
90
+ <li>Replace the per-event coordinator wake with a per-wave decision unless a measurement shows per-event decisions change outcomes; the fixture data so far shows no peer questions in real runs at all.</li>
91
+ <li>Record model identity per turn in the evaluation report and pin it in the runner; otherwise two trials are not comparable even on the same day.</li>
92
+ <li>Add a <code>check</code> detection step to the Auto plan itself: when no check command exists, ask the coordinator to propose one as an investigation task, so verification becomes possible rather than unknown.</li>
93
+ <li>The plan document has become a hybrid of history and status. Move the status table and the storage decision into the evidence document, and keep the plan as the design record it was.</li>
94
+ </ul>
95
+ <h2 id="verification-performed">Verification performed</h2>
96
+ <div class="table-scroll" tabindex="0"><table>
97
+ <thead>
98
+ <tr>
99
+ <th>Check</th>
100
+ <th>Result</th>
101
+ </tr>
102
+ </thead>
103
+ <tbody><tr>
104
+ <td><code>npm run typecheck</code></td>
105
+ <td>passes (now includes <code>scripts/</code>)</td>
106
+ </tr>
107
+ <tr>
108
+ <td><code>npm test</code></td>
109
+ <td>420 passed, 0 failed (416 before; 4 added)</td>
110
+ </tr>
111
+ <tr>
112
+ <td><code>npm run test:e2e</code> (<code>auto-team.e2e.ts</code>, <code>ui.e2e.ts</code>)</td>
113
+ <td>passes after the UI changes</td>
114
+ </tr>
115
+ <tr>
116
+ <td><code>npm run build</code></td>
117
+ <td>passes</td>
118
+ </tr>
119
+ <tr>
120
+ <td><code>git diff --check</code></td>
121
+ <td>clean</td>
122
+ </tr>
123
+ <tr>
124
+ <td>Memory cascade, cap and reference-limit reproductions</td>
125
+ <td>executed before the fixes; covered by tests after</td>
126
+ </tr>
127
+ <tr>
128
+ <td>Overlay cost benchmark</td>
129
+ <td>executed before the fix (36 s per call at 4,096 pending commands)</td>
130
+ </tr>
131
+ <tr>
132
+ <td>Real CLI probes (<code>claude --help</code>, <code>codex mcp get</code>, <code>codex features list</code>)</td>
133
+ <td>executed against the installed CLIs; claims in <code>auto-team.md</code> about them hold</td>
134
+ </tr>
135
+ </tbody></table>
136
+ </div><p><a href="index.html">Documentation library</a> · <a href="architecture.html">Development guide</a></p>
137
+ </article><footer><a href="https://github.com/midhunxavier/code-flow/blob/main/docs/dynamic-teams-implementation-review-1.md">Edit this page on GitHub ↗</a><span>code-flow · 0.1.0-preview.3 · <a href="font-license.txt">Font license</a></span></footer><nav class="pagination" aria-label="Adjacent guides"><a href="dynamic-teams-implementation-plan.html"><small>← Previous</small>Dynamic teams, workflows, messaging, and memory</a><a href="worker-permission-verification.html"><small>Next →</small>Live worker permission verification</a></nav></main>
138
+ <aside class="on-page" aria-label="On this page"><strong>On this page</strong><a class="depth-2" href="#verdict">Verdict</a><a class="depth-2" href="#fixed-in-this-review">Fixed in this review</a><a class="depth-3" href="#runtime-and-scheduling">Runtime and scheduling</a><a class="depth-3" href="#memory-store">Memory store</a><a class="depth-3" href="#live-tool-bridge-and-adapters">Live tool bridge and adapters</a><a class="depth-3" href="#ui">UI</a><a class="depth-3" href="#evaluation-and-runner">Evaluation and runner</a><a class="depth-3" href="#documents">Documents</a><a class="depth-2" href="#open-findings-ranked">Open findings, ranked</a><a class="depth-2" href="#what-to-avoid-next-time">What to avoid next time</a><a class="depth-2" href="#suggestions">Suggestions</a><a class="depth-2" href="#verification-performed">Verification performed</a></aside>
139
+ <aside id="help-panel" hidden aria-labelledby="help-title"><div class="chat-heading"><div><span class="eyebrow">Your AI companion</span><h2 id="help-title">Ask code-flow</h2></div><button id="close-help" aria-label="Close AI companion">✕</button></div><div class="chat-toolbar"><span>Grounded in your docs</span><button id="new-chat">New chat</button></div><div id="help-messages" role="log" aria-label="Help conversation" aria-live="polite"><div id="chat-welcome"><span class="chat-mark" aria-hidden="true">✦</span><h3>What would you like to do?</h3><p>Let’s find your next step. Ask about setup, workflows or something that’s unclear.</p><div class="suggestions"><button type="button" data-question="How do I start my first run?">Start my first run ↗</button><button type="button" data-question="What should I do when a check fails?">Understand a failed check ↗</button></div></div></div><p id="help-status" role="status">Checking your installed CLIs…</p><button id="retry-help" hidden>Retry connection</button><form id="help-form" hidden><label class="sr-only" for="question">Your question</label><textarea id="question" rows="3" maxlength="4000" placeholder="Ask a question…" required></textarea><div class="composer-controls"><label class="sr-only" for="help-agent">Use your CLI</label><select id="help-agent"></select><button type="button" id="stop-help" hidden>Stop</button><button class="primary" id="send-help" aria-label="Send message">Send ↗</button></div><small>Uses your CLI login and quota. Shift + Enter for a new line.</small></form><a id="help-guide" href="help.html">About your local companion →</a></aside></div>
140
+ <dialog id="search-dialog" aria-labelledby="search-title"><div class="dialog-title"><h2 id="search-title">Search documentation</h2><button data-close="search-dialog" aria-label="Close search">✕</button></div><label class="sr-only" for="search">Search all guides</label><input id="search" type="search" placeholder="Search workflows, settings, troubleshooting…" autocomplete="off"><div id="search-results" aria-live="polite"></div></dialog>
141
+ </body></html>
package/public/docs/dynamic-teams-plan-review-0.html ADDED
@@ -0,0 +1,204 @@
1
+ <!doctype html>
2
+ <html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><meta name="description" content="Review 0: Dynamic teams implementation plan — code-flow guides and reference"><title>Review 0: Dynamic teams implementation plan · code-flow</title><link rel="icon" href="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI2NCIgaGVpZ2h0PSI2NCIgdmlld0JveD0iMCAwIDY0IDY0Ij4KICA8Y2lyY2xlIGN4PSIzMiIgY3k9IjMyIiByPSIzMCIgZmlsbD0iIzFlMWYxYSIgc3Ryb2tlPSIjM2Q0MDM2IiBzdHJva2Utd2lkdGg9IjIiLz4KICA8c3ZnIHg9IjE1IiB5PSIxNSIgd2lkdGg9IjM0IiBoZWlnaHQ9IjM0IiB2aWV3Qm94PSIwIDAgMjQgMjQiIGZpbGw9Im5vbmUiIHN0cm9rZT0iI2VjZWJlNCIgc3Ryb2tlLXdpZHRoPSIyIiBzdHJva2UtbGluZWNhcD0icm91bmQiIHN0cm9rZS1saW5lam9pbj0icm91bmQiPgogICAgPHBhdGggZD0iTTEyIDNsOSA1LTkgNS05LTV6TTMgMTNsOSA1IDktNU0zIDE3LjVsOSA1IDktNSIvPgogIDwvc3ZnPgo8L3N2Zz4K"><link rel="stylesheet" href="style.css"><script src="app.js" defer></script></head>
3
+ <body data-page="dynamic-teams-plan-review-0"><a class="skip-link" href="#content">Skip to content</a>
4
+ <header class="topbar"><a class="brand" href="index.html"><img src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI2NCIgaGVpZ2h0PSI2NCIgdmlld0JveD0iMCAwIDY0IDY0Ij4KICA8Y2lyY2xlIGN4PSIzMiIgY3k9IjMyIiByPSIzMCIgZmlsbD0iIzFlMWYxYSIgc3Ryb2tlPSIjM2Q0MDM2IiBzdHJva2Utd2lkdGg9IjIiLz4KICA8c3ZnIHg9IjE1IiB5PSIxNSIgd2lkdGg9IjM0IiBoZWlnaHQ9IjM0IiB2aWV3Qm94PSIwIDAgMjQgMjQiIGZpbGw9Im5vbmUiIHN0cm9rZT0iI2VjZWJlNCIgc3Ryb2tlLXdpZHRoPSIyIiBzdHJva2UtbGluZWNhcD0icm91bmQiIHN0cm9rZS1saW5lam9pbj0icm91bmQiPgogICAgPHBhdGggZD0iTTEyIDNsOSA1LTkgNS05LTV6TTMgMTNsOSA1IDktNU0zIDE3LjVsOSA1IDktNSIvPgogIDwvc3ZnPgo8L3N2Zz4K" width="30" height="30" alt=""><strong>Code Flow</strong><span>Docs</span></a><button class="search-trigger" id="open-search">Search documentation <kbd>⌘ K</kbd></button><div class="top-actions"><a href="https://github.com/midhunxavier/code-flow">GitHub ↗</a><button id="theme" aria-label="Change color theme">Theme</button><button id="open-help" class="primary" hidden aria-expanded="false" aria-controls="help-panel">Ask code-flow</button><button id="menu" aria-label="Toggle documentation navigation" aria-expanded="false" aria-controls="sidebar">☰</button></div></header>
5
+ <div class="layout"><nav class="sidebar" id="sidebar" aria-label="Documentation"><section><h2>Get started</h2><a href="index.html" >Overview</a><a href="installation.html" >Install Code Flow preview</a><a href="getting-started.html" >Getting started</a><a href="patterns.html" >Team patterns</a><a href="acp-agents.html" >ACP coding agents</a><a href="help.html" >Ask code-flow</a></section><section><h2>Work with agents</h2><a href="runs.html" >Runs and workspace</a><a href="auto-team.html" >Team</a><a href="project-teams.html" >Project missions (preview)</a><a href="review-inbox.html" >Review inbox</a><a href="verification.html" >Verification and review</a><a href="github.html" >GitHub, review and shipping</a><a href="github-review-threads.html" >GitHub review threads</a><a href="task-reruns.html" >Selective task reruns</a><a href="deferred-runs.html" >Deferred runs</a></section><section><h2>Your workspace</h2><a href="configuration.html" >Configuration</a><a href="context-inspection.html" >Context and budgets</a><a href="project-conventions.html" >Versioned project conventions</a><a href="checkpoint-review.html" >Checkpoints and reversions</a><a href="launch-profiles.html" >Service launch profiles</a><a href="code-intelligence.html" >Code intelligence</a><a href="architecture-explorer.html" >Architecture explorer</a><a href="memory-storage.html" >Project memory</a><a href="memory-claims.html" >Semantic claim review</a><a href="coordinated-changes.html" >Coordinated changes</a></section><section><h2>Connect and collaborate</h2><a href="team-collaboration.html" >Team collaboration</a><a href="shared-projects.html" >Shared project accounts</a><a href="ssh-projects.html" >SSH projects</a><a href="remote-workers.html" >Remote agent workers</a><a href="code-hosts.html" >GitLab and Bitbucket code workflows</a><a href="external-sources.html" >Read-only external sources</a><a href="automations.html" >Automations and away mode</a><a href="notifications.html" >Outbound notifications</a></section><section><h2>Operate safely</h2><a href="security.html" >Security, subscriptions and caveats</a><a href="filesystem-policy.html" >Project filesystem policy</a><a href="agent-containers.html" >Agent containers</a><a href="filtered-tasks.html" >Filtered Docker tasks</a><a href="dependency-discovery.html" >Dependency discovery</a><a href="maintenance.html" >Backup and maintenance</a></section><section><h2>Build and extend</h2><a href="architecture.html" >Architecture and development</a><a href="api.html" >Local API and command-line client</a><a href="extensions.html" >Provider and workflow extensions</a><a href="provider-compatibility.html" >Provider compatibility</a><a href="accessibility.html" >Accessibility acceptance</a><a href="performance.html" >Performance</a><a href="run-storage.html" >Run storage</a><a href="documentation.html" >Documentation and GitHub Pages</a><a href="releasing.html" >Preparing a preview release</a><a href="vscode.html" >Code Flow for VS Code</a></section><section><h2>Engineering records</h2><a href="application-improvements.html" >Application improvement program</a><a href="project-first-navigation-plan.html" >Project navigation review and implementation plan</a><a href="dynamic-teams-evaluation.html" >Dynamic teams: implementation evidence and rollout decision</a><a href="dynamic-teams-implementation-plan.html" >Dynamic teams, workflows, messaging, and memory</a><a href="dynamic-teams-implementation-review-1.html" >Review 1: the dynamic teams implementation</a><a href="worker-permission-verification.html" >Live worker permission verification</a><a href="dynamic-teams-plan-review-0.html" aria-current="page">Review 0: Dynamic teams implementation plan</a><a href="project-teams-implementation-plan.html" >Standing project teams implementation plan</a><a href="performance-results.html" >Measured performance: 19 October 2026</a></section><a class="app-link" id="back-app" hidden href="/">← Back to app</a></nav>
6
+ <main id="content" tabindex="-1"><div class="breadcrumb">Documentation <span>/</span> Engineering records</div><article><h1 id="review-0-dynamic-teams-implementation-plan">Review 0: Dynamic teams implementation plan</h1>
7
+ <blockquote>
8
+ <p>Engineering record. Status, measurements and decisions below describe the recorded implementation or review. For current usage, start with the <a href="index.html">documentation library</a>.</p>
9
+ </blockquote>
10
+ <p>Reviewed: <code>docs/dynamic-teams-implementation-plan.md</code>, uncommitted, dated 17 October 2026, written against <code>ee246c7</code> (the current <code>main</code>).</p>
11
+ <p>Lens: the product promise the plan exists to serve.</p>
12
+ <blockquote>
13
+ <p>Give code-flow a task; it assembles an appropriate team from your available agents, coordinates their work, and delivers a verified result with reusable project knowledge.</p>
14
+ </blockquote>
15
+ <p>Method: every claim the plan makes about the current code was checked against the working tree, and the four external references were fetched. Findings cite files and functions so they can be re-checked.</p>
16
+ <h2 id="verdict">Verdict</h2>
17
+ <p>The plan is a careful systems design. Its invariants are the right ones: no silent success, unknown is not a pass, persist before dispatch, at-least-once delivery with idempotent application, agents propose and the runtime verifies. The record model is coherent and the acceptance tests are specific. None of the factual claims about the codebase are wrong.</p>
18
+ <p>The problem is the order. The promise becomes visible to a user in Phase 5 of 8, after a storage migration (P1), a memory subsystem (P2), a new scheduler (P3) and a messaging layer (P4) have each shipped. The plan&#39;s own stated reason for a new recovery model is already met by the existing journal, so the biggest early investment rests on a justification that does not hold. The first user-visible milestone the plan names, &quot;the restart-safe question-and-answer scenario at the end of Phase 4&quot;, is a reliability demo, not the promise.</p>
19
+ <p>Recommendation: do not approve the phase order as written. Approve the invariants, the schemas, and the adapter capability inventory. Add a thin vertical slice of the promise on the existing engine before Phase 1, and let what it measures decide the storage, scheduler and messaging investments. Details are in &quot;Proposed re-sequencing&quot; below.</p>
20
+ <h2 id="what-the-plan-gets-right">What the plan gets right</h2>
21
+ <ul>
22
+ <li><strong>code-flow owns the team.</strong> This is confirmed by the vendor docs the plan cites: Claude&#39;s agent teams do not spawn under <code>-p</code>, which is how code-flow runs Claude, and they are experimental with no session resumption for in-process teammates. There is nothing to delegate to.</li>
23
+ <li><strong>Member identity separate from provider identity.</strong> <code>AgentId</code> is <code>&quot;claude&quot; | &quot;codex&quot; | &quot;agy&quot;</code> (<code>src/adapters/types.ts:9</code>). <code>resolveAuto</code> deduplicates within a role, and <code>addNote</code> targets an <code>AgentId</code>, so a note to &quot;codex&quot; goes to whichever Codex turn starts next (<code>src/engine.ts:617</code>). Two Codex workers really are indistinguishable today for notes, usage and Insights.</li>
24
+ <li><strong>Verification in the runtime, bound to evidence.</strong> This extends what <code>check()</code>, <code>integrity.ts</code> and <code>fixUntilGreen</code> already do, and keeps the product&#39;s distinguishing rule: a result is done when the tests pass, not when an agent says so.</li>
25
+ <li><strong>Turn-boundary messaging first, live steering as an enhancement.</strong> Only Codex app-server can take input mid-turn (<code>turn/steer</code>); Claude takes its prompt on stdin and agy has no input path. Making correctness independent of live transport is correct.</li>
26
+ <li><strong>Candour about unknowns.</strong> The adapter matrix marks untested capabilities unknown, nested vendor subagents are called out as unaccountable, and the plan refuses to estimate dates before the spikes. That is the right posture.</li>
27
+ <li><strong>Explicit outcomes with gaps.</strong> &quot;A gap must never become success merely because all runnable tasks ended&quot; is the single most important product rule in the document.</li>
28
+ </ul>
29
+ <h2 id="major-findings">Major findings</h2>
30
+ <h3 id="1-the-promise-arrives-last">1. The promise arrives last</h3>
31
+ <p>Phases 1 to 4 build durable state, memory, a scheduler and mailboxes. A user sees &quot;describe the task, watch the team work&quot; only in P5, and only from the normal composer in P7. The &quot;first collaboration release&quot; after P4 still requires a hand-configured team and a hand-supplied workflow, which is a worse version of the supervisor pattern that exists today.</p>
32
+ <p>The existing supervisor pattern already does more than half of the promise: a model decomposes the task, writes contracts, assigns workers, workers build in parallel worktrees, the runtime integrates, checks, and gets an independent review, and the user approves the split before anything runs (<code>src/patterns/supervisor.ts</code>). The delta to the promise is: the coordinator chooses members and models rather than assigning among a user-picked roster; more than one round; and members that can ask each other questions. The first two are cheap on the existing engine. Only the third needs new machinery, and the plan has not shown how often it is needed.</p>
33
+ <p>Recommendation: build the delta first, on the engine that exists, and measure. See &quot;Proposed re-sequencing&quot;.</p>
34
+ <h3 id="2-the-new-runtimes-recovery-justification-is-already-met">2. The new runtime&#39;s recovery justification is already met</h3>
35
+ <p>Section 2, point 2 says a dynamic workflow &quot;must not reconstruct the team by asking the model to plan again&quot;, and presents this as the reason pattern replay is unsuitable. But <code>TeamContext.remember()</code> journals the result of every <code>decide()</code> and <code>ask()</code> under <code>kind:identity#occurrence</code> and returns the recorded value on resume (<code>src/engine.ts:714</code>). A coordinator&#39;s plan produced through <code>decide()</code> is replayed, not re-asked. As long as the pattern&#39;s control flow is a deterministic function of journaled values, which is the existing contract, a dynamic pattern recovers without re-planning. Claude&#39;s own dynamic workflows use exactly this model: replay by prompt equality, with the first differing agent and everything after it re-run.</p>
36
+ <p>Where the journal genuinely falls short is different and should be stated as such: long-lived members with mailboxes that outlive any one pattern pass, and event-driven wakeups that are not expressible as a linear replay. Those are the real reasons to consider a new runtime. Whether they are worth it depends on how often members need to talk, which nobody has measured.</p>
37
+ <h3 id="3-sqlite-is-a-platform-decision-presented-as-a-spike">3. SQLite is a platform decision presented as a spike</h3>
38
+ <p>The repository has five runtime dependencies and no native module. <code>package.json</code> says <code>node &gt;= 20</code>, and CI runs Node 20 on Linux. <code>node:sqlite</code> does not exist on Node 20. That leaves three options, each a real cost: a native dependency with prebuilt binaries and a node-gyp fallback; a WASM build whose durability semantics differ; or dropping Node 20. Phase 0 defers the choice, but every later phase is designed around SQLite semantics (transactions, outbox, leases, migrations), so the &quot;spike&quot; is not free to fail.</p>
39
+ <p>What the plan actually needs is narrower than a database: atomic commit of a small batch of related records, crash-safe recovery, and idempotent operation application. The server is already the single writer (the one-server lock in <code>src/store.ts</code>). One fsynced append of a JSON line holding the whole batch is atomic under that constraint, torn lines are already detected and skipped (<code>test/store-reliability.test.ts</code>), and in-memory projections rebuilt at load are how runs work now. The journal is already synced and awaited before the pattern moves on (<code>src/store.ts:167</code>); only the event log append is best-effort. The plan&#39;s phrase &quot;the current best-effort logging behavior is not sufficient&quot; is true of the event log and not of the journal, and should say so.</p>
40
+ <p>Recommendation: state the required storage properties, not the technology. Default to extending the existing append-only store with batch records and a snapshot, and keep SQLite as the fallback if a measured need appears (query volume, project memory search at scale). If SQLite is chosen anyway, make the Node 20 decision explicitly in P0 rather than letting the driver choice make it.</p>
41
+ <h3 id="4-the-reference-designs-use-simpler-persistence-than-the-plan">4. The reference designs use simpler persistence than the plan</h3>
42
+ <p>The plan cites Claude agent teams and Claude dynamic workflows as references. Both were checked. Agent teams use one JSON file per mailbox and file locking for task claims; dynamic workflows persist per-agent results and replay by prompt equality; neither uses a transactional store, an outbox or leases. They also document limitations the plan should expect to inherit: task status can lag, teammates stop early, the lead can declare done before tasks finish. Those are prompt and policy problems, not storage problems, and the plan&#39;s verification-in-runtime stance is the right answer to them. The reference designs therefore support a lighter P1 than the plan proposes.</p>
43
+ <h3 id="5-appropriate-team-has-no-definition">5. &quot;Appropriate team&quot; has no definition</h3>
44
+ <p>The promise&#39;s load-bearing word is &quot;appropriate&quot;. The plan says routing must stop deduplicating providers and must expose fallback reasons, but it never states the composition policy the coordinator is constrained by. The existing product encodes composition wisdom that should carry over as rules, not be rediscovered by a model:</p>
45
+ <ul>
46
+ <li>A reviewer or judge should be a different provider from the author (&quot;a good default is to have a different vendor review&quot;, <code>docs/patterns.md</code>). The supervisor pattern warns when it cannot do this.</li>
47
+ <li>Routing skips providers at 90 percent of a usage window or recently limited (<code>src/routing.ts</code>), and prefers the provider whose code passes most often in this repo (<code>src/stats.ts</code>).</li>
48
+ <li>A small task uses one worker. The plan says this but gives the coordinator no rule for it.</li>
49
+ </ul>
50
+ <p>Recommendation: write the composition policy as validation rules in P0 (minimum and maximum members by task size signal, independence constraints for review, quota and ranking inputs, user-pinned choices), and have the coordinator propose within them. The acceptance tests in P5 then test the policy, not a model&#39;s taste.</p>
51
+ <h3 id="6-the-plan-approval-checkpoint-is-missing-from-the-promises-flow">6. The plan-approval checkpoint is missing from the promise&#39;s flow</h3>
52
+ <p><code>ctx.approve(&quot;plan&quot;)</code> exists and the supervisor pattern uses it to show the split and contracts before any worker starts (<code>src/engine.ts:595</code>, <code>src/patterns/supervisor.ts</code>). For a product that assembles a team and spends the user&#39;s subscription quota, approving the team and plan is the most important control, and it already exists. The plan mentions &quot;existing review/permission choices&quot; in P7 and an &quot;awaiting input&quot; outcome, but never names the checkpoint: show the proposed members, models, tasks, acceptance criteria and estimated turns, and let the user approve, revise, or reject before dispatch. Section 3.1&#39;s &quot;requirements with stable IDs&quot; should be the editable list the user approves here, rather than a model-extracted artifact treated as ground truth.</p>
53
+ <h3 id="7-project-memory-has-no-trust-boundary">7. Project memory has no trust boundary</h3>
54
+ <p>Runs started from issues, PRs or alerts by people outside the repo are locked down: Safe mode, no <code>.env</code>, checks in Docker (<code>src/engine.ts:2168</code>). The plan adds <code>publish_finding</code> and promotion to project memory, which every later run reads. An untrusted issue that persuades a worker to publish a &quot;convention&quot; would then reach every future run in that project. Section 6.3 says memory is &quot;not an instruction source allowed to override the current user or permissions&quot;, but offers no mechanism.</p>
55
+ <p>Recommendation: memory entries carry the originating run&#39;s trust level; locked-down runs cannot promote automatically and their proposals wait for the user; retrieval marks entries by provenance; the lockdown rules extend to messages between members in a locked-down run. Add this to P2&#39;s acceptance tests. The existing <code>UntrustedSourceError</code> and <code>lockdown</code> fields are the hooks.</p>
56
+ <h3 id="8-coordinator-cost-is-unmeasured-until-phase-8">8. Coordinator cost is unmeasured until Phase 8</h3>
57
+ <p>The product&#39;s premise is subscriptions, and the vendor docs the plan cites say teams &quot;use significantly more tokens&quot;. Each coordinator wake is a CLI session resume with full context. The plan measures &quot;coordinator overhead&quot; in P8, after the architecture is fixed. It should be the first number produced, because it decides how event-driven the coordinator can afford to be (per event, per wave, or per phase) and therefore how much of P3 and P4 is needed. A related gap: a long-lived coordinator session grows until the CLI compacts it; the plan&#39;s portable checkpoint is the answer but is never connected to the coordinator.</p>
58
+ <h3 id="9-memory-before-execution-is-the-wrong-order">9. Memory before execution is the wrong order</h3>
59
+ <p>P2 builds relevance selection, context budgets, manifests and promotion before P3 produces any workflow data to select from. Relevance cannot be tested without tasks, contracts and findings flowing. Split P2: the parts P3 and P4 need (private checkpoints, accepted team contracts, context manifest) come first; project memory, promotion, retention and deletion come after P5, when there are real findings to promote and the lockdown rule from finding 7 can be tested against real runs.</p>
60
+ <h3 id="10-the-record-model-is-heavier-than-turn-boundary-messaging-needs">10. The record model is heavier than turn-boundary messaging needs</h3>
61
+ <p>Twelve records and three stored state machines. At turn boundaries, &quot;delivery&quot; is &quot;included in the prompt of attempt X&quot;, which the context manifest already records; a separate Delivery record only earns its keep with live steering in P6. Member status (idle, running, waiting) is derivable from the member&#39;s active attempt and open requests, so storing it invites drift. Message, Request and Delivery can start as one record with a type. Keep the plan&#39;s names but defer the splits until a phase needs them.</p>
62
+ <h2 id="minor-findings">Minor findings</h2>
63
+ <ul>
64
+ <li><strong>Budget semantics change silently.</strong> P3 says &quot;resume alone does not grant an unlimited new budget&quot;. Today resume explicitly grants &quot;a fresh budget&quot; (<code>src/engine.ts:2285</code>, <code>docs/runs.md:82</code>), and that is a documented product decision. Changing it for team runs is defensible; say that legacy and team runs differ, and why.</li>
65
+ <li><strong>Verification binding is over-specified.</strong> Binding evidence to commit, contract revision, workflow revision, check definition and environment fingerprint is five dimensions where two (commit SHA and check command, plus setup fingerprint when <code>.codeflow/config.json</code> sets one) cover the cases that occur. Start there; add dimensions when a test shows they are needed.</li>
66
+ <li><strong><code>findPattern</code> is a small problem.</strong> Four call sites (<code>src/server.ts:406</code>, <code>:956</code>, <code>src/engine.ts:1830</code>, <code>:2291</code>), not a broad audit. And an unknown pattern id already makes resume fail safely with &quot;Unknown pattern&quot;. Recording team runs under an id older code-flow does not know gives P8&#39;s &quot;older executables must not execute team-v1 runs&quot; for free; say so instead of designing a schema-version rejection.</li>
67
+ <li><strong>SSE cursors.</strong> <code>Last-Event-ID</code> is honoured only within one server start (<code>src/server.ts:626</code>). The plan&#39;s persistent cursor requirement is real; note that it benefits legacy runs too and could ship independently.</li>
68
+ <li><strong><code>CODEFLOW_TOKEN</code> is already withheld from agents</strong> (<code>src/env.ts:8</code>). P6 presents this as a new rule; cite the existing one and extend it to the scoped credential.</li>
69
+ <li><strong>Claude&#39;s write mode uses an <code>--allowedTools</code> allow-list</strong> (<code>src/adapters/claude.ts:81</code>). P6&#39;s MCP bridge tools must be added to it per trust level; the capability inventory in P0 should include this.</li>
70
+ <li><strong>Three new source directories</strong> (<code>src/team/</code>, <code>src/workflows/</code>, <code>src/memory/</code>) in a codebase that is flat apart from <code>adapters/</code> and <code>patterns/</code>. Not wrong, but the architecture doc&#39;s layout table will need the same treatment, and roughly forty new files for a 22k-line codebase is a scale the plan should state plainly.</li>
71
+ <li><strong>Mermaid diagram.</strong> <code>Runtime --&gt; UI</code> hides that the UI today is driven by the run snapshot plus SSE; the plan&#39;s &quot;projections&quot; should be additions to that snapshot where possible rather than five new GET routes with their own pagination.</li>
72
+ <li><strong>Section 5.1 operations through &quot;validated turn results first&quot;.</strong> This is the right first transport and is under-sold: it is also the only transport that works identically for all three CLIs, which makes it the one to design the protocol around, with live tools conforming to it rather than the reverse.</li>
73
+ <li><strong>&quot;Dynamic-worker prompt&quot; in P4</strong> refers to <code>preamble()</code> in <code>src/patterns/prompts.ts:10</code> (&quot;nobody can answer questions&quot;). The Codex adapter has the same assumption when declining input requests (<code>src/adapters/codex-app-server.ts:242</code>). Both change together.</li>
74
+ </ul>
75
+ <h2 id="claims-checked-against-the-code">Claims checked against the code</h2>
76
+ <div class="table-scroll" tabindex="0"><table>
77
+ <thead>
78
+ <tr>
79
+ <th>Plan claim</th>
80
+ <th>Status</th>
81
+ <th>Evidence</th>
82
+ </tr>
83
+ </thead>
84
+ <tbody><tr>
85
+ <td><code>AgentId</code> means a provider</td>
86
+ <td>Confirmed</td>
87
+ <td><code>src/adapters/types.ts:9</code></td>
88
+ </tr>
89
+ <tr>
90
+ <td>Role resolution deduplicates providers</td>
91
+ <td>Confirmed</td>
92
+ <td><code>resolveAuto</code> in <code>src/routing.ts</code>: <code>[...new Set(chosen)]</code></td>
93
+ </tr>
94
+ <tr>
95
+ <td>Notes can target a provider</td>
96
+ <td>Confirmed</td>
97
+ <td><code>RunManager.addNote(id, text, agent?: AgentId)</code>, <code>takeNotes</code></td>
98
+ </tr>
99
+ <tr>
100
+ <td>Replay uses operation identities plus occurrence counts</td>
101
+ <td>Confirmed</td>
102
+ <td><code>remember()</code> keys <code>kind:identity#n</code>, <code>src/engine.ts:714</code></td>
103
+ </tr>
104
+ <tr>
105
+ <td>Prompt framing says nobody can answer</td>
106
+ <td>Confirmed</td>
107
+ <td><code>src/patterns/prompts.ts:10</code></td>
108
+ </tr>
109
+ <tr>
110
+ <td>JSONL history, replay journal, server lock in <code>store.ts</code></td>
111
+ <td>Confirmed</td>
112
+ <td><code>src/store.ts:13</code>, <code>:167</code>, <code>:329</code></td>
113
+ </tr>
114
+ <tr>
115
+ <td>Journal writes are best-effort</td>
116
+ <td>Partly wrong</td>
117
+ <td>Journal entries are fsynced and awaited; the event log is best-effort (<code>writeHealth</code>)</td>
118
+ </tr>
119
+ <tr>
120
+ <td>CI matrix Node 20/22 Linux, 22 macOS</td>
121
+ <td>Confirmed</td>
122
+ <td><code>.github/workflows/ci.yml</code></td>
123
+ </tr>
124
+ <tr>
125
+ <td>No SQLite today</td>
126
+ <td>Confirmed</td>
127
+ <td><code>package.json</code>: five runtime deps, none native</td>
128
+ </tr>
129
+ <tr>
130
+ <td>Codex live steering exists; others do not</td>
131
+ <td>Confirmed</td>
132
+ <td><code>turn/steer</code> in <code>src/adapters/codex-app-server.ts</code>; Claude prompt on stdin</td>
133
+ </tr>
134
+ <tr>
135
+ <td>APIs assume <code>findPattern</code> succeeds</td>
136
+ <td>Confirmed, small</td>
137
+ <td>Four call sites</td>
138
+ </tr>
139
+ <tr>
140
+ <td>Projects hold several repos</td>
141
+ <td>Confirmed</td>
142
+ <td><code>Project.repos: string[]</code> in <code>src/projects.ts</code></td>
143
+ </tr>
144
+ <tr>
145
+ <td>Recurring findings threshold</td>
146
+ <td>Confirmed</td>
147
+ <td><code>RECURRING = 2</code> in <code>src/learnings.ts</code></td>
148
+ </tr>
149
+ <tr>
150
+ <td>Four external references</td>
151
+ <td>All resolve</td>
152
+ <td>Claude workflows, Claude agent teams, Codex subagents, LangGraph memory</td>
153
+ </tr>
154
+ </tbody></table>
155
+ </div><h2 id="proposed-re-sequencing">Proposed re-sequencing</h2>
156
+ <h3 id="slice-0-the-promise-on-the-existing-engine">Slice 0: the promise on the existing engine</h3>
157
+ <p>Add one opt-in pattern, &quot;Auto team&quot;, written against <code>TeamContext</code> like every other pattern. No new storage, no mailboxes.</p>
158
+ <ol>
159
+ <li><strong>Plan.</strong> The coordinator (user&#39;s choice or routed) runs one read-only <code>decide()</code> against a <code>TEAM_PLAN_SCHEMA</code>: acceptance criteria, members (<code>id</code>, role, provider, model, effort), tasks (<code>id</code>, instructions, owner, depends-on, owned paths), contracts. The runtime validates it against the composition policy from finding 5: installed providers, quota, member cap, acyclic dependencies, reviewer independence.</li>
160
+ <li><strong>Approve.</strong> <code>ctx.approve(&quot;plan&quot;)</code> shows the team and plan. Revise and reject work as they do in the supervisor pattern.</li>
161
+ <li><strong>Execute in waves.</strong> Ready tasks run with <code>ctx.parallel()</code>; each task is an <code>ask()</code> with <code>identity: task.id</code> so the journal key is stable; each member keeps a <code>memberId</code> to session map so two Codex members stay distinct; each task&#39;s worktree starts from the integration branch head, which is the plan&#39;s &quot;artifact dependency through integration&quot;.</li>
162
+ <li><strong>Coordinate per wave.</strong> After integrating and checking a wave, the coordinator gets one bounded <code>decide()</code> against a <code>REVISION_SCHEMA</code>: done, new tasks, reassignments, answers to questions members raised in their structured outcomes. Cap the rounds. This is event-driven coordination at wave granularity.</li>
163
+ <li><strong>Verify.</strong> Independent review by a different provider, bounded repair, final check, <code>setVerdict</code> and <code>setFacts</code>, result with gaps listed.</li>
164
+ </ol>
165
+ <p>Members ask questions by including them in a structured turn outcome; the owner or coordinator answers in the next wave&#39;s prompt. Coarse, but it is turn-boundary messaging, and it produces the number nobody has: how often a member needs an answer before it can continue.</p>
166
+ <p>Recovery is the existing journal. Interrupted runs resume without re-planning (finding 2).</p>
167
+ <p>What Slice 0 proves or refutes, with fake agents in CI and a few real opt-in runs:</p>
168
+ <ul>
169
+ <li>whether a coordinator produces teams a user accepts at the approval step, and how often it is revised;</li>
170
+ <li>coordinator turns and tokens per task as a fraction of worker spend (finding 8);</li>
171
+ <li>how often a wave stalls on a question, which decides whether P4 is needed at all or whether wave-granularity is enough;</li>
172
+ <li>whether two same-provider members cause any confusion beyond notes and Insights, which sizes P1.</li>
173
+ </ul>
174
+ <p>Exit criteria: fake-agent run of the section 9 scenario minus restart-under-delivery; a user can start it from the composer behind an opt-in flag; measurements recorded in the plan.</p>
175
+ <h3 id="then">Then</h3>
176
+ <ul>
177
+ <li><strong>P0 in parallel with Slice 0:</strong> schemas (Slice 0 needs them), adapter capability matrix, composition policy, verification policies by task kind.</li>
178
+ <li><strong>Storage decision after Slice 0,</strong> from the required properties in finding 3. The likely outcome is batch records on the existing store plus a per-run snapshot. If SQLite wins, make the Node 20 call explicitly.</li>
179
+ <li><strong>P3 before P2,</strong> and P2 split as in finding 9.</li>
180
+ <li><strong>P4 only if Slice 0 shows waves are not enough.</strong> If a member rarely needs an answer mid-task, the mailbox layer can be a later enhancement rather than a prerequisite for the MVP.</li>
181
+ <li><strong>P5 becomes</strong> hardening Slice 0&#39;s coordinator (reassignment with handover, member retirement, strategies as reusable sub-plans) rather than building it.</li>
182
+ <li><strong>P6, P7, P8</strong> as planned, with finding 7&#39;s trust rule in P2&#39;s tests and finding 6&#39;s checkpoint in P7&#39;s composer work.</li>
183
+ </ul>
184
+ <h2 id="questions-to-answer-before-approval">Questions to answer before approval</h2>
185
+ <ol>
186
+ <li>What is the composition policy? Write the rules the coordinator must satisfy; they are the product.</li>
187
+ <li>What team-messaging frequency would justify P4&#39;s mailboxes over wave-boundary answers? Pick the threshold before measuring.</li>
188
+ <li>Is dropping Node 20 acceptable if the storage spike points at <code>node:sqlite</code>? If not, say now that native and WASM drivers are the only candidates.</li>
189
+ <li>Who may promote to project memory from a locked-down run? The answer should be &quot;nobody, without the user&quot;.</li>
190
+ <li>What does the user see and approve before any member is dispatched, and does changing the goal mid-run go through the same checkpoint?</li>
191
+ <li>What is the cost ceiling for coordination as a share of a run&#39;s agent turns, and what does the coordinator do when it reaches it?</li>
192
+ </ol>
193
+ <h2 id="notes-on-the-document-itself">Notes on the document itself</h2>
194
+ <ul>
195
+ <li>Tight, well-structured, and unusually honest about unknowns. The invariants in 3.3, 3.5, 5.2 and 5.3 should be lifted verbatim into the architecture doc when any of this ships.</li>
196
+ <li>&quot;Likely files&quot; per phase is useful. Add &quot;likely files removed or shrunk&quot;: the plan adds a great deal and retires nothing, and the supervisor pattern in particular should be slated to become a strategy under the new mode rather than a parallel implementation.</li>
197
+ <li>The <code>docs/README.md</code> link added alongside this plan describes it as proposed. Keep that word until Slice 0 has numbers.</li>
198
+ </ul>
199
+ <p><a href="index.html">Documentation library</a> · <a href="architecture.html">Development guide</a></p>
200
+ </article><footer><a href="https://github.com/midhunxavier/code-flow/blob/main/docs/dynamic-teams-plan-review-0.md">Edit this page on GitHub ↗</a><span>code-flow · 0.1.0-preview.3 · <a href="font-license.txt">Font license</a></span></footer><nav class="pagination" aria-label="Adjacent guides"><a href="worker-permission-verification.html"><small>← Previous</small>Live worker permission verification</a><a href="project-teams-implementation-plan.html"><small>Next →</small>Standing project teams implementation plan</a></nav></main>
201
+ <aside class="on-page" aria-label="On this page"><strong>On this page</strong><a class="depth-2" href="#verdict">Verdict</a><a class="depth-2" href="#what-the-plan-gets-right">What the plan gets right</a><a class="depth-2" href="#major-findings">Major findings</a><a class="depth-3" href="#1-the-promise-arrives-last">1. The promise arrives last</a><a class="depth-3" href="#2-the-new-runtimes-recovery-justification-is-already-met">2. The new runtime&#39;s recovery justification is already met</a><a class="depth-3" href="#3-sqlite-is-a-platform-decision-presented-as-a-spike">3. SQLite is a platform decision presented as a spike</a><a class="depth-3" href="#4-the-reference-designs-use-simpler-persistence-than-the-plan">4. The reference designs use simpler persistence than the plan</a><a class="depth-3" href="#5-appropriate-team-has-no-definition">5. &quot;Appropriate team&quot; has no definition</a><a class="depth-3" href="#6-the-plan-approval-checkpoint-is-missing-from-the-promises-flow">6. The plan-approval checkpoint is missing from the promise&#39;s flow</a><a class="depth-3" href="#7-project-memory-has-no-trust-boundary">7. Project memory has no trust boundary</a><a class="depth-3" href="#8-coordinator-cost-is-unmeasured-until-phase-8">8. Coordinator cost is unmeasured until Phase 8</a><a class="depth-3" href="#9-memory-before-execution-is-the-wrong-order">9. Memory before execution is the wrong order</a><a class="depth-3" href="#10-the-record-model-is-heavier-than-turn-boundary-messaging-needs">10. The record model is heavier than turn-boundary messaging needs</a><a class="depth-2" href="#minor-findings">Minor findings</a><a class="depth-2" href="#claims-checked-against-the-code">Claims checked against the code</a><a class="depth-2" href="#proposed-re-sequencing">Proposed re-sequencing</a><a class="depth-3" href="#slice-0-the-promise-on-the-existing-engine">Slice 0: the promise on the existing engine</a><a class="depth-3" href="#then">Then</a><a class="depth-2" href="#questions-to-answer-before-approval">Questions to answer before approval</a><a class="depth-2" href="#notes-on-the-document-itself">Notes on the document itself</a></aside>
202
+ <aside id="help-panel" hidden aria-labelledby="help-title"><div class="chat-heading"><div><span class="eyebrow">Your AI companion</span><h2 id="help-title">Ask code-flow</h2></div><button id="close-help" aria-label="Close AI companion">✕</button></div><div class="chat-toolbar"><span>Grounded in your docs</span><button id="new-chat">New chat</button></div><div id="help-messages" role="log" aria-label="Help conversation" aria-live="polite"><div id="chat-welcome"><span class="chat-mark" aria-hidden="true">✦</span><h3>What would you like to do?</h3><p>Let’s find your next step. Ask about setup, workflows or something that’s unclear.</p><div class="suggestions"><button type="button" data-question="How do I start my first run?">Start my first run ↗</button><button type="button" data-question="What should I do when a check fails?">Understand a failed check ↗</button></div></div></div><p id="help-status" role="status">Checking your installed CLIs…</p><button id="retry-help" hidden>Retry connection</button><form id="help-form" hidden><label class="sr-only" for="question">Your question</label><textarea id="question" rows="3" maxlength="4000" placeholder="Ask a question…" required></textarea><div class="composer-controls"><label class="sr-only" for="help-agent">Use your CLI</label><select id="help-agent"></select><button type="button" id="stop-help" hidden>Stop</button><button class="primary" id="send-help" aria-label="Send message">Send ↗</button></div><small>Uses your CLI login and quota. Shift + Enter for a new line.</small></form><a id="help-guide" href="help.html">About your local companion →</a></aside></div>
203
+ <dialog id="search-dialog" aria-labelledby="search-title"><div class="dialog-title"><h2 id="search-title">Search documentation</h2><button data-close="search-dialog" aria-label="Close search">✕</button></div><label class="sr-only" for="search">Search all guides</label><input id="search" type="search" placeholder="Search workflows, settings, troubleshooting…" autocomplete="off"><div id="search-results" aria-live="polite"></div></dialog>
204
+ </body></html>
package/public/docs/extensions.html ADDED
@@ -0,0 +1,42 @@
1
+ <!doctype html>
2
+ <html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><meta name="description" content="Provider and workflow extensions — code-flow guides and reference"><title>Provider and workflow extensions · code-flow</title><link rel="icon" href="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI2NCIgaGVpZ2h0PSI2NCIgdmlld0JveD0iMCAwIDY0IDY0Ij4KICA8Y2lyY2xlIGN4PSIzMiIgY3k9IjMyIiByPSIzMCIgZmlsbD0iIzFlMWYxYSIgc3Ryb2tlPSIjM2Q0MDM2IiBzdHJva2Utd2lkdGg9IjIiLz4KICA8c3ZnIHg9IjE1IiB5PSIxNSIgd2lkdGg9IjM0IiBoZWlnaHQ9IjM0IiB2aWV3Qm94PSIwIDAgMjQgMjQiIGZpbGw9Im5vbmUiIHN0cm9rZT0iI2VjZWJlNCIgc3Ryb2tlLXdpZHRoPSIyIiBzdHJva2UtbGluZWNhcD0icm91bmQiIHN0cm9rZS1saW5lam9pbj0icm91bmQiPgogICAgPHBhdGggZD0iTTEyIDNsOSA1LTkgNS05LTV6TTMgMTNsOSA1IDktNU0zIDE3LjVsOSA1IDktNSIvPgogIDwvc3ZnPgo8L3N2Zz4K"><link rel="stylesheet" href="style.css"><script src="app.js" defer></script></head>
3
+ <body data-page="extensions"><a class="skip-link" href="#content">Skip to content</a>
4
+ <header class="topbar"><a class="brand" href="index.html"><img src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI2NCIgaGVpZ2h0PSI2NCIgdmlld0JveD0iMCAwIDY0IDY0Ij4KICA8Y2lyY2xlIGN4PSIzMiIgY3k9IjMyIiByPSIzMCIgZmlsbD0iIzFlMWYxYSIgc3Ryb2tlPSIjM2Q0MDM2IiBzdHJva2Utd2lkdGg9IjIiLz4KICA8c3ZnIHg9IjE1IiB5PSIxNSIgd2lkdGg9IjM0IiBoZWlnaHQ9IjM0IiB2aWV3Qm94PSIwIDAgMjQgMjQiIGZpbGw9Im5vbmUiIHN0cm9rZT0iI2VjZWJlNCIgc3Ryb2tlLXdpZHRoPSIyIiBzdHJva2UtbGluZWNhcD0icm91bmQiIHN0cm9rZS1saW5lam9pbj0icm91bmQiPgogICAgPHBhdGggZD0iTTEyIDNsOSA1LTkgNS05LTV6TTMgMTNsOSA1IDktNU0zIDE3LjVsOSA1IDktNSIvPgogIDwvc3ZnPgo8L3N2Zz4K" width="30" height="30" alt=""><strong>Code Flow</strong><span>Docs</span></a><button class="search-trigger" id="open-search">Search documentation <kbd>⌘ K</kbd></button><div class="top-actions"><a href="https://github.com/midhunxavier/code-flow">GitHub ↗</a><button id="theme" aria-label="Change color theme">Theme</button><button id="open-help" class="primary" hidden aria-expanded="false" aria-controls="help-panel">Ask code-flow</button><button id="menu" aria-label="Toggle documentation navigation" aria-expanded="false" aria-controls="sidebar">☰</button></div></header>
5
+ <div class="layout"><nav class="sidebar" id="sidebar" aria-label="Documentation"><section><h2>Get started</h2><a href="index.html" >Overview</a><a href="installation.html" >Install Code Flow preview</a><a href="getting-started.html" >Getting started</a><a href="patterns.html" >Team patterns</a><a href="acp-agents.html" >ACP coding agents</a><a href="help.html" >Ask code-flow</a></section><section><h2>Work with agents</h2><a href="runs.html" >Runs and workspace</a><a href="auto-team.html" >Team</a><a href="project-teams.html" >Project missions (preview)</a><a href="review-inbox.html" >Review inbox</a><a href="verification.html" >Verification and review</a><a href="github.html" >GitHub, review and shipping</a><a href="github-review-threads.html" >GitHub review threads</a><a href="task-reruns.html" >Selective task reruns</a><a href="deferred-runs.html" >Deferred runs</a></section><section><h2>Your workspace</h2><a href="configuration.html" >Configuration</a><a href="context-inspection.html" >Context and budgets</a><a href="project-conventions.html" >Versioned project conventions</a><a href="checkpoint-review.html" >Checkpoints and reversions</a><a href="launch-profiles.html" >Service launch profiles</a><a href="code-intelligence.html" >Code intelligence</a><a href="architecture-explorer.html" >Architecture explorer</a><a href="memory-storage.html" >Project memory</a><a href="memory-claims.html" >Semantic claim review</a><a href="coordinated-changes.html" >Coordinated changes</a></section><section><h2>Connect and collaborate</h2><a href="team-collaboration.html" >Team collaboration</a><a href="shared-projects.html" >Shared project accounts</a><a href="ssh-projects.html" >SSH projects</a><a href="remote-workers.html" >Remote agent workers</a><a href="code-hosts.html" >GitLab and Bitbucket code workflows</a><a href="external-sources.html" >Read-only external sources</a><a href="automations.html" >Automations and away mode</a><a href="notifications.html" >Outbound notifications</a></section><section><h2>Operate safely</h2><a href="security.html" >Security, subscriptions and caveats</a><a href="filesystem-policy.html" >Project filesystem policy</a><a href="agent-containers.html" >Agent containers</a><a href="filtered-tasks.html" >Filtered Docker tasks</a><a href="dependency-discovery.html" >Dependency discovery</a><a href="maintenance.html" >Backup and maintenance</a></section><section><h2>Build and extend</h2><a href="architecture.html" >Architecture and development</a><a href="api.html" >Local API and command-line client</a><a href="extensions.html" aria-current="page">Provider and workflow extensions</a><a href="provider-compatibility.html" >Provider compatibility</a><a href="accessibility.html" >Accessibility acceptance</a><a href="performance.html" >Performance</a><a href="run-storage.html" >Run storage</a><a href="documentation.html" >Documentation and GitHub Pages</a><a href="releasing.html" >Preparing a preview release</a><a href="vscode.html" >Code Flow for VS Code</a></section><section><h2>Engineering records</h2><a href="application-improvements.html" >Application improvement program</a><a href="project-first-navigation-plan.html" >Project navigation review and implementation plan</a><a href="dynamic-teams-evaluation.html" >Dynamic teams: implementation evidence and rollout decision</a><a href="dynamic-teams-implementation-plan.html" >Dynamic teams, workflows, messaging, and memory</a><a href="dynamic-teams-implementation-review-1.html" >Review 1: the dynamic teams implementation</a><a href="worker-permission-verification.html" >Live worker permission verification</a><a href="dynamic-teams-plan-review-0.html" >Review 0: Dynamic teams implementation plan</a><a href="project-teams-implementation-plan.html" >Standing project teams implementation plan</a><a href="performance-results.html" >Measured performance: 19 October 2026</a></section><a class="app-link" id="back-app" hidden href="/">← Back to app</a></nav>
6
+ <main id="content" tabindex="-1"><div class="breadcrumb">Documentation <span>/</span> Build and extend</div><article><h1 id="provider-and-workflow-extensions">Provider and workflow extensions</h1>
7
+ <p>Inspect the extension bundle and its declared API version before enabling it. Pin the version you intend to run; an extension is trusted executable code, not a sandboxed configuration file.</p>
8
+ <h2 id="connect-a-trusted-extension">Connect a trusted extension</h2>
9
+ <p>For OpenCode or another CLI that speaks Agent Client Protocol, use <a href="acp-agents.html">ACP connections in Settings</a>. No JavaScript extension bundle is needed for a compatible stdio agent.</p>
10
+ <p>The owner can register additional provider adapters and workflow patterns with an explicit server environment configuration. There is no repository discovery, remote download, HTTP plugin installation or shared-user administration. Settings → Extensions reports loaded/rejected bundles and negotiated API versions. Restart to apply configuration changes.</p>
11
+ <p>An extension is trusted JavaScript server code, with the server owner&#39;s filesystem, network and process permissions. Review its source and bundle dependencies before enabling it. Hash pinning detects changed bundle bytes; it does not make malicious code safe or sandbox its behavior. Use self-contained <code>.mjs</code> bundles; relative imports resolve from the private captured-bundle cache, not the original module directory. Provider authors must honor abort signals, timeouts, trust modes and the normalized event/result contracts. Built-in compatibility probes, container isolation and SSH workers do not certify or execute additional plugin providers.</p>
12
+ <p>Set <code>CODEFLOW_EXTENSIONS_FILE</code> to an absolute regular JSON file:</p>
13
+ <pre><code class="language-json">{
14
+ &quot;version&quot;: 1,
15
+ &quot;extensions&quot;: [{
16
+ &quot;id&quot;: &quot;example&quot;,
17
+ &quot;version&quot;: &quot;1.0.0&quot;,
18
+ &quot;module&quot;: &quot;/absolute/path/example.mjs&quot;,
19
+ &quot;sha256&quot;: &quot;replace-with-the-64-character-sha256-of-the-reviewed-bundle&quot;,
20
+ &quot;api&quot;: { &quot;major&quot;: 1, &quot;minimumMinor&quot;: 0 },
21
+ &quot;requires&quot;: [&quot;provider-adapter&quot;, &quot;workflow-pattern&quot;]
22
+ }]
23
+ }
24
+ </code></pre>
25
+ <p><code>CODEFLOW_EXTENSIONS_JSON</code> accepts the same object; choose one source. The host supports API 1.0 and rejects a newer major/minimum minor or unknown required capability before importing the bundle. Up to 16 extensions can each supply up to eight providers and eight workflows. Configuration is bounded to 128 KiB and bundles to 512 KiB; symlink files and changed hashes are refused. Captured bytes are copied to a private hash-named cache before import, so a change to the original file between review and import cannot substitute unpinned content.</p>
26
+ <p>The default export has this shape:</p>
27
+ <pre><code class="language-js">export default {
28
+ api: { major: 1, minor: 0 },
29
+ providers: [/* AgentAdapter objects from src/adapters/types.ts */],
30
+ workflows: [/* Pattern objects from src/engine.ts */]
31
+ };
32
+ </code></pre>
33
+ <p>Each ID must be <code>plugin:example/name</code>. Provider adapters implement <code>available()</code>, <code>catalog()</code> and <code>run(options, onEvent)</code> and return normalized <code>AgentEvent</code>/<code>RunResult</code> data. Workflows declare names, descriptions, bounded role/default-provider and option schemas, then execute through <code>TeamContext</code> for worktrees, agent turns, commits, checks, artifacts and replayable remembered operations. New providers appear in agent selection and workflows in the normal composer. Built-in IDs cannot be replaced, duplicate registrations are refused and workflow default roles must refer to registered providers. Plugin capabilities remain unknown until independently established; built-in tool bridges and live approval prompts are unavailable.</p>
34
+ <p>Runs pin every selected extension&#39;s version and SHA-256. Resume or further dispatch refuses a missing or changed pin; restore the exact reviewed bundle or create a fresh run. A restrictive filesystem policy also blocks plugin execution. The fixture acceptance test loads a real captured bundle, registers a new provider/workflow, runs it through the actual engine, commits its result and executes its real check without provider quota or external requests.</p>
35
+ <p><code>GET /api/extensions</code> is owner-only and returns status, hashes, negotiated versions and registered IDs, with bounded redacted error details. It does not return module source or the configuration document. Extension caches are executable code, not portable project data; restore does not enable plugins without an explicit environment configuration.</p>
36
+ <hr>
37
+ <p><a href="index.html">Documentation library</a> · <a href="getting-started.html">Getting started</a> · <a href="help.html">Ask code-flow</a></p>
38
+ </article><footer><a href="https://github.com/midhunxavier/code-flow/blob/main/docs/extensions.md">Edit this page on GitHub ↗</a><span>code-flow · 0.1.0-preview.3 · <a href="font-license.txt">Font license</a></span></footer><nav class="pagination" aria-label="Adjacent guides"><a href="api.html"><small>← Previous</small>Local API and command-line client</a><a href="provider-compatibility.html"><small>Next →</small>Provider compatibility</a></nav></main>
39
+ <aside class="on-page" aria-label="On this page"><strong>On this page</strong><a class="depth-2" href="#connect-a-trusted-extension">Connect a trusted extension</a></aside>
40
+ <aside id="help-panel" hidden aria-labelledby="help-title"><div class="chat-heading"><div><span class="eyebrow">Your AI companion</span><h2 id="help-title">Ask code-flow</h2></div><button id="close-help" aria-label="Close AI companion">✕</button></div><div class="chat-toolbar"><span>Grounded in your docs</span><button id="new-chat">New chat</button></div><div id="help-messages" role="log" aria-label="Help conversation" aria-live="polite"><div id="chat-welcome"><span class="chat-mark" aria-hidden="true">✦</span><h3>What would you like to do?</h3><p>Let’s find your next step. Ask about setup, workflows or something that’s unclear.</p><div class="suggestions"><button type="button" data-question="How do I start my first run?">Start my first run ↗</button><button type="button" data-question="What should I do when a check fails?">Understand a failed check ↗</button></div></div></div><p id="help-status" role="status">Checking your installed CLIs…</p><button id="retry-help" hidden>Retry connection</button><form id="help-form" hidden><label class="sr-only" for="question">Your question</label><textarea id="question" rows="3" maxlength="4000" placeholder="Ask a question…" required></textarea><div class="composer-controls"><label class="sr-only" for="help-agent">Use your CLI</label><select id="help-agent"></select><button type="button" id="stop-help" hidden>Stop</button><button class="primary" id="send-help" aria-label="Send message">Send ↗</button></div><small>Uses your CLI login and quota. Shift + Enter for a new line.</small></form><a id="help-guide" href="help.html">About your local companion →</a></aside></div>
41
+ <dialog id="search-dialog" aria-labelledby="search-title"><div class="dialog-title"><h2 id="search-title">Search documentation</h2><button data-close="search-dialog" aria-label="Close search">✕</button></div><label class="sr-only" for="search">Search all guides</label><input id="search" type="search" placeholder="Search workflows, settings, troubleshooting…" autocomplete="off"><div id="search-results" aria-live="polite"></div></dialog>
42
+ </body></html>