The four hosts of the site now allow Cloudflare's Web Analytics beacon, but ARCHITECTURE.md and OPERATIONS.md still said the policy blocks every script an intermediary adds. Both now name the beacon, where it loads from and where it reports, and keep the forum placeholder's same-origin policy apart.
The integrity tests still expected tazel.tala.run to serve the Vue build with its own robots.txt and sitemap.xml. They now count four app-shell hosts and check the redirect itself: the two former pages go to their pages under tazel.net/docs/reference/ with the query string, other docs paths to tazel.net/docs, everything else to the same path, the /docs/ prefix is a plain one so the regular expression is reached, and HSTS stays. OPERATIONS.md and ARCHITECTURE.md list tazel.tala.run as a permanent redirect instead of a documentation site.
Nginx sent every path that is not a file to index.html with 200, so probes such as /wp-admin/install.php, xmlrpc.php and phpinfo.php were answered as pages: scanners take that for a hit, and search engines index soft 404s. The three server blocks now fall back to @application, which serves the app shell only for the routes of the application, / and /docs/<page>, and answers every other path with 404. error_page keeps index.html as the body of the 404, so a visitor still reaches the landing page through the router. A test reads the three sitemaps and requires every listed page to match the accepted routes, and scanner paths, /docs and nested paths not to; it also requires the same route rule in all three blocks. OPERATIONS.md describes the expected 404s, and asks for --no-same-owner, chown -R root:root and LF line endings when files are copied from a developer machine: the 2026-10-18 release had left the frontend owned by a Windows user ID. Applied on the server with the owner's approval and verified: nginx -t is clean; /, /docs/overview, talac /docs/command-line, tazel /docs/commands, robots.txt and /api/v1/site answer 200; /wp-admin/install.php, /no-such-page and /docs answer 404. npm test passes, 45 tests.
An audit of the site against the compiler repository found statements that no longer hold, in all four languages: - the overview named BUILD.kts as the project definition, while Tazel reads one of five names; it now says a project file, BUILD.kts or one of four other names; - the overview and the getting-started guide named Windows and macOS as the only development hosts. Ubuntu 26.04 LTS and Fedora 43 are official hosts too, and the guide says which toolchain they use; - the getting-started guide listed the counterparts of the examples in C#, C++ and Java; the examples also have Rust ones; - the project-file page wrote build/debug/Example without the .exe a Windows build has. The talac, Tazel and syntax pages were checked against Documents/CLI.md, Documents/PROJECT_FILES.md and Spec/Language and are otherwise accurate. Of the 43 links in the repository, only the address inside the Fira Sans licence text no longer answers; that text is third-party and verbatim. The browser storage keys still carried the former name of the language: vxs-locale-choice, vxs-theme and vxs-forum-theme become tala-locale-choice, tala-theme and tala-forum-theme. A value under a former key moves to the current one on the first page load, so no visitor loses a choice; a forum test covers the move. The npm package is renamed from @visual-xsharp/website to @progmasoft/tala-website, and the forum assets get a new version query so Cloudflare serves the new script.
The Kotlin backend checked its documentation with Dokka; the ASP.NET Core API had only the compiler warning for a public declaration without a comment. CI now builds the API reference with DocFX, every warning as an error, and Documents/api/CheckDocumentation.cs fails when a namespace, type or member of the reference has no description, internal and private members included. The setup is the one Progmaweb uses: the docfx tool pinned in .config/dotnet-tools.json, the configuration and the namespace description under Documents/api, and the generated reference ignored.
- README, Architecture and Operations describe the three sites one build serves, their routes, the per-host sitemap and robots files, forum.tala.run, the permanent redirects of the former domain, and that tala.run has no ViGet host. - The backend sections describe the ASP.NET Core 10 API: how to build, test, run and publish it, its lock files, and its place on the server in current/site-api beside the legacy process of Progmaweb. - Development explains ?site=talac and ?site=tazel on a development host and lists the new test file; the release and rollback steps label current/site-api for SELinux as well. - The development server proxies /api to port 5086, the port the API uses unless PORT says otherwise.
The pages were renamed; the rest of the repository still said Visual X#: - the site API answered with the name Visual X#, and its test expected it; - the documents, the issue and pull request templates, the support address and the name of the code scanning configuration. The documents also said that a left-to-right mark follows the name of the language in Hebrew text. That was for the `#` of the old name; the sentence now speaks of names that end in a symbol, such as C#. Not changed: host names, paths and unit names on the server, the name of the backend artifact, the Kotlin package of the backend, and the keys of the browser storage.
The documents still described a site in maintenance with two languages and a forum page with a language menu. They now describe what is published, and three documents are new. New, under Documents/: - README.md: index of the documentation. - ARCHITECTURE.md: the frontend, the backend and the forum page, what each serves, what the site deliberately does not contain, and how search engines and crawlers are treated. - LOCALIZATION.md: the four languages, how a page picks one, what counts as a visitor's choice, how Hebrew text is laid out, where the text lives and how to add a language. - DEVELOPMENT.md: requirements, the commands of each part, the dependency locks and checksums, the tests and what CI enforces. Updated: - README.md: the site is public; four languages and the browser-language default; a documentation section; the Dokka gate. - CONTENT.md: the forum notice without a language menu; translation rules for four languages, including preferring the term a reader would use over a literal one; the crawler rules as an owner decision. - OPERATIONS.md: the live route table; the release steps for the directory layout on the server, with the SELinux labelling order that caused an outage once; cache keys for the forum files and CDN caching; maintenance mode as a fallback instead of the current state; rollback by directory; checksum regeneration with --refresh-dependencies; the post-release check for four languages and right-to-left text. No source file changes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Russian (ru-RU) is the third locale of the language site: the shell, the home, overview and getting-started pages, and the page metadata are fully translated, and the language menu offers it. The documentation sidebar reads its labels from the page messages instead of a two-way locale test, and the stored preference is accepted only when it names a supported locale. The forum placeholder gets the same three languages. Its language control is now a menu instead of a two-state button, and an unknown stored or selected value keeps the current language. The site API lists the new locale. Verified locally: prettier, the frontend tests, vue-tsc and the Vite build, the backend tests, and a browser run of the home and overview pages in Russian.