@zeniai/client-epic-state 5.2.36 → 5.2.37

package/lib/view/aiCfoView/epics/deleteRoutineEpic.js

@@ -0,0 +1,39 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.deleteRoutineEpic = void 0;
+const rxjs_1 = require("rxjs");
+const operators_1 = require("rxjs/operators");
+const responsePayload_1 = require("../../../responsePayload");
+const aiCfoViewReducer_1 = require("../aiCfoViewReducer");
+/**
+ * DELETE /1.0/routines/{scheduleId}.
+ *
+ * The row has already left the list by the time this runs — the reducer removes
+ * it optimistically so the click does not feel ignored.
+ *
+ * A failure therefore has to put it BACK, not merely report. The routine still
+ * exists and is still emailing the user their financials on a schedule; leaving
+ * it hidden would tell them they had stopped something they had not. So a
+ * failure drops the tombstone and refetches, and the error explains why the row
+ * returned.
+ */
+const deleteRoutineEpic = (actions$, _state$, zeniAPI) => actions$.pipe((0, operators_1.filter)(aiCfoViewReducer_1.deleteRoutine.match), 
+// mergeMap: deleting one routine must not cancel the delete of another.
+(0, operators_1.mergeMap)((action) => {
+    const { scheduleId } = action.payload;
+    return zeniAPI
+        .deleteAndGetJSON(`${zeniAPI.apiEndPoints.aiCfoMicroServiceBaseUrl}/1.0/routines/${encodeURIComponent(scheduleId)}`)
+        .pipe((0, operators_1.mergeMap)((response) => 
+    // isSuccessStatus, NOT isSuccessResponse: the latter also requires a
+    // non-null `data`, and a successful DELETE here is a 204 with no body.
+    // deleteSkillEpic carries the same note for the same reason — using
+    // the wrong one reported every completed delete as a failure, which
+    // here would also drop the tombstone and refetch the row back.
+    (0, responsePayload_1.isSuccessStatus)(response)
+        ? (0, rxjs_1.of)((0, aiCfoViewReducer_1.deleteRoutineSuccess)({ scheduleId }))
+        : (0, rxjs_1.of)((0, aiCfoViewReducer_1.deleteRoutineFailure)({ scheduleId, status: response.status }), (0, aiCfoViewReducer_1.fetchRoutines)())), (0, operators_1.catchError)((error) => (0, rxjs_1.of)((0, aiCfoViewReducer_1.deleteRoutineFailure)({
+        scheduleId,
+        status: (0, responsePayload_1.createZeniAPIStatus)('Unexpected Error', 'Delete routine REST API call failed', error instanceof Error ? { message: error.message } : undefined),
+    }), (0, aiCfoViewReducer_1.fetchRoutines)())));
+}));
+exports.deleteRoutineEpic = deleteRoutineEpic;

package/lib/view/aiCfoView/epics/fetchRoutineRunsEpic.d.ts

@@ -0,0 +1,13 @@
+import { ActionsObservable } from 'redux-observable';
+import { Observable } from 'rxjs';
+import { ZeniAPI } from '../../../zeniAPI';
+import { fetchRoutineRuns, fetchRoutineRunsFailure, fetchRoutineRunsSuccess } from '../aiCfoViewReducer';
+export type ActionType = ReturnType<typeof fetchRoutineRuns> | ReturnType<typeof fetchRoutineRunsSuccess> | ReturnType<typeof fetchRoutineRunsFailure>;
+/**
+ * GET /1.0/routines/{scheduleId}/runs — one routine's run history.
+ *
+ * switchMap: only the history the user has open matters, so expanding a second
+ * routine while the first is still loading should abandon the first rather than
+ * race it into the single slot the state keeps.
+ */
+export declare const fetchRoutineRunsEpic: (actions$: ActionsObservable<ActionType>, _state$: unknown, zeniAPI: ZeniAPI) => Observable<ActionType>;

package/lib/view/aiCfoView/epics/fetchRoutineRunsEpic.js

@@ -0,0 +1,39 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.fetchRoutineRunsEpic = void 0;
+const rxjs_1 = require("rxjs");
+const operators_1 = require("rxjs/operators");
+const responsePayload_1 = require("../../../responsePayload");
+const aiCfoViewReducer_1 = require("../aiCfoViewReducer");
+const toRoutineRun_1 = require("./toRoutineRun");
+/**
+ * GET /1.0/routines/{scheduleId}/runs — one routine's run history.
+ *
+ * switchMap: only the history the user has open matters, so expanding a second
+ * routine while the first is still loading should abandon the first rather than
+ * race it into the single slot the state keeps.
+ */
+const fetchRoutineRunsEpic = (actions$, _state$, zeniAPI) => actions$.pipe((0, operators_1.filter)(aiCfoViewReducer_1.fetchRoutineRuns.match), (0, operators_1.switchMap)((action) => {
+    const { scheduleId } = action.payload;
+    return zeniAPI
+        .getJSON(`${zeniAPI.apiEndPoints.aiCfoMicroServiceBaseUrl}/1.0/routines/${encodeURIComponent(scheduleId)}/runs`)
+        .pipe((0, operators_1.map)((response) => {
+        // The explicit `data == null` is what narrows the type — the helper
+        // returns a plain boolean, not a type guard — and it means a
+        // malformed 2xx becomes a failure rather than an empty history,
+        // which would read as "this has never run" when it has.
+        if (!(0, responsePayload_1.isSuccessResponse)(response) || response.data == null) {
+            return (0, aiCfoViewReducer_1.fetchRoutineRunsFailure)(response.status);
+        }
+        const { data } = response;
+        return (0, aiCfoViewReducer_1.fetchRoutineRunsSuccess)({
+            // Filtered, not trusted: one malformed row must not take the
+            // whole history down, and a run without an id is not addressable
+            // by anything the UI does with it.
+            runs: (data.runs ?? []).filter(toRoutineRun_1.isRoutineRunPayload).map(toRoutineRun_1.toRoutineRun),
+            scheduleId,
+            sessionId: data.session_id ?? null,
+        });
+    }), (0, operators_1.catchError)((error) => (0, rxjs_1.of)((0, aiCfoViewReducer_1.fetchRoutineRunsFailure)((0, responsePayload_1.createZeniAPIStatus)('Unexpected Error', 'Fetch routine runs REST API call failed', error instanceof Error ? { message: error.message } : undefined)))));
+}));
+exports.fetchRoutineRunsEpic = fetchRoutineRunsEpic;

