System Requirements Document for steel-terra

1. Introduction

DERMAMIND AI — COMPLETE FULL-STACK APP DEVELOPMENT MASTER PROMPT

1. ROLE AND PROJECT OBJECTIVE

Act as a senior full-stack software engineer, mobile app developer, UI/UX designer, AI engineer, Firebase architect, security engineer, and software tester.

Build a functional, production-oriented MVP called DermaMind AI.

App name: DermaMind AI

Tagline: Understand Your Skin. Improve Your Health. Live Better.

Platform priority: Android first, with an architecture that can support iOS and web where the selected technology allows it.

Required Android application ID: "com.aistudio.dermamind"

Create a polished application combining AI-assisted skincare, general health education, nutrition, food analysis, fitness, wellness tracking, and healthcare facility discovery.

This must be a working application, not merely a UI prototype.

• Project name: steel-terra.

2. System Overview

12. FITNESS COACH AND WORKOUT PLANNER

Create a conversational fitness assistant and workout planner.

3. Functional Requirements

If starting a new project, create the architecture and files required to implement the features below.

Main navigation

Use a simple bottom navigation bar with:

• Home

• Skin

• Food

• Fitness

• Profile

Provide accessible navigation to additional features through the dashboard, menus, and dedicated screens.

4. HOME DASHBOARD

Create a premium dashboard containing:

• DermaMind AI logo.

• Welcome message.

• Profile avatar and account access.

• Quick wellness summary.

• Skin Analysis card.

• Skincare Routine card.

• AI Health Assistant card.

• Food Scanner card.

• Food Combination card.

• Nutrition Guidance card.

• Fitness Coach card.

• Progress and History card.

• Dermatologist and Hospital Finder card.

• Settings and privacy access.

Display useful empty states for new users.

5. AI SKIN ANALYSIS

Allow users to select a photo from their gallery or capture one using the camera.

Workflow

1. Request camera or gallery permission when needed.

2. Validate the selected image.

3. Show an image preview.

4. Explain how the image will be processed.

5. Upload the image securely only when required and consented to.

6. Send the image to a supported AI vision model through the appropriate secure integration.

7. Validate the returned result.

8. Display the result in structured cards.

9. Allow the user to save or delete the result.

Analysis output

Provide:

• Estimated skin type: oily, dry, combination, normal, or unclear.

• Visible characteristics such as redness, acne-like spots, visible pores, dryness, flaking, oiliness, dark spots, and uneven texture.

• Confidence or uncertainty information where supported.

• General skincare ingredient recommendations.

• A simple morning routine.

• A simple evening routine.

• Precautions and possible irritation concerns.

• Guidance on when to consult a dermatologist.

Use only observations supported by the image.

Do not diagnose a disease, infer hidden medical conditions, or claim that a photograph can establish a definitive diagnosis.

If the image is blurry, poorly lit, unsuitable, or unrelated to a face, return this exact message:

"Unable to analyze clearly. Please upload a clear, well-lit face photo."

Do not invent analysis results when the model fails.

6. SKINCARE ROUTINE AND PRODUCT GUIDANCE

Provide general skincare guidance based on the user's visible concerns, stated preferences, and skin sensitivity.

Potential ingredient categories include:

• Niacinamide.

• Salicylic acid.

• Azelaic acid.

• Hyaluronic acid.

• Ceramides.

• Vitamin C.

• Gentle cleansers.

• Moisturizers.

• Broad-spectrum sunscreen.

Do not guarantee that a product will work for every person.

Explain that active ingredients should be introduced gradually and may cause irritation.

Offer a basic morning routine:

1. Gentle cleanser.

2. Appropriate skincare product, if suitable.

3. Moisturizer.

4. Broad-spectrum sunscreen, preferably SPF 30 or higher.

Offer a basic evening routine:

1. Gentle cleanser.

2. Appropriate skincare product, if suitable.

3. Moisturizer.

Provide patch-testing and irritation guidance where appropriate.

Do not prescribe medicines or prescription-strength treatments.

7. AI HEALTH ASSISTANT — STRICT MEDICATION RESTRICTIONS

Mandatory medication restrictions

The Health Assistant must not recommend, list, prescribe, or suggest:

• Tablet or medicine names.

If actual commercial products are displayed, use verified product information. Never fabricate product availability, ingredients, prices, ratings, or purchase links.

