Confirm the light and the upload on a real P1P

Four things were shipped unverified because the printer was off when they
were written. Three are now confirmed first-hand (P1P, 2026-10-15), and one
is settled in the opposite direction from what was assumed.

**`set_light` had never once reached a printer**, and `completion::run`
blinks a finished print's chamber light with it. It works - but "accepted" is
not "it changed": `ledctrl` answers `result: "success"` as soon as the
command parses, exactly like the print-control verbs. So `lights_report` is
now modelled on `PrintReport`, which is the only read-back there is, and the
probe polls it rather than printing a reassuring message. Setting the light
on and off reads `[{"node":"chamber_light","mode":"on"}]` / `"off"` back,
about 3s later. The field was observed on v1 even though only the v2 schema
declares it.

**The blink itself works at the rate it ships at.** `completion::celebrate`
is now public so the probe runs the real function instead of a copy: twenty
`ledctrl` commands half a second apart, which a printer is entitled to
refuse. None were refused, it returned after 10.35s, and the light ended
`off` as specified - a blink that leaves the light on would look like a
printer still working.

**The firmware's own `flashing` mode is not the better option.** It is
accepted, and the reply echoes all four parameters back
(`led_on_time`, `led_off_time`, `loop_times`, `interval_time`), so the
printer does parse them. But `lights_report` never reports `flashing` - it
stayed on the previous mode for 12s of polling. A firmware blink is therefore
unobservable: nothing can confirm it happened or tell when it ended, while
the self-driven blink is built from a call that reads back. That is a better
reason to keep `celebrate` than the one in the comment it replaces, which was
that `loop_times` semantics were unconfirmed. Whether the light physically
blinks is still unwitnessed - nobody was watching the machine.

**Multi-MB FTPS upload works, and is slow.** A 4.96 MB project archive went
up with an exact byte count and came back byte-identical (sha256). But it
took 31.3s - about 0.2 MiB/s - so the 62 MB project already on that card
would take six and a half minutes. Anything that uploads a job needs a
timeout budgeted in minutes, not seconds. The claim in `download`'s comment
that these files are "a few hundred KB" is gone; the card disproves it.

Also adds `delete`, because the probe left a 5 MB file on a real SD card and
there was no way to remove it. One explicit path, no globbing: the convenient
version of this deletes something somebody printed from last week. Used to
clean up, and the card is back as it was.

New probe steps: `light on|off|flash`, `blink`, `upload <local> [name]`,
`delete <path>`. 51 tests still pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/completion.rs

