[kvlonge]

Why

A job or sensor that lists its nodes one by one silently stops covering a pipeline when a node is added to it. Selecting a folder or a tag keeps new nodes in the run. Nothing reported these lists.

Changes

• New built-in Rule SQBRORCHESTRATION101 (named-selector-limit). It reports a job select, or the select of a node_event, source_new_data or source_stale sensor condition, that names more than max_named_selectors nodes (default 3).
• Named nodes are bare or typed names, with each name of an intersection counted. Tags, folder paths, job:, job and job group names, + expansions and globs don't count. Repeated names count once.
• A sensor's when is followed through the last module-level assignment or import before the sensor, including imports from project modules. A condition that can't be resolved is reported with what couldn't be resolved; an exact rule exception suppresses it.
• Orchestration declarations are read from disk only when the Rule is selected, and they are part of the Rules memo key.
• Docs: a new Orchestration Rules page, links from the Rules overview, Rule options and orchestration pages, and the regenerated docs skill.

Verification

• Rust tests cover the selector atoms, condition resolution (aliases, imports across modules, cycles, CRLF modules, rebinding order) and the Rule's counting, option, exception and not-selected paths.
• A CLI integration test compiles the DuckShop named-selector fixture under the default limit, a raised limit and an exact exception.
• make check-ci passed on the final head.

DuckShop: new edge-case fixture benchmarks/duckshop/edge_cases/named_selectors (listed and folder jobs, a listed sensor, a computed sensor select, and sensors whose conditions come from another module). The main DuckShop project reports no findings.