Cleanup user guide sections a-c

Account management, container preloading, custom CI, and custom SOTA
client sections were all cleaned up in line with the style guide.
Container preloading was also updated to remove references of named
branches (devel), and removed a number of screenshots of the UI which
are covered in the getting started and tutorial sections.

QA Steps: viewed rendered html in browser. Ran vale linter and
linkcheck.

This commit applies to FFTK-988

Signed-off-by: Katrina Prosise <katrina.prosise@foundries.io>

source/user-guide/account-management/subscription-and-billing.rst

@@ -1,17 +1,17 @@
 .. _ref-subscription-and-billing:
 
-Managing your Subscription
+Managing Your Subscription
 ==========================
 
 .. hint::
-   FoundriesFactory is a DevSecOps platform subscription service.
+   FoundriesFactory® is a DevSecOps platform subscription service.
    Per month or annual plan choices,
    both provide access to all FoundriesFactory features and support.
 
 Subscriptions apply per Factory;
 if you have *Factories*, you will manage them separately.
 
-Changing your Plan
+Changing Your Plan
 ------------------
 
 From your Factory's page, navigate to the :guilabel:`Plan` tab.
@@ -44,7 +44,7 @@ For using other forms of payment, please `contact us <https://foundriesio.atlass
 Payment and Billing
 --------------------
 
-To make changes —such as payment method or autorenewal— you must have an **Owner** or **Accounting** role.
+To make changes—such as payment method or autorenewal—you must have an **Owner** or **Accounting** role.
 Changes can be made through the :guilabel:`Plan` tab.
 
 .. important::

source/user-guide/account-management/team-based-access.rst

@@ -4,7 +4,7 @@ Team Based Factory Access
 =========================
 
 .. tip::
-   The FoundriesFactory :ref:`API documentation<ref-scopes>` covers available scopes.
+   The FoundriesFactory® :ref:`API documentation<ref-scopes>` covers available scopes.
 
 Larger organizations often need to restrict the access level a user has to the Factory.
 For example, some users might only need access for managing devices,
@@ -28,9 +28,8 @@ See :ref:`Access to Device Groups` for more details.
    It may take a moment for changes to scope/teams to take effect.
 
 Teams can be created by anyone with either the **Owner** or **Admin** role.
-Additionally, these roles are granted read-write operations for all Factory resources by default,
-but when checking user scope with ``fioctl users <user id>`` ,
-it will return blank unless they are part of a team.
+While these roles are granted read-write operations for all Factory resources by default,
+checking user scope with ``fioctl users <user id>`` will return blank unless they are part of a team.
 Members with devices may manage their own with read-write access.
 
 .. tip::
@@ -63,12 +62,12 @@ Team "read-write-ci" can do CI read-write operations:
 .. figure:: /_static/teams-example-read-only.png
    :align: center
    :scale: 80%
-   :alt: Teams example - Team read-only users
+   :alt: Teams example: Team read-only users
 
 .. figure:: /_static/teams-example-read-write-ci.png
    :align: center
    :scale: 80%
-   :alt: Teams example - Team read-write CI users
+   :alt: Teams example: Team read-write CI users
 
 A member is then added to both teams.
 The member then has a combined list of scopes:
@@ -128,7 +127,7 @@ Example
 
 A Factory has two teams in place and one device group, ``test-lab-devices``.
 
-Members of the "read-only-users" team have read-only access to all factory resources with one exception - device groups and devices.
+Members of the "read-only-users" team have read-only access to all factory resources with one exception—device groups and devices.
 They can see only the ``test-lab-devices`` group and devices included into it.
 
 

source/user-guide/container-preloading/container-preloading.rst

@@ -3,33 +3,30 @@
 Container Preloading
 ====================
 
-This section guides you to configure your ``platform`` images to preload Docker Compose Apps.
+This guide covers configuring your ``platform`` images to preload Docker Compose Apps.
 
-By default, the ``platform`` build creates an image to be flashed to a device that
-doesn't include Docker Compose Apps. After installing the image and registering
-the device, ``aktualizr-lite`` downloads and runs the configured apps.
+By default, the ``platform`` build creates an image to be flashed to a device—that does not include Docker Compose Apps.
+Then, after installing the image and registering the device, ``aktualizr-lite`` downloads and runs the configured Apps.
 
-There are cases where having applications preloaded on the image can be helpful, such as:
+Cases where having Apps preloaded on the image can be helpful include:
 
-- Executing a Docker Compose App right after the first boot, even without internet or registering the device.
+- Executing a Docker Compose App right after first boot, even without internet or registering the device.
 - Reducing network data usage during the Docker Image download.
 
-.. note::
+.. warning::
 
-    Preloading container images will increase the size of the system image
-    considerably, especially if the containers have not been optimally
-    constructed.
+    Preloading container images will increase the size of the system image considerably,
+    especially if the containers have not been optimally constructed.
 
-    Refer to the official Docker documentation for best practices
-    on writing Dockerfiles:
-    https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
+    Refer to the official Docker documentation for
+    `best practices on writing Dockerfiles <https://docs.docker.com/develop/develop-images/dockerfile_best-practices/>`_.
 
 There are two ways to create these images:
 
  * :ref:`fioctl targets image<fioctl_targets_image>`
  * configuring ``ci-scripts`` to preload each build
 
