Skip to content

fix(smithy): sf task merge honors workspace merge.targetBranch config (#63)#4

Open
komoreka wants to merge 1 commit into
masterfrom
fix/merge-target-branch-config-fallback
Open

fix(smithy): sf task merge honors workspace merge.targetBranch config (#63)#4
komoreka wants to merge 1 commit into
masterfrom
fix/merge-target-branch-config-fallback

Conversation

@komoreka
Copy link
Copy Markdown
Owner

@komoreka komoreka commented May 7, 2026

Fork-side staging PR for upstream issue stoneforge-ai#63. Will hold for live testing before opening upstream.

Summary

merge.targetBranch in .stoneforge/config.yaml was previously only consumed by prompt-builders (sessions, steward scheduler, dispatch daemon) to populate WorkflowPresetContext for agent system prompts. The actual git tooling in sf task CLI commands never loaded it. So setting merge.target_branch: dev told agents about the target in their prompts, but the merge operations themselves still defaulted to git origin/HEAD (typically main).

Resolution across all merge-related paths is now:

task.targetBranch → config.merge.targetBranch → git origin/HEAD → main

This unblocks the steward-merge case from stoneforge-ai#63: stewards cannot own a targetBranch field by the agent-type contract, so a workspace-level config was always meant to be their fallback. Now it actually works.

Files

  • packages/smithy/src/cli/commands/task.ts — adds loadConfigTargetBranch() helper, threads it into the merge handler, sync handler, and update --status merged verify path
  • packages/smithy/src/services/task-assignment-service.ts — same fallback in the MR-creation path used by sf task complete
  • packages/smithy/src/cli/commands/task-target-branch.bun.test.ts — 6 unit tests for the helper covering missing config, null values, empty strings, alternate names

Test plan

  • bun test src/cli/commands/task-target-branch.bun.test.ts — 6/6 pass
  • bun test src (full smithy suite) — 1574 pass, 0 fail, 19 skip
  • turbo typecheck --filter=@stoneforge/smithy — clean
  • pnpm build — clean
  • Live smoke test against a real workspace with merge.target_branch: dev set in config (next step before upstream PR)

Out of scope

The deeper director→task propagation issue Adam mentioned (currently only fires during assignTaskToWorker) is left as a follow-up. This PR closes the user-visible symptom of stoneforge-ai#63 by making the config workaround actually work end-to-end.

The `merge.targetBranch` value in `.stoneforge/config.yaml` was previously
only consumed by prompt-builders (sessions, steward scheduler, dispatch
daemon) to populate WorkflowPresetContext for agent system prompts. The
actual git tooling in the `sf task` CLI commands never loaded it, so
setting `merge.target_branch: dev` told agents about the target in their
prompts but the merge operations themselves still defaulted to git
origin/HEAD (typically `main`).

Resolution chain across all merge-related paths is now:
  task.targetBranch → config.merge.targetBranch → git origin/HEAD → main

Wired in:
- packages/smithy/src/cli/commands/task.ts (merge handler, sync handler,
  update --status merged verify path)
- packages/smithy/src/services/task-assignment-service.ts (MR-creation
  path used by sf task complete)

A new exported `loadConfigTargetBranch()` helper centralises the config
read with safe handling of missing config, missing merge block, null
values, and empty strings. Six unit tests in task-target-branch.bun.test.ts
cover those cases.

Stewards (which cannot own a targetBranch field per the agent type
contract) finally have a config-only path to set a project-wide target.

Refs stoneforge-ai#63.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant