Xide is no longer developed as of 2026-11-08 (Progmasoft/xide#29), so
Progmaweb stops presenting it:

- product.progmasoft.com: Xide leaves the catalog, its card and its
  detail page; /xide on the product host is a 404 like any unknown
  product. The catalog's description in every language names the Tala
  language with its tools and Catch3.
- ides.progmasoft.com served only the IDE list and the Xide page, so the
  whole site goes: the pages under app/ides, its texts in every
  language, idesRoute and its host in the proxy, and both nginx server
  blocks. The certificate of progmasoft.com no longer has to name it.

Tests: the catalog lists the remaining products and refuses xide.

The review found four promises the policies made beyond what exists:

- ViGet takes no uploads from accounts yet; only Progmasoft publishes,
  through a server command. The Privacy Policy now says so, and that
  ViGet will record the IP address of each upload, for that one purpose
  and for the same time, once uploads open. ops/README.md tells the
  upload endpoint to do exactly that.
- A yank leaves a JAR served by nginx and cached by Cloudflare for a
  year. The Security Policy says a malicious version is taken off ViGet
  and kept out of reach as evidence; ops/README.md gives the four steps:
  yank, move the JAR into a root-only quarantine, purge the Cloudflare
  cache, close the account.
- The API cannot delete an account. ops/README.md gives the procedure
  support follows on a request from the account's address: a dump, then
  one transaction that removes the OpenIddict tokens and authorizations
  of the account, the applications it alone owns, and the account with
  its sessions and ownerships.
- Pages allow Cloudflare's analytics script besides their own, and the
  Security Policy now names it.

ops/README.md also records the nginx logs without client addresses on
both servers, which make the Privacy Policy's statement about web-server
logs true.

progmasoft.com/privacy and progmasoft.com/security publish the two
policies in en-US, de-DE, ru-RU and he-IL, and the footer links both.
The Privacy Policy says what an account keeps and that Progmasoft keeps
an IP address for one purpose only: with a ViGet upload, to establish
where an upload that turns out to be malicious software came from and
to give it to the competent authorities. It says that no data, the IP
address included, is sold, rented or traded. The Security Policy covers
passwords, sessions, HTTPS, the ban on malicious software in ViGet and
how to report a weakness.

The registration form asks the person to accept both policies, and the
API refuses a registration without that acceptance, with a password
(acceptPolicies, a validation error of that field) or through Google:
the start of a Google registration without acceptPolicies=true goes
back to /register?google=policies-required, and the completion creates
no account unless the authentication state carries the current version.
An account keeps the version it accepted and the moment, in two new
columns that schema step 2 adds; accounts created before it keep null.
PolicyAcceptance.CurrentVersion and policyVersion on the web side name
the same date, and a web test reads the C# constant to keep them equal.

The pages of progmasoft.com and its hosts had no content security
policy. The proxy now creates a 128-bit nonce for every request and sends
the policy both ways: on the request, so that Next marks its own inline
scripts with the nonce, and on the response. The layout reads the nonce
for the theme bootstrap. Every page is rendered on demand already, so
none is served with a stale nonce.

Scripts may come from the host, carry the nonce, or be Cloudflare's Web
Analytics beacon from static.cloudflareinsights.com, which reports to
cloudflareinsights.com. 'strict-dynamic' is left out, because browsers
ignore host sources under it and the beacon is added by Cloudflare
without a nonce. Styles allow inline ones; objects, framing and other
base URLs are refused. There is no form-action: sign-in and OAuth
consent end in redirects to other hosts, loopback addresses included,
and browsers apply form-action to them. The development server also
gets 'unsafe-eval' for its hot reload.

Tests check the nonce and each directive; ARCHITECTURE.md describes the
policy.

The API of the previous commit holds the catalog; this adds what people and
Tazel reach.

Pages:
- /dslplugins/tazel lists the published plugins, read from the API on its
  loopback address, and says when there is none.
- /dslplugins/tazel/<Publisher>/<Name> is the page of a plugin: its
  description, publisher, latest version, license, authors, homepage and
  repository, the plugins block that uses it, and every version with its
  date, plugin API, size, SHA-256, yanked mark and JAR.
- /dslplugins/gradle opens the Gradle catalog. It only lists: Gradle takes
  com.progmasoft.tazel.plugin from the Gradle Plugin Portal.
- The availability note says that Progmasoft publishes first and every
  account later. Texts are in the four languages of the site.

Nginx (ops/nginx/progmaweb.conf):
- On viget.progmasoft.com, index.json of a plugin goes to the API and the
  JARs come from /srv/viget/files with immutable caching; /api/ stays
  closed.
- maven.progmasoft.com serves /srv/maven, whose /tazel holds tazel-api.

ops/README.md describes the directories, their SELinux labels, the publish
and yank commands, and how a release of Tazel copies the API into the Maven
repository.

Tests cover the texts in every language, the plugins block, the Gradle list,
and that a page asks the API only for identifiers.

progmasoft.com presents Progmasoft as a pool of technology areas instead
of a list of products: languages and compilers, build and packages,
developer tools, quality and testing, identity and access, and
infrastructure. The page has a new hero, a bento of areas, principles and
a developers band that leads to the Progmasoft Console; the products are
one link away in their own catalog.

product.progmasoft.com lists Tala, talac, talafmt, talalint, Tazel, Xide
and Catch3, each with its own page (/tala-lang, /talac, ...) that leads
to the product's site and source. ides.progmasoft.com lists the IDEs and
hosts the Xide site at /xide; catch3.progmasoft.com is the Catch3 site.
The facts follow the READMEs and documentation of the product
repositories: Xide is marked as early work, and Catch3 states that it is
not an official Catch2 release.

The theme switch no longer freezes or flickers. The layout rendered
data-theme="light" on <html>, so every server re-render of the layout
(a language switch) set it back. The control also applied the theme in
an effect after the render while buttons animated their colours. The
attribute now belongs to the bootstrap script and the control alone; the
control applies the theme in the click, and transitions are off for the
two frames of the change.

All new text is in en-US, de-DE, ru-RU and he-IL. The old home messages
leave localization.ts. The proxy maps the new hosts through one table, and
nginx gains their virtual hosts.

Progmasoft OAuth now runs on three hosts:

- credentials.progmasoft.com stays the issuer: discovery documents, key
  set, token, user information, revocation and introspection.
- authorize.progmasoft.com serves the pages people see: the
  authorization and end session endpoints (registered with OpenIddict as
  absolute URIs on that host), sign-in, the consent screen and the
  applications an account has allowed.
- console.progmasoft.com is the Progmasoft Console. Its overview links
  the areas; OAuth 2.1 tokens live under /credentials, with New token,
  then the application type, then its form.

The console has no sign-in of its own and never redirects. It uses the
Progmasoft account session, so production now shares that cookie with
progmasoft.com (__Secure-ProgmasoftSession, Domain=progmasoft.com,
HttpOnly, Secure, SameSite=Lax). Without AccountSessions:CookieDomain the
cookie stays host-only with the __Host- name, as in development and tests.

Application types replace the confidential/public switch: web,
single-page, desktop, mobile and service. Each type has its redirection
rules (RFC 8252), its secret or none, and its grants; only a service
uses client credentials and it registers no address or scope. The type is
kept as an application property and cannot change.

The HTML pages of the API are gone. The pages are Next.js pages in four
languages (en-US, de-DE, ru-RU, he-IL) that call JSON endpoints under
/api/v1/oauth. Requests that change state must come from the page's own
origin; antiforgery forms are no longer needed. The token, revocation and
user information endpoints answer CORS requests from the origins of
single-page applications, without credentials; the discovery documents
and the key set answer every origin.

The host filter keeps every path on its host. Nginx gains the authorize
and console virtual hosts, and the docs describe the hosts, the types and
the shared session.

viget.progmasoft.com now shows, from the top:

1. The state of the registry: what it holds today, the package format,
   the publisher identity and that publishing is not open yet.
2. LANGUAGES: Tala links to viget.progmasoft.com/langs/tala; C++ is a
   gray, disabled button that leads nowhere.
3. BUILD SYSTEM DSL PLUGINS: Tazel links to
   viget.progmasoft.com/dslplugins/tazel; Gradle is a gray, disabled
   button that leads nowhere.

/langs/tala is the catalog of Tala packages and /dslplugins/tazel the
catalog of Kotlin DSL plugins for Tazel, both honestly empty. /langs and
/dslplugins redirect to them. The header, the footer and the sitemap
link the two catalogs, and the coordinates they show begin with the
catalog: /langs/tala/<Publisher>/<Name>/ and
/dslplugins/tazel/<Publisher>/<Name>/.

The text of the catalogs lives in lib/viget-catalogs.ts in all four
locales; localization.ts is close to the size limit of a file. The
two section headings are the registry's names and stay in English.

The language links of the ViGet and Progmasoft pages point at tala.run.

Hebrew (he-IL) joins English, German and Russian with a complete message
tree and its own entry in the language menu.

A visitor who has not chosen a language now gets the language their browser
prefers. The Accept-Language header is negotiated by quality, only the
primary language is compared, and `iw` is accepted as the former code for
Hebrew. A browser that prefers no published language gets en-US, as before.
A language chosen in the menu is still stored in the cookie and always wins.

Hebrew does not mirror the page. The layout, the navigation and code keep
their left-to-right arrangement; only text follows the language. Blocks of
prose run right to left, short pieces such as links and buttons take the
direction of their own first letter, and inputs and code stay left to right.
The onward arrow points left in Hebrew, and a left-to-right mark keeps
"Visual X#" intact inside right-to-left text.

The Hebrew text was not reviewed by a native speaker.

Verified locally: node tests, type check, lint, prettier and a production
build; language selection per Accept-Language header against the dev server;
the Hebrew home and registration pages in a browser.

The language control no longer reloads the page. It calls a server action
that stores the preference cookie; Next.js then renders the current route
again and applies it in place, so scroll position, theme and client state
stay. The lang query parameter remains for links and for browsers without
script, and is the fallback when the action cannot reach the server. Both
paths write the cookie with the same attributes from one function.

The toggle button is now a language menu, a native select that lists each
language by its own name, and Russian (ru-RU) is the third locale with a
complete translation of every message.

Tests require every locale to have exactly the message shape of the default
locale with no empty text, and cover the cookie attributes and host
normalization. Verified locally: prettier, eslint, type check, tests, the
production build, and a browser run on the apex and ViGet hosts where the
language changed with no navigation and the scroll position kept.