discharge

name	discharge
description	Final pre-ship / pre-merge checklist, run like a hospital discharge. The patient (PR, branch, feature, release) doesn't leave the hospital until the discharge criteria are met and the discharge summary is written. Use immediately before merging, deploying, or closing a ticket.

Discharge

"Patient is doing well, tolerating PO, ambulating without assist, ready for home."

Discharge is not a vibe. Discharge is a checklist plus a written summary. If you can't pass the checklist, the patient stays. If you can't write the summary, the patient stays. Sister Mary Margaret (chaplaincy) once said, "we don't discharge people into the night." She was talking about a literal patient at 11 p.m. but the principle holds.

---

Discharge criteria (must all be yes)

Patient (PR / branch / feature / release) may be discharged when:

• Vitals stable. All checks pass (tests, lint, types, build). No flapping.
• Tolerating PO. It runs locally / in staging. You have actually used it, not just compiled it.
• Ambulating. Critical user paths exercised end-to-end. For backend changes: tested under realistic load or with realistic data.
• Pain controlled. Known issues have a documented mitigation or are explicitly accepted (with sign-off).
• Follow-up in place. Monitoring, alerts, dashboards, or feature flags exist for what could regress. If it's a flag or staged rollout, schedule the cleanup (offer the user /schedule).
• Medications reconciled. Dependency changes documented; lockfile committed; no rogue versions. (/consult-pharmacy if uncertain.)
• Prescriptions sent home. Required env vars, migrations, or runbook entries are in the right place.
• Belongings. No leftover scaffolding: dead code, commented-out blocks, debug logs, test print statements.
• Family understands the plan. PR description / commit message is clear to a reader who wasn't in the room. Reviewers' comments addressed (resolved or replied to with rationale).

If any are no: do not merge. The patient stays.

---

The discharge summary (write this, attach to the chart)

Short, structured, in this exact form. Goes into the PR description / merge commit / release notes:

DISCHARGE SUMMARY
─────────────────
Reason for admission: <what problem was being solved>
Hospital course:      <what was actually changed, in 1–3 sentences>
Diagnosis:            <root cause, if it was a bug fix>
Procedures:           <notable refactors or migrations>
Medications on D/C:   <new deps added / removed / bumped>
Follow-up:            <flag to clean up, metric to watch, soak window>
Discharge condition:  Stable / Improved / Resolved

This is not a changelog. A changelog says what changed. A discharge summary says why it changed, what state we're leaving the patient in, and what to watch.

---

Special discharges

• AMA (against medical advice): shipping despite a failing check, with explicit sign-off. Document who signed and why. See workflows/against-medical-advice.md.
• Transfer (not discharge): not actually closing — handing off mid-care. Use SBAR, not a discharge summary.
• Expired: deprecation / shutdown. The patient went to the morgue (departments/morgue/). Greta Sól wants the cause of death.

---

When to delay discharge

• Discharge after dark. Friday-afternoon-into-the-weekend deploys are the medical equivalent of discharging an elderly patient at 10 p.m. with no follow-up. Don't, unless it's a fix-forward for a Code Blue.
• No bed available at home. Receiving environment isn't ready (missing config, dependent service still rolling out). Hold the patient.
• Family not present. No one's around to monitor. If it breaks at 2 a.m., who gets paged?

---

Things Holloway has rejected discharges for

• "Tests pass" with no evidence the tests cover the change
• "I tested it locally" with no description of what was tested
• A discharge summary that just says "fixes #1234"
• Bouncebacks (re-admissions) within 30 days because the discharge skipped follow-up

---

Read the checklist. Write the summary. Then send the patient home.