Update .editorconfig to match MD linting rules

.editorconfig

@@ -8,9 +8,6 @@ indent_style = space
 insert_final_newline = true
 trim_trailing_whitespace = true
 
-[*.md]
-indent_size = unset
-
 [*.py]
 indent_size = 4
 

docs/architecture/Index.md

@@ -1,4 +1,4 @@
-## Architecture
+# Architecture
 
 Be aware of NHS organizational
 standards: [NHS Architecture Principles][nhsap] | [Software Engineering Quality Framework][seqf] |
@@ -17,12 +17,12 @@ standards: [NHS Architecture Principles][nhsap] | [Software Engineering Quality
 * Final "view" documentation is meant to represent the "current" view
   of the system, not work in progress
 * Diagram checklist to help with consistency:
-    1. Diagrams flow from left to right, then top to bottom to allow
-       readability
-    2. 0.5 line and shape width
-    3. lines are recommended to have text (and preferably numbered)
-    4. provide context on which part of the system the diagram relates
-       to
+  1. Diagrams flow from left to right, then top to bottom to allow
+     readability
+  2. 0.5 line and shape width
+  3. lines are recommended to have text (and preferably numbered)
+  4. provide context on which part of the system the diagram relates
+     to
 
 ![img.png](assets/kruchten_4_1_model.png)
 

docs/architecture/physical/initial_account_structure_for_new_architecture.md

@@ -1,26 +1,25 @@
 ## Initial account structure for new architecture
 
-* The initial accounts have been created reflect the structure
-  we intend to use for the new Web UI
-    * A top-level DNS sub-domain provides the mapping from the
-      nhsnotify DNS root to delegated DNS zones in each sub-domain
-      account
-    * The Event Bus account provides a central location for events to
-      be published without the consuming services needing direct
-      knowledge of the source
-    * The Web Platform account provides the endpoint for the Web UI
-      and documentation. It delegates requests to the other
-      micro-frontend (MFE) services
+* The initial accounts have been created reflect the structure we
+  intend to use for the new Web UI
+  * A top-level DNS sub-domain provides the mapping from the nhsnotify
+    DNS root to delegated DNS zones in each sub-domain account
+  * The Event Bus account provides a central location for events to be
+    published without the consuming services needing direct knowledge
+    of the source
+  * The Web Platform account provides the endpoint for the Web UI and
+    documentation. It delegates requests to the other micro-frontend (
+    MFE) services
 * Each MFE (micro-frontend) is implemented in its own sub-domain.
   Initially these will be:
-    * CMS: Service documentation. This may be hosted on GitHub pages
-      in which case it may not have its own domain accounts
-    * Auth: Federated login identity provider which will provide
-      tokens for use across the other MFE services
-    * Template Manager: MVP template manager web UI
+  * CMS: Service documentation. This may be hosted on GitHub pages in
+    which case it may not have its own domain accounts
+  * Auth: Federated login identity provider which will provide tokens
+    for use across the other MFE services
+  * Template Manager: MVP template manager web UI
 * The existing system, while it consists of several conceptual
   domains, is currently deployed to a single account
-  * As we refine the architecture we will extract sub-domains from
-    the core system and create new accounts to encapsulate them.
+  * As we refine the architecture we will extract sub-domains from the
+    core system and create new accounts to encapsulate them.
 
 ![NHS Notify Domains](assets/Domains.drawio.png)

docs/architecture/physical/sub-domains_and_bounded_contexts.md

@@ -12,24 +12,23 @@ bounded contexts these are some suggestions for structuring the AWS
 accounts and components which are deployed within them.
 
 * By default, each sub-domain has its own AWS accounts
-    * <sub-domain>-preprod (aka Dev)
-    * <sub-domain>-prod
+  * <sub-domain>-preprod (aka Dev)
+  * <sub-domain>-prod
 * Each sub-domain will have a top-level GitHub repo which defines the
   account-level infrastructure
 * Each sub-domain will have one or more bounded contexts
-    * Usually this revolves around some store of state
-    * Subscriptions for events which affect that state
-    * Handlers and processing for changes to state
-    * APIs for direct actions on the state
-    * Events published to reflect changes to the state
-    * Auditing and logging to wrap the service and provide
-      observability
+  * Usually this revolves around some store of state
+  * Subscriptions for events which affect that state
+  * Handlers and processing for changes to state
+  * APIs for direct actions on the state
+  * Events published to reflect changes to the state
+  * Auditing and logging to wrap the service and provide observability
 * A sub-domain may contain one or more microservices
-    * Each microservice should be individually deployable with defined
-      contracts between services
-    * Each microservice should be contained in its own GitHub repo
+  * Each microservice should be individually deployable with defined
+    contracts between services
+  * Each microservice should be contained in its own GitHub repo
 * Questions:
-    * Where are audit logs kept? Per sub-domain, or shared location in
-      isolated account?
+  * Where are audit logs kept? Per sub-domain, or shared location in
+    isolated account?
 
 ![Bounded Context Diagram](assets/Bounded_Context.drawio.png)