The layered source tree that exists now

lib/ is organized by technical layer and by feature folders inside screens/. Generated caches and IDE state are not part of the documented source architecture.

mono_vendor/
├─ .gitignore
├─ .metadata
├─ README.md
├─ analysis_options.yaml
├─ analyze_errors.txt
├─ analyze_out.log
├─ pubspec.yaml
├─ pubspec.lock
├─ assets/
│  ├─ logo.png
│  └─ icons/                 app icon, logo, drawer + UI SVGs
├─ lib/
│  ├─ main.dart
│  ├─ core/                   constants, logger, translations, formatting, RTL, presence
│  ├─ models/                 dashboard, AI, bundle, chat, delivery, FAQ, follower, media,
│  │                          notification, order, package tier, product, profile, taxonomy, wallet
│  ├─ providers/              AI quota, locale, theme, auth, dashboard, follower, notification,
│  │                          order, product, wallet
│  ├─ repositories/           translation, AI, auth, bundle, chat, dashboard, delivery, FAQ,
│  │                          follower, media, notification, order, package, product, settings,
│  │                          taxonomy, wallet
│  ├─ screens/                shell, splash, auth, and feature screen folders
│  ├─ services/               Ably chat, Ably notifications, API client, endpoints, FCM
│  ├─ theme/                  app_colors.dart, app_theme.dart
│  └─ widgets/                app bars, buttons, dialogs, drawer, fields, HTML, filters,
│                             search, status, empty, error, and shared UI
├─ android/
├─ ios/
├─ macos/
├─ web/
├─ windows/
└─ test/

Twenty-seven public screens, plus the shell

The class count comes from public classes named *Screen in lib/screens/. Wizard sections, bundle steps, delivery tabs, dialogs, cards, and controllers are internal subviews; they are not additional public screens.

Drawer and internal destination map

Public screen classes

Actual Android capture set

These are the current app captures, not generated mockups. They show the native splash and the current login/registration UI reached on a connected Android device.

Toolchain and target requirements

The lockfile and platform projects define the supported toolchain floor. Both application packages and toolchain constraints have been upgraded to Flutter 3.47.7 and Dart 3.13.5.

Before the first run

• Use Flutter 3.47.7 or newer and a Dart SDK (3.13.5+) compatible with the project constraint.
• For Android, run on an API 23+ device or emulator and configure a reachable API URL.
• For iOS, open the generated Runner.xcworkspace on macOS; no signing team is checked in.
• Do not assume web or Windows parity: the current Dart source contains dart:io dependencies.

Install and launch from the repository

The project is a standard Flutter application rooted at mono_vendor/. Resolve packages from the checked-in lockfile, choose a visible target, and run normally.

cd mono_vendor

flutter pub get

flutter devices

flutter run -d <device-id>

Run sequence

1. Open the mono_vendor project folder in Android Studio or another Flutter-enabled editor.
2. Run flutter pub get; the lockfile resolves 187 packages, including transitives.
3. Confirm the selected device in flutter devices.
4. Run flutter run -d <device-id>. Android Studio can perform the same launch through its Flutter run configuration.
5. Expect SplashScreen, then login or registration when no valid token is restored.

Android Studio evidence

The hero capture is the full-HD project view from the current source. It shows the layered lib/ tree and the active API constant in api_client.dart; use the lightbox to inspect it at full size.

Exact direct declarations and locked versions

pubspec.lock contains 187 packages in total. All direct core packages have been verified and upgraded for Flutter 3.47.7 & Dart 3.13.5.

The API client is fixed to a local development default

lib/services/api_client.dart owns the global Dio client. The active default is the same local LAN HTTP URL shown in the Android Studio capture.

https://example.com/api/v1

MONO_VENDOR / lib/services/api_client.dart FLUTTER

Active file api_client.dart Base URL example.com / api / v1 Capture 1920 × 1080 / Android Studio Transport HTTP / LAN

Current client behavior

• Adds Authorization: Bearer <token> when a token is available.
• Adds X-Locale and Accept-Language from the vendor language preference, defaulting to en.
• Uses a 15-second connect timeout and a 30-second receive timeout. No explicit sendTimeout is configured in the current client.
• Redacts credentials and tokens from request logs and truncates long bodies.
• Resolves relative media paths against the active API base.
• On HTTP 401, clears the token and invokes the logout/redirect callback registered in main.dart.
• Restores vendor_api_base_url from SharedPreferences when present.

