docs: guide agents to show concrete visual context and track integration

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,19 @@
+---
+name: Bug report
+about: Help reproduce and fix a SolveCraft problem
+title: ''
+labels: ''
+assignees: ''
+---
+
+## Behavior
+
+What did you expect, and what happened instead?
+
+## Reproduction
+
+Include steps, SolveCraft version/commit and relevant environment details. Prefer a small example without private design data.
+
+## Concrete visual context (when helpful)
+
+If a screenshot, short demo, diagram or example model view helps make the problem concrete, include it with the reproduction steps, even for kernel, geometry, assembly or backend behavior. Coding agents should run the example and capture the actual result themselves when possible, rather than asking a human for evidence they can produce. Annotate the focus when helpful. Exclude private designs and sensitive details; attach media or use an accessible link, not committed generated artifacts. Problems with no useful visual explanation do not require media.

.github/pull_request_template.md

@@ -0,0 +1,15 @@
+## 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.