Engineering Protocol

1. INTRODUCTION

This document defines the standard operating procedures for Software Engineering at Moustachir Com. It applies to all Developers (Frontend, Backend, Mobile, AI), whether internal team members or external partners.

---

2. ROLE-SPECIFIC ONBOARDING

This protocol defines shared engineering standards that apply to all developers. For role-specific onboarding checklists and workflows, refer to your specialization:

• Fullstack Developers: Fullstack Engineering Protocol
• Frontend Developers: Frontend Engineering Protocol
• Backend Developers: Backend Engineering Protocol
• Mobile Developers: Mobile Engineering Protocol
• AI/ML Engineers: AI/ML Engineering Protocol

---

3. DAILY WORKFLOW & METHODOLOGY

3.1 Git Flow

We follow a strict branching model to ensure stability.

1. Sync: git checkout dev -> git pull.
2. Branch: git checkout -b feat/ticket-id-description (e.g., feat/PROJ-123-login-page).
3. Code: Implement the feature.
4. Commit: Use Conventional Commits (e.g., feat: add login form validation, fix: resolve auth timeout).
5. Push: git push origin feat/...
6. PR: Open a Pull Request to dev.
   • Description: Link the Notion ticket. Explain what changed and why.
   • Screenshots: Attach UI screenshots for frontend changes.

3.2 Code Quality Standards

• Linting: No linting errors allowed. CI will fail.
• Formatting: Prettier must be run before commit.
• Comments: Explain why, not what. Code should be self-documenting.
• Review: You must review at least one PR for every PR you submit (Internal Team).

3.3 Testing Strategy (The MVP Rule)

We distinguish between two phases of product development:

Phase 1: MVP Creation (Speed Mode)

• Goal: Validate the product market fit. Speed is the priority.
• Testing:
  • Manual Testing: Mandatory. You must verify your own work.
  • Automated Tests: Optional. Write them only for complex algorithmic logic.
  • TDD: NOT Required. Do not slow down MVP development with full test coverage.

Phase 2: Post-MVP / Production (Stability Mode)

• Goal: Scale and maintain reliability.
• Testing:
  • TDD (Test Driven Development): MANDATORY.
  • Process: Write the test -> Watch it fail -> Write the code -> Watch it pass -> Refactor.
  • Coverage: Critical paths (Auth, Payments, Data Integrity) must have integration tests.
  • CI/CD: Tests must pass in the pipeline before merging to main.

---

4. DEPLOYMENT

• Dev: Auto-deployed on push to dev.
• Staging: Auto-deployed on merge to staging. Used for QA and UAT.
• Production: Manually triggered or deployed on merge to main. Only Internal Team Leads can deploy to Production.

---

5. EXIT & HANDOVER

1. Push: Ensure all local branches are pushed.
2. Docs: Update README.md or API.md if you introduced new architecture.
3. Secrets: Destroy any local copies of production secrets.
4. Access: Sign out and confirm access revocation.