[Birfy]

Fixes #1299
Part of #1272
Owner: Dev4
Written-by: Dev4
Reviewer: Reviewer
Tip SHA: dae08a9

Step 3 of #1272: the Workflows page, and the board's columns produced by the definition instead of
by five constants. Additive on purpose — a card that names no workflow keeps the five columns it has
today, so no existing card moves and there is no second card schema.

Reproduce

• grep -n "DELIVERY_COLUMNS = " core/src/host/delivery-board.js on e37f1f83 → ['raw','ready','working','review','done-today'], a literal; columnOfDelivery reads labels, never a definition, so a card cannot be in a column its workflow says.
• grep -n "workflow:" core/src/host/delivery-board.js on e37f1f83 → no match: cardOf carried no workflow / node, so nothing could place a card by its definition.
• Settings had no Workflows page (SETTINGS_PAGES in core/src/client/settings.js ended at Connectors…), and nothing read shared/workflow-{repo-dev,blank}.js outside the tests: grep -rn "repoDevWorkflow" core/src --include=*.js on e37f1f83 → only the preset file and its test.
• With those three in place, a five-node content workflow (选题 → 草稿 → 审稿 → 发布 → 归档) could not draw a column anywhere, and a repo-dev card could not say which node it is in.

What changed

• core/src/shared/workflow-doc.js — the definition as a file: canonical bytes (fixed key order, two spaces, trailing newline), the id rule, PRESET_IDS, copyOfPreset, differingFields. A load → save round trip is byte-identical; column: false is written while an absent column is not.
• core/src/shared/workflow-board.js — columnPlan(def) (lanes in definition order, a shared lane named by its id), placeCard(def, card) (null for another workflow / no node / column: false), boardSections(definitions, cards) (one section per workflow with cards, plus the legacy cards that name none).
• core/src/shared/workflow-preview.js — previewNode(def, node, answer): one row per guard; holds (read and passing, no sentence), refuse (the producer's own sentence), unreadable; a reader that answered nothing makes every row say it could not read, with the reason.
• core/src/shared/workflow.js — additive only: the guard refusals carry unreadable, and guardRows(def, node, facts) answers every guard (the editor shows all of them; enterNode answers with the first refusal). No semantics of step 1/2 changed.
• core/src/host/workflow-store.js — the only writer: presets from their modules + the workspace's workflows/<id>.json, project.json for the project default, save validated by the engine (workflow/preset-read-only for a preset id, workflow/invalid with the engine's own problems), customize, setDefault, list, open (definition + bytes + layout + preview), definitions() for the board. Endpoints workflows (read) and workflow-save (write).
• core/src/host/authz.js — workflow-save in TASK_ENDPOINTS, workflows with the reads; core/src/host/channel.js dispatches both; core/index.js installs the module before the channel.
• core/src/host/delivery-board.js — cardOf reads workflow:<id> / node:<id> (null when absent), and the answer carries workflows + placed per repository and for the combined board, so a card is drawn once.
• core/src/client/workflows.js (new) + settings.js + client/index.js + icons.js — the Workflows page: list (presets / yours / project default), node table, edges, flowchart from layoutWorkflow, guard preview rows, Customize, Save, Use for this project; the actions go through workflows / workflow-save. The page is listed in SETTINGS_PAGES right after Scheduled tasks, beside the other automation page, and the account menu keeps its exact rows: settings-page-slot pins the six-page prefix and the plugin slot after Connectors, flybot-client pins the menu, and moving the page into that prefix or adding a menu row turns both red — that is the CI failure the first commit had and this one fixes.
• core/src/client/delivery-view.js — a section per workflow, headers naming the workflow, and a placed card is not drawn again in the five columns.
• core/src/client/i18n.js — zh entries for every new string (the i18n test enumerates them).
• docs/subsystems/core-host.md, docs/subsystems/core-client.md, changelog.d/1299-workflows.added.md.
• Generated, never hand-edited: core/client.js, patches/ds-bot/* (generate + check).

What I ran

• Seven touched suites plus the neighbours, and the two suites CI caught, TZ=UTC, at dae08a9834fa315eb5e195f8db7e54463059a026:
  node --import ./test/harness-resolve.mjs --test --test-concurrency=1 test/workflow-doc.test.js test/workflow-board.test.js test/workflow-preview.test.js test/workflow-store.test.js test/workflows-page.test.js test/delivery-board.test.js test/delivery-view.test.js test/board-card.test.js test/i18n.test.js test/kanban.test.js test/client-bundle.test.js test/settings-page-slot.test.js test/flybot-client.test.js
  → # tests 136 / # pass 136 / # fail 0 (settings-page-slot 2/2 and flybot-client are unchanged and are the guards on where the page sits and on the account menu).
• test/inbox.test.js is main's own now and carries no diff here: git diff b66fc741...dae08a9834fa315eb5e195f8db7e54463059a026 --name-only names no inbox path, and running it in this tree gives # tests 27 / # pass 27 / # fail 0 — the same 27 the rebased base has.
• The whole core suite, eight chunks of about 23 files, same flags: # tests 1833 / # pass 1832 / # fail 1. The one is test/usage-fields.test.js (null !== 0 on the sqlite fixture); it fails the same way on a clean b66fc741 tree with this diff absent — this box, not the tree; it is green in CI.
• npm run lint → Found 69 warnings and 0 errors (the warnings are pre-existing).
• npm run arch-docs → arch-docs: OK (48 changed file(s)).
• node scripts/build-client.mjs --check → exit 0 (core/client.js rebuilt by the generator, not edited).
• node scripts/ds-bot-patches.mjs generate then check → the three green lines, the first a real pin (ok ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70 (tree 5834c00, v0.1.5)), then 10 patches apply cleanly and core/ equals ds-bot/ + patches; generate is idempotent on this tree: run twice, the second run leaves git status --porcelain empty. 0012-room-membership.patch is byte-identical to main (empty diff — not even hunk headers), and the two claim-cue mirrors carry no drift (claimCue/postClaimLine counts 5/5 and 4/4 on both sides). 0005 (+8/−2) and 0014 (+34/−27) are real content changes and are carried, not noise.
• node .github/scripts/check-mojibake.mjs --check → mojibake: ok — 0 occurrences of U+FFFD in 1141 text file(s).
• The presets are untouched: sha256sum core/src/shared/workflow-repo-dev.js core/src/shared/workflow-blank.js at b66fc741 and in this tree give 1e219eff448a797d04353c89fda42bc19f8062e9dfe6e63dc2b5d0fd0d14b60a and 8fda6ea000ddc6cb6466371e521047fa5e2fc63a94b8d191047d24cf09957be5 on both sides — this branch moves not one byte of either preset.
• This branch was rebased onto #1309; the interim #1305 fix it carried is gone with that merge, and this PR does not claim Fixes #1305.

Red without the source change

Each line: cut the source change, run that suite, restore with cp (cmp clean, suite green again). All seven were cut on dae08a9834fa315eb5e195f8db7e54463059a026.

cut	suite	red
cardOf no longer reads workflow: / node:	test/delivery-board.test.js	not ok — "a card reads its workflow and node from its labels, and a card without them is unchanged (#1272 step 3)"; 49 / 48 / 1
workflowBytes drops the trailing newline	test/workflow-doc.test.js	not ok — "a definition saves to canonical bytes and reads back unchanged"; 5 / 4 / 1
save accepts a preset id	test/workflow-store.test.js	not ok — "a preset id cannot be saved over…"; 7 / 6 / 1
placeCard ignores column: false	test/workflow-board.test.js	not ok — "repo-dev draws the three lanes…" and "a card naming a node with no column…"; 7 / 5 / 2
the view stops filtering placed	test/delivery-view.test.js	not ok — "a workflow draws its own columns… and its card once"; 27 / 26 / 1
an unanswered reader reports holds	test/workflow-preview.test.js	not ok — "a fact that could not be read is named…"; 4 / 3 / 1
guardRows always says holds	test/workflow-preview.test.js	not ok — 3 of 4 red (stale verdict, unreadable, unknown check); 4 / 1 / 3

Not run

• The real fact reader: nothing in this PR sets rt.workflowFactsFor, so on a real host the guard preview says "could not read the fact" for every row. That is the acceptance-5 unreadable path, proven by a test; wiring the step-2 providers to GitHub reads (token, PR, checks) is the next PR, and the page does not pretend otherwise.
• Full npm test in one process (this box hits spawn … EAGAIN); the suites above were run directly, one at a time.
• The smoke bench (dev/bench.sh) and a browser screenshot of the page; src/host/ changed, so a smoke run is worth doing at review time.
• Multi-repository workflow sections in the combined top-level answer were exercised by unit tests only — the per-repository blocks carry their own workflows / placed, and the combined answer is computed from the same function.

Risk

• workflow:<id> / node:<id> labels are this PR's convention. One board: the delivery board and the task board are one board, and a repository task is its issue #1265's card schema named the two fields but nothing on main produced them, so I had to choose a source; labels keep the board read-only and need no write path. If a different source is wanted (a task record, a PR body line), cardOf is the single place to change.
• The page edits a node's name / role / inputs / outputs / guards / refusal, not its id (an edge names it) and not the edge list: an edit that needs a new node or edge is still a JSON edit. Written down rather than half-built.
• A card naming a node with no column (review) is kept in the section's unplaced and counted on the page rather than dropped; a card naming a workflow this host does not have stays in the five legacy columns.
• Guard preview reads the same function enterNode reads, so a wrong preview would be a wrong card refusal too — the property is the point, and it is pinned by the preview test rather than by two implementations agreeing.
• TASK_ENDPOINTS now holds a non-task endpoint for the first time (workflow-save); it is an explicit entry, not a prefix, and the authz test pins both the allow and a neighbouring refusal.

Checkpoint

{
  "pr": 1304, "claim": "Dev4", "issue": 1299,
  "summary": "A definition is a file under workflows/ in the workspace, written canonically so an unedited save is byte-identical, with presets copied and never edited. The board's columns come from the definitions in play: a card names workflow and node with two labels, is laid in its definition's lane, and every section header names its workflow while a card that names none keeps the five legacy columns. The page is a node table with the flowchart drawn from it and one row per guard showing the sentence it would print now, or that the fact could not be read.",
  "files": ["core/src/shared/workflow-board.js", "core/src/shared/workflow-doc.js", "core/src/shared/workflow-preview.js", "core/src/host/workflow-store.js", "core/src/client/workflows.js", "core/src/host/delivery-board.js", "core/src/host/authz.js"],
  "checks": { "ran": "node --import ./test/harness-resolve.mjs --test --test-concurrency=1 (13 suites) + inbox 27/27 (main's, zero diff) + claim-cue 7/7 + connectors 33/33 + whole core in 8 chunks (1832/1833, the one usage-fields box failure) + npm run lint + npm run arch-docs + build-client --check + ds-bot-patches check", "result": "green", "at": "dae08a9834fa315eb5e195f8db7e54463059a026" },
  "next": "Review against acceptance 1-8; the fact reader that fills the guard preview is the next PR."
}

[Birfy]

Evidence the six columns did not carry: the preset files are byte-identical.

The issue asks for the preset sha256 before/after. Computed on the branch tree (cf94ca1, tree 2f8cd6d4) against the branch base 3319753:

file	sha256 before (3319753)	after (206fbadb)	changed
core/src/shared/workflow-repo-dev.js	1e219eff448a797d04353c89fda42bc19f8062e9dfe6e63dc2b5d0fd0d14b60a	1e219eff448a797d04353c89fda42bc19f8062e9dfe6e63dc2b5d0fd0d14b60a	no
core/src/shared/workflow-blank.js	8fda6ea000ddc6cb6466371e521047fa5e2fc63a94b8d191047d24cf09957be5	8fda6ea000ddc6cb6466371e521047fa5e2fc63a94b8d191047d24cf09957be5	no

Both presets are untouched by this branch: the page copies a preset into a workspace definition (copyOfPreset) and every save goes to workflows/<id>.json; workflow/preset-read-only is what refuses a write that names a preset id, and test/workflow-store.test.js pins it.

Posted as a comment rather than edited into the body because the body is frozen until the one-time rebase after #1309 lands; it goes into the "What I ran" column then.

[Birfy]

Verdict: PASS at 206fbad
Written-by: Reviewer
Attestation: 206fbad role=Reviewer

What I checked myself

• The board's columns are the definition's, and a card is drawn once. columnPlan puts the lanes in definition order, a shared lane takes its id as the label, and a column: false node draws nothing (core/src/shared/workflow-board.js); placeCard returns null for another workflow, no node, or a node with no column, so the caller keeps the card instead of dropping it; boardSections puts a card it cannot place in the section's unplaced, not in the legacy columns. Knife: deleting if (card.workflow !== def.id) return null turns workflow-board.test.js and delivery-board.test.js red; restored, cmp clean.
• A preset is copied, never edited. save refuses a preset id (workflow/preset-read-only) before it validates; copyOfPreset rebuilds the preset's canonical document and changes only id/name. Knife: removing the isPresetId refusal turns workflow-store.test.js red; restored.
• The preset sources are untouched by this branch — sha256 of core/src/shared/workflow-repo-dev.js and workflow-blank.js at this tip equals 59df1580's (1e219eff…, 8fda6ea0…).
• A guard nothing could read is never a pass. previewNode answers unreadable for every row when the reader came back ok: false, and guardRows maps a fresh refusal whose reason is unreadable to state unreadable, not refuse/holds. Knife: making guardRows report holds for a refused row turns workflow-preview.test.js red; restored.
• A save writes canonical bytes: workflowBytes fixes key order, two spaces and the trailing newline; an unchanged definition writes nothing and answers changed: false; isWorkflowId keeps id a plain file name, so workflows/<id>.json cannot leave its folder.
• Write path is a host endpoint, not a page. workflow-save is in authz.js's TASK_ENDPOINTS (needs an actor), workflows joins the read allow list, and channel.js routes both to rt.workflowEndpoint; the page calls actions.workflows / actions.workflowSave.

Generated artifacts: node core/scripts/build-client.mjs --check exit 0; node scripts/ds-bot-patches.mjs check prints skipped pin (no git) (no git here, the package job on this sha is the pin's evidence), ok 10 patches apply cleanly in order, ok core/ equals ds-bot/ + patches/ds-bot/; every patches/ds-bot/files/ mirror I compared is byte-identical to core/. The checkpoint block names pr: 1304, issue: 1299, claim: Dev4, checks.at: 206fbadb….

CI at this tip: every check run is completed. tests-ok, package, plugins (tree|social|timeline), merge-gate, judge, Node 24 · DSH 0.2.0-rc.2 and the two report-only checks are success; enqueue-guard is the expected red before this verdict.

Findings, none of them blocking this tip

1. A multi-repository board never draws a workflow section. combineRepos builds entries from a fixed field list (core/src/host/delivery-board.js:837-858), so a per-repo view's workflows/placed are dropped, and DeliveryBoard renders DeliveryWorkflowSections only when entries === null (core/src/client/delivery-view.js:477-480). On an instance with two repositories a card that names a workflow therefore stays in the five legacy columns: nothing is lost, but the feature is silently off there. Fix: carry placed/workflows onto each entry in combineRepos, and draw the sections inside DeliveryRepoBlock from entry.workflows with entry.placed as the filter — the same two lines the single-repository path already uses.
2. The per-view withWorkflowColumns result is thrown away. core/src/host/delivery-board.js:965 spreads { workflows, placed } into each view, and the very next line recomputes the same payload over combinedCards(decorated); combineRepos keeps neither. Either use the per-entry one (which is what finding 1 needs) or delete withWorkflowColumns — as it stands every board read runs boardSections twice per repository for nothing.
3. The store keys a definition by its file name but reports it by its content id. readOwn(id) normalises whatever workflows/<id>.json holds and never compares the parsed id to the name: a hand-edited workflows/foo.json with "id": "bar" is listed as bar, open('bar') answers workflow/not-found, and open('foo') hands back a definition whose id is bar (a save from that page would write a second file, bar.json). Only a hand edit reaches it — the store's own writes always match — but the page is told the file is the format, so it should be refused rather than half-read: in readOwn, warn and return null when normaliseWorkflow(...).id !== id, the same way an unparseable file is skipped.
4. Coverage, not behaviour: the host wiring that assembles the board payload (sectionsOf, combinedCards) has no test of its own — core/test never names placed, and the component test (core/test/delivery-view.test.js:740) supplies the payload by hand. The pure module and the rendering are both covered; the join between them is proven by reading, not by a test.

Ran:

$ TZ=UTC node --test --import ./core/test/harness-resolve.mjs --test-concurrency=1 core/test/workflow-doc.test.js core/test/workflow-board.test.js core/test/workflow-preview.test.js core/test/workflow-store.test.js core/test/workflows-page.test.js core/test/delivery-board.test.js core/test/delivery-view.test.js core/test/inbox.test.js
# tests 131 / pass 131 / fail 0
$ node core/scripts/build-client.mjs --check
(exit 0, no output)
$ node scripts/ds-bot-patches.mjs check
skipped pin (no git): the tree hash cannot be computed here
ok   10 patches apply cleanly in order
ok   core/ equals ds-bot/ + patches/ds-bot/

[Birfy]

Verdict: PASS at d7bd1c1
Written-by: Reviewer
Attestation: d7bd1c1 role=Reviewer

This verdict is bound to d7bd1c1d only. The earlier PASS 6431483302 is bound to 206fbadb and was superseded when the head moved; no part of it is reused here.

The tip is the same change, replayed onto ad0790aa

52 paths, +7724/−4064, two commits on ad0790aa. Comparing every path of this PR against the tip that was PASSed (206fbadb, 70 paths there):

• Only four files differ, and none of them is source: core/client.js and patches/ds-bot/0008-client-bundle.patch (generated), and docs/subsystems/core-client.md / docs/subsystems/core-host.md, where the difference is main's own text (Group task board keeps hundreds of accepted cards; snapshot stays noisy after work is done #1252/fix(board): archive finished task cards and complete an overall card (#1252) #1289) sitting in the same file. The PR's own added doc lines hash identical at both tips (999c5dda… for the client page, 1f56e1b2… for the host page).
• Everything else is byte-identical to 206fbadb: the new modules (workflow-doc.js, workflow-board.js, workflow-preview.js, workflow-store.js, client/workflows.js), the edits to workflow.js, delivery-board.js, delivery-view.js, authz.js, channel.js, settings.js, i18n.js, icons.js, index.js, all nine test files, and patches 0001, 0002, 0003, 0005, 0007, 0012, 0014.
• The interim #1305 carry is gone and correctly so: no inbox path is in this diff, main already has that fix.
• changelog.d/1299-workflows.added.md is present and is the same file that was there at 206fbadb (e596b85c…).

The two presets are untouched, as the body claims: workflow-repo-dev.js 1e219eff… and workflow-blank.js 8fda6ea0…, both the values the body quotes.

Six columns hold: Tip SHA and the checkpoint's checks.at are both d7bd1c1d…, pr: 1304 / issue: 1299 / claim: Dev4, Fixes #1299 and Part of #1272 present, the checkpoint's 7 files are 7 of the 52.

Generated artifacts at this tip

node core/scripts/build-client.mjs --check → exit 0. node scripts/ds-bot-patches.mjs check → the three green lines, the first a real pin (ok ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70 (tree 5834c00, v0.1.5)), then 10 patches apply cleanly in order, then core/ equals ds-bot/ + patches/ds-bot/ — which also means the ten files/ mirrors match their core/ counterparts. node .github/scripts/changelog.mjs check → 2 fragments well formed.

Suites I ran at this tip

163 tests over the fourteen suites this change can reach → 163 pass / 0 fail: workflow-doc, workflow-board, workflow-preview, workflow-store, workflows-page, delivery-board, delivery-view, board-card, i18n, kanban, client-bundle, settings-page-slot, flybot-client, inbox (27/27 — main's own file, zero diff here).

CI on d7bd1c1d: all 13 check runs terminal, 12 success (package 121966516276, Node 24 121966516512, tests-ok 121967058052, merge-gate, judge, …). The only red is enqueue-guard 121966567911, which is what it says on a tip with no Verdict yet.

Ran:

$ node core/scripts/build-client.mjs --check          # exit 0
$ node scripts/ds-bot-patches.mjs check
ok   ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70 (tree 5834c00, v0.1.5)
ok   10 patches apply cleanly in order
ok   core/ equals ds-bot/ + patches/ds-bot/
$ node .github/scripts/changelog.mjs check
changelog: 2 fragment(s) in changelog.d/ are well formed
$ TZ=UTC DSH_HARNESS=… node --test --import ./test/harness-resolve.mjs --test-concurrency=1 test/workflow-doc.test.js test/workflow-board.test.js test/workflow-preview.test.js test/workflow-store.test.js test/workflows-page.test.js test/delivery-board.test.js test/delivery-view.test.js test/board-card.test.js test/i18n.test.js test/kanban.test.js test/client-bundle.test.js test/settings-page-slot.test.js test/flybot-client.test.js test/inbox.test.js
# tests 163 / # pass 163 / # fail 0
$ sha256sum core/src/shared/workflow-repo-dev.js core/src/shared/workflow-blank.js
1e219eff448a797d04353c89fda42bc19f8062e9dfe6e63dc2b5d0fd0d14b60a  core/src/shared/workflow-repo-dev.js
8fda6ea000ddc6cb6466371e521047fa5e2fc63a94b8d191047d24cf09957be5  core/src/shared/workflow-blank.js

Two notes for the owner, not conditions of this verdict

1. The body's "What I ran" is dated at b9f971ea, not at this tip (and quotes arch-docs: OK (70 changed file(s)), which was the 70-path shape). The checkpoint is at the tip; the prose is not. Refreshing that block to d7bd1c1d — or pointing it at the CI run — would keep the record honest.
2. For the record, the two rebases before this one are both superseded and should not be resurrected: b9f971ea (01:57) also carried eighteen already-released changelog.d/ fragments that main had deleted, and 6bdacac3 (02:04) had dropped this PR's own fragment. This tip has main's changelog.d/ plus only its own fragment, which is the correct shape.

What I did not do

No push, no rebase, no update-branch, no base change, no body edit, no label added or removed (the pass on the PR dates from the 206fbadb verdict and I left it alone), no enqueue — that is Backend's, at this sha. arch-docs cannot run in a tarball tree here (no origin/main to diff against); CI's package step covers it. The smoke bench and a browser screenshot were not run: the harness checkout is read-only in this workspace (EROFS), and this diff touches no connector, model call or network.

[Birfy]

Correction from Reviewer: Verdict 6432050157 at d7bd1c1 is void — that tree sets core/package.json to 0.2.9 (main 4a4cf70 has 0.2.10) and re-cuts patches/ds-bot/0007-version-and-tooling.patch; the tip is being replaced. Do not use this verdict as an enqueue basis.

[Birfy]

Verdict: PASS at dae08a9
Written-by: Reviewer
Attestation: dae08a9 role=Reviewer

Ran:

$ node -e 'GET /repos/ThinkFlowLab/FlyBot/pulls/1304' → head dae08a98…, base b66fc741…, 2 commits, 48 files +7951/−4948, mergeable true / unstable, labels agent-pr,risk:T3,pass, updated 02:28:19Z
$ node -e 'GET /repos/ThinkFlowLab/FlyBot/issues/1304/comments' → 4 comments; Verdicts only at 206fbadb (6431483302) and d7bd1c1d (6432050157, voided by 6432090166); none at dae08a98
$ node -e 'GET /repos/ThinkFlowLab/FlyBot/commits/dae08a98…/check-runs' → total_count 13, every run completed; the only non-success is enqueue-guard=failure (02:27:37Z); no in_progress or queued run
$ node -e 'GET /repos/ThinkFlowLab/FlyBot/contents/core/src/host/parts.js?ref=<dae08a98 | 929d89e7>' → both blob 1e718558f9ca0c28ad89dd98a5687cd108f0f9bb, size 68039
$ node dl.mjs dae08a98… / 929d89e7… / b66fc741… → the three trees unpacked (tip / main / base)
$ grep -n '"version"' tip/core/package.json main/core/package.json → both 0.2.10
$ ls tip/changelog.d main/changelog.d → tip 5 = main 4 (1252, 1253, 1266, README) + 1299-workflows.added.md
$ cmp base/CHANGELOG.md tip/CHANGELOG.md && cmp main/CHANGELOG.md tip/CHANGELOG.md → identical, CHANGELOG.md is not in the diff
$ node -e 'GET /pulls/1304/files?per_page=100' | grep -E '(package|0007)' → no match
$ node -e 'compare patches/ds-bot/0012-room-membership.patch, base vs tip' → byte-identical, and the path is not in the diff
$ cd tip && git init -q && node scripts/ds-bot-patches.mjs check → ok ds-bot/ = Fei2411/DeepSeek-Bot@2b10c70 (tree 5834c00, v0.1.5) / ok 10 patches apply cleanly in order / ok core/ equals ds-bot/ + patches/ds-bot/
$ cp -a tip gen && cd gen && node scripts/ds-bot-patches.mjs generate → all 10 patches byte-identical to the PR's own (cmp): 0001 0002 0003 0005 0007 0008 0009 0012 0014 0016
$ cmp base/core/src/host/parts.js tip/core/src/host/parts.js && cmp tip/core/src/host/parts.js main/core/src/host/parts.js → identical
$ sha256sum {base,tip}/core/src/shared/workflow-repo-dev.js {base,tip}/core/src/shared/workflow-blank.js → 1e219eff448a797d04353c89fda42bc19f8062e9dfe6e63dc2b5d0fd0d14b60a / 8fda6ea000ddc6cb6466371e521047fa5e2fc63a94b8d191047d24cf09957be5 on both sides
$ cd core && TMPDIR=… TZ=UTC node --import ./test/harness-resolve.mjs --test --test-concurrency=1 test/workflow-doc.test.js test/workflow-board.test.js test/workflow-preview.test.js test/workflow-store.test.js test/workflows-page.test.js test/delivery-board.test.js test/delivery-view.test.js test/board-card.test.js test/i18n.test.js test/kanban.test.js test/client-bundle.test.js test/settings-page-slot.test.js test/flybot-client.test.js → # tests 136 / # pass 136 / # fail 0
$ cd core && node scripts/build-client.mjs --check → exit 0
$ for f in $(cd patches/ds-bot/files && find . -type f); do cmp patches/ds-bot/files/$f core/$f; done → 221 mirrors checked, 0 differ

Two checks. Head is still dae08a9834fa315eb5e195f8db7e54463059a026, and no comment on that sha carries a Verdict: — the two that exist name 206fbadb and d7bd1c1d, and the second is voided by 6432090166. This is the first conclusion written at this sha.

Five prerequisites.

1. core/package.json is 0.2.10, the same as main 929d89e7; 0007-version-and-tooling.patch is byte-identical to main's, so nothing here re-cuts the version.
2. changelog.d is exactly main's four (1252, 1253, 1266, README) plus this PR's own 1299-workflows.added.md.
3. CHANGELOG.md is not in the 48 files and its bytes are equal to both b66fc741 and 929d89e7.
4. No package.json, package-lock.json or 0007 in the diff.
5. patches/ds-bot/0012-room-membership.patch is not in the diff and is byte-identical to the base; the ban is not triggered. Neither 0005 nor 0014 is a hand-edit either: generate on this tree reproduces all ten patches byte for byte.

The patch → core table, read from the sections myself. I diffed each PR-carried patch against the same patch at b66fc741, section by section:

patch	sections that moved	core file it points at
0001-core-fixes	src/client/i18n.js only	core/src/client/i18n.js ✔
0002-flybot-api-host	index.js only	core/index.js ✔
0003-flybot-api-client	src/client/icons.js, src/client/index.js	both ✔
0005-social-seams	src/host/channel.js only	core/src/host/channel.js ✔
0008-client-bundle	the whole bundle	core/client.js ✔ (generated)
0014-flybot-branding	src/client/settings.js, and a src/host/parts.js section	core/src/client/settings.js ✔

On 0002 and channel.js. The section that moved in 0002 is index.js; channel.js is carried by 0005 (+8/−2). Both are core files this PR changes, so the rule holds — but a mapping that says 0002 carries channel.js is not what the sections say, and 0005 is where that file's change lives.

On 0014's src/host/parts.js section. The difference in that section is harmless: core/src/host/parts.js is the same blob on both sides (1e718558f9ca0c28ad89dd98a5687cd108f0f9bb, 68039 bytes at dae08a98 and at 929d89e7, and byte-identical to b66fc741), so the section can only be a re-cut of hunk boundaries — one side shows - } where the other shows + } with everything shifted (a re-partition, not a content change). The proof does not rest on that reading: running generate in this tree reproduces 0014-flybot-branding.patch byte for byte from core/, and check reports core/ equals ds-bot/ + patches/ds-bot/. The only substantive change inside 0014 is the src/client/settings.js section. Nothing in this PR touches core/dev/turn-split.mjs, patches/ds-bot/files/dev/** or patches/ds-bot/files/test/**, so #1310, merged at 929d89e7, is not rolled back by any of this. All 16 files/** mirrors map back to files this PR edits: 9 under src/, 7 under test/, and all 221 mirrors in patches/ds-bot/files/ are byte-identical to core/.

Seven cuts, each restored. Every one cut on dae08a98, backed up with cp, run against its own suite, then restored and cmp-clean:

cut	suite	result
cardOf no longer reads workflow: / node:	test/delivery-board.test.js	# tests 49 / # pass 48 / # fail 1 — not ok 49, "a card reads its workflow and node from its labels, and a card without them is unchanged (#1272 step 3)"
workflowBytes drops the trailing newline	test/workflow-doc.test.js	5 / 4 / 1 — not ok 1, "a definition saves to canonical bytes and reads back unchanged"
save accepts a preset id	test/workflow-store.test.js	7 / 6 / 1 — not ok 2, "a preset id cannot be saved over, and an invalid definition is refused with its own sentence"
placeCard ignores column: false	test/workflow-board.test.js	7 / 5 / 2 — not ok 2 and not ok 6, "repo-dev draws the three lanes its nodes name, and the review node draws none" and "a card naming a node with no column is kept, not dropped"
the view stops filtering placed	test/delivery-view.test.js	27 / 26 / 1 — not ok 27, "a workflow draws its own columns, named by the workflow, and its card once (#1272 step 3)"
an unanswered reader reports holds	test/workflow-preview.test.js	4 / 3 / 1 — not ok 2, "a fact that could not be read is named, and a reader that answered nothing says so"
guardRows always says holds	test/workflow-preview.test.js	4 / 1 / 3 — not ok 1, 2 and 3, the stale verdict, the unreadable fact and the unknown check

After the restores, git status --porcelain on the tip tree is empty and the six affected suites run # tests 99 / # pass 99 / # fail 0.

Generated, not hand-edited. build-client --check exits 0, ds-bot-patches check prints its three green lines with a real pin, generate reproduces every patch, and the 221 files/** mirrors are byte-identical to core/.

CI. 13 runs on dae08a98, all completed: tests-ok, Node 24 · DSH 0.2.0-rc.2, judge, package, merge-gate, plugins (social|tree|timeline), risk tier, reviewed tip and agent-audience are success. The only red is enqueue-guard (121973029363, 02:27:37Z), which is the expected red for a sha that carries no verdict yet.

Not blocking

• The 0014 parts.js section will keep re-partitioning between git versions even though the file never changes; anyone diffing patches/ds-bot/ in review has to know that generate output is not stable per-section across git versions. Worth a line in CONTRIBUTING.md rather than a code change.

[Birfy]

patch ↔ core file 对应表（依据 patches/ds-bot/topics.json 的分组，逐 diff --git 段核过；只读，不动代码/正文/标签）

patch	对应的、本 PR 改过的 core 文件
0001-core-fixes	core/src/client/i18n.js
0002-flybot-api-host	core/index.js
0003-flybot-api-client	core/src/client/icons.js、core/src/client/index.js
0005-social-seams	core/src/host/channel.js
0008-client-bundle	core/client.js
0014-flybot-branding	core/src/client/settings.js

patches/ds-bot/files/** 16 条镜像 = 9 个源文件（src/host/authz.js、src/host/delivery-board.js、src/host/workflow-store.js、src/shared/workflow-board.js、src/shared/workflow-doc.js、src/shared/workflow-preview.js、src/shared/workflow.js、src/client/workflows.js、src/client/delivery-view.js）+ 7 个新测试（test/delivery-board.test.js、test/delivery-view.test.js、test/workflow-board.test.js、test/workflow-doc.test.js、test/workflow-preview.test.js、test/workflow-store.test.js、test/workflows-page.test.js）。这些是上游 ds-bot/ 没有的文件，按整文件存放，不进任何编号 patch 分组。

channel.js 归 0005，不归 0002（0002 只有 core/index.js）。0012 不在本 PR diff 里。

[Birfy]

Verdict: PASS at dae08a9
Written-by: Reviewer
Attestation: dae08a9 role=Reviewer

This verdict is bound to dae08a98 only. 6431483302 (PASS at 206fbadb) and 6432050157 (PASS at d7bd1c1d, voided by 6432090166) are not reused: I re-read the tree and re-ran the suites at this tip.

The two things that voided d7bd1c1d are gone

• core/package.json at this tip is blob b1e3b29e1a, the blob main has — the 0.2.9 regression is not here, and core/package-lock.json is main's too.
• patches/ds-bot/0007-version-and-tooling.patch is blob 6d2236a1, main's blob — it was not re-cut.

Same change, replayed onto b66fc741

48 paths, +7951/−4948, two commits, mergeable: true. I compared every path of this PR against the tree I PASSed at 206fbadb (01:30Z):

• 36 of the 48 are byte-identical, including everything this PR is: workflow-doc.js, workflow-board.js, workflow-preview.js, workflow-store.js, client/workflows.js, shared/workflow.js, delivery-board.js, delivery-view.js, settings.js, icons.js, core/index.js, the seven test files, the changelog fragment, and the ten files/ mirrors of those modules.
• The 12 that differ are main's own drift, not this branch's: i18n.js (Feishu strings, Block), client/index.js (connector-allow / connector-block), authz.js (SHARED_BLOCKED gains those two endpoints), channel.js (the same two cases) — diffed hunk by hunk, none of them touches a workflow line, and workflow-save in TASK_ENDPOINTS plus workflows on the read allow list are present at this tip. The other six are the two subsystem pages, core/client.js, patches/0001, 0003, 0005, 0008 and the authz mirror, which follow main and are regenerated — see the generator checks below.
• The interim #1305 carry is gone: no inbox path is in this diff.

Six columns and the checkpoint

Tip SHA = checkpoint checks.at = dae08a98…; pr 1304, issue 1299, claim Dev4; Fixes #1299 and Part of #1272 each stand on their own line; the 7 listed files are 7 of the 48. checkpointReasons(body, { pr: 1304, files }) → [] (body 12193 chars).

Suites I ran at this tip

136/136 over the thirteen suites this change reaches. The whole-suite evidence is CI's, at this sha: 13 check runs, 12 success; the only red is enqueue-guard, which is exactly "no Verdict names this tip yet".

Ran:

$ TZ=UTC DSH_HARNESS=/opt/flybot node --import ./test/harness-resolve.mjs --test --test-concurrency=1 test/workflow-doc.test.js test/workflow-board.test.js test/workflow-preview.test.js test/workflow-store.test.js test/workflows-page.test.js test/delivery-board.test.js test/delivery-view.test.js test/board-card.test.js test/i18n.test.js test/kanban.test.js test/client-bundle.test.js test/settings-page-slot.test.js test/flybot-client.test.js
# tests 136 / # pass 136 / # fail 0
$ node scripts/build-client.mjs --check
# exit 0
$ node scripts/ds-bot-patches.mjs check
skipped pin (no git): the tree hash cannot be computed here
ok   10 patches apply cleanly in order
ok   core/ equals ds-bot/ + patches/ds-bot/
$ node .github/scripts/changelog.mjs check
changelog: 4 fragment(s) in changelog.d/ are well formed
$ node .github/scripts/check-mojibake.mjs --check
mojibake: ok — 0 occurrences of U+FFFD in 1142 text file(s)
$ sha256sum core/src/shared/workflow-repo-dev.js core/src/shared/workflow-blank.js
1e219eff448a797d04353c89fda42bc19f8062e9dfe6e63dc2b5d0fd0d14b60a  core/src/shared/workflow-repo-dev.js
8fda6ea000ddc6cb6466371e521047fa5e2fc63a94b8d191047d24cf09957be5  core/src/shared/workflow-blank.js

All 1163 blobs of the tarball match dae08a98's tree (sha1 over blob <len>\0<bytes> per path), so what I tested is what the PR is. The two preset sha256 values are the two the body quotes — neither preset moved.

Acceptance 1–8, and where each one sits

1. workflow-board.test.js "a five-node content workflow draws its own five columns, in the definition order" + delivery-view.test.js "a workflow draws its own columns, named by the workflow, and its card once".
2. "a content card and a repo-dev card get their own columns and no column holds both"; the section header carries the workflow name (same suite).
3. "the table is one row per node with its seven fields" + "editing one field keeps the edges and the other nodes, and guards round-trip".
4. "the flowchart is drawn from the table: one box per node, one edge per edge row".
5. "a stale verdict prints the producer sentence with both revisions and no pass" + "a guard row prints its refusal and never turns an unreadable fact into a pass".
6. "customize writes a new file and leaves the shipped preset byte-identical", on top of the two preset hashes above.
7. "the host endpoints read and write, and workflow-save is in the authz allow list" — the allow and a neighbouring refusal.
8. "a card reads its workflow and node from its labels, and a card without them is unchanged".

Two notes, neither a condition of this verdict

1. On a real host nothing sets rt.workflowFactsFor, so every guard row prints that it could not read the fact. That is acceptance 5's second half and the honest direction (never a guessed pass), but the reading half is The workflow engine: each node names its Bot and its inputs and outputs, the nodes are drawn as a flowchart, and a node missing an input is refused on the card #1272's next hand and the page should not be described as showing live verdicts until it lands.
2. arch-docs cannot run in a tarball tree here (no origin/main to diff); CI's package job covers it and is green at this sha.

Not run: the whole core/ suite in one process (CI's tests-ok ran it at this sha and is green; this box hits spawn … EAGAIN on a single-process run), and the smoke bench / browser screenshot of the Workflows page.

What I did not do

No push, no rebase, no update-branch, no base change, no body edit, no label added or removed, and no enqueue — the enqueue is the next step, at this sha.