basyx commited on
Commit
8bf0d31
·
verified ·
1 Parent(s): 7cc81cb

Upload 376 files

Browse files
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