Preparing creative work with enough state to recover.

THE WORK

The project.

Creative Queue Workflow connects source images, visual context and prompt preparation while keeping track of what each job has actually completed. The exported n8n worker checks existing package content before selecting work, then records stage results through context preparation, generation, review and saving. If saving fails after a description is complete, the failure result can preserve that distinction for the next decision.

Work ownership is checked too: the worker writes a run-specific token to the job and reads it back before preparing context. That detects an overwritten claim at the check, although the separate upsert and readback aren't an atomic reservation. This anonymized case study describes the exported implementation. Prompt preparation is the default; image generation remains a separate, explicit handoff that also needs configuration.

IMPLEMENTATION

Design choices.

1. Context work requires a matching claim readback. Writing an owner field alone doesn't establish that the worker still owns the row; matching state and token make that a checked condition at this point in the workflow.
2. The upsert matches the job ID, not its previous owner or state, so it isn't compare-and-swap. Stronger reservation needs an atomic operation or an enforced single-worker setup.
3. Content state is tracked separately from queue state. A retry decision can account for content already produced, while a revision request can intentionally reopen work that otherwise looks complete.
4. The error category and attempt count determine what happens next. Validation, permission, authentication and schema problems can become terminal review work instead of taking the same retry path as every transient failure.
5. Image generation stays opt-in and missing configuration fails the request. The current exports retain that path, so the older README statement that it was retired needs correcting.

HOW IT FITS TOGETHER

Architecture.

• Intake preserves original image references and per-image visual context before creating prompt jobs. Those references give later preparation a specific source to describe instead of relying only on a general product summary.
• The worker sets run identity, batch limits, retry limits and claim timeout, then checks both job state and existing package content. Finished jobs and active claims are excluded; an explicit revision can make existing content eligible again.
• For each selected job, the worker upserts an owner token derived from owner, run and job IDs. Context preparation starts only after a readback matches that token and the in-progress state. A mismatch takes the failure path.
• Visual context, audience context, prompt preparation, review and saving return distinct stage results. Completed-content status travels with the failure step, code and retry flags, allowing later routing to distinguish unfinished generation from an unsuccessful save.
• Review actions resolve retry, hold, close or revision decisions. The normal path prepares prompts; a separate branch calls the optional image workflow only for an explicit request with a configured reference.

CHECKS & RESULTS

What was checked.

A source review shows what the code does. It is not a fresh test of the running app.

1. Code and development records reviewedReviewed11 September 2026

   The code, tests and available development records were checked. Reported test results keep their original scope. No fresh app or live deployment check was run for this write-up.

   Scope of this check

   Code review, not a fresh run of the app