@zeniai/client-epic-state 5.2.34 → 5.2.36

package/lib/view/profitAndLossProjectView/profitAndLossProjectViewPayload.d.ts

@@ -17,18 +17,6 @@ interface ProjectCOABalanceGroupedPayloadByProjectIdV2 {
 export interface SectionByProjectCOABalanceGroupedPayloadV2 extends COABalanceGroupedPayloadV2 {
     projects: ProjectCOABalanceGroupedPayloadByProjectIdV2;
 }
-interface CalculatedProjectCOABalanceGroupedPayloadByProjectIdV2 {
-    [project_Id: string]: COABalanceGroupedPayloadV2;
-}
-/**
- * A section whose per-project entries carry a time series and nothing else: the
- * backend fills the account-wise map only for the account sections, so the
- * calculated sections (net income, the operating total, change in cash) are
- * grouped by project with no accounts underneath.
- */
-export interface CalculatedSectionByProjectCOABalanceGroupedPayloadV2 extends COABalanceGroupedPayloadV2 {
-    projects: CalculatedProjectCOABalanceGroupedPayloadByProjectIdV2;
-}
 export interface ProfitAndLossProjectViewPayload extends ReportByProjectMetadataPayloadV2 {
     cogs: SectionByProjectCOABalanceGroupedPayloadV2;
     earnings_before_interest_and_tax: COABalanceGroupedPayloadV2;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zeniai/client-epic-state",
-  "version": "5.2.34",
+  "version": "5.2.36",
   "description": "Shared module between Web & Mobile containing required abstractions for state management, async network communication. ",
   "main": "lib/index.js",
   "module": "lib/esm/index.js",

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

@@ -1,35 +0,0 @@
-import { of } from 'rxjs';
-import { catchError, filter, mergeMap } from 'rxjs/operators';
-import { createZeniAPIStatus, isSuccessStatus, } from '../../../responsePayload';
-import { deleteRoutine, deleteRoutineFailure, deleteRoutineSuccess, fetchRoutines, } from '../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.
- */
-export const deleteRoutineEpic = (actions$, _state$, zeniAPI) => actions$.pipe(filter(deleteRoutine.match), 
-// mergeMap: deleting one routine must not cancel the delete of another.
-mergeMap((action) => {
-    const { scheduleId } = action.payload;
-    return zeniAPI
-        .deleteAndGetJSON(`${zeniAPI.apiEndPoints.aiCfoMicroServiceBaseUrl}/1.0/routines/${encodeURIComponent(scheduleId)}`)
-        .pipe(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.
-    isSuccessStatus(response)
-        ? of(deleteRoutineSuccess({ scheduleId }))
-        : of(deleteRoutineFailure({ scheduleId, status: response.status }), fetchRoutines())), catchError((error) => of(deleteRoutineFailure({
-        scheduleId,
-        status: createZeniAPIStatus('Unexpected Error', 'Delete routine REST API call failed', error instanceof Error ? { message: error.message } : undefined),
-    }), fetchRoutines())));
-}));

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

@@ -1,35 +0,0 @@
-import { of } from 'rxjs';
-import { catchError, filter, map, switchMap } from 'rxjs/operators';
-import { createZeniAPIStatus, isSuccessResponse } from '../../../responsePayload';
-import { fetchRoutineRuns, fetchRoutineRunsFailure, fetchRoutineRunsSuccess, } from '../aiCfoViewReducer';
-import { isRoutineRunPayload, toRoutineRun } from './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.
- */
-export const fetchRoutineRunsEpic = (actions$, _state$, zeniAPI) => actions$.pipe(filter(fetchRoutineRuns.match), switchMap((action) => {
-    const { scheduleId } = action.payload;
-    return zeniAPI
-        .getJSON(`${zeniAPI.apiEndPoints.aiCfoMicroServiceBaseUrl}/1.0/routines/${encodeURIComponent(scheduleId)}/runs`)
-        .pipe(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 (!isSuccessResponse(response) || response.data == null) {
-            return fetchRoutineRunsFailure(response.status);
-        }
-        const { data } = response;
-        return 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(isRoutineRunPayload).map(toRoutineRun),
-            scheduleId,
-            sessionId: data.session_id ?? null,
-        });
-    }), catchError((error) => of(fetchRoutineRunsFailure(createZeniAPIStatus('Unexpected Error', 'Fetch routine runs REST API call failed', error instanceof Error ? { message: error.message } : undefined)))));
-}));

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

@@ -1,37 +0,0 @@
-import { of } from 'rxjs';
-import { catchError, filter, mergeMap, switchMap } from 'rxjs/operators';
-import { createZeniAPIStatus, isSuccessResponse } from '../../../responsePayload';
-import { fetchRoutines, fetchRoutinesFailure, fetchRoutinesSuccess, } from '../aiCfoViewReducer';
-import { isRoutinePayload, toRoutine } from './toRoutine';
-/** GET /1.0/routines — the caller's own scheduled runs. */
-export const fetchRoutinesEpic = (actions$, _state$, zeniAPI) => actions$.pipe(filter(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.
-switchMap(() => zeniAPI
-    .getJSON(`${zeniAPI.apiEndPoints.aiCfoMicroServiceBaseUrl}/1.0/routines`)
-    .pipe(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 (!isSuccessResponse(response) || response.data == null) {
-        return of(fetchRoutinesFailure(response.status));
-    }
-    const { data } = response;
-    return of(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(isRoutinePayload)
-            .map(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,
-    }));
-}), catchError((error) => of(fetchRoutinesFailure(createZeniAPIStatus('Unexpected Error', 'Fetch routines REST API call failed', error instanceof Error ? { message: error.message } : undefined)))))));

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

