Back to Details

android-saas-planning

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Android SaaS Planning Skill

Android SaaS规划技能

Generate a complete, implementation-ready documentation suite for a native Android app that serves as a mobile client for an existing web-based SaaS system.
为作为现有基于Web的SaaS系统移动客户端的原生Android应用生成一套完整的、可直接实施的文档套件。

When to Use

适用场景

  • Building a new native Android app for an existing web SaaS
  • Porting a web application's functionality to Android
  • Planning a mobile-first or mobile-companion SaaS experience
  • Scoping MVP features for a mobile client
  • Creating a structured handoff document for Android developers
  • 为现有Web SaaS构建新的原生Android应用
  • 将Web应用的功能移植到Android平台
  • 规划移动优先或移动配套的SaaS体验
  • 确定移动客户端的MVP功能范围
  • 为Android开发人员创建结构化的交接文档

When NOT to Use

不适用场景

  • Building a standalone mobile app with no web backend
  • Cross-platform (Flutter/React Native) — this skill targets native Android (Kotlin + Jetpack Compose)
  • Adding a WebView wrapper — this skill targets fully native screens
  • Incremental feature additions to an existing Android app
  • 构建无Web后端的独立移动应用
  • 跨平台（Flutter/React Native）——本技能针对原生Android（Kotlin + Jetpack Compose）
  • 添加WebView包装器——本技能针对全原生界面
  • 为现有Android应用增量添加功能

Prerequisites — Context the Agent MUST Gather

前置条件——Agent必须收集的信息

Before generating ANY documents, the agent must have or discover:
在生成任何文档之前，Agent必须具备或获取以下信息：

1. SaaS Profile (Required)

1. SaaS概况（必填）

FieldWhat to Find
Product nameBrand name and domain
DomainERP, CRM, POS, Healthcare, Fintech, etc.
Target marketRegion, language, currency, payment methods
Backend stackPHP/MySQL, Node/PostgreSQL, Django, Laravel, etc.
API base URLPer environment (see standard 3-env setup below)
Auth modelJWT, OAuth2, session-based, API keys
Multi-tenancyTenant ID in JWT, subdomain, DB-per-tenant
字段需收集的信息
产品名称品牌名称和域名
业务领域ERP、CRM、POS、医疗、金融科技等
目标市场地区、语言、货币、支付方式
后端技术栈PHP/MySQL、Node/PostgreSQL、Django、Laravel等
API基础URL各环境的URL（见下文标准三环境配置）
认证模型JWT、OAuth2、基于会话、API密钥
多租户模式JWT中的租户ID、子域名、按租户分库

2. Module Inventory (Required)

2. 模块清单（必填）

Audit the web app to identify all modules. For each module determine:
  • Name and description (what the module does)
  • Mobile relevance — does it make sense on a phone? (e.g., complex admin panels may not)
  • MVP classification — P0 (ship without), P1 (within 2 sprints), P2 (future)
  • Offline requirement — must it work offline?
  • API endpoints — existing endpoints that serve this module
审核Web应用以识别所有模块。针对每个模块确定：
  • 名称和描述（模块功能）
  • 移动端相关性——在手机上使用是否合理？（例如，复杂的管理面板可能不适合）
  • MVP分类——P0（必须包含）、P1（2个迭代内交付）、P2（未来规划）
  • 离线需求——是否必须支持离线使用？
  • API端点——为该模块提供服务的现有端点

3. Feature Scope (Required — Accept from User)

3. 功能范围（必填——由用户指定）

The user may request a subset of modules. Respect their selection:
  • If the user specifies "only POS and Inventory" — plan only those modules
  • If the user says "full app" — plan all mobile-relevant modules
  • Always include Auth and Dashboard as baseline modules unless explicitly excluded
用户可能会要求仅规划部分模块。需遵循其选择：
  • 如果用户指定“仅POS和库存模块”——仅规划这些模块
  • 如果用户说“完整应用”——规划所有与移动端相关的模块
  • 除非明确排除，否则始终包含认证和仪表盘作为基础模块

4. Technical Constraints (Discover or Ask)

