Spaces:
Running
Running
| # Publishing Operations — Phase 9 | |
| ## Status | |
| Publishing operations are implemented in the current working tree with durable | |
| unified jobs, calendar/queue/draft flows, retries, idempotency, and SDK/MCP/n8n | |
| transport coverage. PostgreSQL/RLS runtime verification, Docker, FFmpeg, | |
| Hugging Face startup, live provider certification, and final production | |
| certification remain deferred until all planned product phases are complete. | |
| ## Audit | |
| The Phase 8 audit found one authoritative publishing domain under | |
| `app/social/`. `SocialPost` is already the canonical draft/post record, a | |
| post owns multiple `SocialPostTarget` rows, `SocialSchedule` stores UTC | |
| timestamps plus the requested IANA timezone, and `SocialJob` is the durable | |
| per-target queue consumed by the existing scheduler and publisher workers. | |
| Provider adapters, OAuth/TokenService, capability discovery, asset ownership, | |
| RLS, retries, cancellation requests, reconciliation, partial success, SDK, | |
| MCP, n8n, Copilot, project provenance, and Content Studio integration are | |
| reused. No duplicate post, account, asset, or job tables were introduced. | |
| Phase 9 adds revision-safe draft mutation and rescheduling, queue/calendar | |
| read models, and durable bounded bulk orchestration. `revision` on posts and | |
| schedules is additive and is checked server-side for updates, duplication, and | |
| rescheduling. `social_publishing_batches` and | |
| `social_publishing_batch_items` are additive, workspace-isolated orchestration | |
| records; individual posts/jobs retain their own state and idempotency. | |
| ## State and APIs | |
| Existing `/v1/social/posts`, `/publish`, `/schedule`, `/cancel`, validation, | |
| jobs, accounts, and provider routes remain canonical. Phase 9 adds: | |
| - `GET /v1/social/drafts` | |
| - `PATCH/DELETE /v1/social/drafts/{post_id}` | |
| - `PATCH /v1/social/posts/{post_id}` | |
| - `POST /v1/social/posts/{post_id}/duplicate` | |
| - `POST /v1/social/posts/{post_id}/reschedule` | |
| - `GET /v1/social/publishing-context` | |
| - `GET /v1/social/calendar` | |
| - `GET /v1/social/queue` | |
| - `POST /v1/social/bulk` | |
| The batch operation is `schedule`, `reschedule`, `cancel`, `duplicate`, or | |
| `delete`. Batch items are claimed with `FOR UPDATE SKIP LOCKED` by the existing | |
| Social scheduler boundary and report independent completion/failure. | |
| Drafts remain `draft` until server validation. `validating` and `ready` are | |
| reserved state vocabulary for future asynchronous validation materialization; | |
| provider execution continues to use the existing `queued` → `preparing` → | |
| `processing` → `uploading` → `publishing` → terminal transitions. No frontend | |
| can arbitrarily mutate execution state. | |
| ## Calendar and timezone model | |
| The calendar accepts an aware UTC range and returns scheduled posts with the | |
| stored schedule timezone and schedule revision. Workspace timezone is read | |
| from authoritative workspace metadata, defaulting to UTC only when no | |
| workspace timezone has been configured. UI date-time inputs are explicitly | |
| labelled with that timezone and converted to an instant before mutation. | |
| Invalid, past, unordered, or excessively broad ranges are rejected. | |
| ## Queue and bulk behavior | |
| Queue filtering supports provider, account, project, status, search, bounded | |
| pagination, and live polling through TanStack Query. Bulk requests are | |
| bounded to 100 posts, idempotent at batch level, and never clone provider job | |
| IDs or provider references. Batch processing runs through the existing worker | |
| loop; partial item failure produces `partial_success` at the batch level. | |
| ## Security, permissions, RLS, and audit | |
| Existing Social scopes are reused: `social:posts:read/write/publish`, | |
| `social:schedules:read/write`, and account scopes. The BFF continues to enforce | |
| same-origin and session permission checks before forwarding authenticated | |
| requests. Migration `0009_publishing_operations.sql` enables and forces RLS | |
| for batch tables, adds workspace checks, foreign keys, indexes, and revision | |
| columns without destructive changes. Audit events use bounded | |
| `publishing.*` names alongside legacy Social event names; credentials, signed | |
| URLs, provider payloads, and binary media are never recorded. | |
| ## Integrations | |
| The Composer, Calendar, Queue, and Drafts routes use the existing Workspace | |
| shell, design system, Social hooks, canonical project assets, and provider | |
| capabilities. TypeScript and Python SDK Social resources expose draft, | |
| duplicate, reschedule, calendar, queue, and bulk methods. MCP exposes narrowly | |
| scoped queue/calendar/reschedule/duplicate/bulk tools through the shared | |
| service. The official n8n Social node exposes deterministic queue/calendar, | |
| duplicate, reschedule, and bulk operations through the SDK credential. | |
| ## Runtime limitations | |
| Local validation is limited by the available Termux environment. PostgreSQL | |
| RLS runtime checks, Docker, FFmpeg, Hugging Face startup, live provider | |
| credentials, provider certification, production OpenAPI verification, and | |
| final production hardening remain intentionally deferred until all MediaRouter | |
| product phases are complete. | |