Skip to content

How to Use This Handbook

Application developer: engineering principles → developer practice → SDLC → repository governance → React, Node, or Python CI → testing.

Platform/DevOps engineer: all of the above, plus reusable CI, CD, containers, Kubernetes, Terraform, supply-chain security, and operations.

Reviewer or engineering manager: principles → lifecycle → quality gates → repository governance → CI metrics → exceptions.

Most standards use the same structure: purpose, Nexa context, mandatory and recommended rules, working model, evidence, failure modes, and maturity path. This consistency is intentional. A reader should quickly distinguish between policy and explanation.

When standards appear to conflict, use this order:

  1. Security and legal requirements.
  2. The repository-type standard.
  3. The general handbook rule.
  4. Team convention.

Raise unresolved conflicts as a handbook issue rather than creating an undocumented local workaround.

A proposed change should describe the problem, affected repositories, migration impact, security implications, and rollback plan. A standard is not changed solely because one repository finds it inconvenient. Conversely, a rule that repeatedly requires exceptions is a signal that the rule needs redesign.