docs: add CHANGELOG.md to track version history and notable changes

CHANGELOG.md

@@ -0,0 +1,31 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on Keep a Changelog.
+
+## [Unreleased]
+
+### Added
+
+### Changed
+
+### Fixed
+
+## [0.1.0]
+
+### Added
+- Multi-AI support for content generation.
+- Multi-platform publishing support (Dev.to, Hashnode, Medium, and custom webhooks).
+- Safari extension support through Xcode Web Extension Converter.
+- Database support for dashboard functionality.
+- Per-platform publishing status reporting.
+- Architecture documentation with system flow diagrams.
+
+### Changed
+- Python version locked to 3.12.3 for consistency across development environments.
+- Added Makefile support for common development workflows.
+- Integrated Ruff linting and pytest configuration.
+
+### Fixed
+- General stability and workflow improvements across publishing and dashboard modules.

backend/ai.py

@@ -42,47 +42,45 @@ def _build_prompt(problem, current_time: str) -> str:
     """
     badge = _difficulty_badge(getattr(problem, "difficulty", None) or "Unknown")
     custom_instructions = ""
-
     default_prompt = f"""
-You are a professional technical writer and competitive programmer.
-
-Generate a highly engaging, beginner-friendly Dev.to blog post about a LeetCode problem.
-
-Author Account: {problem.author}
-Publishing Time: {current_time}
-Title: {problem.title}
-Difficulty: {badge}
-
-Problem Description:
-{problem.description}
-
-Solution Code:
-{problem.code}
-
-Strictly follow this structure:
-1. Title (Use an engaging # Title instead of YAML)
-2. Difficulty Badge — render it prominently right below the title as: **Difficulty:** {badge}
-3. Problem Explanation (explain it simply, as if to a beginner)
-4. Intuition (the "aha!" moment)
-5. Approach (step-by-step logic)
-6. Code (formatted clearly inside markdown code blocks, specify language if obvious)
-7. Time & Space Complexity Analysis
-8. Key Takeaways
-9. Submission Details (MUST include the Author Account [{problem.author}] and the Time Published [{current_time}] in a concluding footnote)
-
-CRITICAL INSTRUCTIONS:
-- DO NOT wrap the output in ```markdown or ``` tags. Return raw markdown text.
-- DO NOT output YAML frontmatter (no --- blocks).
-- TABLE FORMATTING (STRICT RULES):
-  - If you use a Markdown table, it MUST be perfectly formatted to render correctly.
-  - Each row (header, separator, or data) MUST start with `|` and end with `|`.
-  - A table row MUST be on exactly ONE single line. DO NOT use line breaks inside rows.
-  - The header row, separator row (e.g., `|---|---|`), and all data rows MUST have the EXACT same number of columns.
-  - CELL CONTENT: If a cell contains a bitwise OR operator `|` or any pipe character, you MUST escape it as `\\|` (e.g., `(a \\| b)`). Failing to escape pipes inside cells will break the table structure.
-  - Ensure the separator line is continuous (no line breaks) and uses at least 3 dashes per column.
-  - Always provide an EMPTY LINE before and after the table to ensure correct rendering.
-"""
+        You are a professional technical writer and competitive programmer.
+
+        Generate a highly engaging, beginner-friendly Dev.to blog post about a LeetCode problem.
+
+        Author Account: {problem.author}
+        Publishing Time: {current_time}
+        Title: {problem.title}
+        Difficulty: {badge}
 
+        Problem Description:
+        {problem.description}
+
+        Solution Code:
+        {problem.code}
+
+        Strictly follow this structure:
+        1. Title (Use an engaging # Title instead of YAML)
+        2. Difficulty Badge — render it prominently right below the title as: **Difficulty:** {badge}
+        3. Problem Explanation (explain it simply, as if to a beginner)
+        4. Intuition (the "aha!" moment)
+        5. Approach (step-by-step logic)
+        6. Code (formatted clearly inside markdown code blocks, specify language if obvious)
+        7. Time & Space Complexity Analysis
+        8. Key Takeaways
+        9. Submission Details (MUST include the Author Account [{problem.author}] and the Time Published [{current_time}] in a concluding footnote)
+
+        CRITICAL INSTRUCTIONS:
+        - DO NOT wrap the output in ```markdown or ``` tags. Return raw markdown text.
+        - DO NOT output YAML frontmatter (no --- blocks).
+        - TABLE FORMATTING (STRICT RULES):
+        - If you use a Markdown table, it MUST be perfectly formatted to render correctly.
+        - Each row (header, separator, or data) MUST start with `|` and end with `|`.
+        - A table row MUST be on exactly ONE single line. DO NOT use line breaks inside rows.
+        - The header row, separator row (e.g., `|---|---|`), and all data rows MUST have the EXACT same number of columns.
+        - CELL CONTENT: If a cell contains a bitwise OR operator `|` or any pipe character, you MUST escape it as `\\|` (e.g., `(a \\| b)`). Failing to escape pipes inside cells will break the table structure.
+        - Ensure the separator line is continuous (no line breaks) and uses at least 3 dashes per column.
+        - Always provide an EMPTY LINE before and after the table to ensure correct rendering.
+    """   
     if hasattr(problem, "custom_prompt") and problem.custom_prompt:
         cleaned = problem.custom_prompt.strip()
         if cleaned: