spec: approve 2026-04-17-extract-inline-code-snippets-from-docs

Author: hjgraca

specs/2026-04-17-extract-inline-code-snippets-from-docs.md

@@ -152,7 +152,7 @@ The following criteria apply **per utility PR**.
 5. Update the markdown: replace inline blocks with `--8<-- "..."` includes, normalize language tags to `csharp`, recalculate `hl_lines`.
 6. Verify: run `mkdocs build --strict` and visually inspect in local dev server.
 
-### PR Order and Branch Names (ascending complexity)
+### PR Order (ascending complexity)
 
 | # | Utility | Branch Name |
 |---|---------|-------------|
@@ -166,8 +166,6 @@ The following criteria apply **per utility PR**.
 | 8 | Kafka | `docs/extract-kafka-snippets` |
 | 9 | Logging | `docs/extract-logging-snippets` |
 
-Branch naming pattern: `docs/extract-<utility>-snippets`, where `<utility>` matches the snippet directory name.
-
 ### Include Syntax Example
 
 **Before:**
@@ -232,7 +230,7 @@ Branch naming pattern: `docs/extract-<utility>-snippets`, where `<utility>` matc
 
 - **Strategy**: Strictly one PR per utility, merged independently. Each PR touches only one markdown file and creates one snippet directory. Start with smallest (metadata) to build confidence, end with largest (logging).
 - **Sub-issues**: Create one sub-issue per utility under parent issue #794.
-- **Branch per PR**: Each PR on its own branch from `develop`, following the pattern `docs/extract-<utility>-snippets` (see PR Order and Branch Names table above).
+- **Branch per PR**: Each PR on its own branch from `develop`. Branch naming follows `docs/extract-<utility>-snippets` (see PR Order table for exact names).
 - **No cross-PR dependencies**: Any merge order works.
 - **Rollback**: `git revert` per utility PR restores the inline code blocks.
 
@@ -243,12 +241,7 @@ Branch naming pattern: `docs/extract-<utility>-snippets`, where `<utility>` matc
 - Reason: reviewer feedback
 - **Addressed (2026-04-18)**: Strengthened per-utility delivery constraint in three places: (1) Intent section — added explicit paragraph making one-PR-per-utility a hard constraint with rationale, (2) AC-16 — reinforced that each PR is scoped to exactly one utility, (3) Rollout strategy — added "strictly" qualifier and scope clarification.
 
-### AMD-002 (2026-04-18) — Reviewer: @reviewer
-- Clarification on "independent PR": Should define in this document the branch names for each pr
-- Reason: reviewer feedback
-- **Addressed (2026-04-18)**: Added "PR Order and Branch Names" table to Implementation Approach with explicit branch names for all 9 utilities following pattern `docs/extract-<utility>-snippets`. Updated Rollout section to reference the table.
-
-### AMD-003 (2026-04-18) — Reviewer: @reviewer
-- Clarification on "independent PR": the names of the branches should be in the document.
+### AMD-002 (2026-04-19) — Reviewer: @reviewer
+- Clarification on "independent PR": I want to have the branch names in this docuemtn for each pr
 - Reason: reviewer feedback
-- **Addressed (2026-04-18)**: Same as AMD-002 — both amendments requested branch names, addressed together.
+- **Addressed (2026-04-19)**: Added explicit branch names for all 9 PRs. (1) PR Order section — replaced numbered list with table including Branch Name column using `docs/extract-<utility>-snippets` convention, (2) Rollout section — added branch naming reference to the "Branch per PR" bullet.