StyleMate is a client–server system: one Android app and one Django backend, deployed with a GitOps pipeline. Each feature is a separate Django app with its own API under /api/, and a separate screen package in the Android app.

flowchart LR
  subgraph Phone["Android app (Kotlin, Jetpack Compose)"]
    BP["Body profile<br/>onboarding · results · My Profile"]
    WR["Wardrobe<br/>list · AR capture · garment editor"]
    PL["Home · outfit recommendation ·<br/>conversational editing · products<br/>(planned)"]
  end

  subgraph Backend["Django backend (one service)"]
    BA["apps/body_profiles<br/>POST /api/body-profile/analyze/"]
    WA["apps/wardrobe<br/>analysis draft · save · edit · list"]
    RA["recommendation / chat apps<br/>(planned)"]
  end

  subgraph AI["AI models and services"]
    MP["MediaPipe Pose<br/>(on server)"]
    HR["HRNet garment landmarks<br/>(ONNX, on server)"]
    GM["Gemini API<br/>(name, category, color)"]
  end

  DB[("MySQL<br/>garments, measurements, memos")]
  FS[("Server file storage<br/>garment photos")]

  BP -- "HTTPS (REST, multipart)" --> BA
  WR -- "HTTPS (REST)" --> WA
  PL -.-> RA
  BA --> MP
  WA --> HR
  WA --> GM
  WA --> DB
  WA --> FS

