strictdoc-project · stanislaw · Oct 5, 2025 · Oct 5, 2025
diff --git a/.gitignore b/.gitignore
@@ -54,3 +54,6 @@ strictdoc/export/html2pdf/.wdm
 
 ### Test reports
 reports/
+
+### Draw.io
+.*.drawio.bkp
diff --git a/.link_health.yml b/.link_health.yml
@@ -33,3 +33,4 @@ exceptions:
   - url: https://github.com/doorstop-dev/doorstop/blob/804153c67c7c5466ee94e9553118cc3df03a56f9/reqs/REQ001.yml
   - url: https://github.com/tiangolo/fastapi/blob/master/LICENSE
   - url: https://github.com/strictdoc-project/strictdoc/blob/main/about/2025_ESA_SW_Product_Assurance_Workshop.pdf
+  - url: https://github.com/strictdoc-project/strictdoc/blob/main/strictdoc/core/project_config.py
diff --git a/developer/drawio/Architecture.drawio b/developer/drawio/Architecture.drawio
diff --git a/developer/drawio/Backlog.drawio b/developer/drawio/Backlog.drawio
diff --git a/developer/drawio/Roadmap.drawio b/developer/drawio/Roadmap.drawio
diff --git a/developer/drawio/Workspace.drawio b/developer/drawio/Workspace.drawio
diff --git a/docs/_assets/StrictDoc_Workspace-Architecture.drawio.png b/docs/_assets/StrictDoc_Workspace-Architecture.drawio.png
diff --git a/docs/_assets/StrictDoc_Workspace-Backlog.drawio.png b/docs/_assets/StrictDoc_Workspace-Backlog.drawio.png
diff --git a/docs/_assets/StrictDoc_Workspace-Roadmap.drawio.png b/docs/_assets/StrictDoc_Workspace-Roadmap.drawio.png
diff --git a/docs/strictdoc_01_user_guide.sdoc b/docs/strictdoc_01_user_guide.sdoc
@@ -3181,12 +3181,22 @@ If the ``output-dir`` option is not provided, the ``output/`` folder is the defa
 
 [[SECTION]]
 MID: 17a8adb92c8d4e7992e869355e73912d
-TITLE: Options
+TITLE: Configuration
+
+[TEXT]
+MID: 1b42e7a029f5452abbf1fe35411f8e3d
+STATEMENT: >>>
+.. warning::
+
+    StrictDoc is migrating from TOML to Python for its configuration files, see the migration note: [LINK: SECTION-UG-MIGRATE-CONFIG-2025-Q4].
+
+Once the new Python configuration syntax has been sufficiently tested, using TOML will trigger deprecation warnings. The removal of TOML support is expected to take place in 2026-Q1.
+<<<
 
 [[SECTION]]
 MID: 05f82bdf26f141738d2f511133633a2d
 UID: SDOC_UG_OPTIONS_PROJECT_LEVEL
-TITLE: Project-level options
+TITLE: Project-level configuration
 
 [TEXT]
 MID: 6449098df878484fbe8aed8a8b0e9a97
@@ -4423,4 +4433,54 @@ Additionally, when the section behavior is specified to ``[[SECTION]]``, the UI
 
 [[/SECTION]]
 
+[[SECTION]]
+MID: d20ff7cbf64f4db7afb6c82b70445e55
+UID: SECTION-UG-MIGRATE-CONFIG-2025-Q4
+TITLE: Migrating StrictDoc Configuration: Python Replaces TOML (2025 Q4)
+
+[TEXT]
+MID: f72351be40d84f23970f93720c3625c7
+STATEMENT: >>>
+Until 2025-Q4, StrictDoc has been using TOML for its ``strictdoc.toml`` configuration file.
+
+Since 2025-Q4, the new configuration format moving forward is Python. Once the new Python configuration syntax has been sufficiently tested, using TOML will trigger deprecation warnings. The removal of TOML support is expected to take place in 2026-Q1.
+
+The rationale for this change is that configuring StrictDoc with a Python file provides greater flexibility for users who need to:
+
+- Create custom generators
+- Remove existing generators
+- Customize requirement and document tree validations
+- Customize project statistics
+
+With a configuration file written directly in Python, it becomes much easier for users to inject their own Python code into StrictDoc’s traceability pipeline. Achieving the same with TOML would require additional layers of indirection.
+
+Instead of using ``strictdoc.toml``, the new approach includes ``strictdoc_config.py`` with the following syntax:
+
+.. code-block:: py
+
+    from strictdoc.core.project_config import ProjectConfig
+
+
+    def create_config() -> ProjectConfig:
+        config = ProjectConfig(
+            project_title="StrictDoc Documentation",
+            dir_for_sdoc_assets="assets",
+            dir_for_sdoc_cache="output/_cache",
+            project_features=[
+                "TRACEABILITY_SCREEN",
+                "SEARCH",
+            ],
+            # ...
+        )
+        return config
+
+All TOML configuration options specified in StrictDoc’s documentation are still valid but must be migrated to their Python equivalents.
+
+See `StrictDoc's own config file <https://github.com/strictdoc-project/strictdoc/blob/main/strictdoc/core/project_config.py>`_ for a realistic example.
+
+Refer to the `ProjectConfig <https://github.com/strictdoc-project/strictdoc/blob/main/strictdoc/core/project_config.py>`_ class for a complete overview of all available options.
+<<<
+
+[[/SECTION]]
+
 [[/SECTION]]
