app

A public git repository on GitHub: https://github.com/altnovatrail/app

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Every pull request, its branch and its commits are public before they reach main and a release.

Repository on GitHub, which uses git. git is distributed.

Every release has a unique version vX.Y.Z, tagged on its commit. The release workflow numbers it, and nobody tags by hand; releases are immutable, and a ruleset forbids moving or deleting a tag v*. https://github.com/altnovatrail/app/blob/main/.github/workflows/release.yml

Versions are MAJOR.MINOR.PATCH: each release is the next patch of the current line, 0.1 since the first release, v0.1.0, and a change that breaks those who host it starts a new line.

Each release is the git tag vX.Y.Z, which the release workflow creates together with the release.

A release follows every merge to main that changes what the build is made from, and its notes on GitHub list the pull requests it brings, linked to each pull request's description: an English summary of what changed and why. https://github.com/altnovatrail/app/releases

No publicly known vulnerability of app has been fixed in any release. If one is, its release notes will name it and link its GitHub security advisory.

Bugs are reported as GitHub issues, through the bug report form that GitHub shows for every repository of the organization: it asks what happened, what was expected, how to reproduce it on synthetic data and in which commit, release or tag. https://github.com/altnovatrail/app/issues/new/choose

GitHub issues track individual reports. The project's own planned work is in its work plan, RUN.md.

No bug report has been submitted yet; the maintainer answers each report in its issue.

No enhancement request has been submitted yet; the maintainer answers each request in its issue.

GitHub issues are public, permanent and searchable: https://github.com/altnovatrail/app/issues?q=is%3Aissue

The security policy, which every repository of the organization shares, says how to report a vulnerability: privately, through GitHub's private vulnerability reporting. https://github.com/altnovatrail/app/security/policy

Private vulnerability reporting is enabled: a report goes over HTTPS to the maintainers and opens a draft advisory that only they and the reporter see. https://github.com/altnovatrail/app/security/advisories/new

No vulnerability has been reported in the last six months.

just build builds the app with Vite into build/, and just release-files <version> builds a release's file: the archive of the build, packed by the repository's own code in one order with no time or owner, so that the same tree gives the same bytes on any machine, which CI checks by building the tree twice. The release builds it in the toolchain stage of .devcontainer/Dockerfile, from a base image pinned by digest and tools pinned by version and SHA-256, and the packages are those package-lock.json pins. https://github.com/altnovatrail/app/blob/main/justfile

npm installs the packages from the lock file, Vite builds the app, the TypeScript compiler checks its types, Vitest runs the tests, Docker builds the environment, and just runs every recipe.

All FLOSS: Node.js (MIT), npm (Artistic-2.0), Vite and esbuild (MIT), TypeScript (Apache-2.0), Biome (MIT), Vitest (MIT), Playwright (Apache-2.0), Docker Engine (Apache-2.0), just (CC0-1.0), and cosign (Apache-2.0), which signs the release's file.

An automated test suite in this repository, under Apache-2.0, run by Vitest in Node and in Chromium: 700 tests on 2026-11-12, among them the tests of every screen in the browser with axe-core, the tests of the built page under its Content-Security-Policy header, and the check of the release's archive. just ci-test runs them all; the README says so, and CI runs them on every pull request and on main: https://github.com/altnovatrail/app/blob/main/.github/workflows/ci.yml

just ci-test runs every test with vitest run, the standard way for Vitest; the README names it.

On 2026-11-12 the tests covered 95.25% of the lines of the code on main (7fbe939), as Codecov counts them: https://app.codecov.io/gh/altnovatrail/app

GitHub Actions runs every check and every test on each pull request and on each commit to main, and main takes a pull request only when they pass.

RULES.md, the rules every NovaTrail repository shares: code comes with its tests, so a pull request that adds or changes what code does adds or changes the tests of its automated suite. A pull request merges only when at least 90% of its changed lines are covered (codecov/patch, a required check). https://github.com/altnovatrail/spec/blob/v0.15.1/RULES.md

