npm - @midhunxavier/code-flow - Versions diffs - 0.0.0-stage → 0.1.0-preview.1 - Mend

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

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 (284) hide show

package/LICENSE +21 -0
package/README.md +122 -2
package/bin/codeflow.mjs +8 -0
package/bin/launcher.mjs +127 -0
package/dist/remote-host.json +1 -0
package/licenses/inter.txt +92 -0
package/licenses/preact.txt +21 -0
package/licenses/signals-core.txt +21 -0
package/licenses/signals.txt +21 -0
package/licenses/typescript-notices.txt +193 -0
package/licenses/typescript.txt +55 -0
package/licenses/uqr.txt +22 -0
package/licenses/xterm-fit.txt +19 -0
package/licenses/xterm.txt +21 -0
package/package.json +34 -4
package/public/assets/browser-7XI52A6V.js +8 -0
package/public/assets/changes-EYFPASEI.js +1 -0
package/public/assets/chunk-7H3ZLTKA.js +2 -0
package/public/assets/chunk-L7TUCIYF.js +1 -0
package/public/assets/chunk-LLMQG23J.js +163 -0
package/public/assets/main-KIRM2OEK.js +1 -0
package/public/assets/settings-QJZVW22Y.js +9 -0
package/public/assets/styles-615EBB20.css +32 -0
package/public/assets/terminal-A2FI2NAX.js +62 -0
package/public/assets.json +1 -0
package/public/bundle-meta.json +1 -0
package/public/docs/.nojekyll +0 -0
package/public/docs/accessibility.html +19 -0
package/public/docs/acp-agents.html +117 -0
package/public/docs/agent-containers.html +79 -0
package/public/docs/api.html +1130 -0
package/public/docs/app.js +342 -0
package/public/docs/application-improvements.html +275 -0
package/public/docs/architecture-explorer.html +19 -0
package/public/docs/architecture.html +149 -0
package/public/docs/auto-team.html +142 -0
package/public/docs/automations.html +109 -0
package/public/docs/checkpoint-review.html +37 -0
package/public/docs/code-hosts.html +35 -0
package/public/docs/code-intelligence.html +35 -0
package/public/docs/configuration.html +346 -0
package/public/docs/context-inspection.html +23 -0
package/public/docs/coordinated-changes.html +28 -0
package/public/docs/deferred-runs.html +25 -0
package/public/docs/dependency-discovery.html +19 -0
package/public/docs/documentation.html +84 -0
package/public/docs/dynamic-teams-evaluation.html +174 -0
package/public/docs/dynamic-teams-implementation-plan.html +882 -0
package/public/docs/dynamic-teams-implementation-review-1.html +141 -0
package/public/docs/dynamic-teams-plan-review-0.html +204 -0
package/public/docs/extensions.html +42 -0
package/public/docs/external-sources.html +96 -0
package/public/docs/filesystem-policy.html +26 -0
package/public/docs/filtered-tasks.html +44 -0
package/public/docs/font-license.txt +92 -0
package/public/docs/getting-started.html +118 -0
package/public/docs/github-review-threads.html +26 -0
package/public/docs/github.html +157 -0
package/public/docs/help.html +69 -0
package/public/docs/index.html +77 -0
package/public/docs/installation.html +74 -0
package/public/docs/launch-profiles.html +48 -0
package/public/docs/maintenance.html +60 -0
package/public/docs/memory-claims.html +31 -0
package/public/docs/memory-storage.html +58 -0
package/public/docs/notifications.html +39 -0
package/public/docs/patterns.html +195 -0
package/public/docs/performance-results.html +210 -0
package/public/docs/performance.html +166 -0
package/public/docs/project-conventions.html +22 -0
package/public/docs/project-first-navigation-plan.html +587 -0
package/public/docs/project-teams-implementation-plan.html +772 -0
package/public/docs/project-teams.html +99 -0
package/public/docs/provider-compatibility.html +20 -0
package/public/docs/releasing.html +61 -0
package/public/docs/remote-workers.html +64 -0
package/public/docs/review-inbox.html +26 -0
package/public/docs/run-storage.html +23 -0
package/public/docs/runs.html +141 -0
package/public/docs/search.json +1 -0
package/public/docs/security.html +133 -0
package/public/docs/shared-projects.html +31 -0
package/public/docs/ssh-projects.html +60 -0
package/public/docs/style.css +768 -0
package/public/docs/task-reruns.html +30 -0
package/public/docs/team-collaboration.html +379 -0
package/public/docs/verification.html +22 -0
package/public/docs/vscode.html +53 -0
package/public/docs/worker-permission-verification.html +122 -0
package/public/index.html +17 -0
package/scripts/check-node.mjs +7 -0
package/scripts/codeflow.mjs +55 -0
package/scripts/pty.py +273 -0
package/src/acp-connections.js +110 -0
package/src/adapters/acp-presets.js +37 -0
package/src/adapters/acp-types.js +0 -0
package/src/adapters/acp.js +328 -0
package/src/adapters/agy-auth.js +67 -0
package/src/adapters/agy-isolation.js +223 -0
package/src/adapters/agy.js +297 -0
package/src/adapters/claude.js +220 -0
package/src/adapters/codex-app-server.js +518 -0
package/src/adapters/codex.js +299 -0
package/src/adapters/errors.js +57 -0
package/src/adapters/index.js +91 -0
package/src/adapters/managed-permissions.js +37 -0
package/src/adapters/model-discovery.js +100 -0
package/src/adapters/process.js +418 -0
package/src/adapters/team-tools.js +102 -0
package/src/adapters/types.js +0 -0
package/src/agent-container.js +155 -0
package/src/approvals.js +121 -0
package/src/architecture.js +456 -0
package/src/assets.js +44 -0
package/src/automation.js +901 -0
package/src/certificate-renewal.js +75 -0
package/src/chat-handoff.js +55 -0
package/src/checkpoint-review.js +72 -0
package/src/checks.js +303 -0
package/src/code-host-git.js +102 -0
package/src/code-hosts-api.js +99 -0
package/src/code-hosts.js +482 -0
package/src/code-intelligence-worker.mjs +452 -0
package/src/code-intelligence.js +141 -0
package/src/collab/api.js +365 -0
package/src/collab/checkpoints.js +198 -0
package/src/collab/connections.js +139 -0
package/src/collab/host-execution.js +347 -0
package/src/collab/hub-client.js +210 -0
package/src/collab/link-api.js +229 -0
package/src/collab/link.js +595 -0
package/src/collab/model.js +496 -0
package/src/collab/runner.js +1014 -0
package/src/collab/store.js +1452 -0
package/src/collab/terminals.js +361 -0
package/src/collaboration-reviews.js +116 -0
package/src/config.js +48 -0
package/src/context-budget.js +14 -0
package/src/context-inspection.js +204 -0
package/src/context.js +154 -0
package/src/conventions.js +283 -0
package/src/coordinated-api.js +247 -0
package/src/deferred-launch.js +82 -0
package/src/deferred-runs.js +515 -0
package/src/dependency-health.js +35 -0
package/src/diff.js +43 -0
package/src/docs-help.js +316 -0
package/src/doctor.js +232 -0
package/src/engine.js +4366 -0
package/src/env.js +44 -0
package/src/experience.js +50 -0
package/src/extensions.js +144 -0
package/src/filesystem-access.js +107 -0
package/src/filesystem-policy.js +238 -0
package/src/filtered-task-limits.js +93 -0
package/src/filtered-tasks-api.js +53 -0
package/src/filtered-tasks.js +576 -0
package/src/fs.js +57 -0
package/src/git.js +626 -0
package/src/github-review-threads.js +181 -0
package/src/github.js +538 -0
package/src/http.js +69 -0
package/src/improve-settings.js +38 -0
package/src/improve.js +187 -0
package/src/integrations.js +373 -0
package/src/integrity.js +259 -0
package/src/journey-api.js +77 -0
package/src/journey-replay.js +65 -0
package/src/journey-store.js +97 -0
package/src/journeys.js +60 -0
package/src/json.js +81 -0
package/src/launch-profiles.js +292 -0
package/src/learnings.js +80 -0
package/src/log.js +39 -0
package/src/maintenance.js +335 -0
package/src/memory-analysis.js +182 -0
package/src/memory-claims.js +153 -0
package/src/memory-sqlite.js +236 -0
package/src/memory.js +552 -0
package/src/merge-validation.js +58 -0
package/src/model-catalog.js +238 -0
package/src/model-research.js +91 -0
package/src/notes.js +176 -0
package/src/notifications.js +413 -0
package/src/patterns/auto-team-model.js +212 -0
package/src/patterns/auto-team.js +659 -0
package/src/patterns/council.js +199 -0
package/src/patterns/debate.js +188 -0
package/src/patterns/findings.js +141 -0
package/src/patterns/index.js +19 -0
package/src/patterns/loop.js +158 -0
package/src/patterns/pipeline.js +125 -0
package/src/patterns/prompts.js +181 -0
package/src/patterns/race.js +147 -0
package/src/patterns/schemas.js +40 -0
package/src/patterns/solo.js +49 -0
package/src/patterns/supervisor.js +235 -0
package/src/patterns/task-draft.js +29 -0
package/src/patterns/tdd.js +231 -0
package/src/patterns/team-strategies.js +67 -0
package/src/performance.js +43 -0
package/src/persistence-status.js +35 -0
package/src/phone-sessions.js +96 -0
package/src/preview-overlay.js +383 -0
package/src/preview.js +219 -0
package/src/privacy.js +23 -0
package/src/project-report.js +22 -0
package/src/project-team-model.js +178 -0
package/src/project-team-policy.js +42 -0
package/src/project-team-store.js +213 -0
package/src/project-teams-api.js +36 -0
package/src/project-teams.js +551 -0
package/src/projects.js +286 -0
package/src/provider-eligibility.js +9 -0
package/src/readiness.js +98 -0
package/src/remote-tls.js +66 -0
package/src/remote-workers/bundles.js +198 -0
package/src/remote-workers/client.js +332 -0
package/src/remote-workers/durability.js +37 -0
package/src/remote-workers/protocol.js +68 -0
package/src/remote-workers/stdio.js +138 -0
package/src/remote-workers/worker.js +304 -0
package/src/remote.js +204 -0
package/src/repo-config.js +201 -0
package/src/repo-coordination.js +732 -0
package/src/repo-tree.js +106 -0
package/src/retention-policy.js +466 -0
package/src/review-inbox.js +38 -0
package/src/routing.js +49 -0
package/src/run-analysis.js +111 -0
package/src/run-cold-store.js +231 -0
package/src/run-environment.js +15 -0
package/src/run-history.js +91 -0
package/src/run-log.js +160 -0
package/src/run-permissions.js +110 -0
package/src/run-projection.js +75 -0
package/src/run-recovery.js +53 -0
package/src/run-status.js +54 -0
package/src/serve.js +138 -0
package/src/server.js +2738 -0
package/src/shared-access.js +103 -0
package/src/shared-accounts.js +301 -0
package/src/shared-api.js +239 -0
package/src/shell.js +346 -0
package/src/ship.js +344 -0
package/src/slots.js +74 -0
package/src/snapshot.js +388 -0
package/src/source-context.js +17 -0
package/src/sse-writer.js +70 -0
package/src/ssh-projects/bootstrap.mjs +95 -0
package/src/ssh-projects/config.js +45 -0
package/src/ssh-projects/gateway.js +143 -0
package/src/ssh-projects/manager.js +320 -0
package/src/ssh-projects/team-autostart.mjs +93 -0
package/src/ssh-projects/team-remove.mjs +69 -0
package/src/ssh-projects/team-status.mjs +39 -0
package/src/ssh-projects/transport.js +116 -0
package/src/stats.js +139 -0
package/src/store.js +544 -0
package/src/stream.js +91 -0
package/src/sweeps.js +241 -0
package/src/tailscale.js +101 -0
package/src/task-draft.js +23 -0
package/src/team-evaluation.js +242 -0
package/src/team-mailbox.js +160 -0
package/src/team-memory.js +84 -0
package/src/team-rerun-graph.js +15 -0
package/src/team-reruns.js +130 -0
package/src/team-scheduler.js +121 -0
package/src/team-template-store.js +98 -0
package/src/team-templates.js +117 -0
package/src/team-tool-client.mjs +79 -0
package/src/team-tools.js +176 -0
package/src/teams.js +0 -0
package/src/templates.js +62 -0
package/src/transcript.js +134 -0
package/src/verification-integrity.js +27 -0
package/src/verification.js +183 -0
package/src/watch.js +195 -0
package/src/work-queue.js +47 -0
package/src/workflow-control.js +83 -0
package/src/workspace-api.js +207 -0
package/src/workspace-changes.js +61 -0
package/src/workspace.js +146 -0

package/public/docs/dynamic-teams-implementation-plan.html ADDED Viewed

