- Settings → Experimental gains a 'Workflow Graph Engine — dual-observe parity
(diagnostic)' toggle for the workflowInterpreterDualObserve flag.
- store.getWorkflowParitySummary() aggregates the workflow:parity-observed /
workflow:parity-drift run-audit events into the graduation signal: agree-rate,
per-field drift counts, and recent drift samples. Covered by
workflow-parity-summary.test.ts.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add buildWorkflowObservationFromTask (legacy authoritative side, from a task's
terminal column/status/review/mergeDetails + recorded column history) and
buildWorkflowObservation (interpreter/shadow side, from explicit parts), plus
deriveStageTransitions (maps the task-move column history to execute/review/
merge stages) and DEFAULT_WORKFLOW_INVARIANTS. These let both sides of the
dual-observe seam produce a comparable WorkflowRunObservation without
hand-rolling the shape. Covered by workflow-parity.test.ts.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This PR advanced @fusion/core's SCHEMA_VERSION 102 → 105 (migrations 103
workflows, 104 task_workflow_selection, 105 orphaned-selection cleanup) but
the "reaches current version after init/migrate" assertions across the core
test suite — and the roadmap plugin's mirror test — still hardcoded 102. The
dashboard build break was masking this: the test shards never ran until the
build was fixed, then all four failed on `expected 105 to be 102`.
Updated every getSchemaVersion()).toBe(102) current-version assertion to 105
(db, db-migrate, goals-schema, insight-store, mission-store, run-audit,
store-merge-queue, merge-request-record, task-documents) plus the roadmap
plugin. agent-log-migration already asserts against the imported SCHEMA_VERSION
constant (the robust pattern); central-db asserts its own version 13 and is
unaffected.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Resolve the two needs-human findings from PR #1363 review, plus surface the flag.
Merge seam (project-engine.ts):
- manualMergeResolvers is now a per-task LIST of waiters. Both the dashboard
"merge now" path and the interpreter merge seam call onMerge, so a single
resolver per task let the second caller overwrite (and strand) the first.
All resolve/reject/requeue/late-resolver/shutdown sites drain the whole list.
- New requestInterpreterMerge() honors auto-merge eligibility: when autoMerge
is off (or the task isn't merge-ready) it returns merged:false instead of
forcing the merge, so a graph merge node can't override an autoMerge-off
project — it parks the task in review for a human. setMergeRequester now wires
the interpreter to this gate rather than the human bypass.
Selection race (store.ts):
- selectTaskWorkflow/clearTaskWorkflowSelection now hold one withTaskLock across
their whole mutate sequence. Extracted updateTaskUnlocked() (the per-task lock
is non-reentrant, so they couldn't wrap the public updateTask without
deadlocking) and call that inside the lock.
Settings:
- Add "Workflow Graph Engine (run custom workflows)" to the Experimental
Features list so the workflowGraphExecutor flag is a labeled toggle in
Settings → Experimental, not just a raw key.
Tests: interpreter-merge-seam.test.ts (multi-waiter resolve/reject + autoMerge
eligibility gate); existing merge lifecycle/bypass/selection suites still pass.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Greptile + CodeRabbit findings across core/engine/dashboard. Stale findings
(written against earlier commits) verified and skipped; valid ones fixed.
Engine:
- await-input: do not clear pausedReason in the /input route (the node's
marker must survive unpause); the node clears it after consuming input.
Embed a colon-free epoch watermark in the marker so only post-pause steering
comments count as the reply (ISO timestamps collided with the colon
separator and the dashboard question parser).
- gate nodes without a registered runner now fail closed (throw) instead of
silently passing.
- a thrown interpreter error in maybeExecuteWorkflowGraph now falls back to the
legacy pipeline instead of stranding the task in-progress.
- approved-CLI path clears the stale awaiting-cli-approval status/marker.
Core:
- persist+cascade workflow selection: purge task_workflow_selection rows and
compiled workflow_steps on physical task deletes; migration 105 cleans
already-orphaned rows; catch-cleanup for materialized steps when the owner
write fails; WF-id allocation now in a BEGIN IMMEDIATE transaction.
- compiler validates the canonical execute->review->merge seam order (rejects
duplicate/misordered seams).
- disk-backed reopen round-trip + tightened updatedAt/list assertions.
Dashboard:
- WorkflowSelector clears stale default/options across project changes and on
fetch failure; InlineCreateCard/NewTaskModal reset the workflow on all
clear/discard paths and include it in dirty-state.
- WorkflowNodeEditor: config-key deletion now persists; removed an invalid
eslint-disable that was itself a hard lint error.
- TaskCard: single status badge for awaiting-input (no duplicate).
- WorkflowResultsTab: reset paused-action UI between pauses; surface
resume/approve failures inline.
- TaskDetailModal: treat awaiting-user-input/awaiting-cli-approval/paused as
not-in-progress for the live-log subscription.
- workflow-flow-mapping: don't write synthetic node names back into IR.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Main independently landed the same pausedReason persistence fix (column in
the task INSERT/upsert, TaskRow type, rowToTask mapping) with the column
ordered between paused and userPaused; adopt main's ordering and drop this
branch's duplicate entries so the values array stays aligned. Union the
dashboard package.json deps (main's compound-engineering plugin alongside
this branch's sorted pi-coding-agent/cli-printing-press/cursor-runtime).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Address PR #1363 review findings:
- core: pausedReason was written in-memory and read by SELECT but never
persisted by the task upsert (missing column/value) nor mapped back in
rowToTask — so it was lost on every reload. Add it to both. This is the
root cause behind the workflow CLI-approval / await-input pause cycle and
also fixes token-budget / worktrunk pause reasons silently vanishing.
- dashboard: approve-cli now derives the approved command exclusively from
the task's pausedReason; a caller-supplied body.command is ignored, closing
a trust-on-first-use bypass.
- engine: await-input nodes resume only when THIS node paused the task (its
marker on pausedReason), not on any pre-existing steering comment.
- engine: write-capable custom nodes (coding/script/CLI) are refused until a
task worktree exists, so they never mutate the shared repo root before the
execute seam.
- engine: document cliSkipApproval as an intentional workflow-author-only
escape hatch; scriptName is now const (ESLint).
- tests: pausedReason round-trip coverage in store-persistence; approve-cli
body-command-ignored + no-pending-command coverage; built-in-aware list
assertion in workflow-routes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Users can now watch everything the agent does while a CE stage works, steer
it mid-stage, and read the whole conversation as a proper chat surface.
Live output:
- New host capability: CreateInteractiveAiSessionOptions.onProgress — the
engine adapter streams thinking/text deltas + tool start/end markers from
the pi agent hooks (any plugin can use this).
- Orchestrator buffers per-session live activity (merged deltas, discrete
tool lines, capped), emits throttled progress events over SSE, and
GET /sessions/:id attaches it as liveActivity for the polling fallback.
- Routes detach turn execution: start/answer/resume return immediately
(status active) and clients converge via push/poll — the turn is watchable
instead of hidden inside a blocking POST.
- Turn timeout is now INACTIVITY-based: an actively-working long turn is
never killed; a quiet one interrupts with its working trace preserved.
- On settle the trace persists into history as a condensed record.
Steering:
- Stage protocol: responses may be a direct answer, {value, comment}
(answer + guidance), or {feedback} (guidance without answering); the
system prompt instructs agents to treat steering as first-class input.
- CeFlow: guidance textarea alongside selectable questions — attach to the
clicked answer, or "Send guidance" on its own.
Q&A UI:
- Transcript no longer hides control records: past questions/answers render
as chat bubbles (option ids → labels), steering turns marked, working
traces as collapsible "Agent work" blocks, completion marker.
- Live working pane (pulse + streaming thinking/tool lines) while a turn runs.
Tests: 130 plugin tests green (14 new: live buffer/flush ordering, inactivity
watchdog survives active work, detached convergence, steering payload shapes,
transcript rendering, live pane). Engine seam tests green; plugin/core/
engine/dashboard tsc clean. Core full suite OOMs locally (known orchestrator-
shell issue) — covered by CI shards.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Ship read-only built-in workflows surfaced in the workflow list and selectable
like any workflow: 'Coding' (the existing execute->review->merge pipeline as a
graph), 'Quick fix' (no review), 'Review-heavy' (extra security gate), and
'Compound engineering' (plan -> implement -> review -> code-review gate ->
merge -> document, invoking ce-plan/ce-code-review/ce-compound skills). Built-ins
lead the list, resolve by id for selection, and reject edit/delete.
CLI prompt nodes now accept a raw cliCommand (any command + args), not just
named scripts. A raw command must be explicitly approved by the user before it
runs: an unapproved command pauses the task (status awaiting-cli-approval) with
the command shown; the user approves via POST /tasks/:id/workflow/approve-cli,
which records the exact command string in settings.approvedWorkflowCliCommands
and resumes. Named scripts (settings.scripts) still never require approval.
Adds POST /tasks/:id/workflow/input to answer await-input nodes (records a
steering comment + resumes).
Two compounding bugs made the memory-pressure vitest auto-kill a
30-second SIGKILL sweep of anything mentioning vitest:
1. False pressure: getAvailableMemory probed os.availableMemory, which
does not exist, and silently fell back to os.freemem() — on macOS
that reads ~99% used on an idle 256GB machine, permanently above the
90% threshold. Now reads process.availableMemory() (Node 22+) and
refuses to auto-kill when only the unreliable freemem fallback is
available.
2. Overbroad targeting: pgrep -f vitest matches full command lines, so
the sweep also killed wrapper shells (zsh -c '... npx vitest run'),
monitor loops, and anything else whose argv mentions vitest —
stranding exit handlers and taking out unrelated process trees.
New shared findVitestProcessIds (@fusion/core) filters matches to
actual node executables.
Surface enumeration (all vitest-process kill/count surfaces):
- TUI memory-pressure auto-kill (controller.killVitestProcesses)
- TUI manual kill-vitest command (same method)
- dashboard POST /api/kill-vitest
- dashboard GET /api/system-stats vitestProcessCount (display)
All four now route through findVitestProcessIds.
- liveness: graph-routed tasks count as executing in getExecutingTaskIds/
isTaskActive and are skipped by recoverCompletedTask + the completed-task
resume fast-path — recovery can no longer drive a parallel lifecycle (P0)
- handleGraphFailure: sets status 'failed' (self-healing revival exemption,
prevents FN-5704-style re-run loop) and leaves paused tasks untouched
- execute seam distinguishes pause/abort from implementation failure
- merge seam: 30-minute timeout so a wedged queue cannot strand the run
- awaitAbortInFlightTaskWork: defensive interceptor/routing cleanup
- deleteWorkflowDefinition: cascades to selections, materialized steps,
affected tasks' enabledWorkflowSteps, and the project default
Expose operational log retention as a project setting in the dashboard.
- add an Operational log retention selector to the Project General settings section with supported retention options
- validate operationalLogRetentionDays in the settings API and cover accepted and rejected values in tests
- document the constrained retention values and assert project-scope/default parity for the setting
Files changed:
docs/settings-reference.md | 2 +-
packages/core/src/__tests__/settings-parity.test.ts | 7 ++++
packages/dashboard/app/components/SettingsModal.tsx | 47 ++++++++++------------
packages/dashboard/app/components/__tests__/SettingsModal.test.tsx | 8 ++++
packages/dashboard/src/__tests__/routes-settings.test.ts | 21 ++++++++++
packages/dashboard/src/routes/register-settings-memory-routes.ts | 10 +++++
6 files changed, 69 insertions(+), 26 deletions(-)
Fusion-Task-Id: FN-5939
Fusion-Task-Lineage: 2148dd88-1cef-4c6d-9696-31148fce97d3
Tasks with autoMerge explicitly enabled never auto-merged when the
project-level setting was disabled: the merge enqueue gate
(allowInReviewMergeProcessing) and all 19 in-review self-healing sweeps
checked only settings.autoMerge, and the board stall-signal hydration
passed the raw global into the diagnostic gates.
Introduce allowsAutoMergeProcessing(task, settings) in core — additive
relative to the global setting so configs with global auto-merge ON are
unchanged (explicit autoMerge:false tasks still flow to the merger's
manual-required parking) — and use it at the enqueue gate, every
self-healing sweep, and the store's stall/stalled signal contexts.
- selectTaskWorkflow: compile once, materialize the new steps and repoint the
task before deleting prior rows, so a mid-flight failure never leaves the
task referencing deleted step ids
- createTaskWithReservedId: inherit the project default workflow like
createTask (imports/reserved-id creations were skipping it)
- setDefaultWorkflowId: use null (updateSettings' delete sentinel) to clear
- parseWorkflowLayout: reject JSON arrays
- editor inspector: gate-mode default display now matches the compiler
(script/gate block by default, prompt is advisory)
Consolidate the duplicated step-materialization loop; validate by compiling
before any mutation so a non-linear graph still aborts with nothing written.
Add WorkflowSelector: a per-task picker in the task detail workflow tab that
applies a workflow (selection returns the resulting enabledWorkflowSteps so the
controlled steps list refreshes in place), and a ProjectDefaultWorkflowField in
Project General settings for the default new tasks inherit.
Selecting a workflow compiles it, materializes WorkflowStep rows (tagged and
hidden from the step manager), and writes their ids into the task's existing
enabledWorkflowSteps — the executor's read path is untouched. Re-selection
replaces prior steps with no orphans; non-linear graphs abort before any write.
New tasks inherit a project default workflow (settings.defaultWorkflowId) ahead
of legacy default-on steps. Adds task_workflow_selection table (migration 104).
No scheduler/executor/merger changes.
Add compileWorkflowToSteps + validateLinearity: walk the linear main path of a
WorkflowIr, emit prompt/script/gate user nodes as ordered WorkflowStep inputs,
skip the execute/review seams, and use the merge seam as the pre-/post-merge
boundary. Non-linear graphs (branching beyond canonical seam success/failure)
throw WorkflowCompileError so they route to the deferred interpreter instead of
mis-executing.
Add a workflows table (migration 103) storing WorkflowIr graphs plus editor
layout, with CRUD on TaskStore (create/list/get/update/delete) that validates
the IR via parseWorkflowIr on write. IDs (WF-001…) use a monotonic __meta
counter that never reuses across deletes.
branch_groups.branchName is globally UNIQUE, but ensureBranchGroupForSource
only looked up an existing group by (sourceType, sourceId). When a second
mission's shared-branch triage resolved to a base branch (e.g. "main") that
another mission already owned a group for, createBranchGroup threw
"UNIQUE constraint failed: branch_groups.branchName". That error escaped
triageFeature and was swallowed by both callers (validation-failure
auto-triage and the reconcile sweep), leaving the mission's "defined"
features — including generated fix features — permanently un-triaged.
ensureBranchGroupForSource now reuses an existing open group for the same
branch name before attempting to create one, matching the established
getBranchGroupByBranchName(...) ?? ensureBranchGroupForSource(...) idiom.
Confirmed by reproducing against a snapshot of the affected mission DB:
triageFeature threw the UNIQUE error before, succeeds after.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Replaces polling-only with a true server-push seam (any plugin benefits):
- core: createRouteContext accepts an emitEvent override (default still logs)
- dashboard: emitPluginCustomSseEvent forwards a plugin's ctx.emitEvent calls to
connected /api/events clients as a project-scoped 'plugin:custom' event; the
plugin route context's emitEvent is wired to it
- dashboard: PluginDashboardViewContext gains subscribePluginEvents so views
consume push via a host capability (no raw EventSource, no deep app import)
- CE view subscribes its session to push and refetches on each event; polling
stays as the fallback when push isn't wired or an event is missed
Also: skill-reachability test installs into a temp dir (no repo-dir writes).
Tests: dashboard sse +2 (plugin:custom relay + project scoping), plugin 99.
Closes the U2/U5 skill-discovery carry-forward so the plugin's interactive ce-*
sessions actually load the stage's bundled skill in a live agent (not just in
scripted-fake tests).
Root cause: createFnAgent built its DefaultResourceLoader without forwarding any
skill-discovery path, and the interactive seam options couldn't carry one. The
loader's skillsOverride only *filters* skills already discovered from cwd's
standard roots, so the plugin-local .fusion-ce-skills/<id>/SKILL.md was never
discoverable.
Fix (end-to-end):
- AgentOptions.additionalSkillPaths forwarded into DefaultResourceLoader
- CreateInteractiveAiSessionOptions gains requestedSkillNames + additionalSkillPaths
- the interactive engine adapter forwards them to createFnAgent (skills +
additionalSkillPaths)
- the orchestrator runs the session with cwd on the real project root and hands
it [stage.skillId] + the install root
Proven: a real DefaultResourceLoader with additionalSkillPaths discovers ce-plan
and filters out ce-work; the orchestrator passes the right id/path/cwd. Plugin 96,
engine 136, core 99 tests green.
Expose createInteractiveAiSession on route/loader PluginContext alongside the
one-shot createAiSession. The prompt->parse->retry->pause->resume loop is
reimplemented in an engine seam modeled on planning.ts (no engine await-input
primitive exists). Reuses PlanningQuestion/PlanningResponse; stays generic with
no plugin-specific concepts. Injected on route contexts only; tool/runtime
contexts omit it (parity with createAiSession).
Resolve goal tool lookups to the canonical project store from Fusion worktree directories.
- recognize both legacy .worktrees and .fusion/worktrees paths when resolving the project root for pi extensions
- add CLI coverage proving fn_goal_list and fn_goal_show return dashboard-created goals from a Fusion worktree cwd
- extend core worktree-resolution tests and keep the branch conflict recovery test worktree path isolated in tmpdir
- add a patch changeset for the published CLI fix
Files changed:
.changeset/fn-5851-goal-store-resolution.md | 5 +
packages/cli/src/__tests__/goal-store-resolution.test.ts | 104 +++++++++++++++++++++
packages/core/src/__tests__/pi-extensions.test.ts | 14 ++-
packages/core/src/pi-extensions.ts | 12 ++-
packages/engine/src/__tests__/branch-conflicts-recovery.test.ts | 2 +-
5 files changed, 130 insertions(+), 7 deletions(-)
Fusion-Task-Id: FN-5851
Fusion-Task-Lineage: ec4c8239-b953-4df7-9f72-02e17e4b0851
Whether `sqlite3 .recover` can rebuild a given byte-level corruption is
build-dependent — CI's sqlite3 returned "failed" (the safe outcome: leave
the corrupt original untouched rather than swap in an unverified rebuild)
where the local build returned "recovered". Assert the contract for whichever
branch is taken instead of hard-requiring "recovered".
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Root cause: node:sqlite SIGSEGVs inside pager_write leave the B-tree
malformed in a way that still opens but fails integrity checks; large
operational-log tables widen the write window where the crash strikes.
- backup: verify every copy with PRAGMA quick_check, quarantine corrupt
copies as *.corrupt, and never rotate out the last verified-good backup
- db: add Database.recoverIfCorrupt() startup guard (wired into
TaskStore.init, disk-backed only, opt out via FUSION_DISABLE_DB_AUTORECOVER)
that rebuilds a malformed db via sqlite3 .recover, preserving the corrupt
original; also fixes the latent `.recover main` invalid-option bug that made
recoverDatabase() always fail
- db: drop lost_and_found* scratch tables on init; add pruneOperationalLogs()
- settings: add operationalLogRetentionDays (default 30, 0 = off) and prune
activityLog/agentLogEntries/runAuditEvents/agentHeartbeats during maintenance
- dashboard: expose retention in Settings -> Backups -> Database Maintenance
Tests: backup 59/59, db 135/135 (incl. real corrupt->recover->reopen),
self-healing cleanup/corruption 10/10, settings 77/77, SettingsModal 460/460.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Tighten test fixture cleanup so temporary test directories are reliably removed.
- track created test project directories and install process exit/beforeExit backstop cleanup hooks
- make destroyTestProject resilient with async rm plus rmSync fallback and tracked-dir removal
- add regression tests for sqlite wal/shm sibling cleanup and tracked-directory drain behavior
- make db lock-child teardown remove children from tracking during iteration
Files changed:
packages/core/src/__tests__/db.test.ts | 10 +++--
packages/core/src/__tests__/test-project.test.ts | 34 ++++++++++++++-
packages/core/src/__tests__/test-project.ts | 54 +++++++++++++++++++++++-
3 files changed, 92 insertions(+), 6 deletions(-)
Fusion-Task-Id: FN-5840
Fusion-Task-Lineage: 0977be1d-8334-413d-a652-318584d7058b
