Spaces:
Running
Running
Upload 376 files
Browse files- AGENTS.md +168 -0
- app/projects/models/rendering.py +1 -0
- docs/ai-copilot.md +8 -0
- docs/analytics.md +8 -0
- docs/brand-kits.md +66 -0
- docs/publishing-operations-phase9.md +8 -0
- docs/template-marketplace.md +8 -0
AGENTS.md
ADDED
|
@@ -0,0 +1,168 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# MediaRouter — AGENTS.md
|
| 2 |
+
|
| 3 |
+
## Mission
|
| 4 |
+
|
| 5 |
+
MediaRouter is an enterprise media automation platform. Development must preserve production-grade reliability, security, explicit capability gating, authoritative backend contracts, and Hugging Face Spaces compatibility.
|
| 6 |
+
|
| 7 |
+
The repository contains backend, frontend, SDK, n8n, MCP, AI, media-processing, publishing, analytics, collaboration, template, project, and Content Studio functionality.
|
| 8 |
+
|
| 9 |
+
## Operating Rules
|
| 10 |
+
|
| 11 |
+
1. Do not fabricate backend capabilities, provider support, assets, jobs, analytics, templates, or persistence.
|
| 12 |
+
2. Backend contracts are authoritative. Frontend capability discovery must follow actual API/OpenAPI support.
|
| 13 |
+
3. Never weaken authentication, authorization, PostgreSQL RLS, CORS, rate limiting, validation, or production configuration to make tests pass.
|
| 14 |
+
4. Do not introduce a SQLite production fallback.
|
| 15 |
+
5. Do not claim runtime verification when the relevant runtime was not actually exercised.
|
| 16 |
+
6. Do not silently replace real provider/model operations with mocks or fake success paths.
|
| 17 |
+
7. Preserve backward compatibility unless a migration explicitly requires a breaking change.
|
| 18 |
+
8. Database migrations are additive unless a destructive change is explicitly required, reviewed, and safely migrated.
|
| 19 |
+
9. All durable resources must have explicit ownership, workspace isolation, permission enforcement, and audit behavior.
|
| 20 |
+
10. Never store credentials, tokens, secrets, signed URLs, editor documents, or sensitive provider payloads in logs or audit metadata.
|
| 21 |
+
11. Keep Hugging Face Spaces as a supported deployment boundary. Backend containers must bind to port 7860.
|
| 22 |
+
12. Prefer deterministic behavior and explicit failure over optimistic/fake behavior.
|
| 23 |
+
13. When a feature lacks an authoritative backend contract, hide or disable the feature with a truthful reason.
|
| 24 |
+
14. Do not perform final production certification until all planned product phases are complete.
|
| 25 |
+
15. Phase 13 and later features may be added after the current feature set; do not prematurely implement them during stabilization work.
|
| 26 |
+
|
| 27 |
+
## Architecture
|
| 28 |
+
|
| 29 |
+
### Backend
|
| 30 |
+
|
| 31 |
+
Use layered architecture:
|
| 32 |
+
|
| 33 |
+
- API: FastAPI routers, validation, authentication dependencies, response schemas.
|
| 34 |
+
- Service: business rules and orchestration.
|
| 35 |
+
- Repository: persistence and query boundaries.
|
| 36 |
+
- Model: SQLAlchemy domain models.
|
| 37 |
+
- Worker: durable asynchronous jobs and provider/media execution.
|
| 38 |
+
- Security: authentication, authorization, scopes, workspace context, RLS, audit.
|
| 39 |
+
- Migration: PostgreSQL schema changes and security policies.
|
| 40 |
+
|
| 41 |
+
### Frontend
|
| 42 |
+
|
| 43 |
+
Use feature-oriented modules:
|
| 44 |
+
|
| 45 |
+
- API/query layer for authoritative backend resources.
|
| 46 |
+
- TanStack Query for server state.
|
| 47 |
+
- Zustand only for local/editor interaction state where appropriate.
|
| 48 |
+
- Capability discovery from runtime/backend contracts.
|
| 49 |
+
- Explicit loading, empty, unavailable, and error states.
|
| 50 |
+
- Accessible keyboard and responsive behavior.
|
| 51 |
+
|
| 52 |
+
### SDK / n8n / MCP
|
| 53 |
+
|
| 54 |
+
All integrations must map to real backend contracts.
|
| 55 |
+
|
| 56 |
+
- TypeScript SDK: typed resources and errors.
|
| 57 |
+
- Python SDK: typed resources and errors.
|
| 58 |
+
- n8n: explicit operation schemas and backend-compatible requests.
|
| 59 |
+
- MCP: narrow, typed, permission-aware tools; never expose unrestricted generic execution.
|
| 60 |
+
|
| 61 |
+
## Database and Security
|
| 62 |
+
|
| 63 |
+
Production uses PostgreSQL.
|
| 64 |
+
|
| 65 |
+
RLS must be enforced for workspace-owned resources where required. Tests must verify cross-workspace isolation using separate users/roles where the environment supports it.
|
| 66 |
+
|
| 67 |
+
Every new durable resource must consider:
|
| 68 |
+
|
| 69 |
+
- workspace ownership
|
| 70 |
+
- creator/actor
|
| 71 |
+
- lifecycle/status
|
| 72 |
+
- timestamps
|
| 73 |
+
- indexes
|
| 74 |
+
- foreign keys
|
| 75 |
+
- constraints
|
| 76 |
+
- RLS
|
| 77 |
+
- permissions/scopes
|
| 78 |
+
- audit events
|
| 79 |
+
- idempotency
|
| 80 |
+
- concurrency/revision behavior
|
| 81 |
+
- deletion/archive semantics
|
| 82 |
+
|
| 83 |
+
Never use reserved SQLAlchemy Declarative attributes such as `metadata` directly as Python model attributes. Map them to safe Python names when the database column must remain `metadata`.
|
| 84 |
+
|
| 85 |
+
## Production Boundary
|
| 86 |
+
|
| 87 |
+
The target deployment is Dockerized Python 3.10 on Hugging Face Spaces.
|
| 88 |
+
|
| 89 |
+
Expected production characteristics:
|
| 90 |
+
|
| 91 |
+
- Python 3.10
|
| 92 |
+
- pinned dependencies
|
| 93 |
+
- FastAPI/Uvicorn
|
| 94 |
+
- port 7860
|
| 95 |
+
- PostgreSQL
|
| 96 |
+
- PostgreSQL RLS
|
| 97 |
+
- FFmpeg/FFprobe where media processing requires them
|
| 98 |
+
- stateless container filesystem
|
| 99 |
+
- durable external media/data storage
|
| 100 |
+
- explicit environment variables
|
| 101 |
+
- production CORS
|
| 102 |
+
- safe error responses
|
| 103 |
+
- structured logging
|
| 104 |
+
|
| 105 |
+
SQLite may be used only as an explicitly bounded development/test backend when supported by the codebase.
|
| 106 |
+
|
| 107 |
+
## Change Discipline
|
| 108 |
+
|
| 109 |
+
Before modifying code:
|
| 110 |
+
|
| 111 |
+
1. Inspect existing architecture.
|
| 112 |
+
2. Find the authoritative backend route/schema/service.
|
| 113 |
+
3. Find existing patterns for the same resource type.
|
| 114 |
+
4. Preserve naming and migration conventions.
|
| 115 |
+
5. Identify affected tests and integration points.
|
| 116 |
+
6. Make the smallest correct change.
|
| 117 |
+
|
| 118 |
+
After modifying code:
|
| 119 |
+
|
| 120 |
+
1. Compile/import.
|
| 121 |
+
2. Run focused tests.
|
| 122 |
+
3. Run relevant domain tests.
|
| 123 |
+
4. Run frontend typecheck/lint/build where applicable.
|
| 124 |
+
5. Run SDK/n8n/MCP checks where applicable.
|
| 125 |
+
6. Review the final diff.
|
| 126 |
+
7. Report environment blockers honestly.
|
| 127 |
+
|
| 128 |
+
## Error Handling
|
| 129 |
+
|
| 130 |
+
Never fix a runtime error by deleting imports or disabling the subsystem without understanding the dependency chain.
|
| 131 |
+
|
| 132 |
+
For startup failures:
|
| 133 |
+
|
| 134 |
+
1. Read the complete traceback.
|
| 135 |
+
2. Fix the first application-level root cause.
|
| 136 |
+
3. Re-run startup.
|
| 137 |
+
4. Continue until application import/startup is clean.
|
| 138 |
+
5. Then validate health and OpenAPI.
|
| 139 |
+
|
| 140 |
+
For database failures, distinguish:
|
| 141 |
+
|
| 142 |
+
- model error
|
| 143 |
+
- migration error
|
| 144 |
+
- fixture error
|
| 145 |
+
- PostgreSQL configuration error
|
| 146 |
+
- RLS error
|
| 147 |
+
- environment limitation
|
| 148 |
+
|
| 149 |
+
## Status Vocabulary
|
| 150 |
+
|
| 151 |
+
Use only:
|
| 152 |
+
|
| 153 |
+
- PASS — actually verified.
|
| 154 |
+
- FAIL — verification ran and failed.
|
| 155 |
+
- BLOCKED — verification could not run because of the environment.
|
| 156 |
+
- NOT VERIFIED — no verification was performed.
|
| 157 |
+
- PARTIAL — implementation exists but one or more required verification layers remain incomplete.
|
| 158 |
+
- DEFERRED — intentionally postponed by project scope.
|
| 159 |
+
|
| 160 |
+
Never convert BLOCKED into PASS.
|
| 161 |
+
|
| 162 |
+
## Current Project Direction
|
| 163 |
+
|
| 164 |
+
Feature development continues before final hardening/certification.
|
| 165 |
+
|
| 166 |
+
Production certification is intentionally deferred until all planned MediaRouter product features are implemented.
|
| 167 |
+
|
| 168 |
+
The current priority for stabilization work is eliminating confirmed startup/import/model/authentication/frontend contract defects without adding new product features.
|
app/projects/models/rendering.py
CHANGED
|
@@ -12,6 +12,7 @@ from sqlalchemy import (
|
|
| 12 |
JSON,
|
| 13 |
String,
|
| 14 |
Text,
|
|
|
|
| 15 |
)
|
| 16 |
from sqlalchemy.orm import Mapped, mapped_column
|
| 17 |
|
|
|
|
| 12 |
JSON,
|
| 13 |
String,
|
| 14 |
Text,
|
| 15 |
+
UniqueConstraint,
|
| 16 |
)
|
| 17 |
from sqlalchemy.orm import Mapped, mapped_column
|
| 18 |
|
docs/ai-copilot.md
CHANGED
|
@@ -1,5 +1,13 @@
|
|
| 1 |
# AI Copilot
|
| 2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 3 |
AI Copilot is a validated orchestration layer over existing MediaRouter
|
| 4 |
services. It does not execute arbitrary model output and does not duplicate
|
| 5 |
project, asset, editor, AI Studio, generation, or render business logic.
|
|
|
|
| 1 |
# AI Copilot
|
| 2 |
|
| 3 |
+
## Status
|
| 4 |
+
|
| 5 |
+
AI Copilot is implemented in the current working tree as a bounded,
|
| 6 |
+
server-authoritative orchestration layer with durable runs, typed actions,
|
| 7 |
+
scope enforcement, and MCP transport. Provider credential certification,
|
| 8 |
+
PostgreSQL/RLS runtime verification, Docker, and Hugging Face startup remain
|
| 9 |
+
deferred until all planned product phases are complete.
|
| 10 |
+
|
| 11 |
AI Copilot is a validated orchestration layer over existing MediaRouter
|
| 12 |
services. It does not execute arbitrary model output and does not duplicate
|
| 13 |
project, asset, editor, AI Studio, generation, or render business logic.
|
docs/analytics.md
CHANGED
|
@@ -1,5 +1,13 @@
|
|
| 1 |
# MediaRouter Analytics & Insights
|
| 2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 3 |
## Architecture
|
| 4 |
|
| 5 |
Phase 10 extends the authoritative Social analytics boundary. Provider calls
|
|
|
|
| 1 |
# MediaRouter Analytics & Insights
|
| 2 |
|
| 3 |
+
## Status
|
| 4 |
+
|
| 5 |
+
The current working tree implements the bounded Analytics service at
|
| 6 |
+
`app/analytics/`, exposes `/v1/analytics` routes, and provides frontend,
|
| 7 |
+
TypeScript/Python SDK, MCP, and n8n transport surfaces. PostgreSQL schema,
|
| 8 |
+
RLS certification, Docker/Hugging Face runtime verification, and provider
|
| 9 |
+
certification remain deferred until all planned product phases are complete.
|
| 10 |
+
|
| 11 |
## Architecture
|
| 12 |
|
| 13 |
Phase 10 extends the authoritative Social analytics boundary. Provider calls
|
docs/brand-kits.md
ADDED
|
@@ -0,0 +1,66 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Brand Kit
|
| 2 |
+
|
| 3 |
+
## Status
|
| 4 |
+
|
| 5 |
+
The current working tree implements Brand Kit as a real workspace-owned domain
|
| 6 |
+
under `app/brand/` with `/v1/brand` REST routes, frontend brand-kit feature
|
| 7 |
+
modules, TypeScript/Python SDK resources, MCP brand tools, and an n8n
|
| 8 |
+
`MediaBrandKit` node. Authoritative PostgreSQL migrations, RLS runtime
|
| 9 |
+
certification, Docker/Hugging Face runtime verification, and final production
|
| 10 |
+
certification remain deferred until all planned product phases are complete.
|
| 11 |
+
|
| 12 |
+
## Domain model
|
| 13 |
+
|
| 14 |
+
`BrandKit` and `BrandKitVersion` are the canonical records. A kit owns versions
|
| 15 |
+
through `brand_kit_versions`, includes workspace/creator ownership fields, and
|
| 16 |
+
tracks `status`, timestamps, and an `active_version_id`. Versions store bounded
|
| 17 |
+
branding fields such as colors, fonts, voice/tone metadata, asset references,
|
| 18 |
+
watermark settings, and a `metadata` JSON column mapped safely away from the
|
| 19 |
+
SQLAlchemy reserved `metadata` attribute.
|
| 20 |
+
|
| 21 |
+
## API
|
| 22 |
+
|
| 23 |
+
| Method | Endpoint | Purpose |
|
| 24 |
+
|---|---|---|
|
| 25 |
+
| `GET` | `/v1/brand` | List workspace brand kits with active version metadata. |
|
| 26 |
+
| `POST` | `/v1/brand` | Create a workspace brand kit. |
|
| 27 |
+
| `PATCH` | `/v1/brand/{brand_kit_id}` | Update a workspace brand kit. |
|
| 28 |
+
| `DELETE` | `/v1/brand/{brand_kit_id}` | Delete a workspace brand kit. |
|
| 29 |
+
|
| 30 |
+
`POST /v1/brand` accepts `name`, optional `description`, and `initial_version`
|
| 31 |
+
payload data. The response surface returns the kit plus its current
|
| 32 |
+
`active_version_id`; it does not expose invitation tokens or secret fields.
|
| 33 |
+
|
| 34 |
+
Version-specific brand-kit routes are **not exposed** in the current backend
|
| 35 |
+
contract. Python and TypeScript SDKs therefore fail closed with
|
| 36 |
+
`NotImplementedError` for `get_version` and `create_version` instead of
|
| 37 |
+
inventing endpoints.
|
| 38 |
+
|
| 39 |
+
## Frontend
|
| 40 |
+
|
| 41 |
+
The frontend uses `/v1/brand` through `frontend/features/brand-kits/api/index.ts`.
|
| 42 |
+
Brand kits appear in workspace settings navigation with `permission: "admin"`,
|
| 43 |
+
and capability discovery treats the brand area as active when the backend
|
| 44 |
+
advertises the expected routes.
|
| 45 |
+
|
| 46 |
+
## SDK
|
| 47 |
+
|
| 48 |
+
Both official SDKs use `/v1/brand` for list/get/create/update/delete operations.
|
| 49 |
+
The Python client is defined in `sdk/python/media_platform/brand_kits.py`, and
|
| 50 |
+
the TypeScript client is defined in `sdk/typescript/src/resources/brand-kits.ts`.
|
| 51 |
+
Static contract tests verify route paths, request bodies, and fail-closed
|
| 52 |
+
versioned-operation behavior.
|
| 53 |
+
|
| 54 |
+
## MCP and n8n
|
| 55 |
+
|
| 56 |
+
MCP registers narrow typed brand tools through `app/mcp/tools/brand.py` and
|
| 57 |
+
`app/mcp/server.py`. The official n8n `MediaBrandKit` node consumes the shared
|
| 58 |
+
MediaRouter SDK/credential boundary; no provider credentials or raw brand
|
| 59 |
+
documents are exposed to n8n transports.
|
| 60 |
+
|
| 61 |
+
## Security and runtime
|
| 62 |
+
|
| 63 |
+
Brand kit routes reuse the existing API-key authentication, scoped workspace
|
| 64 |
+
context, and structured audit boundary. Sensitive fields remain backend-only.
|
| 65 |
+
PostgreSQL FORCE RLS, migration ordering, and provider-facing certification are
|
| 66 |
+
intentionally deferred to the final production certification phase.
|
docs/publishing-operations-phase9.md
CHANGED
|
@@ -1,5 +1,13 @@
|
|
| 1 |
# Publishing Operations — Phase 9
|
| 2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 3 |
## Audit
|
| 4 |
|
| 5 |
The Phase 8 audit found one authoritative publishing domain under
|
|
|
|
| 1 |
# Publishing Operations — Phase 9
|
| 2 |
|
| 3 |
+
## Status
|
| 4 |
+
|
| 5 |
+
Publishing operations are implemented in the current working tree with durable
|
| 6 |
+
unified jobs, calendar/queue/draft flows, retries, idempotency, and SDK/MCP/n8n
|
| 7 |
+
transport coverage. PostgreSQL/RLS runtime verification, Docker, FFmpeg,
|
| 8 |
+
Hugging Face startup, live provider certification, and final production
|
| 9 |
+
certification remain deferred until all planned product phases are complete.
|
| 10 |
+
|
| 11 |
## Audit
|
| 12 |
|
| 13 |
The Phase 8 audit found one authoritative publishing domain under
|
docs/template-marketplace.md
CHANGED
|
@@ -1,5 +1,13 @@
|
|
| 1 |
# Template Marketplace
|
| 2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 3 |
The Template Marketplace extends the existing `app/templates` domain without
|
| 4 |
replacing the immutable YAML operation-template registry. Marketplace
|
| 5 |
templates are authoritative database records whose versions contain only
|
|
|
|
| 1 |
# Template Marketplace
|
| 2 |
|
| 3 |
+
## Status
|
| 4 |
+
|
| 5 |
+
The template marketplace is implemented in the current working tree with bounded
|
| 6 |
+
catalog CRUD, versioning, visibility, application, instantiation, frontend
|
| 7 |
+
marketplace flows, and SDK/n8n/MCP coverage. PostgreSQL/RLS runtime
|
| 8 |
+
verification, Docker, Hugging Face startup, and final production certification
|
| 9 |
+
remain deferred until all planned product phases are complete.
|
| 10 |
+
|
| 11 |
The Template Marketplace extends the existing `app/templates` domain without
|
| 12 |
replacing the immutable YAML operation-template registry. Marketplace
|
| 13 |
templates are authoritative database records whose versions contain only
|