From c4de82e80e32b9eaf2abbd055a93d2ebb7303087 Mon Sep 17 00:00:00 2001
From: Ole Herman Schumacher Elgesem <ole@northern.tech>
Date: Tue, 5 Aug 2025 14:08:10 +0200
Subject: [PATCH] Fixed / skipped policy snippets

Working with new tooling to check syntax of inline examples / snippets.
In most cases where the snippet was never intended to be valid syntax,
where there is no obvious fix without a bigger rewrite,
I am simply adding skip TODO flags to get back to them later.

Signed-off-by: Ole Herman Schumacher Elgesem <ole@northern.tech>
---
 cheatsheet.markdown                           |  3 +-
 content/examples/_index.markdown              |  6 +-
 .../example_aborting_execution.markdown       |  2 +-
 ...ute-files-from-a-central-location.markdown |  2 +-
 .../integrating-with-sumo-logic.markdown      | 10 +--
 .../json-yaml-support-in-cfengine.markdown    |  6 +-
 .../examples/tutorials/manage-ntp.markdown    | 50 +++++++--------
 ...der-files-with-mustache-templates.markdown |  2 +-
 .../reporting/command-line-reports.markdown   |  2 +-
 content/examples/tutorials/tags.markdown      |  4 +-
 .../tutorials/write-cfengine-policy.markdown  | 33 +++++-----
 ...thoring-policy-tools-and-workflow.markdown |  2 +-
 .../policy-style.markdown                     |  2 +-
 content/reference/components/_index.markdown  |  8 +--
 .../reference/components/cf-agent.markdown    | 10 +--
 .../reference/components/cf-serverd.markdown  | 14 ++---
 content/reference/macros.markdown             | 18 +++---
 .../additional-topics/devops.markdown         | 35 +++++------
 .../distributed-scheduling.markdown           | 12 ++--
 .../additional-topics/file-content.markdown   |  4 +-
 .../additional-topics/hierarchies.markdown    |  2 +-
 .../additional-topics/open-nebula.markdown    | 62 +++++++++----------
 .../faq/fix-undefined-body-error.markdown     |  2 +-
 23 files changed, 142 insertions(+), 149 deletions(-)

diff --git a/cheatsheet.markdown b/cheatsheet.markdown
index 339c67597..600dd8693 100644
--- a/cheatsheet.markdown
+++ b/cheatsheet.markdown
@@ -246,8 +246,7 @@ Linux
 ```
 
 You might also specify output syntax highlighting by adding language
-after the starting backticks and placing `[output]` in the first line.
-This line won't be shown in the resulted HTML.
+after the starting backticks and placing `{output}` at the end of the line.
 
 ```command
 curl --user admin:admin https://test.cfengine.com/api/user
diff --git a/content/examples/_index.markdown b/content/examples/_index.markdown
index a87842b8e..07044603c 100644
--- a/content/examples/_index.markdown
+++ b/content/examples/_index.markdown
@@ -219,7 +219,7 @@ from the example.
 3. Insert the example's bundle name in the `bundlesequence` section
    of the main policy file `/var/cfengine/masterfiles/promises.cf`:
 