diff --git a/docs/strictdoc_03_faq.sdoc b/docs/strictdoc_03_faq.sdoc
@@ -382,7 +382,15 @@ TITLE: How long has the StrictDoc project been around?
 [TEXT]
 MID: 47d60404cf574aebb8c83795589c4137
 STATEMENT: >>>
-The first StrictDoc commit dates back to ``2019-08-10``. A short development chronology of StrictDoc is as follows:
+.. note::
+
+    The complete list of the project milestones is maintained in the Development Plan: [LINK: SECTION-DP-Project-milestones].
+
+Below is a brief chronology of the early development of StrictDoc.
+
+----
+
+The first StrictDoc commit dates back to ``2019-08-10``.
 
 **2019 – July – August**
 
@@ -406,12 +414,6 @@ The result of these efforts was the realization that a text-based requirements a
 **2020 – July**
 
 The custom RST parser was replaced with a TextX-based DSL. Since then, StrictDoc has been using TextX for parsing SDoc files.
-
-**2022 – November**
-
-The FastAPI/Turbo/Stimulus-based Web interface prototype was created to complement the text-based interface with a graphical user interface (GUI). When the Web-based GUI is stable, StrictDoc may become useable by non-programmers too.
-
-See also: [LINK: SECTION-DP-Project-milestones].
 <<<
 
 [[/SECTION]]

diff --git a/docs/strictdoc_04_release_notes.sdoc b/docs/strictdoc_04_release_notes.sdoc
@@ -45,6 +45,36 @@ STATEMENT: >>>
 This document maintains a record of all changes to StrictDoc since November 2023. It serves as a user-friendly version of the changelog, complementing the automatically generated, commit-by-commit changelog available as GitHub releases: `StrictDoc Releases <https://github.com/strictdoc-project/strictdoc/releases>`_.
 <<<
 
+[[SECTION]]
+MID: 403c9f0ad6c34b50b25133f1d9357335
+TITLE: Unreleased (2025-10-05)
+
+[TEXT]
+MID: 9baeff3b28ea4bfe9ca8afe6b21826a8
+STATEMENT: >>>
+This release introduces a new feature: configuring StrictDoc using a Python file instead of a TOML file, improvements to parsing SDoc nodes from source files, and the removal of the legacy ``Section/[SECTION]`` element.
+
+1\) **Parsing StrictDoc configuration from a Python file:**
+StrictDoc can now be configured using a Python file rather than a TOML file. This new method (``strictdoc_config.py``) is intended to replace ``strictdoc.toml`` in the long term.
+
+The rationale for this change is that configuring StrictDoc with a Python file provides more flexibility for users who need to:
+
+- Create custom generators
+- Remove existing generators
+- Customize requirement and document tree validations
+- Customize project statistics.
+
+See [LINK: SECTION-UG-MIGRATE-CONFIG-2025-Q4] for migration instructions.
+
+2\) **Parsing SDoc nodes from source files:**
+The feature for parsing SDoc files from source code has been extended to support the SPDX-* syntax. This means that SDoc nodes can now be parsed not only from test files but also from source files.
+
+3\) **Removal of legacy Section/[SECTION]:**
+The legacy ``Section/[SECTION]`` element has been fully removed from the codebase, completing the migration to composite ``[[SECTION]]`` nodes. From now on, all projects using the old ``[SECTION]`` syntax will generate an error and receive a suggestion to migrate to the new syntax.
+<<<
+
+[[/SECTION]]
+
 [[SECTION]]
 MID: 9e294d6a047b42bf8c55c090fb685b4a
 TITLE: 0.13.0 (2025-09-28)

diff --git a/docs/strictdoc_24_development_plan.sdoc b/docs/strictdoc_24_development_plan.sdoc
@@ -80,6 +80,18 @@ StrictDoc shall be compatible with other software and engineering tools. This in
 
 [[/SECTION]]
 
