Domain Standard
| Purpose | Pattern | Example |
|---|---|---|
| Public company site | root + www | cloudberrie.com, www.cloudberrie.com |
| Internal business application | descriptive subdomain | board.cloudberrie.com |
| Manual | manual | manual.cloudberrie.com |
| API | api | api.cloudberrie.com |
| Status | status | status.cloudberrie.com |
Do not create unused infrastructure merely to reserve a name. Record planned subdomains, but provision services only when there is a real requirement.
Repository Standard
Use descriptive lowercase kebab-case names. Preferred examples:
cloudberrie-website\ncloudberrie-business-operations-manual\ncloudberrie-studio-board\neventlumi\naifa
Avoid inconsistent abbreviations unless the abbreviation is an established product name.
Environment Standard
| local | Individual development only |
| development | Shared integration work where needed |
| staging | Stakeholder review and release validation |
| production | Real users and real data only |
Git Branch Standard
main\ndevelop # only when the project needs a persistent integration branch\nfeature/<short-description>\nfix/<short-description>\nhotfix/<short-description>\nrelease/<version>
Keep the workflow proportional. Small projects can use main + short-lived branches; do not create process overhead without a team or release need.
File & Version Standard
Client_Project_Deliverable_YYYY-MM-DD_v01.ext
Product releases use semantic versioning where practical: major.minor.patch.
Email Standard
- Use hello@ for general public communication.
- Use clients@ for existing client relationship communication.
- Use social@ for social-platform access and administration.
- Use accounts@ for vendor/platform ownership and billing.
- Keep admin@ internal.