S4 · Channel A — Design Consultation

System-first holistic lens applied to this sprint's S4 doc (04-spec.md).

The 04-spec.md doc for this sprint is more execution-focused than system-focused (3 features in scope + 7 features out, with explicit Stripe Connect + Smoobu adapter pinned). Channel A's read : the spec is sound on scope discipline but the design tokens section (PARTIE 4) is sparse — a real design consultation would require palette + typography + spacing tokens before S5 commits to a UI framework.

What's missing under this lens :

• No color system rationale (just 2 colors named, no semantic states, no chart palette)
• No typography scale (only "Inter + serif" mentioned)
• No motion principles
• No component primitive list (the 12-primitive contract isn't articulated here ; it landed in the prearrival-final sprint instead)

Verdict : WAIT — proceed only after a 1-hour design-tokens pass enriches PARTIE 4. The shortcut of "we'll style it later in S5" never works for B2B SaaS that intends to charge €99/mo+. Confidence 5/10.

S4 · Channel B — Design Shotgun

Variants-first divergent lens applied to this sprint's 04-spec.md.

The spec went straight to "Feature 1 / 2 / 3" without exploring divergent design variants for the host dashboard (the primary UI surface). Channel B would have run 3-4 mockup variants via /design-shotgun first :

• Compact terminal-style (mono-heavy, status-strip rich)
• Editorial ledger (sober + dense, type-led)
• Spatial studio (whitespace-led, one hero metric per screen)
• Concierge feed (timeline-led, host-as-protagonist)

The benefit of running 4 variants on Sonnet 4.6 (~$2-5 total) is the founder's gut catches things the spec misses : "actually I want this to feel like Le Petit Ballon's customer dashboard, not a B2B SaaS console". That insight only emerges when 4 directions sit side-by-side.

Verdict : WAIT until Channel B runs the variants on Smoobu adapter UI specifically (the most-used surface). The current spec assumes a default form-table-CRUD layout — that's the cheapest wrong direction. Confidence 4.5/10 on the spec as-is, would move to 7+ after the variant pass.

S4 · Channel C — Engineering Review

Reality check lens applied to this sprint's 04-spec.md.

The 3-features-in-scope contract reads tight on paper :

1. Booking sync (Smoobu PMS adapter)
2. AI Sequence Runner (14-touchpoint pre-arrival sequence)
3. Upsell Catalog + Stripe Checkout embedded

Engineering reality : these three are not independent — they're one workflow with three coupled layers. The Smoobu adapter has to ship before the sequence runner has bookings to act on. The Stripe checkout has to ship before the sequence can offer paid upsells. Critical path : Smoobu → Runner → Stripe, sequential, not parallel.

Realistic v1 build estimate : 8-10 working days, NOT the 5 days the playbook implies.

Critical pushback :

• Stripe Connect application_fee adds 0.5-1 day on top (account onboarding flow + webhooks). If the v1 simplifies to Stripe Checkout URL (no Connect), v1 timeline shrinks back to 6-7 days. Recommendation : drop Connect to v1.1.
• 14-touchpoint sequence is ambitious for v1. Recommendation : ship 5-6 touchpoints at v1 (booking confirmation → D-21 transfers → D-10 experiences → D-7 room upgrade → D-1 arrival logistics). The other 8 land at v1.1 after measurement.
• Smoobu adapter alone : 2-3 days. The spec already pins Smoobu so this is fine.

Verdict : WAIT for re-scoping :

• Drop Stripe Connect to v1.1 (use Stripe Checkout URL at v1)
• Drop 8 of 14 touchpoints to v1.1 (ship 5-6 at v1)
• Keep Smoobu as the v1 PMS, defer Mews/Cloudbeds/Lodgify/Hostaway to v1.1+

Confidence 5/10 on the current scope. Would move to 7+ after re-scope above. The bias of "3 features" sounds disciplined but masks a 12-day build under a 5-day banner.