Build your own MyFitnessPal.

# Build an original app inspired by MyFitnessPal

You are an experienced mobile product designer and mobile engineer. Build a working, polished MVP from the brief below. Implement the core journeys end to end; a static mockup is not sufficient. Inspect the current environment, make sensible implementation decisions, and get started. Ask a question only if a missing answer genuinely blocks implementation.

Starting platform: Android. Explicit customized Product & audience and Tech stack requirements take precedence over this starting target.

## Product & audience
Build an original Android food journal called Mealnote, inspired by MyFitnessPal. It is for people recording what they eat using label values they enter or a small original sample catalog. The main journey is finding a food, choosing its serving quantity, adding it to a meal, and seeing an accurate daily summary. Deliver a native app with a working local database, without pretending to access a commercial food database.

## Design
Create an original calm diary with date navigation, meal sections, a prominent add-food action, and clearly labeled energy and macronutrient totals. Show whether values refer to a serving or 100 grams. Use neutral language and editable targets rather than celebratory weight-loss pressure. Support large text, screen readers, system back navigation, and numeric keyboards with locale-aware decimal input.

## Features
1. Personal foods: add, edit, and search foods with a serving name, gram weight, energy, protein, carbohydrate, and fat. Label original sample foods as examples. Validate nonnegative values and units; unknown nutrients stay unknown rather than silently becoming zero.

2. Diary logging: choose a date and meal, select a food, adjust servings or grams, and preview the calculated values before saving. Edit, move, duplicate, or remove a diary entry; a quick repeated save must not create duplicate meals.

3. Recipes: create a recipe from catalog foods, choose a yield, and calculate per-serving nutrition from its ingredients. Save a snapshot when logging so later recipe or food edits do not rewrite an older diary.

4. Summaries: show daily totals and a short weekly history derived from actual entries. Let users set optional display targets manually, with no automatic medical recommendations. Missing nutrients must remain visible in aggregate completeness indicators.

5. Offline and export: browse, search, and log without internet, remember recent foods, and export a selected date range as CSV through Android sharing. Import a validated app-owned backup with a preview and duplicate detection.

## Tech stack
Use Kotlin, Jetpack Compose, Room, and a testable decimal/unit-conversion module for a new Android project. Use Android file pickers and the share sheet rather than broad storage access. The MVP needs no camera, health-platform permission, or network service; handle cancellation of file selection and denied access to selected files gracefully. If an external food provider is later requested, verify its API, attribution, and license before integrating it. No WebView replacement for the native app.

## Data & behavior
Food {id, name, source, servingLabel, gramsPerServing, nutrients, updatedAt}; Recipe; RecipeIngredient {foodId, quantityGrams}; DiaryEntry {id, localDate, meal, foodId, quantity, unit, nutritionSnapshot}; DisplayTarget; ExportSettings. Keep energy units explicit, use decimal arithmetic before display rounding, and constrain implausible or malformed imports. Persist every confirmed edit transactionally. Retain backups separately from sample seed data, and offer deletion of all personal entries.

Acceptance checks and scope:
Log half a serving and a gram-based portion, edit a food afterward, and verify earlier diary snapshots remain stable. Test a multi-serving recipe, comma decimal input, missing nutrient fields, duplicate save, offline relaunch, canceled export, and database migration. Build the Android app and exercise the flow with emulator and accessibility checks. Exclude scraped food catalogs, barcode lookup, meal-photo AI, weight-loss prescriptions, Health Connect integration, cloud accounts, and medical accuracy claims.

## Originality and assets
The named product is a reference for general workflows only. Use an original product name, visual identity, wording, layout, and assets. Do not copy proprietary code, branded logos, distinctive screens, private APIs, paid templates, or protected media. Use original or appropriately licensed sample data and assets. Build from this brief rather than scraping the reference service. Do not imply affiliation with the referenced company.

## Implementation quality
- Make every visible control work, with clear loading, success, empty, validation, and failure states. Remove controls for unimplemented features.
- Support the target platform and responsive or resizable layouts where appropriate. Use platform-appropriate accessibility semantics, labels, keyboard operation, visible focus, sufficient contrast, and reduced-motion preferences. Provide alternatives for drag-only interactions.
- Validate inputs at the relevant boundary. Treat imported or user-generated content as untrusted; render it safely. Confirm destructive actions or offer undo.
- Keep state changes reliable across navigation and reloads. Never silently lose edits. Handle persistence and network errors with an actionable message.
- Keep the scope realistic. Prioritize the complete primary journey. If a custom Features section differs from the baseline, update the data model, design, and acceptance checks to match it; explicit custom requirements take precedence over baseline assumptions.
- Provide realistic original sample content and a useful empty state. Keep sample data clearly separate from user-created data.

## Delivery and verification
1. Inspect the repository and outline the implementation in a few sentences.
2. Implement the app and connect its actual data flow. Continue until the primary journey works.
3. Run appropriate checks and test the acceptance cases above on the target platform. Verify responsive layouts and keyboard navigation when browser tools are available. For native projects, build with the available SDK and test an emulator or device when possible; report any missing native verification honestly. For games, verify the rules and gameplay loop, not only the menus.
4. Fix observed failures, then provide the runnable result, setup/run instructions, a brief explanation of what is implemented, and any specific configuration or verification limits.

This is a focused MVP. Do not add billing, AI services, or unrelated features unless explicitly requested in the brief. Start building now.