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.

Tazel takes A.B.C, then .D, .E and -METADATA if needed, so the descriptor
check follows it.

Progmasoft's releases move to four numbers, and the plugins publish here.

Registration refuses the reserved names Progmasoft and Leitwolf, which are
meant to be created by trusted operations tooling only, and that tooling did
not exist: the Progmasoft account, the publisher of Progmasoft's Tazel
plugins on ViGet, could not be created at all.

- 'accounts provision-reserved <Name> <email>' runs with the configuration
  of the service, like the viget commands. It accepts only the reserved
  names, applies the rules of registration to the email address and the
  password, never replaces an existing account, and brings the account
  tables to the current schema first.
- The password is read from the terminal without echo, twice, or from one
  line of standard input when it is not a terminal; it never appears on a
  command line or in the output.
- AccountNamePolicy.TryNormalizeReserved checks a reserved name;
  TryNormalize, which registration uses, still refuses it.

Tests cover a reserved account created and signing in with its password,
a name that is not reserved, two different passwords, a weak password, an
existing account and the usage line. ops/README.md shows the command with
systemd-run --pty; docs/ACCOUNT-API.md points to it.

Nginx passes https://viget.progmasoft.com/dslplugins/tazel/<Publisher>/<Name>/index.json
to the API with the host of the request, and host filtering refused it with
400: viget.progmasoft.com was missing from AllowedHosts. The index is what
Tazel reads to download a plugin.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The documentation check of the backend found the private members of
ViGet/ without a summary and no page for its namespace:
- Summaries for every field and helper method of the catalog, the
  descriptor, the properties reader, publishing and the endpoints.
- docs/api/namespaces/Progmasoft.Progmaweb.Api.ViGet.md describes the
  namespace.
- The two regular expressions of TazelPluginDescriptor are excluded from the
  reference like AccountNamePolicy.CanonicalPattern: the generator replaces
  their comment with its own.

The dependency audit found GHSA for zod < 4.6.6, which can exhaust memory
while validating oversized constrained collections. Only
eslint-plugin-react-hooks reaches it, and it accepts any zod 4, so an
override takes 4.6.7 until the plugin resolves a fixed release itself.
pnpm audit --audit-level high finds nothing.

ViGet opens in stages: first only Progmasoft publishes Tazel plugins, later
every account. This adds the catalog and the server-side publishing for the
first stage; nothing publishes through the API yet.

- ViGet/: the catalog of Tazel plugins (in memory, or in PostgreSQL beside
  the accounts with its own numbered schema steps), the descriptor read from
  the JAR (META-INF/tazel-plugin.properties, with a reader of the Java
  properties format, and the ProjectPlugin service entry), and publishing:
  the publisher must be in ViGet:TazelPublishers (Progmasoft for now) and an
  existing account of that exact name, a version is never replaced, names
  that differ only in letter case are refused, and ViGet needs a
  description, an author and a license. The JAR is kept at
  dslplugins/tazel/<Publisher>/<Name>/<Version>/<Name>-<Version>.jar below
  ViGet:ArtifactRoot.
- Read endpoints under /api/v1/viget/dslplugins/tazel: the list, a plugin,
  and index.json, the index Tazel reads.
- 'viget publish-tazel-plugin <jar>' and 'viget yank-tazel-plugin' run with
  the configuration of the service instead of the service.
- The account store can find an account by name.

The pages, the Nginx routes and the deployment follow.

CodeQL flagged the withdraw endpoint: the authorization was looked up by
the identifier in the address and then checked against the account. The
endpoint now searches only the signed-in account's authorizations for that
identifier and revokes the tokens by the identifier it found, so another
account's allowance is never loaded. A test withdraws as another account
and gets 404.

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.

The documentation check of CI requires a comment on every API item and
a page for every namespace; 38 items of Progmasoft.OAuth had none. The
private handlers and helpers get summaries, MemoryOAuthDatabase its
field, and docs/api/namespaces describes Progmasoft.OAuth and its
Developers, Endpoints, Pages and Storage namespaces.

Verified: dotnet build in Release, dotnet docfx with warnings as
errors, and CheckDocumentation: all 353 API items are documented.