7. AI HEALTH ASSISTANT — STRICT MEDICATION RESTRICTIONS

Create a conversational assistant for general health education.

It may explain:

• Common health topics.

• Symptoms in understandable language.

• General non-drug self-care.

• Hydration and rest guidance when appropriate.

• Basic preventive health information.

• General wellness habits.

• Warning signs that warrant professional evaluation.

• How to prepare questions for a healthcare professional.

• Drug names or medication brands.

• Medication dosages.

• Medication schedules.

• Drug combinations.

• Prescription treatments.

• Medication purchase links.

When asked which medicine to take, explain that medication choices require appropriate professional guidance and recommend consulting a qualified healthcare professional or pharmacist.

The assistant must never claim to be a doctor or replace medical care.

For emergency symptoms, clearly advise the user to contact local emergency services or seek urgent medical care.

For uncertain or serious symptoms, avoid false reassurance and recommend appropriate professional assessment.

8. SMALL HEALTH CONDITIONS INFORMATION DATABASE

Create a searchable educational library for common minor health concerns.

Use the Firestore collection:

"small_conditions"

Suggested document fields:

• "name"

• "normalizedName"

• "aliases"

• "description"

• "commonSymptoms"

• "generalCare"

• "organicSolutions"

• "precautions"

• "warningSigns"

• "whenToSeeDoctor"

• "sourceReferences"

• "reviewStatus"

• "createdAt"

• "updatedAt"

The library may cover topics such as mild headaches, common cold symptoms, minor muscle soreness, and general digestive discomfort.

If no reliable entry exists, tell the user that verified information is unavailable instead of generating a false database result.

9. FOOD SCANNER — FIX NUTRITION ACCURACY

Allow users to upload a food photograph or manually enter food names.

The application may identify likely foods from an image, but it must communicate uncertainty.

Required workflow

1. Upload or select an image.

2. Identify likely foods.

3. Allow the user to correct the identification.

4. Ask for portion size or serving quantity when needed.

5. Retrieve nutrition data from a reliable structured nutrition source.

6. Calculate the nutritional values for the actual selected foods and quantities.

7. Display the result and source information where available.

8. Allow the user to save the scan if desired.

Required nutritional output

Display available information for:

• Calories.

• Protein.

• Carbohydrates.

• Fat.

• Fiber.

• Sugar.

• Sodium.

• Selected vitamins and minerals when supported by the data source.

Show units and serving sizes clearly.

Mark estimates as estimates.

Critical calculation requirements

Different foods must not repeatedly return the same nutritional values because of hardcoded examples, stale state, incorrect caching, or faulty matching.

Implement and test:

• Reliable food identification and database matching.

• Correct serving-size conversions.

• Per-food nutritional calculations.

• Correct totals for multiple foods.

• Appropriate handling of missing nutrients.

Do not substitute zero for missing nutritional data without explaining that the value is unavailable.

• Unique cache keys based on food identity, serving size, and relevant data version.

• Correct request and response handling.

• Loading, error, and retry states.

• State updates that replace stale results.

• Validation against known test cases.

If a food cannot be identified reliably, ask the user to enter its name manually.

10. FOOD COMBINATION ANALYZER

Allow users to select multiple foods and specify their quantities.

Examples:

• Rice, chicken, and vegetables.

• Eggs and vegetables.

• Milk and banana.

• Fruits and yogurt.

• User-created combinations.

Analyze the combination using structured nutrition data and transparent calculations.

Display:

1. Overall nutritional assessment.

2. Calories, where data is sufficient.

3. Protein.

4. Carbohydrates.

5. Fat.

6. Fiber.

7. Relevant vitamins and minerals.

8. Possible benefits.

9. Nutritional gaps.

10. Portion guidance.

11. Possible allergens and dietary restrictions.

12. Suggestions for improving nutritional balance.

Use simple assessments such as:

• Good nutritional balance.

• Could be improved.

• Insufficient information.

11. NUTRITION AND PERSONALIZED DIET GUIDANCE

Ask for portion size when it materially affects the result.

11. NUTRITION AND PERSONALIZED DIET GUIDANCE

Allow users to optionally provide:

• Age.

• Nutrition goal.

• Vegetarian or non-vegetarian preference.

• Allergies.

• Dietary restrictions.

• Activity level.

11. NUTRITION AND PERSONALIZED DIET GUIDANCE

