Ingest Publication Slice

---
name: ingest-publication-slice
description: Build and verify a small end-to-end publication path for validated ingested data, including atomic persistence, read fallback, and static artifact precedence.
source: weekly-pattern-learner
source_reason: "Repeatedly implement a validated ingest-to-publication flow with atomic persistence, fallback reads, and static artifact precedence."
source_date: "2026-10-24"
---
<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->

> 🤖 *Auto-generated by **weekly-pattern-learner** · Repeatedly implement a validated ingest-to-publication flow with atomic persistence, fallback reads, and static artifact precedence.*

# Ingest Publication Slice

Use this workflow when an ingest pipeline must make a validated record available immediately while a static or cached publication artifact may be generated later.

## Define the contract

Before changing code, read the repository instructions and trace the current path from ingest entry point through validation, job completion, persistence, request handling, and static artifact generation. Record existing invariants and preserve unrelated work.

Write acceptance criteria for one complete slice:

- Only a completed, validated active dataset can be published.
- The persistent publication record and terminal ingest state commit atomically.
- The canonical read path can serve from the persistent record when no static artifact exists.
- A static artifact remains authoritative once present, if that is the established product contract.
- Retries are idempotent, and collisions, invalid states, hidden records, and takedowns cannot publish.

Adapt these criteria to the actual product contract. Do not invent a static-artifact precedence rule if the system has none.

## Implement test-first

Use the repository's required test command and style. Add focused failing tests before implementation for:

1. A valid ingest publishes the record and terminal state together.
2. A failure between writes leaves neither half committed.
3. The canonical read path uses the persisted record when the artifact is absent.
4. The artifact wins when both sources exist, when precedence is required.
5. Repeated delivery is safe and invalid, hidden, colliding, or withdrawn records stay unpublished.

Test the production boundary and transaction behavior, not only helper functions. Keep the change to the smallest vertical slice; avoid unrelated schema or routing refactors.

## Verify the composed path

Run the focused tests, then the repository's required broader checks. Inspect the final diff and trace the completed path again from ingest through the canonical response. Confirm behavior for retries, partial failures, and transitions from no artifact to artifact present. Report any unavailable integration or deployment evidence explicitly.