← All activity records

FACTUAL ACTIVITY RECORD · An activity record based on work that took place

Adding the Editorial database execution foundation

Managing pre-draft state with six tables, human-admin and Runner RPCs, and a global FIFO

Activity period:

Purpose

Executing the finalized Editorial design required a database foundation that managed Channel configuration, Feed collection, article screening, human decisions, and Codex generation in one state machine while separating administrator and Runner authority.

The goal was to implement a local database contract that exposed no raw tables and advanced scheduled execution, article decisions, generation queue, failures, and fresh reruns only through purpose-specific RPCs.

Implementation

The Editorial migration adds six tables: Channels, Feeds, Runs, Run Executions, Execution Feeds, and Run Items. RLS is enabled and raw grants are removed from every table, while constraints align statuses with failure, stop, and draft fields.

Human-administrator RPCs handle Channel and Feed management, Execution inspection, article decisions, Generate, Stop, and fresh rerun. Runner RPCs handle scheduling, collection start, result recording and finish, global FIFO dequeue, root Thread recording, draft completion, and failure recording, with each principal type rejected from the other's operations.

Only one Run is created for a Channel and target date, making scheduled calls idempotent. Generation queue items are dequeued globally by queued time and ID. Rerunning a failed or stopped Execution preserves the original record and creates a new execution number.

An article with an indeterminate screening result cannot be approved, and generation is queued only after every decision exists and at least one article is approved. During generation, the root ID from thread.started is stored separately from the draft payload without a foreign key to the Thread table, allowing it to be recorded before synchronization.

The product-default fixture adds one Editorial Desk Room. It is stable product data rather than a dummy Room and is inserted by the minimal fixture for later Runner-generated root enrollment.

The cutoff flow from the persisted execution lifecycle to downstream processing

Rendering diagram…

What was confirmed

Verification results

All six tables define RLS and raw-access denial, with separate RPC boundaries for anonymous users, human administrators, and the Runner.

Forty-five pgTAP assertions cover Channel activity, scheduling idempotency, screening decisions, global FIFO, draft storage, failure, and fresh rerun.

Database transactions fix rejection of approval for indeterminate items and creation of a new Execution while retaining failure history.

At the cutoff, the database execution foundation and product-default Room were applied to the target. Feed retrieval, the screening provider, and Codex execution belong to the next activity.

Basis for completion

The work was complete when six tables, constraints, purpose-specific RPCs, principal separation, scheduling idempotency, global FIFO, human decisions, fresh reruns, and the default Room expressed one contract across the migration and pgTAP suite.