For specialized medical diets, recommend professional advice.

11. NUTRITION AND PERSONALIZED DIET GUIDANCE

Create a nutrition section for general wellness and fitness.

Support goals such as:

• Weight gain.

• Weight loss.

• Fat loss.

• Muscle gain.

• Strength.

• General fitness.

• Endurance.

• Weight maintenance.

• Balanced nutrition.

Generate general meal suggestions using the user's stated preferences, allergies, food availability, and goal.

Where numerical nutrition targets are shown, explain their assumptions and uncertainty.

Provide food substitutions and affordable options when suitable.

Allow the user to provide:

• Age.

• Height and weight, optionally.

• Fitness experience.

• Main fitness goal.

• Available equipment.

• Workout location.

• Available time.

• Preferred workout days.

• Relevant limitations or injuries.

Support:

• Weight gain.

• Weight loss.

• Fat loss.

• Muscle gain.

• Strength.

• General fitness.

• Endurance.

• Maintenance.

Generate appropriate plans containing:

• Exercises.

• Sets and repetitions where suitable.

• Rest periods.

• Weekly schedule.

• Warm-up guidance.

• Recovery recommendations.

• Progression guidance.

• Beginner modifications.

• General nutrition advice.

Adapt plans to the user's available equipment and experience.

Provide safe alternatives for users who cannot perform a particular exercise.

Do not recommend dangerous extreme training or promise guaranteed body transformations.

For injuries, chronic conditions, pregnancy, or other special circumstances, recommend appropriate professional guidance.

13. PERSONALIZED WELLNESS DASHBOARD AND TRACKING

Create optional tracking features for:

• Skincare routine completion.

• Workout completion.

• Nutrition logs.

• Weight trends.

• Fitness goals.

• Analysis history.

• User-defined wellness goals.

Let users control which data is stored.

Provide meaningful progress charts only when sufficient real data exists.

Allow users to edit and delete their records.

14. DERMATOLOGIST AND HOSPITAL FINDER

Create a facility discovery feature for:

• Dermatologists.

• Dermatology clinics.

• Hospitals.

• Skin specialists.

• Emergency healthcare facilities.

Support India and additional countries when reliable information is available.

Display available verified information:

• Facility name.

• Specialist name when verified.

• Address.

• Phone number.

• Website.

• Opening hours.

• Map location.

• Distance when location permission is available.

Use a supported places or maps service.

Provide external navigation when supported.

Request location permission only when necessary, explain its purpose, and provide manual location search as an alternative.

15. USER PROFILE AND SETTINGS

Provide an editable user profile containing optional fields such as:

• Display name.

• Profile image.

• Age or age range.

• Fitness goals.

• Dietary preferences.

• Allergies.

• Preferred units.

• Skincare preferences.

• Wellness goals.

Collect only information needed for the selected features.

Do not require sensitive information without a clear reason.

Include settings for:

• Theme.

• Notifications.

• Units.

• Privacy preferences.

• Data export where supported.

• Account management.

• Data deletion.

• Sign out.

Implement Firebase Authentication correctly.

Support, where configured:

• Email and password registration.

• Email and password login.

• Password reset.

• Email verification where appropriate.

• Google sign-in when correctly configured.

• Sign out.

• Authentication state persistence.

• Session restoration.

• Friendly authentication errors.

Include:

• Registration screen.

• Login screen.

• Forgot-password screen.

• Account settings.

• Appropriate authenticated and unauthenticated navigation.

Validate input and display helpful errors.

Allow appropriate public educational content to remain accessible without requiring an account, where practical.

Reviewed educational information, aliases, precautions, and source references.

"user_routines/{routineId}"

User-specific skincare or workout routines.

"analysis_history/{historyId}"

User-owned references and summaries for relevant analyses.

• Clear upload progress and failure handling.

• Deletion of associated files when the user deletes them, where applicable.

4. User Personas

steel-terra serves people seeking everyday health, nutrition, fitness and care-facility guidance. Roles below reflect only responsibilities established by the requirements; the persona set is not closed, and further roles may be added as evidence arrives.

Supporting actors (not human personas): the AI health assistant, which is restricted to general health education and must not provide medication guidance; the fitness coach; and the facility directory supplying verified facility name, specialist name (when verified), address, phone number and website.