package/lib/view/aiCfoView/epics/fetchRoutinesEpic.d.ts

@@ -0,0 +1,7 @@
+import { ActionsObservable } from 'redux-observable';
+import { Observable } from 'rxjs';
+import { ZeniAPI } from '../../../zeniAPI';
+import { fetchRoutines, fetchRoutinesFailure, fetchRoutinesSuccess } from '../aiCfoViewReducer';
+export type ActionType = ReturnType<typeof fetchRoutines> | ReturnType<typeof fetchRoutinesSuccess> | ReturnType<typeof fetchRoutinesFailure>;
+/** GET /1.0/routines — the caller's own scheduled runs. */
+export declare const fetchRoutinesEpic: (actions$: ActionsObservable<ActionType>, _state$: unknown, zeniAPI: ZeniAPI) => Observable<ActionType>;

package/lib/view/aiCfoView/epics/fetchRoutinesEpic.js

@@ -0,0 +1,41 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.fetchRoutinesEpic = void 0;
+const rxjs_1 = require("rxjs");
+const operators_1 = require("rxjs/operators");
+const responsePayload_1 = require("../../../responsePayload");
+const aiCfoViewReducer_1 = require("../aiCfoViewReducer");
+const toRoutine_1 = require("./toRoutine");
+/** GET /1.0/routines — the caller's own scheduled runs. */
+const fetchRoutinesEpic = (actions$, _state$, zeniAPI) => actions$.pipe((0, operators_1.filter)(aiCfoViewReducer_1.fetchRoutines.match), 
+// switchMap: a read. A newer list request makes an older one's answer
+// irrelevant, and letting both land means the older can arrive second and
+// overwrite the newer — which matters here because every write refetches,
+// so two GETs in flight is the normal case rather than the exotic one. It
+// also widens the delete tombstone's race window.
+(0, operators_1.switchMap)(() => zeniAPI
+    .getJSON(`${zeniAPI.apiEndPoints.aiCfoMicroServiceBaseUrl}/1.0/routines`)
+    .pipe((0, operators_1.mergeMap)((response) => {
+    // The explicit `data == null` is what narrows the type — the
+    // helper returns a plain boolean, not a type guard — and it means a
+    // malformed 2xx becomes a failure rather than a silent empty list,
+    // which would read as "you have no routines" when you do.
+    if (!(0, responsePayload_1.isSuccessResponse)(response) || response.data == null) {
+        return (0, rxjs_1.of)((0, aiCfoViewReducer_1.fetchRoutinesFailure)(response.status));
+    }
+    const { data } = response;
+    return (0, rxjs_1.of)((0, aiCfoViewReducer_1.fetchRoutinesSuccess)({
+        // Malformed rows are dropped, not defaulted into existence: a
+        // routine with no id cannot be opened, paused or deleted, so
+        // rendering one offers controls that cannot work.
+        routines: (data.routines ?? [])
+            .filter(toRoutine_1.isRoutinePayload)
+            .map(toRoutine_1.toRoutine),
+        maxRoutines: data.max_routines ?? 0,
+        // Absent reads as OFF, matching the server's fail-closed gate:
+        // an older backend that does not send it should hide the entry,
+        // not show one whose endpoints 404.
+        routinesEnabled: data.routines_enabled === true,
+    }));
+}), (0, operators_1.catchError)((error) => (0, rxjs_1.of)((0, aiCfoViewReducer_1.fetchRoutinesFailure)((0, responsePayload_1.createZeniAPIStatus)('Unexpected Error', 'Fetch routines REST API call failed', error instanceof Error ? { message: error.message } : undefined)))))));
+exports.fetchRoutinesEpic = fetchRoutinesEpic;

package/lib/view/aiCfoView/epics/runRoutineEpic.d.ts

