[codex] remove dead canvas HTTP path and add PR template

[FuJacob]

What does this PR do?

Briefly describe the changes. (e.g., "Added a user authentication form" or "Refactored the API fetching logic.")

• Removes the unused canvas-service HTTP controller, HTTP port, and servlet starter so the durable canvas path is gRPC-only.
• Cleans the backend docs and service comments to match the real runtime boundary, and adds a pull request template that captures what changed, why, and the key lesson.

Why is this necessary?

Explain the problem you are solving. If you look back at this in 6 months, will you know why you wrote this code?

• We had a dead HTTP surface hanging around after moving collab -> canvas-service traffic to gRPC. Leaving that extra transport path and its docs in place made the architecture harder to trust, increased maintenance surface area, and kept an unnecessary web stack in the canvas service.

🧠 What did I learn? (The most important part!)

Did you figure out a new CSS trick? Finally understand Promises? Make a note of it here.

• Once one transport becomes authoritative, keeping a parallel "debug-only" contract around is a drift vector. It is better to trim the dependency stack, remove the dead entry point, and document a single boundary so the code and the system model stay aligned.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
leet-canvas	Ready	Preview, Comment	Apr 10, 2026 0:14am

[Copilot]

Pull request overview

This PR removes the now-dead HTTP surface area from canvas-service so durable canvas operations are exposed only via gRPC, and updates backend documentation accordingly. It also adds a repo PR template to standardize change/why/lesson capture.

Changes:

• Remove the canvas HTTP controller and HTTP port configuration, keeping canvas durable operations gRPC-only.
• Update backend docs/architecture diagrams to reflect the single gRPC boundary for canvas-service.
• Add .github/PULL_REQUEST_TEMPLATE.md.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
services/canvas/src/main/resources/application.properties	Removes the HTTP server.port and keeps the gRPC port configuration.
services/canvas/src/main/java/com/leetdoodle/canvas/service/CanvasService.java	Updates service boundary documentation comment to reflect current collab integration.
services/canvas/src/main/java/com/leetdoodle/canvas/grpc/CanvasGrpcService.java	Updates gRPC adapter documentation to reflect gRPC-only boundary.
services/canvas/src/main/java/com/leetdoodle/canvas/controller/CanvasController.java	Deletes the HTTP debug controller entirely.
services/canvas/pom.xml	Removes the servlet web starter; keeps only the minimal Spring web dependency currently used for status/exception types.
docs/backend/README.md	Updates service inventory to remove the canvas HTTP port.
docs/backend/operations/local-runtime-and-runbooks.md	Removes canvas HTTP port and updates constraints to match current routing.
docs/backend/contracts/rest-api.md	Removes the Canvas REST API contract section and base URL.
docs/backend/architecture/containers.md	Updates container diagram + responsibilities to remove HTTP surface.
docs/backend/architecture/components.md	Updates component diagram + bullets to remove the HTTP controller.
.github/PULL_REQUEST_TEMPLATE.md	Adds a PR template for consistent PR writeups.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The template currently includes empty list items (- with no content). These render as blank bullets and can be confusing to fill out (and may be flagged by Markdown linters if added later). Consider replacing them with clearer placeholders (e.g., HTML comments, or checkbox items like - [ ] ...) so authors know what to write without leaving empty bullets.

[Copilot]

services/canvas is now gRPC-only, but the module still depends on spring-web primarily for HttpStatus/ResponseStatusException usage. If the goal is to trim all HTTP-centric dependencies from canvas-service, consider introducing transport-agnostic/domain exceptions and mapping them to gRPC Status in the adapter, which would let you drop spring-web entirely.

[Copilot]

The service is positioned as a gRPC-only boundary, but errors are still represented via ResponseStatusException/HttpStatus and then mapped to gRPC Status. If you want to keep the gRPC boundary free of HTTP semantics, consider switching to domain exceptions (or gRPC-native exceptions) and mapping those to Status instead of relying on ResponseStatusException.