Login/onboarding integration (PR #26): app-specific ID/password authentication, optional eight-step onboarding, style-profile editing and explicit guest imports are implemented. MySQL now also stores User, AuthToken and AuthRateLimit records and account-owned garments/outfits. Guest data stays in app-private device storage. See §1.6 and §4.

Deployment:
The current repository defines one GitOps deployment path for the backend:

main branch
→ GitHub Actions backend release workflow
→ GHCR backend image
→ Argo CD Application
→ k3s workload in team14 namespace

Argo CD automatically reconciles the desired state in Git with the k3s cluster. The current codebase has no separate Argo CD Application or namespace for develop; only main → team14 is configured.

Team-level decisions:

A client–server design. The Android app uses MVVM: Compose screens observe a ViewModel, which calls a BodyAnalyzer interface. The server is a Django endpoint that delegates to a framework-independent Python package, body_analysis.

flowchart LR
  subgraph App["Android app (Kotlin, Jetpack Compose)"]
    UI["Screens<br/>CaptureGuide · PhotoInput · Analyzing<br/>Review · MyProfile · BodyFigure"]
    VM["BodyProfileViewModel<br/>SetupState / AppState (StateFlow)"]
    IF[["BodyAnalyzer (interface)"]]
    RA["RemoteBodyAnalyzer<br/>(OkHttp)"]
    FA["FakeBodyAnalyzer<br/>(previews, tests)"]
    UI -- "user events" --> VM
    VM -- "state" --> UI
    VM --> IF
    IF -.-> RA
    IF -.-> FA
  end

  subgraph Server["Django backend"]
    V["apps/body_profiles<br/>views.analyze: validation, size limit"]
    S["services: one pipeline per process,<br/>lock around analysis"]
    V --> S
  end

  subgraph Pkg["body_analysis package (pure Python)"]
    D["decode_image<br/>(OpenCV, ≤ 1280 px)"]
    R["ReferenceSet<br/>benchmark marker"]
    P["MediaPipePoseEstimator<br/>landmarks + person mask"]
    Q["check_quality<br/>retake hints"]
    M["measure<br/>widths × depths → cm"]
    C["ClothingDetector<br/>loose top / bottom"]
    K["MeasurementCorrector<br/>learned ridge correction"]
    D --> R --> P --> Q --> M --> C --> K
  end

  RA -- "HTTPS multipart POST<br/>front, side, height, weight?, gender?" --> V
  S --> D
  K -- "measurements, warnings,<br/>clothing, reference (JSON)" --> RA

Deployment (team infrastructure): GitHub Actions builds the backend Docker image and pushes it to GHCR. Argo CD deploys it to k3s on an Azure VM (2 vCPU, 8 GiB). The pose model is downloaded into the image at build time and checked against a checksum.

The wardrobe uses the shared Android app and Django backend. Compose screens and ViewModels manage browsing, analysis and editing. A separate capture activity manages the AR session and frozen camera frame.

%%{init: {"theme":"base","flowchart":{"curve":"stepBefore","nodeSpacing":36,"rankSpacing":55,"htmlLabels":true},"themeVariables":{"darkMode":true,"background":"#000000","primaryColor":"#333333","primaryTextColor":"#FFFFFF","primaryBorderColor":"#FFFFFF","lineColor":"#FFFFFF","secondaryColor":"#333333","tertiaryColor":"#333333","textColor":"#FFFFFF","clusterBkg":"#000000","clusterBorder":"#FFFFFF","edgeLabelBackground":"#000000","fontFamily":"Arial","fontSize":"16px"}}}%%
flowchart LR
  subgraph App["Android app (Kotlin, Jetpack Compose)"]
    UI["Wardrobe screens + ViewModels<br/>list · analysis · editor"]
    CAP["MeasurementActivity<br/>MeasurementCamera · ARCore"]
    GEO["MeasurementGeometry<br/>plane-based cm calculation"]
    NET["Wardrobe API clients<br/>HttpURLConnection"]

    CAP -->|"calculate"| GEO
    UI --> NET
    CAP -->|"detect points"| NET
  end

  subgraph Server["Django backend"]
    API["Wardrobe API<br/>apps/wardrobe"]
  end

  subgraph AI["Models and services"]
    HR["GarmentIQ HRNet<br/>ONNX Runtime · on backend"]
    GM["Gemini API<br/>name · category · colors"]
  end

  subgraph Storage["Storage"]
    DB[("MySQL<br/>garment records")]
    FS[("File storage<br/>garment photos")]
  end

  NET -->|"REST"| API
  API -->|"detect landmarks"| HR
  API -->|"analyze photo"| GM
  API -->|"read / write"| DB
  API -->|"read / write"| FS

  classDef default fill:#333333,stroke:#FFFFFF,color:#FFFFFF
  style App fill:#000000,stroke:#FFFFFF,color:#FFFFFF
  style Server fill:#000000,stroke:#FFFFFF,color:#FFFFFF
  style AI fill:#000000,stroke:#FFFFFF,color:#FFFFFF
  style Storage fill:#000000,stroke:#FFFFFF,color:#FFFFFF
  linkStyle default stroke:#FFFFFF,color:#FFFFFF

Diagram image

Authentication is part of the existing Android/Django system. Compose screens observe account-aware ViewModels; repositories use the same backend and separate device storage by guest/account identity. Onboarding reuses the body-analysis and wardrobe flows instead of introducing another service or database.

%%{init: {"theme":"base","themeVariables":{"darkMode":true,"background":"#000000","primaryColor":"#333333","primaryTextColor":"#FFFFFF","primaryBorderColor":"#FFFFFF","lineColor":"#FFFFFF","secondaryColor":"#333333","tertiaryColor":"#333333","textColor":"#FFFFFF","edgeLabelBackground":"#000000","fontFamily":"Arial","fontSize":"16px"},"flowchart":{"curve":"stepAfter"}}}%%
flowchart TB
    UI["Auth screens / My Profile<br/>OnboardingRoute"]
    VM["AuthViewModel<br/>BodyProfileViewModel<br/>GuestImportViewModel"]
    AUTH["AuthRepository<br/>AccountAccess"]
    IMPORT["GuestImportRepository"]
    LOCAL["LocalUserStore<br/>guest / account scope"]
    KEY["KeystoreSessionStore<br/>encrypted session"]
    UI --> VM
    VM --> AUTH
    VM --> IMPORT
    VM --> LOCAL
    IMPORT --> LOCAL
    IMPORT -->|"account-bound requests"| AUTH
    AUTH --> KEY
    API["users: authentication / profile / import<br/>wardrobe and outfits: protected account APIs"]
    ANALYSIS["Existing body / garment analysis<br/>reused during optional onboarding"]
    DB[("MySQL<br/>User / AuthToken / AuthRateLimit<br/>Garment / Outfit / OutfitItem")]
    FILES[("Server garment photos")]
    DEVICE[("App-private snapshot and garment photos")]
  AUTH -->|"Bearer token"| API
  VM --> ANALYSIS
  API -->|"owner-scoped access"| DB
  API --> FILES
  LOCAL --> DEVICE
  classDef default fill:#333333,stroke:#FFFFFF,color:#FFFFFF
  linkStyle default stroke:#FFFFFF,color:#FFFFFF

Diagram image

Body analysis, garment landmarks and Gemini analysis retain their existing roles. This feature does not add a separate authentication service or change their algorithms.

POST /api/body-profile/analyze/ · multipart/form-data

Responses:

Warning codes: loose_top, loose_bottom, no_weight, arms_touching_body, crotch_not_found. The app maps each to a Korean message.

classDiagram
  direction LR
  class BodyAnalyzer {
    <<interface>>
    +analyze(input, photos) AnalysisResult
  }
  class RemoteBodyAnalyzer {
    +parseResponse(status, body) AnalysisResult
  }
  class FakeBodyAnalyzer
  BodyAnalyzer <|.. RemoteBodyAnalyzer
  BodyAnalyzer <|.. FakeBodyAnalyzer

  class AnalysisInput {
    heightCm: Int
    weightKg: Int?
    gender: Gender
  }
  class AnalysisResult {
    measurements: List~BodyMeasurement~
    warnings: List~String~
    clothing: DetectedClothing
    reference: ReferenceMeasurements?
  }
  class BodyMeasurement {
    type: MeasurementType
    valueCm: Double
    confidence: Confidence
    editedByUser: Boolean
  }
  class DetectedClothing {
    topLoose: Boolean
    bottomLoose: Boolean
    affects(type) Boolean
  }
  class ReferenceMeasurements {
    body: String
    heightCm: Double
    values: Map
    accuracyPercent(m) Double?
  }
  class BodyProfile {
    input: AnalysisInput
    measurements: List~BodyMeasurement~
    preferredFit: PreferredFit
    preferredStyles: List~String~
    clothing: DetectedClothing
  }
  class BodyProfileViewModel {
    setup: StateFlow~SetupState~
    app: StateFlow~AppState~
    analyze()
    editMeasurement(type, cm)
    confirmProfile()
  }
  BodyAnalyzer ..> AnalysisResult
  AnalysisResult *-- BodyMeasurement
  AnalysisResult *-- DetectedClothing
  AnalysisResult o-- ReferenceMeasurements
  BodyProfile *-- AnalysisInput
  BodyProfile *-- BodyMeasurement
  BodyProfileViewModel --> BodyAnalyzer
  BodyProfileViewModel --> BodyProfile

• MeasurementType: 16 values with a group (length / circumference), a Korean label and a base confidence. The server uses the same keys (shoulder_width, chest, …).
• Confidence: high / medium / low. It is lowered for measurements under a detected loose garment and for low landmark visibility. Iteration 1 only shows it in the UI; it will stay internal later.
• Server types (body_analysis/types.py) mirror these: AnalysisInput, Measurement, AnalysisResult, ClothingAssessment, AnalysisError (code → Korean hint).
• Storage: confirmed body data is persisted through LocalBodyProfileStore / LocalUserStore. Guests keep it on the device; signed-in saves also update User.body_profile. Fit/mood/color preferences are stored separately from body data, and onboarding completion does not require a body profile (§4.4–§4.7).

1. Decode each photo in memory and shrink it to at most 1280 px on the long side.
2. Benchmark check: if both photos carry the marker of one of our 8 synthetic benchmark bodies, keep that body's true measurements for the response and paint the marker out (§2.6).
3. Pose and mask: MediaPipe Pose Landmarker (heavy) gives 33 landmarks and a person mask per photo. Images are padded to a width that is a multiple of 4, because MediaPipe aborts the process on other widths when reading the mask.
4. Quality gate: reject photos with no person, several people, a body that is not upright, the wrong orientation (shoulder spread), or a cut-off body. Each case gets its own hint.
5. Geometry:
   • Scale: entered height ÷ mask height in pixels.
   • Lengths: from landmarks and landmark-defined rows (waist = narrowest torso row, crotch, floor).
   • Circumferences: front width × side depth at the same relative body height, as an ellipse perimeter, times a per-measurement calibration factor.
6. Clothing detector: two logistic regressions (loose top, loose bottom) on scale-free silhouette features.
7. Learned correction: one ridge regression per measurement, on the same features plus height, BMI (if weight is given) and gender. It predicts measurement ÷ height. It is skipped for measurements under a detected loose garment, and the bicep is left out entirely under a loose top.
8. Confidence, warnings and derived ratios (shoulder/hip, waist/hip, torso/leg) are added.

Both models were trained on 240 synthetic bodies rendered from the Anny 3D body model, with ground truth sliced from the mesh. They are exported as small JSON files and run with NumPy only, so the server needs no ML framework.

buildInsights (data/BodyAnalyzer.kt) turns measurements into cards:

• Body type:
  • 하체 볼륨형: hip/chest ≥ 1.10
  • 상체 볼륨형: chest/hip ≥ 1.10
  • 허리 라인형: waist/hip ≤ 0.70
  • 일자형: waist/hip ≥ 0.80
• Leg proportion: inseam/height ≥ 0.47 or ≤ 0.45.
• Shoulders: shoulder/height ≥ 0.265.

Each threshold has a margin about the size of the measurement error, so nothing is shown near it. A rule is skipped when a measurement it uses comes from a region with detected loose clothing, unless the user edited that value.

BodyFigureGeometry.kt is pure Kotlin and unit-tested. It holds:

• the figure proportions per gender
• the hotspot of each measurement (a band, a line or a point)
• tap hit-testing: the nearest hotspot within about 26 dp

BodyFigure.kt draws the figure with Compose Canvas, pins the 5 key values as chips with leader lines, and shows the tapped measurement in a detail card.

For demos and validation, the app can show real accuracy ("정확도 98.7 %" = 100 − relative error) for our benchmark bodies:

• scripts/export_benchmark_reference.py renders the 8 bodies with a small marker in the top-left corner: a magenta start block, 5 bits for the body number and view, and a parity block. It also writes their true measurements to models/benchmark_reference.json.
• The server returns reference only when both photos carry markers of the same body. Ordinary photos never get an accuracy.

A marker was chosen over image matching because two benchmark bodies differ by only a few centimetres. After the app's JPEG compression and downscaling, their images were closer to each other than two copies of the same photo. The marker is painted out before analysis, so it changes no measurement.

All routes are under /api/wardrobe/.

Image requests use raw image bytes, not multipart forms. Invalid input, rejected photos, busy services, missing configuration and timeouts produce error responses that the app maps to messages.

options/, landmarks/ and guest analyze-preview/ do not require MySQL. analyze/, item reads/updates and stored-photo reads require a valid Bearer token and an owner-scoped database record. Missing/expired credentials return 401; a foreign item ID returns 404. Guest wardrobe reads/saves use LocalUserStore instead of the account persistence API.

The diagrams show the main classes and modules used by the wardrobe. Nullability and secondary members are omitted; the database and API constraints are specified below.

%%{init: {"theme":"base","themeVariables":{"darkMode":true,"background":"#000000","primaryColor":"#333333","primaryTextColor":"#FFFFFF","primaryBorderColor":"#FFFFFF","lineColor":"#FFFFFF","secondaryColor":"#333333","tertiaryColor":"#333333","textColor":"#FFFFFF","edgeLabelBackground":"#000000","fontFamily":"Arial","fontSize":"16px"}}}%%
classDiagram
  direction LR
  %% Key members only. Nullability is omitted from this structural summary.

  class WardrobeViewModel {
    +state: StateFlow~WardrobeState~
    +refresh()
    +save(id, payload)
  }
  class WardrobeState {
    +records: List~JSONObject~
    +catalog: JSONObject
    +loading: Boolean
    +saving: Boolean
  }
  class WardrobeRepository {
    <<object>>
    +json(path, body) JSONObject
    +thumbnail(path) ImageBitmap
  }
  class GarmentAnalysisViewModel {
    +state: StateFlow~AnalysisState~
    +select(photo)
    +analyze(context, photo)
  }
  class AnalysisState {
    +photo: String
    +busy: Boolean
    +result: JSONObject
  }
  class GarmentAnalysisModule["GarmentAnalysis.kt"] {
    <<module>>
    requestAnalysis(context, photo) JSONObject
  }
  class WardrobeViews["apps/wardrobe/views.py"] {
    <<module>>
    analyze(request)
    items(request)
    item(request, item_id)
    item_image(request, item_id)
  }
  class Garment {
    <<Django model>>
    +id: UUID
    +image: FileField
    +attributes: JSON
    +dimensions: JSON
    +notes: Text
    +saved: Boolean
  }

  WardrobeViewModel --> WardrobeState : maintains
  WardrobeViewModel ..> WardrobeRepository : uses
  GarmentAnalysisViewModel --> AnalysisState : maintains
  GarmentAnalysisViewModel ..> GarmentAnalysisModule : calls
  WardrobeRepository ..> WardrobeViews : REST
  GarmentAnalysisModule ..> WardrobeViews : POST analyze
  WardrobeViews ..> Garment : creates / queries / updates

%%{init: {"theme":"base","themeVariables":{"darkMode":true,"background":"#000000","primaryColor":"#333333","primaryTextColor":"#FFFFFF","primaryBorderColor":"#FFFFFF","lineColor":"#FFFFFF","secondaryColor":"#333333","tertiaryColor":"#333333","textColor":"#FFFFFF","edgeLabelBackground":"#000000","fontFamily":"Arial","fontSize":"16px"}}}%%
classDiagram
  direction LR
  %% Key members only. Nullability is omitted from this structural summary.

  class MeasurementSnapshot {
    +bitmap: Bitmap
    +geometry: MeasurementGeometry
    +point(u, v) MeasurePoint
  }
  class MeasurementGeometry {
    -inverseViewProjection: FloatArray
    -planeOrigin: MeasurePoint
    -planeNormal: MeasurePoint
    +point(u, v) MeasurePoint
  }
  class MeasurePoint {
    +x: Float
    +y: Float
    +z: Float
  }
  class GarmentLandmarks {
    <<object>>
    +detect(bitmap, garment) LandmarkResult
  }
  class LandmarkResult {
    +suggestions: Map~String, LandmarkPath~
  }
  class LandmarkPath {
    +points: List~LandmarkPoint~
  }
  class LandmarkPoint {
    +x: Float
    +y: Float
  }

  MeasurementSnapshot --> MeasurementGeometry : contains
  MeasurementGeometry ..> MeasurePoint : uses / creates
  GarmentLandmarks ..> LandmarkResult : creates
  LandmarkResult --> LandmarkPath : suggestions
  LandmarkPath --> LandmarkPoint : points

UML diagram image

Django stores one garment per row in wardrobe_garment.

attributes contains:

Gemini supplies only name, category and colors. Other fields start as null or empty arrays and can be set by the user. Pattern, relative length, material and wearing properties are not stored as attributes.

dimensions uses cm and stores each available measurement with its source and method. For example:

{
  "unit": "cm",
  "shoulder_width": {
    "value": 45.32,
    "source": "arcore_assisted",
    "method": "flat_shoulder_seam_to_seam",
    "reference": null
  }
}

This is a payload example, not an accuracy result.

Values must be finite and positive and are rounded to two decimal places. Missing measurements are omitted; an empty measurement set becomes null. Widths are not circumferences.

Sources distinguish automatic-point AR measurement, manual-point AR measurement and user-entered numbers. Editing a number changes its source to user_measured. The schema also accepts product_chart, but importing product size charts is not implemented.

Only the current attributes are stored; there is no separate copy of the original AI result. Image bytes, landmark coordinates, camera matrices and body profiles are not stored in the garment row.

1. Track the floor. ARCore estimates the camera pose and a horizontal plane. The user lays the garment flat and keeps it within the frame. No fixed capture height is required.
2. Find image points. The backend resizes the image with aspect ratio preserved and runs pretrained GarmentIQ HRNet through ONNX Runtime on CPU. The selected garment type determines the landmark channels and measurement paths.
3. Restore coordinates. Model coordinates are mapped back to the original image. Low-confidence or missing points may leave some measurements unavailable. Some endpoints are derived from predicted contours rather than directly predicted landmarks.
4. Calculate cm on the phone. The app freezes the image and its AR camera and plane data together. A ray through each image point is intersected with the plane. Distances between intersections, or sums along a multi-point path, are converted from meters to centimeters.
5. Review and describe. The user checks or replaces points. After photo confirmation, Gemini suggests the name, category and colors.
6. Edit and save. The app combines the suggested attributes with compatible measurements and user edits, then saves the record.

HRNet is used without additional training or fine-tuning. It predicts landmark locations, not exact seam segmentation. The measurement assumes the garment lies on the tracked plane; folds, thickness, tracking errors and misplaced points can affect the result.

Abandoned drafts are not automatically expired or deleted. User ownership is enforced for account records and stored photos. Manual guest imports use version checks to detect changes after review (§4.6); ordinary garment edits do not provide general version-based conflict resolution, and garment deletion remains outside this feature. Server photo storage must persist independently of disposable application containers.

This section documents the implemented account/guest integration, including session ownership, local storage, explicit imports and onboarding state. Body and garment analysis algorithms remain in §§2–3.

Requests use JSON except garment-photo imports. Release builds keep cleartext traffic disabled; HTTP is enabled only in the debug manifest for local development. Protected routes require Authorization: Bearer <token>. Missing, expired, revoked or inactive-account credentials return 401; another owner's detail ID returns 404.

• IDs accept lowercase ASCII letters, digits and underscores, 4–20 characters. Password input is 8–64 characters; confirmation must match. Passwords are hashed with Django's password facilities and never included in public user responses.
• Authentication/profile JSON is limited to 8 KiB. Unknown fields, duplicate keys, non-finite numbers and invalid nested body fields are rejected.
• Profile lists contain distinct allowed values: up to five fits, six moods and eight colors. Empty confirmed fits become ["regular"]; empty moods/colors are valid. Colors are normalized to uppercase #RRGGBB.
• body_profile is nullable and accepts height_cm, weight_kg, gender, measurements, clothing, and reference. Measurements use the existing 16 type codes, a positive finite cm value, optional confidence and a user-edited flag. Body photos are not stored in this field. The existing input screen accepts height 100–220 cm; profile API validation permits 100–230 cm.
• Error codes include INVALID_CREDENTIALS, USERNAME_TAKEN, PASSWORD_MISMATCH, INVALID_PROFILE and BODY_TOO_LARGE. Unknown IDs and wrong passwords share INVALID_CREDENTIALS.

1. Generate a cryptographically random 256-bit token on successful registration/login. Return its URL-safe text once; store only its SHA-256 hash, owner and expiration on the server.
2. Persist the app session in noBackupFilesDir/auth-session.enc, encrypted with an Android Keystore AES-256-GCM key. The session contains the token, expiry and cached public profile, not the password.
3. Bind account requests to an AccountAccess for that session. Validate the token on every protected server request and apply owner filters.
4. Restore the local session at app startup and check the profile on foreground entry. Local expiry or a protected 401 clears that session and switches to guest UI. Network/server failure alone keeps the session.
5. Logout revokes the current server token before clearing the local session. A failed logout remains retryable. Other issued tokens remain valid until their own logout or expiration.

Tokens expire 30 days after issuance; there is no sliding expiry or refresh-token endpoint. AuthRateLimit shares counters in the DB: five failed logins for an ID within five minutes block that ID for five minutes; registration/login requests share a 20-per-minute IP limit. A successful login clears that ID's failure counter. 429 responses provide Retry-After and retry_after.

The IP limit uses REMOTE_ADDR and does not trust client-supplied forwarded headers. Proxy address handling must be checked in the deployment environment so unrelated users do not share one proxy-address limit.

Only principal members are shown. The diagrams distinguish interfaces and classes; nullable/secondary members are omitted from the structural view.

%%{init: {"theme":"base","themeVariables":{"darkMode":true,"background":"#000000","primaryColor":"#333333","primaryTextColor":"#FFFFFF","primaryBorderColor":"#FFFFFF","lineColor":"#FFFFFF","secondaryColor":"#333333","tertiaryColor":"#333333","textColor":"#FFFFFF","fontFamily":"Arial","fontSize":"16px"}}}%%
classDiagram
  direction TB
  class AuthViewModel {
    +state: StateFlow~AuthUiState~
    +submit(username, password, confirmation)
    +refreshSession()
    +logout()
  }
  class AuthRepository {
    +status: StateFlow~AuthStatus~
    +restore()
    +authenticate(username, password, confirmation)
    +verify()
    +logout()
    +account() AccountAccess
  }
  class AccountAccess {
    +userId: String
    +json(method, path, data) JSONObject
    +list(path, key) JSONArray
    +patchProfile(data)
    +upload(path, metadata, image)
  }
  class AuthSessionStore {
    <<interface>>
    +read() String
    +write(value)
    +clear()
  }
  class KeystoreSessionStore {
    +read() String
    +write(value)
    +clear()
  }
  class AuthSession {
    +expiresAt: Instant
    +user: AccountUser
  }
  class AccountUser {
    +id: String
    +username: String
    +body: JSONObject
    +style: StyleProfile
  }
  AuthViewModel --> AuthRepository
  AuthRepository --> AuthSessionStore
  AuthSessionStore <|.. KeystoreSessionStore
  AuthRepository --> AuthSession
  AuthRepository ..> AccountAccess
  AccountAccess --> AuthSession : bound to login
  AccountAccess --> AuthRepository
  AuthSession --> AccountUser

Diagram image

%%{init: {"theme":"base","themeVariables":{"darkMode":true,"background":"#000000","primaryColor":"#333333","primaryTextColor":"#FFFFFF","primaryBorderColor":"#FFFFFF","lineColor":"#FFFFFF","secondaryColor":"#333333","tertiaryColor":"#333333","textColor":"#FFFFFF","fontFamily":"Arial","fontSize":"16px"}}}%%
classDiagram
  direction TB
  class BodyProfileViewModel {
    +onboarding: StateFlow~OnboardingProgress~
    +moveOnboarding(step)
    +confirmOnboardingFits()
    +startOnboardingGarment(category, id)
    +skipSetup()
  }
  class BodyProfileStore {
    <<interface>>
    +load() BodyProfile
    +save(profile)
    +saveStyle(style)
    +saveOnboarding(progress)
  }
  class LocalBodyProfileStore
  class LocalUserStore {
    +style() StyleProfile
    +onboarding() OnboardingProgress
    +garments() List~JSONObject~
    +saveGarment(id, payload) JSONObject
    +recordImport(accountId, key, fingerprint, status)
  }
  class OnboardingProgress {
    +step: Int
    +completed: Boolean
    +draft: String
  }
  class GuestImportViewModel {
    +state: StateFlow~GuestImportState~
    +open()
    +confirm()
    +decide(replace)
    +retry()
  }
  class GuestImportRepository {
    +snapshot() GuestImportSnapshot
    +preview(snapshot) GuestImportPlan
    +importRecord(record, plan, replace) String
  }
  class AccountAccess
  BodyProfileViewModel --> BodyProfileStore
  BodyProfileStore <|.. LocalBodyProfileStore
  LocalBodyProfileStore --> LocalUserStore
  BodyProfileViewModel --> OnboardingProgress
  LocalUserStore ..> OnboardingProgress
  GuestImportViewModel --> GuestImportRepository
  GuestImportRepository --> LocalUserStore : import receipts
  GuestImportRepository --> AccountAccess : authenticated imports

Diagram image

StyleMateApp creates a separate ViewModel store for each active identity and disposes the previous one on a switch. BodyProfileStore is an interface: its local implementation adapts LocalUserStore; its in-memory implementation is used in tests/previews. OnboardingProgress(step, completed, draft) is local state independent of BodyProfile.

%%{init: {"theme":"base","themeVariables":{"darkMode":true,"background":"#000000","primaryColor":"#333333","primaryTextColor":"#FFFFFF","primaryBorderColor":"#FFFFFF","lineColor":"#FFFFFF","secondaryColor":"#333333","tertiaryColor":"#333333","textColor":"#FFFFFF","fontFamily":"Arial","fontSize":"16px"}}}%%
erDiagram
  User ||--o{ Garment : ""
  User ||--o{ Outfit : ""
  Outfit ||--o{ OutfitItem : ""
  Garment ||--o{ OutfitItem : ""
  User ||--o{ AuthToken : ""
  User {
    UUID id PK
    string username UK
    string password
    JSON body_profile
    JSON preferred_fits
    JSON preferred_styles
    JSON favorite_colors
  }
  Garment {
    UUID id PK
    UUID user_id FK
    string image
    JSON attributes
    JSON dimensions
    JSON labels
    bool saved
  }
  Outfit {
    UUID id PK
    UUID user_id FK
    string source
    bool saved
  }
  OutfitItem {
    bigint id PK
    UUID outfit_id FK
    UUID garment_id FK
    string slot
    string note
  }
  AuthToken {
    string key_hash PK
    UUID user_id FK
    datetime expires_at
  }
  AuthRateLimit {
    string key PK
    int count
    datetime window_started
    datetime blocked_until
  }

Diagram image

• wardrobe_garment.user_id and outfits_outfit.user_id are required foreign keys to User. Garment attributes, measurements, labels and photo paths retain their existing structures.
• outfits_outfititem continues to connect an Outfit and a Garment with slot and note. Its (outfit_id, slot) unique constraint is retained. Current slots are top, bottom and optional outerwear; shoes remain registrable garments rather than outfit members.
• Neither User nor Outfit stores garment/outfit IDs as a replacement array. Small preference arrays stay in User JSON fields; relational ownership and membership use foreign keys.
• API code enforces ownership and one top/one bottom with optional outerwear. Foreign-key existence and unique outfit slots are DB constraints; cross-record category/ownership validation is application logic.
• Garments referenced by any stored outfit, including an unsaved recommendation, cannot change category. Ordinary saves and import replacements return 409 GARMENT_CATEGORY_IN_USE; same-category edits remain allowed. Garment/category updates and outfit creation use the same user-row transaction lock. Recommendation results are rechecked before persistence in case a garment changed while calculating.
• Django deletion policies cascade account removal to its garments, outfits and tokens; there is no account-deletion UI/API in this feature.

Migration: add the User/token/limit tables, add garment/outfit owner foreign keys, remove legacy unowned garment/outfit rows, and make the foreign keys required. This intentionally approved one-time cleanup preserves owned records; it is not an ongoing deletion policy for new user data.

LocalUserStore saves private metadata under filesDir/local-users/guest/data.json or filesDir/local-users/<account UUID>/data.json. Guest garment photos are kept under that directory's garments/<UUID>.jpg path. The snapshot holds body/style data, onboarding progress/drafts, recommendation taste, garments/outfits and per-account import receipts.

Writes use a temporary file, flush/sync and atomic replacement. Reading malformed data reports an error instead of resetting the file. The implementation uses the new store directly; it does not preserve an incompatible old database through a second storage layer.

Account profile and wardrobe metadata are cached separately from guest data. Server-backed account saves require connectivity; current account photo and saved-outfit reads are online. Guest saved records are local, but new body/garment analysis and recommendation calculation still require the backend.

Account garment and saved-outfit lists use next and ?after=<next>. Each page contains at most 20 records and at most 128 KiB of serialized item data, leaving room under the Android 256 KiB response limit. The URL-safe cursor carries the account/list scope and the page boundary's timestamp/ID; queries always remain owner-filtered. The boundary does not move if the previous page's last record is edited or unsaved. This is not a transaction-wide snapshot of every record during concurrent edits.

The app treats the cursor as opaque, validates its length/character set and rejects repeated cursors. Only a complete successful wardrobe fetch replaces its cache. Guest recommendation previews omit notes, image paths and analysis caches and use a matching 1 MiB request limit on app/server; source records remain unchanged.

1. Snapshot the explicit guest candidates: confirmed body/style data, saved garments/photos and saved outfits. Starting login never starts this operation.
2. Preview conflicts and versions in bounded batches. Keep account values by default; selected conflicts opt into replacement.
3. Map each guest garment/outfit UUID to a deterministic server UUID using UUIDv5 over the account UUID, record kind and source UUID. Equal names are not identity, and two accounts cannot share the imported row.
4. Import profile sections and garments before outfits. Validate that every outfit member resolves to a saved garment owned by this account with the correct category/slot.
5. Lock the user/target row in a transaction and compare the expected version. A changed account value returns 409 IMPORT_CHANGED instead of overwriting the reviewed data. Repeating the same value after a lost response returns an unchanged result.
6. Record successful imported, unchanged or kept receipts and content fingerprints locally. Failures remain pending, source data is retained, and profile-refresh failure after a successful upload can be retried without uploading it again. A later manual import may revisit records previously kept.

Import JSON is bounded to 32 KiB per operation. Photos are JPEG/PNG/WebP, at most 5 MiB and 12 million pixels, and pass through the existing image-normalization path. Account-linked garments retain the category-change restriction above. Imports create no extra DB model and do not recompute recommendation results.

The shared header has back, StyleMate and one upper-right skip action. There is no duplicate lower skip action. My Profile toggles fits/moods directly, commits color edits explicitly and opens body results through the body-balance card. These screens reuse the existing theme and do not introduce another typography system.

The first recommendation uses the existing feature: missing body information shows its analysis-required guidance, and missing suitable top/bottom garments shows its registration guidance. Onboarding stores preferences in User after account save/import, but this change does not add new recommendation rules for those fields.

The feature uses the existing backend, MySQL connection configuration and photo-storage deployment. Its new deployment-specific checks are applying the added migrations and verifying proxy IP handling for the new authentication request limit. Local USB forwarding is a development connection method, not a production requirement. Social authentication, password recovery, continuous guest/account synchronization and new outfit/chat algorithms are outside this change.

TODO (as a team). Candidates in body analysis: Strategy (PoseEstimator / BodyAnalyzer interfaces with real and fake implementations) and a lazily created shared pipeline in services.py.