heartraite 1.0.193 → 1.0.195

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/dq.types.d.ts

@@ -109,6 +109,24 @@ export interface GetQuestionResponse {
     quotaResetsAt?: string;
     /** Number of questions remaining for today */
     questionsRemainingToday: number;
+    /**
+     * True when the user has answered every question currently in the
+     * DQ pool. Distinct from `quotaExhausted` (the daily 3/day cap):
+     *
+     *   - `quotaExhausted: true`           → user used today's 3 — come back tomorrow.
+     *   - `allQuestionsCompleted: true`    → user has cleared the entire pool;
+     *                                        no more questions exist until new ones
+     *                                        are added. Tomorrow's quota reset won't
+     *                                        bring new questions.
+     *
+     * Optional for backward compatibility — older clients that don't
+     * read this field will continue inferring "no question available"
+     * from `question: null && !quotaExhausted`, but they'll show the
+     * generic "come back tomorrow" message which is misleading in this
+     * state. New clients should render a dedicated "all caught up"
+     * surface when this is `true`.
+     */
+    allQuestionsCompleted?: boolean;
     /** User's discovery progress (streaks, counts) */
     progress?: DiscoveryProgress;
 }

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/dist/utils/date/age.util.js

@@ -4,9 +4,9 @@ exports.calculateAgeFromDateString = calculateAgeFromDateString;
 function calculateAgeFromDateString(isoDateString) {
     const birthDate = new Date(isoDateString);
     const today = new Date();
-    const ageDiff = today.getFullYear() - birthDate.getFullYear();
-    const hasBirthdayPassed = today.getMonth() > birthDate.getMonth() ||
-        (today.getMonth() === birthDate.getMonth() &&
-            today.getDate() >= birthDate.getDate());
+    const ageDiff = today.getUTCFullYear() - birthDate.getUTCFullYear();
+    const hasBirthdayPassed = today.getUTCMonth() > birthDate.getUTCMonth() ||
+        (today.getUTCMonth() === birthDate.getUTCMonth() &&
+            today.getUTCDate() >= birthDate.getUTCDate());
     return hasBirthdayPassed ? ageDiff : ageDiff - 1;
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "heartraite",
-  "version": "1.0.193",
+  "version": "1.0.195",
   "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/dq.types.ts

@@ -149,6 +149,25 @@ export interface GetQuestionResponse {
   /** Number of questions remaining for today */
   questionsRemainingToday: number;
 
+  /**
+   * True when the user has answered every question currently in the
+   * DQ pool. Distinct from `quotaExhausted` (the daily 3/day cap):
+   *
+   *   - `quotaExhausted: true`           → user used today's 3 — come back tomorrow.
+   *   - `allQuestionsCompleted: true`    → user has cleared the entire pool;
+   *                                        no more questions exist until new ones
+   *                                        are added. Tomorrow's quota reset won't
+   *                                        bring new questions.
+   *
+   * Optional for backward compatibility — older clients that don't
+   * read this field will continue inferring "no question available"
+   * from `question: null && !quotaExhausted`, but they'll show the
+   * generic "come back tomorrow" message which is misleading in this
+   * state. New clients should render a dedicated "all caught up"
+   * surface when this is `true`.
+   */
+  allQuestionsCompleted?: boolean;
+
   /** User's discovery progress (streaks, counts) */
   progress?: DiscoveryProgress;
 }

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 = {

package/src/utils/date/age.util.ts

@@ -2,11 +2,11 @@ export function calculateAgeFromDateString(isoDateString: string): number {
   const birthDate = new Date(isoDateString);
   const today = new Date();
 
-  const ageDiff = today.getFullYear() - birthDate.getFullYear();
+  const ageDiff = today.getUTCFullYear() - birthDate.getUTCFullYear();
   const hasBirthdayPassed =
-    today.getMonth() > birthDate.getMonth() ||
-    (today.getMonth() === birthDate.getMonth() &&
-      today.getDate() >= birthDate.getDate());
+    today.getUTCMonth() > birthDate.getUTCMonth() ||
+    (today.getUTCMonth() === birthDate.getUTCMonth() &&
+      today.getUTCDate() >= birthDate.getUTCDate());
 
   return hasBirthdayPassed ? ageDiff : ageDiff - 1;
 }