Glossary

Common terms and abbreviations used in the Engineering Playbook.

Playbook-Specific Terms

Atomic Commit

A single commit that addresses one logical change and is always deployable. See /pb-commit.

Code Review Cycle

The process of developing code, reviewing it (self and peer), and getting approval before committing. See /pb-cycle.

Decision Framework

The Engineering Playbook itself-a set of structured processes for making engineering decisions.

Integration Guide

Documentation showing how all commands work together. See /docs/integration-guide.md.

Quality Gate

A checkpoint that must pass before code moves forward. Examples: linting, testing, security review.

Self-Review

Review by the code author before requesting peer review. Catches obvious issues and respects reviewers’ time.

Peer Review

Review by another engineer (usually senior) checking architecture, correctness, security, and maintainability.

Development Process Terms

Branch

A copy of the codebase where you work on a feature without affecting main code. See /pb-start.

Commit

A logical unit of work saved to git with a message explaining what changed and why. See /pb-commit.

Pull Request (PR)

A formal request to merge your branch into main. Includes code, description, and rationale. See /pb-pr.

Feature

A new capability or user-facing improvement.

Hotfix

An emergency fix for production issues, using expedited process. See /pb-incident.

Refactor

Code change that doesn’t change behavior, just improves structure/readability.

Release

Publishing code to production. Includes pre-release checks and deployment. See /pb-release.

Rollback

Reverting to previous code version if release breaks something.

Architecture & Design Terms

ADR

Architecture Decision Record. Documents major decisions with context, options, and rationale. See /pb-adr.

Pattern

A proven solution to a recurring design problem. See /pb-patterns-*.

Microservice

A small, independent service focused on one business capability.

SOA

Service-Oriented Architecture. Breaking system into independent services.

Event-Driven

Architecture where components communicate via events rather than direct calls.

CQRS

Command Query Responsibility Segregation. Separating read and write models.

Saga

Pattern for distributed transactions across multiple services.

Circuit Breaker

Pattern for preventing cascading failures by stopping requests to failing services.

Retry

Pattern for automatically retrying failed operations with backoff.

Code Quality Terms

Linting

Automatic code style checking. Catches style violations and common mistakes.

Type Checking

Verifying code types match (especially in typed languages like TypeScript, Go).

Test Coverage

Percentage of code executed by tests. Target: 70%+ for critical paths.

Edge Case

Unusual or boundary condition that code must handle correctly.

Flaky Test

Test that sometimes passes and sometimes fails (usually due to timing or randomness).

Technical Debt

Code shortcuts taken for speed that require later rework. Accumulates if not managed.

Security Terms

Authentication

Verifying who the user is (login). See /pb-security.

Authorization

Checking if authenticated user has permission for an action.

Injection Attack

Attack where attacker inserts code through input fields (SQL injection, command injection).

Rate Limiting

Restricting requests from single user/IP to prevent abuse.

Secret

Sensitive data like passwords, tokens, API keys. Must never be in code.

Input Validation

Checking user input is valid before processing.

Operations Terms

CI/CD

Continuous Integration / Continuous Deployment. Automated build, test, and deployment.

Observability

System’s ability to be understood from outside. Includes logging, metrics, tracing.

Monitoring

Continuous observation of system health and performance.

Alerting

Automatic notifications when metrics exceed thresholds.

Runbook

Step-by-step guide for handling operational issues.

SLA

Service Level Agreement. Commitment to availability/performance.

P0/P1/P2/P3

Incident severity levels. P0=all users affected, P1=major impact, P2=limited, P3=minor.

Deployment

Moving code from development to production.

Rollout

Gradual deployment to percentage of users (canary deployment).

Downtime

System is unavailable or significantly degraded.

Team & Process Terms

Standup

Daily status update (synchronous or async). See /pb-standup.

Retrospective

Team reflection on what went well and what could improve.

Onboarding

Process of bringing new team member up to speed. See /pb-onboarding.

Knowledge Transfer

Sharing knowledge between team members or with new joiners. See /pb-knowledge-transfer.

Tech Lead

Senior engineer responsible for technical decisions and code quality.

Code Owner

Engineer responsible for specific code area. Should review changes to that area.

Pair Programming

Two developers working on same code simultaneously.

Code Review Feedback

Comments and suggestions on PR from reviewer.

Abbreviations

Command Reference

Shorthand for commands used throughout documentation:

See Also

• Decision Guide - Which command to use?
• Command Reference - All commands
• Getting Started - Quick start
• FAQ - Common questions