docs: add orchestration, registry, dashy, cron, and content pipeline write-ups
Completes the orchestration/registry/content batch - Kestra's check-pause-approve-apply pattern, the self-hosted build pipeline, the SOC dashboard's 14-source aggregation, the cron heatmap, and the in-progress content pipeline, all in the diagram+callout+table style.
This commit is contained in:
5 files changed
+248
No files matched your search
@@ -0,0 +1,41 @@
|
||||
# 📝 Content Pipeline
|
||||
|
||||
> [!WARNING]
|
||||
> Still under active development — this covers the current shape, not a finished architecture. Included deliberately rather than only showcasing finished work.
|
||||
|
||||
## The intended shape
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Idea["Idea"] --> Draft["Drafting"]
|
||||
Draft --> Review["Review"]
|
||||
Review --> Approved["Approved"]
|
||||
Approved --> Published["Published"]
|
||||
|
||||
Approved -.glue via automation tool.-> Storage["Draft/asset staging"]
|
||||
Approved -.glue via automation tool.-> Blog["Published blog"]
|
||||
Approved -.planned, not yet wired.-> Social["Social platforms"]
|
||||
```
|
||||
|
||||
A structured content tracker moves ideas through a status pipeline, with a workflow-automation tool gluing the stages together: approved content flows through to a file-storage staging area and out to a public blog. A separate, still-incomplete leg is meant to fan approved posts out to social platforms automatically.
|
||||
|
||||
## A deliberate constraint, not a limitation stumbled into
|
||||
|
||||
> [!TIP]
|
||||
> The social-publishing tool is **single-origin by design** — its frontend/backend URLs are baked to one specific public hostname at configuration time, so it deliberately has no presence in either internal DNS zone described in [`docs/dns-naming.md`](dns-naming.md); any other hostname hitting it fails CORS. This was a conscious choice, not a workaround: the tool is meant to be reached exactly one way.
|
||||
|
||||
## A real surprise in scale
|
||||
|
||||
> [!IMPORTANT]
|
||||
> The social-publishing tool's real deployment footprint is 8 containers, not the app+database+cache most people would guess — it bundles its own workflow engine (mandatory for all of its background jobs, including scheduled posting itself) plus that engine's own database and search-based visibility store. A useful reminder that a tool's advertised simplicity and its actual operational footprint can be very different things.
|
||||
|
||||
## What's actually built vs. what's still wiring up
|
||||
|
||||
| Piece | Status |
|
||||
|---|---|
|
||||
| Content tracker → automation → draft storage → blog | Most built-out, working end to end |
|
||||
| AI-assisted drafting step | Still being wired up |
|
||||
| Social-publishing fan-out | Still being wired up |
|
||||
|
||||
---
|
||||
Related stacks: [`stacks/productivity/postiz/`](../stacks/productivity/postiz/), [`stacks/productivity/nocodb-content/`](../stacks/productivity/nocodb-content/), [`stacks/productivity/ghost/`](../stacks/productivity/ghost/)
|
||||
Reference in new issue
Block a user