-   ```cf3
+   ```cf3 {skip TODO}
    bundlesequence => {
        ...
        "hello_world",
@@ -230,7 +230,7 @@ from the example.
 4. Insert the policy file name in the [`inputs`][Components#inputs] section of the main policy file
    `/var/cfengine/masterfiles/promises.cf`:
 
-   ```cf3
+   ```cf3 {skip TODO}
    inputs => {
        ...
        "hello_world.cf",
@@ -241,7 +241,7 @@ from the example.
 5. You must also remove any inputs section from the example that
    includes the external library:
 
-   ```cf3
+   ```cf3 {skip TODO}
    inputs => {
        "libraries/cfengine_stdlib.cf"
    };
diff --git a/content/examples/example-snippets/promise-patterns/example_aborting_execution.markdown b/content/examples/example-snippets/promise-patterns/example_aborting_execution.markdown
index 0f3b01864..a2eda0b5c 100644
--- a/content/examples/example-snippets/promise-patterns/example_aborting_execution.markdown
+++ b/content/examples/example-snippets/promise-patterns/example_aborting_execution.markdown
@@ -42,7 +42,7 @@ Copy and paste `abortbundleclasses => { "invalid" };` into
 `/var/cfengine/masterfiles/controls/cf_agent.cf`. If you add it to
 the end of the file it should look something like this:
 
-```cf3
+```cf3 {skip TODO}
 ...
     #  dryrun => "true";
 
diff --git a/content/examples/tutorials/distribute-files-from-a-central-location.markdown b/content/examples/tutorials/distribute-files-from-a-central-location.markdown
index 3c2552854..a3bfdbb53 100644
--- a/content/examples/tutorials/distribute-files-from-a-central-location.markdown
+++ b/content/examples/tutorials/distribute-files-from-a-central-location.markdown
@@ -46,7 +46,7 @@ These variables provide path definitions for storing and deploying patches.
 
 Add the following variable information to the `masterfiles/def.cf` file:
 
-```cf3 {file="def.cf"}
+```cf3 {file="def.cf" skip TODO}
 "dir_patch_store"
   string => "/storage/patches",
   comment => "Define patch files source location",
diff --git a/content/examples/tutorials/integrating-with-sumo-logic.markdown b/content/examples/tutorials/integrating-with-sumo-logic.markdown
index b42275007..09fafd96a 100644
--- a/content/examples/tutorials/integrating-with-sumo-logic.markdown
+++ b/content/examples/tutorials/integrating-with-sumo-logic.markdown
@@ -29,7 +29,7 @@ First, we define a couple of variables.
 
 The two Sumo variables are used to access the service, while the `curl_args` is the actual curl command that will upload our timestamp file to Sumo Logic.
 
-```cf3
+```cf3 {skip TODO}
 vars:
   "policy_update_file"
     string => "/tmp/CFEngine_policy_updated";
@@ -47,7 +47,7 @@ We also ensures that the content of this file will be the value of the `sys.last
 
 Finally, below you will see a body defining how CFEngine is going to detect changes in policy files, this time using an md5 hash and only looking for change in the content (not permissions or ownership).
 
-```cf3
+```cf3 {skip TODO}
 files:
  "$(policy_update_file)"
   create => "true",
@@ -71,7 +71,7 @@ The final section in the CFEngine policy is where the command that uploads the f
 
 The command will only be issued whenever a class called `new_policy_update` is set, which we above defined to be set when there is a change detection. The handle argument is a useful way to document your intentions.
 
-```cf3
+```cf3 {skip TODO}
 commands:
   new_policy_update::
     "/usr/bin/curl"
@@ -105,7 +105,7 @@ Normally, to ensure your policy file is put into action, you would need to follo
 
 Under the body common control, add `sumo_logic_policy_update` to your bundle sequence.
 
-```cf3
+```cf3 {skip TODO}
 body common control
 
 {
@@ -118,7 +118,7 @@ body common control
 
 Under body common control, add /sumologic_policy_update.cf/ to your inputs section.
 
-```cf3
+```cf3 {skip TODO}
 inputs => {
            # File definition for global variables and classes
            "sumologic_policy_update.cf",
diff --git a/content/examples/tutorials/json-yaml-support-in-cfengine.markdown b/content/examples/tutorials/json-yaml-support-in-cfengine.markdown
index ab3ec97d9..87ff02292 100644
--- a/content/examples/tutorials/json-yaml-support-in-cfengine.markdown
+++ b/content/examples/tutorials/json-yaml-support-in-cfengine.markdown
@@ -109,13 +109,13 @@ through them and look up values.
 
 Well, you can change
 
-```cf3
+```cf3 {skip TODO}
 "bykey" data => parsejson('{ "dev": ["c", "b"], "prod": ["flea"], "qa": ["a"], "private": ["linux"] }');
 ```
 
 with
 
-```cf3
+```cf3 {skip TODO}
 "bykey" data => data_readstringarray(...);
 ```
 
@@ -131,7 +131,7 @@ private linux
 
 You can also use
 
-```cf3
+```cf3 {skip TODO}
 "bykey" data => readjson(...);
 ```
 
diff --git a/content/examples/tutorials/manage-ntp.markdown b/content/examples/tutorials/manage-ntp.markdown
index 9731c2d2a..a22e696a2 100644
--- a/content/examples/tutorials/manage-ntp.markdown
+++ b/content/examples/tutorials/manage-ntp.markdown
@@ -34,7 +34,7 @@ You can think of bundles as a collection of desired states. You can have as many
 
 #### vars
 
-```cf3
+```cf3 {skip TODO}
 vars:
 ```
 
@@ -42,7 +42,7 @@ vars:
 
 ##### ntp_package_name
 
-```cf3
+```cf3 {skip TODO}
 "ntp_package_name" string => "ntp";
 ```
 
@@ -50,7 +50,7 @@ A variable with the name `ntp_package_name` is declared and it is assigned a val
 
 #### packages
 
-```cf3
+```cf3 {skip TODO}
 packages:
     "$(ntp_package_name)"   -> { "StandardsDoc 3.2.1" }
       policy          => "present",
@@ -62,7 +62,7 @@ packages:
 
 ##### $(ntp_package_name)
 
-```
+```cf3 {skip TODO}
 "$(ntp_package_name)"   -> { "StandardsDoc 3.2.1" }
 ```
 
@@ -72,7 +72,7 @@ This promiser has a number of additional attributes defined:
 
 ###### policy
 
-```cf3
+```cf3 {skip TODO}
 policy          => "present",
 ```
 
@@ -80,7 +80,7 @@ policy          => "present",
 
 ###### handle
 
-```cf3
+```cf3 {skip TODO}
 handle          => "ntp_packages_$(ntp_package_name)",
 ```
 
@@ -88,7 +88,7 @@ The handle uniquely identifies a promise within a policy. A recommended naming s
 
 ###### classes
 
-```cf3
+```cf3 {skip TODO}
 classes         => results("bundle", "ntp_package_");
 ```
 
@@ -134,16 +134,10 @@ Validate it.
 python -m json.tool < def.json
 ```
 
-```output
+```json {output}
 {
-    "inputs": [
-        "services/ntp.cf"
-    ],
-    "vars": {
-        "control_common_bundlesequence_end": [
-            "ntp"
-        ]
-    }
+  "inputs": ["services/ntp.cf"],
+  "vars": { "control_common_bundlesequence_end": ["ntp"] }
 }
 ```
 
@@ -213,7 +207,7 @@ Let's dissect this policy and review the differences in the policy.
 
 #### vars
 
-```cf3
+```cf3 {skip TODO}
 redhat::
     "ntp_service_name" string => "ntpd";
 debian::
@@ -224,7 +218,7 @@ The first thing that you will notice is that the variable declarations section h
 
 #### reports
 
-```cf3
+```cf3 {skip TODO}
 reports:
   ntp_service_repaired.inform_mode::
     "NTP service repaired";
@@ -238,7 +232,7 @@ ntp_service_repaired.inform_mode::
 
 This line restricts the context for the promises that follow to hosts that have `ntp_service_repaired` and `inform_mode` defined. Note: `inform_mode` is defined when information level logging is requested, e.g. the `-I`, `--inform`, or `--log-level inform` options are given to `cf-agent` defined.
 
-```cf3
+```cf3 {skip TODO}
 "NTP service repaired";
 ```
 
@@ -360,7 +354,7 @@ Let's review the different sections of the code, starting with the variable decl
 
 #### vars
 
-```cf3
+```cf3 {skip TODO}
    vars:
      linux::
        "ntp_package_name" string => "ntp";
@@ -390,7 +384,7 @@ A few new variables are defined. The variables `ntp_package_name`, `config_file`
 
 Now let's walk through the files promise in detail.
 
-```cf3
+```cf3 {skip TODO}
 files:
  "$(config_file)"
    create                => "true",
@@ -406,7 +400,7 @@ The promiser here is referenced by the `config_file` variable. In this case, it
 
 ##### create
 
-```cf3
+```cf3 {skip TODO}
 create                => "true",
 ```
 
@@ -414,7 +408,7 @@ Valid values for this attribute are `true` or `false` to instruct the agent whet
 
 ##### perms
 
-```cf3
+```cf3 {skip TODO}
 perms                 => mog( "644", "root", "root" ),
 ```
 
@@ -422,7 +416,7 @@ This attribute sets the permissions and ownership of the file. [`mog()`][stdlib-
 
 ##### handle
 
-```cf3
+```cf3 {skip TODO}
 handle                => "ntp_files_conf",
 ```
 
@@ -430,7 +424,7 @@ A handle uniquely identifies a promise within a policy set. The [policy style gu
 
 ##### classes
 
-```cf3
+```cf3 {skip TODO}
 classes               => results( "bundle", "ntp_config" );
 ```
 
@@ -438,7 +432,7 @@ The classes attribute here uses the [`results()`][lib/common.cf#results] classes
 
 ##### template_method
 
-```cf3
+```cf3 {skip TODO}
 template_method       => "inline_mustache",
 ```
 
@@ -446,7 +440,7 @@ CFEngine supports multiple templating engines, the [template_method][files#templ
 
 ##### edit_template_string
 
-```cf3
+```cf3 {skip TODO}
 edit_template_string  => "$(config_template_string)",
 ```
 
@@ -454,7 +448,7 @@ The `edit_template_string` attribute is set to `$(config_template_string)` which
 
 ##### template_data
 
-```cf3
+```cf3 {skip TODO}
 template_data         => mergedata( '{ "driftfile": "$(driftfile)", "servers": servers }' ),
 ```
 
diff --git a/content/examples/tutorials/render-files-with-mustache-templates.markdown b/content/examples/tutorials/render-files-with-mustache-templates.markdown
index ccac0e57a..a6e16a8b2 100644
--- a/content/examples/tutorials/render-files-with-mustache-templates.markdown
+++ b/content/examples/tutorials/render-files-with-mustache-templates.markdown
@@ -78,7 +78,7 @@ bundle agent myapp_confs
           }
     ');
 }
-body agent __main__
+bundle agent __main__
 {
   methods:
     "myapp_confs";
diff --git a/content/examples/tutorials/reporting/command-line-reports.markdown b/content/examples/tutorials/reporting/command-line-reports.markdown
index fb30000d7..bcf42fc54 100644
--- a/content/examples/tutorials/reporting/command-line-reports.markdown
+++ b/content/examples/tutorials/reporting/command-line-reports.markdown
@@ -176,7 +176,7 @@ reports:
 
 A bonus to this is that you can get CFEngine to report system anomalies:
 
-```cf3
+```cf3 {skip TODO}
 reports:
 
  rootprocs_high_dev2::
diff --git a/content/examples/tutorials/tags.markdown b/content/examples/tutorials/tags.markdown
index 67e929ee6..f1f1d7eab 100644
--- a/content/examples/tutorials/tags.markdown
+++ b/content/examples/tutorials/tags.markdown
@@ -114,7 +114,7 @@ way to categorize various data accessible to the agent.
 Dynamic bundlesequences are extremely easy. First you find all the bundles whos
 name matches a regular expression and N tags.
 
-```cf3
+```cf3 {skip TODO}
 vars:
   "bundles" slist => bundlesmatching("regex", "tag1", "tag2", ...);
 ```
@@ -122,7 +122,7 @@ vars:
 Then every bundle matching the regular expression `regex` and **all**
 the tags will be found and run.
 
-```cf3
+```cf3 {skip TODO}
 methods:
   "run $(bundles)" usebundle => $(bundles);
 ```
diff --git a/content/examples/tutorials/write-cfengine-policy.markdown b/content/examples/tutorials/write-cfengine-policy.markdown
index 542719203..f6b5c5fb8 100644
--- a/content/examples/tutorials/write-cfengine-policy.markdown
+++ b/content/examples/tutorials/write-cfengine-policy.markdown
@@ -20,10 +20,10 @@ detailed information see the Language concepts section of the Reference manual.
 
 ### Bundles
 
-Bundles are re-usable and blocks of CFEngine policy. The following defines a _bundle_ called `my_test`, and it is a bundle for the agent.
+Bundles are re-usable and blocks of CFEngine policy. The following defines a _bundle_ called `example`, and it is a bundle for the agent.
 
 ```cf3
-bundle agent my_test
+bundle agent example
 {
   # ...
 }
@@ -45,9 +45,12 @@ do some file configuration for example, you would use the files promise type.
 The following policy ensures the existence of the `/tmp/hello-world` file:
 
 ```cf3
-files:
-  "/tmp/hello-world"
-    create => "true";
+bundle agent example
+{
+  files:
+    "/tmp/hello-world"
+      create => "true";
+}
 ```
 
 When defining desired states it is important to be clear about when and where
@@ -75,8 +78,8 @@ Now let's put the bundle, promise type and class components together in a
 final policy. As for classes we will use linux to define that the file
 `/tmp/hello-world` must exists on all hosts of type _linux_:
 
-```cf3 {file="my_test.cf"}
-bundle agent my_test
+```cf3 {file="example.cf"}
+bundle agent example
 {
   files:
     linux::
@@ -86,11 +89,11 @@ bundle agent my_test
 
 bundle agent __main__
 {
-  methods: "my_test";
+  methods: "example";
 }
 ```
 
-Let's save this policy in `/tmp/my-policy.cf`.
+Let's save this policy in `/tmp/example.cf`.
 
 You can now run this policy either in Distributed (client-server) System or in a
 Stand Alone system. The next two sections will cover each of the options.
@@ -109,13 +112,13 @@ this as it is the same cf-agent that runs on the hosts as on the Policy Server.
 command to run a syntax check:
 
 ```command
-cf-promises -f /tmp/my-policy.cf
+cf-promises -f /tmp/example.cf
 ```
 
 Unless you get any output, the syntax is correct. Now, to run this policy, simply type:
 
 ```command
-cf-agent -Kf /tmp/my-policy.cf
+cf-agent -Kf /tmp/example.cf
 ```
 
 As you can see, the response is immediate! Running CFEngine locally like this is
@@ -130,7 +133,7 @@ If you want to see what the agent is doing during its run, you can run the agent
 in verbose mode. Try:
 
 ```command
-cf-agent -Kf /tmp/my-policy.cf --verbose
+cf-agent -Kf /tmp/example.cf --verbose
 ```
 
 In a Stand Alone system, to make and run a policy remember to:
@@ -154,7 +157,7 @@ directory. When the content changes, cf-agent will download the updated files to
 
 This means that by default you should store all your policies in the
 `/var/cfengine/masterfiles` directory on your policy server. So, now create
-`/var/cfengine/masterfiles/my-policy.cf` with the content of the test policy
+`/var/cfengine/masterfiles/example.cf` with the content of the test policy
 previously authored.
 
 **NOTE:** We recommend that you use a version control system to store the audit
@@ -166,7 +169,7 @@ Now we need to tell CFEngine that there is a new policy in town:
 
 ```json {file="def.json"}
 {
-  "inputs": ["my-policy.cf"]
+  "inputs": ["example.cf"]
 }
 ```
 
@@ -182,7 +185,7 @@ any of the bootstrapped clients and you will find the `/tmp/-hello-world` file
 there.
 
 Whenever a host connects to the Policy Server, the host will ensure that it has
-the `my-policy.cf` file from the masterfiles directory exists in the local
+the `example.cf` file from the masterfiles directory exists in the local
 inputs directory. `def.json` will also be downloaded with the new
 instruction that there is a new policy. Within 5 minutes, whether you have 5
 Linux hosts or 50,000 Linux hosts, they will all have the `/tmp/hello-world` file
diff --git a/content/examples/tutorials/writing-and-serving-policy/authoring-policy-tools-and-workflow.markdown b/content/examples/tutorials/writing-and-serving-policy/authoring-policy-tools-and-workflow.markdown
index e460f59d7..e1a4896dd 100644
--- a/content/examples/tutorials/writing-and-serving-policy/authoring-policy-tools-and-workflow.markdown
+++ b/content/examples/tutorials/writing-and-serving-policy/authoring-policy-tools-and-workflow.markdown
@@ -124,7 +124,7 @@ body contain masterfiles_contain
 3. Save the file.
 4. Add bundle and file information to `/var/cfengine/masterfiles/promises.cf`. Example (where `...` represents existing text in the file, omitted for clarity):
 
-```cf3 {file="promises.cf"}
+```cf3 {file="promises.cf" skip TODO}
 body common control
 
 {
diff --git a/content/examples/tutorials/writing-and-serving-policy/policy-style.markdown b/content/examples/tutorials/writing-and-serving-policy/policy-style.markdown
index 532cbabae..6a2ba2a15 100644
--- a/content/examples/tutorials/writing-and-serving-policy/policy-style.markdown
+++ b/content/examples/tutorials/writing-and-serving-policy/policy-style.markdown
@@ -512,7 +512,7 @@ bundle agent satellite_bootstrap_main
 {
 
 @if feature(this_is_not_the_feature_your_looking_for)
-   Hello there.
+   some_promise: "foo" unknown => "bar";
 @endif
 
   meta:
diff --git a/content/reference/components/_index.markdown b/content/reference/components/_index.markdown
index 90ff9b02a..da450c582 100644
--- a/content/reference/components/_index.markdown
+++ b/content/reference/components/_index.markdown
@@ -90,7 +90,7 @@ bundles act like characteristics of the systems. If you want
 different systems to have different `bundlesequences`, distinguish
 them with classes
 
-```cf3
+```cf3 {skip TODO}
 webservers::
 
   bundlesequence => { "main", "web" };
@@ -183,7 +183,7 @@ runs of e.g. `cf-agent` and `cf-promises`.
 
 **Example:**
 
-```cf3
+```cf3 {skip TODO}
 cache_system_functions => "true";
 ```
 
@@ -251,7 +251,7 @@ sequence do not exist, ignore and continue.
 
 **Example:**
 
-```cf3
+```cf3 {skip TODO}
 ignore_missing_bundles => "true";
 ```
 
@@ -283,7 +283,7 @@ not found.
 
 **Example:**
 
-```cf3
+```cf3 {skip TODO}
 ignore_missing_inputs => "true";
 ```
 
diff --git a/content/reference/components/cf-agent.markdown b/content/reference/components/cf-agent.markdown
index d41063e2b..cde2f4922 100644
--- a/content/reference/components/cf-agent.markdown
+++ b/content/reference/components/cf-agent.markdown
@@ -297,7 +297,7 @@ the control section are hard-classes.
 
 **Example:**
 
-```cf3
+```cf3 {skip TODO}
 any::
 
   addclasses => { "My_Organization" }
@@ -329,7 +329,7 @@ rather than a security measure.
 
 **Example:**
 
-```cf3
+```cf3 {skip TODO}
 agentaccess => { "mark", "root", "sudo" };
 ```
 
@@ -357,7 +357,7 @@ syslog facility level.
 
 **Example:**
 
-```cf3
+```cf3 {skip TODO}
 agentfacility => "LOG_USER";
 ```
 
@@ -449,7 +449,7 @@ be given as the argument, not the device name.
 
 **Example:**
 
-```cf3
+```cf3 {skip TODO}
 bindtointerface => "192.168.1.1";
 ```
 
@@ -709,7 +709,7 @@ bundle agent one
 
 Some interactive programs insist on values being set, for example:
 
-```cf3
+```cf3 {skip TODO}
 # Required by apt-cache, debian
 
 environment => { "LANG=C" };
diff --git a/content/reference/components/cf-serverd.markdown b/content/reference/components/cf-serverd.markdown
index 54b59f19b..b4dddc6c4 100644
--- a/content/reference/components/cf-serverd.markdown
+++ b/content/reference/components/cf-serverd.markdown
@@ -69,7 +69,7 @@ See also the warning about regular expressions in
 
 **Examples**:
 
-```cf3
+```cf3 {skip TODO}
 allowconnects => {
      "127.0.0.1",
      "::1",
@@ -101,7 +101,7 @@ will potentially match more than one hostname (e.g.,
 
 **Examples**:
 
-```cf3
+```cf3 {skip TODO}
 allowallconnects      => {
      "127.0.0.1",
      "::1",
@@ -117,7 +117,7 @@ that are not using the latest protocol.
 
 To define subnets or address ranges, use CIDR notation:
 
-```cf3
+```cf3 {skip TODO}
 allowlegacyconnects =>  { "192.168.1.0/24", "192.168.2.123" }
 ```
 
@@ -127,7 +127,7 @@ for compatibility with pre-3.6 CFEngine versions.
 Set this attribute to an empty list to not allow any incoming connections
 using legacy protocol versions:
 
-```cf3
+```cf3 {skip TODO}
 allowlegacyconnects => { }
 ```
 
@@ -216,7 +216,7 @@ correspond to system identities on the server-side system.
 
 **Example:**
 
-```cf3
+```cf3 {skip TODO}
 allowusers => { "cfengine", "root" };
 ```
 
@@ -233,13 +233,13 @@ be given as the argument, not the device name.
 
 **Allowed input range:** (arbitrary string)
 
-```cf3
+```cf3 {skip TODO}
 bindtointerface => "192.168.1.1";
 ```
 
 To bind to all interfaces, including IPV6:
 
-```cf3
+```cf3 {skip TODO}
 bindtointerface => "::";
 ```
 
diff --git a/content/reference/macros.markdown b/content/reference/macros.markdown
index 0fb77fe07..f5d0992ed 100644
--- a/content/reference/macros.markdown
+++ b/content/reference/macros.markdown
@@ -28,7 +28,7 @@ bundle agent extractor
 {
 @if minimum_version(3.8)
 # the function `new_function_3_8()` was introduced in 3.8
-vars: "container" data => new_function_3_8(...);
+vars: "container" data => new_function_3_8();
 @endif
 }
 ```
@@ -47,7 +47,7 @@ bundle agent extractor
 @if maximum_version(3.15)
   # This policy will only be parsed on versions 3.15 and earlier
   vars:
-    "container" data => old_function_3_15(...);
+    "container" data => old_function_3_15();
 @endif
 }
 ```
@@ -68,7 +68,7 @@ bundle agent extractor
 @if at_version(3.15)
   # This policy will only be parsed on 3.15 clients
   vars:
-    "container" data => old_function_3_15(...);
+    "container" data => old_function_3_15();
 @endif
 }
 ```
@@ -89,7 +89,7 @@ bundle agent extractor
 @if between_versions(3.12, 3.15)
   # Policy specific to 3.12, 3.13, 3.14, 3.15
   vars:
-    "container" data => workaround_3_12_3_15(...);
+    "container" data => workaround_3_12_3_15();
 @endif
 }
 ```
@@ -111,7 +111,7 @@ bundle agent extractor
   # Policy to work around issue which was fixed in 3.15
   vars:
     "container"
-      data => workaround_pre_3_15(...);
+      data => workaround_pre_3_15();
 @endif
 }
 ```
@@ -133,7 +133,7 @@ bundle agent extractor
   # This policy is only parsed on 3.16+
   vars:
     "container"
-      data => not_neded_on_3_15(...);
+      data => not_neded_on_3_15();
 @endif
 }
 ```
@@ -157,12 +157,12 @@ bundle agent extractor
   # Implementation for 3.16+
   vars:
     "container"
-      data => classfiltercsv(...);
+      data => classfiltercsv();
 @else
   # Implementation for versions before 3.16
   vars:
     "container"
-      data => readcsv(...);
+      data => readcsv();
 @endif
 }
 ```
@@ -180,7 +180,7 @@ bundle agent extractor
 {
   @if feature(xml)
 # the yaml library may not be compiled in
-  vars: "container" data => parseyaml(...);
+  vars: "container" data => parseyaml();
   @endif
 }
 ```
diff --git a/content/resources/additional-topics/devops.markdown b/content/resources/additional-topics/devops.markdown
index 5b59b90ae..a13de9098 100644
--- a/content/resources/additional-topics/devops.markdown
+++ b/content/resources/additional-topics/devops.markdown
@@ -126,11 +126,13 @@ organizes similar operations into chapters in a simple separation of concerns.
 bundle agent example
 {
   files:
-     "affected object" ...details....
-
+    "affected object"
+      # ...details....
+      ;
   processes:
-     "affected object" ...details....
-
+    "affected object"
+      # ...details....
+      ;
 }
 ```
 
@@ -138,14 +140,14 @@ In general, many such promises and types are collected into bundles, so that the
 form is
 
 ```cf3
-bundle agent SomeUserDefinedName
+bundle agent some_user_defined_name
 {
   type_of_promise:
-
     "affected object/promiser"
-
-     body of the promise/details
- ...
+      # attributes of the promise/details
+      ;
+    # More promises...
+  # More promise types...
 }
 ```
 
@@ -157,18 +159,13 @@ written as a prefix, a bit like a target in a Makefile. They represent known
 properties of the environment.
 
 ```cf3
-bundle agent SomeUserDefinedName
+bundle agent some_user_defined_name
 {
-
   type_of_promise:
-
     property::
-
-      make one promise...
-
+      "make one promise...";
     !property::
-
-      make a different promise...
+      "make a different promise...";
 }
 ```
 
@@ -181,7 +178,7 @@ certain hard-classes by default. In addition, you can probe as many more as you
 like, as separate promises.
 
 ```cf3
-bundle agent SomeUserDefinedName
+bundle agent some_user_defined_name
 {
  classes:
 
@@ -200,7 +197,7 @@ To go from if-then-else thinking to using classes, you just need to thihnk about
 classes as booleans:
 
 ```cf3
-bundle agent Name
+bundle agent some_user_defined_name
 {
   classes:
 
diff --git a/content/resources/additional-topics/distributed-scheduling.markdown b/content/resources/additional-topics/distributed-scheduling.markdown
index 5ff49c10c..4ec3415f5 100644
--- a/content/resources/additional-topics/distributed-scheduling.markdown
+++ b/content/resources/additional-topics/distributed-scheduling.markdown
@@ -112,7 +112,7 @@ classes:
                                            );
 methods:
 
-  Host2.hostX_did_my_job
+  Host2.hostX_did_my_job::
 
     "any" usebundle => do_my_job_bundle;
 
@@ -193,7 +193,7 @@ classes:
                                                         );
 methods:
 
-  Host2.hostX_did_my_job
+  Host2.hostX_did_my_job::
 
     "any" usebundle => do_my_job_bundle;
 
@@ -361,7 +361,7 @@ classes:
                                  if => "Host$(n)";
 methods:
 
-  Host2.Host3.Host4.hostX_did_my_job
+  Host2.Host3.Host4.hostX_did_my_job::
 
     "any" usebundle => do_my_job_bundle;
 
@@ -382,12 +382,12 @@ no error handling or recovery except to schedule the whole thing again.
 Triggering from one or more predecessors, i.e. combining with OR, looks similar,
 we just have to change the class expression:
 
-```
+```cf3
 bundle agent example
 {
   methods:
 
-    (Host2|Host3|Host4).hostX_did_my_job
+    (Host2|Host3|Host4).hostX_did_my_job::
 
       "any" usebundle => do_my_job_bundle;
 }
@@ -414,7 +414,7 @@ classes:
                                                         );
 methods:
 
-  Host2.hostX_did_my_job
+  Host2.hostX_did_my_job::
 
     "any" usebundle => do_my_job_bundle1;
     "any" usebundle => do_my_job_bundle2;
diff --git a/content/resources/additional-topics/file-content.markdown b/content/resources/additional-topics/file-content.markdown
index 60f26b2cf..0800c96bb 100644
--- a/content/resources/additional-topics/file-content.markdown
+++ b/content/resources/additional-topics/file-content.markdown
@@ -803,8 +803,8 @@ with the standard library method:
 ```cf3
 bundle agent example
 {
-  "/tmp/expander"
-
+  files:
+    "/tmp/expander"
            create => "true",
     edit_template => "/home/a10004/input.dat",
     edit_defaults => empty;
diff --git a/content/resources/additional-topics/hierarchies.markdown b/content/resources/additional-topics/hierarchies.markdown
index 6941844bf..6abd1a5bb 100644
--- a/content/resources/additional-topics/hierarchies.markdown
+++ b/content/resources/additional-topics/hierarchies.markdown
@@ -351,7 +351,7 @@ bundle agent example
 
   processes:
     servers::  # the next rules `extend` or add to the class servers
-      "..."
+      "...";
 }
 ```
 
diff --git a/content/resources/additional-topics/open-nebula.markdown b/content/resources/additional-topics/open-nebula.markdown
index 268bc0b05..2abfd8b0d 100644
--- a/content/resources/additional-topics/open-nebula.markdown
+++ b/content/resources/additional-topics/open-nebula.markdown
@@ -70,7 +70,7 @@ cluster-node.
 
 First we can classify the physical machines in this case by IP address:
 
-```cf3
+```cf3 {skip TODO}
 classes:
         "front_end" or => {"192.168.1.2"};
         "node_controllers" or => {"192.168.1.3"};
@@ -81,7 +81,7 @@ IP addresses of intended node controllers. This will allow the "onehost create"
 command to execution each new node controller in turn reducing redundancy in the
 policy file for example:
 
-```cf3
+```cf3 {skip TODO}
 vars:
  "node_controller" slist => { "192.168.1.3", "192.168.1.4", "192.168.1.5" };
 
@@ -100,7 +100,7 @@ classes:
 To install the dependancies for each physical machine we can define these in a
 list and use the CFEngine standard library package promises to install them:
 
-```cf3
+```cf3 {skip TODO}
 vars:
   "front_end_deps" slist => {
     "libcurl3",
@@ -127,7 +127,7 @@ vars:
 
 Promises to perform dependency installation:
 
-```cf3
+```cf3 {skip TODO}
 packages:
 
 front_end::
@@ -149,7 +149,7 @@ The additional line in the front end dependancy installation promise, assuming a
 successful installation, will ensure the Open Nebula daemon is running at all
 times:
 
-```cf3
+```cf3 {skip TODO}
 front_end::
 
 ensure_opennebula_running::
@@ -159,7 +159,7 @@ ensure_opennebula_running::
 
 Resulting in:
 
-```cf3
+```cf3 {skip TODO}
 commands:
 
   start_oned::
@@ -171,7 +171,7 @@ commands:
 Since we will be using Open Nebula version 2 we must manually supply the
 package:
 
-```cf3
+```cf3 {skip TODO}
 commands:
 
   front_end.!opennebula_installed::
@@ -184,7 +184,7 @@ repeated installation we can do a check to see if Open Nebula has already been
 installed by classifying a successful installation as having the oned.conf file
 in existence:
 
-```cf3
+```cf3 {skip TODO}
 classes:
 
   "opennebula_installed" or => {fileexists("/etc/one/oned.conf")};
@@ -194,7 +194,7 @@ Open nebula requires a privileged user "oneadmin" to issue commands. In order to
 have CFEngine perform these commands with the correct privileges we can use the
 contain body by appending the following to commands promises:
 
-```cf3
+```cf3 {skip TODO}
 contain => oneadmin
 ```
 
@@ -214,7 +214,7 @@ dependancy configuration, Up: Top NFS config for shared image repository
 If not present append the NFS export directory stored in the corresponding
 variable (including a new line):
 
-```cf3
+```cf3 {skip TODO}
 vars:
 
 "nfs_export_dir"
@@ -234,7 +234,7 @@ files:
 
 To ensure the NFS service remains available:
 
-```cf3
+```cf3 {skip TODO}
 processes:
 
 ensure_nfs_running::
@@ -251,7 +251,7 @@ start_nfs::
 In order to ensure the share is mounted on all node controllers we can use the
 NFS promise:
 
-```cf3
+```cf3 {skip TODO}
 storage:
 
   cluster_node::
@@ -262,7 +262,7 @@ storage:
 
 Next we will create a directory to hold our virtual machine images:
 
-```cf3
+```cf3 {skip TODO}
 "/var/lib/one/images/.",
   comment => "create dir in image repo share",
   perms => mog("644", "oneadmin", "oneadmin"),
@@ -273,7 +273,7 @@ Next we will create a directory to hold our virtual machine images:
 
 Create the oneadmin bashrc file containing the ONE_XMLRPC environment variable with appropriate permissions:
 
-```cf3
+```cf3 {skip TODO}
 files:
   front_end::
     "/var/lib/one/.bashrc"
@@ -286,7 +286,7 @@ files:
 
 We also need to create the one_auth file:
 
-```cf3
+```cf3 {skip TODO}
 files:
   front_end::
     "/var/lib/one/.one/one_auth",
@@ -300,7 +300,7 @@ Finally password-less authentication for the oneadmin user:
 
 Add key to autorized_keys file:
 
-```cf3
+```cf3 {skip TODO}
 files:
   front_end::
     "/var/lib/one/.ssh/authorized_keys",
@@ -311,7 +311,7 @@ files:
 
 Disable known hosts prompt:
 
-```cf3
+```cf3 {skip TODO}
 front_end::
   "/var/lib/one/.ssh/config",
     comment => "disable strict host key checking",
@@ -325,7 +325,7 @@ Now on the node controller(s) we need to add the oneadmin group and user with
 the same uid and gid as the front end and add the oneadmin user to the libvertd
 group:
 
-```cf3
+```cf3 {skip TODO}
 files:
   node_controller::
     "/etc/passwd",
@@ -344,7 +344,7 @@ files:
 Now that the user environment is configured we can register our node controller
 with the front end:
 
-```cf3
+```cf3 {skip TODO}
 files:
   front_end::
     "/usr/bin/onehost create 192.168.1.2 im_kvm vmm_kvm tm_nfs",
@@ -357,7 +357,7 @@ Before we can create virtual networks we must configure our node controller
 interfaces. In this example we will bridge a virtual interface (vbr0) with eth0.
 First we define the contents of the interfaces file in a variable:
 
-```cf3
+```cf3 {skip TODO}
 vars:
 "interfaces_contents" slist => {
   "auto lo",
@@ -379,7 +379,7 @@ vars:
 
 Next we edit the interfaces file to include our new settings:
 
-```cf3
+```cf3 {skip TODO}
 files:
   node_controller::
     "/etc/network/interfaces",
@@ -391,7 +391,7 @@ files:
 
 And restart networking:
 
-```cf3
+```cf3 {skip TODO}
 commands:
   restart_networking::
     "/etc/init.d/networking restart",
@@ -403,7 +403,7 @@ network file and submit it to the system. The contents of the virtual network
 template file could be defined as a variable as we have seen before but in this
 case it is passed as a parameter to the append promise body:
 
-```cf3
+```cf3 {skip TODO}
 "/var/lib/one/network.template",
   comment => "create lan template",
   create => "true",
@@ -418,7 +418,7 @@ The network template only deals with fixed ip addresses and provides only one
 lease. Obviously this should be altered to suite your requirements. Now we have
 a template we can register it with open nebula:
 
-```cf3
+```cf3 {skip TODO}
 commands:
   front_end::
      "/usr/bin/onevnet create /var/lib/one/network.template",
@@ -430,7 +430,7 @@ commands:
 This follows the same pattern as virtual network setup. First we create the
 template file:
 
-```cf3
+```cf3 {skip TODO}
 files:
 
   "/var/lib/one/vm.template",
@@ -457,7 +457,7 @@ GRAPHICS = [TYPE = \"vnc\", LISTEN = \"localhost\", PORT = 5910]
 
 Now we can launch the virtual machine defined in its template file:
 
-```cf3
+```cf3 {skip TODO}
 commands:
   front_end::
     "/usr/bin/onevm create /var/lib/one/vm.template",
@@ -491,7 +491,7 @@ Once registration is complete we can define a new class based on the ip of our
 virtual machine. In this example that is 192.168.1.100 so we can create a class
 with a meaningful name:
 
-```cf3
+```cf3 {skip TODO}
 "webserver" or => {"192_168_1_100"};
 ```
 
@@ -502,7 +502,7 @@ other machine for example:
 
 First we install apache:
 
-```cf3
+```cf3 {skip TODO}
 packages:
   webserver::
     "apache2",
@@ -514,7 +514,7 @@ packages:
 
 Next we ensure it is running
 
-```cf3
+```cf3 {skip TODO}
 processes:
   ensure_apache_running::
     ".*apache2.*"
@@ -523,7 +523,7 @@ processes:
 
 If not, the service is restarted
 
-```cf3
+```cf3 {skip TODO}
 commands:
   start_apache::
     "/etc/init.d/apache2 restart";
@@ -532,7 +532,7 @@ commands:
 Finally we can copy some content into the document root on our new virtual
 webserver:
 
-```cf3
+```cf3 {skip TODO}
 files:
   "/var/www"
     perms => system("744"),
diff --git a/content/resources/faq/fix-undefined-body-error.markdown b/content/resources/faq/fix-undefined-body-error.markdown
index eac0bf807..0da971d1f 100644
--- a/content/resources/faq/fix-undefined-body-error.markdown
+++ b/content/resources/faq/fix-undefined-body-error.markdown
@@ -34,7 +34,7 @@ Body file control allows you to build modular policy. Body file control inputs
 are typically relative to the policy file itself.
 
 ```cf3
-bundle file_remover_control
+bundle common file_remover_control
 {
   vars:
     "inputs" slist => {