fission-console/CRON/GPT54_HANDOFF.md

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, потом короткая проверка живым сценарием.