Observable success: users find understandable educational content without an account, receive guidance matching their stated preferences, and reach verified facility contact details. Data control—choosing what is stored and editing or deleting records—applies to authenticated users.

5. Core User Flows

5.1 Skin Analysis

Actor: User. Trigger: User opens the Skin Analysis card from the Home dashboard or the Skin tab.

1. User selects a photo from the gallery or captures one with the camera; the app requests camera or gallery permission when needed.
2. App validates the image, shows a preview, and explains how the image will be processed.
3. Image is uploaded securely only when required and consented to, then sent to a supported AI vision model through the appropriate secure integration.
4. App validates the returned result and displays it in structured cards: estimated skin type (oily, dry, combination, normal, or unclear), visible characteristics, confidence or uncertainty where supported, ingredient recommendations, morning and evening routines, precautions and irritation concerns, and dermatologist-consultation guidance.
5. User saves or deletes the result.

Failure branch: If the image is blurry, poorly lit, unsuitable, or unrelated to a face, the app returns exactly: "Unable to analyze clearly. Please upload a clear, well-lit face photo." The user may retry with a new image.

5.2 Skincare Routine and Product Guidance

Actor: User. Trigger: User opens the Skincare Routine card or follows the routine from an analysis result.

1. User reviews or states visible concerns, preferences, and skin sensitivity.
2. App presents general guidance with potential ingredient categories (niacinamide, salicylic acid, azelaic acid, hyaluronic acid, ceramides) and a basic morning routine (gentle cleanser, suitable product if appropriate, moisturizer, broad-spectrum sunscreen preferably SPF 30 or higher) and evening routine (gentle cleanser, suitable product if appropriate, moisturizer).
3. User optionally marks routine steps complete, feeding the tracking features.

5.3 AI Health Assistant Conversation

Actor: User. Trigger: User opens the AI Health Assistant card.

1. User asks a general health question.
2. Assistant explains common topics, symptoms in understandable language, non-drug self-care, hydration and rest, preventive information, wellness habits, warning signs, and how to prepare questions for a professional.
3. Branches: For medication questions, the assistant explains that medication choices require professional guidance and recommends a qualified healthcare professional or pharmacist. For emergency symptoms, it advises contacting local emergency services or seeking urgent care. For uncertain or serious symptoms, it avoids false reassurance and recommends professional assessment. If no reliable entry exists, it states that verified information is unavailable rather than generating a false database result.

5.4 Food Scan

Actor: User. Trigger: User opens the Food Scanner card.

1. User uploads or selects a food photograph, or manually enters food names.
2. App identifies likely foods and communicates uncertainty; user corrects the identification.
3. App asks for portion size or serving quantity when needed.
4. App retrieves nutrition data from a reliable structured nutrition source and calculates values for the actual selected foods and quantities, including per-food calculations and correct totals for multiple foods.
5. App displays calories, protein, carbohydrates, fat, fiber, sugar, sodium, and selected vitamins and minerals where supported, with units, serving sizes, source information, and estimates marked as estimates; missing nutrients are shown as unavailable, never substituted with zero.
6. User saves the scan if desired.

Failure and recovery: Loading, error, and retry states are shown; state updates replace stale results. If a food cannot be identified reliably, the user is asked to enter its name manually.

5.5 Food Combination Analysis

Actor: User. Trigger: User opens the Food Combination card.

1. User selects multiple foods and specifies quantities (e.g., rice, chicken, and vegetables; eggs and vegetables; milk and banana; fruits and yogurt; or a user-created combination).
2. App analyzes the combination using structured nutrition data and transparent calculations.
3. App displays overall nutritional assessment (good balance, could be improved, or insufficient information), calories where data is sufficient, protein, carbohydrates, fat, fiber, relevant vitamins and minerals, possible benefits, nutritional gaps, portion guidance, possible allergens and dietary restrictions, and suggestions for improving balance.

5.6 Nutrition and Personalized Diet Guidance

Actor: User. Trigger: User opens the Nutrition Guidance card.

1. User optionally provides age, nutrition goal, vegetarian or non-vegetarian preference, allergies, dietary restrictions, and activity level.
2. App asks for portion size when it materially affects the result.
3. App generates general meal suggestions using stated preferences, allergies, food availability, and goal.
4. For specialized medical diets, the app recommends professional advice.

5.7 Fitness Plan Generation

