feat(m-decomp): upgrade constraint

[csbobby]

M-Decompose Upgrade

Constraint Extraction and Validation

Description

• Constraint extraction refactored into a normalize-then-parse pipeline
  Added whitespace canonicalization, separator unification, and newline-aware block segmentation to eliminate layout- and order-sensitive parsing failures. Produces stable constraint IDs and consistent downstream bindings, significantly improving subtask–constraint determinism and template reproducibility.
• Introduced an explicit validation-decision stage
  Inserted between constraint extraction and code generation, emitting a constraint to validation-type mapping (e.g., llm / code). Validation strategy is now a first-class, inspectable, template-addressable feature, enabling different generation paths per constraint type.
• Validation code generation turns constraints into executable checking
  The validation_code_generator binds each constraint to a generated function stub in the V2. The CLI output shifts from a descriptive decomposition result to an importable, runnable validation module, allowing downstream systems to call validations directly and removing manual reinterpretation.

[github-actions]

The PR description has been updated. Please fill out the template for your PR to be reviewed.

[mergify]

Merge Protections

Your pull request matches the following merge protections and will not be merged until they are valid.

🟢 Enforce conventional commit

Wonderful, this rule succeeded.

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert|release)(?:\(.+\))?:

[jakelorocco]

Please make sure to run the pre-commit hooks. There's some formatting issues scattered throughout the PR.

I also worry that this is continuing the trend of the decompose module not being melleaic (mostly that it doesn't use components for templating). But I guess it doesn't worsen the problem, so I'm just flagging it now for future consideration.

[csbobby]

Just found a small commit miss, so please ignore the review request today @jakelorocco. I will figure out that later and then rerun the checks.

[csbobby]

Hi @jakelorocco Since the code for PR 556 has been ready and approved since last Friday, do we have any way to prioritize the merging (assuming there are no outstanding issues)? I noticed this would help avoid the recent repeated conflicts with subsequent updates.

Some recently submitted and applied changes (from diff users) are editing several lines of the m_decompose and applied to the main branch directly without going through PR reviews. So once there are overlapped lines and introduced new conflicts with PR 556, this would cause the merge checks to fail. This has been blocking PR 556 from being merged since last Friday. The PR 556 continued to be affected whenever new changes are pushed.

I’ve manually resolved several conflicts already, but I expect this will keep happening as long as new changes touch the same modules before PR 556 is merged.

Best!

[jakelorocco]

Hi @jakelorocco Since the code for PR 556 has been ready and approved since last Friday, do we have any way to prioritize the merging (assuming there are no outstanding issues)? I noticed this would help avoid the recent repeated conflicts with subsequent updates.

No. We have a merge queue. I'm not sure how you are handling updates to your branch from main, but it looks like something has gone awry because you are deleting / touching files that aren't related to m_decompose (like plugins).

Some recently submitted and applied changes (from diff users) are editing several lines of the m_decompose and applied to the main branch directly without going through PR reviews. So once there are overlapped lines and introduced new conflicts with PR 556, this would cause the merge checks to fail. This has been blocking PR 556 from being merged since last Friday. The PR 556 continued to be affected whenever new changes are pushed.

Yes, there were some that updated all the docstrings, etc... This will likely keep happening as we stabilize our formatting and documentation expectations.

I think the best we can do is fix the issues and then ping me to review immediately.

[csbobby]

Hi @jakelorocco Yes, glad to align and prioritize merging the PR. I’ll review and resolve the latest conflict that just came up (it seems unrelated to the PR but is still being flagged as a conflict) and then notify you.

For the existing unintended cases, I double checked: for decompose-irrelevant changes, it looks like the recent updates (e.g., plugins) were all made after the PR was submitted. So at the time the PR was created, those changes weren’t present. I merged the new files when saw them; for decompose-relevant changes (e.g., new lines) after the PR, the conflicts raised w/o a reminder/request, that parts we can collaborate to confirm together in a 5 mins sync.

Although the unintended similar situations happened when both relevant/irrelevant changes, there is no conclusion about the cause: the commit time / merge order or just something else. I think its fine to leave the question to open until our later sync. But this won't block there if we merge the PR at the moment then track. After that, we can see if there will be anything to change and avoid the unintended conflicts.