implementation-workflow: re-run the format check itself instead of trusting the implementer's summary #460

New issue

Open

opened 2026-08-27 06:39:18 +00:00 by mph · 1 comment

mph commented

2026-08-27 06:39:18 +00:00

Owner

From MEDECA-378 triage.

The Phase 2 implementer reported 'scalafmtCheckAll - clean' in its completion summary. The style review disputed it, and a direct check confirmed the reviewer: scalafmt --config .scalafmt.conf --test over the 18 changed .scala files exited 'error: --test failed', with unformatted hunks in five files, all on lines Phase 2 itself had added.

Root cause is mundane: the agent ran the check, then kept editing. A formatting check reported by an agent that also edited code afterwards proves nothing about the final tree.

Proposal: the verification step should re-run the format check itself against the final tree, the same way it already re-derives the changed-file list from git status, rather than reading the claim out of the implementer's summary.

Second-order finding from the same issue, worth knowing when implementing the above: in this project the root scalafmtAll / scalafmtCheckAll tasks do not aggregate every module's sources, so their success is not evidence that a given changed file is formatted. A per-file check over the changed-file list is the reliable form. (The aggregation gap itself is filed project-side as MEDECA-442.)

Type: bug
Filed from: /home/mph/Devel/projects/medeca-modul-poptavky-MEDECA-378 on branch MEDECA-378

From MEDECA-378 triage. The Phase 2 implementer reported 'scalafmtCheckAll - clean' in its completion summary. The style review disputed it, and a direct check confirmed the reviewer: scalafmt --config .scalafmt.conf --test over the 18 changed .scala files exited 'error: --test failed', with unformatted hunks in five files, all on lines Phase 2 itself had added. Root cause is mundane: the agent ran the check, then kept editing. A formatting check reported by an agent that also edited code afterwards proves nothing about the final tree. Proposal: the verification step should re-run the format check itself against the final tree, the same way it already re-derives the changed-file list from git status, rather than reading the claim out of the implementer's summary. Second-order finding from the same issue, worth knowing when implementing the above: in this project the root scalafmtAll / scalafmtCheckAll tasks do not aggregate every module's sources, so their success is not evidence that a given changed file is formatted. A per-file check over the changed-file list is the reliable form. (The aggregation gap itself is filed project-side as MEDECA-442.) --- **Type:** bug **Filed from:** `/home/mph/Devel/projects/medeca-modul-poptavky-MEDECA-378` on branch `MEDECA-378`

claude commented

2026-10-16 00:40:58 +00:00

Member

Intake: needs-input

1. Which repository should own the change: dev-docs, or iw-cli with a new command?

The issue asks the workflow's verification step to run the format check again on the final tree. That step is in skills/ag-implementation-workflow/SKILL.md and in its dx- and wf- copies. These files are in dev-docs, not in iw-cli. In iw-cli the only format check is the check of iw-cli's own code (core/model/ScalafmtGate.scala). No iw-cli command does a per-file format check of a consumer project.

if ! porcelain=$(git status --porcelain --untracked-files=all); then
(https://code.iterative.works/iterative-works/dev-docs/src/branch/main/skills/ag-implementation-workflow/SKILL.md#L428)

a) Move the issue to dev-docs. The three workflow skills run scalafmt again on the changed files that they get from git status. iw-cli does not change, and this issue closes here.
b) Keep it in iw-cli as a new command. iw-cli gets a command that checks the format of each changed file, and the skills then call it. This makes two changes in two repositories, and iw-cli must learn how each consumer project formats its code.

Recommended: a): The issue names only the skill's verification step, and that step is all in dev-docs.

Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

Intake: needs-input ### 1. Which repository should own the change: dev-docs, or iw-cli with a new command? The issue asks the workflow's verification step to run the format check again on the final tree. That step is in `skills/ag-implementation-workflow/SKILL.md` and in its dx- and wf- copies. These files are in dev-docs, not in iw-cli. In iw-cli the only format check is the check of iw-cli's own code (`core/model/ScalafmtGate.scala`). No iw-cli command does a per-file format check of a consumer project. > `if ! porcelain=$(git status --porcelain --untracked-files=all); then` > (https://code.iterative.works/iterative-works/dev-docs/src/branch/main/skills/ag-implementation-workflow/SKILL.md#L428) - **a) Move the issue to dev-docs.** The three workflow skills run scalafmt again on the changed files that they get from git status. iw-cli does not change, and this issue closes here. - **b) Keep it in iw-cli as a new command.** iw-cli gets a command that checks the format of each changed file, and the skills then call it. This makes two changes in two repositories, and iw-cli must learn how each consumer project formats its code. **Recommended: a)**: The issue names only the skill's verification step, and that step is all in dev-docs. Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

claude added the

needs-input

label

2026-10-16 00:40:58 +00:00