# Phase 2: Complete Client User Experience & Client Instance Infrastructure

## Status (July 2026) — host identity + multi-device + backups + mailboxes (1.6.15–1.6.19)
- ✅ **Host identity**: partner = human (person); company = **BusinesSite** only. Business/eShop name on `shop_name` + `instance_slug`.
- ✅ **Dedicated instances**: company on that instance = the business/service; partner remains the human.
- ✅ **Folder slugs**: lowercase, underscores (`la_sculpt_printworks`); path `/opt/docker/{stage}/clients/odoo/19/{ce|ee}/{slug}/`.
- ✅ One phone may not freely multi-register; photo admin auth; ownership transfer keys (sold/gifted).
- ✅ **Daily backups** of instance DB/filestore/images/volumes; admin configures server IP/folder/SSH.
- ✅ **Mother tongue** required on web + mobile registration; chat backfill for legacy profiles.
- ✅ **Platform mailbox**: auto `name_uuid@businessite.online` provisioned on **Mailcow** (cron + on register).
- ✅ Module **≥19.0.1.2.27**; APK **1.6.11+20**.

## Objectives
- Fix and complete automatic provisioning of client folders under `/opt/docker/{stage}/clients/odoo/19/{ce|ee}/{slug}/`.
- Polish the full human user (client) registration, profile, photo capture, GPS, and revenue model flow.
- Ensure every registered "human user" gets a clean, isolated client experience with proper docker + folder setup.
- Strengthen the transition from human user to support provider opt-in.
- Prevent identity masquerade via multi-device phone binding and admin photo review.
- Keep host partner/company rules and shop_name gate airtight.

## Key Technical Deliverables
- Update `businessite` module controllers (main.py, registration.py) and models (business_client.py).
- New provisioning logic in `businessite/models/client_instance.py` or similar to create folders and link Odoo instances under `/client/`.
- Enhance `PhotoCaptureWidget`, GPS capture, and profile save flows.
- Link `businessite.client` to support opt-in (is_support_provider) and future `businessite_support` records.
- Chat enhancements: Commands like "update profile", "my businesses", "opt into support".
- Fix any gaps in QR claim and mobile sync for client users.

## Homepage Impact
- Polished "For Individuals & Human Users" section with clean registration demo and "Start as a Human User" flow.

## Recruitment & Adoption Value
- Removes friction for early human users and businesses.
- Shows production-grade onboarding.

## Dependencies
- Existing registration, photo, GPS, and client creation code.
- Docker instance creation scripts.

## Success Criteria
- New registrations automatically create proper `/client//` structure.
- Full profile + photo + business registration works end-to-end via web and mobile.
- Users can seamlessly opt into support.

## Further Reading
- [Client Instance Provisioning Architecture](client_instances.md)
- [Registration Flow Improvements](registration_enhancements.md)
- [Client User Chat Commands](client_chat_commands.md)

## Detailed Tasks by Layer and Role (for full implementation)

### Data Layer
- **Architect**: Define data models and relations for this phase (e.g. new tables for phase-specific entities).
- **Analyst**: Specify data validation rules, reports, and analytics for the phase.
- **Admin**: Seed initial data, configure access rights, and set up data migration scripts.
- **Developer**: Implement CRUD operations, constraints, and data sync logic.

### System Layer
- **Architect**: Design system architecture, services, and integration points for the phase.
- **Analyst**: Map system workflows, error handling, and performance requirements.
- **Admin**: Configure system parameters, cron jobs, and environment setups.
- **Developer**: Code the backend services, APIs, and background jobs for the phase.

### User Layer
- **Architect**: Design user interfaces and UX flows for the phase (web and mobile).
- **Analyst**: Define user stories, permissions, and role-based access for the phase.
- **Admin**: Set up user training, roles matrix, and onboarding for the phase.
- **Developer**: Build the UI components, controllers, and client-side logic for user interactions.

### Security Layer
- **Architect**: Design security model, authentication, and audit for phase features.
- **Analyst**: Identify security risks and compliance requirements for the phase.
- **Admin**: Configure groups, rules, and access controls; review logs.
- **Developer**: Implement security checks, encryption, and access decorators in code.

### App Layer
- **Architect**: Define app-specific features, integrations with mobile and external apps.
- **Analyst**: Specify app data models and sync requirements.
- **Admin**: Manage app configurations, publish settings, and user grants.
- **Developer**: Code the app-specific models, views, and integration points (e.g. chat commands, mobile features).