@@ -1,34 +0,0 @@
-import { of } from 'rxjs';
-import { catchError, filter, mergeMap } from 'rxjs/operators';
-import { createZeniAPIStatus, isSuccessStatus } from '../../../responsePayload';
-import { fetchRoutineRuns, fetchRoutines, runRoutine, runRoutineFailure, runRoutineSuccess, } from '../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.
- */
-export const runRoutineEpic = (actions$, _state$, zeniAPI) => actions$.pipe(filter(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.
-mergeMap((action) => {
-    const { scheduleId } = action.payload;
-    return zeniAPI
-        .postAndGetJSON(`${zeniAPI.apiEndPoints.aiCfoMicroServiceBaseUrl}/1.0/routines/${encodeURIComponent(scheduleId)}/run`, {})
-        .pipe(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.
-    isSuccessStatus(response)
-        ? of(runRoutineSuccess(), 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.
-        fetchRoutineRuns({ scheduleId }))
-        : of(runRoutineFailure(response.status))), catchError((error) => of(runRoutineFailure(createZeniAPIStatus('Unexpected Error', 'Run routine REST API call failed', error instanceof Error ? { message: error.message } : undefined)))));
-}));

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

@@ -1,65 +0,0 @@
-import { of } from 'rxjs';
-import { catchError, exhaustMap, filter, mergeMap } from 'rxjs/operators';
-import { createZeniAPIStatus, isSuccessResponse } from '../../../responsePayload';
-import { fetchRoutines, saveRoutine, saveRoutineFailure, saveRoutineSuccess, } from '../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.
- */
-export const saveRoutineEpic = (actions$, _state$, zeniAPI) => actions$.pipe(filter(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.
-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(mergeMap((response) => {
-        if (!isSuccessResponse(response)) {
-            return of(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 of(saveRoutineSuccess(), fetchRoutines());
-    }), catchError((error) => of(saveRoutineFailure(createZeniAPIStatus('Unexpected Error', 'Save routine REST API call failed', error instanceof Error ? { message: error.message } : undefined)))));
-}));

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

@@ -1,28 +0,0 @@
-import { of } from 'rxjs';
-import { catchError, filter, mergeMap } from 'rxjs/operators';
-import { createZeniAPIStatus, isSuccessResponse } from '../../../responsePayload';
-import { fetchRoutines, saveRoutineFailure, saveRoutineSuccess, setRoutineEnabled, } from '../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.
- */
-export const setRoutineEnabledEpic = (actions$, _state$, zeniAPI) => actions$.pipe(filter(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.
-mergeMap((action) => {
-    const { enabled, scheduleId } = action.payload;
-    return zeniAPI
-        .putAndGetJSON(`${zeniAPI.apiEndPoints.aiCfoMicroServiceBaseUrl}/1.0/routines/${encodeURIComponent(scheduleId)}`, { enabled })
-        .pipe(mergeMap((response) => isSuccessResponse(response)
-        ? of(saveRoutineSuccess(), 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.
-            of(saveRoutineFailure(response.status), fetchRoutines())), catchError((error) => of(saveRoutineFailure(createZeniAPIStatus('Unexpected Error', 'Set routine enabled REST API call failed', error instanceof Error ? { message: error.message } : undefined)), fetchRoutines())));
-}));

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

@@ -1,64 +0,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.
- */
-export const isRoutinePayload = (value) => {
-    const candidate = value;
-    return (typeof candidate?.schedule_id === 'string' &&
-        candidate.schedule_id !== '' &&
-        typeof candidate.name === 'string');
-};
-/**
- * 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. */
-export 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,
-});

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

@@ -1,42 +0,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.
- */
-export const isRoutineRunPayload = (value) => {
-    const candidate = value;
-    return typeof candidate?.run_id === 'string' && candidate.run_id !== '';
-};
-/**
- * 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;
-export 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),
-});

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

@@ -1,18 +0,0 @@
-import { ActionsObservable } from 'redux-observable';
-import { Observable } from 'rxjs';
-import { ZeniAPI } from '../../../zeniAPI';
-import { deleteRoutine, deleteRoutineFailure, deleteRoutineSuccess, fetchRoutines } from '../aiCfoViewReducer';
-export type ActionType = ReturnType<typeof deleteRoutine> | ReturnType<typeof deleteRoutineSuccess> | ReturnType<typeof deleteRoutineFailure> | ReturnType<typeof fetchRoutines>;
-/**
- * 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.
- */
-export declare const deleteRoutineEpic: (actions$: ActionsObservable<ActionType>, _state$: unknown, zeniAPI: ZeniAPI) => Observable<ActionType>;

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

@@ -1,39 +0,0 @@
-"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

@@ -1,13 +0,0 @@
-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

@@ -1,39 +0,0 @@
-"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

@@ -1,7 +0,0 @@
-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

@@ -1,41 +0,0 @@
-"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

@@ -1,14 +0,0 @@
-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

@@ -1,38 +0,0 @@
-"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

@@ -1,13 +0,0 @@
-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>;