feat: Phase 6 — Secure deployment to Render, Railway, Vercel, and Fly.io

[acm-rgb]

Summary

Tutor-buddy currently ends at phase 5 (GitHub setup). The natural next step for most
beginners is deployment, and it carries the same category of mistakes the skill already
prevents: exposed secrets in environment variable dashboards, public services with no
auth, default configurations that are insecure out of the box.

This issue tracks the design and implementation of a phase 6 covering the four most
common beginner deployment targets.

---

Scope

A new reference file references/deployment.md loaded only when phase 6 begins.
The SKILL.md orchestrator needs a one-line addition routing to it after phase 5.

---

What the phase should cover (per platform)

For each platform, the phase should handle:

1. Environment variables — confirm all .env values are set in the platform's
   secret/env dashboard, not hardcoded in config files committed to the repo.
2. Service visibility — default to private/internal where the platform allows;
   prompt the user before exposing anything publicly.
3. Build command and start command — validate they match what was planned in phase 2.
4. Health check — confirm the platform has one configured so failed deploys are
   caught automatically.
5. Custom domain + HTTPS — note whether it is automatic or requires action.

Platforms in scope:

Platform	CLI available	Notes
Render	render CLI (limited)	render.yaml is the preferred config
Railway	railway CLI	railway.toml or dashboard
Vercel	vercel CLI	vercel.json, strong Next.js default
Fly.io	flyctl	fly.toml, most configurable, steepest curve

---

Security concerns specific to deployment

These are not covered by the phase 4 audit and belong here:

• Secrets set as plain-text env vars visible to all team members in the dashboard
  (Render and Railway both have this risk — flag it)
• Public-facing services with no rate limiting at the platform level
• Auto-deploy from main without required review (should be gated by branch
  protection from phase 5, but worth confirming)
• Default fly.toml exposes metrics endpoints — should be disabled or protected

---

What good looks like

At the end of phase 6 the user should have:

• A live URL
• All secrets stored in the platform's secret manager, not in any committed file
• A health check configured
• A clear statement of what is publicly accessible and why

---

How to contribute

1. Comment here before starting so we can coordinate if multiple people are interested
   in different platforms.
2. Pick one platform — a PR covering one well is better than four covered poorly.
3. Follow the editing guidelines in CONTRIBUTING.md: imperative
   form, one claim per sentence, no check without a concrete detection method and
   correct response.
4. Install the modified skill and run a real session through a deploy before opening
   the PR.

---

Out of scope for this issue

• Docker / self-hosted deployment
• AWS / GCP / Azure (too much surface area for the beginner audience)
• CI-triggered deploy pipelines (separate issue)