@@ -0,0 +1,14 @@
+import { ActionsObservable } from 'redux-observable';
+import { Observable } from 'rxjs';
+import { ZeniAPI } from '../../../zeniAPI';
+import { fetchRoutineRuns, fetchRoutines, runRoutine, runRoutineFailure, runRoutineSuccess } from '../aiCfoViewReducer';
+export type ActionType = ReturnType<typeof runRoutine> | ReturnType<typeof runRoutineSuccess> | ReturnType<typeof runRoutineFailure> | ReturnType<typeof fetchRoutineRuns> | ReturnType<typeof fetchRoutines>;
+/**
+ * POST /1.0/routines/{scheduleId}/run — run a routine now.
+ *
+ * The response says the run was QUEUED, not that it finished: the answer is
+ * emailed a minute or two later. So nothing is spliced in — both refetches are
+ * what show the new run, and the outcome arrives on a later fetch rather than
+ * being polled for.
+ */
+export declare const runRoutineEpic: (actions$: ActionsObservable<ActionType>, _state$: unknown, zeniAPI: ZeniAPI) => Observable<ActionType>;

package/lib/view/aiCfoView/epics/runRoutineEpic.js

@@ -0,0 +1,38 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.runRoutineEpic = void 0;
+const rxjs_1 = require("rxjs");
+const operators_1 = require("rxjs/operators");
+const responsePayload_1 = require("../../../responsePayload");
+const aiCfoViewReducer_1 = require("../aiCfoViewReducer");
+/**
+ * POST /1.0/routines/{scheduleId}/run — run a routine now.
+ *
+ * The response says the run was QUEUED, not that it finished: the answer is
+ * emailed a minute or two later. So nothing is spliced in — both refetches are
+ * what show the new run, and the outcome arrives on a later fetch rather than
+ * being polled for.
+ */
+const runRoutineEpic = (actions$, _state$, zeniAPI) => actions$.pipe((0, operators_1.filter)(aiCfoViewReducer_1.runRoutine.match), 
+// mergeMap, not exhaustMap: these target different rows, so running one
+// routine must not swallow a request to run another. A double-click on the
+// SAME row is already harmless — the server keys a manual run by the
+// minute, so the second press finds the first run and reports it.
+(0, operators_1.mergeMap)((action) => {
+    const { scheduleId } = action.payload;
+    return zeniAPI
+        .postAndGetJSON(`${zeniAPI.apiEndPoints.aiCfoMicroServiceBaseUrl}/1.0/routines/${encodeURIComponent(scheduleId)}/run`, {})
+        .pipe((0, operators_1.mergeMap)((response) => 
+    // isSuccessStatus, not isSuccessResponse: "already_running" is a
+    // legitimate 200 whose body carries no routine, and treating a
+    // second press as a failure would be a lie about what happened.
+    (0, responsePayload_1.isSuccessStatus)(response)
+        ? (0, rxjs_1.of)((0, aiCfoViewReducer_1.runRoutineSuccess)(), (0, aiCfoViewReducer_1.fetchRoutines)(), 
+        // The run history too, or the panel the user is looking at
+        // keeps showing the runs from before they pressed Run. The
+        // new row comes back as claimed/running — the run has been
+        // queued, not finished — which is the honest thing to show.
+        (0, aiCfoViewReducer_1.fetchRoutineRuns)({ scheduleId }))
+        : (0, rxjs_1.of)((0, aiCfoViewReducer_1.runRoutineFailure)(response.status))), (0, operators_1.catchError)((error) => (0, rxjs_1.of)((0, aiCfoViewReducer_1.runRoutineFailure)((0, responsePayload_1.createZeniAPIStatus)('Unexpected Error', 'Run routine REST API call failed', error instanceof Error ? { message: error.message } : undefined)))));
+}));
+exports.runRoutineEpic = runRoutineEpic;

package/lib/view/aiCfoView/epics/saveRoutineEpic.d.ts

@@ -0,0 +1,13 @@
+import { ActionsObservable } from 'redux-observable';
+import { Observable } from 'rxjs';
+import { ZeniAPI } from '../../../zeniAPI';
+import { fetchRoutines, saveRoutine, saveRoutineFailure, saveRoutineSuccess } from '../aiCfoViewReducer';
+export type ActionType = ReturnType<typeof saveRoutine> | ReturnType<typeof saveRoutineSuccess> | ReturnType<typeof saveRoutineFailure> | ReturnType<typeof fetchRoutines>;
+/**
+ * POST /1.0/routines (create) or PUT /1.0/routines/{scheduleId} (update).
+ *
+ * One epic for both: to a user they are the same act, and the server answers
+ * both with the routine. Splitting them would duplicate the body mapping and
+ * the error handling for a difference the form does not have.
+ */
+export declare const saveRoutineEpic: (actions$: ActionsObservable<ActionType>, _state$: unknown, zeniAPI: ZeniAPI) => Observable<ActionType>;

package/lib/view/aiCfoView/epics/saveRoutineEpic.js

