How the Git repository, technical Markdown, this Wiki and the Production Changelog relate to each other.

Rules #

1. Source code and technical .md files live in Git (git@github.com:advertech/signage-estimator.git, server checkout /root/signage-estimator). Git is the source of truth.
2. The WordPress Wiki is the searchable, readable knowledge layer on top of Git. It explains how the system works and links back to code and files.
3. Significant technical Markdown may be published/synchronised into the Wiki. Imported articles carry a metadata box (source file, repository, commit SHA, import time) and live in Reference Files plus their topical sections.
4. The Production Changelog is written only after a production deploy — never per commit.
5. Each changelog entry contains the deployed production Git commit SHA.
6. One production release can include many commits. Git may have many commits between two changelog entries.
7. Old articles are never silently overwritten with wrong information. If a document is outdated, set Status: Deprecated (or Historical) or re-verify it and update Last verified.

Languages #

• The main Wiki language is Russian (URLs without prefix). The second language is English (URLs under /en/); the language switcher is in the top-right corner.
• Most Markdown files in Git are written in English. Their Russian translations live in /root/wiki-sign-expert/translations/ru/; English translations of Russian files live in translations/en/.
• The first line of a translation records which version of the original it was made from: <!-- translation-of: <path> @ <git blob sha> -->. If the file in Git changes later, the import still publishes the article but marks it “⚠ Translation may be outdated” until the translation is refreshed.
• Technical identifiers (class, field and endpoint names, commands) and application UI labels are not translated.

Importing Markdown from Git #

One-way sync, Git → Wiki, run as root on the production server:

/root/wiki-sign-expert/import_git_docs.py --dry-run          # preview
/root/wiki-sign-expert/import_git_docs.py                    # import from HEAD of /root/signage-estimator
/root/wiki-sign-expert/import_git_docs.py --commit <sha>     # import the exact deployed commit

• Content is read from the committed blob (git show <sha>:<path>), not from uncommitted working-tree edits. The repository is never modified.
• Articles are matched by source path and language, so re-running updates the same article instead of creating duplicates.
• The list of imported files, their titles and Wiki sections is the DOCS map in the script. To publish a new file, add it there and put its translation in translations/.
• Do not edit imported articles in WordPress — edits are overwritten by the next import. Change the Markdown in Git (or the translation file) instead. Wiki-native articles (like this one) are edited in WordPress.
• Security- and infrastructure-sensitive files (deploy/DEPLOYMENT.md, SECURITY.md, SECURITY_RECONCILIATION.md) are imported as private: visible only to logged-in editors.

Release flow #

1. Develop and commit in Git (any number of commits).
2. Deploy to production following the Deployment Runbook.
3. Record the deployed SHA: git -C /root/signage-estimator rev-parse HEAD.
4. Re-import docs at that SHA: import_git_docs.py --commit <sha>; refresh translations marked as outdated.
5. Add one Production Changelog entry for the release (see How to write a Production Changelog entry), linking the affected Wiki articles.