WP_DEBUG log grows without rotation obscuring recent deployment errors

Goal: maintain a usable WP_DEBUG log that captures recent errors during theme or plugin deployment without being overwhelmed by historical data.

Constraint: WordPress writes to wp-content/debug.log indefinitely, with no internal rotation or size limit, so administrators must rely on external processes to prevent the file from growing unchecked and hiding recent stack traces.

Uncertainty: how to apply log‑rotation safely while preserving the logging format and ensuring that WordPress continues to write to the same file handle after rotation, and what safeguards are needed to avoid losing diagnostic information or exposing the log to the web.

What are the recommended external log‑rotation strategies for wp-content/debug.log that do not interfere with WordPress’s file handling?

How can administrators implement size‑based rotation (e.g., using logrotate) while preserving the debug.log file permissions and ownership required by WordPress?