Endpoint registry groups

Authentication and translations

Login and registration post credentials or the registration payload to the vendor auth endpoints. Profile updates use PUT /vendor/profile. Language discovery uses GET /languages?scope=mobile; translation bundles use GET /translations/{code} in TranslationRepository.

No hidden environment-variable base URL

The repository has no --dart-define path, no environment-file loader, and no current UI caller for ApiClient.setBaseUrl. Store Settings does not expose a server URL.

How the active URL is selected

1. ApiClient starts with defaultBaseUrl.
2. After initialization, a non-empty vendor_api_base_url value in SharedPreferences overrides it.
3. Otherwise the compiled-in local LAN default remains active.

static const defaultBaseUrl =
    'https://example.com/api/v1';

Transport security flags

Branding, palette, launcher assets, and settings

The app’s real display labels are not identical. Preserve that distinction when changing store metadata, launcher output, screenshots, or documentation.

Primary theme colors

pubspec.yaml declares no font family or bundled font assets. The app uses Flutter theme typography and a small number of explicit monospace contexts.

Launcher icon configuration

flutter_launcher_icons uses assets/icons/app_icon.png and app_icon_foreground.png, with an adaptive background of #059669. Its generation setting says min_sdk_android: 21; the actual Android app currently builds with maxOf(flutter.minSdkVersion, 23). These values serve different purposes and are not interchangeable.

Android FCM is lazy; realtime uses server-issued Ably tokens

main.dart initializes API, theme, locale, and auth providers, but it does not initialize Firebase. Authenticated MainVendorShell binds the notification store, connects Ably notifications, then starts FCM in the background.

main()
  └─ MonoVendorApp
      └─ authenticated MainVendorShell
          ├─ bind VendorNotificationStore
          ├─ connect Ably notification channel
          └─ FirebasePushService.initialize()
              ├─ Android guard
              ├─ high_importance_channel
              ├─ request notification permission
              ├─ register foreground/open/refresh listeners
              └─ register device token

Set up your own Firebase project, step by step

The repository ships with a working google-services.json so the app runs immediately, but that file points at a shared Firebase project. Create your own before you publish. The whole process takes about ten minutes and needs only a free Google account.

1. Create the project. Open console.firebase.google.com, click Add project, give it a name such as mono-vendor, and disable Google Analytics unless you want it. The project finishes creating after you confirm the analytics choice.
2. Add the Android app. On the project overview click the Android icon. Enter the package name — it must match your applicationId character for character, so use com.mono.vendor.app if you have not renamed it yet. Give the app a nickname and download google-services.json.
3. Place the config file. Copy it to android/app/google-services.json, replacing the bundled one. Both the filename and the folder are required by the Google Services Gradle plugin; a wrong path builds fine but throws Default FirebaseApp is not initialized at runtime.
4. Enable Cloud Messaging. In the left sidebar open Build → Cloud Messaging. The Send test message button confirms the project can deliver notifications. Nothing else is required for FCM to work.
5. Leave the channel to the app. The app creates an Android notification channel named high_importance_channel (“Orders and Updates”) at runtime. Do not create a matching channel in the console — the app owns it, and a duplicate console channel is ignored.
6. Rebuild rather than hot reload. Changing google-services.json needs a full rebuild. Stop the app and run flutter run -d <android-device-id> again, adding flutter clean first if the old configuration appears to be cached.

Android push facts

• android/app/google-services.json is tracked and contains the com.mono.vendor.app client. Replace the placeholder values with your own Firebase credentials.
• The Android channel is high_importance_channel, labeled “Orders and Updates”.
• Token registration posts to /vendor/notifications/register-token; logout unregisters through /vendor/notifications/unregister-token.
• A stable vendor_notification_device_id is created and kept in secure storage.
• FirebasePushService.initialize() returns without work on non-Android targets.

Ably chat and notifications

ably_vendor_chat_service.dart and ably_vendor_notification_service.dart request token requests from the backend chat-token endpoint and use Ably auth callbacks. No hard-coded Ably API key is present in the current Dart source.

iOS setup: signing, Firebase, and push notifications

Complete the setup below to take the generated iOS target from local development to a signed build with APNs and Firebase Cloud Messaging. The Flutter shell and bundle identifier are present in the repository; Apple credentials, APNs credentials, and the Firebase iOS configuration are supplied through Xcode, Firebase, and the Apple Developer portal.

1. Prepare Apple and Firebase access

• In the Apple Developer portal, create or select an App ID for com.mono.vendor.app and enable App Push Notifications.
• Create an APNs authentication key and save the .p8 file securely. Record its Key ID and Apple Team ID; do not paste the key or private material into this guide.
• In the Firebase project used by this app, register an iOS app with the exact bundle ID com.mono.vendor.app, then download GoogleService-Info.plist.

2. Resolve Flutter and CocoaPods

flutter pub get
cd ios
pod install
cd ..
open Runner.xcworkspace

The repository does not check in a Podfile. If CocoaPods reports that the file is missing, restore the standard Flutter iOS Podfile for the installed Flutter SDK, review it, and then run pod install. Always open the workspace, not the bare Runner.xcodeproj.

3. Configure signing in Xcode

1. Open ios/Runner.xcworkspace and select the Runner project.
2. Open Signing & Capabilities for the Runner target.
3. Enable Automatically manage signing, select the organization’s Apple Developer team, and confirm the bundle identifier is com.mono.vendor.app.
4. Keep the deployment target at iOS 15.0 or higher, choose a physical iPhone for notification testing, and resolve any signing errors before continuing.

4. Add the Firebase iOS configuration

1. Drag GoogleService-Info.plist into the ios/Runner directory.
2. In Xcode, open the file’s inspector and confirm Target Membership includes Runner.
3. Do not add API keys, APNs private keys, or signing credentials to documentation, source comments, or screenshots.

5. Enable APNs and background delivery

1. In Signing & Capabilities, add the Push Notifications capability to the Runner target.
2. Add Background Modes and enable Remote notifications.
3. In Firebase Console, open Project settings → Cloud Messaging → iOS, upload the APNs .p8 key, and enter its Key ID and Apple Team ID.
4. Build and run on a physical iPhone, allow notifications when prompted, and confirm the app receives a foreground and background test message.

6. Enable the Dart-side iOS path

The current FirebasePushService.initialize() returns immediately unless the platform is Android. For iOS push, change that guard so both Android and iOS continue through the existing Firebase initialization, permission request, foreground handling, and token registration flow. Keep the authenticated lazy initialization in MainVendorShell; do not initialize a second unrelated notification service.

final supportedPlatform = Platform.isAndroid || Platform.isIOS;
if (!supportedPlatform) return;

await Firebase.initializeApp();
// Keep the existing permission, listener, and token flow below.

After the app signs in, verify that the device token is sent to /vendor/notifications/register-token and that logout calls /vendor/notifications/unregister-token. Confirm that the existing high_importance_channel behavior remains unchanged for Android.

7. Build, test, and release

flutter run -d <ios-device-id>
flutter build ios --no-codesign
flutter build ipa --release

• Use flutter build ios --no-codesign as a compile/configuration check before enabling distribution.
• Test login, notification permission, foreground delivery, background delivery, deep links, and logout unregistration on a physical device.
• For TestFlight or the App Store, select the correct team and distribution profile in Xcode, increment the build number, archive the Runner scheme, and validate the IPA before upload.

Build commands and expected targets

Use the normal Flutter commands after package resolution. Select a real device ID rather than assuming an emulator name.

Android debug run

flutter pub get

flutter run -d <android-device-id>

flutter build apk --debug

Android application ID and namespace are both com.mono.vendor.app. The debug build can use the bundled Google services client and the local HTTP development URL.

Change the application ID before you publish

Both platforms ship with the identifier com.mono.vendor.app, which is a real reverse-domain identifier and builds fine. Google Play and the App Store each require the identifier to belong to the account publishing the app, so replace it with your own before your first upload. Pick a domain you own — for example com.yourcompany.mono.vendor.

Renaming the Android package also means moving the Kotlin sources to match: android/app/src/main/kotlin/com/mono/vendor/app/MainActivity.kt becomes android/app/src/main/kotlin/com/yourcompany/mono/vendor/app/MainActivity.kt, and its package line must change too. Forget this and the build fails with a Namespace 'com.mono.vendor.app' is not a valid namespace error pointing at the manifest.

Android SDK levels are pinned deliberately

