Changelog

Repository metadata is a new page. It sets catalog-info.yaml at the repository root as the file that holds ownership, hosting, and release data. ADR-0008 records the decision. Its status is proposed.

• Choose each field in this order: Backstage, DevHub, then a new key.
• Add a new key only when Backstage and DevHub have no field for the value. New keys go in spec.kraken.
• The page defines two keys: hosting and release. Each key has a list of allowed values.
• A team proposes a new key in an issue. An Engineering Navigator approves it in the pull request that adds it to the page.
• The link to the repository documents goes in metadata.links. It does not go in an annotation.
• spec.owner names the first owner of the CODEOWNERS rule that matches catalog-info.yaml.
• A production service names its PagerDuty service in pagerduty.com/service-id. The escalation policy of that service names who gets paged.
• Environment URLs, the runbook, and the Slack channel go in metadata.links. Each link has a type from a fixed list: repository, documentation, production, staging, development, runbook, or slack.
• In Claude Code, the /engineering-standards:filling-catalog-info skill writes the file. The page gives the equivalent prompt for Codex, Cursor, and OpenCode.
• The release values are a proposal. After reviewers accept the ADR, each repository that uses the ninjatrader.com/* annotations moves them to spec.kraken.

This page resolves part of issue #26, including the on-call team and the environment URLs. Criticality and data classification stay open.

Four-eyes answers three questions for engineers creating a repository.

• A repository with a production environment, a production deploy pipeline, or access to production data is production from its first commit, launched or not.
• A repository that is never used in production requests a four-eyes exemption through one ticket, with manager and director approval and an attestation.
• A decision table sends each repository to review or to the exemption route. When unsure, treat the repository as production and ask an Engineering Navigator.

When it doesn’t fit separates exemptions from exception ADRs. References lists the Payward policy behind the attestation.

Consult the standards shows how to set up AGENTS.md so coding agents read these standards before they act on anything the standards cover.

• A copy-pasteable AGENTS.md section points agents at /llms.txt as the source of truth and lists the work that needs a read first.
• CLAUDE.md stays a single import of AGENTS.md.
• The site sits behind Cloudflare Access, so engineers run cloudflared access login once, and the snippet tells an agent how to recover from a 302 redirect.
• The engineer-standards skill in NT-NinjaTrader/skills adds /standards-ask and /standards-check.

Team standards keeps uv as the Python build and dependency manager and now records where FCM stands.

• FCM uses pip with pyproject.toml and == pins, and does not commit a lockfile.
• FCM plans to adopt uv.

Design docs, RFCs & ADRs now holds everything from the Confluence RFCs and ADRs page, so there is one place to check.

• A table shows when to open a pull request only, write an ADR, write an RFC, or write a design document.
• The page defines “architecturally significant” and explains why the ADR bar is lower than the RFC bar.
• RFCs have a status lifecycle, and an RFC needs a risks section alongside its alternatives.
• An ADR must name its trade-offs, and links its RFC instead of copying the alternatives.
• The page carries the only ADR and RFC templates. Repositories copy them into docs/adr/ and docs/rfc/, and Confluence pages paste the same Markdown.
• RFCs and ADRs with no owning repository go under RFCs and ADRs in Confluence.
• ADR statuses are lowercase, matching the template’s frontmatter.
• Design documents use the [TEMPLATE] Technical Design Document - TDD.
• Older Confluence templates, including the previous design document template, are listed as superseded.

The Confluence page now links here.

Team standards now sets Python 3.14+ as the baseline for Non-trading / FCM, up from 3.12+.

• New Python work targets 3.14, the latest stable CPython release.
• FCM runs on Python 3.11 and plans to migrate to 3.14.

Cross-platform repositories is a new page. Our engineers work on Windows, macOS, and Linux, and a repository should work for all of them.

• Windows engineers develop natively by default, and repositories aim to build, test, and run on Windows and Unix. The repository’s README lists the systems it supports.
• For a hard dependency that does not support Windows, a Windows engineer uses WSL2. The repository says so in its README, and the clone lives under /home/<user>/, not /mnt/c/. ADR-0007 records the decision.
• Repositories avoid filenames Windows cannot check out. That covers reserved device names such as aux and nul, the characters < > : " \ | ? *, names that end in a space or a period, and paths that differ only by case. A single bad name makes git clone fail on Windows, so the filename guidance always applies.
• Repositories commit a .gitattributes file that fixes line endings, set the executable bit through Git, and avoid symlinks.
• Scripts stay portable. In package.json, use cross-env for environment variables and rimraf for deletes, quote arguments with escaped double quotes, and move anything longer into a Node script. A single-quoted glob matches no files under cmd.exe, so a lint step passes having checked nothing.
• Enforcement is a reminder, not a gate. An optional shared action, check-portable-paths in NT-NinjaTrader/gh-actions, flags a bad path early and does not block a merge. The page shows how to call it. The action is in review and has no release tag yet.
• The page also covers how to rename a bad path from a machine that can hold it.

Team standards links to the page from its platform-wide table.

Team standards now names a stack for web backends, the non-trading HTTP services behind our clients and partner integrations.

• Web backends run NestJS on Fastify, with @nestjs/swagger generating the OpenAPI document that architecture requires.
• Data access uses Prisma against PostgreSQL on Cloud SQL, at the latest version Cloud SQL supports.
• Services deploy to GKE with Kustomize and Flux.
• A product client and its backend ship from one repository under pnpm workspaces, as apps/api, apps/web, and apps/worker, with kustomize/ and cloudflare/ beside them. Each app deploys on its own and carries its own CODEOWNERS entry.
• Express needs an exception.

The stack records what the services already run, drawn from market-info-api, trader-dashboard-api, preference-api, remote-storage-api, user-context-api, and nt-follow. Repository manifests and lockfiles set exact versions.

FCM clearing and back-office services stay on Python. This page states the default for new work; an existing service that differs is not, by itself, a reason to migrate.

Design system is a new page for Strata, NinjaTrader’s design system.

• It lists the Strata component package and the Strata MCP for coding agents.
• It sets the rules for building UI: use Strata components, style with tokens by name, and do not restyle a component at the call site.
• It asks repositories that build UI with Strata to add the recommended config from @nt-ninjatrader/eslint-plugin-strata.
• It asks repositories that build UI with Strata to add Drift for visual regression checks.
• It routes requests and contributions through #ask-strata-nt and the Strata contributing guide.

Internationalisation now lists slang as the Flutter tooling, with .i18n.yaml catalogues.

• Slang supports ICU-style concepts such as pluralisation and interpolation. The mobile app’s catalogues use slang’s syntax rather than ICU MessageFormat syntax.
• A new Flutter section shows the .arb example in slang YAML, lists slang’s modifiers, and sets key-naming rules.
• The page summarises what the mobile setup provides: compile-time key safety, a single source catalogue, and CI checks for stale, unused, and missing translations.

Team standards groups the guidance into Backend, Web, Mobile, and Desktop.

• Backend separates trading-path Scala services from non-trading services, including FCM Python and TypeScript web services.
• Desktop covers Forge’s Electron and React shell, .NET 10 engine, Rust shared-memory addon, and platform packaging targets alongside NinjaTrader 8.
• Version and dependency guidance records Forge’s current toolchain, including its npm setup.
• JVM builds use JDK 21 only. Other version floors use + notation, and Node support links to the upstream release schedule.
• Deployment guidance identifies Argo CD as a NinjaTrader proof of concept already widely used at Kraken/Payward.

Forge details come from the repository manifests at commit 5ea546e. This update documents the implementation and does not select a new language for non-trading backends.

Feature flagging moves to Statsig, integrated through the native Statsig SDKs on each platform. No abstraction layer sits in between, and the earlier OpenFeature approach is superseded. A repository uses one provider at a time. New work starts on Statsig. A repository still on LaunchDarkly or OpenFeature migrates through a planned project that removes the old provider.

See Feature flags for the standard, and ADR-0005 for the decision and its alternatives.

The NinjaTrader engineering standards are now published as this docs site. The standards that describe how we build and ship software are in one place, versioned in the repository, and open for contributions.