@@ -0,0 +1,882 @@
+<!doctype html>
+<html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><meta name="description" content="Dynamic teams, workflows, messaging, and memory — code-flow guides and reference"><title>Dynamic teams, workflows, messaging, and memory · code-flow</title><link rel="icon" href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAGAAAABgCAYAAADimHc4AAAbSElEQVR42u19a7Ak53nW87xfz5zbrtYSNnbwRU4UGywZE2E5GKfCerETxUlRIVRWVUBcXBJLOKU4wchA7IKzBxzsXCCxQ1JEIT9SCUXYjQMEKiQorpWILSmJpJjgtZEdZGQby7Zuez17zkx/78OP7+ue7p6eOXPO7kryiedU15mZ7pnufi/Pe/8G+OrjWX3wyp9ChBrnOvFMnPMyPo5COAbgGARSXxkXvS6DFHBcYV+J67oMJ1VAsuemBhxXwFEIpE8UQLZ27/nn0w78iTLieTAMxxHEGIk5gqKgEDAlXbEEiur9EsBSel4Q3AJQlJdBPyOIAoDDMAALh5UOg0phqRhH4NzSeOuJ7atPP45v+JoLjfsiTsBwC+Ozz4AkEbWKLn9081rZ8IgUDrv7jXR7MYRDCBi4Ae7pzE2Fri5E1XMB6hwDAMwHOtI+dT4L5c9OXWN+j5OTsPO9ZPt4AFAJUH6BtC+BeLhk/Ag8/Bb+Mh9sQCxbQveMMUAiAAOTFKw+oJu9xNtY4s1cxSEYoHGSXs/S6oI8E4kdojZvnNX7mRHW4E5FaFfnY5nIUoMZuyACK6YQotLpSZAGIAAYAG6AX4A84B4P5c/gmwa/Wmv/HrSBl4SHG4nry/fqm8ywEQLexAESPkTETBBGRzpQ6X9U58bVf2Hsea0usWtZmM0YNr5Dc26+eVzFDAIyAEaIgCBIROGrQDRgXOIuL/GPcZgPQTIQ6r+j/oftGes36Dj+8eHaffFfDMzvGS7jTYMRFDYRrYQoBDmCHAaBcFAC5GlD878mGxr73CfHe+e1Kur79MaKBAKs85pqv0bj/ebrxnVSDirCFBEgFOZQcR5xeBa+EvAtheEjuLt8B0jH+jFmZLhCGpBVbfmjunZQ4JeKFXwzz0MQHECQJwn0TNAKGD1LabWP3QuYoQVNqOpKdA356nneOJCYhripHT3XxGyD2JDWpBlqfJRRBcL4ADA6X/6s3jS4Heviom5rsRfir35E31AU/mvFkn0tz6EEENwRmoQX2nhcS7imbGM/A9TznG0D2/zfhKXuZ2dSoYe5Td6o88EK2ibwJJghcEwNTyPi6uL7R781Nt3Mt+MGBQDx8mmAZCB97V792WC4qwh4IbZRCigqqZ8ifPM9z1pQSfEiBMfOaNq0AXOUaUdta7pS7LFD3efpv8Mm3pRAi6OrUIzOxTvwbcW/XMQwczcGd+X+Cy8ZaPV/FAW+FluIAoLHTPzkkNX4LPVrQFNaey9A85lQMa+JstqJ8nv0TDiDIZPXmmwECAqF+fYQPo7jw/iW4X2V4O6dAVXA8XUP2sGLN941PGiH/RxKCEWM/VLvHY+kBUH5rOqqvxr+f4foTX9fPd6M5km1dkd1qvO8wYguEyo3mUieBgwwMPoBC9tb/nvxnH0zTqHExmzPaGcvKEd7axdufE9x0A77WZRyFJXku9pwU7+uvBa1PZfqdY+30fu8hreGF9TyhmK/JwTPCOwLbjFt8unr9Yb9anpkHvN7YrIPSSCDnUMslu0bsRa/O3mLs+nMRXB/cK/+/LJwfwGYxjA5GDXtj3vjgtEDQ7NwftqaLmCY5xmEKxCSTqQdtTEzNiLoyt8mYYboK2bbI3zUfx+H53lEi3hBDKP4vnAgDHQeUQ62JGIO/PR6P5qD99ph/yyi8wozgW0jzwa8Wp3CMDgcJkCScROwAn/RXzd6Dbj0sVm2oJjrcpIx3D8+Urh9q87B4QjuE99eHenv84TQ3bAAM9QD9pqD65rDlN3YgO55Oc0YNY5jvm9axRSmUJkk5WVYs8Ivhu9w4GO4G4YJ6RZgwNF06Uvj4h1hCdBFuBzmmiZ+RWz3jlvYJbx38wk7aIFmEHcRKNoLA2ZpHvuPk0+YkNxRQlJKIlLkGIDCGwAAb+yPCYp52D+8b+sVNsbNuADIETRDcis/v4aePmlGMyRekPiLYLwukz3QDprRhCM0UheVsFmj/iSHCGIbgPsrcVLLILf68rv9DMjqYuPiu2wZKzqDKE0Y0Ap6vA03wgzY8TlE340hxoJ24VJsQJ8GdfflPJR6YpG0W8QYgPR8nME1AL4wZa9mMiCriyHczHFKH6sj2U2vp2V8+xigGYRdlAm7lf7dHscd0h+zckhdLWBDYQRw7CB0EBolBhybtmDWG/WSWrtPL7QSN2oblMP6DGori9nNTs5jQt8x3vk/61if8/lZW995Fv1s33d5Oy6A1MjOEnJCLio6IARsXlwBABxbxAbckPlblq9hUVytzRyketu4TuXiZ0m4z7AH8yBnlpfU9Yq4g2ZwQc3hgm5tJxSfBJScLmAIyRyX7rCwvTgDXpC/RsWrGQAXooCiie+t4ke2AwsRdRHY0RzXchE3doEE35S/Pw/uOFsI2HU4GlUjSTArAOk8lg88vXhB5vFM2zGua6rZVEKtMjZxjoovoMozYaEPghaFIy0AQ4vA1axzzrNrE61IySHyKbwCT2YN0M4acCof5HixUr6HLePrO/jlmiH1e/GCFomKL8U4L5q84wxY6yniKEODSdIQYAyfxk3cxPp6byQ8rQGZS2XEquJ0bh+NoMt9B0ldRAK1gHbMO35R4z7rc/M0bIfvaJZFJwm8uhSYWxbsdzJhbXe5IM9MrTKUnGBeyyX1BTBdl2iEL1X6fQFJ36laP2O/OtLPLLJyBt+K0a4K/3XGVcxngNgRCO+JCAU4Z3gos3BykRTDohB0qdHyIvFAH/x0EnN1iZIJo+lyLA1N7veOvxsfw/p63UGycD0gYoaf39dFsBuiawG/HAscs+jmC3hl2sFbm4pVBEQHPbV6mHLBXlULRWrO4MD+FUjhhmPcfVFeAD1vnYtqlhU5L/2gXULRbiBokYwodgEz6km6qaeA3yhs1K4/J1Jq0aMvLweN44f9/4Zfx7rmti/O1ACLM1BLC0rUosS/HJtfhu/AbEehEsSqNMdMOKuYkMt85u6wgjH6uWIt3I4NOj5xgntqS2HV+pI1oS5KqMftmuVmLnqzi6ajF3l+OQv0nWp/XXxvWd7EfcpFQeVKESB8/+hv8n9j/WSBjSPlnhiQawvtbOY8yccupHtRo6tLNMCa4c1wjqGdQqlJIMQpp98TU9ydIssDw+Cj8bv9tuEvY10FNnbuFZ1rAxbKaPoOzNiNG7oTg7CHegF2WeJstaCki2ibhsroOSiXCRHFUlEGuBz/wG8b/mSSfMZFzjQvDmhlPedh/5QA7RZzF80JLZqm7jOq2EVdue9C2MzByOkuYxF8tSjKEp9WwO34Xv53HD5ZYONIXBQEd2YA5msAewik3Ro+7BGisIsE3E7FdzUkPG+CqwqsCAmkKAQOlkzLQFn62SjciRW8H3+LT2bMj7uxQDsyoNmcKk33U7aHKpTqpJrU7rST97SbbOnlMrharCZMGgkDA9MUDdPARiT+yIEPYcV+AX+Xn051lJ0N7iU353JGKp6uhJTG9I25SQllFFyCMyW1xUYue5bEZ51Sp9151jGLULfqyanaxmtjasp+PatCr7LYEIg0boHlpjw8Brc/EvGHHOJ+x9MP4bZrztSEx92eJR+XjwHuRJ5Fq+IMdtMNMbUDaJjyFrqwNdLZ7W1cGG9ja1xirIgylSbgIpjmBPKXctLnUROHk+c9rdDUpPdePZ1TUn83VX2SVgduOgfJ1n5WKTVuO/UUiM/K8RDK8Hs4vfkAfuVVX6i//9afG+ATjztObOxpPKkfDSWCFI/rrqUVvBkXU0G+RYicoItDQOPS9dSF8/rSxfM4W47gdAiGpLuA3NLNVhBbjTVlAlSEF6uBlDxzpcSsuuFG7d7YWppZzWhVhGYjWdVmNlralM7V0olmlxPSYBQNCEUKu3y0TbNPgvwvivgP+NlrTwEAjirgxN6G9WYywI7rrqVlvFmbqQu6PjAKMiIS8C+fOavPX3gKm4gKAyLAkr1CKo56Nc7JiQYo/0+tZEwSWM88TAitNBGUPlOXuyfSKmai11NEzaaRDtx0NKD67hZz0NAWqYqECAqWrRoZEJbAMIS2L2yT4Vdj0PvxwZd9HACxvk5s7E4bZjKgOK67BkttBtAhL8A4Go/1f558XE+U5zFcNgUExDQ+BY+s52g9d07WIztkQyMsE3ZC/JrYlcSrTfy03zLcVARuawXFqdvS9Bv1JyftcOz3BtjqhibgJB1QoeFB+Hhz02g/Wn7xpT+CE4zN2TlcyoxYNqmNxJygIRjPb23xf335c3zKz3FlEIBIlKVD0eFeGUdNZkJbI3Z1cJn2G9rEl0FuSaJlEA0kE5wx4UGaWUwQl5iYta6Cn8m4RL21b4z5Oxu9hta4RutkeqbcNJO8gCRsn4mUr2qwtmF/6rHfWL3jMy/CBh1Hj4dLH9Jr5H4oQAPCz2xt8dTjn8M4jDgMQOkRcoekXAkivOoEpiZhY2tOqCKUZU2ZSLpqzcjgSwMZIAQgb1ImegU9DduQhwHhFYOnhbjhSWF6ULZvLrPd/eG54O5yAgiUi1tPl7TBt26NBh9e+qEvfh1O3JI04ZIYUN2EHAiAXxyN9ckn/p80GCNQ8iz1Qkzg1AjBXEpNkg44JxxwVM307JmkridCAQaIAVCAK0DKhK8I7m2mzZL0JtH7G84rI94dvZjSiMlpGkkC5UYgouD26ZI2uH4cR7+Jd37+pdigL8KE2RBEz6JlkFz61JOPacwtBgc9xjwV6YR7Ijg8e0DKQeSMgd7qPpq5DiQjnQx41oBM8InRZgvTNYuwE3Sf2+2vJhR23drpabA2nyenT4of0woK22dLFiuvsFF5HH//syto+dm7ZIA8k7hA0GPnT+v0+LQNTYwoXXA4HEq8gWJzHqZp0NXo2mWjpVpwqNVOPZWLbRnZJrPYGzGz8bfXUYzezmvO3Gr+ZVgCUXDrTInhVa8P0d+b7MEJ2xsDBEcAMIojfuHs4zYIQowl5FGKLkUXFCV3CUkLIE82ofpr9jGmMDMXTlMVg83As6cXvEX8jsROChesI9mpGipmrAah+TmN2hvt519TEyYedL5lKtjW6QiEH1y5/bPfiBO3xHlGua8thTm9cBEDAGe2zmjLz9MQIURIDleqEbkmxE6vK8LXVwOn6inturmoM67TSk+of9JcPZLLvp7AKUjpEH43s+nEDKNde8+trXJEEAEbhLGP/gkA4PqjWpwBVW+o8TEB4FNbZwFFyBPeyzWZnGMiNl3teSXvwIMmJaWa+KxshVpGMwmqWqPvMzOf1A5TG5yZIu3N0HKBrg22oL0dytR6EDg6J7fiLYN3PPraeQbZejrjUngS7BGNAF0oL5ICPEqClKFeSVItq2p2/SrvJlTC1gANqoYHZnjSItUgTOP+FIm5QFFJszs2WtMmfYExO7xki3x18F4H89nnG6yFUnorAOAT/RfZpwHJrhj+p58XMN5OJqYymmAywWpMhGnOXdV+W6xI6e2kmfWv/KAFRt2ZDXv/wdx9fnpubbIHhiamRWzX0CSQcRsQ3nLt+meWc66Ii2iAACCu4iHfGn0RcoO8BDzDUO4VkDITKs3zbAsEyDOh6+vxLPXKYyUNHMgdSE3DrQ4VOGuFiJ1aNhbtVSEWGz6b5xmhETdk/z1ui+R1j54bvCrPXizAgCqU/nY+LsdJBAxMvk15MsL1mDQqrZjcNXM8ML3ATLYVmdA1M/J7VQuwqq7TJsPqKpCmZ0VnMYScX+HfiVFzpJ/tjEeTiSI7CCbXYDWAeA0A4O67bTE39PoXEADiKPyiI6QuReXJWEmpjCFP3o6ake9EUr3nRps9LMwpiyqCVk4iAIlxyi0H7WHYOS3X6lnniXvrT+kKdnfdm6bdYZMpbHhIVdBpYIyvyqNfC8YBG0cisG54oviwynCvg2tGjQA4PApwpyAyU7mCn0q6cyw7qRAzE5fNpEHaZ3SQuacPk83yQgPkpDXB2HC/1Uw2tBNsO1vb+YTvwstU2qgakbf2MWiMzlfXKAcirk2G+HEtGogJR28gNlgq6qcdwSFGg8fU415HpQKzXVBMBI0xLXeoGlIElMkI06vqmFI5zYW06ERiosfMzGpluawJFYRNWtay8e1I/BQ0a7ZRncq7cVrauwzp5uxaxO7RiMrzBg7Migdmh8k5ghv/9Ev+wGP4ZRefR2AMVjkFdxBOwKmYcb1aVqPWFOUReqUALqZFKl2NLccVysZbMR0rJaaqVO1x1Wal8r6aK3zM8MY4a9EhThFrStrnaYD1MZLTjJndmb7AaiknbhGOHg/lky+7s9TwpDw8z+TbIKIBkYjJDjCnKJmTczUTqtREJcFMGSZW6YpshJurTwjKy45UTZE+sTdopLgbjKiZ0e3lQXtlQM6JG9iFF7aPZ2drQRSnl70hEkSZgcHOJgg6wd0uV+M4cUo4wRiXX7oxjoPfkRdXmTQCVCZyuaA8nCl3gE7PUTMqTFesit21oaVXRjfnl6vXqtZXbDj5uS/HpBasEOydne3WIGpp7KyJ2YIPdt7fxYbJd1XmCLRU2DaDrHik6dzsctXEDQfWDT/Ji/Hpl707+tKveAzLFEJaFVQRiA5FT6LrEVRafYfukGLtmiqlNJJmVHZAnss5XjdbqjIwakRnNeE129j2LH9YE9zQXF+s9T5z/a96vqsNve+lp0xyE/ipFOS+UXvsC9rwPOUxKoGfwt959OMhlN8nlF+flmTVGAbQSxMtlRDFQMlUiYPDkldAA2LICWkDFMhUQkuVL+WlUqvYodlbopBdD0AK2UNiu18mm73uarDsSdqRHReTnSB61hK7ndRFdRnd3WRAuT0Oawcf8uYA5N6XrawamCjcqlWUn38LNLqZ8D8NxgOpouWeWE+DVMhgFCw5xCQEY1VeJAKFANJAN4gmYACiKkMaCBNTQ0JVpZwEruOU4xAIqxeNaaeLmaPT7trEVU2afQzoGuvOc/Y3zFpuG8wpMGexau7jU/GVX3MjbuP40petrKYGUuV/E8CHAH5Ib/3cKxHGr0YcvxLGF4FaBTQAUMgZQJkkg1laTyr58AGSiakMqchcTgmsK2FQgESJhBnBGCAvRFsheDVZvAhLBwI1AsoLqYuI1o5Ru66jdROknE4d9TKjsZAc2VMNUi5hq+KRMFgBXL+J2zie1Tu0SwY00hUQcfhYwD0bEb/0kk8B+BQWnKXYy+xE6zNHFfQirGnzSy+30fiIyL9uw2v+ArUJ+MjFYFKjMYNsDxVNEdX6M6tEDwQ1l0Rhw6azpUykmcetaBz++wgA18/Nl+PSVnk8etzw5VPEn7xBOHFKwMaV/qEDdbF88EMXvge68BNm/kKNz7vTMhNSd8uk+c469ZnqPcywBz3EbywUUdvxjIs5ERA1PBTi+MJv+I+98Dvm9QpdyV+z4JWl/zHi6A3EI08bHrwtAvClH7h4nYqL/4mhfLVGF9xJS9a7yo1YFlrrOIJsB1GzavN1o2x22DiR/hr75SLMow1JhDeU7z/0uzh6PODELfFZ+gkTPDM/xXLrAwXuvGmMd229YqDN+4K2roleSoBVcgnm3mA2OxmnffnZFKoDwLpol6AnSb9BYIylrzy/iFtnf0Y/9vzb5xF/76unP/cewp03jXHrAwP8+PKnSfxzLF1FMgVCoKH+X4ttjguqZQ+tJwawTkSco2laOp5WfW+10LdHLR8q4njzY5J+GOsyXH9Kz/KP+DyTbEgAc/B9uGZ0+olPAniB+yiPtli7v4dsQ1DT2LK/yFM7udlGkA2n12NEsRoiwpcd5V/Cew89vJP07ycNQD2IcewYz72bTzr5gIarAOkwa8QQWbLNJlJvjUjYplLK9RgBjbXU01IAliRfpYYHQrThUxbK78R7Dz2MwyeLnYi//xgAIC0LIJbCownrTcrEaxK6CtBbhLdu3kiZPzkMqWGpYTLcSyxfXbgNP2PBvq3cOHQ/1k8WuGexiZn9x4ATyVUx+hptOnfDOt/TJH73V3wqrEcK0muNybBjhMHdHNLaC4pI/vYwDA6X68Pf3+2gHvcdAyBiHRyUT99vYel1vn3eZWZgmKB47mJQN6HfaAe3yr3s/NgNIZirRFguYigAC++Lb7B/iiMscfhkgXt2N6hn++6H1gAcGG7/mTAYvoa+DQRjLb3513jaBZP2EjAphc/s3TQgxwSTPAiOtauLOBg8guXBt8f3hHfjCFP74T27n5LcXwy4IU3ZjcG/YUtrS5CizDiBH06XKzmBm0T4pr2YGGFzjyxWzFcOmZv/QjxQvD6+i/8tTUmucxGDexmScc9xF5SM+FEdxPbW9yBuw3OhnmxMu0iN1TZSYm1Sk2EjEFYVXLlFwNeuDq74GQXeEd9lv9aYDY64hKVBin1kfA1AXPb4nWFp+Vq/cCYqWKhSBXXTNCdrr9U5uEZRXZz0twVXZLEa4tIAMvz8yjXhPee/l483ZoMv+ccU9w8DTh0TJPJHtm8FCVljSJKsG8iBRo2n2VpSpxYESm4CtHooROERLOOd8Qf5n89fJqnff15QzrWvfECvt63yo9reYpSq2dIaUTyvNz9p47JGBJw9HKFksVqoCHDi30bih3EHn8DhkwXeeLdjY0OXi/j7RwOOZv9/q7wNRWEasRRV1AVyAQ7PDYvsNF/ldT7hbm7UgQOFwx+2If5h/AH+egvr78FlT7MX+8L1vIVx5QN6CS6Wf03bI4gI9bQSmz+fyqnlHQmJLufwYHBzl+GnDrzc/tmZ7+LpidQfKa/U5Rf7w/UENIpvteXiKp2/EEVm42uNlv7cOKtGbcwRiRB0YDU48AdYCe+Mb+fdZ66w1O8jG5Brgj+HleXT5R8Gs+vieMuFVH1GvfZsnpJKU4WgSxSdyweCM25pwJ+Iy198H2578ebEw9n7Ahx/fDTgePqNs8Gm/ootFdfp4kUHc1U+B19pgrDh10dF2jD46lIQcfdwNdyx+bb848yX2cPZ/wyo+mzG8VYNg0TWrr7YmWqS3KKg1YPBDU9hiI3y7fjXJemJ8FcW6/cfBGXXc/BB/TmO4wMhenA52zORuSU1ekRYDj4IiIb/ODiIfzRKK10ZDq8b7tl4RqV+f2jA9chDJPGvDpZCga2yBFnUk+Ak4O6MpK+uheh4NCzjPXo7/90IAG59YIA7X1viHpbP5m0UX8HeT+ptK8uXcynEarY8R7yOUtJwNfhAUMC/8VUc87fxS/XQ9J03jZ8Lt1F8BeM/AaAYLv22Av62Us+pSyCKVfNlIDp+15b4nvj3+OFny8jubzdUIu5GCA/6B0D7PghDwOEFHtaSfRCve/DncdNN44ZrqecS8fdXRezHdT0cL0fAabwWD+EIt9IyYifDc03q99+jbxmA9ZPFTkvFfPVxuZlwXAFHFb5K+K8+Fn78f4eywyDh1HjXAAAAAElFTkSuQmCC"><link rel="stylesheet" href="style.css"><script src="app.js" defer></script></head>
+<body data-page="dynamic-teams-implementation-plan"><a class="skip-link" href="#content">Skip to content</a>
+<header class="topbar"><a class="brand" href="index.html"><img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAGAAAABgCAYAAADimHc4AAAbSElEQVR42u19a7Ak53nW87xfz5zbrtYSNnbwRU4UGywZE2E5GKfCerETxUlRIVRWVUBcXBJLOKU4wchA7IKzBxzsXCCxQ1JEIT9SCUXYjQMEKiQorpWILSmJpJjgtZEdZGQby7Zuez17zkx/78OP7+ue7p6eOXPO7kryiedU15mZ7pnufi/Pe/8G+OrjWX3wyp9ChBrnOvFMnPMyPo5COAbgGARSXxkXvS6DFHBcYV+J67oMJ1VAsuemBhxXwFEIpE8UQLZ27/nn0w78iTLieTAMxxHEGIk5gqKgEDAlXbEEiur9EsBSel4Q3AJQlJdBPyOIAoDDMAALh5UOg0phqRhH4NzSeOuJ7atPP45v+JoLjfsiTsBwC+Ozz4AkEbWKLn9081rZ8IgUDrv7jXR7MYRDCBi4Ae7pzE2Fri5E1XMB6hwDAMwHOtI+dT4L5c9OXWN+j5OTsPO9ZPt4AFAJUH6BtC+BeLhk/Ag8/Bb+Mh9sQCxbQveMMUAiAAOTFKw+oJu9xNtY4s1cxSEYoHGSXs/S6oI8E4kdojZvnNX7mRHW4E5FaFfnY5nIUoMZuyACK6YQotLpSZAGIAAYAG6AX4A84B4P5c/gmwa/Wmv/HrSBl4SHG4nry/fqm8ywEQLexAESPkTETBBGRzpQ6X9U58bVf2Hsea0usWtZmM0YNr5Dc26+eVzFDAIyAEaIgCBIROGrQDRgXOIuL/GPcZgPQTIQ6r+j/oftGes36Dj+8eHaffFfDMzvGS7jTYMRFDYRrYQoBDmCHAaBcFAC5GlD878mGxr73CfHe+e1Kur79MaKBAKs85pqv0bj/ebrxnVSDirCFBEgFOZQcR5xeBa+EvAtheEjuLt8B0jH+jFmZLhCGpBVbfmjunZQ4JeKFXwzz0MQHECQJwn0TNAKGD1LabWP3QuYoQVNqOpKdA356nneOJCYhripHT3XxGyD2JDWpBlqfJRRBcL4ADA6X/6s3jS4Heviom5rsRfir35E31AU/mvFkn0tz6EEENwRmoQX2nhcS7imbGM/A9TznG0D2/zfhKXuZ2dSoYe5Td6o88EK2ibwJJghcEwNTyPi6uL7R781Nt3Mt+MGBQDx8mmAZCB97V792WC4qwh4IbZRCigqqZ8ifPM9z1pQSfEiBMfOaNq0AXOUaUdta7pS7LFD3efpv8Mm3pRAi6OrUIzOxTvwbcW/XMQwczcGd+X+Cy8ZaPV/FAW+FluIAoLHTPzkkNX4LPVrQFNaey9A85lQMa+JstqJ8nv0TDiDIZPXmmwECAqF+fYQPo7jw/iW4X2V4O6dAVXA8XUP2sGLN941PGiH/RxKCEWM/VLvHY+kBUH5rOqqvxr+f4foTX9fPd6M5km1dkd1qvO8wYguEyo3mUieBgwwMPoBC9tb/nvxnH0zTqHExmzPaGcvKEd7axdufE9x0A77WZRyFJXku9pwU7+uvBa1PZfqdY+30fu8hreGF9TyhmK/JwTPCOwLbjFt8unr9Yb9anpkHvN7YrIPSSCDnUMslu0bsRa/O3mLs+nMRXB/cK/+/LJwfwGYxjA5GDXtj3vjgtEDQ7NwftqaLmCY5xmEKxCSTqQdtTEzNiLoyt8mYYboK2bbI3zUfx+H53lEi3hBDKP4vnAgDHQeUQ62JGIO/PR6P5qD99ph/yyi8wozgW0jzwa8Wp3CMDgcJkCScROwAn/RXzd6Dbj0sVm2oJjrcpIx3D8+Urh9q87B4QjuE99eHenv84TQ3bAAM9QD9pqD65rDlN3YgO55Oc0YNY5jvm9axRSmUJkk5WVYs8Ivhu9w4GO4G4YJ6RZgwNF06Uvj4h1hCdBFuBzmmiZ+RWz3jlvYJbx38wk7aIFmEHcRKNoLA2ZpHvuPk0+YkNxRQlJKIlLkGIDCGwAAb+yPCYp52D+8b+sVNsbNuADIETRDcis/v4aePmlGMyRekPiLYLwukz3QDprRhCM0UheVsFmj/iSHCGIbgPsrcVLLILf68rv9DMjqYuPiu2wZKzqDKE0Y0Ap6vA03wgzY8TlE340hxoJ24VJsQJ8GdfflPJR6YpG0W8QYgPR8nME1AL4wZa9mMiCriyHczHFKH6sj2U2vp2V8+xigGYRdlAm7lf7dHscd0h+zckhdLWBDYQRw7CB0EBolBhybtmDWG/WSWrtPL7QSN2oblMP6DGori9nNTs5jQt8x3vk/61if8/lZW995Fv1s33d5Oy6A1MjOEnJCLio6IARsXlwBABxbxAbckPlblq9hUVytzRyketu4TuXiZ0m4z7AH8yBnlpfU9Yq4g2ZwQc3hgm5tJxSfBJScLmAIyRyX7rCwvTgDXpC/RsWrGQAXooCiie+t4ke2AwsRdRHY0RzXchE3doEE35S/Pw/uOFsI2HU4GlUjSTArAOk8lg88vXhB5vFM2zGua6rZVEKtMjZxjoovoMozYaEPghaFIy0AQ4vA1axzzrNrE61IySHyKbwCT2YN0M4acCof5HixUr6HLePrO/jlmiH1e/GCFomKL8U4L5q84wxY6yniKEODSdIQYAyfxk3cxPp6byQ8rQGZS2XEquJ0bh+NoMt9B0ldRAK1gHbMO35R4z7rc/M0bIfvaJZFJwm8uhSYWxbsdzJhbXe5IM9MrTKUnGBeyyX1BTBdl2iEL1X6fQFJ36laP2O/OtLPLLJyBt+K0a4K/3XGVcxngNgRCO+JCAU4Z3gos3BykRTDohB0qdHyIvFAH/x0EnN1iZIJo+lyLA1N7veOvxsfw/p63UGycD0gYoaf39dFsBuiawG/HAscs+jmC3hl2sFbm4pVBEQHPbV6mHLBXlULRWrO4MD+FUjhhmPcfVFeAD1vnYtqlhU5L/2gXULRbiBokYwodgEz6km6qaeA3yhs1K4/J1Jq0aMvLweN44f9/4Zfx7rmti/O1ACLM1BLC0rUosS/HJtfhu/AbEehEsSqNMdMOKuYkMt85u6wgjH6uWIt3I4NOj5xgntqS2HV+pI1oS5KqMftmuVmLnqzi6ajF3l+OQv0nWp/XXxvWd7EfcpFQeVKESB8/+hv8n9j/WSBjSPlnhiQawvtbOY8yccupHtRo6tLNMCa4c1wjqGdQqlJIMQpp98TU9ydIssDw+Cj8bv9tuEvY10FNnbuFZ1rAxbKaPoOzNiNG7oTg7CHegF2WeJstaCki2ibhsroOSiXCRHFUlEGuBz/wG8b/mSSfMZFzjQvDmhlPedh/5QA7RZzF80JLZqm7jOq2EVdue9C2MzByOkuYxF8tSjKEp9WwO34Xv53HD5ZYONIXBQEd2YA5msAewik3Ro+7BGisIsE3E7FdzUkPG+CqwqsCAmkKAQOlkzLQFn62SjciRW8H3+LT2bMj7uxQDsyoNmcKk33U7aHKpTqpJrU7rST97SbbOnlMrharCZMGgkDA9MUDdPARiT+yIEPYcV+AX+Xn051lJ0N7iU353JGKp6uhJTG9I25SQllFFyCMyW1xUYue5bEZ51Sp9151jGLULfqyanaxmtjasp+PatCr7LYEIg0boHlpjw8Brc/EvGHHOJ+x9MP4bZrztSEx92eJR+XjwHuRJ5Fq+IMdtMNMbUDaJjyFrqwNdLZ7W1cGG9ja1xirIgylSbgIpjmBPKXctLnUROHk+c9rdDUpPdePZ1TUn83VX2SVgduOgfJ1n5WKTVuO/UUiM/K8RDK8Hs4vfkAfuVVX6i//9afG+ATjztObOxpPKkfDSWCFI/rrqUVvBkXU0G+RYicoItDQOPS9dSF8/rSxfM4W47gdAiGpLuA3NLNVhBbjTVlAlSEF6uBlDxzpcSsuuFG7d7YWppZzWhVhGYjWdVmNlralM7V0olmlxPSYBQNCEUKu3y0TbNPgvwvivgP+NlrTwEAjirgxN6G9WYywI7rrqVlvFmbqQu6PjAKMiIS8C+fOavPX3gKm4gKAyLAkr1CKo56Nc7JiQYo/0+tZEwSWM88TAitNBGUPlOXuyfSKmai11NEzaaRDtx0NKD67hZz0NAWqYqECAqWrRoZEJbAMIS2L2yT4Vdj0PvxwZd9HACxvk5s7E4bZjKgOK67BkttBtAhL8A4Go/1f558XE+U5zFcNgUExDQ+BY+s52g9d07WIztkQyMsE3ZC/JrYlcSrTfy03zLcVARuawXFqdvS9Bv1JyftcOz3BtjqhibgJB1QoeFB+Hhz02g/Wn7xpT+CE4zN2TlcyoxYNqmNxJygIRjPb23xf335c3zKz3FlEIBIlKVD0eFeGUdNZkJbI3Z1cJn2G9rEl0FuSaJlEA0kE5wx4UGaWUwQl5iYta6Cn8m4RL21b4z5Oxu9hta4RutkeqbcNJO8gCRsn4mUr2qwtmF/6rHfWL3jMy/CBh1Hj4dLH9Jr5H4oQAPCz2xt8dTjn8M4jDgMQOkRcoekXAkivOoEpiZhY2tOqCKUZU2ZSLpqzcjgSwMZIAQgb1ImegU9DduQhwHhFYOnhbjhSWF6ULZvLrPd/eG54O5yAgiUi1tPl7TBt26NBh9e+qEvfh1O3JI04ZIYUN2EHAiAXxyN9ckn/p80GCNQ8iz1Qkzg1AjBXEpNkg44JxxwVM307JmkridCAQaIAVCAK0DKhK8I7m2mzZL0JtH7G84rI94dvZjSiMlpGkkC5UYgouD26ZI2uH4cR7+Jd37+pdigL8KE2RBEz6JlkFz61JOPacwtBgc9xjwV6YR7Ijg8e0DKQeSMgd7qPpq5DiQjnQx41oBM8InRZgvTNYuwE3Sf2+2vJhR23drpabA2nyenT4of0woK22dLFiuvsFF5HH//syto+dm7ZIA8k7hA0GPnT+v0+LQNTYwoXXA4HEq8gWJzHqZp0NXo2mWjpVpwqNVOPZWLbRnZJrPYGzGz8bfXUYzezmvO3Gr+ZVgCUXDrTInhVa8P0d+b7MEJ2xsDBEcAMIojfuHs4zYIQowl5FGKLkUXFCV3CUkLIE82ofpr9jGmMDMXTlMVg83As6cXvEX8jsROChesI9mpGipmrAah+TmN2hvt519TEyYedL5lKtjW6QiEH1y5/bPfiBO3xHlGua8thTm9cBEDAGe2zmjLz9MQIURIDleqEbkmxE6vK8LXVwOn6inturmoM67TSk+of9JcPZLLvp7AKUjpEH43s+nEDKNde8+trXJEEAEbhLGP/gkA4PqjWpwBVW+o8TEB4FNbZwFFyBPeyzWZnGMiNl3teSXvwIMmJaWa+KxshVpGMwmqWqPvMzOf1A5TG5yZIu3N0HKBrg22oL0dytR6EDg6J7fiLYN3PPraeQbZejrjUngS7BGNAF0oL5ICPEqClKFeSVItq2p2/SrvJlTC1gANqoYHZnjSItUgTOP+FIm5QFFJszs2WtMmfYExO7xki3x18F4H89nnG6yFUnorAOAT/RfZpwHJrhj+p58XMN5OJqYymmAywWpMhGnOXdV+W6xI6e2kmfWv/KAFRt2ZDXv/wdx9fnpubbIHhiamRWzX0CSQcRsQ3nLt+meWc66Ii2iAACCu4iHfGn0RcoO8BDzDUO4VkDITKs3zbAsEyDOh6+vxLPXKYyUNHMgdSE3DrQ4VOGuFiJ1aNhbtVSEWGz6b5xmhETdk/z1ui+R1j54bvCrPXizAgCqU/nY+LsdJBAxMvk15MsL1mDQqrZjcNXM8ML3ATLYVmdA1M/J7VQuwqq7TJsPqKpCmZ0VnMYScX+HfiVFzpJ/tjEeTiSI7CCbXYDWAeA0A4O67bTE39PoXEADiKPyiI6QuReXJWEmpjCFP3o6ake9EUr3nRps9LMwpiyqCVk4iAIlxyi0H7WHYOS3X6lnniXvrT+kKdnfdm6bdYZMpbHhIVdBpYIyvyqNfC8YBG0cisG54oviwynCvg2tGjQA4PApwpyAyU7mCn0q6cyw7qRAzE5fNpEHaZ3SQuacPk83yQgPkpDXB2HC/1Uw2tBNsO1vb+YTvwstU2qgakbf2MWiMzlfXKAcirk2G+HEtGogJR28gNlgq6qcdwSFGg8fU415HpQKzXVBMBI0xLXeoGlIElMkI06vqmFI5zYW06ERiosfMzGpluawJFYRNWtay8e1I/BQ0a7ZRncq7cVrauwzp5uxaxO7RiMrzBg7Migdmh8k5ghv/9Ev+wGP4ZRefR2AMVjkFdxBOwKmYcb1aVqPWFOUReqUALqZFKl2NLccVysZbMR0rJaaqVO1x1Wal8r6aK3zM8MY4a9EhThFrStrnaYD1MZLTjJndmb7AaiknbhGOHg/lky+7s9TwpDw8z+TbIKIBkYjJDjCnKJmTczUTqtREJcFMGSZW6YpshJurTwjKy45UTZE+sTdopLgbjKiZ0e3lQXtlQM6JG9iFF7aPZ2drQRSnl70hEkSZgcHOJgg6wd0uV+M4cUo4wRiXX7oxjoPfkRdXmTQCVCZyuaA8nCl3gE7PUTMqTFesit21oaVXRjfnl6vXqtZXbDj5uS/HpBasEOydne3WIGpp7KyJ2YIPdt7fxYbJd1XmCLRU2DaDrHik6dzsctXEDQfWDT/Ji/Hpl707+tKveAzLFEJaFVQRiA5FT6LrEVRafYfukGLtmiqlNJJmVHZAnss5XjdbqjIwakRnNeE129j2LH9YE9zQXF+s9T5z/a96vqsNve+lp0xyE/ipFOS+UXvsC9rwPOUxKoGfwt959OMhlN8nlF+flmTVGAbQSxMtlRDFQMlUiYPDkldAA2LICWkDFMhUQkuVL+WlUqvYodlbopBdD0AK2UNiu18mm73uarDsSdqRHReTnSB61hK7ndRFdRnd3WRAuT0Oawcf8uYA5N6XrawamCjcqlWUn38LNLqZ8D8NxgOpouWeWE+DVMhgFCw5xCQEY1VeJAKFANJAN4gmYACiKkMaCBNTQ0JVpZwEruOU4xAIqxeNaaeLmaPT7trEVU2afQzoGuvOc/Y3zFpuG8wpMGexau7jU/GVX3MjbuP40petrKYGUuV/E8CHAH5Ib/3cKxHGr0YcvxLGF4FaBTQAUMgZQJkkg1laTyr58AGSiakMqchcTgmsK2FQgESJhBnBGCAvRFsheDVZvAhLBwI1AsoLqYuI1o5Ru66jdROknE4d9TKjsZAc2VMNUi5hq+KRMFgBXL+J2zie1Tu0SwY00hUQcfhYwD0bEb/0kk8B+BQWnKXYy+xE6zNHFfQirGnzSy+30fiIyL9uw2v+ArUJ+MjFYFKjMYNsDxVNEdX6M6tEDwQ1l0Rhw6azpUykmcetaBz++wgA18/Nl+PSVnk8etzw5VPEn7xBOHFKwMaV/qEDdbF88EMXvge68BNm/kKNz7vTMhNSd8uk+c469ZnqPcywBz3EbywUUdvxjIs5ERA1PBTi+MJv+I+98Dvm9QpdyV+z4JWl/zHi6A3EI08bHrwtAvClH7h4nYqL/4mhfLVGF9xJS9a7yo1YFlrrOIJsB1GzavN1o2x22DiR/hr75SLMow1JhDeU7z/0uzh6PODELfFZ+gkTPDM/xXLrAwXuvGmMd229YqDN+4K2roleSoBVcgnm3mA2OxmnffnZFKoDwLpol6AnSb9BYIylrzy/iFtnf0Y/9vzb5xF/76unP/cewp03jXHrAwP8+PKnSfxzLF1FMgVCoKH+X4ttjguqZQ+tJwawTkSco2laOp5WfW+10LdHLR8q4njzY5J+GOsyXH9Kz/KP+DyTbEgAc/B9uGZ0+olPAniB+yiPtli7v4dsQ1DT2LK/yFM7udlGkA2n12NEsRoiwpcd5V/Cew89vJP07ycNQD2IcewYz72bTzr5gIarAOkwa8QQWbLNJlJvjUjYplLK9RgBjbXU01IAliRfpYYHQrThUxbK78R7Dz2MwyeLnYi//xgAIC0LIJbCownrTcrEaxK6CtBbhLdu3kiZPzkMqWGpYTLcSyxfXbgNP2PBvq3cOHQ/1k8WuGexiZn9x4ATyVUx+hptOnfDOt/TJH73V3wqrEcK0muNybBjhMHdHNLaC4pI/vYwDA6X68Pf3+2gHvcdAyBiHRyUT99vYel1vn3eZWZgmKB47mJQN6HfaAe3yr3s/NgNIZirRFguYigAC++Lb7B/iiMscfhkgXt2N6hn++6H1gAcGG7/mTAYvoa+DQRjLb3513jaBZP2EjAphc/s3TQgxwSTPAiOtauLOBg8guXBt8f3hHfjCFP74T27n5LcXwy4IU3ZjcG/YUtrS5CizDiBH06XKzmBm0T4pr2YGGFzjyxWzFcOmZv/QjxQvD6+i/8tTUmucxGDexmScc9xF5SM+FEdxPbW9yBuw3OhnmxMu0iN1TZSYm1Sk2EjEFYVXLlFwNeuDq74GQXeEd9lv9aYDY64hKVBin1kfA1AXPb4nWFp+Vq/cCYqWKhSBXXTNCdrr9U5uEZRXZz0twVXZLEa4tIAMvz8yjXhPee/l483ZoMv+ccU9w8DTh0TJPJHtm8FCVljSJKsG8iBRo2n2VpSpxYESm4CtHooROERLOOd8Qf5n89fJqnff15QzrWvfECvt63yo9reYpSq2dIaUTyvNz9p47JGBJw9HKFksVqoCHDi30bih3EHn8DhkwXeeLdjY0OXi/j7RwOOZv9/q7wNRWEasRRV1AVyAQ7PDYvsNF/ldT7hbm7UgQOFwx+2If5h/AH+egvr78FlT7MX+8L1vIVx5QN6CS6Wf03bI4gI9bQSmz+fyqnlHQmJLufwYHBzl+GnDrzc/tmZ7+LpidQfKa/U5Rf7w/UENIpvteXiKp2/EEVm42uNlv7cOKtGbcwRiRB0YDU48AdYCe+Mb+fdZ66w1O8jG5Brgj+HleXT5R8Gs+vieMuFVH1GvfZsnpJKU4WgSxSdyweCM25pwJ+Iy198H2578ebEw9n7Ahx/fDTgePqNs8Gm/ootFdfp4kUHc1U+B19pgrDh10dF2jD46lIQcfdwNdyx+bb848yX2cPZ/wyo+mzG8VYNg0TWrr7YmWqS3KKg1YPBDU9hiI3y7fjXJemJ8FcW6/cfBGXXc/BB/TmO4wMhenA52zORuSU1ekRYDj4IiIb/ODiIfzRKK10ZDq8b7tl4RqV+f2jA9chDJPGvDpZCga2yBFnUk+Ak4O6MpK+uheh4NCzjPXo7/90IAG59YIA7X1viHpbP5m0UX8HeT+ptK8uXcynEarY8R7yOUtJwNfhAUMC/8VUc87fxS/XQ9J03jZ8Lt1F8BeM/AaAYLv22Av62Us+pSyCKVfNlIDp+15b4nvj3+OFny8jubzdUIu5GCA/6B0D7PghDwOEFHtaSfRCve/DncdNN44ZrqecS8fdXRezHdT0cL0fAabwWD+EIt9IyYifDc03q99+jbxmA9ZPFTkvFfPVxuZlwXAFHFb5K+K8+Fn78f4eywyDh1HjXAAAAAElFTkSuQmCC" 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>
+<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" >Auto 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" aria-current="page">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>
+<main id="content" tabindex="-1"><div class="breadcrumb">Documentation <span>/</span> Engineering records</div><article><h1 id="dynamic-teams-workflows-messaging-and-memory">Dynamic teams, workflows, messaging, and memory</h1>
+<blockquote>
+<p>Engineering plan and record. Revision 4 below records the implementation scope and remaining extensions; the revision 3 material that follows records the delivered baseline. For current usage, start with the <a href="index.html">documentation library</a>.</p>
+</blockquote>
+<p>Status: <strong>revision 4 core implemented</strong>, updated 21 October 2026. Dynamic Auto is the fresh-session default, Solo is directly accessible, fixed workflows and versioned templates live in Advanced, and all new runs resolve a shared permission policy at every agent launch. The revision 3 scheduler and live-tool bridge remain the execution foundation. See the <a href="auto-team.html">user guide</a> and <a href="dynamic-teams-evaluation.html">measured evidence and rollout decision</a>.</p>
+<h2 id="revision-4--dynamic-auto-solo-and-reusable-templates">Revision 4 — dynamic Auto, Solo, and reusable templates</h2>
+<p>This revision supersedes the earlier opt-in product/default decision and the proposal to make template selection the main Auto behavior. It extends the existing dynamic engine; it does not restart P0–P8. Historical measurements and implementation claims below remain unchanged.</p>
+<h3 id="delivered-scope-and-explicit-limits">Delivered scope and explicit limits</h3>
+<ul>
+<li>Added closed, versioned task-graph/fixed-workflow template definitions, an atomic server library with immutable history, project/personal scope, migration of browser presets, import/export, JSON editing with execution preview, and save-from-run. Auto may compose enabled task graphs; manually selected definitions are mandatory and pinned across recovery.</li>
+<li>Moved fixed workflows into Advanced without replacing their executors or weakening test-first, race, council, loop, or review behavior. Typed composition of those fixed executors remains a future extension; only validated task graphs are currently Auto-compatible.</li>
+<li>Added a shared per-launch policy resolver, recorded effective permissions, narrower turn access, provider eligibility checks, explicit user policy revisions, and inherited mandatory restrictions for child runs. All engine-created runs use the policy, including background and collaborative starts; historical saved runs without a policy retain their existing behavior.</li>
+<li>Controlled launches currently support Claude/Codex. Unsupported provider capabilities fail closed. This is not an identical cross-provider sandbox: filesystem read isolation, general browser/MCP allowlists, and a unified sandbox for setup/check/preview processes remain outside this implementation. Real-provider enforcement acceptance is still required before claiming equivalent isolation; deterministic adapter tests only verify configuration and orchestration.</li>
+<li>Auto retains its existing independent verification model. Coordinator-only investigations, typed artifact/control-flow composition, automatic template-upgrade proposals, and a visual graph designer remain future extensions. The initial designer uses validated JSON and a readable task preview.</li>
+<li>The application default is decoupled from historical quality-evaluation results. Existing explicit mode choices and the Auto disable switch remain intact; no evaluation evidence is synthesized by this change.</li>
+</ul>
+<p>The D0–D6 entries below describe the full design, including these remaining extensions. They should not be read as a claim that every listed extension or release acceptance probe has been completed.</p>
+<p>Initial implementation validation on 21 October 2026: typecheck and production build passed; 29 focused policy/template/adapter/composer checks and 11 browser scenarios passed. The full regression run reported 1,208 passes, eight skips, and two compatibility failures; both failures were corrected and passed in focused reruns. The full suite was not rerun after those fixes. Browser and adapter scenarios use deterministic CLIs, not live-provider sandbox enforcement probes.</p>
+<h3 id="product-decisions">Product decisions</h3>
+<div class="table-scroll" tabindex="0"><table>
+<thead>
+<tr>
+<th>Surface</th>
+<th>Intended behavior</th>
+</tr>
+</thead>
+<tbody><tr>
+<td><strong>Auto — default</strong></td>
+<td>The coordinator investigates the goal, builds an appropriate plan, delegates useful work, and adapts to results. It can start without a template, reuse one, or adapt/combine compatible templates.</td>
+</tr>
+<tr>
+<td><strong>Solo — directly accessible</strong></td>
+<td>One execution agent handles the task; delegation is disabled. Keep it beside Auto in the composer, without opening Advanced.</td>
+</tr>
+<tr>
+<td><strong>Advanced — templates and configuration</strong></td>
+<td>Users choose existing patterns as reusable templates, design their own, edit versions, and configure roles, dependencies, provider/model preferences, and required checks.</td>
+</tr>
+<tr>
+<td><strong>Reasoning and resource controls</strong></td>
+<td>Model effort, concurrency, time, invocation, and spending limits remain separate from execution mode. Do not introduce another Ultra mode in this revision.</td>
+</tr>
+</tbody></table>
+</div><p>Auto is allowed to use the smallest useful execution plan. An investigation may stay with the coordinator; a small code change may need one implementation worker and the verification required by the run. Do not create multiple implementation workers merely because Auto is selected. Required independent review remains independent; choosing Solo must never silently start a reviewer agent. If a selected policy requires another agent, explain that incompatibility before execution.</p>
+<p>Code Flow owns scheduling, workspaces, communication, recovery, permissions, budgets, and verification across providers. The coordinator proposes work and revisions through validated records. Use the existing declarative plan and event scheduler; arbitrary generated orchestration scripts and untracked provider-native teams are outside this revision.</p>
+<h3 id="current-foundations-and-gaps">Current foundations and gaps</h3>
+<div class="table-scroll" tabindex="0"><table>
+<thead>
+<tr>
+<th>Existing foundation</th>
+<th>Revision 4 work</th>
+</tr>
+</thead>
+<tbody><tr>
+<td><code>src/patterns/auto-team.ts</code>, <code>auto-team-model.ts</code>, <code>src/teams.ts</code>, and <code>src/team-scheduler.ts</code> already support generated tasks, dependencies, bounded revisions, messaging, and recovery.</td>
+<td>Extend this execution path and its contracts. Keep generated tasks usable without any template lookup or match.</td>
+</tr>
+<tr>
+<td><code>src/patterns/team-strategies.ts</code> expands three declarative subplans.</td>
+<td>Generalize the reusable-strategy contract to versioned templates with explicit inputs, outputs, and preserved guarantees.</td>
+</tr>
+<tr>
+<td>Fixed patterns have established execution and verification behavior.</td>
+<td>Expose them in Advanced, then share guarded execution primitives so Auto can reuse them without losing those guarantees.</td>
+</tr>
+<tr>
+<td><code>ui/composer-tools.ts</code> and <code>ui/onboarding.tsx</code> already save personal/project task templates and presets in browser storage.</td>
+<td>Add a server-accessible, versioned team-template library and migrate existing entries. Current entries are mainly prompts/settings, not executable team definitions.</td>
+</tr>
+<tr>
+<td><code>src/engine.ts</code> passes <code>params.trust ?? run.trust</code> to adapters; adapters map those labels differently.</td>
+<td>Resolve and validate effective permissions centrally at every launch, including replacements and resumed turns.</td>
+</tr>
+<tr>
+<td><code>ui/state.ts</code> defaults to Pipeline; <code>ui/composer.tsx</code> remembers a team workflow; evaluation metadata can change the default.</td>
+<td>Separate execution-mode preference from template selection and evaluation evidence. Make Auto the application default while preserving explicit user choices.</td>
+</tr>
+</tbody></table>
+</div><h3 id="d0--define-run-policy-and-execution-contracts">D0 — define run policy and execution contracts</h3>
+<p><strong>Outcome:</strong> every execution path derives authority from the run, independently of the selected provider or template.</p>
+<ul>
+<li>Introduce a versioned run-policy record and a common permission resolver at the engine launch boundary. Cover filesystem reads/writes, terminal actions, network access, browser access, MCP tools, approval behavior, execution environment, and delegation where supported. These are separate capabilities: terminal network permission does not automatically grant a browser or connector.</li>
+<li>Derive effective permissions from the authorized run policy, current project/host restrictions, and any narrower turn access. A coordinator&#39;s read-only planning turn must not accidentally make its implementation workers read-only. Conversely, templates, model output, messages, role settings, and provider changes cannot grant additional authority.</li>
+<li>Treat tool availability separately from permission. Inherit the run&#39;s allowed tools where the provider and execution environment support them; route only to eligible providers. Record unsupported or unavailable capabilities explicitly. Do not pass credentials or provider-specific session handles between agents/providers.</li>
+<li>Have each adapter report the enforcement it can provide. Use existing supported isolation when needed; otherwise reject the affected launch with a concrete explanation. Never interpret matching permission labels as proof of equivalent enforcement. Worktrees alone do not restrict reads, and prompt instructions do not constitute a sandbox.</li>
+<li>Apply the resolver to planning, workers, review, integration/repair, retries, replacement members, manual templates, and Solo. Audit setup, checks, previews, remote execution, and container paths too: commands outside the native agent sandbox need their own policy enforcement or an explicit run-authorized execution boundary.</li>
+<li>Persist the policy revision and effective capability summary with each launch. On recovery, retain the authorized policy and revalidate against current restrictions; a revoked permission or weaker replacement provider blocks new affected work. Any explicit user policy change creates a new revision. Reconcile an active process before continuing under changed restrictions.</li>
+<li>Keep Code Flow as the delegation authority. Disable unmanaged provider-native delegation for controlled runs, including Solo; providers unable to enforce a required delegation restriction are ineligible for that mode.</li>
+</ul>
+<p><strong>Primary code:</strong> <code>src/engine.ts</code>, <code>src/adapters/types.ts</code>, provider adapters, <code>src/provider-eligibility.ts</code>, team-tool grants, execution/container/remote-worker boundaries, and shared policy types.</p>
+<p><strong>Exit evidence:</strong> mixed-provider launches receive the intended effective policy; read-only turns remain narrower; retries and replacements cannot increase access; missing enforcement is surfaced rather than silently downgraded.</p>
+<h3 id="d1--strengthen-dynamic-auto-on-the-existing-runtime">D1 — strengthen dynamic Auto on the existing runtime</h3>
+<p><strong>Outcome:</strong> Auto succeeds without a template library and adapts its plan within the run&#39;s constraints.</p>
+<ul>
+<li>Keep initial planning and bounded revisions as the core behavior. The coordinator chooses eligible members, tasks, ownership, dependencies, and sequencing from the current goal and observed evidence. Provider/model pins and runtime verification requirements remain authoritative.</li>
+<li>Preserve task/member/attempt identities and journal accepted revisions before dispatch. Start ready work through the existing scheduler; ask the coordinator for decisions when evidence requires judgment, rather than on every scheduler event.</li>
+<li>Support the smallest useful plan, including coordinator-only investigations where allowed. Keep independent verification for code changes and reserve its budget before admitting additional work. Make task-kind changes explicit so an investigation cannot become an unauthorized implementation task.</li>
+<li>Reassign unfinished work through a checkpoint/handover, without transferring a provider&#39;s native session to another provider. Validate file ownership, serialize conflicting writers, and bind artifact dependencies to recorded commits.</li>
+<li>Preserve completed work when replanning. Invalidate only evidence affected by changed inputs/contracts and require fresh checks before reporting success. Bound expansion, repair, retries, and coordination overhead using the existing run limits.</li>
+<li>Expose the accepted plan, decision rationale, active workers, revisions, blockers, and remaining budget in the run view. Permission changes are runtime/user decisions, never coordinator decisions.</li>
+</ul>
+<p><strong>Primary code:</strong> <code>src/patterns/auto-team.ts</code>, <code>src/patterns/auto-team-model.ts</code>, <code>src/teams.ts</code>, <code>src/team-scheduler.ts</code>, <code>src/workflow-control.ts</code>, and <code>ui/team.tsx</code>.</p>
+<p><strong>Exit evidence:</strong> an empty template catalog does not prevent a small task or a parallel feature task from completing; a worker failure causes a bounded revision and recovery without replaying completed work unnecessarily.</p>
+<h3 id="d2--versioned-templates-using-the-same-execution-contracts">D2 — versioned templates using the same execution contracts</h3>
+<p><strong>Outcome:</strong> users can save reusable team behavior, and the server can validate it before execution.</p>
+<ul>
+<li>Define a shared schema for identity/version, scope, description/applicability, input parameters, role slots, preferred providers/models, tasks/dependencies, ownership, input/output artifacts, required checks, immutable guarantees, and permitted adaptations. Keep the existing starter-prompt catalog distinct from executable team templates.</li>
+<li>Add a durable server-side store/API for built-in, personal, and project templates, with existing account/project access rules, version-conflict checks, and bounded import/export. Built-ins are immutable; users create their own versions or copies.</li>
+<li>Normalize a generated plan and an instantiated template into the same validated execution records. Use typed, bounded control primitives for behavior that a simple task DAG cannot express, such as candidate selection and repair loops. Avoid a separate untracked execution engine.</li>
+<li>Pin the template version, definition snapshot, resolved inputs, expansion, and adaptation patch in each run. Editing or removing a library entry must not change an existing or resumed run.</li>
+<li>Templates can declare required capabilities and suggested resource limits; they cannot grant permissions, weaken required verification, or enlarge the authorized budget. Exclude credentials, auth-volume bindings, session IDs, old results, private transcripts, and machine-specific workspace paths from reusable definitions.</li>
+<li>Migrate existing browser libraries idempotently and retain a recoverable copy. Preserve names, task inputs, criteria, role preferences, and supported workflow options. Stop applying saved trust/tool-approval settings or disabling current isolation. Translate unsupported settings into visible migration notes rather than pretending they are enforced.</li>
+<li>Default user/imported templates to manual use until enabled for Auto. Supply the coordinator only the enabled, accessible, compatible catalog; a template&#39;s text is source material, not authority.</li>
+</ul>
+<p><strong>Primary code:</strong> new shared template schema/store/API modules; <code>src/teams.ts</code>, <code>src/server.ts</code>, <code>src/shared-access.ts</code>, <code>ui/composer-tools.ts</code>, and <code>ui/onboarding.tsx</code>.</p>
+<p><strong>Exit evidence:</strong> a template selected on another client resolves to the same immutable definition; importing or applying a template cannot change the run&#39;s permissions; existing browser libraries migrate without duplicate entries or lost originals.</p>
+<h3 id="d3--convert-existing-patterns-into-reusable-templates">D3 — convert existing patterns into reusable templates</h3>
+<p><strong>Outcome:</strong> familiar workflows remain available in Advanced with their original behavior.</p>
+<p>Initially register built-in template definitions that invoke the existing executors. Preserve legacy pattern IDs and replay identities for saved runs, automations, API clients, and extensions. Extract shared execution primitives incrementally; do not reimplement a pattern as a loose sequence of prompts.</p>
+<div class="table-scroll" tabindex="0"><table>
+<thead>
+<tr>
+<th>Built-in template</th>
+<th>Guarantees that must survive reuse</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>Plan / Build / Review</td>
+<td>Plan checkpoint, implementation, required checks, independent review, and bounded fixes.</td>
+</tr>
+<tr>
+<td>Supervisor / Workers</td>
+<td>Decomposition contracts, separate writer workspaces, integration, conflict handling, and final verification.</td>
+</tr>
+<tr>
+<td>Test first</td>
+<td>Failing baseline evidence, protected tests, implementation, and passing verification.</td>
+</tr>
+<tr>
+<td>Iterative loop</td>
+<td>Bounded iteration, progress/regression checks, and the existing rollback behavior.</td>
+</tr>
+<tr>
+<td>Candidate race</td>
+<td>Isolated candidates, anonymized evaluation, deterministic recorded selection inputs, and required checks.</td>
+</tr>
+<tr>
+<td>Debate</td>
+<td>Recorded proposals/decision, optional implementation, and verification appropriate to the selected behavior.</td>
+</tr>
+<tr>
+<td>Review council</td>
+<td>Read-only source review, independent findings/reproductions, and evidence-preserving synthesis.</td>
+</tr>
+</tbody></table>
+</div><p>For Auto composition, each reusable executor needs explicit input/output commits or artifacts, unique operation namespaces, and a scoped result. It shares the parent run&#39;s permissions, budgets, cancellation, and history, and cannot overwrite the parent&#39;s final verdict or reset counters. Prevent recursive template cycles and bound expansion. Mark Auto compatibility only after these guarantees are tested; Advanced availability alone does not establish composability.</p>
+<p><strong>Primary code:</strong> <code>src/patterns/index.ts</code>, existing pattern modules, <code>src/patterns/team-strategies.ts</code>, and engine execution-context helpers.</p>
+<p><strong>Exit evidence:</strong> parity fixtures pass for every built-in pattern; each template advertised for Auto composition preserves its guarantees under the parent run&#39;s limits and recovery behavior.</p>
+<h3 id="d4--optional-reuse-adaptation-and-saving-from-auto">D4 — optional reuse, adaptation, and saving from Auto</h3>
+<p><strong>Outcome:</strong> Auto can build fresh, reuse, or combine compatible templates without being required to choose one.</p>
+<ul>
+<li>Give the coordinator a compact eligible catalog with applicability, inputs/outputs, required capabilities, estimated overhead where known, and adaptation limits. Preserve direct task generation as an equally valid path.</li>
+<li>Accept a versioned template reference, inputs, role assignments, and bounded patch. Resolve and expand it on the server, then validate it alongside generated tasks against the same requirements, permissions, ownership, verification rules, and budgets.</li>
+<li>Show which work was generated, reused, or adapted and why. Validate composition boundaries explicitly; reject cycles, incompatible artifacts, invalid role assignments, and attempts to remove required checks. An unavailable optional template can lead to a fresh valid plan; an explicitly selected mandatory template produces a visible blocker.</li>
+<li>Distinguish an in-run adaptation from a library upgrade. Adapting the current plan does not mutate its source template. An agent may propose an improved version with a comparison and supporting evidence; a user saves/publishes it explicitly. Revalidate the new version before enabling it for Auto.</li>
+<li>Add “Save as template” for a completed run or selected reusable portion. Preview parameterized inputs, roles, steps, and guarantees before saving. Capture the reusable method, not a transcript, one-off findings, secret values, or a promise that future runs will pass.</li>
+</ul>
+<p><strong>Primary code:</strong> coordinator schemas/prompts, template resolution/validation, <code>src/patterns/team-strategies.ts</code>, <code>ui/run.tsx</code>, <code>ui/run-actions.tsx</code>, and template-library UI.</p>
+<p><strong>Exit evidence:</strong> the same task can use a fresh plan, a template, or an adapted template through the same runtime; saved template versions stay unchanged until explicitly published.</p>
+<h3 id="d5--composer-advanced-and-default-migration">D5 — composer, Advanced, and default migration</h3>
+<p><strong>Outcome:</strong> the primary choice is Auto or Solo; reusable patterns and their design controls live in Advanced.</p>
+<ul>
+<li>Replace the main pattern selector with directly accessible Auto and Solo controls. Put template selection and the template designer in Advanced. Keep the active template name visible in the composer summary when one is selected, so a constrained template run is not mistaken for unrestricted dynamic planning.</li>
+<li>The Advanced designer supports parameters, roles/provider preferences, task dependencies, artifact contracts, required checks, and supported bounded control primitives. Include validation errors and an expanded-plan preview; support editing, version comparison, copying, and import/export using the same server schema.</li>
+<li>Keep reasoning effort and resource controls separate. Validate each selected provider&#39;s supported settings; do not translate an effort label into additional tool authority or assume provider labels have identical meaning.</li>
+<li>Default fresh/unconfigured sessions to Auto, and make the Auto control explicitly return to dynamic planning without a mandatory template. Preserve existing explicit Solo/project/workflow choices; map saved fixed-pattern choices to their Advanced template. When old storage cannot distinguish an implicit default from an explicit choice, preserve it and make Auto easy to select.</li>
+<li>Decouple the application default from the historical evaluation stage. Retain measured evidence, diagnostics, and the new-run disable switch; changing the product default must not fabricate a successful quality evaluation. If Auto is disabled or cannot launch under the current policy, explain the reason and offer Solo or a compatible template without silently changing modes.</li>
+<li>Preserve configured plan approvals, unattended authorization, external-source restrictions, and legacy automation/API behavior. A default change does not authorize spending, tool access, or an extra approval bypass.</li>
+</ul>
+<p><strong>Primary code:</strong> <code>ui/composer.tsx</code>, <code>ui/state.ts</code>, <code>ui/onboarding.tsx</code>, project defaults, run views, <code>src/team-evaluation.ts</code>, and API/automation compatibility paths. Update usage documentation only when the behavior ships.</p>
+<p><strong>Exit evidence:</strong> a new user starts in Auto, switches to Solo with one action, and can design/run a template in Advanced; existing saved choices and automations retain their meaning.</p>
+<h3 id="d6--acceptance-and-delivery-sequence">D6 — acceptance and delivery sequence</h3>
+<p>Implement <strong>D0 → D1 → D2 → D3 → D4 → D5</strong>, adding focused tests with each change. D6 is the release acceptance pass. The template designer and migration work may be developed once D2&#39;s schema is stable, but changing the default follows runtime and permission verification. Do not rebuild the scheduler or storage engine merely to support this revision.</p>
+<div class="table-scroll" tabindex="0"><table>
+<thead>
+<tr>
+<th>Acceptance scenario</th>
+<th>Required evidence</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>Fresh install, no templates</td>
+<td>Auto generates and completes an appropriate plan; template lookup is optional.</td>
+</tr>
+<tr>
+<td>Small task and Solo</td>
+<td>Auto avoids unnecessary parallel workers; explicit Solo launches no delegated agents, including hidden native delegation.</td>
+</tr>
+<tr>
+<td>Mixed-provider feature</td>
+<td>Eligible Claude/Codex or other workers inherit the run policy, use narrower turn access where required, and complete checks and independent review.</td>
+</tr>
+<tr>
+<td>Provider replacement</td>
+<td>A replacement preserves the run policy; unsupported mandatory enforcement prevents dispatch instead of weakening restrictions.</td>
+</tr>
+<tr>
+<td>Template parity and composition</td>
+<td>Advanced and Auto use the same tested template semantics; test-first protection, race isolation, loop bounds, and review-only constraints survive adaptation.</td>
+</tr>
+<tr>
+<td>Template migration and isolation</td>
+<td>Legacy library import is idempotent; permissions/auth bindings are not restored; personal/project access boundaries hold.</td>
+</tr>
+<tr>
+<td>Recovery during execution</td>
+<td>Recorded plan/template/policy revisions remain pinned; completed results are retained; current revocations stop affected new work.</td>
+</tr>
+<tr>
+<td>Adapt and save</td>
+<td>An adapted run can create a new template version; the original and all previously started runs remain unchanged.</td>
+</tr>
+<tr>
+<td>Compatibility</td>
+<td>Saved runs, explicit preferences, automations, extension patterns, remote execution, and the Auto disable switch retain documented behavior.</td>
+</tr>
+</tbody></table>
+</div><p>Use focused tests in the existing Auto/team scheduler/replay/strategy suites, adapter and approval tests, composer/library tests, and browser flows. Add bounded real-provider checks for enforcement claims; fake-agent tests verify orchestration but cannot establish sandbox equivalence. Run typecheck, relevant tests, the build, and documentation/link checks appropriate to the implementation. Report unavailable provider checks as unverified.</p>
+<p>The complete release demonstration starts in default Auto, builds a plan without requiring a template, optionally reuses an enabled template, runs workers across providers under the run policy, recovers from interruption, and delivers verified results. The user can then save the reusable strategy, inspect it in Advanced, or start the next task in Solo.</p>
+<p>Critical review fixes (21 October 2026):</p>
+<ul>
+<li>Removed the engine startup opt-out, inherited parent trust/approval ceilings and execution boundaries, and sent the full validated policy to remote workers.</li>
+<li>Revalidated installed native controls on every launch; rejected unavailable approval transports and strict-boundary/approval combinations. Codex overrides ambient writable roots, temporary write exemptions, approval policy and network settings. Claude explicitly disables Chrome when external tools are forbidden.</li>
+<li>Serialized follow-up permission mutations, validated recovered policy records, and preserved mandatory requirements across revisions and child runs.</li>
+<li>Preserved template dependency types and global acceptance criteria; template revisions cannot replace original instructions or widen owned paths.</li>
+<li>Updated built-in provider defaults to Claude/Codex. New runs using unverified Antigravity, ACP or extension adapters are rejected; legacy adapter-level compatibility remains separately tested.</li>
+</ul>
+<p>These checks establish adapter behavior using deterministic CLIs and local capability probes. They do not establish equivalent operating-system enforcement across providers, or disable arbitrary subprocesses launched through an authorized shell.</p>
+<p>Review validation: the full regression run passed 1,218 tests with eight skips and no failures. All 11 targeted browser scenarios passed, along with 28 focused inheritance/recovery/template tests. The final adapter and approval refinements passed nine adapter tests and the focused approval test. Typecheck, production build, and diff whitespace checks passed. Live-provider sandbox enforcement was unverified at that checkpoint; the 2026-10-21 report below records the subsequent bounded live probes.</p>
+<h2 id="revision-3-baseline-and-historical-implementation-record">Revision 3 baseline and historical implementation record</h2>
+<p>Prepared 17 October 2026 against repository revision <code>ee246c7</code>. Revised against <a href="dynamic-teams-plan-review-0.html">Review 0</a>. Phase numbers below supersede the original ordering; the review remains a record of the original proposal.</p>
+<p>Implementation is based on <code>main</code> at <code>8cb3641</code>, including its checked review findings and fail-to-pass proofs. Sections describing the original repository baseline below are historical design context, not claims about the updated code.</p>
+<h3 id="implementation-status">Implementation status</h3>
+<div class="table-scroll" tabindex="0"><table>
+<thead>
+<tr>
+<th>Work package</th>
+<th>Delivered</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>P0 + Slice 0</td>
+<td>Opt-in Auto team, strict provider-compatible schemas, composition rules, approval, independent members, capability inventory, verification and launch budgets</td>
+</tr>
+<tr>
+<td>P1</td>
+<td>Fail-closed fsynced journal, incomplete-tail recovery, deterministic completion/command replay, crash recovery, SSE restart reconciliation and measured replay bytes/time</td>
+</tr>
+<tr>
+<td>P2</td>
+<td>Member/session/settings/usage identity, isolated writers, typed knowledge/artifact/completion dependencies, integration SHA inputs, stale-attempt rejection and bounded replacement</td>
+</tr>
+<tr>
+<td>P3</td>
+<td>Private checkpoints, team proposals/contracts/findings, attributable project retrieval/promotion, inspector/CAS/retention/deletion, exact-revision relevance feedback and fixture/real-run retrieval measurements</td>
+</tr>
+<tr>
+<td>P4</td>
+<td>Event-driven ready-work dispatch, atomic mailbox commands/receipts, request/wait/deadline state, idle answer turns, immediate/duplicate replies, cycle/unavailable escalation and replayed completion batches</td>
+</tr>
+<tr>
+<td>P5</td>
+<td>Bounded expansion/retirement, safe handovers, compact coordinator checkpoints, declarative reusable subplans, affected-evidence invalidation, shared Supervisor decomposition/integration primitives and saved-wave compatibility</td>
+</tr>
+<tr>
+<td>P6</td>
+<td>Scoped Claude/Codex MCP bridge, expiring member credentials, server-derived authority, durable inbox/memory tools, agent-origin live steering with queued fallback, explicit capability/nested-agent limits and real CLI smoke checks</td>
+</tr>
+<tr>
+<td>P7</td>
+<td>Composer and workflow/inbox/context/memory views, approval and blockers, phone/automation integration, bounded follow-ups, explicit in-flight goal revisions, parent-context/source-trust retention and new-run disable switch</td>
+</tr>
+<tr>
+<td>P8</td>
+<td>Fault/compatibility/browser tests, isolated fake and real paired evaluation runner, immutable versioned reports, approval/memory/replay/coordination measurements and a recorded rollout decision whose beta/default stages are evidence-gated (the stage is a label and a composer default; availability is controlled by <code>CODEFLOW_AUTO_TEAM_ENABLED</code>)</td>
+</tr>
+</tbody></table>
+</div><p>The user&#39;s instruction to implement all remaining phases explicitly opened P4/P6 on 17 October 2026. Their original sampling gates remain below as historical decision criteria; the implementation does not claim that a 20-run/100-turn latency experiment has been completed. The reproducible no-barrier fixture demonstrates the scheduling order (a dependent starts before an unrelated slow worker ends); it measures no benefit. Real model quality, overhead and default rollout are assessed separately in the evidence report.</p>
+<p>The storage decision is to retain the single-writer JSONL journal. One durable command envelope contains question/wait effects and its receipt; replayed drain batches and completion order provide the required logical atomicity. Disposable projections, rather than an outbox, database, leases or a new runtime baseline, remain sufficient. Node 20/22 CI configuration is preserved.</p>
+<p>The rollout decision is <strong>experimental/opt-in</strong>. Implementing the rollout gate does not force promotion: the initial real comparisons expose bounded-time failures and coordination overhead, so there is no evidence for making Auto the default. Unknown vendor-native usage remains unknown; unsupported adapters retain their structured-outcome path.</p>
+<h2 id="1-product-promise-and-delivery-decision">1. Product promise and delivery decision</h2>
+<blockquote>
+<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>
+</blockquote>
+<p>The user should not need to choose an orchestration pattern. A coordinator investigates the goal, proposes members and a workflow, gets plan approval according to the user&#39;s settings, and adapts the work as evidence arrives. Small tasks should produce small teams. Success means satisfying the task with evidence, not creating more agents.</p>
+<p><strong>Build Slice 0 before a storage migration, a new scheduler, or a mailbox service.</strong> It is an opt-in <strong>Auto team</strong> pattern on the existing engine: coordinator planning, plan approval, dependency waves, addressed questions in structured outcomes, bounded revisions, and independent verification. Minimal private checkpoints and team contracts are part of that slice. Reusable project memory follows execution data in Phase 3; Slice 0 does not claim to deliver that part of the promise yet.</p>
+<p>The long-term architecture stays the same: code-flow owns member identities, workflows, communication, and three memory scopes across official vendor CLI sessions. The delivery order changes so real runs determine how much infrastructure is needed.</p>
+<pre><code class="language-mermaid">flowchart TD
+    Goal[User goal and constraints] --&gt; Plan[Coordinator proposes team and tasks]
+    Plan --&gt; Policy[Runtime validates composition and limits]
+    Policy --&gt; Approval[Approve, revise, or reject under user settings]
+    Approval --&gt; Waves[Execute ready tasks; replay saved waves]
+    Waves --&gt; Outcomes[Artifacts, checkpoints, findings, questions]
+    Outcomes --&gt; Revise[Bounded coordinator revision when needed]
+    Revise --&gt; Policy
+    Outcomes --&gt; Verify[Integrate, check, independent review]
+    Verify --&gt; Result[Result with evidence and unresolved gaps]
+    Result --&gt; Promotion[Reviewed project-memory proposals]
+    Waves &lt;--&gt; Journal[Existing replay journal]
+    Outcomes --&gt; View[Run snapshot and SSE team view]
+</code></pre>
+<h2 id="2-what-we-reuse-and-what-actually-needs-changing">2. What we reuse, and what actually needs changing</h2>
+<div class="table-scroll" tabindex="0"><table>
+<thead>
+<tr>
+<th>Foundation</th>
+<th>Existing behavior</th>
+<th>Planned extension</th>
+</tr>
+</thead>
+<tbody><tr>
+<td><code>src/patterns/supervisor.ts</code></td>
+<td>Read-only decomposition, contracts, approval, parallel workers, integration and review</td>
+<td>Generate individual members, execute dependency waves, revise assignments and route questions</td>
+</tr>
+<tr>
+<td><code>TeamContext.decide()</code> / <code>remember()</code></td>
+<td>Completed decisions and operations replay from the journal</td>
+<td>Stable task/wave/attempt identities and deterministic application of recorded revisions</td>
+</tr>
+<tr>
+<td><code>src/store.ts</code></td>
+<td>Ordered JSONL writes, a synced replay journal, one-server lock</td>
+<td>Surface control-write failures; add batch records/snapshots only where required</td>
+</tr>
+<tr>
+<td><code>TeamContext.ask()</code> and adapters</td>
+<td>Official CLIs, sessions, structured output, retries, cancellation</td>
+<td>Member identity and validated member-specific settings, without replacing adapters</td>
+</tr>
+<tr>
+<td><code>src/routing.ts</code>, <code>src/stats.ts</code></td>
+<td>Availability/quota signals and repository outcome ranking</td>
+<td>Apply these inputs to a validated team composition policy; allow repeated providers</td>
+</tr>
+<tr>
+<td><code>src/git.ts</code>, engine worktree/check methods</td>
+<td>Isolated worktrees, replay-aware commits and checks</td>
+<td>Dependency inputs pinned to integration commits, explicit verification coverage</td>
+</tr>
+<tr>
+<td>Notes and Codex steering</td>
+<td>User-origin notes addressed by provider; some live input</td>
+<td>Member addressing and agent-origin messages kept separate from user instructions</td>
+</tr>
+<tr>
+<td><code>src/context.ts</code>, <code>src/learnings.ts</code>, <code>src/projects.ts</code></td>
+<td>Conventions, attachments, recurring findings, project membership</td>
+<td>Scoped checkpoints and attributable memory, with enforced promotion rules</td>
+</tr>
+<tr>
+<td>Run snapshot, SSE and composer</td>
+<td>Existing pattern selection, approvals and live steps</td>
+<td>Auto team choice, roster/tasks/questions and coordination metrics from Slice 0</td>
+</tr>
+</tbody></table>
+</div><h3 id="recovery-correction">Recovery correction</h3>
+<p><code>remember()</code> already journals the result of <code>decide()</code>&#39;s underlying agent call. A deterministic pattern replays completed coordinator decisions; it does not ask the model to invent its team again. Dynamic planning therefore does not, by itself, require a new recovery model.</p>
+<p><code>journalEntry()</code> calls <code>appendLine(..., { sync: true })</code>, and the journal write is awaited before the pattern continues. Ordinary event-log writes do not fsync each event. However, <strong>both paths currently use <code>appendLine()</code>, which catches write errors, increments <code>writeHealth</code>, and resolves</strong>. The journal has a durability mechanism but does not fail closed when that mechanism fails. Slice 0 should add narrowly scoped error propagation for authoritative journal writes and update the in-memory journal only after successful persistence. This is a small hardening change, not a database migration.</p>
+<p>Replay remains appropriate while execution is a bounded sequence of waves and recorded outcomes. Long-lived mailboxes, asynchronous wakeups outside those waves, or expensive replay could justify another driver later. Phase 4 has an evidence gate for that decision.</p>
+<h3 id="compatibility-facts">Compatibility facts</h3>
+<ul>
+<li><code>AgentId</code> is a provider (<code>claude</code>, <code>codex</code>, <code>agy</code>), not an individual worker. Existing role routing deduplicates providers within a role; dynamic member IDs must bypass that deduplication without changing manual-pattern semantics.</li>
+<li>Node 20 is supported and in CI. Preserve it for this plan. SQLite is not a prerequisite; any later driver proposal must explicitly address Node, packaging and platform support.</li>
+<li>Resume currently gives a fresh step/time budget. Slice 0 preserves this documented behavior for an explicit user resume, while reporting lifetime usage separately. A replayed wave never resets its recorded wave/repair counters. Internal retries do not silently grant a fresh budget.</li>
+<li>There are four <code>findPattern()</code> call sites in engine/server code. Register <code>auto-team</code> normally. Older versions already reject an unknown pattern on resume; no new execution-mode framework is necessary for Slice 0. Future incompatible plan schemas need an explicit version check.</li>
+<li>SSE reconnect cursors currently apply within one server start. Improving cross-restart reconnect helps legacy runs too and can ship independently.</li>
+</ul>
+<h2 id="3-invariants-to-keep">3. Invariants to keep</h2>
+<ol>
+<li><strong>Agents propose; the runtime validates and verifies.</strong> A coordinator cannot delete user requirements, increase its budget, raise trust, or authorize publishing through a plan revision.</li>
+<li><strong>Individual identity is independent of provider.</strong> Two Codex members have different IDs, context, sessions, assignments and usage attribution.</li>
+<li><strong>One active turn per member/session, one writer per worktree.</strong> Reassignment reconciles the previous process before starting another writer. Never pass a session ID between providers.</li>
+<li><strong>Persist accepted control state before acting on it.</strong> A failed authoritative write stops new dependent dispatch. UI projections are not a second source of truth.</li>
+<li><strong>Replay completed decisions.</strong> Stable identities, recorded inputs and deterministic ordering reproduce accepted plans. Current clock/quota/filesystem state must not silently change an already-recorded branch during replay.</li>
+<li><strong>Messages are not user authorization.</strong> Sender identity and source trust come from code-flow. Ordinary output text is never parsed as executable control commands.</li>
+<li><strong>Waiting releases capacity.</strong> A member needing information ends its turn with a checkpoint; it does not occupy a CLI slot waiting for another member.</li>
+<li><strong>Verification applies to evidence.</strong> Unknown or unrunnable is not a pass. A gap must never become success merely because all runnable tasks ended.</li>
+<li><strong>Project memory has an enforced trust boundary.</strong> A locked-down or otherwise untrusted source cannot automatically create instructions for future runs.</li>
+<li><strong>No exactly-once model-execution claim.</strong> A process can finish external work before its result is stored. Recovery reconciles artifacts and uses idempotent logical operations; transport or execution can repeat.</li>
+</ol>
+<h2 id="4-define-appropriate-team-before-implementation">4. Define “appropriate team” before implementation</h2>
+<p>These are proposed, testable defaults for the opt-in experiment. Record them in the plan and fixtures, rather than leaving them to a coordinator prompt.</p>
+<div class="table-scroll" tabindex="0"><table>
+<thead>
+<tr>
+<th>Rule</th>
+<th>Initial policy and validation</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>User constraints</td>
+<td>Preserve provider/model pins, trust, allowed paths, check commands and budgets. Reject revisions that exceed them.</td>
+</tr>
+<tr>
+<td>Availability</td>
+<td>Choose installed, usable providers. Reuse <code>exhausted()</code> signals, including near-full windows and recent authentication failures. Unknown quota is labeled unknown.</td>
+</tr>
+<tr>
+<td>All providers exhausted</td>
+<td>Auto team pauses or reports a routing blocker; it does not silently spend against a known exhausted provider. This is stricter than current <code>resolveAuto()</code>, which can fall back to exhausted candidates with a warning. Explicit user choices remain visible.</td>
+</tr>
+<tr>
+<td>Provider ranking</td>
+<td>Use existing repository pass-history ranking among eligible providers, with its existing fallback order. Treat it as a prior with limited evidence, not a universal skill score.</td>
+</tr>
+<tr>
+<td>Small teams</td>
+<td>Start with a coordinator, one worker and an independent reviewer. Allow a second worker only for tasks whose ownership/dependencies permit useful parallel work, with a stated reason. A read-only task may use the coordinator as its investigator.</td>
+</tr>
+<tr>
+<td>Size bounds</td>
+<td>Default maximum four active members including coordinator/reviewer, twelve tasks across accepted revisions, four execution waves, and two repair rounds. Reject expansion beyond the approved limits. These are experiment settings, not measured optima.</td>
+</tr>
+<tr>
+<td>Review independence</td>
+<td>Reviewer is a separate member/session, read-only, and cannot approve work it authored. Prefer a different provider from the primary author; record any same-provider fallback. If the user&#39;s policy requires different providers and none is eligible, report the blocker.</td>
+</tr>
+<tr>
+<td>Same-provider workers</td>
+<td>Allowed when useful. Member IDs, not provider strings or display names, identify tasks and communications.</td>
+</tr>
+<tr>
+<td>Models and effort</td>
+<td>Choose from the supplied supported/configured settings or the provider default. Do not invent a model name. Explicit user settings win.</td>
+</tr>
+<tr>
+<td>Workflow validity</td>
+<td>Unique IDs, existing owners, acyclic dependencies, bounded expansion, acceptance criteria for required tasks, and requirement coverage. Reject silent requirement removal.</td>
+</tr>
+<tr>
+<td>Ownership</td>
+<td>Concurrent tasks need compatible declared ownership; actual changed paths are checked before integration. Shared-file work is ordered or assigned to an integration task.</td>
+</tr>
+<tr>
+<td>Task kind</td>
+<td>Implementation requires applicable checks/review; investigation/design can succeed with an accepted evidence-bearing artifact and no code changes.</td>
+</tr>
+</tbody></table>
+</div><p>The first plan includes stable requirement IDs, editable acceptance criteria, members and rationale, provider/model/effort settings, tasks/dependencies, ownership, contracts, verification requirements, and a turn estimate with a hard cap. Estimates must distinguish known bounds from uncertain token use.</p>
+<h3 id="approval-and-revision-policy">Approval and revision policy</h3>
+<p>Use the existing <code>ctx.approve(&quot;plan&quot;, ...)</code> checkpoint before dispatching workers. Show the proposed team, settings, tasks, acceptance criteria, constraints and estimated turns. Approve, revise and reject must all work. Approval pauses the run clock and its recorded answer replays on resume.</p>
+<p>For a newly selected Auto team, default plan approval on; honor explicit saved choices and existing automation authorization. The initial planning call itself consumes quota, which the composer should make clear. When approval is disabled, still record the validated plan and why no interactive checkpoint was required.</p>
+<p>Routine reassignment or repair within the approved scope can proceed and remains visible. A user-requested goal change produces a new requirement/plan revision and goes through the same configured checkpoint before affected new work. Any proposal exceeding authorized providers, spending limits, permissions or scope requires the relevant user decision; the coordinator cannot approve that increase. Stop or finish the current turn safely before changing its inputs.</p>
+<h3 id="coordination-budget-and-measurements">Coordination budget and measurements</h3>
+<p>Use actual CLI invocations, including schema repair and retry invocations, for coordination accounting. Existing logical <code>agentSteps</code> alone may not expose every underlying retry; add attribution at the launch boundary. Report steps, input/output/cache tokens, elapsed time, and provider-reported API-equivalent cost separately. Missing token/cost reports are unknown, not zero, and API-equivalent cost is not a subscription bill.</p>
+<p>For the initial experiment, with an approved invocation budget <code>B &gt;= 4</code>, reserve at most <code>min(4, floor(B / 4))</code> coordinator invocations. Count initial planning, approval-driven replanning and wave revisions against this ceiling. Enforce the total execution limits too; reserve room for required review and checks before admitting more work. If the budget cannot fund a valid plan, explain that before worker dispatch.</p>
+<p>This caps coordination at 25% of the <em>authorized invocation budget</em>, not necessarily 25% of actual spend. A tiny run may use one coordinator turn out of three total turns. Report the observed fraction honestly. Use 25% observed coordinator turns on multi-worker runs as an initial evaluation target, not an asserted result or a runtime rule that could deadlock startup.</p>
+<p>At the coordination ceiling, run only already-authorized ready work and verification that fit the remaining budget. Do not create additional tasks or keep calling the coordinator. Return explicit gaps if another planning decision is required. User resume retains today&#39;s fresh-budget behavior; expose both the new allocation and cumulative spend. Automatic crash recovery must not be used as a budget-reset mechanism.</p>
+<h2 id="5-slice-0--demonstrate-the-promise-on-the-existing-engine">5. Slice 0 — demonstrate the promise on the existing engine</h2>
+<p><strong>Outcome:</strong> a user chooses Auto team, describes a task, approves the generated team/plan, and sees it execute and adapt without choosing a team pattern. This is the first user-visible milestone.</p>
+<p>Implement Slice 0 alongside the small Phase 0 contract work. It does not wait for Phases 1–4.</p>
+<h3 id="51-plan-and-replay">5.1 Plan and replay</h3>
+<p>Add <code>src/patterns/auto-team.ts</code>, register <code>auto-team</code>, and use <code>TeamContext.decide()</code> with <code>TEAM_PLAN_SCHEMA</code>. Reuse supervisor planning, approval, worktree, integration and review behavior where practical.</p>
+<p>Journal the planning inventory and relevant policy inputs before using them: provider availability/quota observations, configured settings, task limits and base commit. Validate completed decisions against their recorded input revision on replay; refresh availability at a new dispatch boundary through a new recorded observation. Do not recompute historical routing from today&#39;s quota or clock.</p>
+<p>Use stable identities such as <code>plan:0</code>, <code>wave:2</code>, and <code>task:api:attempt:1</code>. Create all task/attempt identities and a sorted wave membership before parallel dispatch. Keep unrelated operations out of those identity counters. Reconstruct the roster, sessions and questions from recorded outcomes; an <code>onStart</code> callback that does not run during replay cannot be the sole source of that state.</p>
+<h3 id="52-individual-members-and-workspace-handling">5.2 Individual members and workspace handling</h3>
+<p>Store a small member map within the pattern&#39;s replayable state. Add an optional <code>memberId</code> to step/ask metadata and a validated per-call settings override so two members on the same provider can actually use different configured models. Preserve existing role/provider settings as the fallback for legacy patterns.</p>
+<p>Associate each member with its current session lineage and workspace. Resume the same session only with its compatible provider and workspace. A new task in a different worktree gets a fresh session plus a portable checkpoint; do not assume a provider can safely resume a conversation in a different directory. Keep one active assignment per member.</p>
+<p>Create a task&#39;s worktree from the recorded integration HEAD containing its required upstream artifacts. A yielded task keeps its existing worktree and checkpoint. Reconcile any newer dependency commits only while that task is idle, then record the new input revision. A message describing code does not make that code available in another worktree.</p>
+<h3 id="53-execute-dependency-waves">5.3 Execute dependency waves</h3>
+<p>Select ready tasks deterministically, respecting dependencies, ownership, available members and global slots. Use <code>ctx.parallel()</code> and <code>allowFailure: true</code> for expected worker failures; retain run-wide stopping for unsafe process/storage/workspace failures.</p>
+<p>Each turn produces a validated <code>TASK_OUTCOME_SCHEMA</code> with:</p>
+<ul>
+<li>task/member/attempt identity and <code>submitted</code>, <code>needs_info</code>, or <code>failed</code> status;</li>
+<li>an observable checkpoint, artifact references and unresolved requirements;</li>
+<li>addressed questions/replies, contract proposals and evidence-bearing findings;</li>
+<li>the input/contract revisions the result relied on.</li>
+</ul>
+<p>A <code>needs_info</code> result ends the CLI turn and releases its slot. Preserve partial edits for that task; do not merge them as a completed dependency. Integrate submitted artifacts serially, handle conflicts through existing controlled repair, and run applicable checks. Downstream work starts only once its required artifacts and acceptance conditions are available.</p>
+<p>An agent saying “submitted” does not make its task verified. Code changes must pass the declared verification policy. No-change investigation tasks are evaluated against their artifact criteria.</p>
+<h3 id="54-questions-answers-and-revision-between-waves">5.4 Questions, answers and revision between waves</h3>
+<p>Represent communication as addressed records in the structured outcomes. A question has a stable request ID, sender, recipient, task, body, source provenance, and whether it blocks progress. A reply references that request ID. The runtime supplies authenticated identities rather than trusting model-written sender fields.</p>
+<p>After a wave, deterministically route known replies and evaluate ready work. Call the coordinator only when a decision is needed, at most once per wave within its budget. <code>REVISION_SCHEMA</code> can propose new bounded tasks, reassignments, accepted contracts, answer tasks, evidence-backed answers, or a completion proposal. Validate the patch against the previous revision and apply it before scheduling.</p>
+<p>If the recipient already supplied the answer, deliver it in the requester&#39;s next prompt. Otherwise schedule a short response task for that member in the next wave. The coordinator may answer from evidence or reroute the question, but cannot manufacture a missing requirement. Questions requiring user judgment become a visible input blocker. No-ready-work and cyclic waits produce a bounded escalation instead of empty waves or endless coordination.</p>
+<p>This is cross-agent communication at turn boundaries. No separate mailbox daemon, live tool bridge, delivery table, outbox, or lease is required. The coordinator does not need to rewrite every answer: addressed contents pass through to the appropriate member.</p>
+<p>Update the Auto team worker framing in <code>src/patterns/prompts.ts</code> so it explains <code>needs_info</code> rather than saying nobody can answer. Update relevant Codex app-server input-denial guidance to point Auto members at the structured protocol. Keep native permission requests subject to existing policy; supporting questions does not authorize new tool permissions.</p>
+<h3 id="55-minimal-memory-and-context">5.5 Minimal memory and context</h3>
+<p>Start with three small replayable objects:</p>
+<ul>
+<li><strong>Private checkpoint:</strong> current assignment, attempted approaches, observable progress, unresolved questions and relevant session/worktree references, scoped to that member.</li>
+<li><strong>Team state:</strong> accepted plan/contracts, shared findings, decisions, questions/replies and artifact references, selected for the current task.</li>
+<li><strong>Context manifest:</strong> the input commit, plan/contract revisions, message IDs and checkpoint used for each turn.</li>
+</ul>
+<p>Keep prompts bounded and send relevant deltas on resume. Record a compact coordinator checkpoint too: accepted plan, completed work, open decisions and remaining budget. Start a fresh coordinator session from that checkpoint when its context grows or resume fails; do not repeatedly send all worker transcripts.</p>
+<p>Use existing conventions and attributable lessons as inputs; do not implement a new project-memory index yet. Auto team must not automatically write project knowledge from locked-down runs through <code>learn()</code> or another side path. <code>learn()</code> currently checks replay and the learning setting, not lockdown; the implementation must explicitly close that bypass for automatic learning, with a regression test.</p>
+<h3 id="56-verify-display-and-measure">5.6 Verify, display and measure</h3>
+<p>Use an independent read-only reviewer, bounded repairs and final checks on the integrated result. A review after repairs must refer to the current commit. Start check identity with commit SHA plus command and a setup fingerprint when applicable; requirement/contract changes invalidate affected acceptance/review evidence without invalidating every unrelated check merely because the plan number changed.</p>
+<p>Completion is a runtime predicate: every required criterion has applicable evidence, required questions are resolved, and the integrated result matches that evidence. Use existing <code>setVerdict()</code>/<code>setFacts()</code> where their meaning fits, plus an additive team outcome/coverage projection. Do not force “completed with gaps” or an unknown check into a passed verdict.</p>
+<p>Add the opt-in composer choice and a minimal roster/task/question view now, using the existing run snapshot and SSE. Agent-origin communications must not go through the existing user-note formatter unchanged. Show coordination usage as soon as the first planning call completes, then update it throughout execution.</p>
+<p><strong>Likely files:</strong> new <code>src/patterns/auto-team.ts</code> and a small focused helper if needed; changes to <code>src/patterns/index.ts</code>, <code>src/patterns/schemas.ts</code>, <code>src/patterns/prompts.ts</code>, <code>src/engine.ts</code>, <code>src/store.ts</code>, <code>src/routing.ts</code>, <code>src/stats.ts</code>, <code>src/server.ts</code>, <code>ui/composer.tsx</code>, <code>ui/run.tsx</code>, shared UI types, and fake-agent fixtures. Avoid three new subsystem directories at this stage.</p>
+<p><strong>Exit criteria:</strong> the composer-to-verified-result scenario in section 10 passes with fake agents; a completed initial decision replays without another model call; two same-provider members remain distinct; a question blocks only its dependent work; coordinator usage and question frequency are recorded; review/permission settings still apply. Real opt-in runs supply the first product measurements, not a prerequisite for offline CI.</p>
+<h2 id="6-records-persistence-and-communication-as-they-grow">6. Records, persistence and communication as they grow</h2>
+<p>The original record names remain useful domain concepts. They do not all need separate durable tables or independent state machines.</p>
+<div class="table-scroll" tabindex="0"><table>
+<thead>
+<tr>
+<th>Concept</th>
+<th>Slice 0 representation</th>
+<th>Split or extend when justified</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>Run / workflow revision</td>
+<td>Existing run plus versioned accepted plan and journaled revisions</td>
+<td>Standalone workflow projection if event-driven execution needs it</td>
+</tr>
+<tr>
+<td>Member</td>
+<td>ID, role/provider/settings, session/workspace lineage</td>
+<td>Derive running/waiting state from attempts and blockers; persist retirement/replacement decisions</td>
+</tr>
+<tr>
+<td>Task / attempt</td>
+<td>Accepted task graph plus recorded turn outcomes and existing steps</td>
+<td>First-class attempt history during execution hardening</td>
+</tr>
+<tr>
+<td>Message / request</td>
+<td>Typed addressed records with optional request/reply reference</td>
+<td>Durable per-member inbox when asynchronous delivery is needed</td>
+</tr>
+<tr>
+<td>Delivery</td>
+<td>Context manifest lists messages included in an attempt</td>
+<td>Separate transport receipt only for live steering/tools</td>
+</tr>
+<tr>
+<td>Memory revision</td>
+<td>Member checkpoints and accepted team entries</td>
+<td>Project store, revisions, retention and retrieval in Phase 3</td>
+</tr>
+<tr>
+<td>Artifact / verification</td>
+<td>Existing Git/check outputs plus task/criterion references</td>
+<td>Additional evidence types as real tasks need them</td>
+</tr>
+<tr>
+<td>Event / command receipt</td>
+<td>Existing journal entries and stable operation IDs</td>
+<td>Atomic batch and deduplication receipt for multi-record async commands</td>
+</tr>
+<tr>
+<td>Outbox / lease</td>
+<td>Not required by the wave pattern</td>
+<td>Only if a measured execution architecture requires independent dispatch ownership</td>
+</tr>
+</tbody></table>
+</div><p>Tasks can be planned, ready, running, waiting, submitted, verified, failed, cancelled or superseded. Attempts distinguish interrupted execution from a failed task. Member display status is derived. Keep explicit run outcomes for succeeded, completed with gaps, awaiting input, failed, stopped and cancelled; legacy cards can project these without changing their historical meaning.</p>
+<h3 id="storage-requirements-and-default">Storage requirements and default</h3>
+<p>Start with the existing single-writer store and journal. Required properties are durable acceptance, stable operation IDs, ordered replay, idempotent application and recoverable snapshots. If one command must update several control records, append one versioned batch envelope containing all those changes, then fsync before acknowledging it.</p>
+<p>A filesystem append is <strong>not guaranteed physically atomic</strong>, even with one writer. Recovery must validate the complete framed record and apply the entire batch or none of it; an incomplete tail cannot expose partial logical changes. A damaged committed record in the middle of control history is a recovery error, not permission to skip a dependency. Test those semantics explicitly, including uncertain completion after a failed sync.</p>
+<p>Use snapshots as disposable projections tied to a journal sequence/checksum, written through a temporary file and replacement with platform-appropriate durability checks. Replay the remaining tail; do not discard authoritative history before snapshot/retention rules make that safe. Keep existing one-server ownership and process cleanup.</p>
+<p>Evaluate SQLite only if measured replay time, query volume, memory search or genuinely concurrent writers outgrow this model. Any proposal must compare complexity and durability, retain Node 20 or explicitly propose a platform change, and state install/backup/migration behavior. There is no mandatory database spike blocking Slice 0.</p>
+<h3 id="delivery-semantics">Delivery semantics</h3>
+<p>At turn boundaries, distinguish queued content from content recorded in an attempt&#39;s context manifest. A manifest describes intended inclusion; a completed turn provides evidence of execution. A protocol acknowledgement is not proof of comprehension. A question is resolved by an accepted reply or an explicit recorded resolution, not a delivery receipt.</p>
+<p>Use stable IDs and idempotent application across repeated turns. Live transport later adds accepted-steering receipts without changing request semantics. Never allow two concurrent resumes of one session, and never acknowledge a control operation before its authoritative write succeeds.</p>
+<p>Keep domain operations independent of HTTP/MCP: <code>send_message</code>, <code>ask_member</code>, <code>reply_request</code>, <code>yield_task</code>, <code>publish_finding</code>, <code>propose_contract</code>, <code>submit_task</code>, and <code>request_help</code>. Structured results are the first transport across all adapters. Add bounded inbox/memory reads only when those stores exist.</p>
+<p>Extend existing run snapshots and SSE before adding dedicated endpoints. Agent tools later call the same validated handlers with member-scoped credentials; user origin is derived from authenticated user requests, not a caller-supplied field.</p>
+<h2 id="7-private-team-and-project-memory">7. Private, team and project memory</h2>
+<div class="table-scroll" tabindex="0"><table>
+<thead>
+<tr>
+<th>Scope</th>
+<th>Purpose</th>
+<th>Visibility and lifetime</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>Private</td>
+<td>Portable progress checkpoint, attempted approaches, unresolved work and session references</td>
+<td>Only that member&#39;s assembled context; explicitly selected handover export; retained with the run under policy</td>
+</tr>
+<tr>
+<td>Team</td>
+<td>Accepted contracts, plan, decisions, findings, questions and artifact references</td>
+<td>Relevant members of the run; preserved across restart; archived with the run</td>
+</tr>
+<tr>
+<td>Project</td>
+<td>Durable conventions, architecture facts, test instructions and verified lessons</td>
+<td>Applicable future runs in the project/repository; revision, invalidation and deletion controls</td>
+</tr>
+</tbody></table>
+</div><p>Private means isolation in code-flow&#39;s context assembly and APIs. It is not filesystem secrecy from a fully trusted process on the same machine. Store concise observable checkpoints, not a claimed export of a model&#39;s internal reasoning. The user can inspect code-flow-owned records according to existing access policy.</p>
+<h3 id="provenance-and-promotion-rules">Provenance and promotion rules</h3>
+<p>Every shared item carries source run/task/artifact, originating source trust/lockdown, author, evidence, scope, relevant paths/commit, revision and status. Execution permission (<code>safe</code>, <code>standard</code>, etc.) and content provenance are separate: a read-only run can still read hostile source text.</p>
+<ul>
+<li>User-authored project rules can be saved directly under user authority.</li>
+<li>Eligible agent-authored facts may be promoted under the configured verification policy after their evidence and target-branch applicability are established.</li>
+<li>A locked-down run, or a proposal derived from untrusted content, cannot promote automatically. It stays a proposal until the user explicitly approves the specific content/revision.</li>
+<li>Derived summaries, replies and handovers retain source provenance. A coordinator or independent reviewer repeating a claim cannot remove its untrusted origin. The server enforces this; agents cannot set their own trust fields.</li>
+<li>Historical learnings with missing provenance are attributed observations, not automatically trusted conventions. The same promotion gate covers <code>learn()</code>, tool commands, summaries and imports.</li>
+<li>Retrieval labels provenance, separates facts from suggestions, and cannot override current user constraints or tool permissions. Team messages inherit the run&#39;s restrictions and source labels.</li>
+</ul>
+<p>Memory about an unmerged implementation stays team-scoped unless explicitly marked and accepted as branch-specific project knowledge. Project-wide conventions must not be inferred from one branch&#39;s code. Recheck applicability when branch, repository membership or project ownership changes.</p>
+<h3 id="selection-conflicts-and-deletion">Selection, conflicts and deletion</h3>
+<p>Build each turn&#39;s context from the goal, assignment, applicable project entries, relevant team contracts, private checkpoint, pending messages and artifact/check references. Select by task, paths, tags, freshness and text search first. Store included revisions and omissions in the context manifest; introduce embeddings only when an evaluation shows a need.</p>
+<p>Shared updates use expected revisions. Conflicts are visible and assigned to an owner; they do not silently overwrite accepted contracts. A changed contract identifies affected tasks and acceptance evidence.</p>
+<p>Deletion covers memory-store bodies and derived memory records, including its snapshots and retrieval data; retained memory history contains deletion metadata. Project selection journals contain references rather than bodies. Source run transcripts and task checkpoints already recorded in the run journal, prompts already delivered to a CLI, provider-managed conversations and user-managed backups have separate retention. The current implementation does not claim to redact those source histories; broader run-history erasure requires a separate retention design. Test exclusions and scope isolation with actual workflow data.</p>
+<h2 id="8-phases-after-slice-0">8. Phases after Slice 0</h2>
+<p>The original default path was <strong>P0 + Slice 0 → P1 → P2 → P3 → P5 → P7 → P8</strong>, with conditional P4/P6 enhancements. The requested complete implementation includes all packages. Reliability, UI visibility and measurement begin in Slice 0, not at the final phase. Phase labels identify work packages, not a requirement to build every subsystem before release.</p>
+<h3 id="phase-0--contracts-and-composition-policy-alongside-slice-0">Phase 0 — contracts and composition policy, alongside Slice 0</h3>
+<p><strong>Deliver:</strong> plan/revision/outcome schemas, the section 4 validation rules, task-kind verification policies, fixtures and an adapter capability inventory. Record structured-output, session-resume, live-input, tool-configuration and sandbox support as tested/unsupported/unknown. Include Claude&#39;s tool allowlist and vendor-native subagent observability.</p>
+<p><strong>Exit:</strong> valid/invalid plan fixtures cover duplicate members, unsupported settings, cycles, over-budget teams, reviewer independence and requirement removal. Slice 0&#39;s first PR can begin immediately; no platform migration blocks it.</p>
+<p><strong>Code impact:</strong> existing pattern schemas and focused policy helpers. No broad engine extraction or new storage tree.</p>
+<h3 id="phase-1--prove-recovery-and-harden-storage-where-needed">Phase 1 — prove recovery and harden storage where needed</h3>
+<p><strong>Deliver:</strong> fault-injected recovery for Slice 0 and an architecture decision based on observed requirements. Verify strict journal writes, completed-plan replay, deterministic parallel identities, crash-after-Git recovery and no concurrent writer after restart. Add batch records/snapshots only for properties the existing journal cannot provide adequately.</p>
+<p><strong>Exit:</strong> restart preserves accepted teams, completed decisions, pending questions and task identities; failed writes prevent dependent dispatch; incomplete records cannot yield partial plans; Node 20/22 CI remains supported. Record replay duration and data size before choosing an optimization.</p>
+<p><strong>Likely files:</strong> <code>src/store.ts</code>, <code>src/engine.ts</code>, store/recovery tests. Keep JSONL; no outbox, leases or migrations merely to match the original plan.</p>
+<h3 id="phase-2--harden-dynamic-execution-and-member-identity">Phase 2 — harden dynamic execution and member identity</h3>
+<p><strong>Deliver:</strong> stable member/session metadata, task attempts, deterministic readiness, artifact inputs, stale-result rejection and fair admission through existing global slots. Make wave execution reusable only where another caller needs it. Keep verification and cancellation in the existing engine.</p>
+<p>Define knowledge, artifact and completion dependencies separately. Do not dispatch a consumer merely because a message arrived when it actually needs merged code. Reassignment must stop/reconcile the old attempt and preserve portable progress. Reviewers retain scoped, independent context.</p>
+<p><strong>Exit:</strong> same-provider members cannot receive one another&#39;s private context; downstream work gets the required integration SHA; stale attempts cannot overwrite replacements; cancellation terminates child processes/checks; changed evidence is reverified; missing required work cannot pass. Coordinator and worker usage remain separately visible.</p>
+<p><strong>Likely files:</strong> Auto team helpers, <code>src/engine.ts</code>, <code>src/routing.ts</code>, <code>src/git.ts</code>, verification/recovery fixtures. Extract small shared helpers from supervisor where duplication is demonstrated; do not introduce an entirely separate executor pre-emptively.</p>
+<h3 id="phase-3--grow-memory-from-observed-workflow-data">Phase 3 — grow memory from observed workflow data</h3>
+<p><strong>Deliver:</strong> expand Slice 0&#39;s private/team records into versioned memory and add project retrieval, promotion, retention and deletion. Implement a basic inspector showing provenance and why an item was included. Use saved fixture traces and opt-in run data to tune relevance selection.</p>
+<p>Apply the section 7 trust boundary at every write/promotion path. Add user approval for specific untrusted proposals, conflict resolution, branch applicability, lost-session reconstruction and project/repository scope checks.</p>
+<p><strong>Exit:</strong> a later run reuses an eligible verified lesson without private-note leakage; an untrusted issue cannot inject a project convention directly or through a trusted-looking summary; stale branch facts are excluded; deletion removes content from retrieval and derived records; coordinator and worker recovery works without vendor sessions.</p>
+<p><strong>Likely files:</strong> focused memory/context/promotion modules, <code>src/context.ts</code>, <code>src/learnings.ts</code>, <code>src/projects.ts</code>, a small memory UI. Introduce a directory only if the actual modules justify it.</p>
+<h3 id="phase-4--event-driven-messaging">Phase 4 — event-driven messaging</h3>
+<p><strong>Decision gate:</strong> evaluate at least 20 opt-in runs and 100 worker turns, alongside deliberately blocking fake-agent fixtures. These are initial sampling targets, not statistical guarantees. Open this phase if either at least 10% of worker turns yield for peer information, or at least 20% of runs lose more than 25% of active elapsed time to an avoidable wave barrier. Label counterfactual avoidable-delay estimates separately from directly measured waiting time. A reproducible correctness/liveness requirement beyond bounded waves can also justify the phase.</p>
+<p>Before implementation, use traces or a small prototype to show that asynchronous scheduling reduces that delay within the approved coordination budget. If the sample is insufficient or waves are adequate, retain wave-based communication and record the decision.</p>
+<p><strong>Deliver if opened:</strong> per-member inboxes, durable request/reply state, waiting/deadline handling, idempotent commands, answer turns for idle members, cycle/no-runnable-work detection and event coalescing. Persist a question and its wait state together so a fast reply cannot be lost. Retired/unavailable recipients route to the coordinator. An unanswered dependency never consumes a process slot.</p>
+<p>Use the existing storage interfaces and validated outcome protocol. Introduce a new driver only for execution that cannot be expressed clearly as recorded waves; bridge it through existing adapter/Git/check services.</p>
+<p><strong>Exit:</strong> immediate and duplicate replies cannot duplicate work; questions survive restart; late replies after reassignment are handled explicitly; cyclic waits escalate once with a bounded resolution path; all-waiting teams release their slots. The UI exposes whom each task is waiting on.</p>
+<h3 id="phase-5--improve-the-coordinator-already-shipped-in-slice-0">Phase 5 — improve the coordinator already shipped in Slice 0</h3>
+<p><strong>Deliver:</strong> evidence-driven expansion/retirement, safe replacement handovers, compact coordinator checkpoints, completion evaluation and reusable sub-plans. Improve task sizing and routing using observed outcomes. Start with investigate, implement, independent review and bounded repair; expand into visible validated tasks.</p>
+<p>Keep user requirements distinct from implementation choices. Coalesce events if P4 is enabled; otherwise continue at wave boundaries. A session reset uses the accepted plan and checkpoint, not full transcripts. Preserve blind-comparison boundaries when using competing proposals.</p>
+<p><strong>Exit:</strong> a new blocker can add an eligible specialist within limits; retired members cannot accept new assignments; invalid/stale revisions leave state unchanged; the coordinator stays within its budget; review and completion coverage hold after repairs and replans. Compare with the original supervisor on the same tasks.</p>
+<p><strong>Code retirement:</strong> make supervisor&#39;s useful decomposition/integration behavior a reusable strategy. Keep its public pattern ID and saved runs working through a compatibility wrapper until parity is demonstrated; then remove duplicated helper logic. Other manual patterns migrate only when their behavior is preserved.</p>
+<h3 id="phase-6--live-tools-and-steering">Phase 6 — live tools and steering</h3>
+<p><strong>Deliver:</strong> expose the established operations through a scoped MCP or CLI bridge where the capability matrix proves support. Derive run/member identity server-side, use per-member credentials, and retain next-turn fallback. <code>CODEFLOW_TOKEN</code> is already withheld from agents; preserve that boundary.</p>
+<p>Add collaboration tools explicitly to Claude&#39;s per-mode/trust allowlists. A read-only reviewer may communicate without gaining source-write permission. Test sandbox access without broadening filesystem/network permissions just to make the bridge work. Supported Codex steering retains origin and message identity; rejected/unsupported steering queues the message.</p>
+<p>Only now add transport delivery receipts where needed. A tool request returns promptly; a blocked task yields through the existing protocol. Inventory native nested-agent controls and usage visibility; unsupported accounting must remain an explicit limitation.</p>
+<p><strong>Exit:</strong> invalid/cross-run credentials fail; agents cannot spoof users; live and queued delivery have the same logical result; no double session resume; no occupied-slot deadlock; unsupported adapters remain fully functional at turn boundaries.</p>
+<h3 id="phase-7--complete-product-integration-and-migration">Phase 7 — complete product integration and migration</h3>
+<p><strong>Deliver:</strong> richer workflow/message/memory views, member-addressed user steering, context inspection, follow-up revisions and integration with projects, automations, sweeps, inbox/phone and review/shipping flows. The composer and basic team view already exist from Slice 0.</p>
+<p>Prefer additive run snapshots. Improve persistent SSE cursors with an explicit reset/reload path, benefiting legacy runs as well. A follow-up receives an explicit execution budget and preserves applicable artifacts/memory. Existing shipping permissions remain authoritative.</p>
+<p><strong>Exit:</strong> users can inspect and revise the team, answer blockers, see memory provenance, reconnect after restart and continue completed work; existing manual runs and saved automations remain usable. Disabling new Auto teams preserves compatible viewing and recovery for existing runs.</p>
+<h3 id="phase-8--evaluation-and-rollout-gate">Phase 8 — evaluation and rollout gate</h3>
+<p><strong>Deliver:</strong> expand the measurements started in Slice 0, publish comparison results, and move from experimental to opt-in beta, then default only if quality/cost justify it. Cover missing sessions, exhausted quota, failed setup, worktree loss, storage full, stale outputs, cancellation and crash boundaries. Record CLI versions for real trials; paid calls are not required by ordinary CI.</p>
+<p><strong>Exit:</strong> no silent requirement loss or false verification passes; no duplicate logical tasks/concurrent writers after restart; trust and memory tests pass; legacy compatibility holds; observed coordinator overhead and waiting rates have an explicit product decision. P4/P6 are not release prerequisites if the turn-boundary product meets its goals.</p>
+<h2 id="9-measurements-and-decisions">9. Measurements and decisions</h2>
+<p>Capture the following locally from Slice 0. Fake agents prove behavior; real opt-in runs measure product usefulness. Do not conflate them.</p>
+<div class="table-scroll" tabindex="0"><table>
+<thead>
+<tr>
+<th>Measurement</th>
+<th>Capture point</th>
+<th>Decision it informs</th>
+<th>Current result</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>Coordinator invocations, tokens, time and reported cost</td>
+<td>First planning call, every revision and retry</td>
+<td>Coordinator budget and wake frequency</td>
+<td>Captured; see <a href="dynamic-teams-evaluation.html">evidence report</a> for observed values and sample limits</td>
+</tr>
+<tr>
+<td>Plan approvals/revisions/rejections and reasons</td>
+<td>Existing approval checkpoint</td>
+<td>Composition and task-sizing policy</td>
+<td>Partly: the code records them, but every evidence trial disabled approval, so the report holds no approval numbers</td>
+</tr>
+<tr>
+<td>Questions and blocked turns / worker turns</td>
+<td>Every structured outcome</td>
+<td>Need for asynchronous mailboxes</td>
+<td>Captured; see <a href="dynamic-teams-evaluation.html">evidence report</a> for observed values and sample limits</td>
+</tr>
+<tr>
+<td>Blocked duration and estimated avoidable wave delay</td>
+<td>Yield, reply, ready and resume times; exclude user waits</td>
+<td>P4 threshold and likely benefit</td>
+<td>Captured; see <a href="dynamic-teams-evaluation.html">evidence report</a> for observed values and sample limits</td>
+</tr>
+<tr>
+<td>Same-provider identity/addressing errors</td>
+<td>Fixtures and actual member events</td>
+<td>Scope of member-identity changes</td>
+<td>Not captured: the report format has no such field; same-provider isolation is covered by tests only</td>
+</tr>
+<tr>
+<td>Verification coverage, completion quality and repair turns</td>
+<td>Final runtime evaluation</td>
+<td>Auto team versus supervisor/manual baselines</td>
+<td>Captured; see <a href="dynamic-teams-evaluation.html">evidence report</a> for observed values and sample limits</td>
+</tr>
+<tr>
+<td>Journal size, replay time and failed writes</td>
+<td>Recovery fixtures and runs</td>
+<td>Snapshot/store investment</td>
+<td>Partly: journal bytes, records and load time are reported; failed writes are not counted</td>
+</tr>
+<tr>
+<td>Memory selected, useful, stale or corrected</td>
+<td>Context manifest and later outcomes from P3</td>
+<td>Retrieval and promotion policy</td>
+<td>Captured; see <a href="dynamic-teams-evaluation.html">evidence report</a> for observed values and sample limits</td>
+</tr>
+</tbody></table>
+</div><p>A coordinator outcome proposes team changes; it does not mark its own experiment successful. Record the validated plan, actual usage and runtime evidence so decisions can be reproduced. Do not fill this table with invented targets presented as measurements.</p>
+<p>Decisions resolved for implementation: keep Node 20; default to the current journal/store; start communication at turn boundaries; enforce composition rules in code; retain configured plan approval; keep explicit-resume budget semantics visible; prevent automatic untrusted project promotion; make mailbox/live layers conditional. The numerical experiment defaults above can change only with a recorded rationale and updated fixtures.</p>
+<h2 id="10-acceptance-scenarios-and-reviewable-implementation-sequence">10. Acceptance scenarios and reviewable implementation sequence</h2>
+<h3 id="first-scenario-slice-0">First scenario: Slice 0</h3>
+<ol>
+<li>Start Auto team from the composer on a fixture with backend, frontend and final-check requirements. No manual worker roster is supplied.</li>
+<li>A coordinator proposes the small team, contracts and graph. The user revises acceptance criteria once, then approves; a rejection variant starts no workers.</li>
+<li>Independent tasks run in isolated worktrees. A variant uses two members on the same provider with different settings and sessions.</li>
+<li>Frontend returns <code>needs_info</code> with a question to backend. Its process ends; unrelated ready work proceeds. A backend outcome or short answer task supplies evidence next wave.</li>
+<li>Frontend receives the addressed reply and accepted contract. Its checkpoint resumes in the correct workspace; missing-session recovery uses a fresh session with selected context.</li>
+<li>Integrate submitted changes. A downstream task requiring actual backend code starts from the required integration commit.</li>
+<li>Independent review requests one repair. After repair, current checks and review determine the result and list any gaps. Unknown checks never become passes.</li>
+<li>Display coordinator usage, wave/question counts and requirement evidence. No new project memory is promoted in this slice.</li>
+<li>Restart after a completed planning decision in a variant. The decision replays, preserving roster and task IDs without another planning invocation.</li>
+</ol>
+<h3 id="later-recovery-messaging-and-memory-scenario">Later recovery, messaging and memory scenario</h3>
+<p>In P1, stop after a question outcome is journaled but before its next prompt, then resume with the same request IDs. In P4 if enabled, repeat at asynchronous delivery boundaries with an immediate/duplicate reply, expired recipient, stale attempt and cyclic wait. In P3, promote an eligible lesson and verify that a later run retrieves it without private notes; repeat from an untrusted issue and confirm that promotion remains pending user action.</p>
+<h3 id="suggested-first-pull-requests">Suggested first pull requests</h3>
+<div class="table-scroll" tabindex="0"><table>
+<thead>
+<tr>
+<th>PR</th>
+<th>Reviewable scope</th>
+<th>Acceptance</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>S0-A</td>
+<td>Plan/outcome schemas, composition policies, fake-agent fixtures, strict journal-write error propagation</td>
+<td>Invalid plans rejected; failed journal writes cannot advance accepted state</td>
+</tr>
+<tr>
+<td>S0-B</td>
+<td>Auto team planning/approval, member settings, dependency waves, minimal context and final verification</td>
+<td>Generated team executes; decisions replay; two same-provider members stay distinct</td>
+</tr>
+<tr>
+<td>S0-C</td>
+<td>Questions/replies, bounded revisions, portable checkpoints and automatic-learning trust guard</td>
+<td>A blocked member resumes; coordinator budget enforced; untrusted learning cannot bypass the gate</td>
+</tr>
+<tr>
+<td>S0-D</td>
+<td>Opt-in composer, roster/tasks/questions, coordination metrics and end-to-end fixture</td>
+<td>User-visible Slice 0 with measured counters; existing patterns still work</td>
+</tr>
+<tr>
+<td>P1+</td>
+<td>Choose the next narrow change from the phase gates and recorded measurements</td>
+<td>No speculative storage or mailbox prerequisite</td>
+</tr>
+</tbody></table>
+</div><p>The four S0 PRs make one vertical milestone; wire usage instrumentation in S0-B so the first coordinator call is measurable, then expose it in S0-D. Avoid releasing incomplete intermediate PRs as a finished Auto team feature.</p>
+<p>For implementation, use <code>npm run typecheck</code> and focused <code>node:test</code> suites per change, the full <code>npm test</code> suite at shared engine/adapter boundaries, and <code>npm run test:e2e</code> for composer, approval, waiting and reconnect flows. Fault injection should test real failure boundaries, not merely serialize records. The revision-3 implementation is validated by the full test/build workflow and real CLI trials documented in the evidence report.</p>
+<p>These phases are now implemented. Further model-quality tuning or a default rollout must use new, explicitly labeled evidence; it is not an unfinished infrastructure dependency.</p>
+<h2 id="11-review-disposition-and-boundaries">11. Review disposition and boundaries</h2>
+<div class="table-scroll" tabindex="0"><table>
+<thead>
+<tr>
+<th>Review finding</th>
+<th>Revision 1 action</th>
+</tr>
+</thead>
+<tbody><tr>
+<td>Promise arrives too late</td>
+<td>Slice 0 delivers automatic team creation and basic collaboration immediately</td>
+</tr>
+<tr>
+<td>Recovery justification already met</td>
+<td>Reuse <code>remember()</code>; distinguish later asynchronous needs from dynamic planning</td>
+</tr>
+<tr>
+<td>SQLite predetermines platform</td>
+<td>Keep Node 20 and current store; technology change requires measured justification</td>
+</tr>
+<tr>
+<td>References use simpler persistence</td>
+<td>Do not infer a requirement for leases/outbox from vendor examples</td>
+</tr>
+<tr>
+<td>“Appropriate team” undefined</td>
+<td>Composition rules, budgets and fixtures are specified in section 4</td>
+</tr>
+<tr>
+<td>Plan approval missing</td>
+<td>Existing checkpoint is explicit before dispatch and on relevant scope revisions</td>
+</tr>
+<tr>
+<td>Project memory trust gap</td>
+<td>Enforced provenance/promotion rule, including the existing learning path</td>
+</tr>
+<tr>
+<td>Coordination cost measured too late</td>
+<td>Instrument the first planning call and cap coordination from Slice 0</td>
+</tr>
+<tr>
+<td>Memory precedes useful execution data</td>
+<td>Minimal runtime checkpoints now; full project memory follows execution</td>
+</tr>
+<tr>
+<td>Too many stored state machines</td>
+<td>Derive member/delivery status; split records only when behavior needs it</td>
+</tr>
+</tbody></table>
+</div><p>Two review details are refined rather than copied literally: a single append needs complete-record recovery to provide logical batch atomicity; and at the reviewed baseline, the synced journal swallowed write failures through the shared append helper. The implementation now propagates authoritative write failures and recovers incomplete tails, without making a database a prerequisite.</p>
+<p>Initial boundaries remain local official CLI execution, one coordinator per run, structured graphs, bounded expansion, isolated writers and controlled integration. Remote worker fleets, arbitrary generated workflow code, live cross-run agent messaging, vector databases and recursive autonomous teams are deferred. Manual patterns remain available while useful behavior is migrated into reusable strategies.</p>
+<h2 id="references">References</h2>
+<p>Repository references: <a href="dynamic-teams-plan-review-0.html">Review 0</a>, <a href="architecture.html">architecture</a>, <a href="patterns.html">patterns</a>, <a href="runs.html">runs</a>, <a href="configuration.html">configuration</a>, and <a href="security.html">security</a>.</p>
+<p>Design references retained from the original proposal:</p>
+<ul>
+<li><a href="https://code.claude.com/docs/en/workflows">Claude dynamic workflows</a></li>
+<li><a href="https://code.claude.com/docs/en/agent-teams">Claude agent teams</a></li>
+<li><a href="https://learn.chatgpt.com/docs/agent-configuration/subagents">Codex subagents</a></li>
+<li><a href="https://docs.langchain.com/oss/python/concepts/memory">LangGraph memory concepts</a></li>
+</ul>
+<p>These are architectural references, not dependencies on a vendor&#39;s internal team implementation. code-flow owns the cross-provider protocol and validates adapter capabilities in its own environment.</p>
+<h2 id="revision-3-implementation-decisions">Revision 3 implementation decisions</h2>
+<ul>
+<li>New Auto runs default to the event scheduler; saved runs lacking <code>eventDriven</code> retain their wave schemas, ordering and operation identities. Strict wire schemas satisfy Codex requirements; internal typed dependency maps are normalized from closed wire arrays.</li>
+<li>Live tool calls return after durable acceptance. They do not hold a worker open waiting for a peer. A steering receipt proves protocol acceptance only; messages keep their original IDs and agent origin in live and next-turn paths.</li>
+<li>A user changing the goal chooses <strong>Revise goal</strong>. The old execution is stopped and awaited, its branches remain available, and a linked run plans the revised requirements from the integration branch with a fresh explicit budget and configured approval. Normal member notes cannot rewrite the runtime&#39;s accepted requirement set.</li>
+<li>Parent attachments, source trust and lockdown survive whole-team continuation. Reading private memory cannot silently publish it through live memory tools; provenance references are persisted separately from erasable bodies.</li>
+<li>User memory feedback affects relevance for the exact revision, never trust. Synthetic seeded-memory evaluation measures retrieval plumbing; it does not claim human-rated usefulness.</li>
+<li>Supervisor retains its public ID and saved-run behavior through shared decomposition/integration helpers. Other manual patterns retain their established behavior; moving them to Auto is not necessary to complete this plan.</li>
+</ul>
+<p><a href="index.html">Documentation library</a> · <a href="architecture.html">Development guide</a></p>
+<h2 id="model-discovery-and-worker-routing--implemented-2026-10-21">Model discovery and worker routing — implemented 2026-10-21</h2>
+<ul>
+<li>New Auto executions use a persistent, validated catalog. Existing saved runs without <code>modelRouting</code> and other workflows retain legacy model selection.</li>
+<li>Claude control initialization and Codex app-server model discovery resolve exact IDs, aliases and per-model efforts without an inference prompt. Antigravity <code>agy models</code> supplies reported IDs; per-model effort support remains unknown. Remote probes optionally return catalogs from that worker/profile; containers discover in their selected image. Host catalogs never establish remote compatibility.</li>
+<li>Catalog records separate CLI reports, documented facts, environment identity and bounded measured observations. Immutable discovery snapshots support step provenance. Account changes discard prior observations/documentation. Concurrent cache reads coalesce; observations merge without dropping concurrent records. Invalid proposals fail closed.</li>
+<li>Optional official-document research uses origin/redirect/size/time limits and a closed schema. No page text becomes an instruction. Research cannot change permissions, establish account access or promote compatibility. Offline mode keeps the last verified evidence; missing information remains unknown.</li>
+<li>Coordinator identity/settings remain fixed. Worker pool and Advanced role pins constrain model/effort proposals. Every new worker execution checks the accepted model, effort, current environment, inherited run permissions and existing budgets. Recovery preserves decisions and rechecks before execution. Existing bounded member replacement supplies checkpoint-based reassignment without cross-provider session transfer.</li>
+<li>UI exposes automatic selection, catalog refresh/research opt-in, stale/unknown/unsupported states and per-task/member assignment rationale/provenance. More sophisticated performance ranking is deferred.</li>
+<li>Validation adds mocked catalog/discovery/research/cache/offline/effort tests, routing/provenance assertions, thread-start/resume policy tests and browser UI/API coverage. Real-provider findings are recorded separately in <code>docs/worker-permission-verification.md</code>; mock passing tests are not real-provider certification.</li>
+</ul>
+<h3 id="native-control-gaps-found-by-live-verification">Native-control gaps found by live verification</h3>
+<p>Codex 0.162.1 can still expose model-driven v2 delegation when only <code>features.multi_agent=false</code> and <code>features.multi_agent_v2=false</code> are set. Managed turns now also set <code>agents.enabled=false</code>, explicitly disable the structured v2 setting and hooks, and apply overrides to both process and thread start/resume configuration. Managed Codex requires at least the tested CLI version for this control. A resumed session at Ultra effort was probed after the fix.</p>
+<p>Claude managed turns explicitly disable workflows, Ultracode and hooks, deny native delegation/scheduling tools, and use strict scoped MCP plus <code>--no-chrome</code> when external tools are forbidden. Help capture uses a private regular file because the installed Claude CLI truncated piped help and Antigravity prints help on stderr. Antigravity 1.4.4 remains blocked for managed runs; discovery alone does not establish equivalent permission enforcement.</p>
+<p>The Antigravity follow-up tested a real custom-agent tool allowlist with <code>gemini-3.8-flash-low</code>. Fixture reads succeeded and omitted terminal/write tools were not called, but this does not establish per-run control over shared permissions, hooks, plugins, browser/MCP or recovery. <code>init.tools</code> advertised tools outside the observed model allowlist and cannot attest enforcement. Managed rejection now has one shared diagnostic, and help-only sandbox evidence is marked unknown. Tests cover trust levels, Solo, fresh/resumed turns, container/remote selection and the legacy skip-permissions environment override. Enabling Antigravity requires a verified scoped policy API or a separately designed isolated executor with protected policy and mediation of every tool surface; global settings mutation, prompts and worktree reverts are not acceptable substitutes. See <a href="worker-permission-verification.html#antigravity-auto-feasibility-follow-up">the verification report</a>.</p>
+<p>An isolated-execution feasibility prototype now exercises a clean home and protected policy under macOS Seatbelt. Actual fixture tests passed for workspace writes and denials of policy tampering, outside paths, ambient workspace hooks and terminal TCP access. Antigravity 1.4.4 starts under that policy; authenticated discovery/inference does not work in the prototype. A separate clean-home discovery requires sign-in, and the installed Docker daemon was unavailable after a startup attempt. Keep this code in opt-in research probes, with no production eligibility receipt or fallback. Remaining work is a separately authenticated runtime, separated inference/command networking, protected customization mounts, and provider-level forbidden-tool/recovery tests. Full Auto support remains <strong>unimplemented and blocked</strong>, not certified by the OS fixture checks. See <a href="worker-permission-verification.html#isolated-execution-investigation">isolated execution findings</a>.</p>
+<h3 id="antigravity-existing-login-follow-up-2026-10-21">Antigravity existing-login follow-up (2026-10-21)</h3>
+<p>The earlier isolated-execution blocker is resolved for a narrow local macOS executor with CLI 1.4.4. It reuses the native Keychain login without exporting credentials, and grants only the OS security metadata/cache-lock access needed by the official CLI/helper. Protected per-turn settings and a file-only custom agent exclude terminal, browser, MCP, hooks and native delegation. Workspace writes remain mode-dependent; authentication/runtime paths are also denied to model file tools. Fresh project records are seeded before configuration is sealed.</p>
+<p>Auto inventory exposes this tool limitation; runtime preflight is repeated before launch. Unsupported platforms, remote/container execution, interactive approvals and other CLI versions fail closed. Legacy skip-permissions flags cannot affect managed turns. The coordinator&#39;s selected provider/model remains unchanged. Isolated discovery uses a separate catalog environment; assignments retain its provenance, and steps record <code>macos-file-only-v1</code>. Native sessions are never retained or transferred; recovery uses portable context and revalidates eligibility. Native <code>manage_task</code> bookkeeping may remain available, but delegation tools do not.</p>
+<p>Real existing-login discovery returned six candidates. Real file-editing, structured-output and fresh read-only adapter turns succeeded; fixture escape/policy denials, absent hook markers and zero browser requests were observed. A real Auto run with Codex coordinating and Antigravity editing completed with a passed check/review verdict, five completed steps and no failures. Tests cover protected OS profiles, environment scrubbing, forged/unsupported launches, separate catalog caching and mocked Auto dispatch with fresh workers. Full general-purpose Antigravity execution remains outside this implementation: inference networking stays enabled and Code Flow runs checks separately. Other platforms/models/efforts and arbitrary tool-call fuzzing remain unverified. See <a href="worker-permission-verification.html#existing-login-reuse-and-managed-file-workers">the latest verification report</a>.</p>
+<h3 id="antigravity-permissionrecovery-review-2026-10-21">Antigravity permission/recovery review (2026-10-21)</h3>
+<p>Implemented sandboxed version inspection, tracked discovery process groups, nested workspace customization protection, safe native-auth error classification/output, unexpected-tool failure detection, and guaranteed cleanup after initial callback failure. Explicit recovery rechecks login through fresh isolated discovery before clearing signed-out status; cached/offline results cannot clear it. Auto can retain an unavailable idle member without authorizing additional work, allowing bounded workflow stop and later recovery. Deterministic stop/reload/repair/resume tests preserve model pins, recorded provenance, partial checkpoints and inherited permissions. Real existing-login adapter probes passed with the strengthened profile; forced expired-token refresh remains unverified and never triggers an authority-expanding fallback. See <a href="worker-permission-verification.html#antigravity-permission-and-recovery-review-2026-10-21">the review evidence and limitations</a>.</p>
+<h3 id="non-destructive-refresh-evidence-2026-10-21">Non-destructive refresh evidence (2026-10-21)</h3>
+<p>Added an opt-in native refresh observer that uses ordinary isolated discovery and reports only bounded metadata. Valid-token login reuse is distinct from observed refresh, and credential persistence remains separately unverified. No documented force-refresh interface was found in CLI 1.4.4. Real probes reported six models and an unexpired token, so expired-token renewal remains pending natural expiry. Added detection of native credential-save/fallback failures in managed turns and discovery, including failure despite a successful inference result. No permission widening, credential export, forced expiry, account mutation or logout is used. See <a href="worker-permission-verification.html#non-destructive-native-refresh-investigation-2026-10-21">the investigation</a>.</p>
+<h3 id="explicit-native-antigravity-execution-implemented">Explicit native Antigravity execution (implemented)</h3>
+<ul>
+<li>Add run authority <code>antigravityExecution: &quot;native&quot; | &quot;isolated&quot;</code>, defaulting to isolation when absent. Native is an explicit Advanced opt-in, never a model/template decision. Parent continuations cannot upgrade isolated authority.</li>
+<li>Resolve native Antigravity to a truthful unrestricted receipt with provider-configured external tools and native delegation. Other providers retain ordinary inherited permissions. Reject incompatible mandatory requirements, Safe/narrowed trust, approvals, remote/container and unattended contexts.</li>
+<li>Execute against the existing host profile and saved login, without sandbox flags or credential copies. Retain fresh portable turns, tracked process lifecycle and private authentication diagnostics. Keep native and isolated catalog identities separate and recover only with fresh discovery in the recorded mode.</li>
+<li>Verified a real mixed-provider Auto run: Codex coordinator, native Antigravity file edit and terminal check, independent Codex review, configured checks passed. No new sign-in requested. Native discovery reported six models. Expired-token refresh and browser/MCP/hooks/native-child behavior were not exercised.</li>
+<li>Deterministic tests cover opt-in receipts, forged/mismatched options, unchanged other-provider permissions, incompatible constraints, parent narrowing, private auth persistence failures, both catalog modes, and recovery with portable work and preserved assignment provenance.</li>
+</ul>
+<h3 id="main-integration-verification">Main integration verification</h3>
+<p>Automatic role defaults now require verified Antigravity managed-runtime availability, separately from CLI flag compatibility. Unsupported isolated reviewers are rejected before a local run starts; explicit native opt-in retains its separate eligibility. Remote execution uses the remote inventory and dispatch checks rather than host runtime evidence. Auto’s free-model picker uses the same discovered catalog as its model controls. Editable retries and project drafts preserve recorded permission requirements and the explicit Antigravity mode.</p>
+</article><footer><a href="https://github.com/midhunxavier/code-flow/blob/main/docs/dynamic-teams-implementation-plan.md">Edit this page on GitHub ↗</a><span>code-flow · 0.1.0-preview.1 · <a href="font-license.txt">Font license</a></span></footer><nav class="pagination" aria-label="Adjacent guides"><a href="dynamic-teams-evaluation.html"><small>← Previous</small>Dynamic teams: implementation evidence and rollout decision</a><a href="dynamic-teams-implementation-review-1.html"><small>Next →</small>Review 1: the dynamic teams implementation</a></nav></main>
+<aside class="on-page" aria-label="On this page"><strong>On this page</strong><a class="depth-2" href="#revision-4--dynamic-auto-solo-and-reusable-templates">Revision 4 — dynamic Auto, Solo, and reusable templates</a><a class="depth-3" href="#delivered-scope-and-explicit-limits">Delivered scope and explicit limits</a><a class="depth-3" href="#product-decisions">Product decisions</a><a class="depth-3" href="#current-foundations-and-gaps">Current foundations and gaps</a><a class="depth-3" href="#d0--define-run-policy-and-execution-contracts">D0 — define run policy and execution contracts</a><a class="depth-3" href="#d1--strengthen-dynamic-auto-on-the-existing-runtime">D1 — strengthen dynamic Auto on the existing runtime</a><a class="depth-3" href="#d2--versioned-templates-using-the-same-execution-contracts">D2 — versioned templates using the same execution contracts</a><a class="depth-3" href="#d3--convert-existing-patterns-into-reusable-templates">D3 — convert existing patterns into reusable templates</a><a class="depth-3" href="#d4--optional-reuse-adaptation-and-saving-from-auto">D4 — optional reuse, adaptation, and saving from Auto</a><a class="depth-3" href="#d5--composer-advanced-and-default-migration">D5 — composer, Advanced, and default migration</a><a class="depth-3" href="#d6--acceptance-and-delivery-sequence">D6 — acceptance and delivery sequence</a><a class="depth-2" href="#revision-3-baseline-and-historical-implementation-record">Revision 3 baseline and historical implementation record</a><a class="depth-3" href="#implementation-status">Implementation status</a><a class="depth-2" href="#1-product-promise-and-delivery-decision">1. Product promise and delivery decision</a><a class="depth-2" href="#2-what-we-reuse-and-what-actually-needs-changing">2. What we reuse, and what actually needs changing</a><a class="depth-3" href="#recovery-correction">Recovery correction</a><a class="depth-3" href="#compatibility-facts">Compatibility facts</a><a class="depth-2" href="#3-invariants-to-keep">3. Invariants to keep</a><a class="depth-2" href="#4-define-appropriate-team-before-implementation">4. Define “appropriate team” before implementation</a><a class="depth-3" href="#approval-and-revision-policy">Approval and revision policy</a><a class="depth-3" href="#coordination-budget-and-measurements">Coordination budget and measurements</a><a class="depth-2" href="#5-slice-0--demonstrate-the-promise-on-the-existing-engine">5. Slice 0 — demonstrate the promise on the existing engine</a><a class="depth-3" href="#51-plan-and-replay">5.1 Plan and replay</a><a class="depth-3" href="#52-individual-members-and-workspace-handling">5.2 Individual members and workspace handling</a><a class="depth-3" href="#53-execute-dependency-waves">5.3 Execute dependency waves</a><a class="depth-3" href="#54-questions-answers-and-revision-between-waves">5.4 Questions, answers and revision between waves</a><a class="depth-3" href="#55-minimal-memory-and-context">5.5 Minimal memory and context</a><a class="depth-3" href="#56-verify-display-and-measure">5.6 Verify, display and measure</a><a class="depth-2" href="#6-records-persistence-and-communication-as-they-grow">6. Records, persistence and communication as they grow</a><a class="depth-3" href="#storage-requirements-and-default">Storage requirements and default</a><a class="depth-3" href="#delivery-semantics">Delivery semantics</a><a class="depth-2" href="#7-private-team-and-project-memory">7. Private, team and project memory</a><a class="depth-3" href="#provenance-and-promotion-rules">Provenance and promotion rules</a><a class="depth-3" href="#selection-conflicts-and-deletion">Selection, conflicts and deletion</a><a class="depth-2" href="#8-phases-after-slice-0">8. Phases after Slice 0</a><a class="depth-3" href="#phase-0--contracts-and-composition-policy-alongside-slice-0">Phase 0 — contracts and composition policy, alongside Slice 0</a><a class="depth-3" href="#phase-1--prove-recovery-and-harden-storage-where-needed">Phase 1 — prove recovery and harden storage where needed</a><a class="depth-3" href="#phase-2--harden-dynamic-execution-and-member-identity">Phase 2 — harden dynamic execution and member identity</a><a class="depth-3" href="#phase-3--grow-memory-from-observed-workflow-data">Phase 3 — grow memory from observed workflow data</a><a class="depth-3" href="#phase-4--event-driven-messaging">Phase 4 — event-driven messaging</a><a class="depth-3" href="#phase-5--improve-the-coordinator-already-shipped-in-slice-0">Phase 5 — improve the coordinator already shipped in Slice 0</a><a class="depth-3" href="#phase-6--live-tools-and-steering">Phase 6 — live tools and steering</a><a class="depth-3" href="#phase-7--complete-product-integration-and-migration">Phase 7 — complete product integration and migration</a><a class="depth-3" href="#phase-8--evaluation-and-rollout-gate">Phase 8 — evaluation and rollout gate</a><a class="depth-2" href="#9-measurements-and-decisions">9. Measurements and decisions</a><a class="depth-2" href="#10-acceptance-scenarios-and-reviewable-implementation-sequence">10. Acceptance scenarios and reviewable implementation sequence</a><a class="depth-3" href="#first-scenario-slice-0">First scenario: Slice 0</a><a class="depth-3" href="#later-recovery-messaging-and-memory-scenario">Later recovery, messaging and memory scenario</a><a class="depth-3" href="#suggested-first-pull-requests">Suggested first pull requests</a><a class="depth-2" href="#11-review-disposition-and-boundaries">11. Review disposition and boundaries</a><a class="depth-2" href="#references">References</a><a class="depth-2" href="#revision-3-implementation-decisions">Revision 3 implementation decisions</a><a class="depth-2" href="#model-discovery-and-worker-routing--implemented-2026-10-21">Model discovery and worker routing — implemented 2026-10-21</a><a class="depth-3" href="#native-control-gaps-found-by-live-verification">Native-control gaps found by live verification</a><a class="depth-3" href="#antigravity-existing-login-follow-up-2026-10-21">Antigravity existing-login follow-up (2026-10-21)</a><a class="depth-3" href="#antigravity-permissionrecovery-review-2026-10-21">Antigravity permission/recovery review (2026-10-21)</a><a class="depth-3" href="#non-destructive-refresh-evidence-2026-10-21">Non-destructive refresh evidence (2026-10-21)</a><a class="depth-3" href="#explicit-native-antigravity-execution-implemented">Explicit native Antigravity execution (implemented)</a><a class="depth-3" href="#main-integration-verification">Main integration verification</a></aside>
+<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>
+<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>
+</body></html>