# GPT 5.4 handoff: Fission CRON plan

## Goal

Составить только план действий по теме Fission cron / time triggers. Не писать реализацию сейчас. Не раздувать ответ. Нужен прагматичный, короткий, пошаговый план.

## What is the topic

В Fission cron-триггеры в документации и CRD называются `TimeTrigger`, а в CLI — `fission timetrigger`.

## Official docs used as source of truth

- https://fission.io/docs/usage/triggers/
- https://fission.io/docs/usage/triggers/timer/
- https://fission.io/docs/reference/crd-reference/
- https://fission.io/docs/reference/fission-cli/fission_timetrigger/
- https://fission.io/docs/reference/fission-cli/fission_timetrigger_create/
- https://fission.io/docs/reference/fission-cli/fission_timetrigger_showschedule/

## Facts to keep in mind

- There is no dedicated `/docs/cron/` page on the official site; relevant official page is `Timer Triggers`.
- Timer triggers run functions on a schedule.
- Cron spec supports 6 fields: seconds, minutes, hours, day of month, month, day of week.
- Readable forms are supported too: `@every 5m`, `@hourly`.
- Schedule output should use server time, not client time.

## CRD facts

- `apiVersion`: `fission.io/v1`
- `kind`: `TimeTrigger`
- `spec.cron` — cron expression
- `spec.functionref` — function reference
- `spec.method` — HTTP method, default `POST`
- `spec.subpath` — subpath, default `/`
- `functionref.type` is `name`
- `functionref.name` is the function name

## CLI facts

### `fission timetrigger`
Subcommands from official docs:
- `create`
- `delete`
- `list`
- `showschedule`
- `update`

### `fission timetrigger create`
Key flags:
- `--name`
- `--function`
- `--cron`
- `--method`
- `--subpath`
- `--spec`
- `--dry`

### `fission timetrigger showschedule`
Key flags:
- `--cron`
- `--round`

## Repo facts

Current repo has a local CRON folder with:
- `CRON/README.md`
- `CRON/CLI.md`
- `CRON/CRD.md`
- `CRON/EXAMPLES.md`
- `CRON/GLOSSARY.md`

Relevant console routes currently visible in code:
- `GET /api/timetriggers`
- `GET /console/api/timetriggers`

This means current console code clearly exposes listing for timetriggers; do not assume create/delete UI is already implemented unless verified separately.

## What the plan should optimize for

- shortest path to useful outcome
- no token waste
- no speculative implementation details
- only actions that are justified by the facts above

## Recommended output format for GPT 5.4

1. One-line conclusion
2. Short numbered plan
3. Risks or unknowns, only if they block the plan
4. No extra explanation

## Plan for mini

1. Зафиксировать целевой результат: что именно нужно сделать с cron в этом проекте.
Нужно выбрать одно из трёх:
`документация`, `console API CRUD`, `UI CRUD/просмотр`, либо полный путь поэтапно.

2. Принять официальный термин как базовый.
В коде и плане опираться на `TimeTrigger`/`timetrigger`, а не на абстрактное “cron”, чтобы не путать CLI, CRD и UI.

3. Разделить текущее состояние на “уже есть” и “надо сделать”.
Уже есть:
`официальная сводка`, `CRON docs`, `GET /api/timetriggers`, `GET /console/api/timetriggers`.
Проверить отдельно:
есть ли `POST/DELETE/UPDATE` для timetriggers в console API, модель запроса, UI-форма, UI-delete.

4. Если цель именно реализация, сначала закрыть backend API.
Минимальный набор:
`CreateTimeTriggerRequest`,
`POST /console/api/timetriggers`,
`DELETE /console/api/timetriggers/:name`,
при необходимости `PUT`.
Логика должна строить CRD `fission.io/v1`, `kind: TimeTrigger` с полями:
`cron`, `functionref`, `method`, `subpath`.

5. После backend закрыть валидацию.
Нужно валидировать:
имя,
существование функции,
непустой `cron`,
при необходимости `method`,
дефолты для `method=POST`, `subpath=/`.
Отдельно не гадать формат cron вручную, если можно отдать это на Fission/его контракт.

6. Затем делать UI только после подтверждённого backend.
Минимум:
список timetriggers,
создание,
удаление,
опционально редактирование.
Если UI не нужен сейчас, не тратить на него время.

7. Тестировать в том же порядке.
Сначала unit/integration на API builder TimeTrigger.
Потом живой сценарий:
создать функцию,
создать timetrigger,
проверить list,
проверить delete.
`showschedule` использовать как вспомогательную проверку cron-строк, а не как часть console API.

8. Документацию держать синхронно с реализацией.
Обновлять только новую папку CRON и соседние материалы, не размазывая контекст по старым документам без необходимости.

9. Не делать лишнего на первом проходе.
Не трогать:
Terraform provider,
сложный scheduler,
расширенные cron-валидаторы,
полный UI-редизайн,
пока не готов минимальный CRUD по TimeTrigger.

10. Рабочий порядок для mini:
сначала поиск фактов в коде,
потом backend routes/models/handlers,
потом тесты,
потом UI,
потом короткая проверка живым сценарием.