@drafthq/draft 3.5.3 → 3.7.1

package/core/templates/architecture.md

@@ -79,6 +79,7 @@ The Graph Health & Fidelity Dashboard (above) is the first artifact any reader o
 The longest and most precise section.
 
 Every invariant must include:
+
 - Precise statement
 - Why violation is dangerous
 - Enforcement mechanism (test, runtime, type system, review, graph constraint, or none)
@@ -86,7 +87,7 @@ Every invariant must include:
 
 Example format:
 
-```
+```text
 ### INV-003: Sentinel Lock Ordering
 **Rule**: `_strategies_lock < _strategy_process_locks < _global_capacity_lock < entry_lock`
 **Fidelity**: High (enforced in code + tests)
@@ -106,6 +107,7 @@ Focus on the highest-value dynamic behavior:
 - Lifecycle sequences (bootstrap, shutdown, reconciliation, failover)
 
 Each backed by:
+
 - Graph-derived paths where available
 - High-quality Mermaid (stateDiagram-v2, sequenceDiagram, or detailed flowchart)
 - Explicit note when the flow is only partially visible in the graph
@@ -135,6 +137,7 @@ Include a short "graph coverage for this view" paragraph.
 ## 6. Error Handling & Failure Mode Catalog
 
 For every major component or flow:
+
 - What can go wrong
 - How it is detected
 - The defined safe response
@@ -145,6 +148,7 @@ For every major component or flow:
 ## 7. State & Data Truth Sources + Reconciliation
 
 For each major domain:
+
 - Authoritative source
 - Derived / cached views
 - Reconciliation mechanisms and lag tolerance
@@ -201,4 +205,4 @@ AI agents are trained by the document itself to treat Stub and Human Judgment cl
 
 **End of clean graph-primary architecture template.**
 
-This is the single forward-looking source of truth. Legacy 28-section volume-oriented material has been retired.
+This is the single forward-looking source of truth. Legacy 28-section volume-oriented material has been retired.

package/core/templates/discovery.md

@@ -67,7 +67,7 @@ track ID, or `_NONE_FOUND_` with justification.
 
 Flat list of files and functions touched in the spike. Files cited here
 without line numbers are exempt from drift checks (they document
-*familiarity*, not pinned facts).
+_familiarity_, not pinned facts).
 
 - _TBD_reference_1_path_ — _TBD_reference_1_symbol_ — _TBD_reference_1_role_
 - _TBD_reference_2_path_ — _TBD_reference_2_symbol_ — _TBD_reference_2_role_

package/core/templates/guardrails.md

@@ -32,21 +32,25 @@ Run `/draft:learn` to scan the codebase and update learned patterns. Quality com
 <!-- Hard constraints that must never be violated. Check [x] to enable enforcement. -->
 
 ### Git & Version Control
+
 - [ ] No direct commits to main/master
 - [ ] No force push to shared branches
 - [ ] PR required for all changes
 
 ### Code Quality
+
 - [ ] No console.log/print statements in production code
 - [ ] No commented-out code blocks
 - [ ] No TODO comments without linked issue
 
 ### Security
+
 - [ ] No secrets/credentials in code
 - [ ] No disabled security checks without documented exception
 - [ ] Dependencies must pass security audit
 
 ### Testing
+
 - [ ] Tests required before merge
 - [ ] No skipped tests without documented reason
 - [ ] Coverage must not decrease
@@ -67,6 +71,7 @@ Run `/draft:learn` to scan the codebase and update learned patterns. Quality com
 - [x] G1.12: No `shared_ptr` binding to non-trivial objects (EventDriver holders) in callbacks
 
 ### C++/Systems — Concurrency & Locking
+
 - [x] G2.1: No mutable operations under shared/read locks
 - [x] G2.2: Always release spinlock before invoking callbacks or `Finish()`
 - [x] G2.3: No expensive object destruction under spinlock protection
