# TANRAIL ONE — Master Index

## 1. Introduction
Welcome to **TANRAIL ONE**, the Integrated Business Management Platform for TANRAIL Investments Limited.

This platform is not designed as a single business application (e.g., a restaurant app or a transport app). It is designed as an **extensible enterprise platform** comprising a **Shared Core**, **Reusable Capabilities**, and **Business-Specific Extensions**. 

The initial implementations are:
- Restaurant
- Catering

Future implementations may include Water production, Transport, Equipment Rental, Manufacturing, and more.

## 2. Architecture Philosophy
The foundational philosophy of TANRAIL ONE is **"Shared Core + Reusable Capabilities + Business-Specific Extensions"**.
New businesses should be onboarded by reusing existing Core and Business capabilities, creating specific extensions only when genuinely necessary.

## 3. System Domains
The system is divided into logical domains:
- **Core Platform**: Authentication, Authorization, Business Units, Users, Reporting.
- **Master Data**: Customers, Suppliers, Products, Assets.
- **Operations**: Inventory, Procurement, Sales, Order Management.
- **Finance**: Invoices, Payments, Expenses, Accounting.
- **Business Extensions**: Restaurant (Tables, Kitchen), Catering (Events), etc.

## 4. Documentation Directory
This `/docs` directory serves as the **Source of Truth** for the entire project. All development MUST follow these guidelines.

### Architecture & Concept
- [01 Vision & Scope](./01-vision-and-scope.md) - Platform objective and scope definition.
- [02 Business Architecture](./02-business-architecture.md) - Organizational structure and entity mapping.
- [03 Core Capability Map](./03-core-capability-map.md) - Definition of Core vs Reusable vs Specific capabilities.
- [04 Business Unit Architecture](./04-business-unit-architecture.md) - How different businesses coexist.

### Specifications & Requirements
- [05 Functional Requirements](./05-functional-requirements.md) - Actionable system requirements.
- [06 Data Architecture](./06-data-architecture.md) - Conceptual data model and entity relationships.
- [07 Technical Architecture](./07-technical-architecture.md) - Laravel/Target tech stack and application layers.
- [08 Workflow & Transaction Spec](./08-workflow-and-transaction-specification.md) - Important state transitions.
- [09 UI/UX & Navigation](./09-ui-ux-and-navigation-specification.md) - Dashboard and navigation architecture.
- [10 Security & Access Control](./10-security-and-access-control.md) - Authentication, RBAC, and system security.
- [11 Reporting & Analytics](./11-reporting-and-analytics-architecture.md) - Consolidated and business-specific reporting.

### Planning & Execution
- [12 Development Roadmap](./12-development-roadmap.md) - Phased delivery plan.
- [13 Testing & Quality Strategy](./13-testing-and-quality-strategy.md) - Definition of "done" and quality standards.
- [14 Deployment & Infrastructure](./14-deployment-and-infrastructure.md) - Server and deployment architecture.
- [15 Architecture Decision Record (ADR)](./15-architecture-decision-record.md) - Log of major architectural choices.
- [16 Future Business Expansion Guide](./16-future-business-expansion-guide.md) - Playbook for onboarding new businesses.
- [99 Do Not Build Yet](./99-do-not-build-yet.md) - Restricted feature list to prevent premature implementation.
- [CHANGELOG](./CHANGELOG.md) - Architectural change tracking.

## 5. Development Workflow
1. **Understand**: Read this index and relevant documentation.
2. **Design**: Ensure new requirements align with the capability map and data architecture.
3. **Decide**: If an architectural change is needed, update the ADR (Doc 15) and relevant documents.
4. **Develop**: Write tests and implement logic. Keep business-specific logic isolated from the Core.
5. **Review**: Ensure no duplication of Core logic occurs.

## 6. Rules for AI Coding Agents
1. **Read this file (`00-project-master-index.md`) first.**
2. Read the relevant architecture documents before modifying code.
3. Understand dependencies before changing code.
4. **Never silently change architectural decisions.**
5. **Never create duplicate modules without justification.**
6. Update documentation when architecture changes.
7. Add tests for significant functionality.
8. Report assumptions and risks.
9. Stop and ask for human approval when making a major architectural decision.

## 7. Recording Architectural Changes
All significant architectural changes MUST be documented in `15-architecture-decision-record.md`. If a decision impacts data flow, security, or business unit isolation, the corresponding document (Docs 01-14) must also be updated to reflect the new state.