The standard for how we build software¶
One consistent way to set up repositories, manage projects, and ship code across every internal and client project. Predictable, secure, and auditable by default.
Why these standards exist¶
Every repository, on every project, should look and behave the same way. Consistency is what lets us move quickly without losing control:
- Predictability - anyone can move between projects and immediately know how things work.
- Quality - shared rules for reviews, CI/CD, and security raise the floor on everything we ship.
- Onboarding - new engineers ramp against one documented way of working, not tribal knowledge.
- Client trust - external projects are set up consistently, with clear ownership and access control.
- Auditability - access, secrets, and releases follow rules that can be checked and proven.
Explore the standards¶
Onboarding Guide
Where new engineers and managers start. The first-change loop, end to end.
Repository Management
Templates, naming, teams, access - plus the project initialization checklist.
Branching
Our trunk-based model and branch naming conventions.
Pull Requests
How to open, describe, and merge changes into main.
Code Review
What authors and reviewers are responsible for, routed via CODEOWNERS.
CI/CD
Required pipelines, status checks, and production deployment gates.
Security
Baseline security requirements for every repository.
Secrets Management
How secrets are stored, rotated, and never committed.
Release Management
Versioning, tagging, release notes, and rollback.
The core rules¶
These apply to every project, internal or external:
- Every repository must use the approved template structure - apply it to new and existing repos with the integration command.
- Repositories are named by convention:
tenacious-<project>internally,<client>-<project>for client work. - Access is managed through GitHub Teams, never individuals - a client team for client work, the internal team otherwise.
- Every change follows the branch, PR, review, CI/CD, security, secrets, and release standards on this site.
A standard is a contract¶
If you find a standard that no longer fits how we work, that is a signal to update the standard, not to quietly ignore it. Open a pull request against this repository following the Pull Request Standard. Standards evolve through the same review process as our code.
New here?
Start with the Onboarding Guide, then read the Repository Management Standard before creating your first project.