root/fusion
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(FN-3421): document branch field plumbing architecture

Browse Source 
- Document how branch field data flows through task lifecycle
- Clarify architecture-level plumbing responsibilities for branch metadata
- Capture Step 4 documentation updates in docs/architecture.md

Fusion-Task-Id: FN-3421
This commit is contained in:
Fusion
2026-05-06 17:54:12 -07:00
committed by gsxdsm
parent f8fe57ea09
commit 9b56e521eb
8 changed files with 272 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/architecture.md
View File

@@ -933,6 +933,17 @@ Behavior summary:
`TaskStore.updateTask()` applies this guard before persisting `nodeId` changes.
### Task branch field plumbing (`branch` + `baseBranch`)
Task create/update now preserves both branch fields end-to-end:
- **Request validation/normalization (dashboard route layer):** `packages/dashboard/src/routes/register-task-workflow-routes.ts`
- `POST /api/tasks` accepts `branch` and `baseBranch` as string values.
- `PATCH /api/tasks/:id` accepts `branch` and `baseBranch` as `string | null` for PATCH-style updates, trims string inputs, and treats empty strings as clears (`null`).
- Route handlers reject non-string/non-null payloads with `400`.
- **Durable persistence (core store layer):** `packages/core/src/store.ts`
- `TaskStore.createTask()` persists both `branch` and `baseBranch` on task creation.
- `TaskStore.updateTask()` preserves existing PATCH semantics where explicit `null` clears either field.
- Fields round-trip through JSON and SQLite persistence via the shared task contract in `packages/core/src/types.ts`.
### Routing activity visibility