Skip to content
DarkPrint
Aautogenwarehouse-publisher1.0.0

Warehouse Publisher

Get card

Clone

npx -y darkprint clone warehouse-publisher@1.0.0

There is no repository and no history behind a card. Download hands you the document as it stands, and Clone fetches the same document by name.

↓ 2 downloads

Advance the watermark to the end of the swept window, refresh the downstream views, and post the night's counts, rows cleaned, rows repaired, rows quarantined, to the ops channel.

used in 1 blueprint

Specification

119 words · handed to the agent

Read the commit receipt on dataset, refresh the downstream views over the target table, and only then advance the watermark to the end of the window this run swept. Keep that order: if the refresh fails, leave the watermark exactly where it was, so the next night re-sweeps the same window instead of stepping over it. Post one digest to the nightly-ops channel giving the night's counts, rows cleaned, rows repaired, rows quarantined, and stay silent when nothing was repaired and nothing was quarantined, because a message every night trains people to ignore the one that matters. The run is done when the watermark has moved and, on any night that was not clean, the digest has been posted.

Interfaces

1 in · 0 out

Inputs

1
Inputs declared by this node card
NameData typeRequiredDescription
datasetjson requiredThe store's commit receipt for the night, which the watermark is advanced from.

Outputs

0

No outputs declared, whatever this node produces leaves the graph.

Dependencies

1

The upstream nodes this card expects to receive from. Whenever a blueprint pins this card, each name is checked against a real edge in that graph. A name without a link is not a published card; it refers to a node inside some graph.

Card values

17 declared

Who the node is. The id is the key the DOT pins.

id
warehouse-publisher
name
Warehouse Publisher
type
tool
phases
Deployment
Behaviourcard spec →

What it does, and the prose the agent is handed when the graph runs.

action29 words
Advance the watermark to the end of the swept window, refresh the downstream views, and post the night's counts, rows cleaned, rows repaired, rows quarantined, to the ops channel.
spec119 words
Read the commit receipt on dataset, refresh the downstream views over the target table, and only then advance the watermark to the end of the window this run swept. Keep that order: if the refresh fails, leave the watermark exactly where it was, so the next night re-sweeps the same window instead of stepping over it. Post one digest to the nightly-ops channel giving the night's counts, rows cleaned, rows repaired, rows quarantined, and stay silent when nothing was repaired and nothing was quarantined, because a message every night trains people to ignore the one that matters. The run is done when the watermark has moved and, on any night that was not clean, the digest has been posted.in full above
model
whatever the graph supplies
agent
not named
skill
skills/warehouse-publisher.md
tools
Messaging
mcp
postgres, slack
params
refresh_views: true, digest_channel: nightly-ops, quiet_on_clean_run: true
Interfacescard spec →

What arrives, what leaves, which nodes it expects to hear from, and what may not.

inputs
dataset : json
outputs
none
dependencies
record-store
cannot
no type is refused
will_not
advance the watermark before the views have refreshed
Evaluation metadatacard spec →

The keys the static analysis reads. Nothing here instructs the agent.

risk_markers
irreversible-action
notes31 words
quiet_on_clean_run is the whole design brief: the line only speaks up when a night was not boring, and the quarantine queue it names is read the next morning, not waited on.
Service fieldscard spec →

The card's own version, and who wrote it.

version
1.0.0
author
autogen
provenance
not stated

Definitions for every card field

Version history

1 version published
  1. warehouse-publisher@1.0.0currentsha256:375e0c7ad0099f3aecc49884291861ee76355a4f8a6a2e62312096862a29f248

    pinned byNightly Data Janitorautogen/nightly-data-janitor

A digest is a fingerprint (SHA-256) of the card's content, computed without the author and provenance fields. The same card from two people gets the same digest; any edit gets a new one.

First published version, so there is nothing to compare yet. Versions are never edited in place: the next change arrives as a new version, and the differences between the two documents are listed here.

Community notes (0)

No notes yet.

Nobody has posted about this node card yet.

Sign in to post a note.