Flow Data Review

Trace the real code path before judging any field. Prefer actual callers, store writes, and request builders over comments or interface names.

Reconstruct The Flow

1. Find the entry page, downstream pages, and every API wrapper used in the chain.
2. Build a minimal path map: page -> action -> store write -> API call -> next page.
3. Mark every branch point explicitly:
   • backend result branches such as 100701 / 100702
   • user choice branches such as confirm / cancel
   • resume vs new-flow initialization
   • success vs failure of follow-up transition APIs

Track Canonical Fields

List the few fields whose semantics must stay stable across the flow. Typical examples:

• trace fields: traceId, orderNo
• business order fields: orderId, bizId
• reservation or plan fields: planOrderId
• identity fields: name, cert number, validity dates, OCR outputs
• process control fields: processId, processType, preType, sysId

For each key field, record:

• source: where the value is first produced
• persistence: where it is written into store/session/local cache
• consumers: which later APIs/pages read it
• required meaning: what the downstream code assumes the field represents

If one field temporarily holds another concept, flag it. Do not accept "it gets corrected later" unless every intermediate consumer is proven safe.

Check Each Branch

For every branch point, verify these questions in order:

1. Does the page continue, block, or only show a message?
2. Does any store state change before the branch is confirmed?
3. If the user cancels or the next API fails, will dirty state remain?
4. Do later pages read from the latest closure variable or from persisted store state?
5. Are success-only values written only after the success condition is truly satisfied?

Pay special attention to:

• writing business ids before transition APIs succeed
• cancel branches that leave persisted intermediate state
• fallback expressions such as orderId || orderNo
• one API using the correct local value while later pages still read an old store value

Validate Request Accuracy

For each important API in the flow:

1. Locate the real payload assembly in code.
2. Map every critical field to its source variable.
3. Check type and format only from actual values or formatting code, not guesses.
4. Compare semantically similar fields across APIs to ensure they are not silently collapsed.

When Excel or API docs are involved, compare:

• field name
• required/optional status
• type
• format
• constant values
• whether the value sits in header, query, or body

Judge Minimal-Change Safety

When reviewing a patch, ask:

1. Did the change fix only the intended semantic bug?
2. Did it move persistence earlier or later than before?
3. Did it alter cancel, retry, refresh, resume, or failure paths?
4. Did it introduce a new rejection/throw path without updating callers?
5. Does it preserve original control flow for unaffected branches?

Prefer the smallest fix that restores correct field semantics without widening behavior changes.

Report Findings

Findings come first. Order by severity.

Each finding should include:

• severity
• exact file and tight line reference
• branch or scenario that triggers it
• why the resulting data becomes inaccurate or inconsistent
• whether the risk is wrong request data, dirty persisted state, or flow-control regression

After findings, give a short flow summary only if it helps explain the issue set.

Output Patterns

Use this skill for outputs such as:

• code review focused on state consistency
• end-to-end flow reconstruction
• branch-by-branch data accuracy audit
• minimal-change and no-regression review
• interface field provenance checks across pages and API wrappers