Distributed script automation.

Two hard constraints, one filter

A node must have an interpreter for the job’s runtime, and must hold every node-local secret it names. Both ask the same thing (can this node run it at all?), so one filter answers both.

A 400 means nothing in the cluster can ever run it. A 503 means nothing that can is reachable right now.

Then weighted by how big the node is

The leader minimises units / slots, where a node’s slots are min(cores × 4, memory / 256 MB): whichever of CPU and RAM runs out first. Ratios are compared by cross-multiplication, so a placement cannot wobble on a rounding error.

Load is queue depth: a node grinding through one 40-minute script is busier than one that churned through fifty one-liners.

Full nodes are skipped if possible

A node at its concurrency limit is skipped while anything else can take the work, but if that would empty the pool it comes back whole, because a full node still runs the job in turn. A declared cost works the same way: it weights placement, and nothing enforces it against the script.

Cluster secrets, with nothing to set up

The key that seals them is derived from the cluster CA, which every node already holds. The CLI seals the value on your own machine; the accepting node re-seals it under the cluster key, and that ciphertext is what replicates. The plaintext is never in the log, in a database, or in a snapshot, and nothing reads one back.

Node-local secrets constrain placement

A file on one machine, never replicated, and it wins on a name collision. Only that node can supply it, so a job naming it can only run there. A cluster secret is usable on every keyed node, so it does not constrain placement.

A printed secret is scrubbed

The node running the job replaces the exact bytes in stdout, stderr, the live tail and the progress line. Base64, a hash, or a value split across a format string is not caught, so treat it as a safety net for accidents. It is not a security boundary.

Queries that say what they cost

Operators are eq, ne, lt, le, gt, ge, prefix, isnull and notnull. There is no contains, because an index cannot answer one.

• Composite primary keys, and unique indexes enforced on write.
• Equi-joins to another table's key: --join local:table, and you can filter on a joined column.
• Show a code as what it means: --label code:weather_codes:description, or declare it once per column and every client draws it. The row keeps its own value.
• Ordering requires an index on the column; nothing else has a stored order to page through.
• Aggregates (count, sum, avg, min, max) with grouping, and CSV in both directions.

Reachable from inside a job

MELANGE_API_URL is a loopback listener serving the table routes and nothing else; MELANGE_JOB_TOKEN is minted per run, dies with it, and carries the submitter’s role.

A stage waits for the one before it to succeed

A job with prerequisites is committed, placed on a node and counted as queued load, but never signalled to run until every prerequisite has succeeded.

If one fails, times out or is cancelled, the rest of the chain is cancelled. A dependency means "after this succeeds".

Fired once, whichever node is leader

One watermark check makes a whole pipeline exactly-once across a failover. A fire is all-or-nothing: if any stage's script is missing or has nowhere to run, the tick is skipped, so half a chain is never left stranded.

A table block is a bounded read

It takes the same joins the row listing does — local:table, with a joined column written table.column — so a report over a table of foreign keys shows names rather than keys, and a join matches at most one row.

• At most 100 rows a block. A report is a thing a person reads.
• A block cut short that did not ask to be says so under the table; an explicit limit is the author's answer, not a truncation to report.
• Ordering needs an index on the column, refused when you save rather than answered in some other order.
• A timestamp is rendered as a time because the schema says it is one, with the zone on the heading.

Placeholders reach text, never a query

{{day}} is filled from --value day=… in a subject, heading, paragraph, field or caption — and never in a table, joins, filters, columns or order_by. That is what keeps a stored report's cost knowable and stops whoever sends it aiming it at data it was never checked against. An unknown placeholder renders as itself, because an empty substitution makes a report that looks finished and is quietly missing a number.

Checked when you save it, and again when it sends

An unknown table or column, a join spelled backwards, an unparseable filter or an un-orderable order_by is refused while you are looking at it. If a table is dropped months later the section draws a line saying what is missing and the rest of the report still goes.

No placement cost

A secret lives on one node, so it constrains where a job can go. A library's content is replicated everywhere, so every node can honour any reference and it never enters placement at all.

Imports are detected

Submitting a script reads its own Import-Module, using module and source lines, and attaches any that name a registered library at the same runtime. --no-detect-libraries turns it off.

Checked at both ends

A name that exists nowhere is refused when the job is submitted, and checked again by the node about to run it, so a job never runs silently without its library.

Libraries are parsed when saved, so a syntax error surfaces as you upload it, before any job imports it.

Run before you upload

project run executes the script locally the way a node would: a private job directory, the vendored libraries on the import path, and the same MELANGE_JOB_DIR, MELANGE_LIB_DIR and MELANGE_CANCEL_FILE variables set.

A script belongs to its project

A script's identity is the pair (project, name), enforced when the entry is applied. Two projects can both have a nightly without one overwriting the other and taking over its schedules.

project clone takes an existing project back out of the registry.