+[[SECTION]]
+MID: 10fba42c4c444be89823d82944f7326f
+TITLE: Roadmap
+
+[TEXT]
+MID: ae3ab626e10a4aff9b7748bee75fd816
+STATEMENT: >>>
+All StrictDoc work is tracked on GitHub via the `StrictDoc issues <https://github.com/strictdoc-project/strictdoc/issues>`_ and `StrictDoc Pull Requests <https://github.com/strictdoc-project/strictdoc/pulls>`_ on GitHub.
+
+As an open-source project, StrictDoc is developed without strict deadlines. However, there are certain high-level priorities that influence its development. In particular, features aligned with the core roadmap and those strongly requested by active users are usually given the highest priority. StrictDoc also benefits from contributions by users who want a particular feature and are willing to develop it themselves.
+<<<
+
 [[SECTION]]
 MID: f1e3c17829fd4eebbd390fceaeb95619
 UID: SECTION-DP-Project-milestones
@@ -88,7 +100,7 @@ TITLE: Project milestones
 [TEXT]
 MID: fd9294fdd2b546de993f649767371394
 STATEMENT: >>>
-As an open-source project, StrictDoc is developed without strict deadlines, however there are certain high-level priorities that influence the development. The work is loosely organized in quarters.
+The work is loosely organized in quarters which are maintained as `GitHub milestones <https://github.com/strictdoc-project/strictdoc/milestones>`_, such as 2025-Q1, 2025-Q2, etc.
 
 .. list-table::
    :header-rows: 1
@@ -143,25 +155,60 @@ As an open-source project, StrictDoc is developed without strict deadlines, howe
      - Connecting requirements to functions (C, Python) and classes (Python) in source code. Support the linking in both directions independently: from requirements to source using RELATION/File and from source to requirements using @relation markers. LINK to documents.
    * - 2025-Q1
      - Connecting requirements to source code – further work. StrictDoc containerized in Docker. JUnit XML report generation.
-   * - 2025-Q2 (planned)
+   * - 2025-Q2
      - Gcov coverage justification report. SDoc node VERSIONs. External links.
+   * - 2025-Q3
+     - Static HTML search. Testing large documentation trees (100+ documents). Tree map visualization. Initial work for Ada support.
+   * - 2025-Q4
+     - Python file for StrictDoc configuration instead of TOML. Requirement validations and node constraints. Reading SDoc nodes from source files, e.g., ``SPDX-*`` identifiers.
 <<<
 
+[[/SECTION]]
+
 [[SECTION]]
 MID: bf9f3f05501140da8d35cde39493c72f
-TITLE: The roadmap diagram
+TITLE: Roadmap diagram
 
 [TEXT]
 MID: 53e101acb20e44e89de27f0f77c5f0cb
 STATEMENT: >>>
-The following diagram contains the work items at the epic and single task levels. This PNG file is exported from a draw.io diagram, where the master version of the roadmap is maintained.
+Additionally, a StrictDoc project maintains a high-level roadmap overview using a draw.io diagram.
+
+The diagram contains work items at both the epic and single-task levels. It represents the already open StrictDoc GitHub issues, as well as some concepts in the backlog that are yet to be worked on.
 
 .. image:: _assets/StrictDoc_Workspace-Roadmap.drawio.png
    :alt: Development plan diagram
    :class: image
    :width: 100%
+<<<
+
+[[/SECTION]]
+
+[[SECTION]]
+MID: 0adcf781ba5b47b0b2e421db2fd97acb
+TITLE: Backlog
+
+[TEXT]
+MID: 4c253eba99644f2dad971e0b0d79f143
+STATEMENT: >>>
+StrictDoc maintains its backlog in a dedicated SDoc document (see [LINK: SDOC_BACKLOG]), as well as among the GitHub issues specifically tracked under the milestone `Backlog <https://github.com/strictdoc-project/strictdoc/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A20XX-Backlog>`_.
+<<<
 
-The roadmap and other artifacts are maintained at a publicly available draw.io diagram workspace `here <https://drive.google.com/file/d/1pkI0T1eAbcTSyCnqH4wCKKQSOfgWTaxi/view>`_.
+[[/SECTION]]
+
+[[SECTION]]
+MID: 21917df7f66d464a9d9a717def2e10db
+TITLE: Backlog diagram
+
+[TEXT]
+MID: c34b77865324416f98a36aa8bdb0fcaa
+STATEMENT: >>>
+The following diagram contains the backlog work items at the epic and single task levels.
+
+.. image:: _assets/StrictDoc_Workspace-Backlog.drawio.png
+   :alt: StrictDoc Backlog
+   :class: image
+   :width: 100%
 <<<
 
 [[/SECTION]]
