A person wants to say what to do and how many times, not first organize platform choices, program IDs and file handles. When revising Northstar's folder repetition, I separated one interpretation of the request from the repeated execution of its prepared items.
Connect the work rather than adding another site selector
Adding separate blog and video selectors can lead to another repeater each time a different site's workflow appears. The common pattern is preparing one item, executing an existing procedure, verifying the outcome and moving to the next item. Site-specific differences belong to the actual plugin; the common runner repeats that procedure.
External Codex inspects the current project, open tabs and enabled plugins and connects a matching procedure once. For generic work, work_program and work_inputs are an internal plan created at that point. Rather than expose more IDs as human options, I made the connecting agent responsible for inspecting and supplying the current parameters.
What interpreting once actually means
resolveRepeatIntent selects the generic workflow path when workProgram is supplied and otherwise uses a limited set of known Naver/YouTube expressions or current-tab conditions. Mixed tasks or a request without a resolvable plan stop. The function does not contain a new universal natural-language classification model.
An explicit repeatCount takes precedence, and an unambiguous numeric count can be read from the request. Different counts appearing together are not silently resolved by guessing. Interpreting once does not mean concealing ambiguity. It means resolving ambiguity before execution and retaining the resulting plan during normal repetition.
Substitute data without evaluating it as code
Generic plugin inputs combine fixed data with permitted placeholders such as title, body, schedule, folder, index, file and files. The person's text is not evaluated as arbitrary code or a shell command. A recursive plan connecting the repeater to itself is also rejected.
This does not mean refusing additional sites. A new workflow first needs a plugin that can actually perform that site's procedure and a defined result to verify. Once that contract exists, the common repeater can use it. Accepting unlimited executable code and reusing a bounded procedure across different work are not the same kind of extensibility.
Verify one folder before starting another
One material folder represents one work item. The original is preserved and a working copy is prepared. The existing plugin receives one execution request; a local program follows its status and verification. Only then is the working copy moved to done and the next item started. Error, stop and uncertain outcomes prevent that next execution.
If fewer folders are prepared than requested, material is not duplicated to fill the count. A repetition count depends on having the corresponding material. Generic repetition may need no date; a first time and interval are connected only for work that requires them. Calling something a scheduler should not force unnecessary date input onto every repeated task.
Record what was actually repeated
The historical generic-repetition check processed only two of three prepared folders through a real reading plugin and moved only those two working copies to done. A repeated registration read reused the completed batch. That supports the generic execution connection and completion boundary; it is not a test newly publishing two external posts or videos.
Future Naver and YouTube reservation-registration tests were also distinguished from execution because they were cancelled before starting. That is why workVerified and publicationVerified have different names. A plugin's checked procedure finishing is not automatically the same as an external public result being created.
Adapting the same repeater to another business
An adopter should first define one item. A folder representing a manuscript, a document bundle or a single query implies a different completion criterion. Next come the actual plugin and inputs, original preservation, result records and stop conditions. A simple human request needs a concrete implementation contract behind it.
For this article I compared the current request-resolution function, common-repetition documentation and historical execution report. I did not run the operational scheduler or source folders again and did not resume the external-PC Jupyter connector. My aim was to connect a verified procedure once to the existing repetition engine rather than rebuild that engine for every business task.