16 lines
1.1 KiB
Markdown
16 lines
1.1 KiB
Markdown
## Change
|
|
|
|
Describe the problem and resulting behavior. Link the issue when applicable.
|
|
|
|
## Validation
|
|
|
|
What did you run, and what were the results? Include expected and measured values for geometry changes.
|
|
|
|
## Concrete visual context (when helpful)
|
|
|
|
If a screenshot, short demo, diagram or before/after model view helps explain what this change means, include it alongside the prose. This includes kernel, geometry, assembly and backend changes, not only UI work. Coding agents should run the example and capture the actual reproduction/result themselves, adding brief steps and annotations where helpful. Use a public-safe example; exclude private designs and sensitive details, and attach media rather than committing generated review artifacts. Changes with no useful visual explanation can omit this section.
|
|
|
|
## Integration status
|
|
|
|
Record the upstream commit and PR status checked before handoff, any conflicts resolved, and validation after integration. Keep up with upstream merges and monitor this PR while the task is active; rebase before pushing and never force-push.
|