With an empty Google client identifier or secret the API answered every request with 500, including registration, password sign-in and the status route. The Google scheme was always registered, and the authentication middleware initializes every remote scheme for each request; with empty credentials the validation of the Google options threw there, before any endpoint ran. The API could not be started locally without credentials, and the "Google sign-in is unavailable" answer of the start endpoint was never reached. The Google scheme is now registered only when both values are configured. Without it the service runs normally, the start endpoint answers 503, the completion endpoint redirects to the failed sign-in page without a session, and the callback path is not a route. With both values nothing changes. The test factory passes the two values as host settings. The program makes the decision while it registers services, and configuration sources a test factory adds are applied only when the host is built, after that point. New tests run the service without a Google client: the ordinary routes, a full register, sign-out and sign-in round trip, and the three Google paths. They failed with 500 against the previous program and pass now, also when the environment of the test run carries Google credentials. The guides no longer list this as a limitation or ask for placeholder credentials. Deploying this change restarts the API, which deletes every account while the store is in memory.
The DocFX gate only failed on a broken link or an unresolved reference. DocFX does not report a declaration without a comment, and the API had none, so the gate passed over a reference with no descriptions at all. The gate now has three parts: - DocFX still builds the reference with warnings as errors. - The API project compiles its XML documentation. With warnings as errors already on, an undocumented public declaration or a wrong cref now fails the build. - docs/api/CheckDocumentation.cs reads the metadata DocFX generated and fails when a namespace, type or member has no summary. This covers internal and private members, which the compiler does not check. It runs as a file-based .NET program, so the gate needs no tool beyond the SDK. It refuses to pass when the metadata is missing or defines nothing. To satisfy the gate, every declaration of apps/api has documentation comments, 131 reference items in all, and the two namespaces are described by overwrite files in docs/api/namespaces. Only comment lines were added to the C# sources; no statement changed. docs/api/filterConfig.yml leaves generator-written code out of the reference: the generated regular-expression namespace, and the one partial method whose generated half replaces the comment of its declaration. Verified locally: the solution builds with no warnings, the 23 API tests pass, DocFX builds with no warnings and the coverage check passes. Removing one summary and one namespace file made the check fail and name both.
- Google-Extended, Google's token for model training, is now allowed. - GPTBot, OpenAI's training crawler, is now disallowed. OAI-SearchBot and ChatGPT-User, which index and fetch pages for answers, stay allowed. - ClaudeBot, Anthropic's training crawler, is now allowed, next to Claude-SearchBot and Claude-User, which already were. Every other rule is unchanged.
A second pass over the Hebrew text replaced words a Hebrew reader would misread or that are not used for the concept: - "native" was rendered with the word for "local"; it is now machine code for output and the Latin term for the native parts of the toolchain. - Typed boundaries, the ecosystem, the dedicated account area and the first-party infrastructure use the usual terms instead of literal ones. - The greetings and the new-visitor prompt no longer address one gender. The text is still not reviewed by a native speaker.
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 dependency audit reports a critical Next.js advisory for releases before 16.3.6 (remote code execution in next/og ImageResponse) and high-severity denial-of-service advisories for brace-expansion before 5.0.12. The site does not import next/og, but production runs the affected Next.js release. - next and eslint-config-next: 16.3.3 to 16.3.8. - brace-expansion: the lockfile resolves 1.1.21 within its range; the 5.x line, which minimatch pins to 5.0.9, is overridden to 5.0.12 in the workspace until minimatch depends on a fixed release. pnpm audit reports no known vulnerabilities. Prettier, eslint, the type check, the tests and the production build pass.
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.