4. 技术约束（需确认或询问）

  • Minimum Android API level (default: API 29 / Android 10)
  • Apps must be tested against the latest stable Android release
  • Max APK size (default: 50MB)
  • Offline requirements (none / basic caching / full offline-first)
  • Hardware peripherals (Bluetooth printer, barcode scanner, NFC)
  • Biometric authentication (fingerprint, face)
  • Push notifications (FCM)
  • Local dev networking: emulator must connect to WAMP via the host machine's static LAN IP (not 
    localhost
    )
  • 最低Android API级别（默认：API 29 / Android 10）
  • 应用必须针对最新稳定版Android进行测试
  • APK最大体积（默认：50MB）
  • 离线需求（无/基础缓存/完全离线优先）
  • 硬件外设（蓝牙打印机、条形码扫描器、NFC）
  • 生物识别认证（指纹、面部识别）
  • 推送通知（FCM）
  • 本地开发网络：模拟器必须通过主机的静态LAN IP连接到WAMP（而非
    localhost
    ）

5. Standard Backend Environment Setup

5. 标准后端环境配置

All SaaS companion apps target these three backend environments:
EnvironmentOSDatabaseAPI Base URL Pattern
DevelopmentWindows 11 (WAMP)MySQL 8.4.7
http://{LAN_IP}:{port}/{project}/api/
StagingUbuntu VPSMySQL 8.x
https://staging.{domain}/api/
ProductionDebian VPSMySQL 8.x
https://{domain}/api/
Use Gradle build flavors to manage per-environment base URLs. All backends use 
utf8mb4_unicode_ci
collation and MySQL 8.x. Always plan API contracts that work identically across all environments.
所有SaaS配套应用均针对以下三个后端环境：
环境操作系统数据库API基础URL格式
开发环境Windows 11（WAMP）MySQL 8.4.7
http://{LAN_IP}:{port}/{project}/api/
预发布环境Ubuntu VPSMySQL 8.x
https://staging.{domain}/api/
生产环境Debian VPSMySQL 8.x
https://{domain}/api/
使用Gradle构建变体来管理各环境的基础URL。所有后端均使用
utf8mb4_unicode_ci
排序规则和MySQL 8.x。始终规划在所有环境中功能一致的API契约。

Phase 1 Bootstrap Pattern (MANDATORY)

第一阶段启动模式（强制要求）

Every Android SaaS app MUST start with Phase 1: Login + Dashboard + Empty Tabs.
This is the proven foundation pattern. Before planning any business features, the first implementation phase always delivers:
每个Android SaaS应用必须从第一阶段开始：Login + Dashboard + Empty Tabs.
这是经过验证的基础模式。在规划任何业务功能之前，第一个实施阶段必须交付以下内容：

Phase 1 Scope (Non-Negotiable)

第一阶段范围（不可协商）

  1. JWT Authentication — Login/logout with the SaaS backend (access tokens + refresh token rotation + breach detection)
  2. Dashboard — Real KPI stats from the backend, offline-first with Room caching, pull-to-refresh
  3. Bottom Navigation — Maximum 5 major section tabs (e.g., Home, Sales, Network, Knowledge, Training). Non-dashboard tabs show "Coming Soon" placeholder screens
  4. Core Infrastructure — Hilt DI modules, Retrofit + OkHttp interceptor chain (auth + tenant + logging), encrypted token storage, network monitor, Room database, Material 3 theme
  5. Backend Endpoints — Mobile login, token refresh, logout, and dashboard stats API endpoints with dual auth middleware (JWT for mobile + session for web backward compatibility)
  6. Unit Tests — Full test coverage for ViewModels, Use Cases, Repositories, Interceptors
  1. JWT Authentication — 与SaaS后端进行登录/登出（访问令牌 + 刷新令牌轮换 + breach检测）
  2. Dashboard — 来自后端的实时KPI统计，采用Room缓存的离线优先模式，支持下拉刷新
  3. 底部导航 — 最多5个主要板块标签（例如：首页、销售、网络、知识库、培训）。非仪表盘标签显示“即将上线”占位界面
  4. 核心基础设施 — Hilt DI模块、Retrofit + OkHttp拦截器链（认证 + 租户 + 日志）、加密令牌存储、网络监控、Room数据库、Material 3主题
  5. 后端端点 — 移动端登录、令牌刷新、登出和仪表盘统计API端点，支持双重认证中间件（JWT for mobile + session for web backward compatibility）
  6. 单元测试 — 对ViewModel、Use Cases、Repositories、Interceptors进行全面测试覆盖

