P10 · Scan Session & Orchestration

• Gate: P10 · Items: WI-070 (session + orchestration) + WI-071 (e2e exit proof) · Owner: Paul · Status: draft
• Depends on: P1 (next_scan + candidate IDs), P2/P3/P4 (pipeline), P5 (review entry), P8 (budget/trace), P9 (conventions/API) · Unblocks: the product's core progressive-scan loop + the P&C exit proof (D31)
• Origin: spec gap analysis (D26 approved 2026-06-20) — closes G2; resolves P1 §21 #3 (deferred cross-scan identity).

Why this gate exists: P1 emits next_scan directives and explicitly defers cross-scan identity; P8 only describes trace links. No spec owns the conductor that sequences table_hunt → item_scan → mark_scan → promotion. P10 is that conductor — without making any single P-gate secretly own orchestration.

1. Purpose

Define the progressive-scan conductor that links P1/P2/P3/P4/P5/P8 into the product loop: a scan session with stable candidate lineage across scans, next-scan execution, the provider/validation/ranking handoff, candidate entry into review, and the end-to-end happy-path proof.

2. Scope

2.1 Session identity + candidate lineage

• scan_session_id, per-scan attempt IDs, and parent/child candidate lineage.
• Stable mapping from result-local P1 candidate IDs (unique within one result) to session-level candidate lineage across scans. Resolves P1's deferred cross-scan identity.

2.2 Next-scan execution

• Consumes P1 next_scan directives; validates target / parent_candidate_id references; assembles the next P1 request; preserves trace links rather than holding one indefinitely-open operation (P8 §6).

2.3 Provider / validation / ranking handoff

• Calls P2 for attempts, P3 for trusted outcomes + recovery, P4 for deterministic ranking only when applicable. No provider-native or untrusted result bypasses the P3/P4 boundaries; recovery retries/fallbacks remain P3/P8-governed, not adapter-local.

2.4 Candidate entry into review

• A trusted/ranked vision candidate enters P5 as source_type: vision_scan → inventory candidate → seller review → promotion. Never writes canonical inventory directly.

2.5 Budget / trace / cost evidence

• Every paid attempt is P8-authorized; the session carries operation/correlation IDs; the e2e proof links trace, cost, validation, ranking, candidate, review, and promotion.

2.6 Failure & partial semantics

• retake_required, insufficient_evidence, partial, rejected, budget_blocked, and user_cancelled are explicit session states.

3. Acceptance

• scan_session_id + lineage mapping; result-local → session candidate identity is stable and traceable.
• Next-scan execution validates refs, builds the next P1 request, and trace-links.
• Handoff uses P2/P3/P4 with no untrusted bypass; review entry goes through P5.
• The e2e happy-path passes (WI-071) — capture → table_hunt → item_scan → P3 validate → P4 rank → P5 review → promotion, with P8 trace/cost evidence — which, with the D32 quarantine clean, satisfies the P&C exit criterion (D31).

4. Work-item split

• WI-070 (orchestration) — session identity + candidate lineage + next-scan execution + the P2/P3/P4 handoff. Lands late in P&C (it conducts gates that must already exist).
• WI-071 (e2e exit proof) — the end-to-end happy-path acceptance + the quarantine-clean check; this is the P&C gatekeeper (D31). Reviewer Mark.