engineering
how the product gets built — standards, processes, the work of shipping
Holds how the product gets built: the coding standards a change can be blocked over and the runbook a release follows. Take it if you ship software; the dev, fixer, qa and reviewer roles work from it.
structure generate department engineeringEngineering — Mission
how the product gets built — standards, processes, the work of shipping.
Purpose. One paragraph: what engineering is accountable for beyond writing code — the thing that would be broken if this department stopped. Say who it builds for, and what it refuses to trade for speed.
How work gets done here. Steering docs live at this root — the standards a change is held to,
and the runbook a release follows. Repeatable how-tos in processes/; accumulating collections in
records/.
---
type: mission
standing: draft
owner: "{{owner}}"
updated: "{{date}}"
---
# Engineering — Mission
_how the product gets built — standards, processes, the work of shipping._
**Purpose.** _One paragraph: what engineering is accountable for beyond writing code — the thing
that would be broken if this department stopped. Say who it builds for, and what it refuses to trade
for speed._
**How work gets done here.** Steering docs live at this root — the standards a change is held to,
and the runbook a release follows. Repeatable how-tos in `processes/`; accumulating collections in
`records/`.
type: department
name: engineering
description: "how the product gets built — standards, processes, the work of shipping"
about: "Holds how the product gets built: the coding standards a change can be blocked over and the runbook a release follows. Take it if you ship software; the dev, fixer, qa and reviewer roles work from it."
version: "0.1.0"
Also in the folder
Coding Standardsdepartments/engineering/coding-standards.md
Coding Standards
The rules a reviewer can point at. Write only what you would actually block a change over — a standard nobody enforces teaches everyone that standards here are decoration.
The stack, and what we don't reach for. Languages, frameworks, the database, and the things deliberately left out with the reason. "No ORM — the queries are the interesting part" is a standard; "we use TypeScript" is a fact.
What a change has to clear before it lands. Tests, types, lint, review, in order. Say which of these may be skipped when something is on fire, and who is allowed to skip them.
How we name and shape things. Only the conventions that have caused the same argument twice. Everything else is style, and style belongs to the formatter.
Where each rule is enforced. CI, a hook, or a person. A rule with no enforcer is a preference — say so, or arm it.
Release Runbookdepartments/engineering/release-runbook.md
Release Runbook
How a release is cut, written for the person who did not build the thing. The test of this document is that it works at six on a Friday: no step that says "as usual", nothing that lives only in somebody's shell history.
The ruled path. The commands, in order, from a clean tree to a published artifact — one per line, copyable. If a step is ever run by hand "just this once", either write it down as a step or remove the possibility.
What has to be green first. The gates, and what each one proves. Include at least one that runs against the built artifact rather than the source tree; that is the class of defect a test suite cannot see.
When it goes wrong. How you find out, how to roll back, and who decides to. Name a person, not a team.
Who may cut a release, and who they tell. The announcement, where it goes, and what it has to say — version, what changed, what to do if it broke something.