Appendix

14.1 Glossary

• ADR (Architecture Decision Record): a short, dated document capturing a significant architectural decision, the alternatives considered, and why the chosen option won. See 14.2.
• Bulkheading: isolating a dependency’s resource usage (a connection pool, a concurrency budget) so a slow or degraded dependency can’t exhaust shared capacity and starve unrelated requests, distinct from circuit breaking, see 10.6.
• Contract-first: defining a request/response schema before writing the implementation that satisfies it, see 6.3.
• CSRF (cross-site request forgery): tricking an authenticated user’s browser into sending a request the user didn’t intend, relying on cookies being attached automatically regardless of the request’s origin, see 11.9.
• DTO (Data Transfer Object): the shape of data as it crosses an API boundary, distinct from the domain model and the DB model, see 6.8.
• Eventual consistency: accepting that a value can be briefly stale after a write, in exchange for avoiding a synchronous cross-service call or a join, only where the staleness is bounded and something closes the gap, see 8.10.
• Expand/contract: the zero-downtime schema migration pattern of adding a new field, migrating readers/writers, then removing the old field, rather than changing a schema in a single breaking step, see 7.8.
• Idempotent: an operation that produces the same effect whether run once or multiple times, required for webhook handlers, payment callbacks, and retried background jobs, see 8.7.
• IDOR (Insecure Direct Object Reference): an access control gap where an authenticated user can reach another user’s resource simply by changing an ID in a request, with no further exploit needed, see 11.14.
• N+1 query: issuing one query per item in a loop instead of a single batched query, a performance and correctness authoring rule, see 6.6.
• SSRF (server-side request forgery): tricking the server into making a request to a URL an attacker controls or influences, potentially reaching internal services or cloud metadata endpoints not meant to be reachable from outside, see 11.10.
• Trunk-based development: a branching model with short-lived branches merged frequently into main, as opposed to long-lived feature branches, see 4.4.
• YAGNI (You Aren’t Gonna Need It): the principle that an abstraction or capability should not be built until a concrete, current need requires it, see 8.4.

14.2 Architecture Decision Records (ADRs)

Significant architectural decisions are documented as lightweight ADRs, one markdown file per decision, so future engineers understand why a decision was made, not just what the current state is.

• Format: a short markdown file per decision (context, options considered, decision, consequences). Keep it brief, an ADR is a record of reasoning, not a design document.
• What qualifies: a decision this document itself would otherwise need to justify inline, why tRPC over REST for internal APIs (see 7.2), why a monorepo (see 3.1), why MongoDB over a relational store (see 6.6). Routine implementation choices don’t need an ADR; decisions a future engineer would reasonably ask “why did we do it this way” about do.
• Where they live: alongside the code they concern, so they’re discoverable in context rather than in a separate, easily-forgotten location.

Rule: a decision that changes something this document states as current fact (notably anything in Section 2.2) gets both an ADR and a change log entry (14.4), the ADR captures the reasoning, the change log captures that it happened.

14.3 Onboarding

A separate onboarding checklist covers the practical steps of getting a new engineer set up (access, tooling, first PR). It is intentionally not duplicated here: this document is the standard to be held to once onboarded, not the onboarding process itself. Refer to the onboarding checklist for setup steps.

14.4 Change log

Every change to this document that goes through the process in 1.3 is recorded here, most recent first. This is mandatory for any change to Section 2.2: a stack addition, removal, or replacement is not considered final until it’s both merged into that section and logged here.

Rule: a PR that changes Section 2.2 without adding a corresponding row here is incomplete, per the same standard this document holds itself to elsewhere: a rule that’s easy to forget in practice needs an explicit checklist item, not just good intentions.

14.5 Reference links

• Introduction and change-proposal process
• Current approved stack
• llms.txt: this standard, indexed for AI agents
• Plugin README : the installable agent-skill plugin

14.6 Acknowledgments

This standard is maintained by the Product Engineering team.

Product Engineering team: Raka Ardhi P., Dennis Jonathan, and Ryu Alvano contributed to drafting, reviewing, make this agent readable and maintaining this standard.

With thanks to people from other teams whose practices, reviews, or prior work directly shaped parts of this document: Adnan Abdul Malik of Operation Maintenance, Luky Prasetya of Architect Cloud Engineer, Petrus Dimas E. of AI Engineer, Zalman Faresi D. of Data & Prompt Engineer, and others.

Rule: add a name here whenever someone outside the immediate authors of a section meaningfully shaped its content, whether through direct contribution, review, or an existing practice this document adopted from them. This is a record of who to actually thank, keep it accurate rather than symbolic.