Context
bmadconfig.load_paths resolves implementation_artifacts / planning_artifacts from the legacy _bmad/bmm/config.yaml only. The renderer-era bmad-dev-auto (BMAD-METHOD #2587/#2588) resolves the same keys from the four-layer central TOML (_bmad/config.toml + config.user.toml + custom/config.toml + custom/config.user.toml), with [modules.bmm] beating [core] on collision.
The BMAD installer regenerates the per-module yaml from the TOML on each install/update, so the two surfaces normally agree — but a hand-added custom/config*.toml override desyncs them until the next install: the skill then writes specs and the deferred-work ledger where the orchestrator is not looking.
Current mitigation
The renderer-compat PR adds bmadconfig.toml_artifact_parity, a validate-time warning (never a FAIL) that deep-merges the four layers with the renderer's exact precedence and compares the resolved implementation_artifacts against the yaml-resolved path.
Proposed fix
Make load_paths read the four-layer TOML as the primary source (same merge + flatten semantics as render.py: layers deep-merge lowest→highest, then [core] → [modules.bmm] flatten with module precedence), falling back to _bmad/bmm/config.yaml for pre-#2285 installs. The parity warning then becomes unnecessary and toml_artifact_parity can be retired.
Care points:
repo_root and output_folder are also read from the yaml today — decide their TOML home before switching.{project-root} substitution must match render.py (forward-slash root).- Keep
BmadConfigError messages actionable for both surfaces.
Context
bmadconfig.load_pathsresolvesimplementation_artifacts/planning_artifactsfrom the legacy_bmad/bmm/config.yamlonly. The renderer-erabmad-dev-auto(BMAD-METHOD #2587/#2588) resolves the same keys from the four-layer central TOML (_bmad/config.toml+config.user.toml+custom/config.toml+custom/config.user.toml), with[modules.bmm]beating[core]on collision.The BMAD installer regenerates the per-module yaml from the TOML on each install/update, so the two surfaces normally agree — but a hand-added
custom/config*.tomloverride desyncs them until the next install: the skill then writes specs and the deferred-work ledger where the orchestrator is not looking.Current mitigation
The renderer-compat PR adds
bmadconfig.toml_artifact_parity, a validate-time warning (never a FAIL) that deep-merges the four layers with the renderer's exact precedence and compares the resolvedimplementation_artifactsagainst the yaml-resolved path.Proposed fix
Make
load_pathsread the four-layer TOML as the primary source (same merge + flatten semantics asrender.py: layers deep-merge lowest→highest, then[core]→[modules.bmm]flatten with module precedence), falling back to_bmad/bmm/config.yamlfor pre-#2285 installs. The parity warning then becomes unnecessary andtoml_artifact_paritycan be retired.Care points:
repo_rootandoutput_folderare also read from the yaml today — decide their TOML home before switching.{project-root}substitution must match render.py (forward-slash root).BmadConfigErrormessages actionable for both surfaces.