18 lines
1.4 KiB
Markdown
18 lines
1.4 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.
|
|
|
|
## Screenshots of the behavior (when observable)
|
|
|
|
For observable CAD, UI or model behavior, include actual descriptive screenshots or a short recording from a small reproduction. This includes kernel, geometry, assembly and backend effects that can be shown in the app. Coding agents should run the app and capture the evidence themselves, rather than asking a human for evidence they can produce. Show the actual failure/result, preferably before and after, with brief steps, expected/actual behavior and annotations where helpful.
|
|
|
|
Flowcharts and Mermaid diagrams cannot substitute for evidence of visible behavior. Use diagrams for architectural reasoning when actual screenshots cannot illustrate the point. Changes with no useful observable behavior may omit screenshot/video evidence. Exclude private designs and sensitive details; attach media or link to an accessible recording rather than committing generated review artifacts.
|
|
|
|
## 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.
|