chore: address markdown lint issues (#327)

Signed-off-by: Michael Beemer <[email protected]>

Author: beeme1mr

specification/sections/01-flag-evaluation.md

@@ -48,7 +48,7 @@ See [event handlers and initialization](./05-events.md#event-handlers-and-initia
 
 #### Requirement 1.1.2.3
 
->  The `provider mutator` function **MUST** invoke the `shutdown` function on the previously registered provider once it's no longer being used to resolve flag values.
+> The `provider mutator` function **MUST** invoke the `shutdown` function on the previously registered provider once it's no longer being used to resolve flag values.
 
 When a provider is no longer in use, it should be disposed of using its `shutdown` mechanism.
 Provider instances which are bound to multiple `domains` won't be shut down until the last binding is removed.
@@ -227,7 +227,6 @@ number myNumber = client.getNumberValue('number-flag', 75);
 MyStruct myStruct = client.getObjectValue<MyStruct>('structured-flag', { text: 'N/A', percentage: 75 }, options);
 ```
 
-
 #### Condition 1.3.3
 
 > The implementation language differentiates between floating-point numbers and integers.
@@ -409,7 +408,7 @@ It's recommended that application-authors call this function on application shut
 
 The global API object defines a `shutdown` function, which will call the respective `shutdown` function on all providers.
 Alternatively, implementations might leverage language idioms such as auto-disposable interfaces or some means of cancellation signal propagation to allow for graceful shutdown.
-This shutdown function unconditionally calls the shutdown function on all registered providers, regardless of their state. 
+This shutdown function unconditionally calls the shutdown function on all registered providers, regardless of their state.
 
 see: [`shutdown`](./02-providers.md#25-shutdown)
 

specification/sections/02-providers.md

@@ -124,6 +124,7 @@ ResolutionDetails<number> resolveNumberValue(string flagKey, number defaultValue
 // example structure flag value resolution with generic argument
 ResolutionDetails<MyStruct> resolveStructureValue(string flagKey, MyStruct defaultValue, context: EvaluationContext);
 ```
+
 #### Requirement 2.2.9
 
 > The `provider` **SHOULD** populate the `resolution details` structure's `flag metadata` field.

specification/sections/03-evaluation-context.md

@@ -177,7 +177,7 @@ see: [dynamic-context paradigm](../glossary.md#dynamic-context-paradigm)
 
 > The API **SHOULD** have a method for setting a `transaction context propagator`.
 
-If there already is a `transaction context propagator`, it is replaced with the new one. 
+If there already is a `transaction context propagator`, it is replaced with the new one.
 
 #### Condition 3.3.1.2
 

specification/sections/04-hooks.md

@@ -74,12 +74,14 @@ see: [dynamic-context paradigm](../glossary.md#dynamic-context-paradigm)
 Either the `hook data` reference itself must be mutable, or it must allow mutation of its contents.
 
 Mutable reference:
-```
+
+```js
 hookContext.hookData = {'my-key': 'my-value'}
 ```
 
 Mutable content:
-```
+
+```js
 hookContext.hookData.set('my-key', 'my-value')
 ```
 
@@ -116,6 +118,7 @@ hookContext.hookData.set('my-key', 'my-value')
 > `Hook data` **MUST** must be created before the first `stage` invoked in a hook for a specific evaluation and propagated between each `stage` of the hook. The hook data is not shared between different hooks.
 
 Example showing data between `before` and `after` stage for two different hooks.
+
 ```mermaid
 sequenceDiagram
 actor Application
@@ -248,21 +251,70 @@ client.getValue('my-flag', 'defaultValue', new Hook3());
 
 > Hooks **MUST** be executed "stack-wise" with respect to flag resolution, prioritizing increasing specificity (API, Client, Invocation, Provider) first, and the order in which they were added second.
 
-Before flag resolution (the `before` stage), hooks run in the order `API` -> `Client` -> `Invocation` -> `Provider`, and within those, in the order in which they were added. 
+Before flag resolution (the `before` stage), hooks run in the order `API` -> `Client` -> `Invocation` -> `Provider`, and within those, in the order in which they were added.
 After flag evaluation (the `after`, `error`, or `finally` stages), hooks run in the order `Provider` -> `Invocation` -> `Client` -> `API`, and within those, in reverse of the order in which they were added.
 This achieves intuitive "stack-like" or "LIFO" behavior for side effects and transformations.
 
-```
 Given hooks A - H, each implementing the both the `before` and `after` stages, added at the following levels and order:
 
-API: [A, B]
-Client: [C, D]
-Invocation: [E, F]
-Provider: [G, H]
+- API: [A, B]
+- Client: [C, D]
+- Invocation: [E, F]
+- Provider: [G, H]
 
 The expected order of execution is:
 
-A.before -> B.before -> C.before -> D.before -> E.before -> F.before -> G.before -> H.before -> flagResolution -> H.after -> G.after -> F.after -> E.after -> D.after -> C.after -> B.after -> A.after
+```mermaid
+flowchart BT
+    subgraph FlagResolution [Flag Resolution]
+        flagResolution[flagResolution]
+    end
+
+    subgraph Provider [Provider Layer]
+        G_before[G.before]
+        H_before[H.before]
+        G_after[G.after]
+        H_after[H.after]
+    end
+
+    subgraph Invocation [Invocation Layer]
+        E_before[E.before]
+        F_before[F.before]
+        E_after[E.after]
+        F_after[F.after]
+    end
+
+    subgraph Client [Client Layer]
+        C_before[C.before]
+        D_before[D.before]
+        C_after[C.after]
+        D_after[D.after]
+    end
+
+    subgraph API [API Layer]
+        A_before[A.before]
+        B_before[B.before]
+        A_after[A.after]
+        B_after[B.after]
+    end
+
+    A_before --> B_before
+    B_before --> C_before
+    C_before --> D_before
+    D_before --> E_before
+    E_before --> F_before
+    F_before --> G_before
+    G_before --> H_before
+    H_before --> flagResolution
+    
+    flagResolution --> H_after
+    H_after --> G_after
+    G_after --> F_after
+    F_after --> E_after
+    E_after --> D_after
+    D_after --> C_after
+    C_after --> B_after
+    B_after --> A_after
 ```
 
 #### Requirement 4.4.3
@@ -349,6 +401,7 @@ but different hooks have different hook data instances.
 Access to hook data is restricted to only a single hook instance, and it has no serialization requirements, and as a result does not require any value type restrictions.
 
 Example TypeScript definition:
-```JavaScript
+
+```js
 type HookData = Record<string, unknown>;
 ```

specification/sections/05-events.md

@@ -31,7 +31,7 @@ see: [domain](../glossary.md#domain)
 
 #### Requirement 5.1.1
 
-> The `provider` **MAY** define a mechanism for signaling the occurrence of one of a set of events, including `PROVIDER_READY`, `PROVIDER_ERROR`, `PROVIDER_CONFIGURATION_CHANGED` and `PROVIDER_STALE`, with a `provider event details` payload. 
+> The `provider` **MAY** define a mechanism for signaling the occurrence of one of a set of events, including `PROVIDER_READY`, `PROVIDER_ERROR`, `PROVIDER_CONFIGURATION_CHANGED` and `PROVIDER_STALE`, with a `provider event details` payload.
 
 Providers cannot emit `PROVIDER_CONTEXT_CHANGED` or `PROVIDER_RECONCILING` events.
 These are emitted only by the SDK during context reconciliation.
@@ -50,7 +50,7 @@ see: [provider event types](../types.md#provider-events), [`event details`](../t
 > When a `provider` signals the occurrence of a particular `event`, the associated `client` and `API` event handlers **MUST** run.
 
 Client event handlers respect the dynamic binding of clients to providers via `domains`.
-Client event handlers run when a lifecycle function terminates on the associated provider, or the associated provider emits an event. 
+Client event handlers run when a lifecycle function terminates on the associated provider, or the associated provider emits an event.
 
 see: [provider event types](./../types.md#provider-events) and [event handlers](#52-event-handlers).
 
@@ -59,7 +59,7 @@ see: [provider event types](./../types.md#provider-events) and [event handlers](
 > When a `provider` signals the occurrence of a particular `event`, event handlers on clients which are not associated with that provider **MUST NOT** run.
 
 Client event handlers respect the dynamic binding of clients to providers via `domains`.
-Client event handlers do not run when a lifecycle function terminates on an unassociated provider, or an unassociated provider emits an event. 
+Client event handlers do not run when a lifecycle function terminates on an unassociated provider, or an unassociated provider emits an event.
 
 see [setting a provider](./01-flag-evaluation.md#setting-a-provider), [domain](../glossary.md#domain) for details.
 
@@ -152,7 +152,7 @@ See [provider initialization](./02-providers.md#24-initialization) and [setting
 
 > If the provider's `initialize` function terminates abnormally, `PROVIDER_ERROR` handlers **MUST** run.
 
-A failed initialization could represent an unrecoverable error, such as bad credentials or a missing file. 
+A failed initialization could represent an unrecoverable error, such as bad credentials or a missing file.
 If a failed initialization could also represent a transient error.
 A provider which maintains a persistent connection to a remote `flag management system` may attempt to reconnect, and emit `PROVIDER_READY` after a failed initialization.
 

specification/sections/06-tracking.md

@@ -104,4 +104,4 @@ See [provider tracking support](./02-providers.md#27-tracking-support).
 
 The `tracking event details` supports the addition of arbitrary fields, including nested objects, similar to the `evaluation context` and object-typed flag values.
 
-See [structure](../types.md#structure), [evaluation context](.//03-evaluation-context.md).
+See [structure](../types.md#structure), [evaluation context](.//03-evaluation-context.md).