ERP Plus Roles & Access Model¶

This document defines how different roles interact with the ERP Plus system and documentation.

It is designed for startup → enterprise scale onboarding clarity.

Core Principle¶

ERP Plus documentation is NOT flat.

It is:

role-aware, permission-aware, and context-aware

Different users should NOT consume the same depth of system information.

Role-Based Documentation Model¶

ERP Plus defines 4 primary roles:

- Backend Developer
- Frontend Developer
- DevOps Engineer
- QA Engineer

Each role has a different lens into the system.

Backend Developer View¶

Access Level: FULL DOMAIN LAYER¶

Backend developers can access:¶

→ Architecture

→ Engines

→ System

→ Development

→ Decisions (ADRs)

Responsibilities:¶

implement engine logic
define domain rules
maintain services
ensure engine isolation

Forbidden:¶

modifying infrastructure without review
bypassing engine contracts

Frontend Developer View¶

Access Level: API CONSUMER ONLY¶

Frontend developers can access:¶

→ System

→ Architecture

→ Getting Started

API contracts (future section)

Responsibilities:¶

consume backend APIs
build UI/UX
avoid domain logic

Forbidden:¶

touching engine logic
modifying backend services
altering business rules

DevOps Engineer View¶

Access Level: INFRASTRUCTURE + DEPLOYMENT¶

DevOps engineers can access:¶

→ Environments

→ Security

→ System

→ CI/CD documentation

→ architecture (infrastructure sections)

Responsibilities:¶

CI/CD pipelines
deployments (Kamal)
monitoring
security enforcement

Forbidden:¶

modifying domain logic
altering business rules
touching engine internals

QA Engineer View¶

Access Level: SYSTEM BEHAVIOR ONLY¶

QA engineers can access:¶

→ System

→ Architecture

→ Engines

→ Testing docs

→ Decisions (ADRs)

Responsibilities:¶

validate system behavior
ensure regression safety
test engines independently

Forbidden:¶

modifying production logic
implementing features
changing architecture

Internal vs External Contributors¶

ERP Plus distinguishes between internal staff and community contributors.

The two groups participate differently in the delivery process.

Internal Staff¶

Internal contributors have access to:

Taiga
GitHub repositories
CI/CD pipelines
Sprint planning

Responsibilities:

execute User Stories
update Tasks
participate in sprint commitments
maintain delivery traceability

Typical workflow:

User Story
    ↓
Task
    ↓
Branch
    ↓
Pull Request
    ↓
Merge

Community Contributors¶

Community contributors do not require access to Taiga.

They contribute through GitHub.

Responsibilities:

report bugs
submit Pull Requests
improve documentation
propose enhancements

Typical workflow:

GitHub Issue
      ↓
Branch
      ↓
Pull Request
      ↓
Maintainer Review

Maintainers decide whether external work should be represented in Taiga.

Access Matrix¶

Capability	Internal Staff	Community
View Documentation	✔	✔
Submit PRs	✔	✔
Create Branches	✔	✔
Access Taiga	✔	✘
Sprint Planning	✔	✘
Manage User Stories	✔	✘
Manage Tasks	✔	✘
Production Deployments	Restricted	✘

Documentation Visibility Rules¶

Not all documentation is equal.

Public Layer (All Roles)¶

→ System

→ Blueprint

→ Getting Started

→ Architecture

Technical Layer (Engineers Only)¶

→ Engines

→ Modular Monolith

→ Engines Overview

Operational Layer (DevOps Only)¶

→ Environments

→ Security Policies

→ CI/CD

Decision Layer (All Engineers)¶

→ Decisions

Onboarding Flow (REAL WORLD)¶

When a new developer joins:

Step 1 — System Understanding¶

Read:

→ Overview

→ Blueprint

Step 2 — Architecture Understanding¶

Read:

→ Reading Guide

→ Data Flow

→ Engine Contracts

Step 3 — Role-Specific Deep Dive¶

Depending on role:

backend → Contribution Guide
frontend → Overview
devops → CI/CD
QA → Testing

Step 4 — First Contribution¶

Must follow:

CONTRIBUTING.md

→ CI/CD

→ Contribution Guide

Key Insight¶

ERP Plus is NOT documented like a project.

It is documented like:

🧠 a system with controlled knowledge exposure

WHY THIS MATTERS (CRITICAL)¶

Without this model:

frontend devs break backend rules
QA misunderstands engine boundaries
DevOps touches domain logic
external devs get lost
architecture becomes inconsistent

SCALING IMPACT¶

This structure enables:

✔ onboarding external teams safely
✔ parallel development across roles
✔ reduced architectural mistakes
✔ clear responsibility boundaries
✔ enterprise-grade maintainability

FINAL MENTAL MODEL¶

Same system → different perspectives → controlled knowledge exposure