Actor: User. Trigger: User opens the Fitness Coach card.

1. User provides age, optional height and weight, fitness experience, main goal, available equipment, workout location, available time, preferred workout days, and relevant limitations or injuries.
2. App generates a plan with exercises, sets and repetitions where suitable, rest periods, weekly schedule, warm-up guidance, recovery recommendations, progression guidance, beginner modifications, and general nutrition advice, adapted to available equipment and experience.
3. App provides safe alternatives for exercises the user cannot perform.
4. For injuries, chronic conditions, pregnancy, or other special circumstances, the app recommends appropriate professional guidance.

5.8 Wellness Tracking and Progress Review

Actor: User. Trigger: User opens the Progress and History card or a tracking entry point.

1. User opts into tracking skincare routine completion, workout completion, nutrition logs, weight trends, fitness goals, analysis history, and user-defined wellness goals, controlling which data is stored.
2. App shows meaningful progress charts only when sufficient real data exists; otherwise it shows useful empty states.
3. User edits or deletes records as needed.

5.9 Dermatologist and Hospital Finder

Actor: User. Trigger: User opens the Dermatologist and Hospital Finder card.

1. App requests location permission only when necessary and explains its purpose; manual location search is available as an alternative.
2. App uses a supported places or maps service to find dermatologists, dermatology clinics, hospitals, skin specialists, and emergency healthcare facilities, supporting India and additional countries when reliable information is available.
3. App displays verified facility name, specialist name when verified, address, phone number, website, opening hours, map location, and distance when location permission is available.
4. App provides external navigation when supported.

5.10 Account Access and Authentication

Actor: User. Trigger: User opens registration, login, forgot-password, or account settings; or the app restores a persisted session on launch.

1. User registers or signs in with email and password, or with Google sign-in when correctly configured; password reset and email verification are offered where appropriate.
2. App validates input, displays helpful and friendly authentication errors, and persists authentication state so sessions are restored on return.
3. Navigation adapts to authenticated and unauthenticated state; appropriate public educational content remains accessible without an account where practical.
4. User signs out from account settings.

5.11 Profile and Settings Management

Actor: User. Trigger: User opens the Profile tab or account access from the dashboard.

1. User edits optional profile fields: display name, profile image, age or age range, fitness goals, and dietary preferences.
2. User adjusts settings for theme, notifications, units, privacy preferences, data export where supported, account management, data deletion, and sign out.
3. When the user deletes content, associated files are deleted where applicable; uploads show clear progress and failure handling.

5.12 Dashboard Orientation

Actor: User. Trigger: App launch or return to Home.

1. User lands on the Home dashboard showing the DermaMind AI logo, welcome message, profile avatar and account access, quick wellness summary, and cards for Skin Analysis, Skincare Routine, AI Health Assistant, Food Scanner, Food Combination, Nutrition Guidance, Fitness Coach, Progress and History, Dermatologist and Hospital Finder, and Settings and privacy.
2. Bottom navigation provides Home, Skin, Food, Fitness, and Profile; additional features are reachable through the dashboard, menus, and dedicated screens.
3. New users see useful empty states; genuine user-specific progress appears only when real data is available, and health scores, scan results, progress percentages, and activity statistics are never fabricated.

6. Visuals Colors and Theme

[Design proposal; unspecified choices are defaults.]

Muse and headline. MARQ by Garmin — a personal instrument you consult, not a chatbot you play with. DermaMind AI (project name steel-terra) reads as a precision skin-and-wellness instrument: trustworthy and premium, never clinical-cold or gimmicky.

Palette (light mode). Page ground soft mint #F2F7F3; content surfaces white #FFFFFF; text #14211D; structural primary deep pine-teal #0E5C4A (headings, dial strokes, primary buttons); single hot signal accent instrument green #1FA37A (live values, gauge fills, one CTA per screen — never a large fill); muted sage-grey #6B7F78 for labels and secondary copy. Dark mode inverts to graphite-titanium #10171A ground with #E8F1EC text and the same two greens. Proportions ≈70% mint/white, 20% pine, 10% signal green. No blue or indigo anywhere.

Typography. Headings and numerals Barlow Condensed 600–700, tight tracking (-0.01em); micro-labels uppercase 11–12px at +0.14em. Body and UI Sora 400/500, card titles Sora 600. Numerals always tabular; large measurement values set condensed and large so they read as instrument readouts. Modular scale 1.25: 11/12 label, 15 body, 19 card title, 24 section, 34 display, 48 hero numeral (mobile 34 → desktop 56 via clamp).

