The build that serves tala.run, talac.tala.run and tazel.tala.run now
also serves the formatter and the linter, chosen by host name like the
others. Each site has a landing page and two documentation pages in
en-US, de-DE, ru-RU and he-IL:

- talafmt: the command line (inputs, --check, --emit, exit status 2 for
  an unreadable line) and what it changes (indentation, line endings,
  trailing whitespace, the final newline; protected text; encodings from
  talafmt.kts).
- talalint: the command line (--fix) and what it checks: the compiler's
  diagnostics as compiler.<code>, and format.trailingWhitespace,
  format.mixedLineEndings and format.missingFinalNewline. --fix rewrites a
  file with talafmt's default layout, which also re-indents blocks.

The facts follow the READMEs of Progmasoft/talafmt and Progmasoft/talalint
0.1.0 and the talalint source. site.ts lists the sites once, with their
names, so the header, the landing page and the documentation shell no
longer keep their own copies. Each host has its robots.txt and
sitemap.xml, nginx gains the two server blocks, and the tests check the
new hosts like the others.

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.

.run has no HSTS requirement of its own, but tala.run is served as if it
had one: every HTTPS response of tala.run, www, talac, tazel and forum
sends max-age=63072000; includeSubDomains; preload, and plain HTTP only
answers the ACME challenge and otherwise redirects to HTTPS. A test
checks both for every tala.run block of the three Nginx files. The
redirects of the former .xyz domain keep their header.

The language now lives at tala.run. One frontend build serves three
sites and picks its content from the host name:

- tala.run: the home page, /docs/overview, /docs/getting-started and a
  new /docs/syntax, a first look at programs, comments, declarations,
  operators and evaluation by need, with every sample taken from the
  public specification.
- talac.tala.run: /docs/command-line and /docs/outputs, the compiler's
  options, the entry rule, warnings, --build and --emit, and the record
  of a check.
- tazel.tala.run: /docs/commands and /docs/project-file, the commands of
  the build system, target selection, workspaces and the project DSL.

The new pages are written in all four locales from one content model;
a test keeps code samples and option names identical across them. The
header links the three sites and forum.tala.run. On a development host
?site=talac or ?site=tazel selects a site.

Corrections to the existing pages:

- Getting started used `go run scripts/develop.go`, `talac check -File`,
  `talac build -File` and `-Help`; it now uses `go run ./helpers/cmd/...`,
  `--emit=metadata`, `--entry=` and `--help`.
- The overview no longer names the retired .vxse extension, and the
  project DSL is evaluated by Tazel.
- Canonical URLs, Open Graph data, robots.txt and the sitemap name
  tala.run; talac and tazel have their own robots and sitemap files,
  served per host by Nginx. The notice about the move is gone: the
  former domain redirects instead.
- The leopard mark files are called tala-mark.svg and tala.svg.

Nginx: ops/nginx/tala.conf serves the three hosts, redirects www.tala.run
to tala.run and every path of xsharp-lang.xyz to the same path of
tala.run, and keeps viget.xsharp-lang.xyz pointing at
viget.progmasoft.com; tala.run has no ViGet host of its own.
ops/nginx/forum.conf serves the informational page at forum.tala.run and
redirects the former forum address to it.

The language website ran a Spring Boot application on JVM 25 for two
endpoints, and it was the only JVM on the server: a quarter of a
gigabyte of resident memory for /api/v1/site and /health. The server
already runs ASP.NET Core 10 for Progmaweb.

The API is now Progmasoft.Tala.Website.Api, a minimal ASP.NET Core 10
application under the namespace Progmasoft.Tala.Website. It answers as
before: /api/v1/site returns the site's own state as the same JSON,
POST is not allowed there, /health answers with an empty 200, and every
other path is 404. It listens on 127.0.0.1, port 5086 unless PORT says
otherwise, as the Spring process did, so Nginx is unchanged.

- Progmasoft.Tala.Website.slnx, Directory.Build.props and global.json
  set up the solution with warnings as errors, documentation comments
  required and NuGet lock files.
- Progmasoft.Tala.Website.Api.Tests runs the endpoints in an in-memory
  host with xUnit v3 on Microsoft.Testing.Platform.
- ops/systemd/tala-site-api.service runs the published DLL on the shared
  runtime from /srv/xsharp/website/current/site-api, with the hardening
  of the unit it replaces.
- CI builds, tests, publishes and reports coverage with dotnet; CodeQL
  analyzes C# instead of Kotlin; Renovate watches NuGet instead of
  Gradle.

Invoke the framework-dependent registry status API through the installed dotnet runtime so copied immutable releases do not depend on apphost inode execution metadata surviving the SELinux staging boundary.