@@ -74,12 +79,14 @@ Run `/draft:learn` to scan the codebase and update learned patterns. Quality com
 - [x] G2.5: No synchronous waits (`Trigger::Wait`) in async code paths
 
 ### C++/Systems — Control Flow & Error Handling
+
 - [x] G3.1: Always `return` after `Finish()` in conditional blocks
 - [x] G3.2: CHECKs for internal consistency only — never for external input validation
 - [x] G3.3: No side-effecting expressions inside DCHECK
 - [x] G3.4: CHECK/DCHECK/LOG(DFATAL) selection per severity matrix
 
 ### C++/Systems — Format & API Correctness
+
 - [x] G4.1: Printf format specifiers must match argument types
 - [x] G4.2: MemTracer Print vs Printf selection (lazy construction vs immediate materialization)
 - [x] G4.3: Use Maybe-prefixed MemTracer variants only when op may be finished
@@ -87,9 +94,11 @@ Run `/draft:learn` to scan the codebase and update learned patterns. Quality com
 - [x] G4.5: `boost::optional<bool>` tests presence, not value — use `*xx` or `.value_or()`
 
 ### C++/Systems — GFlags & Runtime Configuration
+
 - [x] G5.1: Snapshot gflag values at op start — never depend on flag stability mid-op
 
 ### C++/Systems — Performance
+
 - [x] G6.1: Avoid `ByteSize()` on proto objects in hot paths
 - [x] G6.2: Prefer repeated fields over map fields in proto for serialization-sensitive paths
 - [x] G6.3: No inline execution in `SpawnWorkersAndJoin` `done_cb`

package/core/templates/hld.md

@@ -194,9 +194,9 @@ For each component, populate one subsection:
 
 Provide a brief list and summary of all inventions associated with the proposed design.
 
-1. 
-2. 
-3. 
+1.
+2.
+3.
 
 **Were Invention Disclosure Forms (IDFs) submitted for the inventions listed?**
 
@@ -208,6 +208,7 @@ Provide a brief list and summary of all inventions associated with the proposed
 ### Third Party Technology (TPT)
 
 **TPT includes:**
+
 - **Open Source Software (OSS):** Software licensed under an Open Source License (e.g., MIT, BSD, GPL, Apache)
 - **Commercial (non-OSS) Technology:** Non- software, documentation, content, APIs, SDKs, logos, artwork, data, GUIs, Tools, databases, and other intellectual property NOT licensed under an Open Source License
 
@@ -289,7 +290,7 @@ Provide a brief list and summary of all inventions associated with the proposed
 
 ### Cost Implications <!-- REQUIRED -->
 
-*Primarily for SaaS deployments*
+_Primarily for SaaS deployments_
 
 - Include cloud cost calculation here
 - Is there any cost to the customer for cloud workloads?

package/core/templates/intake-questions.md

@@ -28,17 +28,20 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ## Phase 1: Initial Context
 
 ### Question 1.1: Existing Documentation
+>
 > Start here. Gather any existing context before diving in.
 
 **Ask:**
 > "Do you have existing documentation for this work? (PRD, RFC, design doc, Jira ticket, or any notes)"
 
 **If yes:**
+
 - Request the document or key excerpts
 - Ingest and extract: goals, requirements, constraints, open questions
 - Summarize: "I've extracted [X, Y, Z]. I notice [gap] isn't covered yet."
 
 **If no:**
+
 - Acknowledge: "No problem. Let's build this from scratch together."
 - Proceed to Phase 2
 
@@ -49,10 +52,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ## Phase 2: Problem Space
 
 ### Question 2.1: Problem Definition
+
 **Ask:**
 > "What problem are we solving?"
 
 **After response, contribute:**
+
 - Pattern recognition: "This sounds similar to [industry pattern]..."
 - Domain concepts: Reference Jobs-to-be-Done, DDD problem space if relevant
 - Clarifying probe: "When you say [X], do you mean [A] or [B]?"
