Stage 5 — Give it a schedule

Register a pipeline job on your worker, bind it to a nightly cron, and roll last night's incidents up by region into a table the app reads back — closing the loop on the app you started with.

This stage turns a one-off into standing behaviour. A pipeline job runs every night, rolls the day’s incidents up by region, and writes one row per region into a table Lumen reads back — so the loop closes on the app you started with in Stage 1.

On the Lumen tool server, register a pipeline job "incident_report" with
server.RegisterJob — a Go JobHandler that takes a "region" parameter, reports its
work with ctx.Logger.TaskStarted/TaskCompleted, and upserts one row per region
into an incident_rollups table (UNIQUE on the rollup key so re-runs are
idempotent). Deploy the worker as a long-running service so it gets
DATABASE_URL_LUMEN_INCIDENTS — do NOT use a dibbla.yaml jobs: cron, which cannot
see the database. Then create a pipeline that binds the job to a region and a
5-field nightly cron (server-local time), trigger it manually once so it runs in
the same minute, and show me the newest row in incident_rollups.

What happens next

A schedule is just a promise the platform keeps for you: “run this on its own, every night, without anyone starting it.” You are handing your assistant one piece of work — roll up last night’s incidents by region — and asking it to make that work happen unattended, forever, at 3 a.m. Nothing about the loop below requires you to be awake, or even logged in.

To get there, the assistant will teach the platform two things. First it registers the rollup as a pipeline job on the same tool server you built in Stage 4 — a small piece of Go that reads a region’s incidents and writes one summary row. Then it wraps that job in a pipeline and hands the pipeline a cron schedule: a five-field time expression that means, here, “nightly at 03:00.” The job is the work; the pipeline is the alarm clock that fires it.

Once that is wired, open Pipelines and you will see the job, daily schedule and enabled state — proof the promise is in place before a single night has passed.

The capture fixture, armed: incident_report bound to a daily schedule and ready for its first manual check.

Waiting until 3 a.m. is no way to check your work, so the assistant triggers the pipeline once by hand. The capture fixture completes Collect, Process and Publish with dry_run=false, which makes the worker’s task and log reporting visible. It is deliberately a UI fixture: unlike the handler you build below, it does not connect to Lumen’s database.

The run surface: worker-reported tasks, progress and logs. The database query below — not this fixture — proves that your own rollup handler wrote its row.

Finally the loop closes. The row your handler upserts is the row Lumen reads back, so the rolled-up number appears in the app you started with in Stage 1 — no longer a one-off you kicked off, but a figure that refreshes itself every night. Trigger it twice for the same night and the number updates instead of doubling, which is exactly what makes an unattended nightly job safe to leave running. Because a coding assistant makes its own choices, your table and column names, and the exact shape of the pipeline, may differ from the walkthrough below — the three moving parts (a registered job, a cron that fires it, a row the app reads back) are what to look for.

type IncidentReportJob struct{}

func (j *IncidentReportJob) GetJobID() string   { return "incident_report" }
func (j *IncidentReportJob) GetJobName() string { return "Incident Report" }

func (j *IncidentReportJob) GetParameters() []jobs.JobParameter {
    return []jobs.JobParameter{
        {Name: "region", Type: "string", Required: true},
    }
}

func (j *IncidentReportJob) Execute(ctx *jobs.JobContext) error {
    region := ctx.GetStringArg("region", "")

    // TaskStarted / Progress / TaskCompleted ARE the run UI — see the callout.
    ctx.Logger.TaskStarted("rollup")
    ctx.Logger.Info("rolling up incidents for region " + region)

    // Reads DATABASE_URL_LUMEN_INCIDENTS from the environment, like any service.
    // The UNIQUE constraint on (region, day) makes this upsert idempotent:
    //   INSERT INTO incident_rollups (region, day, open_count, ...)
    //   VALUES (...)
    //   ON CONFLICT (region, day) DO UPDATE SET open_count = EXCLUDED.open_count
    ctx.Logger.TaskCompleted()
    return nil
}

# in main(), before Start():
$server.RegisterJob(&IncidentReportJob{})
# the worker deploys as a long-running service, so DATABASE_URL_LUMEN_INCIDENTS is injected like any service secret

# POST /api/pipelines/:id/trigger runs it immediately, without waiting for the cron
# the run screen shows the 'rollup' task starting and completing

SELECT * FROM incident_rollups
ORDER BY created_at DESC
LIMIT 1;

-- returns the rollup row the run just upserted for its region

Next: someone else uses it

Every stage so far has been about building Lumen. Stage 6 is about the first person who isn’t you — a user who opens the app, hits something they don’t understand, and needs a way to tell you.

Stage 6 → Get help

Also at this point

• Maintenance agent — the app now works unattended, so “who watches it overnight?” is a concrete question. The agent reads logs, source and check history and either reports nothing, records a finding, or opens a change a different person approves. Lumen does not need it to close the rollup loop, which is why this is not a stage — but the moment you care who looks while you sleep, this is where that lives.