@goodandready/dsh-cron 0.2.5 → 0.2.7

package/lib/silent-rule.js

@@ -0,0 +1,100 @@
+/**
+ * The "silent rule" (#44): a plain-language condition that decides whether a
+ * successful run is worth alerting about.
+ *
+ * A script that runs every 30 minutes usually produces nothing interesting, and
+ * `onlyOnFailure` cannot tell "the disk is at 12%" from "the disk is at 96%".
+ * The rule is written by the user in words; a cheap model call turns it into a
+ * yes/no verdict with a reason.
+ *
+ * Fail-open by design: no rule, no model, a broken call or an unusable answer all
+ * mean "deliver the report". Silence is only ever produced by an explicit
+ * verdict.
+ */
+
+import { askModel, parseJsonAnswer, resolveAskTarget } from './llm-ask.js';
+
+/** Task types whose runs produce output a rule can judge. */
+export const SILENT_RULE_TASK_TYPES = ['script', 'node', 'python', 'http'];
+
+export function supportsSilentRule(task) {
+  return SILENT_RULE_TASK_TYPES.includes(String(task && task.type ? task.type : 'script'));
+}
+
+const SYSTEM_PROMPT = [
+  'You decide whether a monitoring job should notify its owner.',
+  'Answer with a single JSON object and nothing else:',
+  '{"notify": true|false, "reason": "short explanation"}',
+  'Be conservative: when the output shows a problem, a warning, an error or anything uncertain, notify.',
+  'Only stay silent when the output clearly matches the condition for silence.',
+].join(' ');
+
+export function buildSilentRulePrompt(task, runInfo) {
+  const output = String((runInfo && runInfo.output) || '').slice(0, 4000);
+  return [
+    `Task: ${task.title || 'scheduled task'} (type: ${task.type || 'script'})`,
+    `Schedule: ${task.scheduleText || task.schedule || ''}`,
+    `Exit status: ${(runInfo && runInfo.status) || 'success'}`,
+    '',
+    'Condition for staying silent:',
+    String(task.silentRule || '').trim(),
+    '',
+    'Output of the run:',
+    '```',
+    output || '(no output)',
+    '```',
+  ].join('\n');
+}
+
+/** Turn a model answer into a verdict; anything unusable means "notify". */
+export function readVerdict(text) {
+  const parsed = parseJsonAnswer(text);
+  if (!parsed || typeof parsed.notify !== 'boolean') {
+    return { ok: false, error: 'the model did not answer with a notify verdict' };
+  }
+  return { ok: true, notify: parsed.notify, reason: String(parsed.reason || '').slice(0, 500) };
+}
+
+/**
+ * Decide whether a finished run should be delivered.
+ * Returns `{ skipped, reason, verdictError? }`; `skipped` is true only after an
+ * explicit "stay silent" verdict.
+ */
+export async function applySilentRule({ task, runInfo, ask, preferredModel, timeoutMs }) {
+  if (!task || !task.silentRule || String(task.silentRule).trim() === '') {
+    return { skipped: false, reason: '' };
+  }
+  if ((runInfo && runInfo.status) !== 'success') {
+    return { skipped: false, reason: '', note: 'the rule only judges successful runs' };
+  }
+  if (typeof ask !== 'function') {
+    return { skipped: false, reason: '', verdictError: 'no model is available for the silent rule' };
+  }
+  try {
+    const result = await ask({
+      task,
+      prompt: buildSilentRulePrompt(task, runInfo),
+      system: SYSTEM_PROMPT,
+      preferredModel,
+      maxTokens: 200,
+      timeoutMs,
+    });
+    if (!result || !result.ok) {
+      return { skipped: false, reason: '', verdictError: (result && result.error) || 'the model call failed' };
+    }
+    const verdict = readVerdict(result.text);
+    if (!verdict.ok) return { skipped: false, reason: '', verdictError: verdict.error };
+    return { skipped: verdict.notify === false, reason: verdict.reason };
+  } catch (err) {
+    // The rule never decides by failing: a thrown model call means "deliver".
+    return { skipped: false, reason: '', verdictError: (err && err.message) || String(err) };
+  }
+}
+
+/** Ask helper bound to a context, used by the scheduler. */
+export function makeAsk(ctx) {
+  return async ({ prompt, system, preferredModel, maxTokens, timeoutMs, task }) => {
+    const target = resolveAskTarget(ctx, task || {}, preferredModel);
+    return askModel(ctx, { ...target, prompt, system, maxTokens, timeoutMs });
+  };
+}

