sync docs changes to md

Author: krylosov-aa

Makefile

@@ -23,5 +23,8 @@ build:
 publish:
 	uv publish
 
-build_docs:
+docs_build:
 	mkdocs build -f docs_sources/mkdocs.yml -d ../docs
+
+docs_serve:
+	mkdocs serve -f docs_sources/mkdocs.yml

docs/index.html

@@ -221,5 +221,5 @@ <h2 id="how-it-works">How it works</h2>
 
 <!--
 MkDocs version : 1.6.1
-Build Date UTC : 2026-01-12 21:26:27.089860+00:00
+Build Date UTC : 2026-01-12 21:31:58.475550+00:00
 -->

docs/testing/index.html

@@ -111,21 +111,19 @@ <h1 id="testing">Testing</h1>
 <ol>
 <li>
 <p><strong>Separate sessions</strong>: The test uses its own session that prepares data and
-verifies results after execution. The application also has its own session.</p>
-</li>
-<li>
-<p>It is a more "honest" way to test the application.</p>
-</li>
+   verifies results after execution. The application also has its own session.</p>
+<ul>
+<li>It is a more "honest" way to test the application.</li>
 <li>Verifies how it handles sessions and transactions automatically.</li>
-<li>
-<p>The ability to inspect the database state when the test is paused.
-Complex session management scenarios make other test methods difficult or impossible (e.g., concurrent query execution).</p>
+<li>The ability to inspect the database state when the test is paused.</li>
+<li>Complex session management scenarios make other test methods difficult or impossible (e.g., concurrent query execution).</li>
+</ul>
 </li>
 <li>
 <p><strong>Shared session and transaction</strong>: The test and the application share the same session and transaction.</p>
-</li>
-<li>
-<p>Rolling back transactions is faster and takes less time than starting a new session.</p>
+<ul>
+<li>Rolling back transactions is faster and takes less time than starting a new session.</li>
+</ul>
 </li>
 </ol>
 <p>In my projects, I use both approaches at the same time:</p>

docs_sources/docs/testing.md

@@ -5,16 +5,17 @@ When testing with a real database, one important problem needs to be solved: ens
 There are two approaches:
 
 1. **Separate sessions**: The test uses its own session that prepares data and
-verifies results after execution. The application also has its own session.
+   verifies results after execution. The application also has its own session.
 
-- It is a more "honest" way to test the application.
-- Verifies how it handles sessions and transactions automatically.
-- The ability to inspect the database state when the test is paused.
-Complex session management scenarios make other test methods difficult or impossible (e.g., concurrent query execution).
+    - It is a more "honest" way to test the application.
+    - Verifies how it handles sessions and transactions automatically.
+    - The ability to inspect the database state when the test is paused.
+    - Complex session management scenarios make other test methods difficult or impossible (e.g., concurrent query execution).
 
 2. **Shared session and transaction**: The test and the application share the same session and transaction.
 
-- Rolling back transactions is faster and takes less time than starting a new session.
+    - Rolling back transactions is faster and takes less time than starting a new session.
+
 
 
 In my projects, I use both approaches at the same time: