[fas89]

What and why

Follow-ups #734 documented instead of fixing: fluid validate, the build runners and fluid scaffold-composer did not know trigger.type: continuous.

A continuous trigger on a build forge-cli runs as a batch run is a validation warning (the user's decision: warn, not refuse). A continuous trigger says the job's platform keeps it running, so no scheduler starts the build; forge-cli's batch runners run a build to completion. Plain fluid validate passes and --strict fails:

 1. builds[0] (id 'customer360_build'): trigger.type continuous on engine 'dbt': forge-cli runs dbt builds as batch runs, which end, and its dbt runner refuses a continuous trigger: forge-cli never runs this build. Use trigger.type schedule or manual, or run the job on a platform that keeps it running.

fluid validate and fluid apply read one predicate (build_runners/base.py::_batch_runner_for), in the dispatcher's order:

Continuous build	fluid apply --mode amend-and-build	fluid validate
dbt, dbt-<adapter>, python, and everything else the python runner takes: no engine, a local spark / glue / custom script, an ingestion engine without pattern: acquisition	the runner refuses it by name (exit 1)	warns (names a missing pattern: acquisition)
inline SQL on local DuckDB or Snowflake; duckdb / airbyte / meltano / dlt acquisition	runs it once	warns
kafka-connect / debezium acquisition	deploys the connector, which keeps running	—
Flink (engine: flink, language: flink_sql)	left to its platform (unchanged)	—
spark / glue / custom that names a runtime.platform other than local; inline SQL on a platform with no embedded-SQL executor	new: left to that platform like a Flink job (Run outside forge-cli: 1, run report skipped / runs_outside_forge); used to reach the python runner or the SQL executor and fail	—

• The streaming set is pinned against the runners' own declared_capabilities (RunnerCapability.STREAMING). A parity test runs the real dispatcher over every engine and pattern, and another checks that the python runner still receives every local script.
• EMBEDDED_SQL_PLATFORMS is the one list the inline-SQL executor and the warning read.
• The dbt and python runners print one refusal (refuse_continuous_trigger) with the warning's remedy, instead of Unknown trigger type: continuous / Supported types: manual, schedule. The dbt runner refuses before it resolves a profile.
• A crash in the check is a warning that says the contract was not checked.

fluid scaffold-composer writes no DAG for a contract whose every build is continuous or runs outside forge-cli, unless it declares orchestration.tasks (the test fluid generate schedule applies, through the shared util/contract.has_only_unscheduled_builds), and says so. It names a DAG it wrote before (recognised by the template's tags=["FLUID"] and the dag_id; a same-named file it did not write is not claimed) and leaves it in place; the path prints whole and literally (soft_wrap, markup=False, emoji=False). Otherwise the DAG takes the cron of the first build a scheduler starts, not a Flink job's own cron.

Borrowed, not built

• Spark UnsupportedOperationChecker.checkForContinuous: a continuous trigger is checked against what the engine can run before anything starts, and the refusal names what it cannot run.
• Databricks INFINITE_STREAMING_TRIGGER_NOT_SUPPORTED: where a job cannot be kept running, the continuous trigger is refused by name, with the alternative.
• In repo: is_unscheduled_build / is_continuous_build (feat: trigger.type continuous (0.7.6 preview) is never scheduled; --strict fails on a retargeted overlay patch #734), the dispatch predicates and _report_externally_run_build in build_runners/base.py, the runners' declared_capabilities, the (errors, warnings) validator shape of the Iceberg / governance gates, and generate schedule's "nothing to schedule". Strategy: adapt the pattern; no new dependency.

Validation

• Tests: tests/test_continuous_trigger.py 26 → 107. Each round's fix was red first: the stale-DAG path fold, the :emoji:/[/] out-dir, the dispatcher parity (6 engine shapes), inline SQL on databricks, the explicit-tasks DAG, the foreign same-named file, the python-runner handoff (10 tests red on the round-2 commit). Every commit is green on its own.
• Gates (local): ruff (incl. the dead-code gate), black 24.10.0, scripts/mypy_strict.py, import-linter (6 kept), license headers, product guardrail (0 failing). Affected suites (58 files/dirs, ~5.9k tests): failures equal clean main id-for-id in this venv (19 failed + 10 errors: dlt SDK, sqlglot, tmp-root naming). tests/perf: the module budget passes (1018 modules on both trees); the 3 wall-clock budgets fail on clean main too at load average ~145.
• Live CLI (copies of examples/customer360 and examples/02-csv-to-data-product, plus python/spark/no-engine contracts):
  • continuous dbt: validate exit 0 with the warning, --strict exit 1, --quiet --strict names it, --format json lists it, the bundle report counts it; apply --mode amend-and-build refuses before any profile (exit 1).
  • continuous inline SQL: warned; plain apply and --mode amend-and-build each run it once.
  • continuous python / no engine: warned; refused, the script never runs.
  • continuous spark with a local script, and dlt without pattern: acquisition: warned (--strict exit 1), refused (exit 1), the script never runs. Continuous spark on runtime.platform: databricks: no warning, apply --mode amend-and-build exit 0, Run outside forge-cli: 1.
  • scaffold-composer: Flink-only or continuous-only contract → no DAG, no --out-dir; after a scheduled run wrote a DAG, the next run names it and keeps it; a foreign same-named file is not named; a 0.7.5 flink_sql + dbt contract takes the dbt cron (0 3, was the Flink 0 5); generate schedule unchanged.
• ripwire --quality-delta: gating rows left are _run_contract_rules growing by one rule block in its existing pattern, and per-module test helpers flagged as duplication (house style).

Reviews

• Security review (Opus): no HIGH or MEDIUM. Fixed: the no-DAG message claimed any same-named file as ours. Pre-existing, listed below: scaffold-composer overwrites a colliding file; the runners print the contract's trigger.type with Rich markup on.
• Defect hunt (Opus, reproduced findings only): fixed the validate/dispatcher disagreement (spark/glue/custom, ingestion engines without the acquisition pattern, no engine), inline SQL on executor-less platforms, the explicit-tasks divergence, the run-once wording, the differing remedies, a terminal-width-dependent assertion.
• Round 2 re-review (Opus): confirmed the round-1 fixes (6,624 mocked dispatches across 23 engines, 8 patterns and 9 platforms agreed with validate), and found that skipping every python-runner build as "outside forge-cli" reported success for dlt / local spark scripts that run when manual. Round 3 keeps them on the python runner (warned + refused) and skips only builds that name a platform of their own. A pre-security: fix injection/RCE/RLS findings (scheduler, IaC, MCP, build-runners, providers) #215 DAG file name is not matched; the CHANGELOG says so.
• Round 3 verification (Opus): F1 and F2 confirmed fixed. Of 16,830 recorded dispatches, no non-continuous build changed runner against main, and every continuous build is warned exactly when a batch runner takes it. Two LOW wording items fixed: the CHANGELOG's platform exception excludes inline SQL, and the warning for spark / glue / custom names execution.runtime.platform.

Documentation

• Docs PR linked: docs: a continuous trigger on a batch build warns; scaffold-composer schedules only scheduled builds (forge-cli #737) forge_docs#159 (validate warning section, Continuous builds bullet, scaffold-composer notes; merge after this PR)
• No docs needed
• Docs TODO

Not in this PR

• fluid scaffold-composer reads only trigger.cron, not trigger.schedule (documented on its page); it overwrites a colliding file it did not write.
• The dbt and python runners print the contract's trigger.type (the Trigger: and Unknown trigger type lines) with Rich markup on.
• fluid verify still expects a dbt run record for a continuous dbt build, which fluid apply refuses.
• With no dbt project or script found, a continuous dbt/python build is reported as skipped, not refused.
• fluid validate workspace mode runs no contract rules (documented), so it does not show this warning either.
• A DAG deployed before a product went all-continuous is not retired by stage 11 (upgrade note kept).

[github-actions]

📄 Documentation Reminder

This PR appears to be missing a documentation reference. Our docs live in a separate repo.

Please update the PR description with one of:

• Link a docs PR — check the "Docs PR linked" box and paste the URL
• Mark as no docs needed — check "No docs needed" with a justification
• Acknowledge docs TODO — check "Docs TODO" and create the docs PR before merge

See the Contributing Guide for details.