@@ -62,10 +67,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 2.2: Urgency & Impact
+
 **Ask:**
 > "Why does this problem matter now? What happens if we don't solve it?"
 
 **After response, contribute:**
+
 - Validate urgency: Is this symptom or root cause?
 - Impact analysis: Who's affected? How severely?
 - Reference: 5 Whys technique if they're describing symptoms
@@ -75,10 +82,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 2.3: Users & Workarounds
+
 **Ask:**
 > "Who experiences this pain? How do they currently cope?"
 
 **After response, contribute:**
+
 - User segmentation: Are there different user types with different needs?
 - Workaround analysis: Current workarounds often reveal requirements
 - Prior art: "Similar products handle this by [X]..."
@@ -88,10 +97,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 2.4: Scope Boundary
+
 **Ask:**
 > "What's the scope boundary? Where does this problem end and adjacent problems begin?"
 
 **After response, contribute:**
+
 - Identify adjacent problems that should NOT be solved here
 - Reference: Bounded Context (DDD)
 - Flag scope creep risks: "I'd suggest explicitly excluding [X]..."
@@ -104,6 +115,7 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 
 **Summarize:**
 > "Here's what we've established about the problem:
+>
 > - Problem: [summary]
 > - Why now: [summary]
 > - Users: [summary]
@@ -118,10 +130,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ## Phase 3: Solution Space
 
 ### Question 3.1: Simplest Solution
+
 **Ask:**
 > "What's the simplest version that solves this problem?"
 
 **After response, contribute:**
+
 - MVP identification: What's truly essential vs nice-to-have?
 - Gold-plating risks: "We could simplify by [X]..."
 - Reference: YAGNI, Walking Skeleton, Tracer Bullet (Pragmatic Programmer)
@@ -131,10 +145,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 3.2: Approach Rationale
+
 **Ask:**
 > "Why this approach over alternatives?"
 
 **After response, contribute:**
+
 - Present 2-3 alternative approaches with trade-offs
 - Reference: Architecture Decision Records pattern
 - Probe: "Have you considered [alternative]? Trade-off would be [X]..."
@@ -144,10 +160,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 3.3: Explicit Non-Goals
+
 **Ask:**
 > "What are we explicitly NOT doing? What should be out of scope?"
 
 **After response, contribute:**
+
 - Suggest common scope creep items to exclude
 - Reference: Anti-goals pattern, MoSCoW prioritization
 - "I'd recommend also excluding [X] to keep scope tight..."
@@ -157,10 +175,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 3.4: Architecture Fit
+
 **Ask:**
 > "How does this fit with the current architecture?"
 
 **After response, contribute:**
+
 - Cross-reference `draft/.ai-context.md` (or `draft/architecture.md`) for integration points
 - Identify affected modules/components
 - Reference: Clean Architecture boundaries, module coupling
@@ -171,10 +191,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 3.5: Reusable Patterns
+
 **Ask:**
 > "What existing patterns or components can we leverage?"
 
 **After response, contribute:**
+
 - Search codebase context for reusable patterns
 - Suggest tech-stack.md conventions to follow
 - Reference: DRY, existing abstractions
@@ -188,6 +210,7 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 
 **Summarize:**
 > "Here's the proposed solution:
+>
 > - Approach: [summary]
 > - Why this approach: [rationale]
 > - Not doing: [non-goals]
@@ -203,10 +226,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ## Phase 4: Risk & Constraints
 
 ### Question 4.1: What Could Go Wrong
+
 **Ask:**
 > "What could go wrong with this approach?"
 
 **After response, contribute:**
+
 - Surface risks user may not have considered
 - Security: Reference OWASP Top 10 if relevant
 - Performance: Identify potential bottlenecks
@@ -218,10 +243,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 4.2: Dependencies & Blockers
+
 **Ask:**
 > "What dependencies or blockers exist? (External APIs, other teams, data, infrastructure)"
 
 **After response, contribute:**
