Skip to content

Keep "stop" only for build-time generation with no Bazel mapping (for discussion) - #55

Open
anakanemison wants to merge 1 commit into
mschaller/d2-non-interactive-scope-checkfrom
mschaller/d3-narrow-the-stop
Open

anakanemison wants to merge 1 commit into
mschaller/d2-non-interactive-scope-checkfrom
mschaller/d3-narrow-the-stop

Conversation

@anakanemison

Copy link
Copy Markdown

Part 20 of 23 of a stacked series (tracking issue: #35). Based on D2-non-interactive-scope-check, the previous part: review and merge that first.

Kind: discussion. Lab proposal: P9.

What the migration runs showed

The stop was ignored in 13 of 13 applicable runs, for codegen with a direct Bazel mapping such as bison and flex. Narrowed, it fired where it should: yugabyte-db's PostgreSQL sub-build (runs 090, 091).

The change

The scope list tells the agent to stop at any build-time custom command or
generated code. In non-interactive runs the stop is not honored, and where
the codegen maps directly onto Bazel the agents migrated it correctly, so
the instruction bought nothing; where it does not map, it is the right
call and deserves a sharper description.

Observed in any2bazel-lab: every
skill-guided pono migration (five runs) went through the stop and migrated
its bison/flex genrules and stamped version.h, with parser and lexer
outputs identical to the reference in all of them; the unguided run did
the same, but silently downgraded bison below the declared minimum. The one
honored stop (YugabyteDB) was right: the blocker was a PostgreSQL fork
built by autotools outside the CMake model and linked into the servers,
and the unguided migration that went ahead produced servers that abort at
startup for that reason.

The scope list now keeps "stop" only for build-time generation with no
clear Bazel mapping, described as a sub-build the CMake model does not
show whose outputs the binaries link, in SKILL.md and in
docs/REFERENCE-cmake.md's scope traps. Without an answer, that is still a
stop (the non-interactive fallback earlier in this series says so). A short
paragraph under "Create initial BUILD.bazel files" says codegen that maps to a genrule over a host tool or to a ruleset is the
agent's to migrate, with the project's declared generator version; the
byte comparison of its outputs is the one the convergence-boundary list
already requires. The frontmatter description still says "no
codegen/custom commands"; it is trigger text, so it is unchanged.

In the lab's later runs with this change, two YugabyteDB agents stopped at
the PostgreSQL sub-build, the case the narrowed text describes. A pono agent
migrated bison and flex with the declared minimum versions enforced, and a
Kodi agent continued past FFmpeg's link wrapper, having mapped FFmpeg.

This is a proposal for discussion: moving from a blanket stop to guidance
is a scope decision for the maintainers, and the evidence is a few runs.

Testing

pytest tests/ at this commit: 196 passed (130 on main).

🤖 Generated with Claude Code

…ion)

The scope list tells the agent to stop at any build-time custom command or
generated code. In non-interactive runs the stop is not honored, and where
the codegen maps directly onto Bazel the agents migrated it correctly, so
the instruction bought nothing; where it does not map, it is the right
call and deserves a sharper description.

Observed in any2bazel-lab: every
skill-guided pono migration (five runs) went through the stop and migrated
its bison/flex genrules and stamped version.h, with parser and lexer
outputs identical to the reference in all of them; the unguided run did
the same, but silently downgraded bison below the declared minimum. The one
honored stop (YugabyteDB) was right: the blocker was a PostgreSQL fork
built by autotools outside the CMake model and linked into the servers,
and the unguided migration that went ahead produced servers that abort at
startup for that reason.

The scope list now keeps "stop" only for build-time generation with no
clear Bazel mapping, described as a sub-build the CMake model does not
show whose outputs the binaries link, in SKILL.md and in
docs/REFERENCE-cmake.md's scope traps. Without an answer, that is still a
stop (the non-interactive fallback earlier in this series says so). A short
paragraph under "Create initial BUILD.bazel files" says codegen that maps to a genrule over a host tool or to a ruleset is the
agent's to migrate, with the project's declared generator version; the
byte comparison of its outputs is the one the convergence-boundary list
already requires. The frontmatter description still says "no
codegen/custom commands"; it is trigger text, so it is unchanged.

In the lab's later runs with this change, two YugabyteDB agents stopped at
the PostgreSQL sub-build, the case the narrowed text describes. A pono agent
migrated bison and flex with the declared minimum versions enforced, and a
Kodi agent continued past FFmpeg's link wrapper, having mapped FFmpeg.

This is a proposal for discussion: moving from a blanket stop to guidance
is a scope decision for the maintainers, and the evidence is a few runs.

Lab-Proposal: P9

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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