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.
#110 recorded pyproject.toml + __init__.py as verified on a real toolchain
but they were never committed; origin has nothing past d5203ce.
pyproject.toml is deliberately plain: the sidecar's pypi.ReadProjectMetadata
is a line scanner, not a TOML parser, and reads name and version as literal
single-line assignments under [project]. A dynamic version would break both
the publish check and the startup reconcile.
__init__.py re-exports the public API so src/i7lib is an importable package.
.gitignore keeps dist/ out of the tree — a committed wheel would travel in
gitea's source archive and trip the builder's one-wheel-in-dist check.
Iñigo Etxaniz