Shape and depth. Rounded-rectangle instrument cards (18–22px radius) with a 1px inner hairline rgba(14,92,74,0.10) and a two-layer shadow (0 1px 2px rgba(20,33,29,0.06), 0 10px 24px -12px rgba(20,33,29,0.18)). Circular gauge wells with a thin 3px pine ring and a signal-green sweep. Buttons are capsules with a 1px darker bottom edge to read as physical keys. Sharp 2px rules separate label/value rows. No blobs, no glass.

Layout. Mobile-first single column at 375px with 20px gutters; 12-column grid at 768px; 1280px two-zone layout with a fixed left instrument rail (logo, mode switch, section index) and a scrolling card column. Every data card shares one anatomy: micro-label row, dominant condensed value, ruled sub-rows, one action. Bottom navigation stays five items (Home, Skin, Food, Fitness, Profile) with the active item marked by a filled green dial dot, not a pill. Feature cards use a clean vertical layout with a 2px-stroke pine pictogram in a small circular well on the left and the description on the right; the interface stays uncluttered and beginner-friendly.

Imagery. Macro material only where it earns its place: a close-cropped water-droplet-on-skin texture, brushed-metal grain in card shadows, a topographic line field at 6% opacity behind the dashboard header. Icons are 2px-stroke pictograms in pine. No stock people, no stock clinic photography, no fake 3D body or skin scans.

Accessibility. Accessible contrast, readable text, and sufficiently large touch targets in both modes; headlines, wordmarks, labels, numbers and controls stay whole inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling to fit.

3. PREMIUM UI/UX DESIGN SYSTEM

Design DermaMind AI as a premium, modern healthcare and wellness application.

Visual identity

• Clean white and soft mint backgrounds.

• Sophisticated teal and green accents.

• Dark, readable headings.

• Subtle gradients where appropriate.

• Rounded cards and buttons.

• Consistent spacing and typography.

• High-quality icons and illustrations.

• Soft shadows and subtle dimensional effects.

• Smooth, restrained animations.

• Professional, friendly healthcare styling.

• Light and dark modes where supported.

• Accessible contrast, readable text, and sufficiently large touch targets.

Use a consistent design system for colors, typography, buttons, cards, input fields, icons, dialogs, loading indicators, and navigation.

Use a clean vertical card layout with appropriate illustrations on the left and feature descriptions on the right where suitable.

Keep the interface uncluttered and beginner-friendly.

7. Signature Design Concept

[Design proposal; unspecified choices are defaults.]

Signature concept — the instrument panel. DermaMind AI's Home dashboard opens on a full-width instrument header rather than a centred marketing hero. On the left, a 96px circular wellness gauge (pine ring, green sweep, condensed tabular numeral inside) with the welcome message set beneath it in Sora 500; the profile avatar and account access sit in the header. The DermaMind AI wordmark sits top-left in Barlow Condensed uppercase with a small green dial dot as its logotype punctuation. At 768px+ a stacked column of three ruled readouts sits on the right — 'Skin · not analysed yet', 'Nutrition · no scans today', 'Fitness · no plan yet' — each a label/value pair with a hairline rule, in honest empty states. A topographic line field at 6% opacity bleeds off the top-right edge behind the gauge. No gradient blob, no centred headline, no blue button.

Signature moves. (1) The circular wellness gauge as the dashboard's dominant object — 96px mobile, 180px desktop — with green sweep, tabular condensed numeral, and a hairline tick ring at 5-unit intervals. (2) Ruled instrument readout rows: every data point as an 11px uppercase micro-label over a condensed value, separated by 1px rules — used for nutrition totals, skin concerns, and facility hours alike. (3) Bezel cards: each feature card carries a 1px inner hairline and two-layer shadow so it reads as a machined panel seated on the mint ground. (4) Bottom navigation as an instrument cluster: five items, active state a filled green dot inside a thin ring that slides between tabs over 180ms. (5) Food and nutrition totals as a horizontal band of stacked mini-gauges (calories, protein, carbs, fat) with condensed numerals, replacing progress bars.