+
 - Identify external dependencies and their reliability
 - Team dependencies: Who else needs to be involved?
 - Data dependencies: What data do we need? Where does it come from?
@@ -232,10 +259,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 4.3: Assumptions
+
 **Ask:**
 > "What assumptions are we making? Why might this fail?"
 
 **After response, contribute:**
+
 - List implicit assumptions explicitly
 - Fact-check against `draft/tech-stack.md` and `draft/.ai-context.md`
 - Reference: Pre-mortem technique
@@ -246,10 +275,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 4.4: Constraints
+
 **Ask:**
 > "What constraints must we operate within? (Timeline, tech limitations, compliance, performance requirements)"
 
 **After response, contribute:**
+
 - Identify tech constraints from tech-stack.md
 - Performance requirements: Latency, throughput, scale
 - Compliance: GDPR, SOC2, industry-specific
@@ -260,10 +291,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 4.5: Security & Compliance
+
 **Ask:**
 > "Are there security or compliance considerations?"
 
 **After response, contribute:**
+
 - Flag relevant OWASP concerns
 - Data privacy: PII handling, encryption, access control
 - Authentication/authorization patterns
@@ -277,6 +310,7 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 
 **Summarize:**
 > "Key risks and constraints identified:
+>
 > - Risks: [list]
 > - Dependencies: [list]
 > - Assumptions: [list]
@@ -292,10 +326,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ## Phase 5: Success Criteria
 
 ### Question 5.1: Definition of Done
+
 **Ask:**
 > "How do we know this is complete? What must be true when we're done?"
 
 **After response, contribute:**
+
 - Suggest measurable acceptance criteria
 - Convert vague criteria to testable outcomes
 - Reference: SMART criteria, Given-When-Then format
@@ -306,10 +342,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 5.2: Verification Strategy
+
 **Ask:**
 > "How will we verify it works correctly?"
 
 **After response, contribute:**
+
 - Suggest testing strategies appropriate to feature type
 - Reference: Test pyramid, TDD practices
 - Integration testing: What integration points need testing?
@@ -320,10 +358,12 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 ---
 
 ### Question 5.3: Stakeholder Acceptance
+
 **Ask:**
 > "What would make stakeholders accept this? What does success look like to them?"
 
 **After response, contribute:**
+
 - Align with product.md goals
 - Suggest demo scenarios
 - Reference: Stakeholder analysis, acceptance criteria patterns
@@ -337,6 +377,7 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 
 **Summarize:**
 > "Success criteria defined:
+>
 > - Done when: [criteria list]
 > - Verified by: [testing approach]
 > - Stakeholders accept when: [demo scenarios]
@@ -360,11 +401,13 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 > Ready to finalize this spec, or any changes needed?"
 
 **If changes needed:**
+
 - Discuss specific sections
 - Update spec-draft.md
 - Return to this review step
 
 **If confirmed:**
+
 - Promote spec-draft.md → spec.md
 - Announce: "Spec finalized. Now let's create the implementation plan."
 
@@ -374,6 +417,7 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 
 **After spec is finalized, propose plan structure:**
 > "Based on the spec, I propose these phases:
+>
 > - Phase 1: [name] — [goal]
 > - Phase 2: [name] — [goal]
 > - Phase 3: [name] — [goal]
@@ -382,6 +426,7 @@ Structured questions for track creation. **Ask ONE question at a time.** Wait fo
 > Does this phasing make sense, or should we adjust?"
 
 **After confirmation:**
+
 - Build out detailed plan-draft.md with tasks
 - Present for review
 - On confirmation: promote plan-draft.md → plan.md

package/core/templates/jira.md

@@ -28,11 +28,12 @@ labels: # Labels to apply to all created issues
 # Jira Story Template (Minimal)
 
 ## Summary
+
 [Brief, descriptive title]
 
 ## Description
 
-```
+```text
 h3. Description:
 
 Problem Statement:
@@ -68,7 +69,7 @@ Use Cases:
 
 ## Acceptance Criteria
 
