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.

AGENTS.md

@@ -71,6 +71,25 @@ People trust SolveCraft with their designs; a crash loses their work. **This out
 - **Never break wasm**: everything below the apps must build for `wasm32-unknown-unknown`
   (`cargo xtask wasm`, part of `cargo xtask ci`).
 
+## Showing and following through on changes
+
+- Give issues and PRs concrete visual context whenever it helps explain what is broken or
+  changed, including kernel, geometry, assembly and backend work. Coding agents should run
+  the relevant example and capture a screenshot, short recording, diagram or before/after
+  model view themselves. Show the actual reproduction/result, annotate the focus when useful,
+  and pair it with brief expected/actual behavior; do not ask a human for evidence the agent
+  can produce. Changes with no useful visual explanation do not need media.
+- Use a small public-safe example and check for private designs, paths, account details or
+  other sensitive content before sharing. Attach media to the issue/PR or link to an accessible
+  recording; do not commit generated screenshots or videos just to provide review evidence.
+- Throughout the work and before handoff, check current upstream commits and the relevant
+  PR's merge status. Keep your branch current with upstream merges, resolve conflicts without
+  discarding others' work, and re-run validation when integration changes the result. Use
+  `git pull --rebase origin main` before pushing as above; never force-push. Report the checked
+  upstream/PR state, any conflicts resolved and the validation performed. If a PR remains open,
+  keep monitoring it while the task is active and make its pending status clear at handoff;
+  do not claim it merged without checking.
+
 ## Application releases
 Development pushes are not application releases. Follow `docs/releasing.md` when asked to
 prepare or ship a release: choose the version from the actual changes, update Cargo.toml and

CONTRIBUTING.md

@@ -168,6 +168,23 @@ install. If you work on geometry and want to check against it, ask in an issue.
 4. Reference the issue (`Fixes #12`). In the PR, say what you tested and how. For geometry work, include the measured numbers (and
    the expected ones).
 
+Words alone can leave a change hard to picture. When a screenshot, short demo, diagram or
+before/after model view helps explain what is broken or changed, please include that concrete
+context in the issue or PR. This applies to kernel, geometry, assembly and backend work as well
+as the UI. Coding agents should run the relevant example and capture the actual reproduction
+or result themselves, with a brief expected/actual explanation and annotations where useful;
+please don't ask a human for evidence the agent can produce. Changes with no useful visual
+explanation do not need media. Use a small example without private designs or sensitive
+details; attach the media or link to an accessible recording rather than committing generated
+review artifacts.
+
+Keep checking upstream commits and the relevant PR's merge status throughout the work and
+before handoff. Integrate upstream merges, resolve conflicts without losing others' changes,
+and validate the integrated result. Before pushing, run `git pull --rebase origin main`, re-run
+CI if it brought changes, and push without force. Report the upstream/PR state you checked,
+any conflicts resolved and validation results. While a task remains active, follow an open
+PR through its status changes; at handoff, clearly identify anything still awaiting merge.
+
 Much of SolveCraft so far was written by AI coding agents (Claude) working in parallel, each
 owning one area, with a human setting direction and reporting bugs. Their working notes are in
 [AGENTS.md](AGENTS.md). Human contributors are just as welcome. Use whatever tools you like, as