signals.yml is managed by the sidecar, not authored by the customer, and
the write flag is used by the supporting services rather than being a
script author's lever. The previous text presented both as a customer
contract, which is wrong.
Now claims only runtime behaviour: which signals a job sees is configured
for it, an unexposed signal is absent rather than an error, and batch
rejection is described as the sidecar not recognising an id. Also points a
customer at their own job output rather than platform-side logs they may
not have access to.
Customer-facing API reference for the three modules, written from source
plus the live test-script job. Scoped to the API: the signals.yml and
schedule.yaml contract gets only what a caller needs to read the API
correctly, not a full treatment.
Three behaviours documented because they are invisible from the source a
customer reads: a write batch is all-or-nothing on an unknown id, run()
skips logic_func entirely on a failed or empty read, and every method
swallows its exceptions so a falsy return conflates failure with empty.
The dbutils calls also set no timeout, unlike the signal calls.
pyproject.toml is unchanged; README.md is already its readme field.
Iñigo Etxaniz