Standards

How we build software at Newfold Labs. Standards are filed by how wide their blast radius is, and every document carries a stable id that checks and AI answers cite, so a failure points at the exact standard behind it.

This index and the navigation are generated from document metadata. Nothing on this page is hand-maintained. Open the atlas Browse all 44 standards a folder at a time, and see what links to what. Open the scorecard See where all 125 repositories sit against these standards, and which checks each one can run.

General

Standards that hold regardless of platform or artifact type.

Introduction
Who we are, why these standards exist, and how they are organised
Philosophy
How we approach software engineering, and the values behind the rules
Naming
General naming principles that apply before any language or platform convention
Naming projects
The platform-type-name convention for repositories, Composer packages and npm packages
Naming files and directories
Directory and filename conventions, and where they bend to a framework's expectations
Naming code
How to name variables, keys and identifiers so related names group and grow predictably
Naming in global namespaces
Defensive prefixing for names that land in a namespace we do not control
Frontend best practices
Markup, runtime and payload expectations for anything a visitor's browser loads
Git and branching
GitFlow, branch naming, and what CI runs at each stage
Releases and versioning
Release cadence, semantic versioning, and the tags each branch type may carry
Testing
The kinds of tests we write, who writes them, and what a good assertion looks like

Platform

Standards for a specific technology, applying across everything we build on it.

WordPress

WordPress support matrix
The WordPress, PHP and browser versions our products must work on
WordPress PHP
PHPCS setup, namespacing, bootstrapping and the defensive habits we expect in PHP
WordPress JavaScript
How JavaScript in WordPress differs from a standard build, and how to work with it
WordPress security
Authentication, nonces, escaping, sanitization and safe database access
WordPress assets
Registering and enqueuing scripts and styles so other codebases can override them
WordPress hooks
When to add custom actions and filters, and how to pick arguments and priorities
Hook naming
The newfold/context/type/name convention for custom action and filter hooks
WordPress interfaces
Building admin UI that coexists with core, other plugins and every color scheme
WordPress performance
Query, option, cron and caching habits that matter at our install count
Internationalization
Making every user-facing string translatable, and the files that carry the translations
WP-CLI
Running WP-CLI commands safely against installations we do not own
Tools and services
Recommended development plugins and local environments, none of them required

Artifacts

Standards for a specific kind of thing we ship.

Plugins

Plugin structure
How a brand plugin is laid out, and why distribution files decide the layout

Themes

Theme structure
Placeholder for theme standards, which have never been written down

Modules

Module structure
The directory layout every module shares, and what ends up in the distributed zip
Module development
What module owners are responsible for, and the flow from feature branch to plugin PR
Module testing
Playwright conventions that let a module's tests run from any brand plugin

Workers

Cloudflare Workers
KV, Workers AI and the Vitest setup we use for edge workers

Process

How we work together. Judgement and coordination, not lintable rules.

Code review and release restrictions
Who reviews what, who is allowed to release, and the bar a PR must clear to merge
Release runbook
The step by step a release lead follows, from Jira planning to posting in Teams
Architectural review
What an architectural review covers and what to prepare before requesting one
Organization teams
How repository access is granted through GitHub teams rather than individuals
Token management
Setting up a personal access token for private packages, and why runners never get one from the repo
Crowdin translation workflow
Uploading source strings to Crowdin and getting translations back as a pull request
AI translation workflow
Automating po and json translation through Azure AI Translator and a central workflow

By artifact type

Tagging every document with applies_to is what makes it possible to pull just the standards binding one kind of repository. Documents marked any apply to all of them and are listed under each.