heartraite 1.0.193 → 1.0.194

package/dist/types/consultation.types.d.ts

@@ -7,13 +7,23 @@ import { ConsultationInterestStatus } from "../enum";
  * (`Consultation`) so subsequent professionals can land here
  * without a schema rename.
  *
- * One pending record per user at a time — the
- * `/consultation/express-interest` endpoint upserts rather than
- * appending so resubmits don't duplicate.
+ * `expertId` scopes the record to a specific professional. v1 has
+ * exactly one value (`"bohm"`); future additions (other
+ * psychologists, therapists, sex therapists, financial planners,
+ * etc.) plug in without a schema migration. Idempotency at the
+ * backend is `(userId, expertId)` — a user can express interest in
+ * multiple experts independently, but only one pending record per
+ * (user, expert) pair at any time.
+ *
+ * The slug format (e.g. `"bohm"`) reads cleanly in logs / admin
+ * dashboards. Future v2 may move expert metadata (name, photo,
+ * pricing, credentials) into DatoCMS and key entries by their CMS
+ * slug — the runtime contract stays the same string.
  */
 export type ConsultationInterest = {
     id: string;
     userId: string;
+    expertId: string;
     submittedAt: string;
     status: ConsultationInterestStatus;
     /**
@@ -35,11 +45,17 @@ export type ConsultationInterest = {
  * to show the "Anmäl intresse" CTA or the post-submit "Tack — vi
  * hör av oss" confirmation state.
  *
+ * Scoped to a single `expertId` (the one the client asked about) —
+ * a user with interest in multiple experts gets multiple summaries
+ * via multiple calls. v1 only ever asks about `"bohm"`, so the app
+ * still has a single CTA flow.
+ *
  * Carries just enough for the UI to render the two states; the
  * full `ConsultationInterest` record (notes, internal status
  * machinery) stays admin-only.
  */
 export type ConsultationInterestSummary = {
+    expertId: string;
     hasInterest: boolean;
     submittedAt: string | null;
     status: ConsultationInterestStatus | null;

package/dist/types/request.types.d.ts

@@ -59,14 +59,23 @@ export type SubmitFeedbackRequest = {
     context?: string;
     rating?: number;
 };
-export type ExpressConsultationInterestRequest = undefined;
-export type GetMyConsultationInterestRequest = undefined;
+export type ExpressConsultationInterestRequest = {
+    expertId: string;
+};
+export type GetMyConsultationInterestRequest = {
+    expertId: string;
+};
 export type GetConsultationInterestsRequest = {
     /**
      * Optional status filter. Omit to fetch every record. Most
      * common use is `PENDING` for the team's outreach worklist.
      */
     status?: ConsultationInterestStatus;
+    /**
+     * Optional expert filter. Omit for the cross-expert worklist;
+     * pass to scope a single professional's outreach queue.
+     */
+    expertId?: string;
 };
 export type UpdateConsultationInterestRequest = {
     id: string;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "heartraite",
-  "version": "1.0.193",
+  "version": "1.0.194",
   "description": "Heartraite npm package for common functionality",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/src/types/consultation.types.ts

@@ -8,13 +8,23 @@ import { ConsultationInterestStatus } from "../enum";
  * (`Consultation`) so subsequent professionals can land here
  * without a schema rename.
  *
- * One pending record per user at a time — the
- * `/consultation/express-interest` endpoint upserts rather than
- * appending so resubmits don't duplicate.
+ * `expertId` scopes the record to a specific professional. v1 has
+ * exactly one value (`"bohm"`); future additions (other
+ * psychologists, therapists, sex therapists, financial planners,
+ * etc.) plug in without a schema migration. Idempotency at the
+ * backend is `(userId, expertId)` — a user can express interest in
+ * multiple experts independently, but only one pending record per
+ * (user, expert) pair at any time.
+ *
+ * The slug format (e.g. `"bohm"`) reads cleanly in logs / admin
+ * dashboards. Future v2 may move expert metadata (name, photo,
+ * pricing, credentials) into DatoCMS and key entries by their CMS
+ * slug — the runtime contract stays the same string.
  */
 export type ConsultationInterest = {
   id: string;
   userId: string;
+  expertId: string;
   submittedAt: string;
   status: ConsultationInterestStatus;
   /**
@@ -37,11 +47,17 @@ export type ConsultationInterest = {
  * to show the "Anmäl intresse" CTA or the post-submit "Tack — vi
  * hör av oss" confirmation state.
  *
+ * Scoped to a single `expertId` (the one the client asked about) —
+ * a user with interest in multiple experts gets multiple summaries
+ * via multiple calls. v1 only ever asks about `"bohm"`, so the app
+ * still has a single CTA flow.
+ *
  * Carries just enough for the UI to render the two states; the
  * full `ConsultationInterest` record (notes, internal status
  * machinery) stays admin-only.
  */
 export type ConsultationInterestSummary = {
+  expertId: string;
   hasInterest: boolean;
   submittedAt: string | null;
   status: ConsultationInterestStatus | null;

package/src/types/request.types.ts

@@ -90,14 +90,20 @@ export type SubmitFeedbackRequest = {
 
 // consultation — 1:1 video sessions with credentialed professionals
 //
-// v1 endpoints are AuthGuard'd from the user-facing side (express +
-// my-interest) and AdminGuard'd from the team side (admin-interests
-// + admin-update-interest). The express + my-interest payloads are
-// intentionally empty / minimal — userId comes from the request's
-// authed token, never the client.
-export type ExpressConsultationInterestRequest = undefined;
+// v1 endpoints are CAGuard'd from the user-facing side (express +
+// my-interest, gated on completed CA) and AdminGuard'd from the
+// team side (admin-interests + admin-update-interest). userId
+// always comes from the authed token, never the client. `expertId`
+// scopes the request to a specific professional — v1 only sends
+// `"bohm"` but the field is required so the schema is stable when
+// future experts land.
+export type ExpressConsultationInterestRequest = {
+  expertId: string;
+};
 
-export type GetMyConsultationInterestRequest = undefined;
+export type GetMyConsultationInterestRequest = {
+  expertId: string;
+};
 
 export type GetConsultationInterestsRequest = {
   /**
@@ -105,6 +111,11 @@ export type GetConsultationInterestsRequest = {
    * common use is `PENDING` for the team's outreach worklist.
    */
   status?: ConsultationInterestStatus;
+  /**
+   * Optional expert filter. Omit for the cross-expert worklist;
+   * pass to scope a single professional's outreach queue.
+   */
+  expertId?: string;
 };
 
 export type UpdateConsultationInterestRequest = {