@@ -0,0 +1,69 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.saveRoutineEpic = void 0;
+const rxjs_1 = require("rxjs");
+const operators_1 = require("rxjs/operators");
+const responsePayload_1 = require("../../../responsePayload");
+const aiCfoViewReducer_1 = require("../aiCfoViewReducer");
+/**
+ * POST /1.0/routines (create) or PUT /1.0/routines/{scheduleId} (update).
+ *
+ * One epic for both: to a user they are the same act, and the server answers
+ * both with the routine. Splitting them would duplicate the body mapping and
+ * the error handling for a difference the form does not have.
+ */
+const saveRoutineEpic = (actions$, _state$, zeniAPI) => actions$.pipe((0, operators_1.filter)(aiCfoViewReducer_1.saveRoutine.match), 
+// exhaustMap, and neither of the obvious two.
+//
+// switchMap is wrong: it cancels the client's subscription, not the request
+// that already left the browser. The routine is still created; the client
+// just stops listening and never tells the user.
+//
+// mergeMap is wrong for the same reason in reverse: a double-clicked Save
+// sends two POSTs, and the user gets two routines that both email them the
+// company's financials on the same schedule.
+//
+// exhaustMap ignores further saves while one is in flight, which is exactly
+// what a submit button should do.
+(0, operators_1.exhaustMap)((action) => {
+    const { draft, scheduleId } = action.payload;
+    const base = `${zeniAPI.apiEndPoints.aiCfoMicroServiceBaseUrl}/1.0/routines`;
+    const isUpdate = scheduleId != null && scheduleId !== '';
+    const body = {
+        name: draft.name,
+        recurrence: draft.recurrence,
+        hour: draft.hour,
+        minute: draft.minute ?? 0,
+        tz_name: draft.tzName,
+        // Spread rather than sent as null. `weekday` and `day_of_month` are
+        // meaningful only for their own recurrence, and the server validates
+        // that pairing — sending a stale weekday alongside a monthly cadence is
+        // a 400 rather than a field politely ignored.
+        ...(draft.recurrence === 'weekly' &&
+            draft.weekday != null && { weekday: draft.weekday }),
+        ...(draft.recurrence === 'monthly' &&
+            draft.dayOfMonth != null && { day_of_month: draft.dayOfMonth }),
+        ...(draft.enabled != null && { enabled: draft.enabled }),
+        // `macro_id` is create-only: re-sending it on an update would let an
+        // edit silently repoint a schedule at a different skill.
+        ...(!isUpdate && draft.macroId != null && { macro_id: draft.macroId }),
+        // `prompt` is allowed on both. On update the server accepts it only for
+        // a one-off, where it saves a new version of the routine's own
+        // instructions — that is editing what this routine says, not repointing
+        // it at someone else's skill.
+        ...(draft.prompt != null && { prompt: draft.prompt }),
+    };
+    const request$ = isUpdate
+        ? zeniAPI.putAndGetJSON(`${base}/${encodeURIComponent(scheduleId)}`, body)
+        : zeniAPI.postAndGetJSON(base, body);
+    return request$.pipe((0, operators_1.mergeMap)((response) => {
+        if (!(0, responsePayload_1.isSuccessResponse)(response)) {
+            return (0, rxjs_1.of)((0, aiCfoViewReducer_1.saveRoutineFailure)(response.status));
+        }
+        // Refetch rather than splice the response in: a create changes the
+        // list's ordering, and the server recomputes `next_run_at` on every
+        // write, so a local insert would show a time the next load moves.
+        return (0, rxjs_1.of)((0, aiCfoViewReducer_1.saveRoutineSuccess)(), (0, aiCfoViewReducer_1.fetchRoutines)());
+    }), (0, operators_1.catchError)((error) => (0, rxjs_1.of)((0, aiCfoViewReducer_1.saveRoutineFailure)((0, responsePayload_1.createZeniAPIStatus)('Unexpected Error', 'Save routine REST API call failed', error instanceof Error ? { message: error.message } : undefined)))));
+}));
+exports.saveRoutineEpic = saveRoutineEpic;

package/lib/view/aiCfoView/epics/setRoutineEnabledEpic.d.ts

@@ -0,0 +1,15 @@
+import { ActionsObservable } from 'redux-observable';
+import { Observable } from 'rxjs';
+import { ZeniAPI } from '../../../zeniAPI';
+import { fetchRoutines, saveRoutineFailure, saveRoutineSuccess, setRoutineEnabled } from '../aiCfoViewReducer';
+export type ActionType = ReturnType<typeof setRoutineEnabled> | ReturnType<typeof saveRoutineSuccess> | ReturnType<typeof saveRoutineFailure> | ReturnType<typeof fetchRoutines>;
+/**
+ * PUT /1.0/routines/{scheduleId} with nothing but `enabled`.
+ *
+ * Separate from `saveRoutineEpic` because pausing is not editing. A routine
+ * whose cadence this client version does not recognise has `recurrence: null`
+ * and cannot produce a `RoutineDraft` — and that is precisely the routine
+ * someone most needs to be able to stop. Sending only `enabled` also means a
+ * pause can never rewrite a schedule as a side effect.
+ */
+export declare const setRoutineEnabledEpic: (actions$: ActionsObservable<ActionType>, _state$: unknown, zeniAPI: ZeniAPI) => Observable<ActionType>;

package/lib/view/aiCfoView/epics/setRoutineEnabledEpic.js

