AdjustPrescriptionCommand silently no-ops when the patient's matched Medication has no prior Prescription record

[nara-falconeer]

Repro

1. Create a patient. At intake, add metformin via a committed MedicationStatementCommand (sig "500 mg BID"). This produces a Medication row with FDB coding, no Prescription row.
2. From a plugin, originate an AdjustPrescriptionCommand against that patient + note:

   AdjustPrescriptionCommand(
       fdb_code="155744",          # the metformin FDB code from the chart's coding
       sig="1000 mg BID",
       days_supply=30,
       refills=1,
       substitutions=PrescribeCommand.Substitutions.ALLOWED,
       prescriber_id=<provider uuid>,
       note_uuid=<note uuid>,
   )

   quantity_to_dispense and type_to_dispense set per Prescribe conventions.
3. .originate() succeeds. Plugin logs show the effect was emitted. No error in canvas logs at any level.
4. Refresh the note in the Canvas UI → no Adjust Prescription card appears anywhere. Plan/Diagnose/etc. commands originated in the same handler render normally.

Expected

Either:

• An Adjust Prescription draft card appears on the note (in whichever section is appropriate for Sendable / Refill-family commands), OR
• A COMMAND_VALIDATION_ERRORS effect comes back with a clear reason (e.g. "no prior Prescription to adjust"), so the plugin can surface a useful error or fall back to ChangeMedicationCommand.

The current "accepted-but-invisible" behavior is the worst of both — no feedback, no UI.

Hypothesis

AdjustPrescriptionCommand extends RefillCommand, which models "refill an existing prescription with adjusted parameters." Server-side rendering presumably anchors on a real Prescription row, and silently drops the effect when none exists for the (patient, fdb_code) pair — even though RefillCommand._get_error_details only checks Medication.objects.active().filter(codings__code=fdb_code, patient=...).

Why it matters

For any clinic whose meds come primarily from intake / med-rec (not their own e-Rx history), AdjustPrescription will silently no-op on most patients. The SDK is misleading here:

• The name suggests "adjust the documented prescription."
• The validation in RefillCommand only looks at the Medication table, implying any active med is adjustable.
• But the server requires a Prescription row to actually render anything.

Suggested fixes (any one would unblock us)

1. Surface a validation error when Prescription.objects.filter(patient=..., medication__codings__code=fdb_code).exists() is false at originate time — push the existing tighter check into RefillCommand._get_error_details.
2. Document the requirement in the AdjustPrescriptionCommand docstring + class Meta (e.g. "requires an existing Canvas-originated Prescription; for sig-only updates to Statement-sourced meds use ChangeMedicationCommand").
3. Permit Statement-only adjustments by writing a new Prescription row tied to the existing Medication when none exists — but that changes semantics and is probably out of scope.

Workaround we're using

Dispatch at the plugin level: AdjustPrescriptionCommand when med.prescriptions.exists(), else ChangeMedicationCommand. This works but every plugin author will need to learn this the hard way; would prefer at least (1) or (2) upstream.

[rmagier1]

@nara-falconeer Looks like the AdjustPrescription command was not enabled as an SDK command in your dev environment (it is in your production environment though). I have enabled it now, can you please try your plugin out and see if you are good to go now?