Depth discipline. Subtle 3D lives only in layered bezel cards, realistic shadows, gentle elevation, dimensional buttons and smooth transitions. Genuine 3D rendering is used only where it serves a real purpose and the platform supports it; no simulated skin scanner, body scanner, or 3D model is shown where no such functionality exists. Speed, accessibility and usability outrank visual effects. Structured results (skin analysis, food analysis) render in these same ruled cards; loading, error and retry states reuse the gauge ring and readout rows rather than introducing new chrome. Every visible button works, is explicitly disabled with an explanation, or shows a clearly labelled coming-soon state.

Subtle 3D appearance

Add tasteful depth through layered cards, realistic shadows, gentle elevation, dimensional buttons, and smooth transitions.

Use genuine 3D rendering only when it serves a real purpose and is supported by the platform. Do not simulate a working skin scanner, body scanner, or 3D model when no such functionality exists.

Prioritize speed, accessibility, and usability over unnecessary visual effects.

8. Interaction Model & Motion Direction

[Design proposal; unspecified choices are defaults.]

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: dimensional_css

Landing Hero Motion Brief. Focal subject: the 96px (180px desktop) circular wellness gauge in the Home instrument header, with the topographic line field bleeding off the top-right. Input → transformation → outcome: on mount the gauge needle sweeps from zero to the user's wellness value over 900ms on cubic-bezier(0.2,0.7,0.2,1) while the condensed numeral counts up once; the three ruled readouts settle into their honest empty states ('not analysed yet', 'no scans today', 'no plan yet'); the outcome is a composed instrument panel the user can read at a glance. Motion vocabulary: one purposeful loop only — the gauge sweep and single count-up; cards reveal with a 12px rise and 0.98→1 scale, staggered 60ms, never repeating; the bottom-nav active dot slides between tabs over 180ms; upload progress is a thin green arc filling the gauge ring. Composed first frame: gauge at rest at zero with tick ring visible, wordmark and dial dot top-left, readout rows ruled and empty, topographic field static behind. Reduced-motion state: gauges render at final value instantly, no rise, no count-up, no stagger — a fully usable static arrangement with all readouts legible.

Avoid. Playful bounce or springy micro-interactions; gradient-blob heroes, glassmorphism, floating 3D primitives; fabricated health data in empty states — always show honest 'not yet measured' readouts.

9. Non-Functional Requirements

• Monitoring: appropriate error logging and application diagnostics.

Never expose private API keys, Firebase service-account credentials, administrative credentials, or privileged secrets in frontend code.

Every visible button must work, be explicitly disabled with an explanation, or display a clearly labelled coming-soon state.

Show genuine user-specific progress only when real data is available. Never fabricate health scores, scan results, progress percentages, or activity statistics.

Only publish reviewed and appropriately sourced health information.

Do not present unverified remedies as proven treatments.

Organic or home-care suggestions must include relevant safety precautions. Natural products can cause allergies, irritation, or other harm.

Never claim laboratory-level accuracy from a photograph.

Do not label ordinary food combinations toxic or dangerous without reliable evidence.

11. NUTRITION AND PERSONALIZED DIET GUIDANCE

Do not invent exact nutritional values or claim that estimated requirements are medical prescriptions.

Avoid extreme calorie restriction, unsafe bulking recommendations, or unbalanced diets.

For minors, pregnancy, eating disorders, chronic disease, or other special circumstances, use conservative guidance and recommend qualified professional advice.

Do not store passwords directly in Firestore.

Do not create a fake login screen that grants access without authenticating the user.

If a provider is not configured, show a clear setup requirement instead of pretending sign-in works.

Do not duplicate unnecessary sensitive information.

Avoid storing the same information in multiple collections unnecessarily.

Use server timestamps where appropriate, stable document IDs, indexes for required queries, and schema validation.

Design the schema to support future changes without breaking existing records.

Separate public educational data from private user information.

Requirements:

• Private image access by default.

• Authenticated access where appropriate.

• File-type and file-size validation.

• Safe filenames and storage paths.

• Appropriate upload and download permissions.

10. Tech Stack

2. REQUIRED TECHNOLOGY AND ARCHITECTURE

Use the technologies supported by the chosen app-building platform.

Preferred architecture:

• Android application: Flutter or another genuinely supported Android framework.

• Frontend: reusable, responsive components.

• Backend: secure server-side functions or an appropriate backend service.

• Authentication: Firebase Authentication.