@@ -0,0 +1,32 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.setRoutineEnabledEpic = void 0;
+const rxjs_1 = require("rxjs");
+const operators_1 = require("rxjs/operators");
+const responsePayload_1 = require("../../../responsePayload");
+const aiCfoViewReducer_1 = require("../aiCfoViewReducer");
+/**
+ * PUT /1.0/routines/{scheduleId} with nothing but `enabled`.
+ *
+ * Separate from `saveRoutineEpic` because pausing is not editing. A routine
+ * whose cadence this client version does not recognise has `recurrence: null`
+ * and cannot produce a `RoutineDraft` — and that is precisely the routine
+ * someone most needs to be able to stop. Sending only `enabled` also means a
+ * pause can never rewrite a schedule as a side effect.
+ */
+const setRoutineEnabledEpic = (actions$, _state$, zeniAPI) => actions$.pipe((0, operators_1.filter)(aiCfoViewReducer_1.setRoutineEnabled.match), 
+// mergeMap: pausing one routine must not cancel pausing another, and these
+// target different rows so they cannot collide the way two saves of one
+// form would.
+(0, operators_1.mergeMap)((action) => {
+    const { enabled, scheduleId } = action.payload;
+    return zeniAPI
+        .putAndGetJSON(`${zeniAPI.apiEndPoints.aiCfoMicroServiceBaseUrl}/1.0/routines/${encodeURIComponent(scheduleId)}`, { enabled })
+        .pipe((0, operators_1.mergeMap)((response) => (0, responsePayload_1.isSuccessResponse)(response)
+        ? (0, rxjs_1.of)((0, aiCfoViewReducer_1.saveRoutineSuccess)(), (0, aiCfoViewReducer_1.fetchRoutines)())
+        : // Refetch on failure too: the switch was flipped optimistically,
+            // and leaving it showing "paused" for a routine that is still
+            // running would be the one lie this list must not tell.
+            (0, rxjs_1.of)((0, aiCfoViewReducer_1.saveRoutineFailure)(response.status), (0, aiCfoViewReducer_1.fetchRoutines)())), (0, operators_1.catchError)((error) => (0, rxjs_1.of)((0, aiCfoViewReducer_1.saveRoutineFailure)((0, responsePayload_1.createZeniAPIStatus)('Unexpected Error', 'Set routine enabled REST API call failed', error instanceof Error ? { message: error.message } : undefined)), (0, aiCfoViewReducer_1.fetchRoutines)())));
+}));
+exports.setRoutineEnabledEpic = setRoutineEnabledEpic;

package/lib/view/aiCfoView/epics/toRoutine.d.ts

@@ -0,0 +1,17 @@
+import { RoutinePayload } from '../aiCfoViewPayload';
+import { Routine } from '../aiCfoViewState';
+/**
+ * A routine is usable if it has an identity. That is the whole bar.
+ *
+ * `schedule_id` and `name` are what every consumer dereferences, so those are
+ * what this establishes.
+ *
+ * Deliberately NOT also requiring `macro_id`. A routine whose skill was deleted
+ * can come back without one — and it is still an active schedule emailing the
+ * user's financials. Dropping it here would make it invisible in the UI while
+ * it kept running, with no way for anyone to turn it off. Showing a broken row
+ * that can be paused or deleted is strictly better than hiding a live one.
+ */
+export declare const isRoutinePayload: (value: unknown) => value is RoutinePayload;
+/** Map one routine off the wire. Every default here is a deliberate reading. */
+export declare const toRoutine: (payload: RoutinePayload) => Routine;

package/lib/view/aiCfoView/epics/toRoutine.js

@@ -0,0 +1,69 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.toRoutine = exports.isRoutinePayload = void 0;
+const RECURRENCES = ['daily', 'weekly', 'monthly'];
+const STATUSES = ['succeeded', 'failed', 'timeout'];
+/**
+ * A routine is usable if it has an identity. That is the whole bar.
+ *
+ * `schedule_id` and `name` are what every consumer dereferences, so those are
+ * what this establishes.
+ *
+ * Deliberately NOT also requiring `macro_id`. A routine whose skill was deleted
+ * can come back without one — and it is still an active schedule emailing the
+ * user's financials. Dropping it here would make it invisible in the UI while
+ * it kept running, with no way for anyone to turn it off. Showing a broken row
+ * that can be paused or deleted is strictly better than hiding a live one.
+ */
+const isRoutinePayload = (value) => {
+    const candidate = value;
+    return (typeof candidate?.schedule_id === 'string' &&
+        candidate.schedule_id !== '' &&
+        typeof candidate.name === 'string');
+};
+exports.isRoutinePayload = isRoutinePayload;
+/**
+ * Narrow a server string to a known recurrence, or null.
+ *
+ * Null, NOT a fallback to 'daily'. A read-side default becomes a write-side
+ * value the moment the user opens that routine and saves it — so guessing here
+ * would quietly convert a cadence this client does not understand into a daily
+ * one, and the owner would find out from the volume of email. Null says "this
+ * client does not know", and the UI shows the row so it can still be paused or
+ * deleted while refusing to edit its schedule.
+ */
+const toRecurrence = (value) => RECURRENCES.includes(value)
+    ? value
+    : null;
+const toStatus = (value) => STATUSES.includes(value) ? value : null;
+/** Map one routine off the wire. Every default here is a deliberate reading. */
+const toRoutine = (payload) => ({
+    unreadRuns: payload.unread_runs ?? 0,
+    consecutiveFailures: payload.consecutive_failures ?? 0,
+    dayOfMonth: payload.day_of_month ?? null,
+    // Absent reads as enabled: a routine the server returned without the flag is
+    // one it intends to run, and defaulting to false would show every row paused.
+    enabled: payload.enabled !== false,
+    hour: payload.hour ?? 0,
+    isAdHoc: payload.is_ad_hoc === true,
+    lastRunAt: payload.last_run_at ?? null,
+    lastStatus: toStatus(payload.last_status),
+    // '' is the sanctioned "unset ID" (CLAUDE.md), not a papered-over absence:
+    // the row still renders, and the UI reads this to show it as broken rather
+    // than offering to open a skill that is not there.
+    macroId: payload.macro_id ?? '',
+    minute: payload.minute ?? 0,
+    name: payload.name,
+    nextRunAt: payload.next_run_at ?? null,
+    pinnedVersion: payload.pinned_version ?? null,
+    recurrence: toRecurrence(payload.recurrence),
+    scheduleId: payload.schedule_id,
+    sessionId: payload.session_id ?? null,
+    // Null, not a guessed 'UTC'. Same trap as `recurrence`: a read-side default
+    // is written straight back on the next save, silently moving the routine's
+    // delivery by however many hours the real zone differed by. The server always
+    // sends this, so null means something is wrong and the UI should say so.
+    tzName: payload.tz_name ?? null,
+    weekday: payload.weekday ?? null,
+});
+exports.toRoutine = toRoutine;

