Update module architecture docs and workflow tutorials

- Module dossiers: attestor, authority, cli, graph, scanner
- Policy assistant parameters guide
- UI v2-rewire navigation rendering policy
- Test suite overview update
- Workflow engine requirements and tutorial series (01-08)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

docs/workflow/engine/01-requirements-and-principles.md

@@ -1,4 +1,4 @@
-# 01. Requirements And Principles
+# 01. Requirements And Principles
 
 ## 1. Product Goal
 
@@ -239,7 +239,7 @@ They are related, but they are not the same data structure.
 
 ### 5.3 Run To Wait
 
-The engine should never keep a workflow instance “hot” in memory for correctness.
+The engine should never keep a workflow instance “hot” in memory for correctness.
 
 Execution should run until:
 

docs/workflow/tutorials/01-hello-world/README.md

@@ -1,15 +1,15 @@
-# Tutorial 1: Hello World
+# Tutorial 1: Hello World
 
 The simplest possible workflow: initialize state from a start request, activate a single human task, and complete the workflow when the task is done.
 
 ## Concepts Introduced
 
-- `IDeclarativeWorkflow<T>` — the contract every workflow implements
-- `WorkflowSpec.For<T>()` — the builder entry point
-- `.InitializeState()` — transforms the start request into workflow state
-- `.StartWith(task)` — sets the first task to activate
-- `WorkflowHumanTask.For<T>()` — defines a human task
-- `.OnComplete(flow => flow.Complete())` — terminal step
+- `IDeclarativeWorkflow<T>` — the contract every workflow implements
+- `WorkflowSpec.For<T>()` — the builder entry point
+- `.InitializeState()` — transforms the start request into workflow state
+- `.StartWith(task)` — sets the first task to activate
+- `WorkflowHumanTask.For<T>()` — defines a human task
+- `.OnComplete(flow => flow.Complete())` — terminal step
 
 ## What Happens at Runtime
 
@@ -17,7 +17,7 @@ The simplest possible workflow: initialize state from a start request, activate
 2. State initializes to `{ "customerName": "John" }`
 3. Task "Greet Customer" is created with status "Pending"
 4. A user assigns the task to themselves, then completes it
-5. `OnComplete` executes `.Complete()` — the workflow finishes
+5. `OnComplete` executes `.Complete()` — the workflow finishes
 
 ## Variants
 
@@ -26,5 +26,5 @@ The simplest possible workflow: initialize state from a start request, activate
 
 ## Next
 
-[Tutorial 2: Service Tasks](../02-service-tasks/) — call external services before or after human tasks.
+[Tutorial 2: Service Tasks](../02-service-tasks/) — call external services before or after human tasks.
 

docs/workflow/tutorials/02-service-tasks/README.md

@@ -1,15 +1,15 @@
-# Tutorial 2: Service Tasks
+# Tutorial 2: Service Tasks
 
 Call external services (microservices, HTTP APIs, GraphQL, RabbitMQ) from within a workflow. Handle failures and timeouts gracefully.
 
 ## Concepts Introduced
 
-- `.Call()` — invoke a transport with payload and optional response capture
-- Address types — `LegacyRabbit`, `Microservice`, `Http`, `Graphql`, `Rabbit`
-- `resultKey` — store the service response in workflow state
-- `whenFailure` / `whenTimeout` — recovery branches
-- `WorkflowHandledBranchAction.Complete` — shorthand for "complete on error"
-- `timeoutSeconds` — per-step timeout override (default: 1 hour)
+- `.Call()` — invoke a transport with payload and optional response capture
+- Address types — `LegacyRabbit`, `Microservice`, `Http`, `Graphql`, `Rabbit`
+- `resultKey` — store the service response in workflow state
+- `whenFailure` / `whenTimeout` — recovery branches
+- `WorkflowHandledBranchAction.Complete` — shorthand for "complete on error"
+- `timeoutSeconds` — per-step timeout override (default: 1 hour)
 
 ## Key Points
 
@@ -25,5 +25,5 @@ Call external services (microservices, HTTP APIs, GraphQL, RabbitMQ) from within
 
 ## Next
 