• Database: Cloud Firestore.

• Image storage: Firebase Storage with private access controls.

• AI: a supported vision-and-text model through a secure backend.

• Nutrition: a reliable structured nutrition data source, with calculations performed by application logic.

• Maps: a supported maps or places service for real healthcare facilities.

Create a clear separation between:

1. UI and presentation.

2. Application logic.

3. Authentication and authorization.

4. Database and storage operations.

5. AI integrations.

6. External APIs.

7. Validation and error handling.

8. FIREBASE AUTHENTICATION

9. FIRESTORE DATABASE DESIGN

Use Cloud Firestore for structured application data.

Suggested collections:

"users/{uid}"

Fields may include:

• "displayName"

• "email"

• "photoURL"

• "preferences"

• "dietaryPreferences"

• "fitnessGoals"

• "createdAt"

• "updatedAt"

"small_conditions/{conditionId}"

"skin_analysis/{analysisId}"

• "userId"

• "storagePath", when applicable

• "result"

• "createdAt"

• "modelVersion", when available

"food_analysis/{analysisId}"

• "userId"

• "foods"

• "portions"

• "nutritionTotals"

• "dataSource"

• "createdAt"

"fitness_profiles/{uid}"

Optional fitness preferences and goals.

"workout_logs/{logId}"

• "userId"

• "workout"

• "completionStatus"

• "createdAt"

"nutrition_logs/{logId}"

• "userId"

• "foodItems"

• "quantities"

• "nutritionTotals"

• "createdAt"

18. FIREBASE STORAGE AND IMAGE PRIVACY

Use Firebase Storage for uploaded images when needed.

11. Assumptions and Constraints

Critical preservation rules

If working inside an existing project:

• Inspect the existing codebase, framework, dependencies, backend, Firebase configuration, API integrations, screens, navigation, assets, and permissions before making changes.

• Preserve all existing working functionality.

• Do not delete, rename, replace, disable, or break existing features, files, routes, APIs, database collections, authentication, or navigation.

• Preserve the exact Android application ID "com.aistudio.dermamind".

• Do not overwrite working configurations with invented placeholders.

• Make the smallest safe changes necessary and explain any required migrations.

• Back up important files before making potentially destructive changes.

Do not mix incompatible frameworks or generate duplicate applications.

If the existing project uses React, React Native, Flutter, or another framework, retain its working architecture unless a migration is genuinely necessary.

Do not include medicine names or dosages in this feature.

Do not infer or invent missing records.

Avoid presenting cosmetic or wellness estimates as medical measurements.

Do not fabricate facilities, doctor names, credentials, addresses, phone numbers, or opening hours.

Clearly distinguish unavailable information from verified information.

Do not imply that a listed facility is medically endorsed unless that endorsement has been verified.

• No publ

12. Glossary

DermaMind AI — the product built by this project (working project name: steel-terra). Tagline: Understand Your Skin. Improve Your Health. Live Better. Android-first, application ID com.aistudio.dermamind, with an architecture that can support iOS and web where the selected technology allows it.

MVP — the production-oriented first release of DermaMind AI: a working application, not merely a UI prototype, combining AI-assisted skincare, general health education, nutrition, food analysis, fitness, wellness tracking, and healthcare facility discovery.

Skin condition record — the educational entry describing a skin condition. Its fields are normalizedName, aliases, description, commonSymptoms, generalCare, organicSolutions, precautions, warningSigns, whenToSeeDoctor, sourceReferences, reviewStatus, createdAt, and updatedAt.

normalizedName — the single canonical name under which a skin condition record is stored and referenced.

aliases — alternative names for a condition, used to match user searches and references to the canonical record.

commonSymptoms — the typical signs of a condition as described in its educational record.

generalCare — general self-care guidance attached to a condition record.

organicSolutions — natural or organic remedy suggestions attached to a condition record.

precautions — measures a user should take to avoid aggravating a condition.

warningSigns — indicators in a condition record that signal a need for escalated attention.

whenToSeeDoctor — the conditions under which the record directs the user to seek professional care.

sourceReferences — the citations backing a condition record's educational content.

reviewStatus — the state of a condition record indicating whether its educational information, aliases, precautions, and source references have been reviewed.

Fitness goal — the user-selected training objective, one of: fat loss, muscle gain, strength, general fitness, endurance, maintenance.