android/app/build.gradle.kts sets compileSdk = 37 and pins targetSdk = 36 as an explicit integer rather than flutter.targetSdkVersion. The Flutter value resolves to 35 on Flutter 3.29 and newer, which is below the current Google Play submission requirement, so the explicit number keeps your uploads accepted as you upgrade Flutter. minSdk stays at maxOf(flutter.minSdkVersion, 23) because Firebase Messaging and flutter_local_notifications need a modern minimum.

iOS run

open ios/Runner.xcworkspace

On macOS, open the workspace, select a development team and runnable signing configuration in Xcode, then complete the iOS setup section before testing notifications.

Other generated targets

macOS declares deployment target 12.0. Web and Windows folders are generated Flutter targets, but mobile-only imports mean the current source does not verify web support. Treat any such build as an engineering task, not an existing guarantee.

Release blockers visible in source

The repository is runnable source, but it does not contain production signing or production transport configuration. A release build command can still be issued, yet that is not the same as a store-ready artifact.

Add work along the project’s actual layers

Mono Vendor uses repositories behind providers, with public screens selected by the shell. Extend the current layers rather than introducing a second navigation or state system.

Source-backed extension sequence

1. Add or update the data shape under lib/models/.
2. Add the server path to lib/services/api_endpoints.dart when a new endpoint is required.
3. Implement request, response parsing, and error behavior in the matching lib/repositories/ class.
4. Expose loading, mutation, and refresh state through a ChangeNotifier in lib/providers/.
5. Register a persistent provider in the MultiProvider list in lib/main.dart when its lifetime is app-wide.
6. Build the public UI under the appropriate lib/screens/ feature folder and reuse lib/widgets/ components.
7. For a shell destination, add an AppConstants key, drawer selection, title mapping, and _buildActiveBody() case in MainVendorShell.
8. Add focused tests under test/ for parsing, provider behavior, or widget output.

Screen
  └─ Provider<ChangeNotifier>
      └─ Repository
          ├─ ApiEndpoints path
          ├─ ApiClient / service
          └─ Model parsing

Worked example: add a wishlist feature module

Here is the sequence above applied to one concrete feature, so you can copy the shape rather than infer it. The example adds a vendor wishlist backed by a GET /vendor/wishlist endpoint.

1. Model — lib/models/vendor_wishlist_item.dart. A plain data class with fromJson, matching the field names the endpoint returns.
2. Endpoint — lib/services/api_endpoints.dart. Add a static path constant alongside the existing vendor routes; never inline a URL in a repository.
3. Repository — lib/repositories/wishlist_repository.dart. Takes an ApiClient, calls the endpoint, maps the response into the model, and returns typed data or throws — no widget types.
4. Provider — lib/providers/wishlist_provider.dart. A ChangeNotifier holding items, isLoading, and error, with load() and toggle(item). Register it in the MultiProvider list in lib/main.dart if it should survive navigation.
5. Screen — lib/screens/wishlist/wishlist_screen.dart. A public *Screen class that watches the provider and renders loading, empty, error, and populated states. Reuse existing lib/widgets/ cards instead of restyling.
6. Navigation. Push the screen with Navigator.push from an existing entry point. Only touch MainVendorShell if the feature is a new permanent drawer destination, in which case add the AppConstants key, the drawer item, the title mapping, and the _buildActiveBody() case together.

lib/
├─ models/vendor_wishlist_item.dart        ← new
├─ services/api_endpoints.dart             ← add wishlist path
├─ repositories/wishlist_repository.dart   ← new
├─ providers/wishlist_provider.dart        ← new
├─ screens/wishlist/wishlist_screen.dart   ← new
└─ widgets/wishlist_tile.dart              ← new, if reused

main.dart                                  ← register provider (if app-wide)

Communication exists; a support-ticket system does not

Mono Vendor communicates with customers through the unified chat list/thread, follower conversation entry, notifications, and server-authorized Ably sessions. Store Settings exposes account and logout actions. These are the source-backed communication paths.

Known source limitations

• The active API is a local cleartext LAN URL.
• Android release mode is debug-signed.
• iOS requires developer-provided Apple signing, APNs, Firebase plist, and Dart push initialization; the setup steps are documented above.
• The app targets Android and iOS; mobile-only dart:io imports prevent a web build.
• No source-backed support-ticket workflow or support contact exists.

Add your own credentials, signing keys, and production API base URL before you publish. They are intentionally left out of the source package so your keys stay private.