The (office) route group (office-home, office-more, office-chats, office-properties). IMPORTANT: this entire route group is currently gated behind ComingSoonGate — see mobile-company-office-gate in Mobile — Shared. None of the stories below are reachable by real users right now; they're a readiness checklist for when COMPANY_OFFICE_LOCKED flips off, grounded in what's actually built in the code today.
Office Home dashboard stats and trial banner are 100% hardcoded (not live data)
P1
As an office user, I want my dashboard to show real numbers for my active listings, services, views, and messages, so that I can actually gauge how my office's listings are performing instead of looking at numbers that never change.
Flag that office-home.tsx's entire 2x2 stats grid (الإعلانات النشطة / خدمات نشطة / المشاهدات / الرسائل الجديدة, showing the literal strings '3', '3', '700+', '5') and the trial-countdown banner ('يتبقى 14 يومًا') are hardcoded JSX text with no state, hook, or API call feeding them — an identical pattern to company-home.tsx (mobile-company-dashboard-mock-data) — so this is tracked as a known readiness gap for whenever COMPANY_OFFICE_LOCKED flips off.
AC-01Every number on the stats grid and the '14 يومًا' trial banner is confirmed static in the component source, not derived from any request, subscription record, or count.
AC-02Tapping the 'الإعلانات النشطة' and 'خدمات نشطة' cards both currently navigate to office-properties — confirm whether that's intentional or a routing bug once services management exists as its own feature.
AC-03This story's acceptance criteria must be rewritten once real data wiring lands — verify the numbers actually match backend state instead of just confirming they're currently fake.
Test Scenarios
TC-01Compare two different office test accounts with genuinely different amounts of activity and confirm the dashboard numbers are identical between them — if so, that reconfirms they're hardcoded.
TC-02Tap both stat cards that route to office-properties and confirm the destination is the same for both.
TC-03Cross-check against company-home.tsx (mobile-company-dashboard-mock-data) to confirm both dashboards were built from the same hardcoded template.
Office profile 'معاينة' (Preview) and 'مشاركة' (Share) buttons have no onPress handler at all
P2
As an office user, I want to preview how my office profile looks to the public and easily share it, so that I can check my presentation and promote my agency without leaving the app.
Verify that on office-more.tsx's profile header card, the 'معاينة' (Preview) and 'مشاركة' (Share) buttons render with no onPress prop whatsoever — only 'تعديل' (Edit) actually navigates anywhere (to /edit-profile) — an identical gap to company-more.tsx (mobile-company-more-dead-actions) — so this is documented ahead of the gate lifting rather than discovered fresh.
AC-01Tapping 'معاينة' does nothing — no navigation, no modal, no console log, no crash.
AC-02Tapping 'مشاركة' does nothing for the same reason.
AC-03'تعديل' correctly navigates to /edit-profile and is the only one of the three action buttons that's wired up.
Test Scenarios
TC-01Tap all three action buttons on the office profile card in sequence and confirm only Edit does anything.
TC-02Cross-check against company-more.tsx (mobile-company-more-dead-actions) to confirm the two profile cards share the exact same unwired-buttons issue, not two unrelated bugs.
TC-03Flag to product whether Preview/Share are meant to ship in the release that lifts the gate, or were intentionally left unwired for a later phase.
Office has 4 explicit 'قريباً' menu stubs — more than Company's 2 (expected, not a bug)
P2
As an office user, I want to eventually manage deals, auctions, and broker relationships, and see analytics on my listings, so that I can run my agency's operations from within the app.
Confirm that office-more.tsx shows Alert.alert('قريباً', ...) for 4 items — 'الصفقات' (Deals), 'المزادات' (Auctions), 'إدارة الوسطاء' (Broker Management), and 'التحليلات' (Analytics) — twice as many placeholder stubs as company-more.tsx's 2, so this asymmetry is tracked as an intentional difference in each role's roadmap, not an inconsistency to flag as a bug.
AC-01Tapping each of the 4 items shows its corresponding 'قريباً' alert ('ميزة الصفقات ستكون متوفرة قريباً', 'ميزة المزادات ستكون متوفرة قريباً', 'ميزة إدارة الوسطاء ستكون متوفرة قريباً', 'ميزة التحليلات ستكون متوفرة قريباً') and nothing else happens.
AC-02Every other menu item in office-more (chat, favorites, notifications, reviews, plans, account-balance, invoices, settings, about, faq, contact, privacy, terms) navigates to a real shared screen.
AC-03This asymmetry with Company (2 stubs vs. 4) is confirmed intentional per the product roadmap, not a copy-paste gap between the two role's menu screens.
Test Scenarios
TC-01Tap all 4 'قريباً' items in office-more.tsx and confirm each shows its own correctly-worded alert.
TC-02Tap every remaining menu item and confirm all route to a real, working shared screen.
TC-03Cross-check against company-more.tsx's 2-item list (mobile-company-coming-soon-menu-items) to confirm the difference in scope is a deliberate roadmap choice.
Office Properties tab is permanently empty regardless of filter (known gap)
P1
As an office user, I want to see and manage my listed properties, filtered by their publish status, so that I can track what's live, in draft, or archived.
Verify that office-properties.tsx renders its all/published/draft/archived filter pills but the list stays empty no matter which is selected. Track this known frontend/backend wiring gap explicitly and re-verify it once real property data is wired in.
AC-01All 4 filter pills (all/published/draft/archived) render and are tappable.
AC-02The list beneath stays empty for every filter — expected today.
AC-03The screen settles into a clear empty state rather than an infinite spinner or crash.
Test Scenarios
TC-01Tap through all 4 filter pills and confirm each renders the same empty state.
TC-02Navigate to office-properties both from the Office Home stats cards and from wherever else it's reachable, and confirm behavior is identical from both entry points.
TC-03Re-run this check once backend wiring lands and flip the acceptance criteria to expect real data.
Office '+' tab renders a completely blank screen (not even a redirect)
P2
As an office user, I want a clear '+' action to list a new property, so that I have an obvious way to add new listings to my portfolio.
Flag that (office)/add.tsx is a literal `return <View />;` — a blank screen with no content, no redirect, and no action sheet — the identical stub to (company)/add.tsx (mobile-company-add-tab-empty), unlike the individual role's real '+' action sheet, so this genuinely blank screen doesn't get mistaken for a rendering bug once the gate lifts — it is the current implementation as written.
AC-01Tapping the '+' tab as an Office identity renders a blank screen with no visible content or action.
AC-02Nothing crashes and no console error is thrown — it's empty, not unstable.
AC-03This must be revisited before the gate lifts — shipping a genuinely blank tab to real office users would be a real regression, not just a documentation footnote.
Test Scenarios
TC-01Tap the '+' tab as an Office identity and confirm literally nothing renders beyond a blank screen.
TC-02Compare directly against the Individual role's '+' action sheet to make the gap concrete for a ticket.
TC-03Cross-check against (company)/add.tsx (mobile-company-add-tab-empty) to confirm both role stubs are identical, not two independently-introduced gaps.