Phase 1 Deliverables

第一阶段交付物

ComponentAndroidBackend
AuthLoginScreen, LoginViewModel, AuthRepository, AuthApiService, TokenManager, interceptorsmobile-login.php, mobile-refresh.php, mobile-logout.php, MobileAuthHelper, ApiAuthMiddleware
DashboardDashboardScreen, DashboardViewModel, DashboardRepository, Room cachedashboard-stats.php (dual auth)
Navigation5-tab BottomBar, NavGraph, PlaceholderScreen for future tabs—
InfrastructureDI modules, theme, encrypted prefs, network monitorrefresh_tokens table, .env loading
Tests40+ unit tests across all layerscurl/Postman endpoint verification
组件Android后端
AuthLoginScreen、LoginViewModel、AuthRepository、AuthApiService、TokenManager、拦截器mobile-login.php、mobile-refresh.php、mobile-logout.php、MobileAuthHelper、ApiAuthMiddleware
DashboardDashboardScreen、DashboardViewModel、DashboardRepository、Room缓存dashboard-stats.php（双重认证）
Navigation5-tab BottomBar、NavGraph、未来标签的PlaceholderScreen—
InfrastructureDI模块、主题、加密偏好设置、网络监控refresh_tokens表、.env加载
Tests各层共40+单元测试curl/Postman端点验证

Why Phase 1 First

为何先做第一阶段

  • Proves the entire vertical slice works (UI → ViewModel → UseCase → Repository → API → Backend → Database)
  • Establishes all infrastructure patterns that every future feature reuses
  • Gives the user a working app they can install and log into immediately
  • Uncovers backend integration issues early (auth, CORS, env loading, session handling)
  • Creates the navigation skeleton that future phases fill in
  • 验证整个垂直链路是否可行（UI → ViewModel → UseCase → Repository → API → 后端 → 数据库）
  • 建立所有未来功能将复用的基础设施模式
  • 为用户提供可立即安装并登录的可用应用
  • 尽早发现后端集成问题（认证、CORS、环境加载、会话处理）
  • 创建未来阶段将填充内容的导航框架

Tab Selection (Max 5)

标签选择（最多5个）

When auditing modules, group them into a maximum of 5 bottom navigation tabs. Common patterns:
App TypeTab 1Tab 2Tab 3Tab 4Tab 5
MLM/DistributorHomeSalesNetworkKnowledgeTraining
ERP/BusinessHomeSalesInventoryReportsSettings
CRMHomeContactsDealsTasksSettings
POS/RetailHomeSalesProductsCustomersReports
HealthcareHomePatientsScheduleRecordsSettings
FintechHomeTransactionsCardsSavingsSettings
If more than 5 sections exist, nest sub-sections within tabs or use drawer navigation for secondary items.
审核模块时，将其分组为最多5个底部导航标签。常见模式：
应用类型标签1标签2标签3标签4标签5
MLM/分销商首页销售网络知识库培训
ERP/企业应用首页销售库存报表设置
CRM首页联系人商机任务设置
POS/零售首页销售商品客户报表
医疗首页患者日程病历设置
金融科技首页交易卡片储蓄设置
如果板块超过5个，可将子板块嵌套在标签内，或使用抽屉导航放置次要项目。

Phase 1 Implementation Plan Structure

第一阶段实施计划结构

The Phase 1 plan MUST be structured as 11 sections (following the proven pattern):
docs/plans/phase-1-login-dashboard/
├── 00-build-variants.md          # Dev/Staging/Prod flavors
├── 01-project-bootstrap.md       # Gradle, manifest, strings, packages
├── 02-backend-api.md             # PHP JWT endpoints + DB migration
├── 03-core-infrastructure.md     # DI, security, network, interceptors
├── 04-authentication-feature.md  # Login vertical slice (DTO→Entity→Domain)
├── 05-dashboard-feature.md       # Dashboard with offline-first Room caching
├── 06-navigation-tabs.md         # Bottom nav + placeholder screens
├── 07-room-database.md           # Database class, converters, module
├── 08-theme-ui-components.md     # Material 3 theme + reusable components
├── 09-testing.md                 # 40+ unit tests across all layers
└── 10-verification.md            # Backend curl tests + Android manual checklist
第一阶段计划必须按照以下11个部分构建（遵循验证后的模式）：
docs/plans/phase-1-login-dashboard/
├── 00-build-variants.md          # Dev/Staging/Prod flavors
├── 01-project-bootstrap.md       # Gradle、清单、字符串、包结构
├── 02-backend-api.md             # PHP JWT端点 + 数据库迁移
├── 03-core-infrastructure.md     # DI、安全、网络、拦截器
├── 04-authentication-feature.md  # 登录垂直链路（DTO→Entity→Domain）
├── 05-dashboard-feature.md       # 带离线优先Room缓存的仪表盘
├── 06-navigation-tabs.md         # 底部导航 + 占位界面
├── 07-room-database.md           # 数据库类、转换器、模块
├── 08-theme-ui-components.md     # Material 3主题 + 可复用组件
├── 09-testing.md                 # 各层共40+单元测试
└── 10-verification.md            # 后端curl测试 + Android手动检查清单

Phase 2+ Planning

第二及后续阶段规划

Only after Phase 1 is fully implemented, tested, and verified E2E should Phase 2 features be planned. Phase 2 fills in the placeholder tabs with real functionality, reusing all the infrastructure from Phase 1.
只有在第一阶段完全实现、测试并通过端到端验证后，才能规划第二阶段的功能。第二阶段将用实际功能填充占位标签，复用第一阶段的所有基础设施。

Document Generation Workflow

文档生成流程

Generate documents one at a time, in order. Each document builds on the previous.
按顺序逐个生成文档。每个文档基于前一个文档构建。

Step 1: Audit the Existing Web App

步骤1：审核现有Web应用

Before writing any documents:
  1. Read the codebase — scan API routes, controllers, models, database schema
  2. Identify modules — group endpoints by business domain
  3. Map data models — understand entities, relationships, field types
  4. Note auth flow — how login, tokens, permissions, and multi-tenancy work
  5. Find existing docs — API docs, database docs, architecture docs
  6. Present findings to the user for confirmation before proceeding
编写任何文档之前：
  1. 阅读代码库——扫描API路由、控制器、模型、数据库架构
  2. 识别模块——按业务领域分组端点
  3. 映射数据模型——理解实体、关系、字段类型
  4. 记录认证流程——登录、令牌、权限和多租户的工作方式
  5. 查找现有文档——API文档、数据库文档、架构文档
  6. 向用户展示发现结果并确认后再继续

Step 2: Generate Documents in Order

步骤2：按顺序生成文档

OrderDocumentIndex FileSub-files Directory
1README
README.md
—
2Product Requirements
01_PRD.md
prd/
3Software Requirements
02_SRS.md
srs/
4Software Design
03_SDS.md
sds/
5API Contract
04_API_CONTRACT.md
api-contract/
6User Journeys
05_USER_JOURNEYS.md
— (or split if >500 lines)
7Testing Strategy
06_TESTING_STRATEGY.md
testing/
8Release Plan
07_RELEASE_PLAN.md
—
顺序文档名称索引文件子文件目录
1README
README.md
—
2产品需求文档
01_PRD.md
prd/
3软件需求文档
02_SRS.md
srs/
4软件设计文档
03_SDS.md
sds/
5API契约
04_API_CONTRACT.md
api-contract/
6用户旅程
05_USER_JOURNEYS.md
—（若超过500行可拆分）
7测试策略
06_TESTING_STRATEGY.md
testing/
8发布计划
07_RELEASE_PLAN.md
—

Step 3: Review and Refine

步骤3：审核与优化

After all documents are generated, verify:
  • All module requirements trace to API endpoints
  • Room entities match backend data models
  • Auth flow matches the web app's actual auth implementation
  • Offline sync strategy covers all P0 modules
  • No fabricated endpoints — every endpoint references real backend routes
生成所有文档后，验证以下内容：
  • 所有模块需求均关联到API端点
  • Room实体与后端数据模型匹配
  • 认证流程与Web应用的实际认证实现一致
  • 离线同步策略覆盖所有P0模块
  • 无虚构端点——每个端点均引用真实的后端路由

Formatting Rules (Strict)

格式规则（严格遵守）

  1. 500-line max per markdown file — split into sub-files if exceeded
  2. Numbered requirement IDs — 
    FR-AUTH-001
    , 
    NFR-PERF-003
    , etc.
  3. Real Kotlin code — not pseudocode; include actual imports and versions
  4. JSON examples — complete request/response bodies for every endpoint
  5. ASCII diagrams — flow charts, architecture layers, sync flows
  6. Markdown tables — for requirements, endpoints, metrics, comparisons
  7. Cross-references — link between documents liberally
  8. Back-links — every sub-file links back to its parent index
  9. Navigation — every index links to all its sub-files with descriptions
  1. 每个Markdown文件最多500行——若超过则拆分为子文件
  2. 编号需求ID——
    FR-AUTH-001
    、
    NFR-PERF-003
    等
  3. 真实Kotlin代码——而非伪代码；包含实际导入和版本
  4. JSON示例——每个端点的完整请求/响应体
  5. ASCII图表——流程图、架构层、同步流程
  6. Markdown表格——用于需求、端点、指标、对比
  7. 交叉引用——在文档间大量添加链接
  8. 回链——每个子文件均链接回其父索引
  9. 导航——每个索引均链接到所有子文件并附带描述

Tech Stack Defaults

技术栈默认值

Use these unless the project context requires alternatives:
LayerTechnologyVersion
LanguageKotlin2.0+
UIJetpack Compose + Material 3BOM 2024.06+
IconsCustom PNGs (no icon libraries)Use placeholders + PROJECT_ICONS.md
ReportsTable-first for >25 rowsUse android-report-tables
ArchitectureMVVM + Clean Architecture—
DIDagger Hilt2.51+
NetworkingRetrofit + OkHttp + Moshi2.11+ / 4.12+
Local DBRoom2.6+
AsyncCoroutines + Flow1.8+
BackgroundWorkManager2.9+
NavigationNavigation Compose2.7+
Image LoadingCoil2.6+
ChartingVico (Compose-first)Use guide
SecurityEncryptedSharedPreferences, BiometricPromptAndroidX
LoggingTimber5.0+
TestingJUnit 5, MockK, Turbine, Compose UI Testing—
CI/CDGitHub Actions—
除非项目上下文要求替代方案，否则使用以下技术栈：
层级技术版本
语言Kotlin2.0+
UIJetpack Compose + Material 3BOM 2024.06+
图标自定义PNG（不使用图标库）使用占位符 + PROJECT_ICONS.md
报表超过25行时优先使用表格使用android-report-tables
架构MVVM + Clean Architecture—
DIDagger Hilt2.51+
网络Retrofit + OkHttp + Moshi2.11+ / 4.12+
本地数据库Room2.6+
异步处理Coroutines + Flow1.8+
后台任务WorkManager2.9+
导航Navigation Compose2.7+
图片加载Coil2.6+
图表Vico（Compose优先）参考指南
安全EncryptedSharedPreferences、BiometricPromptAndroidX
日志Timber5.0+
测试JUnit 5、MockK、Turbine、Compose UI测试—
CI/CDGitHub Actions—

Document Content Requirements

文档内容要求

Detailed templates for each document are in 
references/document-templates.md
. Architecture and code patterns are in 
references/architecture-patterns.md
. API integration patterns are in 
references/api-integration-patterns.md
.
各文档的详细模板位于
references/document-templates.md
。 架构和代码模式位于
references/architecture-patterns.md
。 API集成模式位于
references/api-integration-patterns.md
。

Quick Reference — What Each Document Must Contain

快速参考——各文档必须包含的内容

01_PRD — Vision, personas (3-5), user stories (5+ per module), MVP scope with release phases, competitive analysis, success metrics, risk register, glossary
02_SRS — Numbered functional requirements (10+ per core module), non-functional requirements (performance, security, offline, accessibility, localization), Room entity definitions, traceability matrix
03_SDS — Architecture layers, complete Gradle config, project structure, Hilt modules, security implementation (cert pinning, encrypted storage, biometrics, ProGuard), offline sync (Room DAOs, SyncWorker, conflict resolution, staleness budgets), networking (Retrofit services, interceptors, token refresh), CI/CD workflows
04_API_CONTRACT — Base URLs, auth model, JWT structure, every endpoint with method + path + request JSON + response JSON + validation rules + error responses, pagination model, rate limits, error code reference
05_USER_JOURNEYS — 8-12 journeys with ASCII flow diagrams, step-by-step breakdowns, error paths, offline behavior. Must include: first-time setup, login, primary transaction, offline transaction, search, dashboard, error recovery
06_TESTING_STRATEGY — Test pyramid (60/25/10/5), unit test examples (ViewModel with Turbine, UseCase, Repository), UI test examples (Compose), integration tests (MockWebServer, Room), security tests, performance benchmarks, CI gates, test data fixtures
07_RELEASE_PLAN — Play Store setup, signing strategy, release channels with staged rollout, versioning, privacy policy checklist, app store listing, in-app update strategy, release checklist, rollback procedure, post-launch monitoring
01_PRD——愿景、用户角色（3-5个）、用户故事（每个模块5+个）、分阶段的MVP范围、竞品分析、成功指标、风险登记册、术语表
02_SRS——编号的功能需求（每个核心模块10+个）、非功能需求（性能、安全、离线、可访问性、本地化）、Room实体定义、需求追溯矩阵
03_SDS——架构层、完整Gradle配置、项目结构、Hilt模块、安全实现（证书固定、加密存储、生物识别、ProGuard）、离线同步（Room DAOs、SyncWorker、冲突解决、过期策略）、网络（Retrofit服务、拦截器、令牌刷新）、CI/CD工作流
04_API_CONTRACT——基础URL、认证模型、JWT结构、每个端点的方法+路径+请求JSON+响应JSON+验证规则+错误响应、分页模型、速率限制、错误代码参考
05_USER_JOURNEYS——8-12个用户旅程，附带ASCII流程图、分步拆解、错误路径、离线行为。必须包含：首次设置、登录、主要交易、离线交易、搜索、仪表盘、错误恢复
06_TESTING_STRATEGY——测试金字塔（60/25/10/5）、单元测试示例（带Turbine的ViewModel、Use Cases、Repositories）、UI测试示例（Compose）、集成测试（MockWebServer、Room）、安全测试、性能基准、CI门禁、测试数据夹具
07_RELEASE_PLAN——Play Store设置、签名策略、带分阶段发布的发布渠道、版本控制、隐私政策检查清单、应用商店列表、应用内更新策略、发布检查清单、回滚流程、上线后监控

Adaptation Rules

适配规则

Partial Module Selection

部分模块选择

When the user requests only specific modules:
  1. Still generate ALL 7 documents, but scope content to selected modules
  2. Auth module is always included (required for any authenticated app)
  3. Dashboard adapts to show only KPIs relevant to selected modules
  4. API Contract only documents endpoints for selected modules
  5. User Journeys only cover flows for selected modules
  6. Room entities only include tables needed by selected modules
当用户仅要求规划特定模块时：
  1. 仍需生成全部7份文档，但内容范围限定为所选模块
  2. 始终包含认证模块（任何需认证的应用都需要）
  3. 仪表盘调整为仅显示与所选模块相关的KPI
  4. API契约仅记录所选模块的端点
  5. 用户旅程仅覆盖所选模块的流程
  6. Room实体仅包含所选模块所需的表

No Offline Requirement

无离线需求

If the user says offline support is not needed:
  1. Remove 
    sds/04-offline-sync.md
    entirely
  2. Simplify Repository pattern (no local-first fallback)
  3. Remove SyncWorker and WorkManager sync setup
  4. Remove offline-related NFRs from SRS
  5. Remove offline user journeys
  6. Keep Room for caching only (not as offline data store)
如果用户表示不需要离线支持：
  1. 完全移除
    sds/04-offline-sync.md
  2. 简化Repository模式（无本地优先回退）
  3. 移除SyncWorker和WorkManager同步设置
  4. 从SRS中移除离线相关的非功能需求
  5. 移除离线用户旅程
  6. 仅保留Room用于缓存（而非作为离线数据存储）

Module-Gated vs All-Inclusive

模块Gated vs 全包含

If modules are subscription-gated:
  • Add module unlock system to SDS (feature flags, ModuleAccessManager)
  • Add module discovery journey to User Journeys
  • Add locked-module UI patterns (upgrade prompts, feature previews)
If all modules are available to all users:
  • Remove module gating from SDS
  • Remove module discovery journey
  • Gate features by role/permission only
如果模块是订阅Gated：
  • 在SDS中添加模块解锁系统（功能标志、ModuleAccessManager）
  • 在用户旅程中添加模块发现流程
  • 添加锁定模块的UI模式（升级提示、功能预览）
如果所有模块对所有用户开放：
  • 从SDS中移除模块Gating
  • 移除模块发现旅程
  • 仅按角色/权限限制功能

Regional Customization

区域定制

Adapt to target market:
  • East Africa: M-Pesa/Mobile Money, UGX/KES/TZS, Swahili/English, low-bandwidth optimization
  • West Africa: Paystack, NGN/GHS, French/English/Hausa, USSD fallback
  • Southeast Asia: GrabPay/GCash, local currencies, multi-script support
  • Global: Stripe, multi-currency, broad language support
根据目标市场调整：
  • 东非：M-Pesa/移动货币、UGX/KES/TZS、斯瓦希里语/英语、低带宽优化
  • 西非：Paystack、NGN/GHS、法语/英语/豪萨语、USSD回退
  • 东南亚：GrabPay/GCash、本地货币、多脚本支持
  • 全球：Stripe、多货币、多语言支持

Quality Checklist (Run After All Documents)

质量检查清单（所有文档生成后执行）

  • Every FR traces to at least one API endpoint
  • Every API endpoint has complete request/response JSON
  • Every Room entity maps to a backend data model
  • Auth flow matches the web app's actual implementation
  • All Kotlin code compiles conceptually (correct imports, types, annotations)
  • No file exceeds 500 lines
  • All sub-files have back-links to parent index
  • All indexes link to all sub-files
  • Requirement IDs are unique and sequential
  • Version numbers for libraries are realistic and compatible
  • Personas reflect the actual target market
  • Success metrics have specific numeric targets
  • Release plan includes rollback procedure
  • 每个功能需求均关联到至少一个API端点
  • 每个API端点均有完整的请求/响应JSON
  • 每个Room实体均与后端数据模型映射
  • 认证流程与Web应用的实际实现一致
  • 所有Kotlin代码在概念上可编译（正确的导入、类型、注解）
  • 无文件超过500行
  • 所有子文件均有回链到父索引
  • 所有索引均链接到所有子文件
  • 需求ID唯一且连续
  • 库的版本号现实且兼容
  • 用户角色反映实际目标市场
  • 成功指标有具体的数值目标
  • 发布计划包含回滚流程

Cross-Skill References

跨技能参考

Load these skills alongside for deeper implementation guidance:
  • android-development
    — Kotlin/Android coding standards
  • android-tdd
    — Test-driven development workflow
  • android-data-persistence
    — Room, DataStore, offline-first patterns
  • jetpack-compose-ui
    — Compose UI standards and Material 3
  • dual-auth-rbac
    — Authentication and permission system
  • api-error-handling
    — API error response patterns
  • modular-saas-architecture
    — Module toggle and subscription gating
  • multi-tenant-saas-architecture
    — Tenant isolation patterns
可同时加载以下技能以获取更深入的实施指导：
  • android-development
    ——Kotlin/Android编码标准
  • android-tdd
    ——测试驱动开发流程
  • android-data-persistence
    ——Room、DataStore、离线优先模式
  • jetpack-compose-ui
    ——Compose UI标准和Material 3
  • dual-auth-rbac
    ——认证和权限系统
  • api-error-handling
    ——API错误响应模式
  • modular-saas-architecture
    ——模块切换和订阅Gating
  • multi-tenant-saas-architecture
    ——租户隔离模式