Skip to main content

Client Learnings

What individual clinics teach us — the edge cases, feature requests, and workflow realities that a spec never captures. This is a near-empty section today, and that is worth stating plainly rather than filling with invented anecdotes.

Why this section exists​

The best product knowledge is downstream of real clinics. Today those learnings are scattered across: GitHub issues (from staff intake), Slack threads, Sentry reports, the Atlas COO's customer-health signals, and George's head. They are not consolidated into durable, searchable learnings — which is exactly the problem the internal knowledge base is meant to solve (Slack + issues + Firestore as sources).

What a real entry looks like​

Until the KB automates this, a client-learning entry should be a short, dated note:

## <Clinic> — <what we learned> (YYYY-MM-DD)
- Context: what they were doing
- Surprise: what broke the assumption / what they needed
- Change: what we shipped or decided (link the issue/PR)
- Generalizes to: which other clinics this applies to

Seed material that exists in the repo​

  • Junction lab integration — team-per-clinic, zip-first ordering, TOS-only consent (confirmed with a real clinic contact). → [junction integration in agent-fleet/ops docs]
  • Benchmark sources — real divergence found between mobile (Dart) and web (benchmark-defaults.ts), including a unit-normalization bug on HDL.
  • Membership horizon — a real clinic (basisweb) capped at 21 days because the editor wrote defaultJoinPolicy while the reader read joinPolicies.

These are genuine learnings, currently living in commit history and memory rather than here.

Gap — this is a real, deliberate blank

No consolidated client-learnings log exists. Rather than backfill it with plausible stories, this page defines the template and names the automation (KB) that will populate it. The honest state: empty, with a plan.