@@ -190,6 +237,22 @@ STATEMENT: >>>
 StrictDoc's development incorporates quality measures to ensure a high standard of code quality.
 <<<
 
+[[SECTION]]
+MID: 185776da602c49589f9252b46a9ce663
+TITLE: Bug reporting and tracking
+
+[TEXT]
+MID: a7874a49450448dfbfb557f9495f2b6e
+STATEMENT: >>>
+StrictDoc provides an issue template for bug reports, which users can use to report bugs and other issues.
+
+All known bugs in StrictDoc are reported as GitHub issues and labeled with the Bug tag:
+
+`Known StrictDoc issues and bugs <https://github.com/strictdoc-project/strictdoc/issues?q=is%3Aissue%20state%3Aopen%20type%3ABug>`_
+<<<
+
+[[/SECTION]]
+
 [[SECTION]]
 MID: bc49b1e28fff4386b3bf5788a6686a79
 TITLE: Linting of code
@@ -245,7 +308,7 @@ Most of StrictDoc's implemented features are tested through its own documentatio
 - Source files and tests
 - Tests, test results, and code coverage data
 
-As of Q2 2025, the goal is to achieve 100% traceability across all artifacts in the StrictDoc codebase.
+The goal is to achieve 100% traceability across all artifacts in the StrictDoc codebase.
 <<<
 
 [[/SECTION]]
@@ -271,7 +334,7 @@ TITLE: Python baseline
 [TEXT]
 MID: 081ee6266bab4a3a80f290c95e055a25
 STATEMENT: >>>
-The supported version of Python is kept to be as low as possible. As of 2024-Q4, the currently supported version is Python 3.8.
+The supported version of Python is kept to be as low as possible. As of 2025-Q4, the currently supported version is Python 3.9.
 
 Ideally, the lowest Python version should only be raised when it is consistently deprecated by the major software platforms like Ubuntu or GitHub Actions.
 

diff --git a/docs/strictdoc_28_Backlog.sdoc b/docs/strictdoc_28_Backlog.sdoc
@@ -1,6 +1,7 @@
 [DOCUMENT]
 MID: cabef7629dda4f2fb34255d01fea8d5f
 TITLE: StrictDoc Backlog
+UID: SDOC_BACKLOG
 VERSION: Git commit: @GIT_VERSION, Git branch: @GIT_BRANCH
 DATE: @GIT_COMMIT_DATETIME
 PREFIX: SDOC-BACKLOG-
@@ -102,6 +103,12 @@ The real-time editing feature is hard to achieve with a small part-time involvem
 
 [[/SECTION]]
 
+[[SECTION]]
+MID: 17cc0a3e936b45e581de5ed57bcba801
+TITLE: Backlog high-level overview
+
+[[/SECTION]]
+
 [[SECTION]]
 MID: 7614a9f4f7bd4b1c9899995ac3d1e6ad
 UID: SECTION-SB-Backlog

diff --git a/tasks.py b/tasks.py
@@ -1135,3 +1135,43 @@ def check_file_owner(filepath):
 def qualification(context):
     test_all(context, coverage=True, headless=True)
     coverage_combine(context)
+
+
+@task()
+def drawio(context):
+    path_to_drawio = "/Applications/draw.io.app/Contents/MacOS/draw.io"
+
+    artifacts = [
+        (
+            "developer/drawio/Architecture.drawio",
+            "docs/_assets/StrictDoc_Workspace-Architecture.drawio.png",
+        ),
+        (
+            "developer/drawio/Backlog.drawio",
+            "docs/_assets/StrictDoc_Workspace-Backlog.drawio.png",
+        ),
+        (
+            "developer/drawio/Roadmap.drawio",
+            "docs/_assets/StrictDoc_Workspace-Roadmap.drawio.png",
+        ),
+    ]
+
+    for path_to_drawio_, path_to_png_ in artifacts:
+        print(f"Copying: {path_to_drawio_} -> {path_to_png_}")  # noqa: T201
+
+        # Basic safety for now to avoid writing wrong files.
+        os.path.isfile(path_to_drawio_), path_to_drawio_
+        os.path.isfile(path_to_png_), path_to_png_
+
+        run_invoke(
+            context,
+            f"""
+            {path_to_drawio}
+                --export
+                --format png
+                -o {path_to_png_}
+                --page-index 0
+                {path_to_drawio_}
+            """,
+            pty=True,
+        )