Slice #22.1: Move ADR/QS/R headings to section level

example/src/docs/arc42/09-architecture-decisions/adr-001-backend-api-boundary.adoc

@@ -20,37 +20,37 @@ relations:
 metadata_version: '1.0'
 ---
 [[adr-001-backend-api-boundary]]
-= ADR-001: Backend API Boundary
+== ADR-001: Backend API Boundary
 
-== Status
+=== Status
 
 Proposed.
 
-== Decision
+=== Decision
 
 We propose a versioned HTTP JSON API as the boundary between web UI, mobile app,
 and backend.
 
-== Context
+=== Context
 
 The application has two clients and one backend system of record. Both clients
 need the same budget commands and summaries.
 
-== Considered Options
+=== Considered Options
 
-=== HTTP JSON API
+==== HTTP JSON API
 
 Simple to consume from web and mobile clients.
 
-=== GraphQL
+==== GraphQL
 
 Flexible for clients, but more complexity than the first increment needs.
 
-=== Client-specific backends
+==== Client-specific backends
 
 Allows tailored client APIs, but duplicates budget behavior early.
 
-== Pugh Matrix
+=== Pugh Matrix
 
 [cols="2,1,1,1", options="header"]
 |===
@@ -61,10 +61,10 @@ Allows tailored client APIs, but duplicates budget behavior early.
 s| Sum s| 3 s| 0 s| -2
 |===
 
-== Consequences
+=== Consequences
 
 * Web UI and mobile app share the same backend contract.
 * API versioning must be managed deliberately.
 
-include::generated/adr-001-backend-api-boundary-traceability.adoc[]
+include::generated/adr-001-backend-api-boundary-traceability.adoc[leveloffset=+1]
 

example/src/docs/arc42/09-architecture-decisions/adr-002-mobile-local-first-entry.adoc

@@ -27,23 +27,23 @@ relations:
 metadata_version: '1.0'
 ---
 [[adr-002-mobile-local-first-entry]]
-= ADR-002: Mobile Local-First Expense Entry
+== ADR-002: Mobile Local-First Expense Entry
 
-== Status
+=== Status
 
 Proposed.
 
-== Decision
+=== Decision
 
 We propose that the mobile app stores pending expense commands locally and syncs
 them when connectivity returns.
 
-== Context
+=== Context
 
 Expense entry often happens away from a stable network. Losing an entry makes
 the budget less trustworthy.
 
-== Pugh Matrix
+=== Pugh Matrix
 
 [cols="2,1,1,1", options="header"]
 |===
@@ -54,10 +54,10 @@ the budget less trustworthy.
 s| Sum s| 1 s| 1 s| -1
 |===
 
-== Consequences
+=== Consequences
 
 * Users can enter expenses offline.
 * Sync conflict handling becomes an explicit architecture concern.
 
-include::generated/adr-002-mobile-local-first-entry-traceability.adoc[]
+include::generated/adr-002-mobile-local-first-entry-traceability.adoc[leveloffset=+1]
 

example/src/docs/arc42/09-architecture-decisions/adr-003-server-owned-budget-calculation.adoc

@@ -20,22 +20,22 @@ relations:
 metadata_version: '1.0'
 ---
 [[adr-003-server-owned-budget-calculation]]
-= ADR-003: Server-Owned Budget Calculation
+== ADR-003: Server-Owned Budget Calculation
 
-== Status
+=== Status
 
 Proposed.
 
-== Decision
+=== Decision
 
 We propose to calculate budget totals and remaining amounts on the backend.
 
-== Context
+=== Context
 
 The web UI and mobile app should display the same budget state. Client-only
 calculation would duplicate business rules.
 
-== Pugh Matrix
+=== Pugh Matrix
 
 [cols="2,1,1,1", options="header"]
 |===
@@ -46,10 +46,10 @@ calculation would duplicate business rules.
 s| Sum s| 3 s| -3 s| 2
 |===
 
-== Consequences
+=== Consequences
 
 * Budget rules have one implementation point.
 * Backend availability affects live budget summaries.
 
-include::generated/adr-003-server-owned-budget-calculation-traceability.adoc[]
+include::generated/adr-003-server-owned-budget-calculation-traceability.adoc[leveloffset=+1]
 

example/src/docs/arc42/10-quality-requirements/qs-001-budget-total-integrity.adoc

@@ -20,9 +20,9 @@ relations:
 metadata_version: '1.0'
 ---
 [[qs-001-budget-total-integrity]]
-= QS-001: Budget Total Integrity
+== QS-001: Budget Total Integrity
 
-== Scenario
+=== Scenario
 
 [cols="1,3", options="header"]
 |===
@@ -35,5 +35,5 @@ metadata_version: '1.0'
 | Response Measure | Assumption: service-level tests cover create, edit, delete, and retry cases with no unexplained total drift.
 |===
 
-include::generated/qs-001-budget-total-integrity-traceability.adoc[]
+include::generated/qs-001-budget-total-integrity-traceability.adoc[leveloffset=+1]
 

example/src/docs/arc42/10-quality-requirements/qs-002-expense-entry-latency.adoc

@@ -20,9 +20,9 @@ relations:
 metadata_version: '1.0'
 ---
 [[qs-002-expense-entry-latency]]
-= QS-002: Expense Entry Latency
+== QS-002: Expense Entry Latency
 
-== Scenario
+=== Scenario
 
 [cols="1,3", options="header"]
 |===
@@ -35,5 +35,5 @@ metadata_version: '1.0'
 | Response Measure | Assumption: p95 interaction time stays below 2 seconds after the user submits the form.
 |===
 
-include::generated/qs-002-expense-entry-latency-traceability.adoc[]
+include::generated/qs-002-expense-entry-latency-traceability.adoc[leveloffset=+1]
 

example/src/docs/arc42/10-quality-requirements/qs-003-offline-expense-capture.adoc

@@ -20,9 +20,9 @@ relations:
 metadata_version: '1.0'
 ---
 [[qs-003-offline-expense-capture]]
-= QS-003: Offline Expense Capture
+== QS-003: Offline Expense Capture
 
-== Scenario
+=== Scenario
 
 [cols="1,3", options="header"]
 |===
@@ -35,5 +35,5 @@ metadata_version: '1.0'
 | Response Measure | Assumption: no pending expense is lost across app restart during the outage.
 |===
 
-include::generated/qs-003-offline-expense-capture-traceability.adoc[]
+include::generated/qs-003-offline-expense-capture-traceability.adoc[leveloffset=+1]
 

example/src/docs/arc42/11-risks-and-technical-debt/r-001-private-data-exposure.adoc

@@ -20,15 +20,15 @@ relations:
 metadata_version: '1.0'
 ---
 [[r-001-private-data-exposure]]
-= R-001: Private Budget Data Exposure
+== R-001: Private Budget Data Exposure
 
-== Risk Statement
+=== Risk Statement
 
 Because budget data contains personal spending patterns, weak authorization,
 transport security, or logging may expose sensitive information to unauthorized
 parties.
 
-== Assessment
+=== Assessment
 
 [cols="1,3", options="header"]
 |===
@@ -40,10 +40,10 @@ parties.
 | Confidence | Medium.
 |===
 
-== Mitigation Options
+=== Mitigation Options
 
 Use authenticated API access, server-side authorization, transport encryption,
 password hashing, and log redaction.
 
-include::generated/r-001-private-data-exposure-traceability.adoc[]
+include::generated/r-001-private-data-exposure-traceability.adoc[leveloffset=+1]
 

example/src/docs/arc42/11-risks-and-technical-debt/r-002-sync-conflict-loss.adoc

@@ -20,15 +20,15 @@ relations:
 metadata_version: '1.0'
 ---
 [[r-002-sync-conflict-loss]]
-= R-002: Sync Conflict Causes Expense Loss
+== R-002: Sync Conflict Causes Expense Loss
 
-== Risk Statement
+=== Risk Statement
 
 Because the mobile app queues offline commands, a retry or conflict may lose,
 duplicate, or misapply an expense unless commands are idempotent and conflicts
 are visible.
 
-== Assessment
+=== Assessment
 
 [cols="1,3", options="header"]
 |===
@@ -40,10 +40,10 @@ are visible.
 | Confidence | Medium.
 |===
 
-== Mitigation Options
+=== Mitigation Options
 
 Use client-generated command IDs, idempotent backend processing, and explicit
 conflict feedback.
 
-include::generated/r-002-sync-conflict-loss-traceability.adoc[]
+include::generated/r-002-sync-conflict-loss-traceability.adoc[leveloffset=+1]
 

example/templates/adr.adoc

@@ -17,45 +17,45 @@ relations:
     reviewed: false
 ---
 [[adr-000-short-title]]
-= ADR-000: Short Decision Topic
+== ADR-000: Short Decision Topic
 
-== Status
+=== Status
 
 Proposed.
 
 This ADR is AI-assisted and must not be treated as accepted architecture truth
 until reviewed and accepted by the accountable owner.
 
-== Decision
+=== Decision
 
 We propose to choose the selected option.
 
-== Context
+=== Context
 
 Describe the problem, forces, constraints, affected architecture artifacts, and
 source-code evidence inspected before writing this decision.
 
-== Decision Drivers
+=== Decision Drivers
 
 * Driver 1.
 * Driver 2.
 * Driver 3.
 
-== Considered Options
+=== Considered Options
 
-=== Option 1: Name
+==== Option 1: Name
 
 Describe benefits, costs, risks, and fit to the drivers.
 
-=== Option 2: Name
+==== Option 2: Name
 
 Describe benefits, costs, risks, and fit to the drivers.
 
-=== Option 3: Name
+==== Option 3: Name
 
 Describe benefits, costs, risks, and fit to the drivers.
 
-== Pugh Matrix
+=== Pugh Matrix
 
 Use `+1` for better support, `0` for neutral support, and `-1` for weaker
 support. Mark cells with `?` when assessment requires human review. Add each
@@ -72,21 +72,21 @@ the sum for that option is `?`.
 s| Sum s| ? s| 0 s| ?
 |===
 
-== Consequences
+=== Consequences
 
-=== Positive
+==== Positive
 
 * Positive consequence.
 
-=== Negative
+==== Negative
 
 * Negative consequence.
 
-=== Neutral or Follow-Up
+==== Neutral or Follow-Up
 
 * Follow-up decision or implementation concern.
 
-== Impact
+=== Impact
 
 [cols="1,1,3", options="header"]
 |===
@@ -95,22 +95,22 @@ s| Sum s| ? s| 0 s| ?
 | xref:risk.adoc#risk-000-short-title[RISK-000-short-title] | introduced | Explain the risk impact.
 |===
 
-== Traceability
+=== Traceability
 
 [cols="1,1,3", options="header"]
 |===
 | Relation | Target | Rationale
 | `addresses` | xref:quality-scenario.adoc#qs-000-short-title[QS-000-short-title] | Explain the relation.
 |===
 
-== Assumptions
+=== Assumptions
 
 * Assumption requiring review.
 
-== Open Questions
+=== Open Questions
 
 * Question for the accountable owner.
 
-== Review Notes
+=== Review Notes
 
 State what must be confirmed before this ADR can be marked reviewed or accepted.