-Here we focus on the second approach so every Target includes a flashable image with preloaded containers.
+Here we focus on the second approach, so that every Target includes a flashable image with preloaded containers.
 
 Configure the CI
 ----------------
@@ -41,11 +38,10 @@ Clone your ``ci-scripts`` repo and enter its directory:
     git clone https://source.foundries.io/factories/<factory>/ci-scripts.git
     cd ci-scripts
 
-Edit the ``factory-config.yml`` file and add the configuration below:
-
-**factory-config.yml**:
+Add the following to ``factory-config.yml``,
+making sure to set the appropriate values for ``app_type`` and ``oe_builtin`` (see below):
 
-.. prompt:: text
+.. code-block:: YAML 
 
       containers:
         preloaded_images:
@@ -54,17 +50,21 @@ Edit the ``factory-config.yml`` file and add the configuration below:
          shortlist: "shellhttpd"
          oe_builtin: <true|false>
 
-- ``enabled`` -  Whether to produce an archive containing docker images as part of a container build trigger.
-- ``shortlist`` - Defines the list of apps to preload. All Target's apps are preloaded if it is not specified or its value is empty. Here, it is set to preload the ``shellhttpd`` app.
-- ``app_type`` - Defines a type of Apps to preload.
-  If an option is not defined or set to an empty value, the ``app_type``  preload will depend on the LmP version. If the LmP version is equal to or higher than **v85**, then `restorable` type is preloaded, otherwise `compose` type.
+- ``enabled``- Whether to produce an archive containing Docker images as part of a container build trigger.
+- ``shortlist``- Defines the list of apps to preload.
+  All the  Target's apps are preloaded if not specified or empty.
+  Here, it is set to preload the ``shellhttpd`` app.
+- ``app_type`` - Defines the type of Apps to preload.
+  If not defined, or set to an empty value, the ``app_type`` preload will depend on the LmP version.
+  If the LmP version is **v85** or newer, then `restorable` type is preloaded, otherwise `compose` type is used.
   See :ref:`ug-restorable-apps` for more details on Restorable Apps.
 - ``oe_builtin`` - *Optional*: Preload Apps during an OE build CI run. Should be left disabled/undefined for most machines.
 
 .. note::
-   The ``oe_builtin`` is a special preloading case where Apps are preloaded during an OE build CI run, rather than preloaded by the `assemble` run of a LmP CI build. This is needed when the image produced by the LmP build is not a WIC image.
+   ``oe_builtin`` is a special preloading case where Apps are preloaded during an OE build, rather than by the `assemble` run of a LmP build.
+   This is needed when the image produced is not a WIC image.
 
-   In this case, rootfs as well as a system image produced by the run include preloaded Apps.
+   In this case, rootfs and the system image will include preloaded Apps.
 
    Only `Restorable` type of Apps (default) are supported by the OE builtin preloader.
 
@@ -80,25 +80,20 @@ Add the ``factory-config.yml`` file, commit and push:
 Getting a New Image with Preloaded Containers
 ----------------------------------------------
 
-After these steps, when a ``platform`` or ``containers`` build finishes, it will
-generate a ``.wic.gz`` file in :guilabel:`Runs`, ``assemble-system-image`` , ``<tag>`` folder, with the preloaded Docker Images.
+After these steps, a ``platform`` or ``containers`` build will generate a ``.wic.gz`` file with the preloaded Docker Images under
+:guilabel:`Runs`, ``assemble-system-image`` , ``<tag>``.
 
-For example, pushing to ``containers-devel`` after this change triggers the usual build and an additional run called ``assemble-system-image``. Check the latest **Target** named ``containers-devel`` you just created:
+For example, pushing to ``main`` triggers the usual build and an additional run called ``assemble-system-image``.
+Check the latest Target you just created:
 
 .. figure:: /_static/userguide/container-preloading/container-preloading-new-target.png
    :width: 900
    :align: center
 
-   FoundriesFactory New Target
-
-When FoundriesFactory CI finishes all jobs, click in the **Target**, find :guilabel:`Runs` and download the image from ``assemble-system-image``:
-
-.. figure:: /_static/userguide/container-preloading/container-preloading-image.png
-   :width: 900
-   :align: center
-
-   FoundriesFactory New Containers Image
+   New Target
 
+When the FoundriesFactory® CI finishes, click Target.
+Find :guilabel:`Runs` and download the image from ``assemble-system-image``.
 Flash the image and boot the device.
 
 .. note::
@@ -110,47 +105,49 @@ Flash the image and boot the device.
 Checking the Preloaded Image
 ----------------------------
 
-app_type: restorable
-~~~~~~~~~~~~~~~~~~~~
+Restorable Type
+~~~~~~~~~~~~~~~
 
 Restorable apps are enabled by default on LmP v85+.
 
