fe910fcce7c875c596ed56a44f8a27c7c6eba866
760 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Phil Larson
|
aedcb681b9 |
test(cli): refresh task command store fixtures (#3459)
## Summary - keep CLI task command store mocks aligned with required settings and retry-budget capabilities - preserve resolved-store identity while filling production-shaped test capabilities - update task-create assertions for synchronous post-create tracking ownership ## Test plan - `corepack pnpm --filter @runfusion/fusion exec vitest run src/commands/__tests__/task.test.ts --silent=passed-only --reporter=dot` - `corepack pnpm --filter @runfusion/fusion typecheck` - `corepack pnpm lint` ## CI note - Build, Gate, Typecheck, Desktop packaging, CodeRabbit, and Greptile pass on head `6632fd7e4`. - Lint reaches the lifecycle-column ratchet, then hits current-main mailbox census drift already fixed by green PR #3440. Co-authored-by: gsxdsm <gsxdsm@users.noreply.github.com> |
||
|
gsxdsm
|
0ec3c76faf |
fix(FN-9093): eagerly install bundled Cursor runtime plugin at host boot
The Cursor provider card's Enable action only flips useCursorCli in
settings and never registers fusion-plugin-cursor-runtime, so
getRuntimeById("cursor") missed and every cursor-cli selection hit the
runtime-routed fail-fast error even with an authenticated cursor-agent.
Mirror the FN-7761 Grok eager bootstrap in serve, dashboard, and daemon,
guarded by the same source-scan regression test.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
gsxdsm
|
c7779e44ac |
FN-9055: guard archive disposal of live workspace worktrees
Prevent archive cleanup from removing worktrees that still belong to live tasks. - Add shared archive liveness evaluation and transactional refusal guards. - Require CLI and extension archive operations to refuse live tasks unless a human uses --force. - Protect baseline archive worktree disposal and cover CLI, core, and engine paths with tests. Files changed: .changeset/fn-9055-archive-live-worktree-guard.md | 7 ++ docs/cli-reference.md | 4 +- docs/task-management.md | 4 +- .../extension-task-archive-live-guard.test.ts | 82 +++++++++++++++++++ packages/cli/src/bin.ts | 6 +- packages/cli/src/commands/__tests__/task.test.ts | 66 ++++++++++++++- packages/cli/src/commands/task.ts | 49 +++++++++--- packages/cli/src/extension.ts | 25 ++++-- .../src/__tests__/archive-live-task-guard.test.ts | 70 ++++++++++++++++ .../postgres/archive-live-task-fence.pg.test.ts | 69 ++++++++++++++++ .../src/__tests__/task-archive-liveness.test.ts | 19 +++++ packages/core/src/index.ts | 10 +++ packages/core/src/store.ts | 4 +- .../core/src/task-store/archive-lifecycle-2.ts | 27 +++++-- packages/core/src/task-store/archive-lifecycle.ts | 20 ++--- .../src/task-store/async/async-archive-lineage.ts | 17 +++- packages/core/src/tasks/task-archive-liveness.ts | 56 +++++++++++++ ...chive-baseline-disposer-live-task-guard.test.ts | 93 ++++++++++++++++++++++ .../healing/archive-worktree-disposer-install.ts | 15 +++- 19 files changed, 592 insertions(+), 51 deletions(-) Fusion-Task-Id: FN-9055 Fusion-Task-Lineage: 08644626-cc61-4854-abb9-5b415ddc9491 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
9ba6a67695 |
fix: create CLI GitHub tracking issues synchronously before process exit
The task-created hook (GitHub tracking issue creation) was deferred behind the fire-and-forget auto-title-summarize chain whenever autoSummarizeTitles is on and the task has a long description and no title — i.e. for every 'fn task create'. The short-lived CLI process closed the store and exited before the deferred chain ran, so tasks ended up with githubTracking.enabled=true but no issue (observed on FN-9045..FN-9061). fn task create now suppresses the deferred hook and calls createTrackingIssueForTask directly after create, printing the linked issue; exports that helper from @fusion/dashboard. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
gsxdsm
|
41d415fe70 |
FN-9051: report blocked workspace finalization
Prevent workspace merge entry points from treating an unfinalized task as a successful merge. - Add a typed blocked-finalization result and engine handling that avoids retries, failure parking, and branch promotion. - Return blocked outcomes through dashboard and CLI merge surfaces. - Cover blocked finalization behavior and publish a patch changeset. Files changed: .changeset/fn-9051-workspace-blocked-finalize.md | 7 ++ packages/cli/src/commands/__tests__/task.test.ts | 38 ++++++++ packages/cli/src/commands/dashboard.ts | 22 +++-- packages/cli/src/commands/task.ts | 19 ++-- .../engine/src/__tests__/project-engine.test.ts | 105 ++++++++++++++++++++- .../engine/src/__tests__/workspace-merger.test.ts | 1 + packages/engine/src/index.ts | 1 + packages/engine/src/merge/merger-ai.ts | 28 +++++- packages/engine/src/project-engine.ts | 42 ++++++++- 9 files changed, 240 insertions(+), 23 deletions(-) Fusion-Task-Id: FN-9051 Fusion-Task-Lineage: 89d5fcbb-1a00-4429-87ea-fc3e34db2706 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
52a28d39ff |
feat: add per-task GitHub tracking overrides to task create (fn_task_create + CLI)
fn_task_create gains github_tracking/github_repo params and fn task create gains --github/--no-github/--github-repo flags, resolved through resolveTaskGithubTracking (task > project > global). CLI create now also honors the project/global tracking-enabled default it previously ignored; explicit disables persist enabled:false so later default flips cannot re-enable a task. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
gsxdsm
|
9d31396f7a |
FN-9031: strengthen computer snapshot action fencing
Serialize computer snapshots and actions through a durable app-scoped fence. - Hold the fence from snapshot acquisition or element resolution through OS action consumption. - Report snapshot consumption only when the expected latest pointer was invalidated. - Heartbeat and token-check directory locks for safe crash recovery and add command-fence coverage. Files changed: .../commands/__tests__/computer-commands.test.ts | 26 +++++++++- .../__tests__/computer-snapshot-index.test.ts | 2 +- packages/cli/src/commands/computer.ts | 37 ++++++++----- .../cli/src/commands/computer/snapshot-store.ts | 60 ++++++++++++++++------ 4 files changed, 93 insertions(+), 32 deletions(-) Fusion-Task-Id: FN-9031 Fusion-Task-Lineage: f196b7ca-ce3f-4a50-98d2-d6ac8bf184ac Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
2dcead4c8f |
FN-9035: prevent static computer commands in shipped skills
Keep bundled computer-use guidance limited to runtime discovery so command syntax cannot drift. - Scan all shipped skill markdown files, including plugin skills - Reject static `fn computer` commands outside the computer-use discovery stub - Assert the discovery stub exposes only its supported JSON probes Files changed: packages/cli/src/commands/__tests__/computer-use-skill.test.ts | 50 ++++++++++++++++++++-- 1 file changed, 47 insertions(+), 3 deletions(-) Fusion-Task-Id: FN-9035 Fusion-Task-Lineage: 5049fd29-1b3b-4968-b09e-1bb7be9d52ff Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
1788dc0506 |
FN-9033: harden macOS computer-use permission handling
Treat missing osascript as an explicit automation denial while preserving replay failures. - Track missing osascript separately from indeterminate permission probes. - Block all macOS automation paths before execution when osascript is unavailable. - Preserve replay permission and timeout errors, mapping only stale locators to element errors. - Add coverage for replay failures and missing-binary enforcement. Files changed: .../__tests__/computer-adapter-registry.test.ts | 87 +++++++++++++++++++++- .../commands/__tests__/computer-commands.test.ts | 29 +++++++- .../cli/src/commands/computer/adapter-macos.ts | 52 +++++++------ 3 files changed, 142 insertions(+), 26 deletions(-) Fusion-Task-Id: FN-9033 Fusion-Task-Lineage: 48e77cc5-cd71-49f1-a163-13d68a81d1d4 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
7673f2e839 |
FN-9031: enforce snapshot consumption after computer actions
Computer-use actions now consume the captured app snapshot and require a fresh state capture before another element-targeted action. - Add app-scoped, serialized snapshot-pointer consumption with stale-state diagnostics. - Mark successful action results as consuming their snapshot and cover action/replay behavior. - Document the enforced snapshot → act → snapshot loop and add a CLI changeset. Files changed: .../fn-9031-computer-use-snapshot-consumption.md | 7 ++ docs/cli-reference.md | 2 +- docs/computer-use.md | 11 +-- .../commands/__tests__/computer-commands.test.ts | 88 ++++++++++++++++++++-- .../commands/__tests__/computer-contract.test.ts | 7 +- .../__tests__/computer-snapshot-index.test.ts | 52 ++++++++++++- .../commands/__tests__/computer-use-guide.test.ts | 4 + packages/cli/src/commands/computer.ts | 37 ++++++--- .../cli/src/commands/computer/adapter-macos.ts | 4 +- packages/cli/src/commands/computer/contract.ts | 17 ++++- packages/cli/src/commands/computer/guide.ts | 4 +- .../cli/src/commands/computer/snapshot-store.ts | 79 +++++++++++++++++-- 12 files changed, 272 insertions(+), 40 deletions(-) Fusion-Task-Id: FN-9031 Fusion-Task-Lineage: f196b7ca-ce3f-4a50-98d2-d6ac8bf184ac Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
d3e51f566e |
FN-9030: resolve computer state at project root
Resolve computer-use state once per invocation at the containing Fusion project root. - Add a state-root resolver shared by computer command adapters and snapshot storage. - Preserve capture and replay snapshots across working directories while isolating projects. - Cover root resolution and cross-directory state behavior, and document the storage contract. - Add a patch changeset for the CLI fix. Files changed: .../fn-9030-computer-use-project-local-state.md | 7 ++ docs/computer-use.md | 2 +- .../commands/__tests__/computer-commands.test.ts | 76 ++++++++++++++++++++++ .../__tests__/computer-snapshot-index.test.ts | 14 ++++ .../commands/__tests__/computer-state-root.test.ts | 49 ++++++++++++++ packages/cli/src/commands/computer.ts | 9 ++- packages/cli/src/commands/computer/state-root.ts | 18 +++++ 7 files changed, 171 insertions(+), 4 deletions(-) Fusion-Task-Id: FN-9030 Fusion-Task-Lineage: a0cb48ee-fd7f-4966-9930-cde273027eca Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
62979d8796 |
FN-8985: centralize CLI version resolution
Centralize CLI self-version discovery without widening the early boot import graph. - Reuse one bounded manifest resolver for the CLI binary, updater, and plugin scaffold. - Add regression coverage for manifest lookup bounds, malformed manifests, and scaffold version fallback. - Preserve update command test isolation after the core i18n module relocation. Files changed: packages/cli/src/__tests__/cli-version.test.ts | 136 +++++++++++++++++++++ .../plugin-scaffold-caret-fallback.test.ts | 91 ++++++++++++++ packages/cli/src/bin.ts | 45 +------ packages/cli/src/cli-version.ts | 51 ++++++++ packages/cli/src/commands/__tests__/update.test.ts | 2 +- packages/cli/src/commands/plugin-scaffold.ts | 40 +----- packages/cli/src/commands/update.ts | 37 +----- 7 files changed, 292 insertions(+), 110 deletions(-) Fusion-Task-Id: FN-8985 Fusion-Task-Lineage: dd95b651-3578-4c5f-957a-5af7b85129d7 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
eacd6687bc |
FN-8961: add computer-use skill and version-matched guide
Ship the computer-use skill across bundled clients and surface its matching guide through the CLI. - add the computer-use skill, computer command descriptor, and `fn skills get computer-use` guide - reconcile all shipped Claude skills at project and startup entry points - cover both skills' reconciliation outcomes and every required call site Files changed: .changeset/fn-8961-computer-use-skill.md | 7 + docs/cli-reference.md | 6 +- docs/computer-use.md | 8 + packages/cli/skill/computer-use/SKILL.md | 31 +++ packages/cli/src/__tests__/package-config.test.ts | 20 ++ packages/cli/src/bin.ts | 14 +- .../__tests__/claude-skills-callsites.test.ts | 64 ++++++ .../src/commands/__tests__/claude-skills.test.ts | 221 ++++++++------------- .../__tests__/computer-surface-descriptor.test.ts | 108 ++++++++++ .../commands/__tests__/computer-use-guide.test.ts | 36 ++++ .../commands/__tests__/computer-use-skill.test.ts | 20 ++ packages/cli/src/commands/__tests__/daemon.test.ts | 36 +++- .../__tests__/dashboard-claude-skills.test.ts | 19 ++ packages/cli/src/commands/__tests__/init.test.ts | 48 ++++- .../cli/src/commands/__tests__/project.test.ts | 38 ++++ packages/cli/src/commands/__tests__/serve.test.ts | 36 +++- .../commands/__tests__/skill-installation.test.ts | 12 ++ .../cli/src/commands/__tests__/skills-get.test.ts | 67 ++++++ packages/cli/src/commands/claude-skills-runner.ts | 55 ++--- packages/cli/src/commands/claude-skills.ts | 47 +++-- packages/cli/src/commands/computer.ts | 6 +- packages/cli/src/commands/computer/contract.ts | 52 +++++ packages/cli/src/commands/computer/guide.ts | 62 ++++++ packages/cli/src/commands/init.ts | 4 +- packages/cli/src/commands/skill-installation.ts | 45 +++-- packages/cli/src/commands/skills.ts | 24 +++ 26 files changed, 853 insertions(+), 233 deletions(-) Fusion-Task-Id: FN-8961 Fusion-Task-Lineage: b6baaebb-bf72-4991-8239-eb9bcf9cbcf1 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
1da61f35f7 |
FN-8960: add macOS computer automation CLI
Add a snapshot-backed macOS computer-use surface to the Fusion CLI. - Register fn computer commands for app state, permission, capability, and UI actions. - Implement macOS JXA automation with locator replay and persisted snapshot safety checks. - Document the CLI surface, add contract coverage, and include a release changeset. Files changed: .changeset/fn-8960-computer-use-cli.md | 7 + docs/README.md | 1 + docs/cli-reference.md | 21 ++ docs/computer-use.md | 156 +++++++++++++ packages/cli/src/bin.ts | 11 + .../__tests__/computer-adapter-registry.test.ts | 154 ++++++++++++ .../commands/__tests__/computer-commands.test.ts | 71 ++++++ .../commands/__tests__/computer-contract.test.ts | 34 +++ .../__tests__/computer-snapshot-index.test.ts | 87 +++++++ packages/cli/src/commands/computer.ts | 182 +++++++++++++++ .../cli/src/commands/computer/adapter-macos.ts | 211 +++++++++++++++++ .../cli/src/commands/computer/adapter-registry.ts | 42 ++++ .../src/commands/computer/adapter-unsupported.ts | 44 ++++ packages/cli/src/commands/computer/adapter.ts | 97 ++++++++ packages/cli/src/commands/computer/contract.ts | 83 +++++++ packages/cli/src/commands/computer/exec-seam.ts | 61 +++++ .../cli/src/commands/computer/scripts/macos-jxa.ts | 37 +++ .../cli/src/commands/computer/snapshot-store.ts | 257 +++++++++++++++++++++ 18 files changed, 1556 insertions(+) Fusion-Task-Id: FN-8960 Fusion-Task-Lineage: 5870bf69-b751-4879-bf9d-5f5396cc0f55 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
a839c61929 |
FN-8926: expose graph and recall through MCP
Expose Fusion knowledge graph and durable recall through a built-in MCP transport. - Add the reserved fusion-memory server with graph and recall MCP tools. - Resolve built-in availability and enable/disable tombstones across configuration and UI. - Add CLI transport, documentation, release metadata, and lane coverage tests. Files changed: .changeset/fn-8926-memory-mcp-server.md | 7 + docs/cli-reference.md | 4 + docs/mcp.md | 10 ++ packages/cli/src/bin.ts | 6 + .../__tests__/mcp-memory-server-spawn.test.ts | 79 ++++++++++ .../commands/__tests__/mcp-memory-server.test.ts | 83 +++++++++++ packages/cli/src/commands/__tests__/mcp.test.ts | 27 +++- packages/cli/src/commands/mcp-memory-server.ts | 104 +++++++++++++ packages/cli/src/commands/mcp.ts | 64 ++++++-- packages/core/package.json | 10 ++ .../core/src/__tests__/mcp-builtin-servers.test.ts | 17 +++ packages/core/src/__tests__/mcp-config.test.ts | 12 ++ packages/core/src/config/mcp-builtin-descriptor.ts | 16 ++ packages/core/src/config/mcp-builtin-servers.ts | 18 +++ packages/core/src/config/mcp-config.ts | 40 +++-- packages/core/src/config/mcp-discovery.ts | 3 +- packages/core/src/index.ts | 6 + packages/core/src/memory/index.ts | 1 + .../mcp/__tests__/memory-mcp-handler.test.ts | 36 +++++ .../mcp/__tests__/memory-mcp-serialization.test.ts | 23 +++ packages/core/src/memory/mcp/index.ts | 4 + .../core/src/memory/mcp/memory-mcp-backends.ts | 39 +++++ packages/core/src/memory/mcp/memory-mcp-handler.ts | 54 +++++++ .../src/memory/mcp/memory-mcp-serialization.ts | 48 ++++++ packages/core/src/memory/mcp/memory-mcp-tools.ts | 64 ++++++++ packages/core/src/types.ts | 10 ++ .../settings/sections/GlobalMcpSection.tsx | 14 +- .../settings/sections/McpServersCard.tsx | 67 +++++++-- .../settings/sections/ProjectMcpSection.tsx | 15 +- .../__tests__/McpServersCard.builtin.test.tsx | 45 ++++++ .../dashboard/src/__tests__/chat-manager.test.ts | 24 +++ .../register-config-mcp-pi-settings-routes.ts | 20 ++- packages/dashboard/vitest.config.ts | 2 + .../__tests__/mcp-builtin-lane-coverage.test.ts | 163 +++++++++++++++++++++ packages/engine/src/mcp/mcp-resolution.ts | 10 +- packages/engine/vitest.config.ts | 2 + 36 files changed, 1097 insertions(+), 50 deletions(-) Fusion-Task-Id: FN-8926 Fusion-Task-Lineage: b2861491-33da-4b05-b9f8-a7c1448c1c8c Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
3143f9536f |
FN-8908: auto-recover terminal task failures
Recover generic terminal task failures through a bounded, durable retry budget before escalating them to operators. - add fenced task-store recovery claims, retries, budget resets, and audit events - defer terminal-failure notifications until recovery is exhausted while preserving a single escalation - expose operator retry budget reset and cover recovery lifecycle behavior Files changed: .../fn-8908-terminal-failure-auto-recovery.md | 7 + AGENTS.md | 1 + docs/agents.md | 2 + docs/architecture.md | 2 + packages/cli/src/commands/task.ts | 2 + packages/cli/src/extension.ts | 2 + ...terminal-failure-auto-recovery-store.pg.test.ts | 108 +++++++++ .../terminal-failure-auto-recovery.test.ts | 60 +++++ packages/core/src/index.gate.ts | 1 + packages/core/src/index.ts | 1 + packages/core/src/store.ts | 179 ++++++++++++++- .../core/src/task-store/archive-lifecycle-2.ts | 15 ++ packages/core/src/task-store/moves.ts | 48 +++- packages/core/src/task-store/persistence.ts | 18 +- packages/core/src/task-store/project-store-ops.ts | 4 +- .../src/task-store/workflow-task-create-ops.ts | 4 +- packages/core/src/tasks/index.ts | 1 + .../src/tasks/terminal-failure-auto-recovery.ts | 114 ++++++++++ packages/core/src/types/task/task-core.ts | 24 ++ .../src/routes/register-task-workflow-routes.ts | 2 + ...-healing-terminal-failure-auto-recovery.test.ts | 199 ++++++++++++++++ .../__tests__/notification-service.test.ts | 86 ++++++- .../__tests__/task-wedge-notification.test.ts | 2 +- .../src/notification/notification-service.ts | 103 +++++++-- .../src/notification/task-wedge-notification.ts | 30 ++- packages/engine/src/self-healing.ts | 251 ++++++++++++++++++++- packages/engine/src/util/run-audit.ts | 7 + 27 files changed, 1240 insertions(+), 33 deletions(-) Fusion-Task-Id: FN-8908 Fusion-Task-Lineage: 99e96b16-0306-41f1-87da-8623d69735f7 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
27cb2d2621 |
FN-8921: add deterministic knowledge graph tooling
Add a committable, provenance-tagged knowledge graph layer with CLI generation and query support. - Extract TypeScript, Markdown, and FNXC knowledge into deterministic graph nodes and edges. - Persist recoverable graph artifacts outside ignored Fusion state and expose build/query CLI commands. - Document configuration and add core and CLI coverage for graph structure, serialization, and recovery. Files changed: .changeset/fn-8921-knowledge-graph.md | 7 + .gitattributes | 3 + AGENTS.md | 1 + docs/README.md | 2 + docs/cli-reference.md | 4 + docs/knowledge-graph.md | 37 +++++ docs/settings-reference.md | 4 + docs/storage.md | 2 + packages/cli/package.json | 3 +- .../__tests__/knowledge-graph-bundle-shape.test.ts | 4 + .../src/__tests__/knowledge-graph-command.test.ts | 115 ++++++++++++++ packages/cli/src/bin.ts | 19 +++ packages/cli/src/commands/knowledge-graph.ts | 79 ++++++++++ packages/cli/tsup.config.ts | 2 + packages/core/package.json | 4 +- packages/core/src/config/settings-schema.ts | 2 + packages/core/src/index.ts | 1 + .../__tests__/derive-modules.test.ts | 11 ++ .../__tests__/extract-file-composition.test.ts | 20 +++ .../knowledge-graph/__tests__/extract-fnxc.test.ts | 33 ++++ .../__tests__/extract-markdown.test.ts | 21 +++ .../__tests__/extract-typescript.test.ts | 30 ++++ .../__tests__/file-discovery.test.ts | 26 ++++ .../graph-artifact-not-gitignored.test.ts | 15 ++ .../__tests__/graph-builder-equivalence.test.ts | 76 ++++++++++ .../__tests__/graph-builder-incremental.test.ts | 52 +++++++ .../__tests__/graph-identity.test.ts | 11 ++ .../knowledge-graph/__tests__/graph-query.test.ts | 13 ++ .../__tests__/graph-serialization.test.ts | 29 ++++ .../__tests__/graph-store-recovery.test.ts | 106 +++++++++++++ .../__tests__/resolve-imports.test.ts | 10 ++ .../core/src/knowledge-graph/derive-modules.ts | 4 + packages/core/src/knowledge-graph/extract-file.ts | 6 + packages/core/src/knowledge-graph/extract-fnxc.ts | 168 +++++++++++++++++++++ .../core/src/knowledge-graph/extract-markdown.ts | 9 ++ .../core/src/knowledge-graph/extract-typescript.ts | 107 +++++++++++++ .../core/src/knowledge-graph/file-discovery.ts | 85 +++++++++++ packages/core/src/knowledge-graph/graph-builder.ts | 141 +++++++++++++++++ .../core/src/knowledge-graph/graph-manifest.ts | 4 + packages/core/src/knowledge-graph/graph-query.ts | 126 ++++++++++++++++ .../src/knowledge-graph/graph-serialization.ts | 134 ++++++++++++++++ packages/core/src/knowledge-graph/graph-store.ts | 97 ++++++++++++ packages/core/src/knowledge-graph/graph-types.ts | 54 +++++++ packages/core/src/knowledge-graph/index.ts | 14 ++ .../core/src/knowledge-graph/resolve-imports.ts | 4 + packages/core/src/types/settings/settings-scope.ts | 2 + pnpm-lock.yaml | 12 +- 47 files changed, 1700 insertions(+), 9 deletions(-) Fusion-Task-Id: FN-8921 Fusion-Task-Lineage: 7014d0f1-fc47-454b-afe5-5f0d9b229f33 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
Victor Canô
|
a09e0cb87f |
feat(i18n): add Português (Brasil) (pt-BR) locale (#3347)
## Summary Adds **Português (Brasil)** (`pt-BR`) as a supported locale: - Selectable as **Translation target language** (project settings) and as the dashboard / terminal UI language. - Full machine-drafted catalogs (`app`, `cli`, `common`), disclosed in `packages/i18n/locales/TRANSLATION_STATUS.md` following the pattern #1352 established — reviewed for glossary/register consistency (0.18% untranslated, matching only keys that are empty in `en`), but native-speaker corrections are welcome. - Brazilian Portuguese content-language detection (accent-stripped stopword list — the scorer strips diacritics before matching, so accented entries never match; `com`/`mais` deliberately omitted to avoid bare-domain `.com` and French collisions, with regression tests for both directions). - `pt`/`pt-PT` browser and environment locales resolve to `pt-BR` on all three detection paths (`FALLBACK_LNG` routing plus a `pt` branch in `normalizeToSupportedLocale`, mirroring the existing `zh` handling). - `README.pt-BR.md` + switcher links in all READMEs, docs updates (`settings-reference`, `cli-reference`, `i18n-contributing`, `--lang` help text), changeset (`minor`). Drive-by fixes bundled: `TRANSLATION_STATUS.md` was missing the `ko` row; the LanguageSelector endonym test was missing `한국어`; `docs/i18n-contributing.md` now names the two compile-enforced display maps (`LOCALE_LABELS`, `localeDisplayName`) a new locale must update; the `--lang` CLI help text no longer drifts from its validator. ## Test plan - `pnpm i18n:status` (key parity gate) green; catalogs are `i18n:sync`-idempotent. - Updated/extended suites: core `locale-settings`, i18n `config`/`parity`/`db-banner-catalog`/`i18n-gate-coverage`, dashboard `useLanguage`/`LanguageSelector`/`GeneralSection.importTranslate`/`detectContentLanguage` (incl. new pt-BR detection + bare-domain regression tests), CLI `settings`. - `pnpm verify:fast` (typecheck, build, boot smoke), `pnpm lint`, `pnpm check:changesets`, and the bounded `pnpm test` lane all green locally (the three `test:pg-gate` files fail locally only for lack of a Postgres instance; they fail identically on clean `main`). <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added Brazilian Portuguese (Português (Brasil)) across the dashboard, terminal interface, settings, and translation tools. * Added Portuguese translations for common interface and CLI content. * Added automatic Portuguese language detection, locale normalization, and fallback support. * Added a Portuguese (Brazil) README with product, setup, and usage documentation. * **Documentation** * Updated language selectors, CLI references, settings documentation, and translation guidance. * Added Portuguese README links to translated documentation. * Added French to the documented dashboard language options. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: gsxdsm <gsxdsm@users.noreply.github.com> |
||
|
gsxdsm
|
c7c879905b |
FN-8903: add event-driven GitHub CI merge checks
Persist ingested GitHub CI signals and use them to assess merge readiness. - Store project-scoped GitHub check states with retention maintenance. - Resolve configured required checks from ingested signals during PR merge decisions. - Add delivery, lifecycle, persistence, and retention coverage with operator documentation. Files changed: .changeset/fn-8903-event-driven-checks.md | 7 ++ docs/architecture.md | 1 + docs/settings-reference.md | 2 +- docs/signals-connectors.md | 2 +- .../src/commands/__tests__/task-lifecycle.test.ts | 50 ++++++++- packages/cli/src/commands/task-lifecycle.ts | 7 +- .../core/src/__tests__/ingested-checks.test.ts | 66 +++++++++++ .../postgres/github-check-states.pg.test.ts | 71 ++++++++++++ packages/core/src/config/index.ts | 1 + packages/core/src/config/ingested-checks.ts | 32 ++++++ packages/core/src/index.ts | 10 ++ .../0048_fn_8903_github_check_states.sql | 32 ++++++ packages/core/src/postgres/schema-applier.ts | 15 ++- packages/core/src/postgres/schema/project.ts | 29 ++++- .../core/src/task-store/async/async-ci-checks.ts | 104 ++++++++++++++++++ packages/core/src/task-store/async/index.ts | 1 + packages/core/src/types.ts | 2 + packages/dashboard/src/__tests__/github.test.ts | 121 ++++++++++++++++++++- .../src/__tests__/register-signal-routes.test.ts | 81 +++++++++++++- packages/dashboard/src/github.ts | 74 +++++++++---- .../dashboard/src/routes/register-git-github.ts | 29 +++-- .../dashboard/src/routes/register-signal-routes.ts | 10 +- .../src/routes/register-task-workflow-routes.ts | 14 ++- packages/dashboard/src/signal-source.ts | 23 ++++ packages/dashboard/src/signal-sources/github.ts | 2 + .../self-healing-github-check-retention.test.ts | 121 +++++++++++++++++++++ packages/engine/src/self-healing.ts | 23 ++++ 27 files changed, 878 insertions(+), 52 deletions(-) Fusion-Task-Id: FN-8903 Fusion-Task-Lineage: b2643587-c568-4b6c-8b3a-d50a6165963d Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
2643f4e567 |
FN-8884: enable GitHub-native PR auto-merge
Enable opt-in GitHub-managed auto-merge for pull requests. - Add a project setting and dashboard control for GitHub native auto-merge. - Arm individual, group, dashboard, and workflow PRs with `gh pr merge --auto` or GraphQL, including while checks are pending. - Preserve deferred PR reconciliation, unavailable-feature errors, project-scoped runtime configuration, tests, documentation, and a release changeset. Files changed: .changeset/fn-8884-github-native-auto-merge.md | 7 + docs/settings-reference.md | 5 + packages/cli/src/commands/__tests__/daemon.test.ts | 16 +++ packages/cli/src/commands/__tests__/serve.test.ts | 14 ++ .../src/commands/__tests__/task-lifecycle.test.ts | 158 +++++++++++++++++++++ packages/cli/src/commands/daemon.ts | 11 +- packages/cli/src/commands/dashboard.ts | 11 +- packages/cli/src/commands/serve.ts | 11 +- packages/cli/src/commands/task-lifecycle.ts | 45 ++++-- .../core/src/__tests__/settings-defaults.test.ts | 4 + packages/core/src/config/settings-schema.ts | 1 + packages/core/src/types/settings/settings-scope.ts | 8 ++ .../settings/__tests__/section-keys.test.ts | 1 + .../app/components/settings/section-keys.ts | 1 + .../components/settings/sections/MergeSection.tsx | 14 +- .../settings-default-descriptions.test.tsx | 1 + .../src/__tests__/github-native-auto-merge.test.ts | 114 +++++++++++++++ .../src/__tests__/routes-pr-merge.test.ts | 84 +++++++++++ packages/dashboard/src/github.ts | 88 +++++++++++-- packages/dashboard/src/index.ts | 2 +- .../dashboard/src/routes/register-git-github.ts | 33 +++-- .../project-engine-deferred-startup.test.ts | 21 +++ packages/engine/src/project-engine-manager.ts | 2 + packages/engine/src/project-engine.ts | 6 + packages/engine/src/project/project-runtime.ts | 6 + packages/engine/src/runtimes/in-process-runtime.ts | 9 +- packages/i18n/locales/en/app.json | 4 +- 27 files changed, 634 insertions(+), 43 deletions(-) Fusion-Task-Id: FN-8884 Fusion-Task-Lineage: cf1b1ea4-7ef7-4050-bd87-25933456a5b6 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
d59c1b162f |
FN-8855: enforce configured PR checks before merging
Add configurable Fusion-side PR check gating across merge surfaces. - Add project required-check settings, validation, UI controls, CLI support, and operator documentation. - Evaluate configured checks before dashboard and CLI PR merges, accepting successful, skipped, and neutral checks. - Bind merges to the evaluated PR head SHA to prevent push-and-merge races. - Cover required-check policy and head-SHA merge behavior with tests. Files changed: .changeset/fn-8855-required-checks.md | 7 + docs/dashboard-guide.md | 5 + docs/settings-reference.md | 1 + .../src/commands/__tests__/task-lifecycle.test.ts | 30 ++++- packages/cli/src/commands/task-lifecycle.ts | 17 ++- .../core/src/__tests__/required-checks.test.ts | 16 +++ packages/core/src/config/index.ts | 1 + packages/core/src/config/required-checks.ts | 16 +++ packages/core/src/config/settings-schema.ts | 1 + packages/core/src/index.ts | 1 + packages/core/src/types.ts | 6 + packages/core/src/types/settings/settings-scope.ts | 6 + packages/core/src/types/task/task-tracking.ts | 5 + .../settings/__tests__/section-keys.test.ts | 1 + .../app/components/settings/section-keys.ts | 1 + .../settings/sections/MergeSection.search.ts | 3 + .../components/settings/sections/MergeSection.tsx | 30 ++++- .../__tests__/MergeSection.requiredChecks.test.tsx | 50 +++++++ .../settings-default-descriptions.test.tsx | 1 + packages/dashboard/src/__tests__/github.test.ts | 123 +++++++++++++++++ packages/dashboard/src/github.ts | 149 +++++++++++++-------- .../dashboard/src/routes/register-git-github.ts | 38 ++++-- .../src/routes/register-task-workflow-routes.ts | 8 +- packages/i18n/locales/en/app.json | 4 +- 24 files changed, 441 insertions(+), 79 deletions(-) Fusion-Task-Id: FN-8855 Fusion-Task-Lineage: 708e9c27-72be-4925-bf09-5db421bcaa67 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
b3504f01a4 |
FN-8838: refresh automated PR heads before GitHub mutations
Refresh isolated automated PR heads against their target immediately before PR creation or merge. - Rebase and lease-publish task and group heads at every automated GitHub boundary. - Fail closed on concurrent head updates and reconcile retained refresh worktrees. - Add lifecycle coverage and document the configurable integration remote. Files changed: .changeset/fn-8838-refresh-pr-heads.md | 7 + docs/settings-reference.md | 6 + .../task-lifecycle-refresh.integration.test.ts | 438 ++++++++++++++++ .../src/commands/__tests__/task-lifecycle.test.ts | 309 ++++++++++- packages/cli/src/commands/daemon.ts | 4 +- packages/cli/src/commands/dashboard.ts | 4 +- packages/cli/src/commands/serve.ts | 4 +- packages/cli/src/commands/task-lifecycle.ts | 581 +++++++++++++++++++-- .../src/__tests__/group-merge-coordinator.test.ts | 43 ++ .../engine/src/merge/group-merge-coordinator.ts | 34 +- packages/engine/src/merge/pr-nodes.ts | 35 +- packages/engine/src/project-engine.ts | 16 +- 12 files changed, 1425 insertions(+), 56 deletions(-) Fusion-Task-Id: FN-8838 Fusion-Task-Lineage: a9b9e800-7d73-441f-bc1b-2488d244e0b1 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
c0e2ba2ade |
FN-8836: classify GitHub branch policy merge blocks
Classify ambiguous GitHub merge failures using refreshed pull request state. - Distinguish branch-protection blocks from true merge conflicts. - Surface review and required-check blockers in CLI and dashboard merge flows. - Add regression coverage and a patch changeset. Files changed: .changeset/fn-8836-gh-merge-policy-errors.md | 7 ++ .../src/commands/__tests__/task-lifecycle.test.ts | 55 +++++++++ packages/cli/src/commands/task-lifecycle.ts | 14 ++- packages/core/src/__tests__/gh-cli.test.ts | 39 +++++- packages/core/src/cli/gh-cli.ts | 60 +++++++++- packages/core/src/index.gate.ts | 1 + packages/core/src/index.ts | 1 + .../dashboard/src/__tests__/routes-github.test.ts | 131 +++++++++++++++++++++ .../dashboard/src/routes/register-git-github.ts | 58 +++++++-- 9 files changed, 351 insertions(+), 15 deletions(-) Fusion-Task-Id: FN-8836 Fusion-Task-Lineage: 7102f5ba-aca9-48cd-a27b-76deb952c4a5 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
54d1ccb8d5 |
FN-8835: block unmergeable pull requests
Fail closed before auto-merging pull requests that GitHub reports as unmergeable. - Require normalized clean mergeability in PR readiness checks. - Cover protected, behind, conflicting, and unknown PR states across CLI and dashboard tests. - Add a patch changeset for the corrected auto-merge behavior. Files changed: .changeset/fn-8835-pr-merge-readiness.md | 7 +++ .../src/commands/__tests__/task-lifecycle.test.ts | 21 ++++--- packages/dashboard/src/__tests__/github.test.ts | 64 ++++++++++++++++++---- packages/dashboard/src/github.ts | 11 ++++ 4 files changed, 84 insertions(+), 19 deletions(-) Fusion-Task-Id: FN-8835 Fusion-Task-Lineage: 698dacf9-5f24-42b7-b927-ae5b5579ee3f Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
0fda8b203b |
test: bind a project partition in the PG harness for built-in agent provisioning
FN-8764 made AgentStore.init() unconditionally provision the four durable built-in workflow-owner agents, and that provisioning needs a bound asyncLayer.projectId — backendProjectId rejects the empty/unbound partition so a shared cluster cannot mix ownership. Every AgentStore-backed PG test therefore threw in init(); without this change all 10 cases in agent-instructions.pg.test fail at agent-store.ts:526. createTaskStoreForTest / createSharedPgTaskStoreTestHarness gain an OPT-IN projectId. Undefined keeps the historical project-agnostic harness (RLS bypass, empty-string partition) that the rest of the core suite relies on. When set, the connection GUC `fusion.project_id`, the AsyncDataLayer, and the seeded config row all share one partition — so agents (explicit project_id) and their config revisions (GUC-default project_id) land together and the (project_id, agent_id) FK on agent_config_revisions holds. Also folds in two already-merged consequences: serve.test expects the consumerId: "engine" that serve.ts:326 already passes (FN-8685), and the auto-generated Fusion skill docs pick up fn_workflow_step_resume, the roles / max_workflow_sessions agent fields, and the deprecated singular role. Uncommitted in the working tree; reviewed, verified against the real database, and committed as-is. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
ischindl
|
4739f8aa67 |
fix: eagerly warm extension host stores from engine TaskStores (#3340)
## Summary Warm the extension-host task stores **up front** at dashboard startup instead of letting the first `fn_task_*` call lazily boot a second PostgreSQL pool per project. ## What changed `packages/cli/src/commands/dashboard.ts`: - After the dashboard boots, iterate every registered project (from `centralCoreForEngine.listProjects()`) and call `setHostTaskStore(p.path, engine.getTaskStore())` for each non-cwd project that already has a running `ProjectEngine`. - Reuses each engine's **existing** `TaskStore` directly — no new backend connection, no schema advisory-lock contention, no extra connection-pool exhaustion. - `cwd` is skipped because its store is already injected at startup. - Per-project failures are non-fatal (warn) and a failed project listing logs a single warn — dashboard startup never blocks on this. - `.changeset/extension-host-store-warmup.md` (patch, fix). ## Why Left on its own, the first extension tool call (`fn_task_update`, `fn_task_archive`, `fn_agent_show`, …) for a non-cwd project falls through to `createTaskStoreForBackend`, which boots a **second** PostgreSQL connection pool on demand. On busy hosts that lazy boot can time out, or the call stalls behind pool/startup contention — the classic "first `fn_task_*` call is slow or errors" experience. Pre-populating from the already-running engines removes that lazy worst-case path entirely. ## Verification - `pnpm verify:fast` — PASS (13 steps, 115s): CLI `tsup` build green, scoped typecheck/build green, boot smoke green (`fn --help` + real `serve` with `GET /api/health` 200). - Cherry-picked cleanly onto current `origin/main` (`5532019fd`); branch is up-to-date with `origin/main` at PR time. ## Files - `packages/cli/src/commands/dashboard.ts` (+30) - `.changeset/extension-host-store-warmup.md` (new) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved dashboard startup reliability by reusing existing project task connections. * Prevented extension task tools from creating duplicate connection pools. * Added non-blocking warnings when individual project initialization or discovery fails. * Dashboard startup now reports how many project task stores were successfully prepared. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: gsxdsm <gsxdsm@users.noreply.github.com> |
||
|
gsxdsm
|
2a0827835d |
FN-8810: wire secrets stores into runtime worktrees
Wire project secrets stores into runtime and dashboard heartbeat worktree acquisition. - Inject the project secrets store into executor and heartbeat monitors. - Cover in-process, UI-only dashboard, and secrets-env worktree materialization paths. - Add a patch changeset for restored secrets-env files. Files changed: .changeset/fn-8810-secrets-env-runtime-wiring.md | 7 ++ .../commands/__tests__/dashboard-supervise.test.ts | 28 ++++- packages/cli/src/commands/dashboard.ts | 38 ++++++- .../src/__tests__/in-process-runtime.pg.test.ts | 121 ++++++++++++++++++++- .../src/__tests__/secrets-env-writer.test.ts | 35 ++++++ .../worktree-acquisition-secrets-env.test.ts | 4 +- packages/engine/src/runtimes/in-process-runtime.ts | 9 ++ 7 files changed, 233 insertions(+), 9 deletions(-) Fusion-Task-Id: FN-8810 Fusion-Task-Lineage: a67c3fbe-7744-4898-8a56-8739caa04479 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
9e4a0817db |
feat: restart the development engine on source changes (#3329)
## Summary Add an opt-in source-development loop that restarts the dashboard and engine when runtime TypeScript or JSON changes. Use `pnpm dev:watch`; `pnpm dev:hmr` now combines Vite UI HMR with the same supervised API/engine restart path. The watcher filters tests, fixtures, generated declarations, build output, and task state. It coalesces bursts with a two-second maximum wait, waits for the child to acknowledge its IPC listener, and rebuilds runtime dist artifacts before a source-triggered respawn. ## Safety model - Close scheduler, triage, heartbeat, mission, routine, self-healing, and merge admission before checking for active work. - Let already-running agents reach a safe boundary; do not mutate durable pause settings. - Enter the existing graceful exit-code-86 shutdown and supervised respawn path. - Retry failed liveness reads and declined restart requests instead of dropping the pending change. - Keep ordinary `pnpm dev` behavior unchanged; inherited watch state does not break nested non-dashboard development commands. A development restart intentionally replaces the dashboard process, so transient dashboard connections and project dev-server children reconnect or restart with it. Agent work is the protected boundary. ## Validation - `pnpm lint` - `pnpm test:gate` (753 tests passed across engine, core, PostgreSQL gate, and CI-shape suites) - Focused CLI watcher/restart/supervision suites: 40 tests passed - Focused engine drain/manager suites: 52 tests passed - `pnpm --filter @runfusion/fusion typecheck` - `pnpm --filter @fusion/engine typecheck` - `pnpm verify:fast` (13 steps passed, including CLI build and real health boot smoke) - Manual unsupported-command probe confirms explicit `--watch` fails clearly outside the dashboard command ## Post-Deploy Monitoring & Validation - Watch for `[fusion:dev] source changed`, `source restart deferred`, `active work drained`, and `restart requested` logs during the first watched development session. - Healthy behavior is one exit-86 respawn per edit batch, no interrupted active agents, refreshed dist artifacts, and a healthy dashboard after respawn. - Investigate repeated restart loops, watcher attachment warnings, declined restart retries, or liveness-read failures. - Immediate mitigation is to use ordinary `pnpm dev` without `--watch`; no production runtime behavior or durable setting needs rollback. - Validation owner: Fusion maintainers during the first source edit after merge. --- [](https://github.com/EveryInc/compound-engineering-plugin) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added `pnpm dev:watch` to automatically restart development runtime processes when source files change. * Development restarts now wait for active work to finish, preventing new work from starting during the transition. * Enhanced `pnpm dev:hmr` with graceful runtime source restarts while keeping the dashboard available. * Rapid source changes are grouped to avoid unnecessary restarts. * **Documentation** * Updated development setup and contribution guides with the new watch workflow. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
gsxdsm
|
006cc40454 |
FN-8685: add durable cross-process task deletion consumers
Deliver durable, replay-safe cross-process task deletion observation. - Add PostgreSQL lifecycle consumer cursors, leases, acknowledgements, retention, and recovery. - Start named consumers in dashboard, serve, and engine runtime paths. - Preserve delete integration metadata while suppressing replayed GitHub and GitLab side effects. - Cover outbox identity, observed delivery, fencing, and reconciliation behavior. Files changed: ...fn-8685-cross-process-task-deleted-observers.md | 7 + .../fn-8685-task-deleted-outbox-consumers.md | 7 + docs/architecture.md | 8 +- ...tgres-cross-process-task-deleted-observation.md | 8 +- docs/storage.md | 10 +- packages/cli/src/commands/dashboard.ts | 9 +- packages/cli/src/commands/serve.ts | 9 +- packages/cli/src/project-context.ts | 9 +- .../task-deleted-outbox-consumer.pg.test.ts | 157 ++++++++ ...-deleted-observed-dispatch-side-effects.test.ts | 36 ++ .../task-lifecycle-consumer-identity.test.ts | 22 ++ packages/core/src/index.ts | 11 + .../0041_fn_8685_task_lifecycle_consumers.sql | 88 +++++ packages/core/src/postgres/schema-applier.ts | 16 +- packages/core/src/postgres/schema/project.ts | 45 +++ packages/core/src/postgres/startup-factory.ts | 4 + packages/core/src/store.ts | 54 ++- .../__tests__/lifecycle-outbox-writer.test.ts | 4 +- .../core/src/task-store/archive-lifecycle-2.ts | 1 + packages/core/src/task-store/lifecycle-ops.ts | 13 +- packages/core/src/task-store/lifecycle-outbox.ts | 2 + packages/core/src/task-store/project-store-ops.ts | 4 +- .../src/task-store/task-deleted-outbox-consumer.ts | 333 +++++++++++++++++ .../task-store/task-lifecycle-consumer-identity.ts | 32 ++ .../task-store/task-lifecycle-consumer-registry.ts | 396 +++++++++++++++++++++ .../task-store/task-lifecycle-event-retention.ts | 104 ++++++ packages/core/src/task-store/task-mutation-ops.ts | 1 + packages/dashboard/src/github-tracking-state.ts | 12 +- packages/dashboard/src/gitlab-delete-close.ts | 3 + packages/dashboard/src/gitlab-split-close.ts | 7 +- packages/dashboard/src/project-store-resolver.ts | 9 +- packages/engine/src/project-manager.ts | 4 +- packages/engine/src/project-runtime.ts | 2 +- packages/engine/src/runtimes/in-process-runtime.ts | 17 +- packages/engine/src/self-healing.ts | 27 ++ 35 files changed, 1439 insertions(+), 32 deletions(-) Fusion-Task-Id: FN-8685 Fusion-Task-Lineage: 63eca9ac-d2af-44b0-ba79-388a950148d3 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai> |
||
|
gsxdsm
|
56e16d9dea |
test(cli): pin the board glyph's terminal-lane resolve (extract seam + pin) (#3238)
## What Pins the CLI board glyph's terminal-lane resolve — **the last flagged site in the repo-wide resolver audit.** Two commits: a behaviour-preserving extraction, then the test. ## I was wrong to flag this as unpinnable In #3236 I recorded this site as not pinnable, reasoning that *"extracting a pure helper and testing it would look like coverage and would not be."* That is true of a helper that **receives** the lane set — such a test passes with the resolve blinded, which is exactly the `reads.ts` trap the audit note records. It is **not** true of one that **resolves** it. Building `resolveReliabilityLanes` in #3237 made the distinction obvious: the seam has to contain the resolve, and then blinding fails a test of it. So the flag was too broad, and correcting it closes the site rather than leaving a permanent excuse. That is the same failure mode I corrected in someone else's note earlier today — a caution that hardens into a reason not to look. ## Measured ``` converted: Tests 5 passed (5) blinded: Tests 2 failed | 3 passed (5) ``` The two failures are the **renamed complete** and **renamed archive** lanes. The three survivors are the default-vocabulary control, the active-lane negative, and the degrade path — all of which should survive. ``` task-list-board-columns + bin: 82 passed typecheck clean; lint clean; fnxc-future-dates: none added ``` ## Why the sibling file did not cover it `task-list-board-columns.test.ts` pins `boardColumnsForDisplay`, which decides **which** lanes print. That function takes no lane set, so it cannot fail when this resolve is blinded — and its own header says so honestly. Two tests about the same command, one of which cannot see the other's bug. ## What breaks without the conversion On a board whose complete lane is `shipped`, a finished lane renders `●` — the same glyph as active work. The board says work is in flight when it shipped. Cosmetic next to the blank-board bug this area already fixed, but wrong in the direction an operator reads at a glance. ## Also pinned Two contracts the surrounding comments assert but nothing tested: - **Cards come from the TASKS, not a resolved IR** — a card must never depend on resolution succeeding to be *visible*. Asserted with an unreadable workflow list. - **A failed resolve degrades to the legacy pair**, with an unresolved custom lane rendering as active — the documented fail-open direction. Plus the paired negative: an ACTIVE lane keeps the active glyph under both vocabularies, so widening the terminal set cannot mark the whole board finished. ## Audit complete Every `resolveProjectColumnsForRoles` call site in the repository — `engine`, `core`, `dashboard`, `cli` — has now been blinded individually, and every uncovered one is either pinned or has a recorded reason it cannot be. Nothing is left flagged. |
||
|
gsxdsm
|
7d9d097acf |
fix(cli): the TUI board fell back to the LEGACY workflow — it rendered a triage lane the default no longer has (#3178)
Found by following an unexplained number rather than by a sweep: while re-verifying #3141 the resolver reported `intake: "todo"` where `BUILTIN_CODING_WORKFLOW_IR` resolves `intake: "triage"`. That divergence is correct and intentional inside core — and wrong here. ## The defect `dashboard.ts` resolved a task's columns as `def?.ir ?? BUILTIN_CODING_WORKFLOW_IR`, and its card-chip fields the same way. That constant is the **legacy** monolithic IR (`builtin:legacy-coding`); the catalog's actual default is `resolveDefaultWorkflowIr()`. Post-U11 they differ **by a whole column**: ``` default todo, in-progress, in-review, done, archived (planning merged into todo) legacy triage, todo, in-progress, in-review, done, archived ``` So a task with **no workflow selection row** was rendered against a six-column board including `triage` — a lane the real default no longer declares. ## The same drift is already documented as fixed elsewhere `builtin-workflows.ts` records it: > `prepareWorkflowMovePolicyPreflightImpl` resolved the default through the catalog while `resolveTaskWorkflowIrForMove` used the raw constant, so a task with NO selection row produced two different workflow signatures and every flag-ON move threw *"workflow move policy preflight is stale"*. Both sides (and the sync resolver) now call this helper so the default cannot drift again. This surface was missed, and it is the **last non-test consumer of the legacy constant outside core**. ## Test scope, stated because it is narrow Driving the TUI end-to-end needs a rendered terminal and a live store. That harness does not exist here, and building one to assert a fallback would be testing the harness. So the test pins the two facts that make the bug possible and the fix meaningful: 1. **the two IRs genuinely disagree, about `triage` specifically** — if a future change re-merges them, this reports it rather than leaving the fix silently pointless; 2. **the source no longer reaches for the legacy constant.** (2) is a source assertion, weaker than driving the code. It is used for the same reason as the `FloatingWindow` aria-label scan: the defect is a **value at a call site**, there is no single render that reaches both sites, and a per-site render test would pin the one someone bothered to write. Both assertions are anti-vacuity guarded — the IR comparison fails if either side stops resolving to a v2 column set. ## Verification | | result | |---|---| | cli `tsc` | **0 errors** | | new test | **2 passed** | | mutation — restore `?? BUILTIN_CODING_WORKFLOW_IR` | **1 failed / 2** | | census `--strict`, `check-fnxc-future-dates` | exit 0 (this class is invisible to the census — an argument, not a comparison) | Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
gsxdsm
|
72f5f8e51a |
fix(gate): the FNXC stamp gate never validated the hour, so 25:30 passed (#2995)
`check-fnxc-future-dates.mjs` validates the **date** portion of a stamp
and never looks at the clock time:
```js
const STAMP = /FNXC:[A-Za-z0-9_-]+\s+(\d{4}-\d{2}-\d{2})/g;
…
for (const match of source.matchAll(STAMP)) if (match[1] > today) hits += 1;
```
The capture stops before the hour, so a stamp may carry **any** `hh:mm`
and pass. Found while pre-flighting #2992, whose new comments read
`2026-07-30-25:30`.
## It is not one typo
Four stamps **already on `main`** carry a clock time that cannot exist:
```
packages/cli/src/__tests__/task-list-board-columns.test.ts:2 -24:40
packages/cli/src/commands/task.ts:29 -24:40
packages/cli/src/commands/task.ts:636 -24:40
scripts/check-lane-wiring.mjs:18 -24:00
```
Three separate authors, so this is the gate's blind spot rather than one
person's slip — and #2992 adds two more, which is how I noticed.
AGENTS.md specifies `yyyy-MM-dd-hh:mm`. The stamp's whole purpose is to
make the FNXC record a readable chronology of *why* code exists; a
timestamp that cannot exist quietly costs it that, and nothing was going
to catch it.
## The fix
Hours `00-23`, minutes `00-59`, counted per file **alongside** the
future-dated population rather than as a separate gate — same defect
class (a stamp that does not describe a real moment), and one ratchet is
cheaper to keep honest than two.
**Mutations, both directions:**
| stamp | result |
|---|---|
| `2026-07-30-25:00` | **flagged** |
| `2026-07-30-23:75` | **flagged** |
| clean tree | `475 known future-dated stamp(s), none added`, exit 0 |
## On the four existing stamps
Normalized by clamping the impossible hour to `23`, minutes preserved,
so relative ordering within each file survives. **That is a
normalization with a stated rule, not a claim about the true minute** —
`-24:40` most plausibly meant "just past midnight", but writing
`2026-07-31-00:40` would be future-dated against today's local calendar
and fail the very gate this PR extends. Clamping keeps every stamp real,
ordered, and non-future; the exact minute was already unrecoverable.
**Verified:** FNXC gate exit 0, lane-wiring gate exit 0,
`task-list-board-columns` 5/5, lint clean.
Comment-only changes to the CLI files (stamp text inside FNXC blocks),
so no behaviour change and no changeset.
Noted separately on #2992 so its two new stamps get corrected there
rather than landing and immediately failing this gate.
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
gsxdsm
|
a57f6699b3 |
fix(cli): fn task list never printed cards in renamed columns (#2986)
## `fn task list` never printed cards in renamed columns
```ts
for (const col of COLUMNS) { // the legacy six ids
const colTasks = tasks.filter((t) => t.column === col);
```
A task in a workflow-defined column matches **no iteration**, so it is
not printed. This is not a wrong label or a wrong glyph — **the card is
absent**, and the output reads as a shorter, healthy board rather than
as a bug. On a fully renamed board the command prints nothing but the
header. `COLUMNS` also still contains `triage`, which U11 (#2515)
deleted.
## Found where the previous author left it
The `DELIBERATE-LITERAL` note directly above this loop is correct about
its own glyph, and it named the deeper bug rather than hiding it:
> NOT claimed as trait-resolved, and the deeper bug is left alone:
because the loop iterates the legacy enum, a card in a workflow-renamed
column is not rendered AT ALL. That is the R8/U10 surface change […] and
a far bigger fix than this glyph.
It also predicted the coupling: *"If this ever iterates
workflow-resolved columns, that difference becomes live and the right
answer is a trait lookup, not this."* So both move together — once the
loop can yield a custom id, the terminal test **must** stop being an id
comparison. Fixing only the loop would leave a renamed done-lane
rendering as active work.
## Two deliberate choices
**Lanes come from the tasks, not from a resolved IR.** A board can span
several workflows and therefore has no single column list, and a card
must never depend on a resolution succeeding in order to be *visible*.
Legacy ids keep their familiar order and labels; anything else follows
alphabetically, so output is deterministic.
**Terminal lanes are resolved**, via
`resolveProjectColumnsForRoles(TERMINAL_ROLES)` — that is a display
question with a real answer, and this function is async with a store in
hand. Best-effort: a failed resolve falls back to the legacy pair rather
than failing the command, and an unresolved custom lane renders as
*active*. Showing a finished card with the wrong glyph is a far smaller
error than the blank board this replaces.
## Coverage, and its limit stated plainly
The lane-selection decision is extracted to an exported seam and tested
there. It is **not** end-to-end: `runTaskList` resolves a real project
context and ends in `process.exit`, so driving it would need the
mock-the-world shell `docs/testing.md` tells us to avoid when a narrower
seam exists. The call site is held by the compiler instead — the loop's
only source of lanes is that function. I have written this in the test
file rather than leaving it implied, because "5 passed" on a helper
could otherwise read as proof of the command's behaviour.
Reverted — the seam returning `[...COLUMNS]`, which is exactly what the
loop did — **all 5 cases fail**:
```
AssertionError: expected [ 'triage', 'todo', …(4) ] to deeply equal [ 'backlog', 'building', 'checking' ]
AssertionError: expected [ 'triage', 'todo', …(4) ] to deeply equal [ 'todo', 'shipped' ]
Tests 5 failed (5)
```
## Verification (measured)
- **86 passed / 3 files** — new suite plus `bin.test.ts` and
`pr-merge-review-lane.test.ts`
- `tsc --noEmit`, `eslint` — clean
- `lifecycle-column-census --strict`, `check-lane-wiring` (26, none
added), `check-fnxc-future-dates` — green
- `pnpm check:changesets` — clean; changeset included (`patch`), since
`packages/cli` is the published `@runfusion/fusion` and this is
user-facing
|
||
|
gsxdsm
|
be79fe0db6 |
fix(cli): PR merges silently never ran on a renamed board — the blocker was asked about in-review (#2976)
## PR merges silently never ran on a renamed board
`processPullRequestMergeTask` called its injected blocker with the task
alone:
```ts
if (getTaskMergeBlocker(task)) return "skipped";
```
So `options.reviewColumns` was undefined and the blocker's identity
check fell back to `task.column === "in-review"`. On a board whose merge
lane is named anything else it returns:
```
task is in 'checking', must be in 'in-review'
```
…which is truthy, so this function returns `"skipped"`. **Silently and
permanently** — nothing logs, nothing fails, the PR simply never merges.
`daemon.ts`, `serve.ts` and `dashboard.ts` all drain PR merges through
here, making this a third instance of the #2963/#2964 class ("merge
entry points unwired — merging was impossible on a renamed board").
Found via the baseline #2966 shipped:
`packages/cli/src/commands/task-lifecycle.ts` was a known-unwired call
site in it.
## Narrow resolution, deliberately
`resolveReviewColumns` is the **broad** set, and its own FNXC note warns
that a caller which admits on it *and then moves the card* will act on
cards the engine does not consider in review. This function merges and
moves to the complete lane — a state-changing admission — so it uses
`resolveMergeOrchestrationColumn`, the single lane the engine acts on.
That matches how `moves.ts` wires the same call.
Degradation is unchanged in both directions: `resolveWorkflowIrForTask`
substitutes the default IR rather than throwing, so a default board
resolves `in-review` and behaves identically; a v1-upgraded IR resolves
every role empty and keeps the documented legacy literal (covered by a
test).
## One shape choice worth flagging
The option is always **passed** and conditionally **valued**:
```ts
getTaskMergeBlocker(task, { reviewColumns: mergeLane ? new Set([mergeLane]) : undefined })
```
rather than making the whole argument conditional. These are identical
at runtime — the blocker treats an undefined `reviewColumns` exactly as
it treats absent options — but **only this shape is visible to
`lane-wiring-census.mjs`**, which matches an object-literal argument and
cannot see a ternary. I wrote the ternary first, and the gate still
reported the site as unwired; wiring a gate cannot check is how this
defect survived in the first place.
The gate then confirmed the fix and asked for the baseline in the same
commit:
```
[check-lane-wiring] unwired call sites decreased:
packages/cli/src/commands/task-lifecycle.ts: 1 -> 0
```
Baseline re-recorded 9 → 8 in this commit, so the allowance cannot be
regrown into.
## Revert proof
**There was no test for this function at all** — that is why it went
unnoticed. Restoring only `task-lifecycle.ts`:
```
AssertionError: expected "vi.fn()" to be called with arguments: [ ObjectContaining{…}, …(1) ]
AssertionError: expected 'skipped' not to be 'skipped'
AssertionError: expected "vi.fn()" to be called with arguments: [ ObjectContaining{…}, undefined ]
Tests 3 failed | 1 passed (4)
```
The one case that passes both ways is "still skips a card that is not in
any merge lane" — it guards against over-admission rather than proving
the fix, and I am not claiming it as coverage of the defect.
## Verification (measured)
- new suite **4/4**; with `pr-automerge-cleanup` **9 passed / 2 files**
- `tsc --noEmit`, `eslint` — clean
- `check-lane-wiring` (8, none added), `lifecycle-column-census
--strict`, `check-sql-column-literals`, `check-fnxc-future-dates` —
green
**Changeset added** (`patch`). `packages/cli` is the published
`@runfusion/fusion` and this changes user-facing merge behaviour, so
AGENTS.md requires one. My first pass hedged and left it to a maintainer
— that was wrong, the rule is not discretionary, and it is now in the
branch.
|
||
|
flexi767
|
dd930c8d7d |
fix(cli): qualify cross-fork PR heads (#2377)
## Summary - resolve the repository receiving pushes through `git remote get-url --push origin` - qualify pull-request head branches with the fork owner when the push owner differs from upstream - preserve the existing unqualified head for same-repository workflows ## Root cause Fusion correctly resolved the PR target from origin's fetch URL, but assumed the pushed branch lived in that same repository. With an upstream fetch URL and a fork push URL, GitHub requires `fork-owner:branch`; the unqualified branch is rejected. ## Validation - CLI task lifecycle tests: 48 passed - `@fusion/core` typecheck - `@runfusion/fusion` typecheck - strict changeset validation <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Pull requests created from branches pushed to contributor forks now correctly qualify the PR head with the fork owner when the push remote differs from the upstream owner. * Improved PR head handling across both group/shared-branch and per-task pull request creation paths. * **Tests** * Updated and expanded lifecycle tests to cover “origin push to fork” scenarios using push URL–based repo resolution. * **Documentation** * Added a patch release note for the fork-aware PR head fix. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: v <v@v.speedport.ip> Co-authored-by: gsxdsm <gsxdsm@users.noreply.github.com> |
||
|
gsxdsm
|
189f237a07 |
fix(security): make the approval and permission gates actually enforce (#2457)
## Why
An AI agent autonomously deleted a live task (FN-8609) via
`fn_task_delete`. Investigating that led to two audits, which found the
gate machinery is well-built and its *enforcement* well-tested — but the
*decision boundary* was unguarded and the tools that matter never
reached the gate at all.
The headline defect: all ~76 tools in `packages/cli/src/extension.ts`
are delivered through `hostExtensionPaths` → `DefaultResourceLoader`,
which never passes through `wrapToolsWithActionGate`. `fn_task_delete`
*was* classified as gated in `gating-classifications.ts` — that
classification was dead code. Roughly 15 destructive tools were ungated
even for an operator who had locked their policy all the way down.
Second: `POST /api/approvals/:id/decision` took the approver identity
from the request body, validated for shape only, with no check that the
decider was human or differed from the requester. Combined with a bash
tool whose command string was never inspected (only `params.cwd`), an
agent could read the daemon token from `~/.fusion/settings.json`, find
its own pending request, and approve it.
## Scope
This does **not** tighten defaults. The `unrestricted` preset is
byte-for-byte unchanged — `git diff` on `agent-permission-policy.ts` is
empty — and regression tests assert that an out-of-the-box install
behaves exactly as before. The bug was never "the default is too
permissive"; it was "strict policy doesn't enforce." This makes turning
security up actually work.
The one deliberate exception: the containment that stops an agent
escalating its *own* privileges (reading the daemon token / credentials,
calling the approvals API to self-approve) applies at every preset
including `unrestricted`. That is a privilege-escalation boundary rather
than a permission preference — if it only engaged under strict policy it
would not have prevented the incident that prompted this.
## What changed
8 bisectable commits:
- **Approval lifecycle** — self-approval blocked via server-derived
deciders; same-verdict replay 409s; decide re-reads and re-validates
inside the transaction; expiry TTLs; `markCompleted` ownership check;
session identity registry in core.
- **Engine gates enforce for real** — unclassified tools resolve to a
policy-governed category instead of hardcoded `allow`; missing-policy
fail-open closed; bash containment floor + exact-command approval
binding.
- **Dashboard decision routes** — stop trusting client-supplied actors
(decision, bypass-review, worktrunk → 403 on forged actors).
- **`fn serve` authenticated by default** — auto-mints a token following
the existing `fn dashboard` precedent; `--no-auth` opts out.
- **Sibling entry points closed** — user-sourced hard-cancel moves, ACP
execute-once approvals, plugin task-store gating.
- **pi-extension principal resolution** — the extension resolves the
acting principal and can withhold or policy-gate the previously ungated
destructive tools.
- **Root-cause bonus fix** — `findLatestByDedupeKey` was broken in
PostgreSQL backend mode (already-parsed jsonb fed through a string-only
parser), so approved-grant redemption **never matched in production**,
minting duplicate requests. This explains the live DB state of 17
approved / 0 completed. *(Also cherry-picked to `main` as `a9b30013bb`,
since it is an active production defect on its own.)*
- **Review follow-ups** (`627f1b1fa8`) — operator-configured
provisioning privilege and a configurable grant TTL; see below.
## Review follow-ups
**Provisioning privilege is operator-configured, not role-derived.**
`isCallerPrivileged` had gone from `caller.reportsTo == null` (every
top-level agent privileged — permanent escalation by creating a
manager-less agent) to `caller.role === "ceo"`, which swapped an
implicit rule for a magic string: any agent config can claim that role,
while an operator who genuinely wants a privileged agent had no
supported way to say so. Privilege now derives solely from
`agentProvisioning.trustedAgentIds` / `trustedRoles` and fails closed
when settings are unresolvable.
It is also no longer forwarded to `resolveAgentProvisioningPolicy` as
`isPrivileged`, because that flag short-circuits ahead of
`alwaysApproveDelete` — a trusted caller was bypassing delete approval
entirely. The policy applies the same trusted rules itself, in the right
order. The function now governs only the org-chart escape hatch (acting
outside your own direct reports).
**Grant TTL defaults to 1 hour and is configurable.** Approval →
redemption is not instantaneous: an operator approving from their phone,
an engine restart, a queued lane, or a task waiting on a worktree all
routinely exceeded 15 minutes, after which the grant expired and the
agent silently re-requested. One hour remains far short of the
"redeemable forever" hazard the TTL exists to bound. Override via
`FUSION_APPROVAL_GRANT_TTL_MS` or `configureApprovalRequestTtls()`;
invalid overrides are ignored rather than widening the window to
infinity or collapsing it to zero.
## Behavior changes requiring operator review before rollout
1. `fn serve` requires a bearer token by default (`--no-auth` opts out);
unauthenticated clients get 401.
2. Agents can no longer run withheld destructive tools
(`fn_task_delete`, `fn_task_bypass_review`,
mission/milestone/slice/feature/workflow deletes, `experiment_finalize`,
`skills_install`). Operators keep them via CLI/dashboard. **This is the
incident fix.**
3. Agents get provisioning privilege only when the operator lists them
in `agentProvisioning.trustedAgentIds` / `trustedRoles`; the
provisioning gate is now live in production. Previously-implicit
privilege (top-level position, or a `ceo` role) no longer grants
anything on its own.
4. Decision replay 409s (was 200); pending approvals expire after 24h,
approved grants after 1h (configurable); bash approvals bind per exact
command.
5. Forged/body actors on decision, bypass-review, worktrunk routes →
403; `archive-all-done` requires `{confirm:true}` (external scripts
affected).
6. `fn_secret_get` approvals grant exactly one reveal (previously
granted nothing and looped forever); ACP approvals are execute-once
(previously infinite reuse).
7. Bash containment denies token/credential/approvals-API commands in
all agent sessions at every preset.
## Verification
Independently re-run against the branch, not just self-reported:
- 5 typechecks (core, engine, cli, dashboard `tsconfig.json` +
`tsconfig.app.json`) — clean
- `pnpm lint` — clean
- `pnpm test:gate` — 379 passed
- `pnpm build --force` — green (a plain `pnpm build` skips packages as
unchanged and does **not** compile the branch)
- `pnpm check:changesets` — clean
- ~650 file-scoped tests including new negative-path suites for the
decision boundary, which previously had **zero** test coverage
`packages/engine/src/__tests__/plugin-runner.test.ts` fails 56/80 —
**verified pre-existing**, reproducing identically at base commit
`93a403af67` on `main`. Not in the merge gate.
### A mutation check that failed to fail
Worth recording, because it nearly shipped an untested security fix. The
first mutation check on the provisioning change reintroduced the `ceo`
hardcode and **all 17 tests still passed** — the tests asserted through
the policy path, which can no longer observe `isCallerPrivileged` at
all, precisely because `isPrivileged` is no longer forwarded there.
Org-chart cases that do exercise the function were added; the hardcode
now fails exactly 1 of 19, and restoring is green. A green mutation run
is only meaningful if the test can actually see the code under test.
## Known limitations (stated, not papered over)
- The bash containment floor is string-matching: a cost-raiser, not a
sandbox. Quoting, encoding, `$HOME`, symlinks, or an interpreter
one-liner can evade it. The durable protection is the decision route
refusing agent-originated deciders — the filter is the belt, not the
braces.
- Approval expiry is lazy (evaluated at decide/complete/redeem), not
swept, so an expired pending row stays visible in lists until touched.
- The extension's require-approval path returns a pending message but
cannot suspend a pi session mid-turn; engine-side pause hooks cover
engine lanes only.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Security**
* Hardened approval and permission gating with server-side decider
attribution, self-approval blocking, ownership checks, replay/race
protection, and status/TTL enforcement.
* Added fail-closed behavior for sensitive/unclassified tools and
sandbox provisioning approvals.
* Blocked credential/approval access via bash containment; plugin
destructive task operations now require explicit permission.
* **New Features**
* `fn serve` now defaults to bearer-token auth, with `--no-auth` as the
explicit opt-out.
* **Bug Fixes**
* Improved task move-source attribution (`moveSource: "user"`) and
tightened dashboard archive/bypass confirmation and operator attribution
behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
|
||
|
gsxdsm
|
6fc98fd6c7 |
the third census-invisible class: 51 hardcoded moveTask destinations, measured — and duplicates never archived on a renamed board (#2808)
A third census-invisible class, measured — plus the two worst instances
fixed.
## The shape
```ts
if (task.column !== "in-review") { … return; } // the census counts THIS
await this.store.moveTask(taskId, "in-progress"); // and cannot see THIS
```
The census is an AST scan for **comparisons**. A `moveTask` destination
is a **call argument**, so no backlog entry ever points at one.
Converting the guard alone is *worse than converting neither*: the
handler starts admitting work on a renamed board and then tries to move
the card into a lane that board may not declare.
This bit twice in one week — #2797 (`branch-worktree` requeued into a
lane that may not exist) and #2807 (a GitHub "changes requested" review
dropped, then a move to a hardcoded `in-progress`). Both times it was
found only because the guard *next to it* happened to be under
conversion. So I went looking.
## Measured
Across `core`/`engine`/`dashboard`/`cli`/`plugins`, excluding
`__tests__`/`*.test.*` and comment lines:
| | count |
| --- | ---: |
| hardcoded `moveTask` destinations in production | **51** |
| …passing `recoveryRehome: true` — **deliberate**, not defects | 22 |
| …plain, rejected on a board that does not declare the target | **29**
|
**The 22 must not be "fixed".** `moves.ts` exempts them on purpose
(#1411): a card stranded in an undeclared column has to stay rescuable
to a legacy safe-landing column, or it can never be recovered at all. A
sweep that converts them deletes the rescue path. That distinction is
the reason this is 29 and not 51, and it is why I measured before
writing.
## Why this got sharper recently
The `workflowHasColumn(workflowIr, toColumn)` rejection used to sit
inside a block gated on `isWorkflowColumnsCompatibilityFlagEnabled` — a
settings key **nothing in production writes** — so it never executed and
the legacy `VALID_TRANSITIONS` table decided instead. U12 hoisted it out
of that dead branch and it is now live, proven on a real store by
`live-move-path-undeclared-target.test.ts`:
```
moveTask(card in "todo" -> "triage") now REJECTS: /Unknown column for this workflow/
```
That changed the failure mode of all 29 from *"silently lands the card
in an undeclared column"* to *"throws"*.
**29 is not a crash count.** Whether a throw surfaces or disappears
depends on whether the caller catches, which is per-site and I did
**not** measure it — the doc says so explicitly rather than letting the
number imply severity it hasn't earned.
## Fixed here: 9 of the 29
`duplicate-intake` and `duplicate-guard` both archive a duplicate. On a
renamed archive lane the move is rejected, so **the duplicate is never
archived and keeps sitting on the operator's board as live work** — and
in `duplicate-guard` the row has already been stamped
`deterministicDuplicateOf`, so it is *marked* a duplicate while
occupying an active lane. Half-applied, which is the same trap as
#2797's branch clear.
Both now resolve the `archived`-trait column from the task's own
workflow through one shared helper, unioned with the legacy id.
**`cli/commands/task-lifecycle`** — `finalizePullRequestMerge` and
`finalizeNoOpMergeTask` both move the card to a hardcoded `"done"`, and
both run `updateTask({ status: null, mergeRetries: 0 })` *first*. On a
rejection the merge has already landed and the bookkeeping is already
cleared while the card never reaches its complete lane: the operator
sees a merged branch, a card still sitting in review, and a reset retry
counter. Same half-applied shape as #2797's branch clear. Both now route
through one resolver so they cannot drift.
**`contamination` / `foreign-only-contamination` (×2) /
`restart-recovery-coordinator`** — four recovery requeues to a hardcoded
`"todo"`, none of them a `recoveryRehome` escape. On a board without
that column the move is rejected and **the recovery never completes** —
the card stays contaminated or stranded, which is precisely the state
these paths exist to clear.
**Consolidation.** `resolveReboundTargetForTask` and
`resolveArchiveTargetForTask` now live beside
`resolveTaskLifecycleColumns` in `workflow-lifecycle-traits`, already
the store-dependent resolution seam. My first pass put the archive
helper inside `duplicate-intake` and had `duplicate-guard` import it
from there — wrong home, and it would have grown a copy per caller as
more sites converted. Seven call sites now share two definitions.
**Plain (non-`recoveryRehome`) destinations: 29 → 21.**
**Coverage on the CLI pair is scoped, and I'd rather say so than imply
more:** the test covers the *resolver*, not the two call sites. Both
enclosing functions are private and reachable only through
`processPullRequest`, which needs a live GitHub surface — exporting them
purely to test wiring is a worse trade than stating what is covered.
Three cases: renamed lane resolves, no-workflow falls back to the legacy
id (which also pins that a default board is byte-identical), and a
throwing lookup falls back.
## Revert result (measured)
| conversion | reverted → |
| --- | --- |
| duplicate archive destination | new case fails — `moveTask` called
with `"archived"` on a board whose archive lane is `boxed` |
| CLI complete-lane resolver | replacing the body with a bare `return
"done"` fails the renamed case |
| both move-target resolvers | replacing either body with a bare return
of its legacy id fails 5 cases across the resolver suite and
`duplicate-guard` |
Each resolver has a **non-vacuous companion** asserting it does *not*
return the legacy id on a renamed board — without it, a resolver
returning any string would pass. The fallback cases are load-bearing
rather than padding: `resolveWorkflowIrForTask` degrades to the built-in
IR rather than throwing, and the built-in rebound/archive lanes *are*
`todo`/`archived`, so those cases also pin that a default board is
byte-identical.
The pre-existing case asserting the legacy `"archived"` passes both
ways, which is exactly why it could not detect this and why the new one
supplies a workflow.
## Ownership note
`packages/core` was `batch-core`'s territory and `packages/cli` was
`batch-cli-plugins`'. Both batches have landed, and this is
newly-discovered work in the class documented here rather than leftover
conversion backlog. Four sites, two shared helpers — happy for either
half to move if those owners would rather carry it.
## Verification
- `pnpm test:gate` — 161 + 487 + 13 + 71, green
- `duplicate-guard` + `duplicate-intake` — 40 passed
- `tsc` on core and engine — clean
- `pnpm lint`, `check:changesets`, census `--strict` — all clean (run
explicitly; a clean `pnpm lint` alone is not evidence the CI Lint check
passes)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Bug Fixes**
- Duplicate tasks are now archived to each workflow’s configured archive
lane.
- Completed tasks are moved to the workflow-specific completion lane,
with a safe fallback for older workflows.
- Recovery and requeue actions now use each workflow’s configured
rebound lane instead of assuming a fixed destination.
- **Documentation**
- Added guidance on avoiding failures caused by hardcoded workflow
destinations and incomplete lifecycle conversions.
- **Tests**
- Added coverage for renamed workflow lanes, fallback behavior,
duplicate archiving, and recovery destinations.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
gsxdsm
|
29186a96da |
fix(tests): new CLI red from #2775 — the test pinned a decision its own PR superseded (#2801)
## New red on main #2775 landed and put one failure on `main`, in a test that PR itself added: ``` pr-create-review-lane-resolved.test.ts > refuses WITHOUT naming a phantom lane when the workflow declares no review lane AssertionError: expected undefined to be defined ``` ## Two review rounds pushed `pr.ts` in opposite directions; the test is from the losing one | round | decision | |---|---| | **1** (greptile P2) | a resolved workflow with no review-trait column is an **answer** — do not invent `'in-review'`, say *"no review lane"*. **This test was written against that.** | | **2** (greptile) | refusing on an empty set rejects **every v1 workflow**, because `synthesizeDefaultColumns` upgrades a v1 graph by emitting every column with `traits: []` — so a v1 board whose `in-review` column plainly exists resolves to an empty review set. | **Round 2 shipped** (`pr.ts:206-207`) and is right: an empty set is indistinguishable from a v1 upgrade, so it means *unexpressed* rather than *absent* and takes the same legacy fallback as an unreadable workflow. Both rounds are extensively documented in `pr.ts` — the code is deliberate and I have not touched it. The consequence is simply that **there is no "no review lane" message in the shipped code at all**, so `errors.find((e) => e.includes("no review lane"))` returned `undefined`. The test could never have passed against what merged. ## The fix Re-pointed at the contract that actually shipped: the filtered board takes the legacy `'in-review'` fallback, and the refusal must **not** name the renamed lanes (`signoff`, `waiting-on-a-human`) that this board no longer declares — which preserves the anti-phantom-lane intent the test was named for. ## Flagged, not guessed The round-1 behaviour is **not recoverable** without a way to distinguish *"v2 board that declares no review lane"* from *"v1 board whose traits were synthesised empty"*. The IR does not currently carry that signal, so emitting a distinct message would re-break every pre-v2 project — the exact regression round 2 caught. Recorded in the test rather than invented. ## Evidence Mutations, both caught: | mutation | result | |---|---| | fallback names lanes the board lacks | **1 failed** | | the review-lane gate removed entirely | **2 failed** | Full CLI package **1684 passed / 106 skipped (126 files)** — was 1 failed. Gate **732 green** · lint clean. Test-only; `pr.ts` restored clean after the mutations. ## How this was found Pre-flighting the open batch PRs against current `main` rather than their branch heads, after batch-engine's previous landing put 32 failures on main that were only caught post-merge. #2785 and #2783 both came back clean (commented on each); re-running `main` itself after the newest landings surfaced this one. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
gsxdsm
|
4184fde08d |
batch-cli-plugins: 7 guards — 3 were a foreign enum, and fn pr create refused every card on a renamed board (#2775)
`batch-cli-plugins` — the u7 worker's mega-batch: `packages/cli` + `plugins` + anything left. ## The batch is 7 guards, and 3 of them are not guards at all The census's per-file list gives this batch seven sites. Reading them, **three are a foreign vocabulary the census matches on the string alone**: | file | site | verdict | |---|---|---| | `plugins/fusion-plugin-reports/store/report-store.ts` | `next === "archived"` ×2 | **not a column** — `next` is a `ReportStatus` | | `plugins/fusion-plugin-reports/store/report-types.ts` | `to === "failed" \|\| to === "archived"` | **not a column** — same enum, its own terminal states | The reports plugin has its own status lineage (`draft → generating → review_* → approved → published`, plus `failed`/`archived`) that shares two spellings with the lifecycle vocabulary. A report is not on a board and has no workflow, so resolving an IR there would answer a question nobody asked. All three are marked `DELIBERATE-LITERAL` with the reason at the site. **This cuts the other way from #2763.** That PR establishes the census total as a *floor* (25 membership predicates it structurally cannot see). This is the opposite error in the same number: a foreign enum inflating it. The total is neither a ceiling nor a floor — it is an estimate with error in both directions, and the per-file list is worth reading before trusting a file's count. ## Converted (census before → after, per file) | file | before | after | |---|---|---| | `packages/cli/src/commands/pr.ts` | 1 | **0** | | `plugins/…/even-realities-glasses/notifications/diff.ts` | 1 | **0** | | `plugins/…/reports/store/report-store.ts` | 2 | **0** (deliberate) | | `plugins/…/reports/store/report-types.ts` | 1 | **0** (deliberate) | ### `fn pr create` refused every card on a renamed board The live defect in this batch. The gate was `task.column !== "in-review"`, and its error told the operator to move the task to a column their board does not have: ``` Error: Task must be in 'in-review' column to create a PR (current: signoff) ``` There is no way to satisfy that short of renaming the workflow back. Now resolved through core's `resolveReviewColumns`, and the message names the lanes that actually exist. **The SET, not `lifecycle.review`.** A board may declare more than one review lane, and a card parked in a `humanReview`-only lane is still a card you can open a PR from. A single-id answer keeps refusing those — the same narrowing #2728's review caught in the CLI retry gate, which is why the test pins both lanes. ## Skipped, with the reason **`plugins/fusion-plugin-even-cards` (2 guards) — blocked on packaging, not on analysis.** The defect is real: `boardToDeck` filters with `column !== "archived" && column !== "done"`, so on a renamed board every finished card stays in the deck, fills `maxCards`, and pushes the active cards off the display. The wearer sees a board that never finishes anything. I implemented the fix and **reverted it**: this plugin is not in `pnpm-workspace.yaml` and depends only on `@fusion/plugin-sdk` — it has no `@fusion/core` dependency, so the route cannot reach `resolveTaskLifecycleColumns`. Adding one is a packaging change, which this program's rules put out of scope. Shipping only the injected parameter without a caller was the alternative, and that is precisely the decorative conversion #2759 documents: the census would drop by 2 and the deck would keep the bug. Flagged for whoever owns the plugin's dependency surface. The glasses plugin next door *does* depend on `@fusion/core`, so this is a one-plugin problem, not a plugin-wide one. ## Honest note on the glasses conversion `diff.ts`'s completion branch is **currently unreachable** — the only production caller (`notifier.ts`) passes `alsoNotifyOnDone: false`. So that conversion changes nothing at runtime today. It is converted rather than marked deliberate because the literal is not deliberate: it is wrong, and would ship the bug the day someone turns the flag on. Stated here rather than left for a reviewer to discover. ## Verification - new CLI suite **4 passed**; `pr-command` + `pr-automerge-cleanup` + `bin-pr-router` **35 passed** - glasses plugin **181 passed (19 files)** · reports plugin **110 passed (23 files)** - `pnpm test:gate` — **158 / 10 / 487 / 71** · `pnpm lint` clean · `--strict` exits 0 **Revert proof, measured.** Restoring `if (task.column !== "in-review")` fails 3 of the 4 new cases (`process.exit:1` on both renamed lanes, and the refusal message reverts to naming `in-review`). The unresolvable-workflow case keeps passing — it is the legacy path — so the negative cases alone do not pin the fix and all four are required. ## Handoff to `batch-engine` `packages/engine/src/project-engine.ts` **5 → 0** is finished, green, and pushed as `handoff/project-engine-lanes-for-batch-engine` (`34dbb35209`) for the capacity worker to cherry-pick — it is engine-owned, not mine to land. It fixes two live defects: a card that **had merged** reported as a failed merge to `fn task merge` and the dashboard button (`merged: finalTask?.column === "done"`), and the three post-finalize `column === "done" && mergeConfirmed` fast-path checks, which on a renamed board sent an already-landed card down the bounce path — re-queued, retry-counted, and in the capped branch parked `failed` with its merge sitting on main. Plus `hasAutoHealableVerificationBufferFailure`, which returned false for every card on a renamed board, so a buffer-overflow verification failure was never auto-healed. 8 new tests, revert-proven (restoring the literal fails 4 of 8), gate green. --- ## Completion pass (u7) — the batch is now closed Two workers converged on this branch. I rebased onto the first-landed commit rather than force-pushing over it, took its wording wherever the conclusion was identical, and added what was missing. ### What this pass added 1. **`even-cards` (2 sites)** — the only in-scope file the first pass left open. Marked DELIBERATE-LITERAL: the package depends on `@fusion/plugin-sdk` only, and the SDK does not re-export the lifecycle role helpers, so there is no IR, no store, and no trait flags to resolve *from*. Fixing it properly means the SDK exposing role flags on the task shape it hands plugins — a structural change, out of scope, and recorded at the site as the correct home. Live consequence is cosmetic: a finished card on a renamed board shows as active in the glasses deck. 2. **A red test in the `fn pr create` conversion.** The incoming version rendered `Task must be in 'in-review' to create a PR`, dropping the word `column`. `task.test.ts:3422` pins `must be in 'in-review' column`, so that hunk failed `runTaskPrCreate > exits with error when task not in in-review column`. Restoring the word makes the single-lane message **byte-identical** to the pre-conversion one, which is what a vocabulary conversion should be — the guard's own test now passes unmodified. Marked at the site so it is not "simplified" back. 3. **Duplicate imports** — the two independent conversions each added `resolveWorkflowIrForTask`/`resolveReviewColumns`, which does not compile. Deduped in its own commit. ### Census Measured with `--json` on `origin/main` and on this branch. | file | before | after | action | |---|---|---|---| | `packages/cli/src/commands/pr.ts` | 1 | 0 | converted | | `plugins/fusion-plugin-reports/src/store/report-types.ts` | 1 | 0 | marked | | `plugins/fusion-plugin-reports/src/store/report-store.ts` | 2 | 0 | marked | | `plugins/fusion-plugin-even-cards/src/cards/board-cards.ts` | 2 | 0 | marked | | `plugins/fusion-plugin-even-realities-glasses/.../diff.ts` | 1 | 0 | marked | Backlog **415 → 408** (−7, exactly the in-scope count). Deliberate **40 → 46** (+6 marked); 6 + 1 converted = 7. `--strict` exits 0. **Nothing remains in `cli` + `plugins` + everything-else — there is no follow-up batch behind this one.** ### One note on the `even-realities-glasses` site Worth recording beyond "cannot resolve": its only production caller (`notifier.ts:80`) passes `alsoNotifyOnDone: false`, so that arm is **unreachable today**. Converting it could not have changed observed behaviour either way. ### Verification (measured, on the merged branch) - `pnpm --filter @runfusion/fusion exec tsc --noEmit` → exit 0 - `pnpm lint` → 0 errors - CLI `task.test.ts` → 144 passed, including the `runTaskPrCreate` guard test - `@fusion-plugin-examples/reports` → 110 passed; `even-realities-glasses` → 181 passed **Pre-existing failures, not from this change:** the 5 `runTaskImportFromGitHub` / `runTaskImportGitHubInteractive` tests fail identically on `origin/main` — verified by stashing this diff and re-running (5 failed / 144 passed both ways). --- ## Census audit (unowned follow-on) After closing the batch scope I audited whether the **392** column-backlog number is inflated by foreign vocabularies — the class this batch found in the reports plugin, where `"archived"` is a `ReportStatus` rather than a board lane. If that class were widespread, every remaining batch would be chasing sites that must not be converted. **It is not. The number is real.** A receiver-level pass over all 392 column-category sites found exactly **3** false positives, all in `plugins/fusion-plugin-reports` (`next`, a `ReportStatus`), all now marked in this PR. What was checked and cleared: - **Property-reached foreign enums** (`step.status`, `feature.status`, `mission.status`) — already correctly bucketed into the separate `status` category (185), not the column backlog. Verified against `merge-queue-ops.ts`: 11 lifecycle-spelled literals in the file, census counts **1**, and that 1 is the genuine `.column` guard. - **Bare step-status variables** (`status`, `currentStatus`, `liveStatus` compared to `"done"`/`"skipped"`) — likewise excluded. - **Every other receiver in the backlog** — `to`, `from`, `column`, `fromColumn`, `toColumn`, `latestColumn`, `state`, `preArchiveColumn`. All resolve to genuine task columns. `executor.ts`'s 15 sites were spot-checked line by line: all 15 are real. The gap the classifier genuinely cannot close is a foreign enum held in a **bare variable** — the receiver name carries no type information, so `next === "archived"` is indistinguishable from a lifecycle guard by AST alone. That is why the reports sites need a marker rather than a classifier fix, and it is now documented in `lifecycle-column-census-ast.mjs`'s header alongside the measured scope, so the remaining batches do not re-run this hunt. Census tests: **43 passed**. The change is comment-only. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
gsxdsm
|
59b5e61fa2 |
fix(tests): the last CLI reds — import assertions still required the column U11 removed (#2788)
## What was red All 5 failures in a full `@runfusion/fusion` run on `origin/main` (`5 failed / 1673 passed`), in `src/commands/__tests__/task.test.ts`: ``` - "column": "triage", ``` ## The product change is intentional and documented **#2603 (U11)** removed the hardcoded `column: "triage"` from the GitHub/GitLab import writes so `createTaskImpl` resolves the **workflow's** intake column instead. Passing `column` would override that resolution and, post-U11, name a lane the default workflow no longer declares. `task.ts` still carries the note at three sites: > `createTaskImpl` resolves the WORKFLOW'S intake column, and `input.column` would override it. Hard-coding `"triage"` created the card in a column the default [workflow does not declare]. Six `toHaveBeenCalledWith` assertions still required the removed literal, so a correct product change surfaced as five CLI failures. ## Scoped deliberately Only the **six assertion-side** occurrences are removed. The other **16** `column: "triage"` literals in this file are mock *return* values and `makeTask` fixtures, and they stay — what a created task comes *back* as is a different question from what the import *asks for*, and blanking them would weaken unrelated cases. ## Evidence - Full CLI package: **1678 passed / 106 skipped, 125 files green** (was 5 failed). - **Mutation:** reintroduce `column: "triage"` into the import write → **2 failed**. The assertions still pin the invariant rather than having been loosened into always-true — the thing worth checking when a fix is "delete an expectation". - Gate **732 green** · `pnpm lint` clean. Test-only (mutation reverted; `git diff` clean). ## Ownership `packages/cli` belongs to the **batch-cli-plugins** owner (u7) under the mega-batch split. This is fix-forward on a red rather than a conversion, confined to one test file, and touches no production code. With #2779 and #2786 this leaves engine, core and CLI at **0 failures** on main. The remaining known reds are the 123 dashboard failures documented in #2784. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
gsxdsm
|
2e4905fa0e |
refactor: one definition of "which columns are review" — three copies deleted onto core's resolver (#2751)
**#2730 added `resolveReviewColumns` to core. This deletes the three copies that predated it.** Measured on `origin/main` before this change — three in-tree definitions, **none of which agreed**: | site | definition | |---|---| | `core/workflow-lifecycle-traits.ts` (#2730, authoritative) | mergeOrchestration ∪ mergeBlocker ∪ humanReview — **all** columns | | `dashboard/routes/register-task-workflow-routes.ts` | mergeBlocker ∪ humanReview ∪ **first** mergeOrchestration | | `cli/src/extension.ts` | mergeBlocker ∪ humanReview ∪ **first** mergeOrchestration | | `cli/src/commands/task.ts` | all three, full union | **Both `.slice(0, 1)` variants are mine**, from #2723's review round: I narrowed to core's then-single `.review` because the reviewer was right that a superset let the dashboard act on a lane the engine did not own. #2730 answered that question authoritatively in the other direction, so the narrowing is obsolete. Worse, and the part that makes this urgent rather than tidy: **the two CLI copies had already drifted apart inside #2728.** `fn_task_retry` refused a card in a second merge lane that `fn task retry` accepted — two surfaces, one operator action, two answers, from two copies of one definition written days apart by me. All three now call core. The dashboard keeps its thin store→IR wrapper (its callers hold a store and a task id, not an IR) but the **body** is core's. ## One assertion inverted, deliberately My #2723 case asserted that a **second** `mergeOrchestration` column is **refused**. Core says every merge lane is review, so the behaviour legitimately changed and the assertion flips with it. **Kept rather than deleted**, because the invariant under test — *the routes agree with core* — is unchanged. Deleting the case would have hidden that its answer moved; inverting it records which decision moved and why. A test whose expectation quietly disappears is indistinguishable from a test that was wrong. ## A footgun found while rebasing The shipped signature is `isInReviewMissingWorktreeSessionStartFailure(task, isReviewColumn?: boolean)` — the merged version takes the **answer**, not the lanes. My branch had passed a `ReadonlySet`, and because the parameter is `boolean | undefined` with a `??` default, **a truthy object makes it answer `true` for every column**. TypeScript stops typed callers; my test only reached it through an `as never` cast, which is how I found it. All three production call sites correctly pass `retryReviewColumns.has(task.column)` — now asserted structurally so a fourth surface cannot omit it. The boolean is arguably the better shape, and I'd keep it: there is nothing left for the callee to re-derive, so it cannot disagree with the caller's own membership test. ## The ratchet No surface may reintroduce a local review union (`columnsWithFlag(…, "mergeBlocker" | "humanReview")`). Those three copies appeared because each was added **in good faith, in a different review round, by someone reading only their own call site** — which no amount of care prevents and a ratchet does. ## Verification census **553** · `pnpm test:gate` **487 / 10 / 71** · `tsc` clean in cli and dashboard · `pnpm lint` clean · 10/10 in each touched suite. **Pre-existing, not mine:** `register-task-workflow-routes.move-bypassguards.test.ts` fails on `origin/main` (400 vs 200) — already reported on #2723. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
gsxdsm
|
dc363543a2 |
fix(cli): fn task retry now CRASHES on a renamed board — #2728 converted the classifier and left the target (#2752)
## This is a live regression on `main`, not a conversion `#2728` converted the retry **classifier** and left all three re-queue **targets** on the literal `"todo"`. That pairing is **strictly worse than the bug it fixed**: - **Before:** `fn task retry` silently did nothing on a renamed board. - **After (main today):** it correctly decides to retry, then throws. ``` TransitionRejectionError: Invalid transition: 'checking' → 'todo'. Unknown column for this workflow. ``` `todo` is not a column that board declares. Reproduced against main's exact code — reverting this fix fails **2 of 4** cases with that error. I flagged this on #2728 before it landed; posting it as a fix rather than a comment now that it is merged. ## Why the census did not catch it The census counts **comparisons**. A move **target** contains no comparison, so all three sites are invisible to it — `packages/cli/src/commands/task.ts` reads **0 guards** on main while the crash is live. That is the clearest case in this program so far that **the census measures conversion progress, not correctness**. A classifier and the target it feeds have to move together, and no automated signal will say so. ## The fix The target resolves from the task's own workflow: ```ts const retryHoldColumn = (await resolveTaskLifecycleColumns(context.store, id))?.hold ?? "todo"; ``` Failing soft to `"todo"` when the workflow cannot be resolved, matching every other fallback in this file. Three call sites, all three converted. ## Revert proof | state | result | |---|---| | main today (classifier converted, target literal) | **2 failed** / 2 passed — `Invalid transition: 'checking' → 'todo'` | | with this fix | **4 passed** | ## The fixture is derived, not hand-built The renamed workflow is `BUILTIN_CODING_WORKFLOW_IR` with **only its column ids renamed**, so the sole difference between the two runs is vocabulary. Hand-building a graph tested the fixture's shape as much as the code — the IR validator rejects an undeclared back-edge, and once declared as `kind: "rework"` the transition table still did not match the default board's. The suite also asserts the rename landed (`checking` present, `in-review` absent), so a surviving literal cannot pass by accident. Real store, real persisted workflow, driven through the real `runTaskRetry` — not the predicate. A unit test of the classifier goes green on the half-fix; only driving the whole command surfaces the crash. ## Relationship to #2736 This replaces it. #2736's other contents (active-task count, near-duplicate filter, archived-lineage label, node-override guards, the missing-worktree classifier) are now redundant with #2728, so they are dropped rather than re-litigated. What survives is this fix, its test, and the **changeset for the published CLI** that #2728 did not include. I will close #2736 once this is reviewed. ## Verification - new PG suite **4 passed** · `task-retry.test.ts` **7 passed** across 2 files - `pnpm test:gate` — **10 / 158 / 487 / 71** · `pnpm lint` clean · CLI `tsc --noEmit` clean · `check:changesets` passes · `--strict` exits 0 --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
gsxdsm
|
72d42652e5 |
fleet: CLI surface 16 → 0 — 'active=0' on a busy board, and a retry gate that disagreed with the dashboard (#2728)
**Claimed on #2714 before starting.** `packages/cli/src/commands/task.ts` (8) + `dashboard.ts` (8) — **16 → 0**. ## The finding that matters: `active=0` on a busy board The same four-line aggregation appears **four times** in `dashboard.ts` — the TUI stats refresh, the serve summary, the status line, the agent-stats pass. Each compared the default lineage's two ids, so on a renamed board every one reported `active=0` while the board was plainly busy. **This is worse than an inert internal guard.** A recovery path that silently stops firing is invisible until something breaks. A stats line that says zero is **read, believed, and acted on** — *"nothing is running, so I can restart the engine."* The four copies are now one helper, and that is the other half of the fix: four independent copies of a lifecycle decision is how they drift, and these were identical **by accident, not by construction**. One IR read per *workflow*, asserted by call count — because the returned number is identical either way, so only counting the work can see it. ## The retry gate exists twice, and #2713 converted one of them After #2713, `POST /tasks/:id/retry` accepted a renamed board's stalled review card while `fn task retry` refused it with *"not in a retryable state"* — **one operator action answering differently depending on the surface**. The rule, stated at the site: **converting one copy of a duplicated gate creates a disagreement that is harder to diagnose than the original inert guard.** Grep the classifier by name before calling a lane converted. ## The rest - **`fn task set-node` / `clear-node`** rewrote the node override of an *actively executing* card, because the "is in progress" check never matched. That guard exists because the rewrite races the run. - **The duplicate-guard candidate filter** kept completed cards in the comparison set on a renamed board, so a new task was reported as a duplicate of work that had already landed — the opposite of useful. - **The duplicate-lineage `(archived)` marker** never printed, so the operator could not tell a live duplicate from a filed one. ## Two DELIBERATE-LITERALs, with reasons The board-render glyph compares `col` taken from the legacy `COLUMNS` enum **that loop iterates** — the literal matches its own receiver by construction. The real defect is already named in the code above it: a card in a renamed column **is not rendered at all**, which is the R8/U10 surface change, not this glyph. Converting it would hide that behind a trait lookup while the loop still cannot see the card. ## Pre-existing, not mine 5 failures in `commands/__tests__/task.test.ts` (GitHub import) **fail on `origin/main`** — verified by stashing this change and re-running. Someone owns that; it should not ride in here. ## Verification census **16 → 0** · `pnpm test:gate` **10 / 71** · `pnpm smoke:boot` **PASS** · `tsc -p packages/cli` clean · `pnpm lint` clean · `task-retry` 3/3 · 4 new cases with **2 red on revert**. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
gsxdsm
|
dbb53eebaa |
test(cli): four suites broke on mocks that predate the PG cutover and U11 (12 red → 0) (#2702)
## What was red
`project.test.ts` (8), `extension.test.ts` (2),
`project-lock-retry.test.ts` (1), `extension-workflow-tools.test.ts` (1)
— **12 failures** on clean main, all from full-suite shard 4/4. **No
product defect in any of them.**
### Cause 1 — an incomplete mock that the fail-soft catch disguised (9
cases)
`getTaskCounts` now **enriches** each row before counting, so a renamed
wip column still counts as running work (`FNXC:WorkflowLifecycleColumns
2026-07-30-12:20`). But `resolveWorkflowIrForTask` and
`enrichRunningAgentTaskShape` were absent from the `@fusion/core` mocks.
Calling an undefined function threw, and `getTaskCounts`'s
**deliberately fail-soft** catch converted that into `{ byColumn: {},
runningAgentCount: 0 }`.
So the failures presented as "task counts are zero" — indistinguishable
from a real counting bug. Worth flagging beyond this PR:
`project-lock-retry.test.ts` exists specifically to prove a transient
lock does *not* "silently masquerade as zero tasks" (FN-7731/FN-7740),
and an incomplete mock produced that exact symptom by a different route.
**That catch will hide the next real enrichment failure the same way.**
### Cause 2 — column-vocabulary drift (3 cases)
A column-less `createTask` used to land in `triage`; post-U11 it lands
in `todo`, the merged Planning column. Three assertions were pinned to
the old landing column, or to `COLUMN_LABELS` values **the product never
prints** — the stale mock said `"Triage"` / `"To Do"` where core says
`"Planning"` / `"Todo"`. A label assertion could pass against a string
that exists only in the mock. The mock's labels are now copied from the
real table.
## Measured
| Check | Result |
|---|---|
| the four files | 12 failed → **0** (107 passed) |
| whole `@runfusion/fusion` package | **122 of 126 files green, 1656
passed** |
| `pnpm test:gate` | **726 passed** |
| `pnpm lint`, CLI `tsc --noEmit` | clean |
**Census unaffected — 721 both with and against my diff**, verified by
reverting the four files and re-measuring rather than assuming test
files are unscanned. (I also caught that `--strict` *writes* the
baseline locally; that write is reverted, so this PR does not touch the
baseline.)
## Not touched
`task.test.ts`'s **5 failures**. That file is claimed by
`feature/tool-permission-gates`, and its 5 are exactly the ones shard
4/4 reports — so shard 4/4 goes 17 → 5, with the remainder belonging to
that PR.
## Two judgement calls recorded in-file rather than made silently
**The `extension-workflow-tools` guard is RE-PINNED, not deleted.** It
asserted "a task created on `builtin:coding` lands in `triage`" — a
byte-identical regression guard that fired because the change was
*intended* (U11's merge). Deleting it would remove the only check that
this landing column stays stable; leaving it pinned a column the product
no longer declares. Re-pinning to `todo` keeps it doing its job.
**The broad-listing assertion now names the group that actually leads
the output.** It asserted a *second* group header inside a listing that
truncates to a text budget. That only ever passed because `triage` sorts
before `todo` in `COLUMNS`, so its group fitted before truncation —
fixture ordering masquerading as a bounding assertion. Per-column
coverage of every group is still asserted by the three filtered cases,
which do not truncate. I also seeded those 8 tasks in an explicit third
column so that case still covers a three-way filter instead of
collapsing to two groups.
|
||
|
gsxdsm
|
50ebf3c543 |
TAKING cli/project.ts (fn project reported 0 running agents) + two test fixes — dashboard conversions WITHDRAWN in favour of #2626 and #2636 (#2631)
Three app-cluster conversions plus the evidence that they behave on a renamed AND a merged board. ## Per-file guard counts | file | before | after | note | |---|---|---|---| | `packages/cli/src/commands/project.ts` | 0 | 0 | not a comparison site — see below | | `packages/dashboard/app/components/TaskContextMenu.tsx` | 2 | 2 | **count does not move — deliberate, see below** | | `packages/dashboard/app/components/Column.tsx` | 2 | 2 | **count does not move — deliberate, see below** | **Read this before scoring the PR against the bar.** You said a claim that does not move your number is not done, so I am telling you up front that *this PR does not move it*, and why. Both dashboard conversions are **fallback-preserving**: ```ts const isIntakeColumn = columnFlags ? columnFlags.intake === true : column === "triage"; ``` The literal survives as the no-flags branch, so the grep still counts it. That is the shape the sibling code already uses (`isPreExecutionHoldColumn`, same file, converted earlier in the program), and dropping the fallback would make an unresolved-column render *lose* the affordance a second way. What changes is the **behaviour when flags exist** — which is what the mutation results below measure. If you want these to zero out the count, the fallback has to go, and that is a separate decision about whether an unresolved column should fail open or closed. Say the word and I will do it as a follow-up; I did not make that call unilaterally because it is not reversible from a rendering standpoint. `cli/project.ts` was never a comparison site at all — it fed **raw rows** to `isRunningAgentTaskShape`, so the helper's own internal legacy fallback kicked in and `fn project` reported **0 running agents** on any renamed board. Fixed by resolving the IR per task before counting. Nothing to subtract. ## Two of the three had a test that looked like coverage and was not - **`Column.tsx`** — the quick-create gate is `workflowMode || isIntakeColumn`. Every pre-existing intake case in `Column.test.tsx` *also* passes `workflowMode`, so the `||` short-circuited and **none of them ever reached the trait lookup**. Added cases that omit `workflowMode`, the only path where the conversion changes the answer. - **`TaskContextMenu.tsx`** — the intake suppression was asserted only for the legacy `triage` id, the one board shape where a broken conversion still returns the right answer. Mutation-verified rather than asserted: | mutation | result | |---|---| | `isIntakeColumn` → `column === "triage"` | **2 of 88 fail** (exactly the renamed and merged cases) | | menu suppression → `task.column !== "triage"` | **1 of 12 fail** | ## A pre-existing red I fixed on the way past `uses VALID_TRANSITIONS and in-review back-to-progress labels` was **already failing on origin/main**. #2521 correctly moved the "Back to X" label onto the host's `columnLabel` function; this file's stub is `(column) => column`, so the hardcoded `"Back to In Progress"` expectation was left over from the pre-#2521 hardcode and nothing had updated it. Matching the raw id would have made it pass while proving nothing, so instead that one case gets a display-like label function — the assertion now fails both if the "Back to" prefix regresses **and** if the label stops routing through `columnLabel`. Strengthened, not relaxed. Counts against completion criterion #2. ## Verification - `Column.test.tsx` + `TaskContextMenu.test.tsx`: **100 passed** - `tsc -p tsconfig.app.json` (the root config does not cover `app/`) and the CLI typecheck: clean - `pnpm test:gate`: green 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
gsxdsm
|
eb874f3da3 |
convert(cli/commands/task.ts): triage guard 1 → 0 (+ a live main regression in the lifecycle E2E release path) (#2627)
**Batched push, gate open.** One conversion; the two E2E commits are held back and the reason is below — it is the more important half of this PR body. ## Conversion | File | triage column comparisons before | after | |---|---|---| | `packages/cli/src/commands/task.ts` | **1** | **0** | `pnpm test:gate` green, `pnpm lint` clean. All four non-terminal columns rendered the **same** glyph, so the four id comparisons were only ever asking "is this column terminal?". Naming `triage` made it a lifecycle-vocabulary site for no behavioural reason — the merged Planning column dropped that id, so the comparison silently stopped matching while the output stayed correct **by accident** (the fallthrough gave it the same glyph). Behaviour-identical **only** because the loop iterates the legacy `COLUMNS` constant (`types/board.ts:27` — exactly the six ids), so `col` can never be a custom id. Stated because the forms **diverge** outside that set: the old chain fell through to the terminal glyph for an unrecognised id, the new form returns the non-terminal one. If this ever iterates workflow-resolved columns that difference becomes live, and the right answer is a trait lookup, not this. **Deeper bug deliberately untouched, for U12:** because the loop iterates the legacy enum, a card in a workflow-renamed column **is not rendered at all**. That is R8's surface change, far bigger than this glyph. *(Note: this file is not on the 45-guard list, so it will not move your count. Flagging so the numbers reconcile.)* --- ## ⚠️ Live regression on origin/main — the lifecycle E2E release path While rebasing to push, the flagship lifecycle E2E went red. **I verified it on `origin/main` alone, with none of my commits: 2 failed / 18 passed.** ``` scenario 1 — DEFAULT vocabulary → AssertionError: expected [] to include 'FN-E2E-1' (r.sweep.released is EMPTY) scenario 2 — RENAMED vocabulary → audit trail differential broken: renamed produced [{end},{review}], default produced [] ``` Both are pre-existing tests I have never touched. **The capacity release sweep is releasing nothing.** **Likely cause, from reading rather than bisecting** — so treat it as a lead, not a verdict: `moves.ts:1059` now resolves a capacity pool id and enforces `enforcePooledColumnCapacity` **inside the move transaction** (#2488 "bind the in-transaction capacity gate", made user-visible by #2499 "make the capacity gate actually bind for real projects"). The E2E drives with `settings = { experimentalFeatures: { workflowGraphExecutor: true } }` — **no `maxConcurrent`** — while the fixture's wip column declares `{ trait: "wip", config: { limitSetting: "maxConcurrent", countPending: true } }`. If the resolved limit is finite and the pooled count meets it, the hold→wip move is rejected on capacity and the sweep correctly reports nothing released. If that is right, it is a **test-harness/production interaction, not a product break** — but it means the program's primary end-to-end evidence for the capacity boundary is currently inert on main, which matters for completion criterion 3. It needs the capacity worker's eyes, since #2488/#2499 are theirs and I would be guessing at the intended pool/limit contract. ## Why my two E2E commits are held They add scenario 3 (merged intake+hold board) and scenario 6 (REVISE → rework), both of which **depend on the same release leg**. On current main they fail for main's reason, taking the file from 2 failures to 4. Pushing them would add red to the count you are tracking and obscure whose regression it is. Both are complete, mutation-attributed, and green against the commit I wrote them on: | Scenario | Proves | Mutation that fails it | |---|---|---| | 3 — merged intake+hold | capacity release works from a dual-role column | `isHeldTask` treating intake/hold as exclusive → exactly its 2 tests | | 6 — REVISE → rework | `InReview → InProgress` on renamed *and* merged boards | disabling rework re-entry → exactly its 2 tests | They go out in the next batch the moment the release path is green. ## Also not shipped, twice attempted, deleted both times Safeguard 2 (`autoMerge:false` terminal-until-human) still has **no** graph-level E2E. Attempt 1 passed and then survived mutating `merge-gate` to ignore `task.autoMerge` — the card was parking on the review column's `merge-blocker` trait, not the gate. Attempt 2 removed that trait to isolate the gate, and then the *control* case parked too, so the flag still was not the discriminator. A fixture that can isolate it needs a merge path mirroring the builtin (`merge-gate → merge node → end`) rather than a direct edge to `end` — a real redesign, not a speculative edit. The enforcement that actually holds today is `allowInReviewMergeProcessing` in `project-engine` (unit-mutation verified, NEW=9; gated via #2526). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
gsxdsm
|
d5f1ce7abd |
U11 [writes]: stop CREATING cards into a column the workflow no longer declares (9 -> 0, engine+cli) (#2603)
**Taking: `engine/triage.ts`, `engine/pr-comment-handler.ts`, `engine/eval-followups.ts`, `cli/commands/task.ts`, `cli/extension.ts`** (write class — no collision with the comparison backlog). ## A class the census does not count The 48-guard work list tracks `=== "triage"` **comparisons**. These are `column: "triage"` **writes** — and post-#2515 every one creates a card directly into the state STALL 3 was about, except **manufactured continuously** rather than left behind by the upgrade. ## Why they bite `createTaskImpl` resolves the column as: ```ts column: input.column || options?.resolvedEntryColumn || fallbackIntakeColumn || "triage" ``` `input.column` **wins**, so an explicit `column: "triage"` overrides the workflow's resolved intake column entirely. `store-create-intake-column.test.ts` already pins that a create with **no** column lands in the default workflow's intake (now `todo`) — these callers opted out of it. The sharpest is `triage.ts`'s `fn_task_create` agent tool: it passed `workflowId: params.workflow_id` **and** `column: "triage"` in the same call. The caller chose a workflow and the column ignored it — a Coding (Ideas) create landed in `triage` instead of `ideas`. ## Counts **Comparison guards: unchanged by this PR.** This is the write class; conflating the two would misreport convergence toward the zero bar. | file | `column: "triage"` writes before | after | |---|---:|---:| | `packages/engine/src/triage.ts` | 1 | **0** | | `packages/engine/src/pr-comment-handler.ts` | 1 | **0** | | `packages/engine/src/eval-followups.ts` | 1 | **0** | | `packages/cli/src/commands/task.ts` | 3 | **0** | | `packages/cli/src/extension.ts` | 3 | **0** | | **total** | **9** | **0** | ## A test that pinned the defect `pr-comment-handler.test.ts` asserted `column: "triage"` in the createTask call — so it would have **failed the fix and passed the bug**. Rewritten to assert the invariant (the caller passes no column, so the workflow's intake wins) plus an explicit `Object.hasOwn(arg, "column") === false`, which is what actually catches a reintroduction. ## Interaction with #2591 My merged #2591 rescues these cards once created — they sit on a legacy planner id their workflow doesn't declare and are still in planning stage. So this isn't a *visible* stall today; the rescue absorbs it. **That's the reason to fix it rather than leave it:** a self-healing path silently absorbing a steady stream of malformed creates is exactly how the underlying defect stays invisible. ## Deliberately not touched - `{ id: "start", kind: "start", column: "triage" }` in the builtin coding / PR / lead-generation IRs — workflow-internal **node declarations** for workflows that still legitimately declare a `triage` column, not lifecycle writes. - Left for their owners: `core/task-store/project-store-ops.ts:210`, `core/task-store/update-task-deps.ts:111` (main worker), `dashboard/src/routes/register-gitlab.ts:108` (u12). Same defect, same one-line shape. ## Verification - 304 engine/CLI tests green across the affected suites - merge gate green (482 + 132 + 10), engine + CLI tsc clean, lint clean No changeset: `@fusion/engine` and `@fusion/core` are private; the CLI change is a bug fix with no user-facing API change — happy to add one if you'd rather it appear in release notes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) |
||
|
Phil Larson
|
9a8fc409ff |
fix: persist manual task pauses (#2536)
## Summary - persist an explicit `userPaused` latch when operators pause tasks through CLI, MCP, dashboard task routes, or mission stop - keep automatic/internal pauses distinct (`userPaused` remains false unless explicitly requested) - clear the latch on unpause - route the flag through in-memory and PostgreSQL task stores - add contract coverage across core, CLI, MCP, dashboard task routes, and mission stop ## Why A manually paused task could lose the reason for its pause across dashboard/runtime restart. Startup recovery then treated it like an internally interrupted task and reclaimed it, restarting automation against the operator’s intent. Manual pauses must survive restart and remain non-runnable until explicitly unpaused. ## Verification - core pause durability tests: 2 passed - CLI task/extension tests: 150 passed; PostgreSQL integration lane remains active in CI - dashboard route tests: 261 passed - `@fusion/core`, `@runfusion/fusion`, and `@fusion/dashboard` typechecks passed - full workspace build passed with pnpm 10.33.0 - changeset validation and `git diff --check` passed - live aggregate runtime verification also confirmed `paused=true,userPaused=true` survived a normal dashboard restart with zero active tasks <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Bug Fixes** - Manual task pauses now persist across application restarts and recovery. - Pauses initiated via the CLI, dashboard, MCP tools, and mission stop controls are recorded as explicit user actions. - Automatically paused tasks remain eligible for recovery. - Unpausing clears the durable manual-pause state. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
gsxdsm
|
4158cf1ab7 |
Phase A: workflow-owned lifecycle foundation (U1, U2, U3) (#2467)
Phase A (Foundation) of
`docs/plans/2026-07-26-001-refactor-workflow-owned-lifecycle-plan.md`.
Three units, one commit each. No operator-visible behavior change.
## U1 — Lifecycle-column resolution seam
`resolveLifecycleColumns(ir)` returns `{ intake, hold, wip, review,
complete, archived }` — the first column carrying each trait,
`undefined` for a role no column carries.
`resolveTaskLifecycleColumns(store, taskId, cache?)` is the store-aware
form; the cache is caller-owned so a sweep reads one IR per workflow
rather than one per card.
A v1/column-less IR resolves to `undefined` for the **whole struct**
rather than a struct of undefined roles. A caller must be able to
distinguish "this workflow declares no hold column" (a real shape to
honor) from "no column vocabulary at all" (skip and log) — only the
second licenses conservative fallback.
Nothing consumes the seam yet; Phases B–D convert the ~207 hardcoded
column literals onto it.
## U2 — Delete the pre-cutover parity machinery (delete-only)
**`workflow-columns-settings.ts`** — `isWorkflowColumnsEnabled` had the
body `return true`. Six live call sites branched on it, so every
flag-OFF arm was dead code that read as a supported configuration.
Deleted; surviving side inlined at self-healing's transitionPending
sweep, the scheduler's per-column capacity diagnostic, merge-trait's
policy resolver, the board-workflows payload, two task-workflow routes,
and the CLI TUI's column enrichment.
**`workflow-parity.ts`** — asserted the default workflow's adjacency
*equals* the legacy `VALID_TRANSITIONS`. U11 deliberately breaks that
equality by merging Todo into Planning, so this is not a stale assertion
to update; it is a contract against the target state. Its emitter
(`workflow-parity-observer.ts`) is already a tombstone, so
`getWorkflowParitySummary` and `computeWorkflowColumnsGraduationReport`
aggregated run-audit rows nothing writes and had no caller outside
`TaskStore`. Both store methods go with it.
`flagEnabled` stays on the board-workflows **wire** as a constant `true`
— shipped dashboard clients still branch on it, and changing the
response shape is not a deletion. U10 retires the field once no client
reads it.
The `legacy-tombstones` ratchet is extended to both files plus seven
symbols, each with the reason it is gone.
### ⚠️ Finding: the third listed deletion was NOT dead
The plan also lists "the flag-off inline move path" in
`task-store/moves.ts`. It is **not** deleted, per U2's execution note
("any behavior change found while removing a branch means the branch was
not dead").
That path is gated on `isWorkflowColumnsCompatibilityFlagEnabled`
(`store.ts:38`) — a **different** function from the always-true public
helper. It reads the raw `experimentalFeatures.workflowColumns` setting,
which nothing in production sets (`settings-schema.ts:396` — "no default
flags are emitted"; zero non-test writers; the operator's own
`~/.fusion/settings.json` has no such key). So `useWorkflow` is false
for effectively every real project: the flag-OFF inline side effects are
the **live** default move path and the flag-ON `default-workflow-hooks`
path is the dead one. The code says so itself at `moves.ts:638`.
Deleting that branch would swap every project onto an untravelled code
path — a behavior change, not a deletion.
**Carry this into Phases B and C, stated plainly so the plan's error is
not repeated:**
> **The inline move path in `moves.ts` is LIVE.
`default-workflow-hooks.ts` (the trait-hook path) is DEAD.** KTD-6
asserted the inverse. Until the convergence unit lands, **nothing may
assume trait hooks run** — a guard, sweep, or subscriber written against
`applyDefaultWorkflowMoveEffects` would never fire in production and
would still pass its tests.
Convergence is **not** attempted here. It is its own unit (Phase A2)
with a proper equivalence proof, per operator decision.
### U3's emit point is on the LIVE path — the seam is not born dead
Worth stating explicitly because it is the failure mode that would make
every later subscriber silently never fire: the `TaskTransitioned` emit
is **not** inside the `if (useWorkflow)` branch. That block closes at
`moves.ts:1212`; the emit sits at `:1214`, beside the existing
`store.emit("task:moved", …)`, on the unconditional post-commit path. It
therefore fires on **both** the live inline path and the dead hooks
path, and the convergence unit inherits the obligation to keep it firing
on whichever path survives — same events, same order, same payloads.
The graph-side emitters (`NodeEntered`, `RunSuspended`) carry the same
risk from a different direction: the bus refuses an invalid payload
*silently* by design, so an emitter regression would stop the event with
no test failure. They are asserted end-to-end through the real bus —
"did a subscriber actually receive it", not "was emit called" — because
a spy passes on a refused payload. The `moveTaskInternalImpl` emit does
**not** yet have that end-to-end assertion against a real store move;
that proof belongs to the convergence unit, which has to build the
both-paths fixture anyway.
## U3 — Post-commit event seam with a transactional outbox
**The bus is not a queue, not a transaction participant, and not a
delivery guarantee.** Durable follow-on work uses the transactional
outbox — a `workflow_work_items` row written *inside* the transition
transaction (the shape `createCompletionHandoffWorkflowWork` already
uses). "Emit after commit, let a subscriber enqueue the work" has a
crash window where a process dies between commit and subscriber, leaving
no event *and* no work-item row, so required work is skipped permanently
with nothing to recover from. Post-commit subscribers therefore carry
only losable reactions.
Emission is consequently lossy and isolated by design: a throwing or
rejecting subscriber is caught and logged, cannot roll back the
transition, and cannot stop the others. Deliveries append to one serial
chain, so two transitions on a task deliver in commit order.
The ids/outcomes-only rule is **mechanised, not documented** —
run-audit's equivalent lives only in prose and has been violated
repeatedly. A payload carrying an object body or a prose string is
refused at the emit boundary and never reaches a subscriber or log sink.
It degrades rather than throws: the emitter is post-commit, so a shape
bug must not become a lifecycle failure.
Emit points: `TaskTransitioned` from the single post-commit point in
`moveTaskInternalImpl`; `NodeEntered` and `RunSuspended` from the graph
column boundary, the latter *after* the durable continuation is
persisted so an observed suspension implies a resumable run.
`registerWorkflowEventSubscribers` (engine) is empty on purpose —
U7/U8/U10 move real reactions onto it, each with the characterization
test proving the reaction was non-authoritative first.
## Verification
- `pnpm test:gate` — green (2/10, 16/299, 1/71).
- `pnpm lint`, `pnpm build`, `tsc --noEmit` on core and engine — green.
- U1: 20 tests in `workflow-lifecycle-traits.test.ts`, including the
fully-renamed-workflow case (fails if the resolver falls back to a
literal) and a shared-cache read-count assertion.
- U2: `legacy-tombstones.test.ts` green with the extended ratchet;
`board-workflows`, `merge-trait`, `workflow-graph-executor-parity`, and
move-hook suites green with no expectation edits.
- U3: 20 bus-invariant unit tests (isolation, ordering, the allowed-key
and required-key halves of the ids-only rule, lossiness) plus 3
end-to-end emitter-delivery tests; 5 outbox tests against a **real
PostgreSQL** work-item table (crash survival, rollback, at-least-once
redelivery on lease expiry, idempotent handler → one effect,
dropped-subscriber vs. durable work). A hand-written fake of the lease
predicate would only prove the fake redelivers.
**Not verified:** the `moveTaskInternalImpl` emit is confirmed on the
unconditional post-commit path by structure and by the surrounding
tests, but is *not* yet asserted end-to-end against a real store move on
both flag settings — that is Phase A2's fixture. The engine subscriber
registry ships empty by design, so no production subscriber exercises
the bus end-to-end yet. `settings-defaults.test.ts` has one pre-existing
failure on `main` (a logger-prefix mismatch in the
`mergeIntegrationWorktree=cwd-main` warning) — confirmed present on a
clean tree, unrelated to this branch.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Workflow lifecycle columns are now derived from workflow definitions,
supporting renamed and custom workflows.
* Added post-commit lifecycle events for task transitions, node entry,
and run suspend/resume with validated payloads.
* Follow-on processing for lifecycle emissions is now more robust
(rollback-safe, at-least-once delivery, idempotent handling).
* **Bug Fixes**
* Workflow board responses, task enrichment, and promotion no longer
depend on workflow-columns feature-flag gating.
* Subscriber failures no longer impact committed workflow transitions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
|
||
|
gsxdsm
|
3f33cb000f |
feat: per-origin workflow selection + feedback-derived refinement titles
Two task origins had no workflow picker in front of the operator and always inherited the project default: `fn task create` (CLI + the `fn_task_create` agent tool) and refinement tasks. Add a Project General setting for each, where blank/unset means "Selected workflow" (the operator's current Board lane, falling back to the project default) and a concrete id pins that origin. Because the Board lane lives in browser localStorage, non-browser callers could not resolve "Selected workflow" at all. `boardSelectedWorkflowId` mirrors the lane into project settings so they can. Note this makes the mirrored lane project-scoped: two operators on one project share it, last switch wins. The Board never reads it back, so the only effect is which workflow a newly created task inherits. Resolution is `TaskStore.resolveOriginWorkflowOverrideId(origin)`: pinned setting -> mirrored lane -> `undefined` to inherit each caller's existing default-workflow path unchanged. A deleted or fragment id degrades to inherit rather than throwing, so a stale settings value can never break task creation. An explicit `workflow_id` argument to `fn_task_create` still wins. Separately, a refinement is now titled by the operator's own feedback via the shared `deriveFallbackTaskTitle`, not `Refinement: <parent title>`. Ten refinements of one task previously rendered ten identical titles, so the board could not tell them apart while the text saying what each one asked for sat in the description. Provenance moves to a `Refines <id>` card chip alongside the existing detail-view parent link and dependency edge. Verified: merge gate (299 tests), lint, full build, and typecheck for core, CLI, and dashboard all pass. New coverage: origin resolution across both origins and the full precedence ladder, the two settings pickers, the board-lane mirror, refinement titling (including sibling distinctness), and the card chip. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |