Back to Details

assess-react-native-migration

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Assess React Native Migration

React Native迁移评估

Produce a read-only migration decision. Diagnose the product and delivery system; do not execute the migration.
生成只读的迁移决策。诊断产品与交付系统；不执行迁移操作。

Establish Product Scope

确定产品范围

Run the assessment from a workspace that exposes as many production client codebases as possible. The current checkout is not evidence that it contains the whole product.
Before assessing readiness:
  1. Inspect the current repository and every workspace root available to the agent.
  2. Infer supported client platforms from product documentation, CI, release configuration, workspace manifests, submodules, and references to sibling repositories.
  3. Locate each production client codebase, including separate native iOS and Android repositories, app variants, and any web client relevant to staffing or proposed code sharing.
  4. Record a platform inventory with the client, repository or path, evidence of product membership, and access status.
When iOS and Android are both supported, inspect both native codebases before recommending a path. If a codebase remains unavailable, mark its evidence 
unknown
, state that the assessment covers only the accessible platforms, and lower confidence accordingly. Do not infer that a platform is unsupported merely because its project is absent from the current repository.
Scope gate: every supported production client is listed, and each codebase is accessible, explicitly unavailable, or confirmed not to exist.
从可暴露尽可能多生产客户端代码库的工作区开展评估。当前检出的代码并不代表其包含完整产品。
评估就绪性之前：
  1. 检查当前代码库以及Agent可访问的所有工作区根目录。
  2. 从产品文档、CI、发布配置、工作区清单、子模块以及对同级代码库的引用中推断支持的客户端平台。
  3. 定位每个生产客户端代码库，包括独立的原生iOS和Android代码库、应用变体，以及任何与人员配置或拟议代码共享相关的Web客户端。
  4. 记录平台清单，包含客户端、代码库或路径、产品归属证据以及访问状态。
当同时支持iOS和Android时，在推荐迁移路径前需检查两个原生代码库。若某代码库仍不可访问，标记其证据为
unknown
，说明评估仅覆盖可访问平台，并相应降低置信度。不可仅因当前代码库中不存在某平台项目，就推断该平台不受支持。
范围关卡： 所有受支持的生产客户端均已列出，且每个代码库要么可访问、要么明确不可用、要么确认不存在。

First Response Gate

首次响应关卡

When the scope gate has not passed, the first response must be exactly:
markdown
**Question:** Where can I access the production codebase for each client platform this product supports, including iOS and Android if both exist?

**Why it matters:** A migration path based on only one platform can miss native dependencies, product behavior, and delivery constraints that change the decision.
After the scope gate passes, grill rather than survey when repository evidence is unavailable.
If the measurable migration driver is unknown, the first response must be exactly:
markdown
**Question:** What measurable delivery or business problem should a React Native migration solve?

**Why it matters:** This determines whether migration is relevant and which outcomes the assessment must test.
If the driver is already known, ask only the next highest-impact unknown using the same two-line shape. End the turn immediately after the question and reason. Do not add a preamble, questionnaire, recommendation, or implementation guidance.
当范围关卡未通过时，首次响应必须严格为：
markdown
**问题：** 我可以从何处访问该产品支持的每个客户端平台的生产代码库？若同时存在iOS和Android平台，请一并说明。

**重要性：** 仅基于单一平台制定的迁移路径可能会忽略原生依赖、产品行为和交付约束，从而改变决策结果。
范围关卡通过后，当代码库证据不可用时，采用追问而非调研的方式。
若可衡量的迁移驱动因素未知，首次响应必须严格为：
markdown
**问题：** React Native迁移应解决哪些可衡量的交付或业务问题？

**重要性：** 这将决定迁移是否具有相关性，以及评估必须验证哪些成果。
若驱动因素已知，仅采用相同的两行格式提出下一个影响最大的未知问题。提出问题和理由后立即结束本轮对话，不得添加开场白、调查问卷、建议或实施指导。

Rules

规则

  • Treat every production app as a source of truth, including undocumented behavior.
  • Inspect available code, CI, tests, release configuration, product documents, and runtime evidence before asking questions.
  • Compare iOS and Android explicitly where their implementation, behavior, dependencies, delivery, or roadmap differ.
  • Base product-wide claims only on evidence from every supported platform, or qualify their platform coverage.
  • Label material claims 
    observed
    , 
    measured
    , 
    reported
    , 
    assumed
    , or 
    unknown
    .
  • Recommend from evidence, not an aggregate readiness score.
  • Default to gathering evidence, not to brownfield, greenfield, or migration itself.
  • Own the decision phase. Do not apply implementation skills or select Expo versus bare React Native before Path A is accepted.
  • Count only React Native's marginal value over the current native system.
  • Measure agents by accepted, verified work, not tokens, generated code, or pull requests.
  • Make no universal claims about duration, cost, code sharing, agent productivity, or ROI.
  • 将每个生产应用视为事实来源，包括未记录的行为。
  • 在提出问题前，检查可用代码、CI、测试、发布配置、产品文档和运行时证据。
  • 当iOS和Android在实现、行为、依赖、交付或路线图上存在差异时，明确进行对比。
  • 仅基于所有受支持平台的证据得出产品层面的结论，或明确说明其平台覆盖范围。
  • 为重要结论标注
    observed
    （观测到的）、
    measured
    （测量到的）、
    reported
    （报告的）、
    assumed
    （假设的）或
    unknown
    （未知的）。
  • 基于证据提出建议，而非基于汇总就绪性评分。
  • 默认优先收集证据，而非默认选择棕地、绿地或迁移本身。
  • 主导决策阶段。在Path A被接受前，不得应用实施技能或选择Expo与原生React Native。
  • 仅计算React Native相对于当前原生系统的边际价值。
  • 以已接受、已验证的工作衡量Agent，而非以令牌、生成的代码或拉取请求衡量。
  • 不得对时长、成本、代码共享、Agent生产力或ROI做出通用声明。

Select the Evidence Mode

选择证据模式

Use repository-backed assessment when source code or delivery artifacts are available:
  1. Complete the platform inventory and establish which repositories the assessment can inspect.
  2. For each accessible mobile codebase, locate app variants, CI, tests, release configuration, architecture records, and product documentation.
  3. Search each native codebase for SDKs, permissions, app extensions, storage, authentication, push, deep links, analytics, experiments, and platform-specific behavior.
  4. Cite repository names plus file paths and line numbers so evidence remains attributable when codebases are separate.
  5. Ask stakeholders only for missing codebase locations or for product, organizational, and operational facts the repositories cannot establish.
Use interview assessment when the repository is unavailable or material evidence remains missing:
  1. Start with the measurable delivery or business problem unless the user already supplied it.
  2. Ask exactly one decision-changing question per turn.
  3. Explain in one sentence which path, risk, or assumption the answer affects.
  4. Challenge vague or contradictory answers with a narrower follow-up instead of accepting them as evidence.
  5. Record the answer, update the evidence state, and choose the next highest-impact unknown.
  6. Stop grilling when another answer cannot change the recommendation, confidence, or checkpoint.
Before the evidence gate passes, every response must contain only:
markdown
**Question:** [one question]

**Why it matters:** [one sentence]
Do not include a questionnaire, path recommendation, checkpoint, or implementation guidance during these turns. If the user pauses the interview, return the current evidence state and the single highest-impact unknown without pretending the assessment is complete.
Interview turn gate: one answer has been requested, its decision impact is explicit, and no second question appears.
当源代码或交付工件可用时，采用基于代码库的评估：
  1. 完成平台清单，确定评估可检查的代码库。
  2. 针对每个可访问的移动代码库，定位应用变体、CI、测试、发布配置、架构记录和产品文档。
  3. 在每个原生代码库中搜索SDK、权限、应用扩展、存储、身份验证、推送、深度链接、分析、实验和平台特定行为。
  4. 引用代码库名称、文件路径和行号，以便在代码库分离时仍可追溯证据。
  5. 仅向利益相关者询问缺失的代码库位置，或代码库无法确定的产品、组织和运营事实。
当代码库不可用或关键证据缺失时，采用基于访谈的评估：
  1. 除非用户已提供，否则从可衡量的交付或业务问题开始。
  2. 每次仅提出一个会改变决策的问题。
  3. 用一句话解释答案会影响哪条路径、风险或假设。
  4. 若答案模糊或矛盾，提出更具体的跟进问题，而非将其作为证据接受。
  5. 记录答案，更新证据状态，并选择下一个影响最大的未知问题。
  6. 当新答案无法改变建议、置信度或检查点时，停止追问。
在证据关卡通过前，每次响应必须仅包含：
markdown
**问题：** [一个问题]

**重要性：** [一句话]
在此期间，不得包含调查问卷、路径建议、检查点或实施指导。若用户暂停访谈，返回当前证据状态和影响最大的单一未知问题，不得假装评估已完成。
访谈回合关卡： 仅请求一个答案，明确说明其决策影响，且未提出第二个问题。

1. Collect Decision Evidence

1. 收集决策证据

State the decision, deadline, current alternative, and measurable driver. A framework preference is not a driver.
Inspect these dimensions:
DimensionMinimum evidence
ProductSupported platforms, app variants, shared versus platform-specific roadmap, critical flows, accessibility, analytics, and edge cases
Native surfaceSDKs, modules, permissions, background work, app extensions, payments, hardware APIs, custom rendering, and viable React Native paths
ContinuityAuth and sessions, secure and persisted storage, push tokens, deep links, subscriptions, installed-user update, legal, security, and offline constraints
VerificationReproducible builds, test accounts, manual and automated QA, device control, native-reference evidence, performance baselines, and independent review
ReleaseCurrent cadence and recovery, internal distribution, flags, experiments, store rollout, and desired binary plus optional OTA lanes
OwnershipDecision authority and owners for artifacts, parity, native boundaries, shared foundations, verification, and releases
Agent governanceApproved model and source boundary, protected secrets and test data, least-privilege access, evidence retention, audit trail, and human architecture and release approval
Delivery baselineDuplicate implementation and review, waiting and handoffs, parity gap, two-platform verification, release metrics, defects, rework, and maintenance cost
For an OTA-dependent plan, require an owner plus runtime compatibility, rollout, observability, rollback or republish, and audit policy. OTA availability alone is not a migration benefit.
Use a small migration core that combines existing product and native knowledge with React Native migration expertise. Ask only for missing facts that could change the decision; expose the rest as assumptions.
Gate: every dimension has evidence or an explicit unknown, and every path-blocking unknown is named.
说明决策内容、截止日期、当前替代方案和可衡量的驱动因素。框架偏好不属于驱动因素。
检查以下维度：
维度最低证据要求
产品支持的平台、应用变体、共享与平台特定路线图、关键流程、可访问性、分析和边缘情况
原生界面SDK、模块、权限、后台任务、应用扩展、支付、硬件API、自定义渲染，以及可行的React Native路径
连续性身份验证与会话、安全持久化存储、推送令牌、深度链接、订阅、已安装用户更新、法律、安全和离线约束
验证可重现构建、测试账户、手动与自动化QA、设备控制、原生参考证据、性能基准和独立评审
发布当前节奏与恢复机制、内部分发、功能标志、实验、商店发布流程，以及所需的二进制文件和可选OTA通道
所有权工件、一致性、原生边界、共享基础架构、验证和发布的决策权限与负责人
Agent治理已批准的模型与源边界、受保护的机密与测试数据、最小权限访问、证据保留、审计跟踪，以及人工架构和发布审批
交付基准重复实现与评审、等待与交接、一致性差距、双平台验证、发布指标、缺陷、返工和维护成本
对于依赖OTA的计划，要求指定负责人，并具备运行时兼容性、发布、可观测性、回滚或重新发布以及审计策略。仅OTA可用并不构成迁移优势。
组建小型迁移核心团队，结合现有产品和原生知识与React Native迁移专业知识。仅询问可能改变决策的缺失事实；其余内容作为假设披露。
关卡： 每个维度均有证据或明确标注未知，且所有阻碍路径的未知因素均已列出。

2. Choose a Path

2. 选择迁移路径

Choose one outcome and state why the alternatives lose.
OutcomeRecommend when
Path A: brownfieldRelease or installed-user continuity dominates, native coupling is deep, flows can move independently, or whole-app cutover risk is unacceptable. Include the cost of host boundaries and dual architecture.
Path B: greenfieldBehavior is recoverable, native dependencies have credible replacements, continuity can be proven, verification is strong, and legacy scope can be controlled until replacement.
Path C: greenfield-first checkpoint with brownfield fallbackGreenfield offers a simpler target but material uncertainty remains, and completed React Native work can be proven inside the native hosts before scaling.
DeferThe business case is plausible, but evidence, verification, ownership, budget, or release readiness is missing. Name the smallest readiness work and reopening condition.
Do not migrateThe native system meets the desired outcomes, duplicated mobile delivery is not material, the roadmap is asymmetric, platform-specific work dominates, or risk-adjusted return is not credible.
Treat Path C as Callstack's emerging post-2025 operating model, not an industry benchmark. Agent access makes behavioral porting more viable; only a measured checkpoint on this product establishes speed and quality.
After Path A is accepted, hand implementation planning to react-native-brownfield-migration. Do not repeat its Expo, XCFramework, AAR, or host-integration guidance.
Gate: one outcome is supported by decisive evidence, rejected alternatives have reasons, and confidence reflects evidence quality.
选择一个结果，并说明其他备选方案被否决的原因。
结果推荐场景
路径A：棕地迁移发布或已安装用户的连续性至关重要、原生耦合较深、流程可独立迁移，或全应用切换风险不可接受。需考虑宿主边界和双架构的成本。
路径B：绿地迁移行为可恢复、原生依赖有可靠替代方案、连续性可验证、验证能力较强，且可控制遗留范围直至完成替换。
路径C：先绿地迁移再检查点，附带棕地回退方案绿地迁移提供更简单的目标，但仍存在重大不确定性，且已完成的React Native工作可在原生宿主中验证后再进行扩展。
推迟迁移业务案例看似可行，但证据、验证、所有权、预算或发布就绪性存在缺失。指出最小的就绪性工作和重启条件。
不迁移原生系统已满足预期成果、重复的移动交付影响不大、路线图不对称、平台特定工作占主导，或经风险调整后的回报不可信。
将路径C视为Callstack 2025年后的新兴运营模式，而非行业基准。Agent的访问使行为移植更可行；仅针对该产品的可衡量检查点才能确定速度和质量。
路径A被接受后，将实施规划移交至react-native-brownfield-migration。不得重复其Expo、XCFramework、AAR或宿主集成指导内容。
关卡： 一个结果有决定性证据支持，被否决的备选方案有明确理由，且置信度反映证据质量。

3. Define a Representative Checkpoint

3. 定义代表性检查点

Use a checkpoint for Path C and whenever one uncertainty could invalidate the recommended path. Set a fixed calendar and effort budget supplied by the organization. Select two or three vertical flows:
  1. A common flow covering UI, data, analytics, and navigation.
  2. An authenticated, stateful flow covering persistence, errors, and session behavior.
  3. The boundary most likely to disprove the plan, such as a native SDK, background task, hardware API, offline behavior, app extension, accessibility requirement, or low-end Android constraint.
Tie each flow to native source references, runtime evidence, owners, and parity scenarios. Do not select only easy screens.
Define measurable acceptance criteria against the existing product:
  • Behavior, states, validation, errors, analytics, accessibility, and visual output match the native reference.
  • Auth, storage, deep links, push, and selected native boundaries work on required devices and OS versions.
  • Startup, interaction, memory, and crash behavior meet agreed baselines or tolerances.
  • CI, internal distribution, observability, and the intended release lane work reliably enough to continue.
  • Every flow has device-level evidence and an independent review with clean context.
  • Path C packages and opens at least one representative React Native flow in each required native host.
Run two passes on at least one flow:
  1. Faithful pass: preserve behavior, analytics, accessibility, states, and edge cases. Record native-shaped architecture retained for parity.
  2. Idiomatic pass: introduce React component composition, clear state boundaries, typed navigation, reusable primitives, suitable tests, and measured performance. Repeat parity and device checks.
Before scaling, assign owners for 
MIGRATION.md
, 
SCREENS.tsv
, 
STATE_AND_STORAGE.tsv
, 
DEPENDENCIES.tsv
, 
EVENTS.tsv
, and 
PARITY_CHECKS.md
. During assessment, identify missing artifacts rather than creating full inventories unless asked.
End with one decision: continue greenfield, continue Path C, move completed work into Path A, defer, or stop. Do not extend the checkpoint merely because its result is inconvenient.
Gate: flows, budget, criteria, evidence, owners, and terminal decisions are explicit.
为路径C以及任何可能使推荐路径失效的不确定性设置检查点。使用组织提供的固定日历和工作量预算。选择两到三个垂直流程：
  1. 涵盖UI、数据、分析和导航的通用流程。
  2. 涵盖持久化、错误和会话行为的已认证有状态流程。
  3. 最可能否定计划的边界，例如原生SDK、后台任务、硬件API、离线行为、应用扩展、可访问性要求或低端Android约束。
将每个流程与原生源代码引用、运行时证据、负责人和一致性场景关联。不得仅选择简单界面。
针对现有产品定义可衡量的验收标准：
  • 行为、状态、验证、错误、分析、可访问性和视觉输出与原生参考一致。
  • 身份验证、存储、深度链接、推送和选定的原生边界在所需设备和OS版本上正常工作。
  • 启动、交互、内存和崩溃行为符合商定的基准或容差。
  • CI、内部分发、可观测性和预期发布通道足够可靠，可继续推进。
  • 每个流程都有设备级证据和独立评审，且评审上下文清晰。
  • 路径C在每个所需的原生宿主中打包并开放至少一个代表性React Native流程。
对至少一个流程进行两轮测试：
  1. 忠实复刻轮： 保留行为、分析、可访问性、状态和边缘情况。记录为保持一致性而保留的原生架构。
  2. 符合规范轮： 引入React组件组合、清晰的状态边界、类型化导航、可复用原语、合适的测试和可测量的性能。重复一致性和设备检查。
在扩展前，为
MIGRATION.md
、
SCREENS.tsv
、
STATE_AND_STORAGE.tsv
、
DEPENDENCIES.tsv
、
EVENTS.tsv
和
PARITY_CHECKS.md
指定负责人。评估期间，仅识别缺失的工件，除非被要求，否则无需创建完整清单。
最终做出一个决策：继续绿地迁移、继续路径C、将已完成工作转入路径A、推迟或停止。不得仅因检查点结果不符合预期就延长检查点。
关卡： 流程、预算、标准、证据、负责人和最终决策均明确。

4. Test the Economics

4. 测试经济性

Map one representative change from ready-for-implementation to verified availability on both platforms. Capture two clocks:
  1. Change lead time: commit to an artifact available to a production cohort; separate binary and OTA delivery.
  2. Cross-platform feature lead time: ready-for-implementation to verified availability on iOS and Android.
Count potential return from removed duplicate implementation and business-logic review, lower parity coordination, engineer mobility, and measured release or recovery improvements. Keep iOS and Android device verification in the model. Keep web convergence outside the base case unless separately funded and assessed.
Count full investment: checkpoint, dual maintenance, native modules, training, idiomatic second pass, testing and device automation, observability, release infrastructure, platform ownership, cutover, and native-surface retirement.
Do not invent payback inputs. Use ranges when supplied data is uncertain. Revise, defer, or stop when verification and boundary work consume expected savings, native surfaces keep growing, dual maintenance has no retirement bound, agents add rework without verified throughput, parity improves without delivery improvement, or released capacity has no planned use.
Gate: marginal benefits and full investment can be compared without treating two-platform verification as removed work.
绘制一个从准备实施到在两个平台上验证可用的代表性变更流程。记录两个周期：
  1. 变更交付周期： 从提交到工件可供生产群组使用；区分二进制文件交付和OTA交付。
  2. 跨平台功能交付周期： 从准备实施到在iOS和Android上验证可用。
计算潜在回报，包括减少重复实现和业务逻辑评审、降低一致性协调成本、工程师流动性提升以及可测量的发布或恢复改进。模型中保留iOS和Android设备验证环节。除非单独获得资金并评估，否则将Web融合排除在基础案例之外。
计算全部投资：检查点、双重维护、原生模块、培训、符合规范的第二轮测试、测试与设备自动化、可观测性、发布基础设施、平台所有权、切换和原生界面退役。
不得虚构投资回报输入。当提供的数据不确定时，使用范围值。当验证和边界工作消耗预期节省、原生界面持续增长、双重维护无退役期限、Agent增加返工但未验证吞吐量、一致性提升但交付无改善，或释放的产能无计划用途时，修订、推迟或停止迁移。
关卡： 可对比边际收益与全部投资，且不得将双平台验证视为已移除工作。

Output Contract

输出约定

Use this contract only after the evidence gate passes or when the user ends the interview.
Return a concise report in this order:
  1. Recommendation: outcome, confidence, decisive reason, and decision boundary.
  2. Evidence: platform inventory, coverage limits, and material findings with source status and platform differences.
  3. Assumptions and blockers: unknowns ordered by decision impact.
  4. Checkpoint: budget, flows, criteria, owners, evidence, and terminal decisions.
  5. Baseline and ROI: measured inputs, missing inputs, counted return, full investment, and exclusions.
  6. Next decision: who decides what, using which evidence, and when.
Keep the conclusion diagnostic. If execution comes up, state only that orchestration, task contracts, prompts, retry rules, and private agents are engagement-specific. Never expose or invent private implementation material.
仅在证据关卡通过或用户结束访谈时使用本约定。
按以下顺序返回简洁报告：
  1. 建议： 结果、置信度、决定性理由和决策边界。
  2. 证据： 平台清单、覆盖范围限制，以及带有来源状态和平台差异的关键发现。
  3. 假设与障碍： 按决策影响排序的未知因素。
  4. 检查点： 预算、流程、标准、负责人、证据和最终决策。
  5. 基准线与ROI： 已测量的输入、缺失的输入、计算的回报、全部投资和排除项。
  6. 下一个决策： 谁来决策、决策依据的证据以及决策时间。
保持结论为诊断性内容。若涉及执行，仅说明编排、任务约定、提示、重试规则和私有Agent属于特定参与项目内容。不得披露或虚构私有实施材料。