Merge logic isn't applying a strict filter on which files were altered/added and instead commits all uncommitted code

[a4xrbj1]

Steps to reproduce

1. Make a local edit manually, eg. adding a comment
2. When Overstory is working on this repo, it will commit everything, not apply a filter to exclude files that were created/updated manually.

Expected behavior

Should apply a filter and only commit the files that overstory itself touched for that specific task.

At the minimum, I'd expect it to check with the human if it detects and other uncommitted changes but not commit them silently without even mentioning them in the commit itself.

Actual behavior

Commit everything

overstory version

0.8.6

Bun version

1.3.10

Operating system

MacOS 26.3.1

[lucabarak]

Looked into this — the merge resolver (src/merge/resolver.ts) is actually properly scoped:

1. Os-eco state files (.overstory/, .seeds/, .mulch/, etc.) → auto-committed separately with a chore: sync os-eco runtime state message
2. Remaining dirty tracked files → stashed before merge, popped after (never committed)
3. Untracked files → only committed if they overlap with files the agent branch modified

So ov merge itself shouldn't be silently committing your manual edits.

The more likely culprit is the agent itself (Claude Code, Codex, etc.) running git add . or git add -A as part of its normal workflow. Agents have git add/git commit whitelisted in guard rules (src/agents/guard-rules.ts, src/agents/hooks-deployer.ts) — but there's no mechanism to scope the agent's git add to only files it touched. If the agent runs in the same worktree where you have manual edits, its git add . would scoop those up.

A few possible mitigations:

• Worktree isolation (already the default for builders) — agents work in separate worktrees, so manual edits in the canonical dir aren't affected. Is this happening with an agent running directly in the main worktree (coordinator/lead)?
• Pre-commit hook: a hook that checks staged files against a manifest of "agent-touched files" and warns/blocks on unexpected additions
• Git add scoping: teach the agent to use git add <specific-files> instead of git add . — this could be enforced via guard rules (block git add . / git add -A, only allow git add <path>)

Could you share more about the setup? Specifically:

1. Which agent capability was running (coordinator, lead, builder)?
2. Was it in the main worktree or an agent worktree?
3. Was the commit made by the agent directly, or by ov merge?

That would help narrow down the exact code path.

[a4xrbj1]

Q1: Which agent capability was running (coordinator, lead, builder)?

A1: Coordinator

Q2: Was it in the main worktree or an agent worktree?

A2: The "main" worktree would be the parent directory where there's no code, just where the coordinator runs. It was in a subdirectory below the parent directory. Coordinator spilled a lead agent there, which spilled a builder.

Q3: Was the commit made by the agent directly, or by ov merge?

A3: no idea, I'm not 100% sure how this works. Does the lead agent make the merge or is the coordinator doing the merge? The "ov dashboard" shows the merge to be ready when the coordinator picks it up. I lack this detail information.

[lucabarak]

Thanks for the details — that narrows it down.

To answer your Q3: the coordinator runs ov merge, not the lead or builder. The coordinator picks up the merge when the lead signals merge_ready.

Looking at the merge resolver code (src/merge/resolver.ts), the flow before merging is:

1. Auto-commit os-eco state files (.seeds/, .overstory/, .greenhouse/, .mulch/, .canopy/, .claude/, CLAUDE.md) with a "chore: sync os-eco runtime state" message
2. Stash any remaining dirty tracked files
3. Merge the agent branch
4. stash pop in the finally block

So regular source file edits should be stashed and restored — not committed. But if your manual edit was to a file that matches the os-eco state patterns (anything under .seeds/, .overstory/, .claude/, .greenhouse/, etc., or CLAUDE.md itself), it would get auto-committed in step 1.

Builders always work in isolated worktrees, so they can't stage files from your main working tree.

Could you share:

1. git show <the-commit-hash> --stat — to see exactly which files ended up in the commit
2. Was your manual edit to a source file, or to something like CLAUDE.md / a file under .claude/?

That'll confirm whether it's the auto-commit path or something else.

[a4xrbj1]

I'm sorry, I can't even see when I opened this issue (says "last week". I don't remember exactly which of the several repo's and I have done probably close to a high three digit number of commits. In short, I don't know and I won't be able to find.

Just to add to your reply, it wasn't any file that matches overstories pattern.

I also noticed that it once again didn't commit an UPDATE to a .seed/issues.jsonl today twice! So the problem with at least one file under the .seed folder not being committed is still unsolved.

[Koroqe]

Scoping each agent to a specific feature slice with explicit file boundaries fixed this for me. No broad staging — the agent only commits files within its designated scope, and a review gate checks the diff against expected changes before merge. https://github.com/Koroqe/claude-code-sdlc uses this pattern with bounded implementation slices.

[lucabarak]

Since the original commit can't be tracked down, we probably won't be able to root-cause that one further. @Koroqe's scoped boundaries approach is a solid mitigation going forward.

On the .seeds/issues.jsonl not being committed — that's worth looking at separately. The merge resolver's autoCommitStateFiles() is a one-shot that runs before the merge starts: it snapshots whatever .seeds/, .overstory/, .mulch/, etc. files are dirty at that moment and commits them as chore: sync os-eco runtime state. If the agent writes to .seeds/issues.jsonl after that auto-commit step (e.g., during or after the merge itself), the update would be left uncommitted.

Next time it happens, could you check git status right after the coordinator finishes? If .seeds/issues.jsonl shows as modified, that confirms the timing theory — the write happened after the auto-commit window.