package/lib/store.js

@@ -8,8 +8,8 @@ import { getDshDefaultTelegramCredentials } from './telegram.js';
  * DSH_DATA_DIR wins when the harness sets it. Otherwise the profile home
  * (DSH_HOME) is authoritative: falling back to ~/.dsh would make an isolated
  * profile — a test contour, a second profile — write its tasks into another
- * home's data directory, which is how the MiniPC test cycle leaked a task into
- * the non-test profile.
+ * home's data directory, which is how an isolated test cycle once leaked a
+ * task into the wrong profile.
  */
 export function getDefaultStorePath() {
   const base = process.env.DSH_DATA_DIR
@@ -139,7 +139,7 @@ export class TaskStore {
    * fields (botTokenRef, ntfyTokenRef, …) take precedence over them.
    */
   static get MASKED_SETTING_KEYS() {
-    return ['botToken', 'discordWebhookUrl', 'slackWebhookUrl', 'barkKey'];
+    return ['botToken', 'discordWebhookUrl', 'slackWebhookUrl', 'barkKey', 'apiToken'];
   }
 
   saveSettings(newSettings = {}) {
@@ -283,6 +283,17 @@ export class TaskStore {
       usage,
       costUsd,
       sessionId: runInfo.sessionId || null,
+      // #45: which model produced the run, and whether it only finished thanks
+      // to the configured fallback.
+      model: runInfo.model || '',
+      fallback: Boolean(runInfo.fallback),
+      // #44: this run was suppressed by its silent rule, with the reason.
+      silentSkip: Boolean(runInfo.silentSkip),
+      silentReason: runInfo.silentSkip ? String(runInfo.silentReason || '').slice(0, 500) : '',
+      // #43: the failure diagnosis and the prompt change it proposes.
+      diagnosis: runInfo.diagnosis ? String(runInfo.diagnosis).slice(0, 1000) : '',
+      suggestion: runInfo.suggestion ? String(runInfo.suggestion).slice(0, 2000) : '',
+      confidence: runInfo.confidence || '',
     });
     if (runs.length > 50) runs.length = 50;
     this.history.set(id, runs);

package/lib/task-patch.js

@@ -0,0 +1,98 @@
+/**
+ * Partial task updates, shared by the HTTP PATCH route and the cron_update_task
+ * tool (#49).
+ *
+ * One implementation keeps the whitelist, the type validation, the schedule
+ * re-parse and the re-scheduling identical on both surfaces; the HTTP route adds
+ * its own cross-origin and confirmation checks on top, while an agent calling the
+ * tool acts on the user's explicit instruction.
+ */
+
+import { parseScheduleExpression } from './scheduler.js';
+import { normalizeTaskType, CODE_EXECUTING_TYPES } from './runtimes.js';
+import { PATCHABLE_TASK_FIELDS, validateTaskType } from './task-transfer.js';
+import { pickPatchableFields } from './http-utils.js';
+import { unknownChannelIds } from './channels.js';
+import { isConfigOwned, configOwnedMessage } from './config-jobs.js';
+
+/** True when a patch changes a task into a type that executes code. */
+export function isCodeTypeSwitch(current, nextType) {
+  if (!current || nextType === undefined) return false;
+  const target = normalizeTaskType(nextType);
+  return CODE_EXECUTING_TYPES.includes(target) && !CODE_EXECUTING_TYPES.includes(current.type);
+}
+
+/**
+ * Normalise a patch: whitelist the fields, resolve the type, re-parse the
+ * schedule so cron patterns and one-shot markers stay consistent.
+ * Returns `{ ok: false, error }` when the merged task would be invalid.
+ */
+export function buildTaskPatch(current, body) {
+  const patch = pickPatchableFields(body || {}, PATCHABLE_TASK_FIELDS);
+  if (patch.type !== undefined) {
+    patch.type = normalizeTaskType(patch.type);
+    const typeError = validateTaskType(patch.type, { ...current, ...patch });
+    if (typeError) return { ok: false, error: typeError };
+  }
+  if (patch.channels !== undefined) {
+    // #121: a typo in a channel id used to be dropped silently, so the client
+    // got ok: true and a task that never notified anyone. The refusal lives
+    // here so the HTTP route and the tool behave identically.
+    const unknown = unknownChannelIds(patch.channels);
+    if (unknown.length) {
+      return { ok: false, error: 'Unknown channel ids: ' + unknown.join(', '), unknownChannels: unknown };
+    }
+  }
+  if (patch.schedule !== undefined) {
+    // An empty schedule would leave an armed task that can never fire.
+    if (!String(patch.schedule).trim()) return { ok: false, error: 'Schedule cannot be empty' };
+    const parsed = parseScheduleExpression(patch.schedule);
+    patch.schedule = parsed.cronPattern || patch.schedule;
+    patch.scheduleText = (body && body.scheduleText) || parsed.humanText;
+    patch.oneShot = Boolean(parsed.isOneShot || (body && body.oneShot));
+  }
+  return { ok: true, patch };
+}
+
+/**
+ * Apply a patch to a stored task and re-arm or pause it.
+ *
+ * Switching a task into a code-executing type is the one change that turns a
+ * harmless schedule into code execution, so it needs explicit confirmation on
+ * EVERY surface: the HTTP route passes the result of its confirmation header,
+ * and the tool exposes its own switch. A prose request in a tool description is
+ * not a gate, so the refusal lives here instead.
+ *
+ * Returns `{ ok: true, task }`, `{ ok: false, error }`, or
+ * `{ ok: false, needsConfirmation: true, error }` for that switch.
+ */
+export function applyTaskPatch({ store, scheduler, id, body, allowCodeSwitch = false }) {
+  const current = store.get(id);
+  if (!current) return { ok: false, notFound: true, error: 'Task not found' };
+  // A task declared in the profile config (#50) is owned by that file: any
+  // change made here disappears at the next start, so the refusal lives with
+  // the patch logic and covers both the HTTP route and the agent tool.
+  if (isConfigOwned(current)) {
+    return { ok: false, configOwned: true, error: configOwnedMessage(id) };
+  }
+  if (isCodeTypeSwitch(current, body && body.type) && allowCodeSwitch !== true) {
+    return {
+      ok: false,
+      needsConfirmation: true,
+      error: `Switching this task to ${normalizeTaskType(body.type)} makes it execute code; confirm that explicitly and retry`,
+    };
+  }
+  const built = buildTaskPatch(current, body);
+  if (!built.ok) return built;
+  const task = store.set({ ...current, ...built.patch, id });
+  if (task.status === 'active') scheduler.scheduleTask(task);
+  else scheduler.pauseTask(id);
+  return { ok: true, task, patch: built.patch };
+}
+
+/** Human-readable summary of what changed, for tool output and logs. */
+export function describeTaskPatch(task, patch) {
+  const keys = Object.keys(patch || {}).filter((k) => k !== 'scheduleText');
+  if (!keys.length) return 'no changes';
+  return keys.map((key) => `${key}=${JSON.stringify(patch[key])}`).join(', ');
+}

package/lib/task-transfer.js

@@ -21,6 +21,10 @@ export const PATCHABLE_TASK_FIELDS = [
   'delivery',
   'provider',
   'model',
+  'fallbackProvider',
+  'fallbackModel',
+  'silentRule',
+  'inspectOnFailure',
   'timezone',
   'misfirePolicy',
   'maxRetries',

package/lib/templates.js

@@ -17,6 +17,8 @@ export const TEMPLATE_VARIABLES = [
   'time',
   'tokens',
   'cost',
+  'model',
+  'diagnosis',
 ];
 
 export const DEFAULT_PLAIN_TEMPLATE = '⏰ {title}\nStatus: {status}\nSchedule: {schedule}\nDuration: {duration}\n{output}';
@@ -60,6 +62,8 @@ export function buildTemplateVars(task, runInfo = {}) {
     time: new Date(runInfo.at || Date.now()).toISOString(),
     tokens: String(tokens),
     cost: `$${Number(runInfo.costUsd || 0).toFixed(4)}`,
+    model: runInfo.model || '',
+    diagnosis: truncateText(runInfo.diagnosis || ''),
   };
 }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@goodandready/dsh-cron",
-  "version": "0.2.5",
+  "version": "0.2.7",
   "description": "Scheduled cron tasks, background automation and agent execution for DeepSeek Harness.",
   "type": "module",
   "main": "lib/index.js",
@@ -14,7 +14,8 @@
     "lib/",
     "cordis.patch.yml",
     "README.md",
-    "docs/",
+    "docs/README.ru.md",
+    "docs/README.zh.md",
     "LICENSE"
   ],
   "scripts": {

package/docs/design/DESIGN.md

@@ -1,81 +0,0 @@
-# DESIGN.md — dsh-cron
-
-## Product / Purpose
-- Назначение: Интегрированный планировщик cron-задач и фоновой автоматизации для DeepSeek Harness. Позволяет запускать агентские сессии по расписанию, выполнять автоматические проверки и предоставлять визуальный интерфейс управления задачами.
-- Аудитория: Пользователи и операторы DeepSeek Harness, автоматизирующие периодические процессы (утренние сводки, проверка тикетов, мониторинг серверов).
-- Статус: Active, публичный npm-пакет @goodandready/dsh-cron (линия 0.2.x).
-
-## User Surfaces
-- Web/UI:
-  - Экран «Запланированные задачи» (полноэкранный оверлей в центральной колонке интерфейса DSH, аналогично dsh-kanban).
-  - Раздел «Активные задачи» в сайдбаре под кнопкой плагина: сворачиваемый (свёрнут по умолчанию, состояние запоминается), до пяти строк с названием и временем следующего запуска или живым статусом, строка «и ещё N»; клик открывает панель и подсвечивает задачу (#34).
-  - Панель фильтров в списке задач: тип, модель, канал; фильтрация мгновенная на клиенте, есть сброс, счётчик «показано N из M» и понятное пустое состояние (#40).
-  - Кнопка вызова в боковой панели (sidebar-entry) рядом с новой сессией + иконка в шапке сессии (utilities slot).
-  - Кнопка «Создать ⌄» с дропдауном:
-    - 💬 «Создать с DSH» (запуск интерактивного диалога постановки задачи агенту).
-    - ✏️ «Настроить вручную» (модальная форма: тип и параметры рантайма, расписание, таймаут, overlap, промпт, модель, каналы доставки, шаблон сообщения).
-  - Табы фильтрации: «Все», «Активные», «На паузе», «Завершённые».
-  - Поисковая строка; сводная статистика (активные задачи, запуски, токены, стоимость).
-  - Карточки задач: статус-переключатель, название, расписание (человекочитаемое + raw cron), действия (запуск, редактирование, удаление).
-  - Блок «Рекомендуемые задачи»: готовые шаблоны (Daily digest, Weekly review, Follow-up monitor) в один клик.
-  - Карточка настроек в слоте settings.plugin.item, key = namespace `dsh-cron`; отдельный раздел настроек не используется (#102).
-- LLM Tools: cron_create_task (+ alias cron_schedule_task), cron_list_tasks, cron_pause_task, cron_resume_task, cron_delete_task, cron_run_task. Параметры задачи включают рантайм (`type`), `channels` (список каналов доставки) и `template` (шаблон сообщения).
-- API: HTTP эндпоинты /dsh-cron/* (tasks, models, chat/start, settings, telegram/test, kanban/test, tasks/:id/actions, legacy action/:id/:action). Мутирующие эндпоинты отклоняют cross-origin запросы; script-задачи по HTTP требуют заголовок x-dsh-cron-confirm. Настройки доставки принимаются как плоские ключи (webhook URL, топики, base URL) и `channelTemplates` — карта шаблонов по каналам.
-- Chat / Slash Commands: отсутствуют (ранее заявленные /cron-команды не были реализованы и удалены из документации; решение 2026-09-09).
-
-## Visual Direction
-- Атмосфера: Строгий утилитарный интерфейс в нативном стиле DeepSeek Harness.
-- Использование нативных токенов темы DSH: --dsw-alias-bg-base, --dsw-alias-bg-layer-*, --dsw-alias-border-l1/l2, --dsw-alias-label-primary/secondary/tertiary, --dsw-alias-interactive-bg-hover.
-- Семантические статусы объявляются один раз через plugin-переменные --dsh-cron-success/danger/info/accent/warning (токен ядра при наличии, иначе фолбэк); рассыпанных hex в инлайн-стилях нет.
-- Иерархия: читаемые карточки с чётким акцентом на статусе и времени следующего запуска.
-
-## Foundations
-- Семантические цвета статусов:
-  - Зелёный/активный: рабочее расписание, успех.
-  - Серый/приостановленный: на паузе.
-  - Синий/информационный: шаблоны, Shell-тип, Telegram-акценты.
-  - Красный: ошибка/таймаут последнего запуска.
-  - Фиолетовый: разовая (one-shot) задача; жёлтый: skipped/missed.
-- Доступность: aria-label у иконок и действий, роль button + управление с клавиатуры (Enter/Space) для строк списков, Escape закрывает модалки, autofocus первого поля формы.
-- Язык: канонические строки — английские (словарь STRINGS.en, namespace dsh-cron, регистрация через ctx.locale.register); русский и другие языки предоставляет translation-плагин в рантайме.
-
-## Components And States
-- Components:
-  - CronSidebarButton: кнопка в левом сайдбаре DSH.
-  - CronScreen: основной оверлей со списком, табами, статистикой и рекомендациями.
-  - CreateDropdown: всплывающее меню выбора способа создания.
-  - ManualTaskModal: модальная форма создания/редактирования (вкладки «Параметры» / «История запусков»); блок каналов доставки — сетка чекбоксов (Telegram, dsh-kanban, Discord, Slack, ntfy, Bark, PushPlus, Voice, Gitea) и поле шаблона сообщения с подсказкой по переменным.
-  - SettingsModal: настройки доставки с тестами; три сворачиваемые секции — «Credentials (references)», «Delivery channels», «Message templates» (шапка-кнопка, aria-expanded, шеврон).
-  - DeliverySettingsForm: общая форма настроек доставки, одна реализация для SettingsModal и CronSettingsCard; секреты вводятся только по имени credential-ссылки.
-  - TaskItem: строка задачи с переключателем состояния и действиями (запуск, редактирование, дублирование, удаление); адресуется атрибутом data-task-id для подсветки из сайдбара.
-  - ImportModal: сводка по файлу (сколько добавится, заменится, пропустится) и выбор стратегии add/replace/skip до применения (#42).
-  - RecommendationCard: плашка с готовым шаблоном.
-  - CronSettingsCard: карточка параметров плагина в настройках; свёрнута по умолчанию, шапка-кнопка с шевроном разворачивает тело (aria-expanded), кнопка «Открыть панель задач» — внутри раскрытого тела (решение 2026-09-10, #100).
-- States:
-  - Loading: индикатор загрузки списка/истории.
-  - Empty: дружелюбный пустой экран со списком рекомендаций.
-  - Error: баннер с ошибкой и кнопкой повтора (в панели), статус-баннеры в модалках.
-  - Success: статус-баннеры тестов доставки, «✓ Сохранено».
-- Опасные действия: удаление задачи — через confirm(); переключение типа на script по HTTP требует confirm-заголовок.
-
-## User Flows
-1. Создание через DSH-чат: «напоминай каждый день в 9 утра...» → «Создать с DSH» → агент уточняет тип (LLM/NO-LLM), расписание, модель, Silent Rule → после подтверждения вызывает cron_create_task → задача появляется на экране.
-2. Создание вручную: кнопка сайдбара → «Создать ⌄» → «Настроить вручную» → форма → сохранение.
-3. Выполнение по расписанию: croner/таймер one-shot → запуск по выбранному рантайму (агентская сессия, shell, node, python, http, ssh, docker) → запись в историю → доставка отчёта в выбранные каналы (Telegram, Kanban, Discord, Slack, ntfy, Bark, PushPlus, Voice, Gitea) с учётом `onlyOnFailure`.
-4. Разбор инцидента: история запусков в карточке задачи → статус, длительность, вывод/ошибка.
-
-## Locked Design Decisions
-- 2026-09-11 — Доставка вынесена в отдельный слой: сообщение рендерится шаблоном `{var}` (#25), транспорт — адаптеры каналов с чистым builder'ом payload и инжектируемым fetch, маршрутизатор собирает ошибки каналов и не роняет запуск (#26, #20–#23, #28, #47). Явно выбранные каналы задачи перекрывают legacy-флаги `notifyTelegram`/`kanbanMode`.
-- 2026-09-11 — Доставка не может заблокировать планировщик: каждый канал ограничен таймаутом (`deliveryTimeoutMs`, по умолчанию 15 с), каналы отправляются параллельно, а ошибки (включая таймаут) собираются в `failures`. Причина: `protect: true` в croner пропускал бы следующие тики, пока висит незавершённая доставка (находка независимого review PR #114).
-- 2026-09-11 — Блок A (0.2.5): список активных задач в сайдбаре (#34), фильтры по типу/модели/каналу (#40), адаптив до 375 px без скрытия информации (#39), дублирование задачи серверным маршрутом с принудительной паузой и сбросом состояния (#41), экспорт/импорт конфигурации задач в JSON со стратегиями и dry-run (#42), нормализация и нижняя граница таймаута доставки (#115). Экспорт — только JSON: YAML-парсера в проекте нет, а зависимость ради формата не добавляется.
-- 2026-09-11 — Значения с секретом внутри (webhook-URL Discord/Slack, ключ Bark) маскируются при отдаче в браузер, а замаскированное значение, вернувшееся от UI, не перезаписывает сохранённое; сырые credential-ключи отклоняются и в store, и на входе `/dsh-cron/settings`.
-- 2026-09-11 — Секреты доставки хранятся только как credential-ссылки (#51): настройки содержат имя credential, значение резолвится в момент отправки через DSH credentials-сервис с фолбэком на ENV; store отказывается сохранять сырые secret-ключи.
-- 2026-09-11 — Каталог данных плагина: `DSH_DATA_DIR` → `DSH_HOME/data` → `~/.dsh/data`. Причина: изолированный профиль не должен писать в чужой домашний каталог (issue #112, найдено на приёмке в тест-контуре).
-- 2026-09-09 — Пакет надёжности ядра (v0.1.24): буфер shell-задач 10МБ, атомарное сохранение с PID, аудит пропущенных запусков при рестарте (missed), фоновый поллинг UI (8с).
-- 2026-09-03 — Публичный скоуп @goodandready/dsh-cron; оверлей через mountSidebarEntry/mountScreen аналогично dsh-kanban; двойная кнопка «Создать ⌄».
-- 2026-09-09 — Слот карточки настроек: settings.plugin.item с key/namespace `dsh-cron` (совпадение с серверной регистрацией). Причина: контракт слота настроек (#85). Changed 2026-09-10 (#102): settings.section fallback удалён — карточка только во вкладке плагинов.
-- 2026-09-10 — Значения настроек пишутся через зарегистрированный settings-скоуп (`scope.set` → `watch` → store); REST /dsh-cron/settings остаётся транспортом для карточки и headless-сценариев; карточка проверяет статус снапшота и не рисует поля до его получения (#102).
-- 2026-09-09 — Английский — канонический язык строк; словарь STRINGS.en регистрируется в ctx.locale; русский — через translation-плагин. Причина: стандарт DSH-плагинов (#87).
-- 2026-09-09 — Same-origin проверка мутирующих эндпоинтов, лимит тела 1 МБ, confirm-заголовок для script-задач. Причина: закрытие CSRF→RCE поверхности (#86).
-- 2026-09-09 — Стилевая изоляция: динамические <style> с data-dsh-plugin="dsh-cron"; цвета только через токены темы + единый блок plugin-переменных. Причина: защита от очистки стилей соседями и поддержка светлой темы (#91).
-- 2026-09-09 — /cron slash-команды удалены из документации (не были реализованы); при появлении продукта — отдельная feature-issue и согласование. Причина: документация = истина (#84).

package/docs/plans/0.2.5-ui-block.md

@@ -1,50 +0,0 @@
-# План: блок A — пользовательские поверхности (0.2.5)
-
-Живой план блока. Обновляется по факту работы; источник истины по задачам —
-Gitea (`goodandready/dsh-cron`), milestone `0.2.5`.
-
-## Состав блока (согласован владельцем)
-
-| Issue | Задача | Сложность |
-|:--|:--|:--|
-| #34 | Сворачиваемый раздел активных задач в сайдбаре | H |
-| #40 | Поиск и фильтры списка задач | M |
-| #39 | Адаптив под узкие экраны | M |
-| #41 | Клонирование задачи | L |
-| #42 | Экспорт/импорт задач (JSON/YAML) | L |
-| #115 | Поле «Delivery timeout»: сброс и нижняя граница | L |
-
-Дальше по согласованию: блок B (0.2.6) — #45, #44, #43, #49, #48;
-блок C (0.2.7) — #54, #50, #53, #97, #121.
-
-## Границы и инварианты
-
-- Один блок → одна ветка `feat/0.2.5-ui-block` → один PR → один релиз 0.2.5.
-- В релиз 0.2.5 также входит уже смёрженное удаление email-канала (#23, PR #120).
-- Клиентская половина остаётся single-file (`lib/client.js`) — требование загрузчика DSH.
-- Новых зависимостей блок не добавляет; экспорт/импорт использует существующие средства разбора.
-- Публичные экспорты `lib/index.js` и контракты маршрутов не ломаются: новые поля — только additive.
-- Секреты в экспортируемом файле отсутствуют: переносятся лишь имена credential-ссылок.
-
-## Вне scope
-
-- Серверная авторизация и внешний API (блок C).
-- Изменения в путях исполнения и работе с моделью (блок B).
-- `#117` (мажор croner), `#95` (scope токена), `#113` (инфраструктура тест-контура) — вне блоков.
-
-## План проверки блока
-
-- `npm test` + новые тесты на каждый пункт (контракт разметки, фильтрация, сериализация, клонирование, клампинг таймаута).
-- `bash deploy.sh check` — тесты, гейт размера пакета, сборка кандидата.
-- Приёмка на изолированном MiniPC: установка кандидата, проверка списка/фильтров/дублей/экспорта-импорта и геометрии на 375/768/1280 в браузере.
-- Независимое ревью PR перед merge.
-
-## Журнал
-
-- 2026-09-11 — блок согласован (A=0.2.5, B=0.2.6, C=0.2.7), созданы milestones и ТЗ по каждой задаче.
-- 2026-09-11 — реализовано: #115 (клампинг таймаута), #41 (дублирование серверным маршрутом), #42 (экспорт/импорт JSON), #40 (фильтры), #39 (адаптив), #34 (аккордеон в сайдбаре). 123/123 тестов, гейт размера 23 файла.
-- Приёмка на MiniPC (изолированный профиль, кандидат из ветки): дубликат — копия `disk-check (copy)` в статусе paused, настройки скопированы, история и счётчики пусты; экспорт — 4 задачи, поля только конфигурации (нет status/totalTokens/lastRunAt/nextRunAt); dry-run импорта — `{add:0, replace:0, skip:4}`, импорт со стратегией add — 4 задачи, все на паузе; битый документ → 400 без изменений в хранилище. В браузере: секция «Active jobs» свёрнута по умолчанию, раскрывается, показывает 3 активные задачи с временем следующего запуска, состояние сохраняется; клик по задаче открывает панель и подсвечивает её; фильтры — 8 → 6 (type=script) → 2 (+channel=ntfy) с подписью «Showing N of 8» и сбросом; дублирование из строки — 9 задач и подтверждение «copy created and paused»; поле таймаута доставки: ввод 4000 сохраняется, очистка возвращает 15000.
-- Ограничение приёмки: смена ширины окна в текущем браузерном транспорте недоступна, поэтому адаптив (#39) проверен наличием и разбором media-query-правил и тестами, а не визуально на 375 px. Это единственный пункт блока без живой визуальной проверки.
-- 2026-09-11 — после независимого ревью (FAIL): импорт переведён на жёсткий whitelist (статус из файла игнорируется, лишние ключи отбрасываются), добавлен confirm-заголовок для документов с code-задачами, зарезервированы id `export`/`import` на создании и импорте, добавлен откат при частичном сбое записи, сайдбар и панель разведены разными атрибутами, добавлен 16px для полей на телефоне, `mountSidebarJobs` разбит на мелкие функции. Проверено живьём: без заголовка 403, с заголовком задача приходит paused с обнулёнными счётчиками и отброшенными лишними ключами; подсветка из сайдбара указывает на строку панели (`.dsh-cron-container .dsh-cron-task-highlight`). 127/127 тестов.
-- 2026-09-11 — релиз: bump 0.2.4 → 0.2.5, тег v0.2.5, npm publish, GitHub Release, установка точной версии в production web-профиль MiniAI и production-проверки. Закрыты #34, #39, #40, #41, #42, #115.
-- Отклонения от первоначального ТЗ (зафиксированы в issue): #41 — сделан отдельный маршрут вместо клиентской сборки payload (сервер знает, что конфигурация, а что состояние запуска, и это тестируемо); #42 — только JSON вместо JSON/YAML (парсера YAML в проекте нет, зависимость ради формата не добавляется); состояние фильтров не пишется в URL-хеш, чтобы не конфликтовать с роутингом SPA.