Repeated processing does not always need a publication date. Scheduled content also has a work-start time distinct from its intended visibility time. I separated those concepts and the procedure-specific timing rules, so an untimed task remains usable without weakening validation for work that genuinely needs a schedule.
Allow an empty schedule for an untimed workflow
The workflow planning branch retains an empty schedule when no first time is supplied. It does not require dates encoded in folder names. Whether timing is needed depends on the selected plugin contract and present task; using a common repeater does not turn every operation into scheduled publication.
Not every plugin accepts an empty date. A media-specific stage can still reject it through its own input validation. Avoiding a universal date requirement differs from removing a required date from a particular operation. Generality should preserve the conditions of each supported workflow rather than erase them.
Expand a supplied first time into an item schedule
When a first time is supplied, the planner applies interval hours and item index to produce each intended time. A timed generic workflow still passes future-time and precision checks. Interval bounds also remain validated when the date is omitted, so untimed does not mean every timing-related check disappears.
Combining quantity and interval requires reviewing each prepared time. A correct first date cannot guarantee that the final date is intended too. The expanded list is useful review material. Convenient arithmetic and a correct publication plan are separate conclusions, particularly when the batch crosses days or reporting periods.
Keep platform-specific schedule rules distinct
Dedicated scheduled delivery uses a supplied first time or a supported date-folder convention. The current implementation interprets timezone-free values in Korean time and converts explicit offsets. It checks future lead time and precision, with an additional ten-minute-slot condition in the Naver path.
That does not establish the same ten-minute restriction for every platform. A shared repetition skeleton can retain different service scheduling rules. A useful error explanation identifies which input and platform condition needs attention rather than hiding all timing failures behind one generic invalid-format message.
Run start is a separate time from intended visibility
The batch has its own start time, defaulting to now when omitted. For timed content, the planner checks that execution can start sufficiently before the first intended publication. The structure therefore represents preparing a future publication now without treating those moments as identical.
Late worker startup has its own rule: a start more than two minutes overdue is retained as overdue rather than automatically executed. That does not rewrite the content's scheduled time. Execution delay and schedule revision are different decisions requiring current intent and conditions, not an implicit catch-up policy.
Distinguish preview, local registration and verified service scheduling
Preview returns calculated items and times while registration and publication-verification flags remain false. Local registration also does not mean every service reservation has finished. Producing a timetable and retaining actual server-side scheduling are different outcomes.
The existing unit test checks that one typed reservation request can return queued while publication remains unverified. This article reads code and tests without creating a new live reservation. Explaining time arithmetic does not require republishing a user's existing schedule or business material. Preparation, execution and service outcomes retain their own evidence.
Ask for necessary timing and expose what it controls
Demanding every internal time field makes simple repetition difficult. Guessing a required schedule for convenience can expose content at an unintended moment. The chosen approach asks for timing where the workflow needs it and connects that meaning to actual inputs.
Business batch start, billing date and customer-visible dispatch can also be different moments. Reducing them to one field is not automatically intuitive. People need to understand which time changes which outcome. Separating schedule inputs is a way to describe the work's timing accurately rather than merely multiplying controls.