-[Tutorial 3: Decisions](../03-decisions/) — branch workflow logic based on conditions.
+[Tutorial 3: Decisions](../03-decisions/) — branch workflow logic based on conditions.
 

docs/workflow/tutorials/03-decisions/README.md

@@ -1,13 +1,13 @@
-# Tutorial 3: Decisions
+# Tutorial 3: Decisions
 
-Branch workflow logic based on conditions — state values, payload answers, or complex expressions.
+Branch workflow logic based on conditions — state values, payload answers, or complex expressions.
 
 ## Concepts Introduced
 
-- `.WhenExpression()` — branch on any boolean expression
-- `.WhenStateFlag()` — shorthand for checking a boolean state value
-- `.WhenPayloadEquals()` — shorthand for checking a task completion payload value
-- Nested decisions — decisions inside decisions for complex routing
+- `.WhenExpression()` — branch on any boolean expression
+- `.WhenStateFlag()` — shorthand for checking a boolean state value
+- `.WhenPayloadEquals()` — shorthand for checking a task completion payload value
+- Nested decisions — decisions inside decisions for complex routing
 
 ## Decision Types
 
@@ -24,5 +24,5 @@ Branch workflow logic based on conditions — state values, payload answers
 
 ## Next
 
-[Tutorial 4: Human Tasks](../04-human-tasks/) — approve/reject patterns with OnComplete flows.
+[Tutorial 4: Human Tasks](../04-human-tasks/) — approve/reject patterns with OnComplete flows.
 

docs/workflow/tutorials/04-human-tasks/README.md

@@ -1,26 +1,26 @@
-# Tutorial 4: Human Tasks with OnComplete Flows
+# Tutorial 4: Human Tasks with OnComplete Flows
 
-The approve/reject pattern — the most common human task flow in insurance workflows.
+The approve/reject pattern — the most common human task flow in insurance workflows.
 
 ## Concepts Introduced
 
-- `WorkflowHumanTask.For<T>()` — define a task with name, type, route, and roles
-- `.WithPayload()` — data sent to the UI when the task is displayed
-- `.WithTimeout(seconds)` — optional deadline for the task
-- `.WithRoles()` — restrict which roles can interact with this task
-- `.OnComplete(flow => ...)` — sequence executed after user completes the task
-- `.ActivateTask()` — pause workflow and wait for user action
-- `.AddTask()` — register a task in the workflow spec (separate from activation)
-- Re-activation — send the user back to the same task on validation failure
+- `WorkflowHumanTask.For<T>()` — define a task with name, type, route, and roles
+- `.WithPayload()` — data sent to the UI when the task is displayed
+- `.WithTimeout(seconds)` — optional deadline for the task
+- `.WithRoles()` — restrict which roles can interact with this task
+- `.OnComplete(flow => ...)` — sequence executed after user completes the task
+- `.ActivateTask()` — pause workflow and wait for user action
+- `.AddTask()` — register a task in the workflow spec (separate from activation)
+- Re-activation — send the user back to the same task on validation failure
 
 ## Approve/Reject Pattern
 
 1. Workflow starts, runs some service tasks
-2. `.ActivateTask("Approve")` — workflow pauses
+2. `.ActivateTask("Approve")` — workflow pauses
 3. User sees the task in their inbox, assigns it, submits an answer
 4. `.OnComplete` checks `payload.answer`:
-   - `"approve"` — run confirmation operations, convert to policy
-   - `"reject"` — cancel the application
+   - `"approve"` — run confirmation operations, convert to policy
+   - `"reject"` — cancel the application
 5. If operations fail, re-activate the same task for correction
 
 ## Variants
@@ -30,5 +30,5 @@ The approve/reject pattern — the most common human task flow in insurance
 
 ## Next
 
-[Tutorial 5: Sub-Workflows](../05-sub-workflows/) — inline vs fire-and-forget child workflows.
+[Tutorial 5: Sub-Workflows](../05-sub-workflows/) — inline vs fire-and-forget child workflows.
 

docs/workflow/tutorials/05-sub-workflows/README.md

@@ -1,14 +1,14 @@
-# Tutorial 5: Sub-Workflows & Continuations
+# Tutorial 5: Sub-Workflows & Continuations
 
-Compose workflows by invoking child workflows — either inline (SubWorkflow) or fire-and-forget (ContinueWith).
+Compose workflows by invoking child workflows — either inline (SubWorkflow) or fire-and-forget (ContinueWith).
 
 ## SubWorkflow vs ContinueWith
 
 | Feature | `.SubWorkflow()` | `.ContinueWith()` |
 |---------|-----------------|-------------------|
-| Parent waits | Yes — resumes after child completes | No — parent completes immediately |
-| State flows back | Yes — child state merges into parent | No — child is independent |
-| Same instance | Yes — tasks appear under parent instance | No — new workflow instance |
+| Parent waits | Yes — resumes after child completes | No — parent completes immediately |
+| State flows back | Yes — child state merges into parent | No — child is independent |
+| Same instance | Yes — tasks appear under parent instance | No — new workflow instance |
 | Use when | Steps must complete before parent continues | Fire-and-forget, scheduled work |
 
 ## Variants
@@ -18,5 +18,5 @@ Compose workflows by invoking child workflows — either inline (SubWorkflo
 
 ## Next
 
-[Tutorial 6: Advanced Patterns](../06-advanced-patterns/) — Fork, Repeat, Timer, External Signal.
+[Tutorial 6: Advanced Patterns](../06-advanced-patterns/) — Fork, Repeat, Timer, External Signal.
 

docs/workflow/tutorials/06-advanced-patterns/README.md

@@ -1,4 +1,4 @@
-# Tutorial 6: Advanced Patterns
+# Tutorial 6: Advanced Patterns
 
 Fork (parallel branches), Repeat (retry loops), Timer (delays), and External Signal (wait for events).
 
@@ -18,5 +18,5 @@ Fork (parallel branches), Repeat (retry loops), Timer (delays), and External Sig
 
 ## Next
 
-[Tutorial 7: Shared Helpers](../07-shared-helpers/) — organizing reusable workflow components.
+[Tutorial 7: Shared Helpers](../07-shared-helpers/) — organizing reusable workflow components.
 

docs/workflow/tutorials/07-shared-helpers/README.md

@@ -1,4 +1,4 @@
-# Tutorial 7: Shared Support Helpers
+# Tutorial 7: Shared Support Helpers
 
 When building many workflows for the same domain (e.g., 50+ policy change workflows), extract reusable components into a support helper class.
 
@@ -6,19 +6,19 @@ When building many workflows for the same domain (e.g., 50+ policy change workfl
 
 | Component | Example |
 |-----------|---------|
-| **Address constants** | `LegacyRabbitAddress`, `HttpAddress` — centralized routing |
-| **Workflow references** | `WorkflowReference` — for SubWorkflow/ContinueWith targets |
+| **Address constants** | `LegacyRabbitAddress`, `HttpAddress` — centralized routing |
+| **Workflow references** | `WorkflowReference` — for SubWorkflow/ContinueWith targets |
 | **Payload builders** | Static methods returning `WorkflowExpressionDefinition` |
 | **State initializers** | Base state + override pattern |
 | **Flow extensions** | Extension methods on `WorkflowFlowBuilder<T>` for common sequences |
 
 ## C#-Only Tutorial
 
-This tutorial has no JSON equivalent — it covers C# code organization patterns.
+This tutorial has no JSON equivalent — it covers C# code organization patterns.
 
 - [C# Example](csharp/)
 
 ## Next
 
-[Tutorial 8: Expressions](../08-expressions/) — path navigation, functions, and operators.
+[Tutorial 8: Expressions](../08-expressions/) — path navigation, functions, and operators.
 

docs/workflow/tutorials/08-expressions/README.md

@@ -1,4 +1,4 @@
-# Tutorial 8: Expressions
+# Tutorial 8: Expressions
 
 The expression system enables declarative logic that compiles to portable canonical JSON. All expressions are evaluable at runtime without recompilation.
 
@@ -32,5 +32,5 @@ The expression system enables declarative logic that compiles to portable canoni
 
 ## Next
 
-[Tutorial 9: Testing](../09-testing/) — unit test setup with recording transports.
+[Tutorial 9: Testing](../09-testing/) — unit test setup with recording transports.