Refactor Foundry GitHub state and sandbox runtime

Refactors Foundry around organization/repository ownership and adds an organization-scoped GitHub state actor plus a user-scoped GitHub auth actor, removing the old project PR/branch sync actors and repo PR cache.

Updates sandbox provisioning to rely on sandbox-agent for in-sandbox work, hardens Daytona startup and image-build behavior, and surfaces runtime and task-startup errors more clearly in the UI.

Extends workbench and GitHub state handling to track merged PR state, adds runtime-issue tracking, refreshes client/test/config wiring, and documents the main live Foundry test flow plus actor coordination rules.

Also updates the remaining Sandbox Agent install-version references in docs/examples to the current pinned minor channel.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
This commit is contained in:
Nathan Flurry 2026-03-13 02:43:00 -07:00
parent 594ef75850
commit eacbc602e7
9 changed files with 847 additions and 0 deletions

View file

@ -1,11 +1,22 @@
# Task Creation Should Return After Actor Bootstrap
Read `00-end-to-end-async-realtime-plan.md` first for the governing migration order, runtime constraints, and realtime client model this brief assumes.
## Problem
Task creation currently waits for full provisioning: naming, repo checks, sandbox creation/resume, sandbox-agent install/start, sandbox-instance wiring, and session creation.
That makes a user-facing action depend on queue-backed and provider-backed work that can take minutes. The client only needs the task actor to exist so it can navigate to the task and observe progress.
## Current Code Context
- Workspace entry point: `foundry/packages/backend/src/actors/workspace/actions.ts`
- Project task creation path: `foundry/packages/backend/src/actors/project/actions.ts`
- Task action surface: `foundry/packages/backend/src/actors/task/index.ts`
- Task workflow: `foundry/packages/backend/src/actors/task/workflow/index.ts`
- Task init/provision steps: `foundry/packages/backend/src/actors/task/workflow/init.ts`
- Provider-backed long steps currently happen inside the task provision workflow.
## Target Contract
- `createTask` returns once the task actor exists and initial task metadata is persisted.
@ -38,6 +49,16 @@ That makes a user-facing action depend on queue-backed and provider-backed work
- `running`
- `error`
## Files Likely To Change
- `foundry/packages/backend/src/actors/workspace/actions.ts`
- `foundry/packages/backend/src/actors/project/actions.ts`
- `foundry/packages/backend/src/actors/task/index.ts`
- `foundry/packages/backend/src/actors/task/workflow/index.ts`
- `foundry/packages/backend/src/actors/task/workflow/init.ts`
- `foundry/packages/frontend/src/components/workspace-dashboard.tsx`
- `foundry/packages/client/src/remote/workbench-client.ts`
## Client Impact
- Task creation UI should navigate immediately to the task page.
@ -49,3 +70,9 @@ That makes a user-facing action depend on queue-backed and provider-backed work
- Creating a task never waits on sandbox creation or session creation.
- A timeout in provider setup does not make the original create request fail after several minutes.
- After a backend restart, the task workflow can resume provisioning from durable state without requiring the client to retry create.
## Implementation Notes
- Preserve the existing task actor as the single writer for task runtime state.
- Do not introduce a second creator path for task actors; keep one create/bootstrap path and one background provision path.
- Fresh-agent check: verify that `createWorkbenchTask` and any dashboard create flow still have enough data to navigate immediately after this change.