tas/Codewalkers
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'main' into cw/continuous-code-quality-conflict-1772832123778

Browse Source 
# Conflicts:
#	apps/server/drizzle/meta/0037_snapshot.json
#	apps/server/drizzle/meta/_journal.json
This commit is contained in:
Lukas May
2026-03-06 22:30:21 +01:00
parent 753b2e9fb8 dca4224d26
commit b21d32fd91
39 changed files with 5291 additions and 419 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
docs/dispatch-events.md
View File

@@ -93,6 +93,18 @@ InitiativeChangesRequestedEvent { initiativeId, phaseId, taskId }
4. **Auto-queue tasks** — When phase starts (branches confirmed), pending execution tasks are queued (planning-category tasks excluded)
5. **Events** — `phase:queued`, `phase:started`, `phase:completed`, `phase:blocked`
### Auto-Integration Phase
When `queueAllPhases` is called (i.e. the user clicks "Execute"), it auto-creates an **Integration** phase if the initiative has multiple end phases (leaf nodes with no dependents). This catches cross-phase incompatibilities before the initiative reaches review.
- **Trigger**: `queueAllPhases` in `apps/server/trpc/routers/phase-dispatch.ts`
- **Guard**: Only created when `endPhaseIds.length > 1` and no existing "Integration" phase
- **Status**: Created as `approved` (same pattern as Finalization in orchestrator.ts)
- **Dependencies**: Integration depends on all end phases — dispatched last
- **Task**: A single `verify` category task instructs the agent to build, run tests, check types, and review cross-phase imports
- **Idempotency**: Name-based check prevents duplicates on re-execution
- **Coexistence**: Independent of the Finalization phase (different purpose, different trigger)
### PhaseDispatchManager Methods
| Method | Purpose |
@@ -137,8 +149,11 @@ When an agent crashes (`agent:crashed` event), the orchestrator automatically re
On server restart, `recoverDispatchQueues()` also recovers:
- Stuck `in_progress` tasks whose agents are dead (status is not `running` or `waiting_for_input`) — reset to `pending` and re-queued
- Erroneously `blocked` tasks whose agents completed successfully (status is `idle` or `stopped`) — marked `completed` so the phase can progress. This handles the legacy case where conflict resolution incorrectly blocked already-completed tasks.
- Stale duplicate planning tasks — if a phase has both a completed and a pending task of the same planning category (e.g. two `detail` tasks from a crash-and-retry), the pending one is marked `completed` with summary "Superseded by retry"
- Fully-completed `in_progress` phases — after task recovery, if all tasks in an `in_progress` phase are completed, triggers `handlePhaseAllTasksDone` to complete/review the phase
The `detailPhase` mutation in `architect.ts` also cleans up orphaned pending/in_progress detail tasks before creating new ones, preventing duplicates at the source.
Manual retry via `retryBlockedTask()` resets `retryCount` to 0, giving the task a fresh set of automatic retries.
### Coalesced Scheduling