package/lib/view/aiCfoView/epics/toRoutineRun.d.ts

@@ -0,0 +1,12 @@
+import { RoutineRunPayload } from '../aiCfoViewPayload';
+import { RoutineRun } from '../aiCfoViewState';
+/**
+ * A run is usable if it has an identity — the same bar `isRoutinePayload` sets.
+ *
+ * Nothing else is required. A run that is still in flight has no `finished_at`,
+ * a claimed one has no `started_at`, and a failed one may have neither an error
+ * nor an answer to link to. Requiring any of those would drop exactly the rows
+ * the history exists to show.
+ */
+export declare const isRoutineRunPayload: (value: unknown) => value is RoutineRunPayload;
+export declare const toRoutineRun: (payload: RoutineRunPayload) => RoutineRun;

package/lib/view/aiCfoView/epics/toRoutineRun.js

@@ -0,0 +1,47 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.toRoutineRun = exports.isRoutineRunPayload = void 0;
+const STATUSES = [
+    'claimed',
+    'running',
+    'succeeded',
+    'failed',
+    'timeout',
+];
+/**
+ * A run is usable if it has an identity — the same bar `isRoutinePayload` sets.
+ *
+ * Nothing else is required. A run that is still in flight has no `finished_at`,
+ * a claimed one has no `started_at`, and a failed one may have neither an error
+ * nor an answer to link to. Requiring any of those would drop exactly the rows
+ * the history exists to show.
+ */
+const isRoutineRunPayload = (value) => {
+    const candidate = value;
+    return typeof candidate?.run_id === 'string' && candidate.run_id !== '';
+};
+exports.isRoutineRunPayload = isRoutineRunPayload;
+/**
+ * Narrow a server status to one this client knows, or null.
+ *
+ * Null rather than a fallback, for the same reason `toRecurrence` returns null:
+ * a guess here would badge an unknown state as something specific, and on a run
+ * history the difference between "failed" and "we don't know" is the whole
+ * message. The UI shows an unknown status as neither succeeded nor failed.
+ */
+const toStatus = (value) => STATUSES.find((status) => status === value) ?? null;
+/** Empty strings become null: the server sends '' for an absent deep link. */
+const toId = (value) => value != null && value !== '' ? value : null;
+const toRoutineRun = (payload) => ({
+    runId: payload.run_id,
+    attempt: payload.attempt ?? 1,
+    isManual: payload.is_manual === true,
+    error: toId(payload.error),
+    finishedAt: toId(payload.finished_at),
+    questionAnswerId: toId(payload.question_answer_id),
+    sessionId: toId(payload.session_id),
+    scheduledFor: toId(payload.scheduled_for),
+    startedAt: toId(payload.started_at),
+    status: toStatus(payload.status),
+});
+exports.toRoutineRun = toRoutineRun;

package/lib/view/cashFlowClassesView/cashFlowClassesViewPayload.d.ts

@@ -1,14 +1,14 @@
-import { ReportByClassMetadataPayloadV2, SectionByClassCOABalanceGroupedPayloadV2 } from '../../commonPayloadTypes/classesView/reportByClassPayloadV2';
+import { CalculatedSectionByClassCOABalanceGroupedPayloadV2, ReportByClassMetadataPayloadV2, SectionByClassCOABalanceGroupedPayloadV2 } from '../../commonPayloadTypes/classesView/reportByClassPayloadV2';
 import { ZeniReportResponse } from '../../responsePayload';
 interface OperatingActivitiesClassesView {
     adjustments: SectionByClassCOABalanceGroupedPayloadV2;
-    net_income: SectionByClassCOABalanceGroupedPayloadV2;
+    net_income: CalculatedSectionByClassCOABalanceGroupedPayloadV2;
 }
 export interface CashFlowClassesViewPayload extends ReportByClassMetadataPayloadV2 {
-    change_in_cash_and_equivalents: SectionByClassCOABalanceGroupedPayloadV2;
+    change_in_cash_and_equivalents: CalculatedSectionByClassCOABalanceGroupedPayloadV2;
     financing_activities: SectionByClassCOABalanceGroupedPayloadV2;
     investing_activities: SectionByClassCOABalanceGroupedPayloadV2;
-    operating_activities: SectionByClassCOABalanceGroupedPayloadV2 & OperatingActivitiesClassesView;
+    operating_activities: CalculatedSectionByClassCOABalanceGroupedPayloadV2 & OperatingActivitiesClassesView;
 }
 export type CashFlowReportClassesViewResponse = ZeniReportResponse<CashFlowClassesViewPayload>;
 export {};

