A workflow belongs to a Project: projectId on the definition, the run bound at assign, and Settings grouped by Project

Written-by: Chief

Owner decision 2026-10-30: the existing Project project-1fe64499 ("FlyBot 开发") is the one Project; every workflow line moves under it instead of living in a global list. Today a workflow definition has no Project at all — only a run can be bound (state.projectRuns), and nothing binds it — so "移到项目下" has no place to land.

Data model

A workflow record in workflows.json gains projectId?: string. Absent or null = unowned, and behaves exactly as today.
workflow-save accepts projectId: when it is a non-empty string it must name an existing Project (readProject), otherwise the save is refused with the reason and nothing is written. Saving with projectId: null clears it.
Authorization does not change: workflow-save stays a signed-in write. Do not add a Project-owner check in this slice.

Binding a run (this is the part with no seam today)

The plugin cannot write host state, so add one seam beside the existing task seams (fb.tasks.onWrite, fb.tasks.onProjectProvider, plugins/workflow/index.js:158-176):

fb.projects.bindRun(runId, projectId) → writes state.projectRuns[runId] = projectId, validating the Project exists, using the same setEntry(state.projectRuns, …) the project-bind endpoint uses (core/src/host/store.js:537-551).
A host without the seam must not fail a run: the plugin logs once and keeps today's behaviour (unbound run).

Then in plugins/workflow/src/service.js:

assign({ workflowId, taskId, title, brief, projectId? }) — when projectId is given it wins; otherwise the workflow's own projectId applies; a run is bound at creation, so the Project board sees it from its first step.
A refused binding (unknown Project, or no seam) does not fail the assign.

Settings UI (`plugins/workflow/client.js`)

The workflow list shows the Project name on each row (and "未归属" when it has none), with a filter that can narrow the list to one Project.
The editor gains one "Project" picker fed by the host's projects endpoint; saving writes projectId.
No new page, no new panel: this is the existing list and editor.

Tests

plugins/workflow/test/assign.test.js: an assign on a workflow with projectId binds the run to it; projectId in the assign call overrides; a workflow without one binds nothing; a binding refusal still starts the run.
plugins/workflow/test/save-graph*.test.js (or the file that covers workflow-save): an unknown projectId is refused and nothing is written; null clears it; a save without the field keeps the stored value.
core/test/: the new bindRun seam writes projectRuns and validates the Project — one case each; a host without the seam answers undefined rather than throwing.

Acceptance

npm run verify (TZ=UTC) green at the tip.
On a live host: assign a run of a workflow carrying projectId and GET project-board for that Project shows the row with runId (the board already reads projectOfMember('run', …), core/src/host/project-board.js:391-400).
A workflow with no projectId behaves exactly as today.
Fixes #<this> in the PR body, plus Owner: / Reviewer: lines and a ## Checkpoint block.

Migration (mine, after this merges)

I set projectId on the eight FlyBot lines — wf-1cdf6ec5 (issue 快线), wf-7ed167b6 (PR 快线), wf-957f985b (变脏修复), wf-4dc654c8 (Triage), wf-2fc09116 (每日发布), wf-9fddf24a / wf-62948ce1 / wf-afbd83c4 (bot-social) — and leave wf-479fa7c4 (openDigitalMate verify) unowned, because it belongs to another repository's project.

Out of scope

Listing the Project's lines on the Project board (its own slice, after this one).
Any change to how a run is dispatched, retried or stepped.

Written-by: Triage

Scope confirmed from the issue body (Owner decision 2026-10-30: project-1fe64499 "FlyBot 开发" is the one Project). No open PR references #1856, no competing open issue, no hold.

Data model + seams

core/src/host/hooks.js (the fb object, tasks: block at 1329-1351): add fb.projects with bindRun(runId, projectId) and the Project lookup workflow-save needs to validate against (read(id)/has(id), built on readProject in core/src/host/store.js); a host without the seam logs once, answers undefined, and never throws out of a run.
core/src/host/store.js 537-553 already has bindProject/setEntry(state.projectRuns, …) and requireProject: bindRun reuses that path so the two cannot disagree.
Workflow record gains projectId?: string; workflow-save path is saveGraph (plugins/workflow/src/service.js:1412) over mutate (973): non-empty must name an existing Project (refuse with the reason, write nothing), null clears, omitted keeps.
service.js assign() binds at run creation: an explicit projectId wins, else the workflow's own; a refused binding (unknown Project / no seam) still starts the run.
plugins/workflow/client.js: Project name per row ("未归属" when unowned) + a one-Project filter; the editor gets one Project picker fed by the host projects endpoint. No new page/panel.
core/ and patches/ commit together: node scripts/ds-bot-patches.mjs generate then check (hooks.js/store.js are mirrored into patches/ds-bot/files/src/host/).

Tests, red first

plugins/workflow/test/assign.test.js: workflow projectId binds the run; assign-call projectId overrides; no projectId binds nothing; a binding refusal still starts the run.
save-graph coverage (extend plugins/workflow/test/save-graph-running-node.test.js or the saveGraph test file): unknown projectId refused and nothing written; null clears; omitted keeps the stored value.
core/test/: the bindRun seam writes projectRuns and refuses an unknown Project (one case each); a host without the seam answers undefined rather than throwing.

Acceptance probes

TZ=UTC npm run verify green at the tip; node scripts/ds-bot-patches.mjs check green.
Live host: assign a run of a workflow carrying projectId, then GET project-board for that Project shows the row with runId (projectOfMember('run', …), core/src/host/project-board.js:391-400).
A workflow with no projectId behaves exactly as today.
PR body: Fixes #1856, Owner: / Reviewer: lines, ## Checkpoint block.

Tier: T2 — core/src/host/** and plugins/** (.github/agent/risk-rules.json), so a PASS at the tip plus green tests-ok.

Out of scope: listing the Project's lines on the board; any change to dispatch/retry/step; the migration of the eight existing workflow ids (Chief does that after the merge).

Written-by: Dev

Claimed for implementation — branch dev/1856-workflow-project. First step: fb.projects.bindRun in core/src/host/hooks.js over the existing bindProject path.

Apply the Project binding only after the graph validated (#1856)

Show a workflow's Project in the sidebar and in Settings (#1856)

Bind a workflow run to its Project (ThinkFlowLab#1856) (ThinkFlowLab#…

Navigation Menu

Repository navigation

A workflow belongs to a Project: projectId on the definition, the run bound at assign, and Settings grouped by Project #1856

Data model

Binding a run (this is the part with no seam today)

Settings UI (`plugins/workflow/client.js`)

Tests

Acceptance

Migration (mine, after this merges)

Out of scope

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

A workflow belongs to a Project: projectId on the definition, the run bound at assign, and Settings grouped by Project #1856

Description

Data model

Binding a run (this is the part with no seam today)

Settings UI (plugins/workflow/client.js)

Tests

Acceptance

Migration (mine, after this merges)

Out of scope

Activity

Birfy commented on Oct 30, 2026

Birfy commented on Oct 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Settings UI (`plugins/workflow/client.js`)