The latest major changes came with their tests: the archive of a release and its check (https://github.com/altnovatrail/app/pull/36); going to the lesson or the task the engine chose (#35); the lesson player (#34).

The rule on tests is in RULES.md, which the organization's CONTRIBUTING.md names as the rules every contribution follows, and the pull request template that GitHub shows for every repository of the organization asks for it: code comes with its tests. https://github.com/altnovatrail/.github/blob/main/.github/pull_request_template.md

Biome, with its recommended rules, and the TypeScript compiler in strict mode check the code on every pull request, as just ci-lint runs them in the required check TypeScript / lint, and the scripts of the recipes run with set -euo pipefail. SonarCloud analyses the code on every pull request, and its quality gate is a required check. https://sonarcloud.io/summary/new_code?id=altnovatrail_app

A finding of SonarCloud or CodeQL is fixed in code before the next task starts; marking one false is a last resort, with the reason written down. SonarCloud's current findings are public: https://sonarcloud.io/project/issues?id=altnovatrail_app

SonarCloud's quality gate holds a merge on any new finding, and the answer to a finding is a change to the code: the two it raised on the release workflow and its archive — a condition on the actor of a run, which anyone who reruns it becomes, and a sort without a comparison — were fixed in their pull request (#36).

The maintainer designs for least privilege, fail-safe defaults and a small attack surface. app gets only a task's open view, never its key, solution or traps while it is unsolved, and decides no verdict: its server does. It talks to its own api and the sign-in service alone, and loads nothing at run time beyond its signed build: a Content-Security-Policy with no inline script, no eval, no frame of it anywhere and a short list of addresses holds that, both as a meta element of the page and as the host's header. The learner's strokes stay on the device, and a check sends only an image of the work. Text from the server is rendered as React elements, never as HTML. Every workflow starts with a read-only token, a job gets only the write it needs, the workflows hold no secret, and main has no bypass. The decisions behind these, in Russian, are in https://github.com/altnovatrail/app/blob/main/docs/decisions.md

For this kind of software, a web app for children under an adult's account, the maintainer counters: cross-site scripting (React escapes text, no HTML string reaches the page, the legal texts' Markdown becomes elements with its HTML, links and images shown as text, and the Content-Security-Policy allows no inline script); clickjacking (frame-ancestors 'none'); path traversal in the addresses of a package's files (a path that would leave its folder is refused); data left on a shared device (after every sign-in the device erases what belongs to no account it holds, and a sign-out names what will go and erases all of that account); open redirects and tracking (no external links, ads or third-party scripts beyond the sign-in service); and supply-chain tampering (exact versions, the lock file's integrity, the signatures of NovaTrail's own packages checked against their releases, actions pinned by commit, downloads checked against pinned SHA-256 sums).

app implements no cryptography. It relies on the browser's TLS for every connection, on SHA-256 (FIPS 180-4) for the sum of the release's archive and SHA-512 for the integrity of the packages in the lock file, and on cosign, keyless, through Sigstore, whose certificates and signatures are ECDSA (FIPS 186-5), for the signature of the release and of NovaTrail's packages it is built from.

It calls the browser's crypto.randomUUID for the idempotency keys of the learner's actions and Node's crypto for the sum of the archive; npm checks the integrity of the packages, and the shared release workflow calls cosign to sign the release's file. It never implements cryptography itself.

Node.js (MIT), npm (Artistic-2.0) and cosign (Apache-2.0) are FLOSS, and app runs in FLOSS browsers, such as Chromium and Firefox, whose TLS and Web Crypto are FLOSS too.

app has no cryptographic keys of its own; the sign-in service's tokens are signed by Google and checked by api.

No broken algorithm is used: SHA-256 and SHA-512 only, and TLS as the browser negotiates it.

No algorithm with known serious weaknesses is used: SHA-256 and SHA-512 only, never SHA-1 or MD5.

app implements no key agreement: its connections are the browser's HTTPS.

app stores no passwords: the adult signs in with Google through Firebase Auth, and app keeps no credential of its own.

app generates no cryptographic keys or nonces. Its idempotency keys come from the browser's crypto.randomUUID, a cryptographically secure generator, though they are no secret.

app is delivered over HTTPS only: the repository, its releases and their files. Releases are immutable, GitHub attests each one with its file, and the archive is signed with cosign, its bundle beside it in the release. spec's just release-verify checks the archive against its bundle and Sigstore's trust root and against everything the certificate names: who signed, at whose call, on which branch and of which commit; infra's rollout serves a build only once that check has accepted it.

No hash is retrieved over HTTP: every SHA-256 sum is pinned in the file next to its version, the lock file pins each package's integrity, and every download of the devcontainer is restricted to HTTPS, redirects included (curl --proto =https --proto-redir =https).

No vulnerability is open: Dependabot has raised no alert, and npm audit of what ships finds none at high severity or above.

Dependabot security updates are on, npm audit of what ships is a required check (TypeScript / vuln), and a finding of Scorecard, CodeQL or SonarCloud is fixed before the next task starts.

gitleaks scans the whole history on every pull request and on main, and GitHub's secret scanning and push protection are on. The workflows hold no secret: coverage goes to Codecov with a short-lived OIDC token. The deployment configuration of a local run stays on the developer's machine, out of git.

CodeQL, with the security-extended queries, analyses the TypeScript of the app and every workflow, and SonarCloud analyses the repository, on every pull request and on main. Both are required checks, CodeQL for each of its languages, and a release comes only after CI passes on main.

CodeQL's security-extended queries and SonarCloud's security rules look for common vulnerabilities, such as cross-site scripting and injection, and npm audit for the known vulnerabilities of the packages that ship (TypeScript / vuln, a required check).

The ruleset of main holds a merge on any CodeQL alert at error level or of high severity and above, and on SonarCloud's quality gate; every finding is fixed before the next task starts.

On every pull request and on every commit to main.

The automated test suite runs on every pull request and on main, the screens and the built page in a real browser, Chromium: the built page under its Content-Security-Policy header, where a violation fails the test, and every screen under axe-core. On 2026-11-12 it covered 94.25% of the branches, as V8 counts them, above the 80% that the criterion counts as dynamic analysis.

app is TypeScript, a memory-safe language, and has no code in a memory-unsafe one.

The code checks what it reads — the deployment configuration against its schema, the server's answers by the contract — and throws or shows a named failure, always on; the tests assert with Vitest's expect.

A failing test fails a required check, and the pull request cannot merge until it passes. No vulnerability has been found this way.