Update docs for implicit/naked tasks

src/glossary.rst

@@ -412,6 +412,29 @@ Glossary
       * :term:`job`
       * :term:`qualifier`
 
+   implicit task
+   naked task
+      An implicit task is a task in the graph that does not have an explicit
+      runtime definition. For example, ``bar`` is an implicit task in the
+      following workflow:
+
+      .. code-block:: cylc
+
+         [scheduling]
+             [[graph]]
+                 R1 = foo & bar
+         [runtime]
+             [[foo]]
+
+      Implicit tasks are not allowed by default, as they are often typos.
+      However, it is possible to allow them using
+      :cylc:conf:`flow.cylc[scheduler]allow implicit tasks` during
+      development of a workflow.
+
+      See also:
+
+      * :ref:`ImplicitTasks`
+
    run directory
       When a :term:`suite <Cylc suite>` is run a directory is created for all
       of the files generated whilst the suite is running. This is called the

src/user-guide/writing-suites/runtime.rst

@@ -390,7 +390,7 @@ Remote Task Hosting
 -------------------
 
 If a task declares a different platform to the one running the workflow,
-Cylc will use non-interactive ssh to execute the task using the 
+Cylc will use non-interactive ssh to execute the task using the
 :term:`job runner` and one of the hosts from the :term:`platform` definition
 (platforms are defined in ``global.cylc[platforms]``).
 
@@ -444,27 +444,30 @@ Remote task log directories, like local ones, are created on the fly, if
 necessary, during job submission.
 
 
-Naked Dummy Tasks And Strict Validation
----------------------------------------
+.. _ImplicitTasks:
 
-A *naked dummy task* appears in the suite graph but has no
+Implicit Tasks
+--------------
+
+An :term:`implicit task` appears in the workflow graph but has no
 explicit runtime configuration section. Such tasks automatically
 inherit the default "dummy task" configuration from the root
 namespace. This is very useful because it allows functional suites to
 be mocked up quickly for test and demonstration purposes by simply
 defining the graph. It is somewhat dangerous, however, because there
-is no way to distinguish an intentional naked dummy task from one
-generated by typographic error: misspelling a task name in the graph
-results in a new naked dummy task replacing the intended task in the
-affected trigger expression; and misspelling a task name in a runtime
-section heading results in the intended task becoming a dummy task
+is no way to distinguish an intentional implicit task from one
+caused by typographic error. Misspelling a task name in the graph
+results in a new implicit task replacing the intended task in the
+affected trigger expression, and misspelling a task name in a runtime
+section heading results in the intended task becoming an implicit task
 itself (by divorcing it from its intended runtime config section).
 
-To avoid this problem any dummy task used in a real suite should not be
-naked - i.e. it should have an explicit entry in under the runtime
-section of the suite configuration, even if the section is empty. This
-results in exactly the same dummy task behaviour, via implicit
-inheritance from root, but it allows use of
-``cylc validate --strict``
-to catch errors in task names by failing the suite if any naked dummy
-tasks are detected.
+You can allow implicit tasks during development of a workflow using
+:cylc:conf:`flow.cylc[scheduler]allow implicit tasks`. But, to avoid
+the problems mentioned above, any task used in a production/operational
+workflow should not be implicit, i.e. it should have an explicit entry in under
+the runtime section of ``flow.cylc``, even if the section is empty. This
+results in exactly the same dummy task behaviour, via inheritance from root,
+but adds a layer of protection against mistakes. Thus, it is recommended to
+turn off :cylc:conf:`flow.cylc[scheduler]allow implicit tasks` when the
+:cylc:conf:`flow.cylc[runtime]` section has been written.