Tingg

h1. Engineering Standards – Overview

*Purpose:* Define the scope, intent, and governance of engineering standards at Tinggit  

*Audience:* Engineering, Architecture, Security, QA, Product Leadership

{{toc}}

---

h2. 1. Purpose of Engineering Standards

Engineering Standards exist to ensure that Tinggit builds software that is:

* Reliable

* Secure

* Maintainable

* Scalable

* Audit-ready

These standards define **how we build**, not **what we build**.

*bq.* Standards protect long-term quality, even when delivery pressure is high.

---

h2. 2. Scope of This Section

The Engineering Standards section governs:

* Coding practices

* Architecture principles

* API and integration guidelines

* Security and compliance expectations

* Branching, PR, and review discipline

These standards apply to:

* All services

* All UIs

* All repositories

* All contributors

---

h2. 3. What Belongs in Engineering Standards

Engineering Standards pages must contain:

* Long-lived rules

* “Must / Must Not” expectations

* Principles that survive multiple sprints

* Cross-team consistency requirements

Examples:

* Naming conventions

* Error-handling expectations

* Security baselines

* Architectural constraints

---

h2. 4. What Does NOT Belong Here (Very Important)

The following must *never* be stored in Engineering Standards:

* Step-by-step tutorials

* Framework-specific how-to guides

* Temporary implementation decisions

* Sprint-specific design notes

* Experimental spike outcomes

Rules:

* If it changes sprint-to-sprint → it does not belong here

* If it is specific to one issue → it belongs in the issue

---

h2. 5. Relationship to Other Wiki Sections

Engineering Standards are **orthogonal** to delivery processes.

|_. Area |_. Responsibility |

| Product Process | How work is planned and delivered |

| Sprint Rules | How execution is governed |

| Engineering Standards | How code is written and structured |

| Role Guides | How people apply standards and process |

Engineering Standards do NOT override:

* Product priorities

* Sprint commitments

* Release governance

---

h2. 6. Current and Planned Standard Areas

The following standard areas may be added under this section:

* Coding Standards

* Architecture Principles

* API & Integration Guidelines

* Security & Compliance Practices

* Branching & PR Guidelines

Each area must:

* Have a clear owner

* Be reviewed periodically

* Avoid duplication with other sections

---

h2. 7. Governance & Change Rules

To keep standards effective:

* Standards must be reviewed before addition

* Changes must be intentional and documented

* Breaking changes must be communicated

* Old standards must be deprecated, not deleted

If a standard changes:

* Create a new version or page

* Reference the old one

* Preserve history

---

h2. 8. Enforcement Expectations

Engineering Standards are enforced through:

* Code reviews

* Automated checks (where applicable)

* QA validation

* Architecture review (when required)

Standards are not optional.

Exceptions must be:

* Explicit

* Documented

* Approved

---

h2. 9. Final Statement

*bq.* Engineering Standards are not about control.

They are about enabling teams to move fast  

*without breaking what they have already built*.

This page defines the boundaries.  

Future standards must respect them.