package/lib/view/cashFlowProjectView/cashFlowProjectViewPayload.d.ts

@@ -1,14 +1,14 @@
 import { ZeniReportResponse } from '../../responsePayload';
-import { ReportByProjectMetadataPayloadV2, SectionByProjectCOABalanceGroupedPayloadV2 } from '../profitAndLossProjectView/profitAndLossProjectViewPayload';
+import { CalculatedSectionByProjectCOABalanceGroupedPayloadV2, ReportByProjectMetadataPayloadV2, SectionByProjectCOABalanceGroupedPayloadV2 } from '../profitAndLossProjectView/profitAndLossProjectViewPayload';
 interface OperatingActivitiesProjectView {
     adjustments: SectionByProjectCOABalanceGroupedPayloadV2;
-    net_income: SectionByProjectCOABalanceGroupedPayloadV2;
+    net_income: CalculatedSectionByProjectCOABalanceGroupedPayloadV2;
 }
 export interface CashFlowProjectViewPayload extends ReportByProjectMetadataPayloadV2 {
-    change_in_cash_and_equivalents: SectionByProjectCOABalanceGroupedPayloadV2;
+    change_in_cash_and_equivalents: CalculatedSectionByProjectCOABalanceGroupedPayloadV2;
     financing_activities: SectionByProjectCOABalanceGroupedPayloadV2;
     investing_activities: SectionByProjectCOABalanceGroupedPayloadV2;
-    operating_activities: SectionByProjectCOABalanceGroupedPayloadV2 & OperatingActivitiesProjectView;
+    operating_activities: CalculatedSectionByProjectCOABalanceGroupedPayloadV2 & OperatingActivitiesProjectView;
 }
 export type CashFlowReportProjectViewResponse = ZeniReportResponse<CashFlowProjectViewPayload>;
 export {};

package/lib/view/invoicing/editInvoicingCustomerDetailView/editInvoicingCustomerDetailViewPayload.d.ts

@@ -1,7 +1,7 @@
 import { InvoicingCustomerPayload } from '../../../entity/invoicing/invoicingCustomer/invoicingCustomerPayload';
 import { ZeniAPIResponse } from '../../../responsePayload';
 import { AddressUpdatableInfo } from '../../addressView/addressViewState';
-import { InvoicingCustomerFormLocalData } from './editInvoicingCustomerDetailViewState';
+import { InvoicingCustomerFormLocalData, InvoicingPaymentLinkEmailPreviewData } from './editInvoicingCustomerDetailViewState';
 export type SaveInvoicingCustomerResponse = ZeniAPIResponse<InvoicingCustomerPayload>;
 /**
  * Build the create/update customer request body from the form draft. The
@@ -25,15 +25,5 @@ export type InvoicingPaymentLinkEmailPreviewResponse = ZeniAPIResponse<Invoicing
  * The email rendered once with sentinel tokens standing in for the subject and
  * body, so the composer can splice a draft into it without another request.
  */
-export interface InvoicingPaymentLinkEmailPreviewData {
-    /** Default body prefill, plain text. */
-    body: string;
-    bodyToken: string;
-    renderedHtmlTemplate: string;
-    /** Default subject prefill. */
-    subject: string;
-    subjectToken: string;
-    to: string;
-}
 export declare const toInvoicingPaymentLinkEmailPreview: (payload: InvoicingPaymentLinkEmailPreviewPayload) => InvoicingPaymentLinkEmailPreviewData;
 export type AddPromotionalCreditsResponse = ZeniAPIResponse<InvoicingCustomerPayload>;

package/lib/view/invoicing/editInvoicingCustomerDetailView/editInvoicingCustomerDetailViewPayload.js

@@ -34,6 +34,10 @@ const localDataToSaveInvoicingCustomerPayload = (localData, billingAddress) => {
     };
 };
 exports.localDataToSaveInvoicingCustomerPayload = localDataToSaveInvoicingCustomerPayload;