-```
+```text
 - [ ] [Criterion 1: Specific, testable requirement]
 - [ ] [Criterion 2: Specific, testable requirement]
 - [ ] [Criterion 3: Specific, testable requirement]
@@ -77,35 +78,42 @@ Use Cases:
 ## Required Fields
 
 ### Standard Fields
+
 - **Issue Type:** Story
 - **Priority:** Medium
 - **Components:** [Component name]
 - **Fix Version/s:** [Version or master]
 
 ### People
+
 - **Assignee:** [Your email]
 - **Product Owner:** [PO email]
 - **Tech Lead:** [Tech lead email]
 - **Scrum Master:** [Scrum master email]
 
 ### Team
+
 - **Developers:** [List developer emails]
 - **Reviewers:** [List reviewer emails]
 
 ### Story Details
+
 - **Story Points:** [1/2/3/5/8/13]
 - **Work Type:** Operational Excellence
 - **Sub-Team:** [Sub-team name]
 - **Organization:** R&D
 
 ### Development Status
+
 - **Development Status:** Not-Started
 
 ### Security
+
 - **Requires Security Review:** Yes/No
 - **Security Review Status:** Review Needed
 
 ### Quality Gates
+
 - [ ] Tasks complete
 - [ ] Functional Testing complete
 - [ ] 100% code unit tested or Automated
@@ -113,6 +121,7 @@ Use Cases:
 - [ ] i18n impact review
 
 ### Other
+
 - **Risk Assessment:** Toss Up
 - **Priority Level:** Normal
 - **Category:** Uncategorized

package/core/templates/lld.md

