From 01efb913e70066468770fe47e449f1fa39db0831 Mon Sep 17 00:00:00 2001 From: Mark Schaller Date: Sat, 26 Sep 2026 02:32:02 -0400 Subject: [PATCH] Keep "stop" only for codegen with no clear Bazel mapping (for discussion) 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 --- SKILL.md | 12 ++++++++++-- docs/REFERENCE-cmake.md | 6 ++++-- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/SKILL.md b/SKILL.md index fb4ddc1..834ab02 100644 --- a/SKILL.md +++ b/SKILL.md @@ -243,8 +243,12 @@ proceed, unless an item on the not-yet-supported list below applies: without an answer, stop there and report it. **NOT yet supported — warn the user if the project has these:** -- Build-time custom commands / generated code. Configure-time generated - files are handled by you, not the tool: see the reference guide. +- Build-time generation with **no clear Bazel mapping**: a sub-build the + reference model does not show (autotools, a vendored fork's own build) whose + outputs the binaries link. Other codegen and configure-time generated files + are yours to migrate: see + [Create initial BUILD.bazel files](#create-build-files) and the reference + guide. - Per-test-binary identity alignment, and include search **order** (presence only) — both have planned follow-ups - Packaging / install rules @@ -301,6 +305,10 @@ silently: a genrule cannot see `.git` from the sandbox, and the binary reports an "unknown version". Feed them through `--workspace_status_command` to a `stamp = 1` rule. +**Build-time codegen** that maps to a `genrule` over a host tool (bison/flex) or +to a ruleset (protoc) is yours to migrate: use the project's declared generator +version. + The reference guide covers what is specific to translating its build system (for CMake: the build type and configure-time generated files). diff --git a/docs/REFERENCE-cmake.md b/docs/REFERENCE-cmake.md index 37c6c98..9008557 100644 --- a/docs/REFERENCE-cmake.md +++ b/docs/REFERENCE-cmake.md @@ -14,8 +14,10 @@ as the reference build. When [confirming scope](../SKILL.md#confirm-scope), inspect `CMakeLists.txt` for these and surface them before proceeding: -- Build-time generated code: `add_custom_command`, protoc or other codegen - steps. `configure_file` is handled by you, not the tool: see +- Build-time generation with no clear Bazel mapping: a sub-build the CMake + model does not show (autotools, a vendored fork's own build) whose outputs + the binaries link. Other codegen (`add_custom_command`, protoc) is yours to + migrate, and so is `configure_file`: see [Configure-time generated files](#configure-time-generated-files). - `find_package` of non-system libraries. There is no automatic `find_package` → bzlmod resolution; each one must be mapped by hand.