-On your device, switch to root and list the files in the folder
-``/var/sota/reset-apps``.
+On your device, switch to root and list the files in the folder ``/var/sota/reset-apps``.
 
 .. prompt:: bash device:~$
 
     sudo su
     ls /var/sota/reset-apps/apps
 
-.. prompt:: text
+.. code-block:: text
 
      app-05 app-07 app-08
 
-Preloaded Restorable Apps should be listed in the output, provided that the preloading was successful. In this case, the preloaded apps are ``app-05``, ``app-07`` and ``app-08``.
+Preloaded Restorable Apps are listed in the output, provided that the preloading was successful.
+In this case, the preloaded apps are ``app-05``, ``app-07`` and ``app-08``.
 
-Another option to verify whether Restorable Apps are preloaded is to use `aklite-apps` utility.
+Another option to verify whether Restorable Apps are preloaded is to use the `aklite-apps` utility.
 
 .. prompt:: bash device:~$
 
     sudo su
     aklite-apps ls
 
-.. prompt:: text
+.. code-block:: text
 
      app-05
      app-07
      app-08
 
-A user can try to start preloaded Restorable Apps manually by using `aklite-apps` utility.
+Try to start the preloaded Restorable Apps manually using `aklite-apps`:
 
 .. prompt:: bash device:~$
 
     sudo su
     aklite-apps run [--apps <a comma separated list of Apps>]
 
 .. note::
-    ``app_type`` is set to ``restorable`` by default since LmP **v85**. If ``compose`` app type is set, then the preloaded apps are located under ``/var/sota/compose-apps/<app>``. Here is an example using ``shellhttpd`` preloaded app:
+    ``app_type`` is set to ``restorable`` by default since LmP **v85**.
+    If ``compose`` app type is set, then the preloaded apps are located under ``/var/sota/compose-apps/<app>``.
+    Here is an example using ``shellhttpd`` preloaded app:
 
     .. prompt:: bash device:~$
 
@@ -161,24 +158,21 @@ A user can try to start preloaded Restorable Apps manually by using `aklite-apps
 Starting Compose Apps Automatically
 -----------------------------------
 
-To start the preloaded application automatically after the boot and before
-the device registration when aktualizr-lite starts, you have to enable a systemd service
-responsible for it.
+To start the preloaded application automatically between the boot and the device registration when aktualizr-lite starts,
+enable a systemd service responsible for it.
 
 meta-lmp_ provides a recipe that launches preloaded apps after the device boots.
 
 Clone your ``meta-subscriber-overrides.git`` repo and enter its directory:
 
 .. prompt:: bash host:~$
 
-    git clone -b devel https://source.foundries.io/factories/<factory>/meta-subscriber-overrides.git
+    git clone https://source.foundries.io/factories/<factory>/meta-subscriber-overrides.git
     cd meta-subscriber-overrides
 
 Edit the ``recipes-samples/images/lmp-factory-image.bb`` file and add the recipe to the ``CORE_IMAGE_BASE_INSTALL`` list:
 
-**recipes-samples/images/lmp-factory-image.bb**:
-
-.. prompt:: text
+.. code-block:: diff
 
      diff --git a/recipes-samples/images/lmp-factory-image.bb b/recipes-samples/images/lmp-factory-image.bb
      --- a/recipes-samples/images/lmp-factory-image.bb
@@ -199,35 +193,28 @@ Add the ``recipes-samples/images/lmp-factory-image.bb`` file, commit and push:
     host:~$ git commit -m "compose-apps-early-start: Adding recipe" recipes-samples/images/lmp-factory-image.bb
     host:~$ git push
 
-The latest **Target** named ``platform-devel`` should be the CI job you just created.
+The latest Target should be the CI job you just created.
 
 .. figure:: /_static/userguide/container-preloading/container-preloading-platform.png
    :width: 900
    :align: center
 
-   FoundriesFactory New Platform Target
-
-When FoundriesFactory CI finishes all jobs, click in the **Target**, find :guilabel:`Runs` and download the image from the ``assemble-system-image`` run:
-
-.. figure:: /_static/userguide/container-preloading/container-preloading-platform-image.png
-   :width: 900
-   :align: center
-
-   FoundriesFactory Platform Image
+   New Platform Target
 
+When the FoundriesFactory CI finishes, click on the Target.
+Find :guilabel:`Runs` and download the image from the ``assemble-system-image`` run.
 Flash the image and boot the device.
 
 Testing Auto Start
 ------------------
 
-On your device, use the following command to list the ``compose-apps-early-start``
-service:
+On your device, list the ``compose-apps-early-start`` service:
 
 .. prompt:: bash device:~$
 
     systemctl list-unit-files | grep enabled | grep compose-apps-early-start
 
-.. prompt:: text
+.. code-block:: text
 
     compose-apps-early-start.service           enabled         enabled
 
@@ -237,7 +224,7 @@ Verify the ``compose-apps-early-start`` application status:
 
     device:~$  systemctl status compose-apps-early-start
 
-.. prompt:: text
+.. code-block:: text
 
      compose-apps-early-start.service - Ensure apps are configured and running as early>
           Loaded: loaded (/usr/lib/systemd/system/compose-apps-early-start.service; enabl>