get2knowio / get2knowio/maverick

Refuel fixer invents work units instead of closing the reported gap

Open
#167 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
4
Forks
0
Avg merge
17h 37m
Merged PRs (30d)
7

Description

Found during the #135 subtask 5 live walkthrough.

When `request_fix` hands the decomposer a validation gap, the fixer
responds by **adding new work units** rather than amending existing ones
to close the gap. Measured on the sample project, same plan each time:

| run | gap reported | rounds | work units |
| --- | --- | --- | --- |
| pre-fix | 16 blank refs | 3 | 7 -> 18 |
| after the SC-ref fix | 1 real ref (`SC-015`) | 3 | 7 -> **33** (+12, +8, +6) |

The second row is the interesting one. Giving the fixer a *precise*
target made it try harder and produce more units, not fewer. The units
were largely duplicates of existing ones — e.g. `001-project-setup`
alongside `001-pyproject-scaffold`, both `sequence: 1`, both
`depends-on: []`, both "initialize pyproject.toml + package skeleton +
test dirs".

Those duplicates become beads, so `fly` would implement the same work
twice.

## Root cause vs. this issue

The gap it was chasing (`SC-015: total source lines stay at or below
500`) is a cross-cutting constraint no work unit can carry. `ceff42a`
makes untraced criteria advisory, so the fixer is no longer invoked for
them at all — which removes the observed trigger.

What is **not** fixed is the fixer's behaviour itself. It is still
reachable via the paths that legitimately fail validation (overloaded
work units, dangling `depends_on`, cycles), and there is no evidence it
behaves better there. A fixer asked to close a coverage gap should be
adding an acceptance criterion with the right `trace_ref` to an existing
unit, or splitting one unit — not appending a dozen new ones.

## Suggested work

* Constrain the fix prompt: state explicitly that new work units are for
splitting, and that coverage gaps are closed by amending acceptance
criteria.
* Consider rejecting a fix payload whose `work_units` delta is
implausible for the reported gap, rather than merging it blind
(`_merge_to_specs` currently appends whatever comes back).
* Add a duplicate check across work units before bead creation.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Contributor guide

Open the contributing guide

Research direction

Start by tracing the request_fix path through the fixer and decomposer, then inspect _merge_to_specs, which currently appends returned work units. Reproduce the reported duplicate-unit behavior against the sample project and review the existing validation-failure paths. Done means coverage gaps amend or split existing work appropriately, implausible deltas are handled safely, and duplicate work cannot reach bead creation.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.