@@ -126,7 +126,11 @@ pub async fn run(fleet: SharedFleet) {
 /// The light is left off whatever happens, including when a blink fails
 /// part-way: a printer abandoned mid-blink with its light on looks like a
 /// machine still working.
-async fn celebrate(fleet: SharedFleet, printer_id: String) {
+/// Public so `examples/bambu_print_probe.rs` can run the real blink against a
+/// real printer. Twenty light commands in ten seconds is a rate a printer can
+/// refuse, and a blink reimplemented in the probe to match would not have
+/// told us whether this one works.
+pub async fn celebrate(fleet: SharedFleet, printer_id: String) {
     let deadline = tokio::time::Instant::now() + BLINK_FOR;
     let mut state = LightState::On;
 

src/printer/bambu.rs

@@ -933,6 +933,31 @@ impl BambuPrinter {
         .map_err(|err| PrinterError(format!("{}: FTPS download failed: {err}", self.base.name)))
     }
 
+    /// Removes one file from the printer's SD card.
+    ///
+    /// Takes one explicit path, because the convenient version of this is
+    /// also the dangerous one - see `bambu_ftps::delete`. Nothing calls it
+    /// automatically yet: a gateway that uploads a project per job needs to
+    /// clear them eventually, but *which* file is safe to remove is a
+    /// question about the job queue, not about FTPS.
+    pub async fn delete_file(&self, path: &str) -> Result<(), PrinterError> {
+        let connector = self
+            .tls
+            .build_connector()
+            .map_err(|err| PrinterError(format!("{}: TLS setup failed: {err}", self.base.name)))?;
+
+        let host = self.base.host.clone();
+        let access_code = self.access_code.clone();
+        let path = path.to_string();
+
+        tokio::task::spawn_blocking(move || {
+            super::bambu_ftps::delete(&host, &access_code, connector, &path)
+        })
+        .await
+        .map_err(|err| PrinterError(format!("{}: FTPS delete thread failed: {err}", self.base.name)))?
+        .map_err(|err| PrinterError(format!("{}: FTPS delete failed: {err}", self.base.name)))
+    }
+
     /// `list_cache` for any directory on the printer's SD card.
     ///
     /// Read-only, and the way to answer "what is the path to this file?"

src/printer/bambu_commands/mod.rs

@@ -26,7 +26,10 @@ mod print;
 mod pushall;
 
 pub use get_version::{GetVersionRequest, GetVersionResponse, ModuleInfo};
-pub use print::{AmsState, AmsTray, AmsUnit, EmptyTray, LoadedTray, PrintReport, VtTray, XcamSettings};
+pub use print::{
+    AmsState, AmsTray, AmsUnit, EmptyTray, LightReport, LoadedTray, PrintReport, VtTray,
+    XcamSettings,
+};
 pub use pushall::PushallRequest;
 
 /// Fields every Bambu command/response shares. This is the "inheritance"

src/printer/bambu_commands/print.rs

@@ -20,9 +20,8 @@ pub struct PrintReport {
     /// actual, reliable signal for which kind a given message is -
     /// confirmed against a real printer, unlike trying to infer it from
     /// request/reply timing (see `BambuMqttSession`'s `PrintStatusCache`,
-    /// which used to try that and got it wrong twice). Not in
-    /// `push_status.schema.json` yet - add it there too when you're back
-    /// in continuum-schemas.
+    /// which used to try that and got it wrong twice). Now declared in
+    /// `push_status.schema.json` too.
     pub msg: Option<i32>,
     pub ams: Option<AmsState>,
     pub ams_exist_bits: Option<String>,
@@ -112,6 +111,18 @@ pub struct PrintReport {
     /// is the precedent, and making that one required broke every report from
     /// the other generation.
     pub vt_tray: Option<VtTray>,
+    /// What each light is actually doing. This is the read-back for
+    /// `set_light`, and the only one there is: a `ledctrl` reply says
+    /// `result: "success"` as soon as the command parses, which on a Bambu
+    /// means "accepted" and not "the light changed" (the same trap as the
+    /// print-control verbs). Confirmed on the P1P (2026-10-15) by setting
+    /// the chamber light on and off and reading
+    /// `[{"node":"chamber_light","mode":"on"}]` / `"off"` back here - which
+    /// is the first time `set_light` was shown to do anything at all.
+    ///
+    /// Observed on v1 despite only the v2 schema declaring it; the v1
+    /// schema was simply missing it.
+    pub lights_report: Option<Vec<LightReport>>,
 
     // There are still ~60 more top-level fields in a real v2 payload (see
     // `tests/fixtures/push_status_v2_h2c_printing.json` for the full set):
@@ -181,9 +192,25 @@ impl PrintReport {
         self.stg_cur = newer.stg_cur.or(self.stg_cur.take());
         self.stg = newer.stg.or(self.stg.take());
         self.vt_tray = newer.vt_tray.or(self.vt_tray.take());
+        self.lights_report = newer.lights_report.or(self.lights_report.take());
     }
 }
 
+/// One light's state, as the printer reports it rather than as we asked for
+/// it. `mode` is the same vocabulary `ledctrl` accepts (`"on"`, `"off"`,
+/// `"flashing"`), and `node` the same light name - so a round-trip is
+/// directly comparable, which is the point of having it.
+///
+/// Both fields optional on principle rather than from evidence: every entry
+/// seen on the P1P carried both, but one light in a list is not a sample of
+/// every light on every model, and a missing `node` must not cost us the
+/// whole report.
+#[derive(serde::Deserialize, Debug, Clone)]
+pub struct LightReport {
+    pub node: Option<String>,
+    pub mode: Option<String>,
+}
+
 /// Bambu's own naming has the outer container and the inner array both
 /// called `ams` - `print.ams.ams`, not a typo here, just what the printer
 /// actually sends.

src/printer/bambu_ftps.rs

@@ -142,9 +142,15 @@ pub fn download(
     ftp.transfer_type(FileType::Binary)?;
 
     // `retr_as_buffer` rather than `retr_as_stream`: suppaftp 12's
-    // `TransferStream` finalizes itself on drop, and the files being read
-    // here are project archives of a few hundred KB, so there is nothing to
-    // gain from streaming them.
+    // `TransferStream` finalizes itself on drop, and a project archive is
+    // read whole anyway - `plate_filaments` needs the central directory at
+    // its end before it can read anything.
+    //
+    // Confirmed fine at 4.96 MB on the P1P (2026-10-15, byte-identical
+    // round trip). The qualifier here used to be "a few hundred KB", which
+    // the card itself disproves - the largest project on it is 62 MB, and
+    // that one would be held in memory twice during a round trip. Streaming
+    // is the answer if that ever matters; it has not yet.
     let bytes = ftp.retr_as_buffer(path)?.into_inner();
 
     let _ = ftp.quit();
@@ -152,6 +158,38 @@ pub fn download(
     Ok(bytes)
 }
 
+/// Blocking: removes one file from the card.
+///
+/// The counterpart to `upload`, and the only reason it did not exist before
+/// is that nothing had uploaded anything worth removing. It is needed now:
+/// the P1P's card already holds 45 project archives and 47 extracted
+/// `cache/` entries, so a gateway that uploads a project per job and never
+/// removes one is a gateway that eventually fills a customer's SD card and
+/// starts failing prints for a reason nobody will connect to this code.
+///
+/// Deliberately takes one explicit path and does no globbing or recursion:
+/// the obvious convenience here ("clear the old ones") is also the obvious
+/// way to delete a file somebody printed from last week.
+pub fn delete(
+    host: &str,
+    access_code: &str,
+    connector: native_tls::TlsConnector,
+    path: &str,
+) -> anyhow::Result<()> {
+    let mut ftp = NativeTlsFtpStream::connect_secure_implicit(
+        (host, FTPS_PORT),
+        NativeTlsConnector::from(connector),
+        host,
+    )?;
+
+    ftp.login(FTPS_USER, access_code)?;
+    ftp.rm(path)?;
+
+    let _ = ftp.quit();
+
+    Ok(())
+}
+
 /// Blocking: lists `cache/` on the printer.
 ///
 /// Read-only, and the counterpart to `upload`. The previous version of this

src/printer/mod.rs

@@ -49,7 +49,8 @@ pub use bambu::{
 };
 pub use bambu_commands::{
     AmsState, AmsTray, AmsUnit, BambuReport, BambuRequest, CommandEnvelope, EmptyTray, GetVersionRequest,
-    GetVersionResponse, LoadedTray, ModuleInfo, PrintReport, PushallRequest, VtTray, XcamSettings,
+    GetVersionResponse, LightReport, LoadedTray, ModuleInfo, PrintReport, PushallRequest, VtTray,
+    XcamSettings,
 };
 pub use klipper::KlipperPrinter;
 pub use prusa::{PrusaLinkPrinter, PrusaSerialPrinter};