@@ -48,7 +48,7 @@ links:
 <Link to HLD and explain context here>
 
 > See [`./hld.md` §Background](./hld.md#background) for the high-level rationale. Use this section only for component-internal context the HLD doesn't cover.
-
+>
 > **Citations.** Use `path/to/file.ext:LINE` (or `LINE-RANGE`); verifier:
 > `scripts/tools/verify-citations.sh`. Prefer `// DRAFT-CITE: <id>` source
 > anchors over raw line numbers for code that moves often.
@@ -67,6 +67,7 @@ links:
 ## Low Level Design
 
 > **NOTE:**
+>
 > - HLD and Detailed Design covers components and interactions across various services that the feature touches
 > - LLD to be documented here is for each such component and internal implementation
 > - A single doc here can cover all components, or they can be split up, but the key is to ensure every component in every service the design touches has an LLD
@@ -159,6 +160,7 @@ links:
 > deploy-checklist fail on bare prose without diagram blocks.
 
 Examples:
+
 - List of steps to failover a multi-region database cluster
 - Analysis phase of a background data indexing service
 - Transferring session state information between authentication and profile services via a secure messaging protocol
@@ -188,13 +190,14 @@ sequenceDiagram
 
 **Pseudocode:**
 
-```
+```text
 1. validate inputs
 2. ...
 3. return result
 ```
 
 **Edge cases handled:**
+
 - {case 1 — what happens}
 - {case 2 — what happens}
 
@@ -269,9 +272,9 @@ sequenceDiagram
 
 List down all metrics that developers and SREs need to look at to identify issues:
 
-- 
-- 
-- 
+-
+-
+-
 
 ### Alerting Thresholds
 

package/core/templates/okf/concept.md

@@ -60,4 +60,3 @@ okf-validate-quality.sh and therefore does NOT satisfy okf-coverage-check.sh —
 the bundle will not be promoted. Diagram types (Subsystem/Module/Feature/
 Entrypoint) require ≥1 valid Mermaid block and ≥2 x-grounded-paths.
 -->
-

package/core/templates/plan.md

@@ -111,7 +111,7 @@ validator chain via the canonical resolver pattern (see
 [core/shared/verification-gates.md](../../core/shared/verification-gates.md)):
 
 ```bash
-DRAFT_TOOLS="$(cat ~/.cache/draft/plugin-root 2>/dev/null)/scripts/tools"
+DRAFT_TOOLS="${DRAFT_PLUGIN_ROOT:-$(cat ~/.cache/draft/plugin-root 2>/dev/null)}/scripts/tools"
 [ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$(ls -d ~/.claude/plugins/cache/*/draft/*/scripts/tools 2>/dev/null | sort -V | tail -1)"
 [ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$(ls -d ~/.claude/plugins/marketplaces/*draft*/scripts/tools 2>/dev/null | tail -1)"
 [ -d "$DRAFT_TOOLS" ] || DRAFT_TOOLS="$PWD/scripts/tools"

package/core/templates/product.md

@@ -26,10 +26,12 @@ generated_at: "{ISO_TIMESTAMP}"
 ## Target Users
 
 ### Primary Users
+
 - **[User Type 1]**: [What they need, their context]
 - **[User Type 2]**: [What they need, their context]
 
 ### Secondary Users
+
 - **[Admin/Support]**: [Their interaction with the product]
 
 ---
@@ -37,15 +39,18 @@ generated_at: "{ISO_TIMESTAMP}"
 ## Core Features
 
 ### Must Have (P0)
+
 1. **[Feature 1]**: [Brief description]
 2. **[Feature 2]**: [Brief description]
 3. **[Feature 3]**: [Brief description]
 
 ### Should Have (P1)
+
 1. **[Feature 4]**: [Brief description]
 2. **[Feature 5]**: [Brief description]
 
 ### Nice to Have (P2)
+
 1. **[Feature 6]**: [Brief description]
 
 ---
@@ -61,16 +66,16 @@ generated_at: "{ISO_TIMESTAMP}"
 ## Constraints
 
 ### Technical
+
 - [Constraint, e.g., "Must support IE11"]
 - [Constraint, e.g., "API response time < 200ms"]
 
 ### Business
+
 - [Constraint, e.g., "Must comply with GDPR"]
 - [Constraint, e.g., "Budget for external APIs: $X/month"]
 
 ### Timeline
-- [Milestone 1]: [Date]
-- [Milestone 2]: [Date]
 
 ---
 
@@ -93,19 +98,23 @@ Things explicitly out of scope for this product:
 ## Guidelines (Optional)
 
 ### Writing Style
+
 - **Tone:** [professional / casual / technical]
 - **Voice:** [first person "we" / third person "the system" / second person "you"]
 - **Terminology:** [domain-specific terms and definitions]
 
 ### UX Principles
+
 1. [e.g., "Convention over configuration" — minimize required decisions]
 2. [e.g., "Accessible by default" — WCAG AA compliance minimum]
 3. [e.g., "Progressive disclosure" — show complexity only when needed]
 
 ### Error Handling
+
 - **Error message tone:** [helpful / technical / minimal]
 - **User feedback patterns:** [toasts / modals / inline / status bar]
 
 ### Content Standards
+
 - **Date format:** [ISO 8601 / localized / relative]
 - **Internationalization:** [i18n required / English-only / planned]

package/core/templates/rca.md

@@ -64,15 +64,19 @@ generated_at: "{ISO_TIMESTAMP}"
 ## Prevention Items
 
 ### Detection Improvement
+
 - [ ] [monitoring/alerting improvement to catch this sooner]
 
 ### Process Improvement
+
 - [ ] [review/testing improvement to prevent this class of bug]
 
 ### Code Improvement
+
 - [ ] [guard/validation to add in code]
 
 ### Architecture Improvement
+
 - [ ] [structural change if needed to make this class of bug impossible]
 
 ## Proposed Fix
@@ -80,8 +84,10 @@ generated_at: "{ISO_TIMESTAMP}"
 [Brief description of the fix approach — developer reviews before implementation]
 
 **Files to modify:**
+
 - `file1:line` — [change description]
 - `file2:line` — [change description]
 
 **Regression test:**
+
 - [Description of regression test to write — pending developer approval]