@zeniai/client-epic-state 5.2.35 → 5.2.36

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>;

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

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

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

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

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

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

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

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