[Validation gap] Conductor Jinja inventory pin and lint enforcement
Part of #172.
Gap
Workflow YAMLs and lint-*.ps1 rules can demand Jinja constructs
(filters, globals, custom functions) that conductor's TemplateRenderer
does not actually expose at runtime. There is no inventory; we discover
the truth by crashing.
Bugs this would have caught
Implementation sketch (design TBD; this issue captures the gap)
- A small probe script that imports/instantiates conductor's
TemplateRenderer (or the equivalent entry point) and enumerates the
Jinja Environment.filters, globals, and tests registries with
their callable signatures (introspected via inspect.signature).
- Emits
conductor-jinja-inventory.json as a checked-in artifact.
- Lint refuses any Jinja construct in workflow YAMLs (or in
lint-*.ps1 allowlists) that is not in the inventory, including
arity mismatches on filter calls.
- Probe runs in CI against the conductor version polyphony pins.
Pin location
Polyphony does not currently pin a conductor SHA. The closest thing is
metadata.min_polyphony_version in each workflow YAML
(docs/decisions/versioning-strategy.md), which gates polyphony CLI
itself, not conductor. conductor registry add does not accept
--ref / --tag (per same doc). Designing where the conductor
version is pinned is part of this issue's scope. Candidates:
- A new
metadata.min_conductor_version field in workflow YAML
(parallels the existing min-polyphony pattern).
- A repo-level pin in
.conductor/profile.yaml or process-config.yaml.
- A submodule / vendored copy of the conductor source for the probe to
import.
Status
Design TBD. This issue captures the gap; no code yet.
[Validation gap] Conductor Jinja inventory pin and lint enforcement
Part of #172.
Gap
Workflow YAMLs and
lint-*.ps1rules can demand Jinja constructs(filters, globals, custom functions) that conductor's
TemplateRendererdoes not actually expose at runtime. There is no inventory; we discover
the truth by crashing.
Bugs this would have caught
severities_at_or_above(open_questions_policy.output.min_severity),a function conductor never registered. Both lint and YAML "agreed,"
conductor crashed at render time.
default(0, true)(the standard Jinjatwo-arg form to coerce
None → 0) crashed because conductor's_default_filter(conductor/src/conductor/executor/template.py:82)accepts only 2 positional args in a non-standard arity. Workflow had
to revert to bare
default(0)and accept theNone-vs-Undefinedasymmetry.
Implementation sketch (design TBD; this issue captures the gap)
TemplateRenderer(or the equivalent entry point) and enumerates theJinja
Environment.filters,globals, andtestsregistries withtheir callable signatures (introspected via
inspect.signature).conductor-jinja-inventory.jsonas a checked-in artifact.lint-*.ps1allowlists) that is not in the inventory, includingarity mismatches on filter calls.
Pin location
Polyphony does not currently pin a conductor SHA. The closest thing is
metadata.min_polyphony_versionin each workflow YAML(
docs/decisions/versioning-strategy.md), which gates polyphony CLIitself, not conductor.
conductor registry adddoes not accept--ref/--tag(per same doc). Designing where the conductorversion is pinned is part of this issue's scope. Candidates:
metadata.min_conductor_versionfield in workflow YAML(parallels the existing min-polyphony pattern).
.conductor/profile.yamlorprocess-config.yaml.import.
Status
Design TBD. This issue captures the gap; no code yet.