Build your own Forest.

# Build an original app inspired by Forest

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 focus companion called Sprouttime, inspired by Forest. It is for students and independent workers using a commitment timer with a visual record of completed sessions. The primary flow is selecting a duration, starting a session, finishing or explicitly abandoning it, and seeing an original plant added to the history. This MVP is a focus timer, not an app blocker; do not claim to restrict other applications.

## Design
Use original simple plant illustrations and a quiet timer screen with elapsed/remaining time, a task label, and a clear give-up action. Keep rewards gentle and distinguish finished, abandoned, and interrupted sessions. Add a compact garden/history view without copying Forest artwork. Support TalkBack, large text, reduced animation, and sufficient contrast in both light and dark system themes.

## Features
1. Session setup: choose a bounded duration, an optional task tag, and one of a few original plant styles. Show the commitment rule before starting. Prevent multiple simultaneous active sessions and support a short preview session for testing.

2. Reliable timer: calculate remaining time from a persisted deadline and monotonic elapsed time while running, not a decrementing UI counter. Reconcile after screen lock, app switching, and process recreation. Leaving the app alone does not fail the session in this version.

3. Completion and abandonment: complete an elapsed session once, show a finished plant, and offer an explicit give-up confirmation before recording an abandoned result. Do not award focus time for abandoned sessions or duplicate the reward after relaunch.

4. History and tags: view finished sessions by day and tag, inspect duration and outcome, edit a label, and remove a record with confirmation. Calculate daily/weekly focused minutes from persisted finished sessions and label interrupted sessions clearly.

5. Reminders and backup: optionally notify at the end using supported Android notification scheduling, with visible best-effort timing limitations. Denied notification permission leaves the timer usable. Export/import a versioned local backup through native file selection and sharing.

## Tech stack
Use Kotlin, Jetpack Compose, Room, and platform notification APIs for a new native Android app. Keep timer state and reconciliation in a testable module, animations derived from the timer state, and lifecycle writes off the UI thread. Include Gradle project files and a documented target SDK. Do not request Accessibility Service, usage access, broad storage access, or exact-alarm permissions just to imitate app blocking. A WebView, fake background loop, or browser-only timer is insufficient.

## Data & behavior
FocusSession {id, plannedSeconds, startedAt, deadlineAt, elapsedCheckpoint, bootMarker, state, completedAt, tagId, plantStyle}; Tag; NotificationPreference; BackupVersion. Store one active-session identifier transactionally and apply an idempotent complete transition. Define how clock changes and reboot affect a session: retain an uncertain/interrupted state rather than inventing focus duration. Keep history offline and distinguish starter examples from the user’s actual completed sessions.

Acceptance checks and scope:
Complete a one-minute test, lock the screen halfway, recreate the process, and verify one reward plus the correct duration. Test give-up confirmation, duplicate completion, system clock changes, reboot recovery, notification denial, canceled import, and large text. Build and run the Android emulator; verify screen-lock behavior on a physical device if available. Exclude cross-app blocking, shared focus rooms, copied tree art, real-world tree-planting promises, purchases, and cloud accounts.

## 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.