+/**
+ * The email rendered once with sentinel tokens standing in for the subject and
+ * body, so the composer can splice a draft into it without another request.
+ */
 const toInvoicingPaymentLinkEmailPreview = (payload) => ({
     body: payload.body,
     bodyToken: payload.body_token,

package/lib/view/invoicing/editInvoicingCustomerDetailView/editInvoicingCustomerDetailViewReducer.d.ts

@@ -1,7 +1,6 @@
 import { ID } from '../../../commonStateTypes/common';
 import { ZeniAPIStatus } from '../../../responsePayload';
-import { InvoicingPaymentLinkEmailPreviewData } from './editInvoicingCustomerDetailViewPayload';
-import { EditInvoicingCustomerDetailViewState, InvoicingCustomerFormLocalData } from './editInvoicingCustomerDetailViewState';
+import { EditInvoicingCustomerDetailViewState, InvoicingCustomerFormLocalData, InvoicingPaymentLinkEmailPreviewData } from './editInvoicingCustomerDetailViewState';
 /** Add promotional credits to a customer. */
 export interface SubmitAddPromotionalCreditsPayload {
     amount: number;

package/lib/view/invoicing/editInvoicingCustomerDetailView/editInvoicingCustomerDetailViewSelector.d.ts

@@ -5,8 +5,7 @@ import { InvoicingFieldHelpByCode, InvoicingNamedOption } from '../../../entity/
 import { InvoicingCustomer, InvoicingCustomerPaymentMethod } from '../../../entity/invoicing/invoicingCustomer/invoicingCustomerState';
 import { RootState } from '../../../rootStateTypes';
 import { InvoicingSetupIntent } from '../customerPaymentMethod/customerPaymentMethodState';
-import { InvoicingPaymentLinkEmailPreviewData } from './editInvoicingCustomerDetailViewPayload';
-import { InvoicingCustomerFormLocalData } from './editInvoicingCustomerDetailViewState';
+import { InvoicingCustomerFormLocalData, InvoicingPaymentLinkEmailPreviewData } from './editInvoicingCustomerDetailViewState';
 /**
  * Read-only view for the customer detail page: the customer entity + its fetch
  * state, plus everything the page renders in view mode — recent invoices, the

package/lib/view/invoicing/editInvoicingCustomerDetailView/editInvoicingCustomerDetailViewState.d.ts

@@ -1,5 +1,19 @@
 import { FetchStateAndError, FetchedState, ID } from '../../../commonStateTypes/common';
-import { InvoicingPaymentLinkEmailPreviewData } from './editInvoicingCustomerDetailViewPayload';
+/**
+ * The payment-link email the composer opens with: the backend's prefill plus
+ * the tokens the frontend splices the user's edits into. State, not wire shape
+ * — `toInvoicingPaymentLinkEmailPreview` in the payload file maps onto it.
+ */
+export interface InvoicingPaymentLinkEmailPreviewData {
+    /** Default body prefill, plain text. */
+    body: string;
+    bodyToken: string;
+    renderedHtmlTemplate: string;
+    /** Default subject prefill. */
+    subject: string;
+    subjectToken: string;
+    to: string;
+}
 /**
  * Draft form state for the create/edit customer form. Held in CES so the form
  * flows its data from here (mirrors the bill-pay / reimbursement pattern). The

package/lib/view/invoicing/invoicingCustomerListView/invoicingCustomerListViewReducer.d.ts

@@ -26,7 +26,7 @@ export declare const fetchInvoicingCustomerList: import("@reduxjs/toolkit").Acti
     ids: ID[];
     keepExistingListItems: boolean;
     nextCursor: string | null;
-}, "invoicingCustomerListView/updateInvoicingCustomerList">, updateInvoicingCustomerListFailure: import("@reduxjs/toolkit").ActionCreatorWithPayload<ZeniAPIStatus<Record<string, unknown>>, "invoicingCustomerListView/updateInvoicingCustomerListFailure">, fetchInvoicingCustomerCounts: import("@reduxjs/toolkit").ActionCreatorWithoutPayload<"invoicingCustomerListView/fetchInvoicingCustomerCounts">, updateInvoicingCustomerCounts: import("@reduxjs/toolkit").ActionCreatorWithPayload<InvoicingListCounts, "invoicingCustomerListView/updateInvoicingCustomerCounts">, updateInvoicingCustomerCountsFailure: import("@reduxjs/toolkit").ActionCreatorWithPayload<ZeniAPIStatus<Record<string, unknown>>, "invoicingCustomerListView/updateInvoicingCustomerCountsFailure">, updateInvoicingCustomerFilters: import("@reduxjs/toolkit").ActionCreatorWithPayload<InvoicingCustomerFilters, "invoicingCustomerListView/updateInvoicingCustomerFilters">, setInvoicingCustomerActiveTab: import("@reduxjs/toolkit").ActionCreatorWithPayload<"active" | "all" | "at_risk" | "trial", "invoicingCustomerListView/setInvoicingCustomerActiveTab">, addInvoicingCustomerToList: import("@reduxjs/toolkit").ActionCreatorWithPayload<{
+}, "invoicingCustomerListView/updateInvoicingCustomerList">, updateInvoicingCustomerListFailure: import("@reduxjs/toolkit").ActionCreatorWithPayload<ZeniAPIStatus<Record<string, unknown>>, "invoicingCustomerListView/updateInvoicingCustomerListFailure">, fetchInvoicingCustomerCounts: import("@reduxjs/toolkit").ActionCreatorWithoutPayload<"invoicingCustomerListView/fetchInvoicingCustomerCounts">, updateInvoicingCustomerCounts: import("@reduxjs/toolkit").ActionCreatorWithPayload<InvoicingListCounts, "invoicingCustomerListView/updateInvoicingCustomerCounts">, updateInvoicingCustomerCountsFailure: import("@reduxjs/toolkit").ActionCreatorWithPayload<ZeniAPIStatus<Record<string, unknown>>, "invoicingCustomerListView/updateInvoicingCustomerCountsFailure">, updateInvoicingCustomerFilters: import("@reduxjs/toolkit").ActionCreatorWithPayload<InvoicingCustomerFilters, "invoicingCustomerListView/updateInvoicingCustomerFilters">, setInvoicingCustomerActiveTab: import("@reduxjs/toolkit").ActionCreatorWithPayload<"active" | "all" | "trial" | "at_risk", "invoicingCustomerListView/setInvoicingCustomerActiveTab">, addInvoicingCustomerToList: import("@reduxjs/toolkit").ActionCreatorWithPayload<{
     id: ID;
     status?: string;
 }, "invoicingCustomerListView/addInvoicingCustomerToList">;