Manifest is best understood as a media production system rather than a collection of unrelated generators. The visible tools are different rooms in one workspace, but the important connection is the path from source and brief to asset, job, project state, review, export, and reuse. A generated image can enter Library. A recording can move into Short Form or Editor. A Short Form render can become a social draft. An advertising variation can retain the sources and plans that explain how it was made.
What Manifest is
Manifest is the TronXVI media workspace currently organized in the tron-media-workspacepackage. Its frontend is a Next.js and React application, its backend is an Express and TypeScript API, and its shared directory contains the types that describe assets, jobs, models, social publishing, the Project Graph, governance, provider contracts, and Short Form pipelines.
The product’s central idea is an owned-source-to-approved-export workflow. A creator starts with a prompt, recording, upload, transcript, or imported source. Manifest turns that input into a plan or transformation, persists the resulting asset and lineage, and keeps enough metadata to continue the work in another tool. The long-term target is a canonical Project Graph so creative decisions, assets, rights, approvals, costs, provider receipts, and releases remain connected.
The repository currently contains a strong local implementation and a broader production target. Those are not identical. SQLite and local files are useful for development and tests; the documented production architecture requires PostgreSQL, private S3-compatible storage, Redis-backed durable jobs, a separate worker, real identity and tenant isolation, provider governance, and release evidence.
Manifest's position in TronXVI
Manifest is one of the specialist workspaces inside Infinity. Infinity owns the wider navigation shell and selects the Manifest surface; Manifest owns the media creation and transformation experience inside that boundary. The active source route is the embedded /manifest/ workspace, while the Manifest folder remains the source package for its frontend and backend implementation.
This boundary matters because Manifest is not a second account system floating beside Infinity. Its frontend uses Infinity’s authenticated session bridge and project context. The Manifest API client can attach a bearer token, a selected project ID, credentials, and CSRF information for state-changing calls. Authentication and project selection are therefore part of the host integration contract, not optional decoration around a standalone demo.
The product is also intentionally provider-neutral at the architecture level. Current services include OpenAI text and image gateways, video gateway hooks, social adapters, local media tooling, and capability status. A provider can be unavailable without the entire data model disappearing. The UI should say which capability is live, limited, offline, blocked, or maintenance rather than treating every button as proof of availability.
The Manifest workspace
| Surface | Implementation position | Primary job |
|---|---|---|
| Home / Create | Native workspace entry | Starts a creation session and routes into image, video, or another media workflow. |
| Creation Images | Implemented, provider-dependent | Generates images, edits images, accepts references and masks, and can save outputs into Library. |
| Creation Video | Implemented, provider-dependent | Collects a video prompt and settings and creates a durable job when a configured video provider exists. |
| Short Form | Deepest transformation workflow | Turns source media, links, or transcripts into analysis, ranked clips, rendered variants, and posting-ready assets. |
| Ads | Planning and package workflow | Creates scored ad variations, copy, hooks, shot lists, media plans, and optional generated media. |
| Editor | Versioned project state | Builds an edit plan and persists a project snapshot and command history around a timeline model. |
| Record | Browser capture workflow | Captures camera and microphone media, uploads recordings, and hands clips to Short Form or Editor. |
| Library | Backend asset history | Searches, filters, opens, and removes stored assets while exposing source and lineage metadata. |
The workspace header keeps Home and the six main tools visible: Create, Short form, Ads, Editor, Record, and Library. The selected tool is held in client state and can be remembered in browser storage. The tool components are dynamically imported so the main shell does not need to eagerly execute every large editor surface before a creator selects it.
A shared model selector can resolve the available tier from the backend. The repository defines Sentinel, Elite, Efficient, and Fast-style choices, while the selected mode is stored locally and sent to supported operations. The server remains responsible for the actual model registry and provider configuration; a browser label is not a guarantee that a live model is configured.
Manifest’s standalone source package has a simple page entry that mounts TronMediaPageClient, which mounts TronMediaApp. In the Infinity host, the root frontend mounts the same page under the Manifest surface and imports the Manifest styles, page client, and auth bridge. This keeps one product implementation while allowing the host shell to provide shared navigation and identity.
The active tool state is one of creation, short-form, ads,editor, record, or library. The app dynamically loads the specialist components. Library deliberately does not need the model lookup that creation and Short Form use, while other tools can share the resolved model response and selected tier.
Loading still has to be interpreted carefully. Dynamic import prevents unnecessary code execution, but it does not make a missing provider live. A tool can render successfully while its backend capability is offline. The intended loading model is therefore: load the selected surface, check capability status, show real readiness, and keep long jobs observable through durable status rather than claiming instant output.
Creation
Creation is the home of new visual media. It has two modes: image and video. The image surface has a prompt canvas, reference and mask upload slots, a settings sidebar, generated-result cards, model controls, platform presets, and actions to download, print, copy, or save metadata into Library. Video uses a job submission and status path rather than pretending that a generated movie is synchronous.
The creation component is large because it handles real state transitions: prompt draft, enhancement, upload state, generation state, selected canvas, result variants, settings, output actions, backend asset persistence, and video job polling. The UI contains many controls, but the backend only honors fields that its request contract understands. The product documentation explicitly calls out that some visible image settings remain UI-only or only partially wired.
| Creation control | Current meaning | Boundary |
|---|---|---|
| Prompt | Describes the requested image or video. | Text generation depends on the configured provider. |
| Mode | Generate a new image or edit an existing image. | Video is a separate job path and may be unavailable. |
| References / mask | Uploads source material for image edit or reference context. | Reference semantics and provider support must be validated per operation. |
| Size / ratio | Maps to supported generation dimensions and platform presets. | Displayed platform dimensions are normalized to provider-supported sizes. |
| Quality / count | Requests output quality and number of variants. | Actual provider limits and cost still apply. |
| Background / format | Requests opaque, transparent, auto, PNG, JPEG, or WebP behavior where supported. | The backend is authoritative for accepted fields and output format. |
Image generation and editing
Image generation sends a typed request through /api/creation/generate. Image editing uses/api/creation/edit and can include a primary source, reference assets, and a mask. The backend image service creates structured metadata: prompt sections, model and tier, reference analysis, variant grouping, edit operation, source fingerprints, and parent asset relationships.
The asset pipeline is what makes an output more useful than a transient data URL. Generated images can be converted into backend assets with kind, source, filename, MIME type, dimensions, prompt, revised prompt, model used, parent IDs, tags, and metadata. Library can later show that image alongside its source and lineage badges.
Current truth is provider-dependent. The image route and tests exist, but the repository records that a valid OpenAI key and enabled image models are required for live generation. Missing or invalid credentials must produce a truthful error rather than a fake canvas result. Visible controls such as matching strength, moderation, streaming preview, and compression should be treated as pending or partial unless the backend contract actually applies them.
Video creation
Video creation is deliberately modeled as a job. The frontend sends a request to/api/creation/video, receives a job identifier, and can poll/api/creation/video/:jobId. The shared job states include queued, planning, generating, rendering, validating, completed, failed, and cancelled.
A real video workflow must retain the request, resolved model or provider, cost, retry information, output asset IDs, warnings, and typed error details. If TRON_VIDEO_PROVIDER=none or no video model is configured, the backend is expected to return a real configuration error such asVIDEO_API_NOT_CONFIGURED. The current product should not display a completed video or a download action until a real output asset exists.
The long-term video architecture is provider-neutral and worker-backed: submit through the provider gateway, reconcile status, persist outputs and derived thumbnails, record the provider job ID and cost, and keep the source-to-output lineage in the Project Graph. The current local implementation is the foundation for that path, not proof that every video provider is live.
Short Form
Short Form is Manifest’s deepest end-to-end transformation workflow. It starts with existing content rather than generating a new video from a blank prompt. The source can be an uploaded video or audio file, an existing asset, a direct media URL, a supported social URL, or transcript-only input.
The frontend treats Short Form as a pipeline with clipping, split-screen, and posting sections. Its state tracks source readiness, ingest, preparation, transcript, analysis, slate planning, candidate selection, rendering, split-screen rendering, social accounts, drafts, and activity messages. The backend owns the corresponding services and durable job transitions.
| Workflow stage | What it produces |
|---|---|
| Creation | Prompt or reference → provider request → image/video result → asset record → Library. |
| Short Form | Source intake → preflight → ingest → prepare → transcribe → analyze → slate → render → download/publish readiness. |
| Ads | Brief and references → angles → scoring → copy and shot lists → media plan → optional asset package. |
| Editor | Source and transcript → edit plan → project creation → versioned commands → snapshot and later render work. |
| Record | Camera/microphone permission → browser recording → upload → optional transcript → handoff to another workflow. |
| Library | Persisted asset query → filters and lineage grouping → metadata and preview → asset file or delete operation. |
Short Form V1 is not prompt-to-video, a full timeline editor, or a universal social scraper. Its defensible promise is source-driven: ingest, understand, rank, render, save, download, and optionally publish a real output after rendering. If a URL is unsupported or provider-blocked, the UI should explain the failure and offer upload or transcript input rather than pretending that the source was imported.
Short Form source intake
Intake normalizes source descriptors before analysis begins. The accepted source kinds are upload, asset, direct URL, social URL, and transcript-only. The frontend also distinguishes direct links, social links, uploaded files, transcript text, and transcript files. Transcript files can be plain text, Markdown, JSON, or SRT according to the shared contract.
Preflight checks whether the source is supported, whether a provider session might be required, whether media was found, whether it is audio or video, whether the source is retryable, and whether the local machine has FFmpeg, FFprobe, Python, and social extraction support. The response includes blockers and user guidance. This is intentionally more honest than treating every pasted URL as downloadable.
Ingest persists a source asset before later analysis. Preparation can persist a report asset, thumbnail, extracted audio, waveform, and keyframe asset, plus media facts such as duration, dimensions, codecs, bitrate, frame rate, audio channels, and transcript word count. Those derived objects provide the evidence later stages need and make the result reusable in Editor or Library.
Short Form analysis and planning
Transcription produces timestamped segments and, where available, word timing and speaker information. Analysis can return ranked clip candidates, platform presets, warnings, and a trend context. Full-video analysis goes deeper: chapters, speaker turns, narrative beats, visual moments, audio signals, and an opportunity map of hooks, lessons, proof, stories, payoffs, and calls to action.
Slate planning turns that analysis into planned shorts. A planned short has a rank, archetype, title, hook, angle, target platform, time range, source beat IDs, source opportunity IDs, a reason it should work, an editing goal, an edit plan, confidence, trend alignment, and a score breakdown. The score is a planning signal, not a guarantee of virality.
Performance feedback can be recorded against a source, render, analysis, slate, candidate, creator key, and platform. That gives Manifest a path toward learning which structures work for a creator without replacing evidence with a generic “viral boost” slider. The repository explicitly warns against claiming trend or performance intelligence that is not backed by a real contract.
Short Form rendering and posting
Rendering accepts approved candidate IDs, target platforms, subtitle behavior, caption mode, output ratio, optional intro and outro cards, hook variants, and whether to save to Library. Render status returns progress, clips, variants, warnings, output asset IDs, download URLs when available, thumbnail IDs, caption mode, export profile IDs, packaging plans, and publishing readiness.
Platform presets carry aspect ratio, target duration, caption mode, safe-zone notes, bitrate, caption words per line, teaser strategy, and intro/outro hold times. Captions can be sidecar or burned-in depending on the supported mode. Split-screen is a separate workflow with a top asset, bottom asset, bottom-video type, subtitle settings, and a fixed vertical ratio.
Publishing comes after rendering. A failure to publish must not remove the rendered downloadable asset. The current social contract intentionally separates platform descriptor, OAuth state, account state, draft post, publishing state, external post ID, and error. Direct posting is not assumed to work merely because an account button exists.
Ads
Ads turns a brief and optional reference assets into structured advertising work. The frontend accepts a prompt, brand images, briefing documents, objective, platform, size, duration, variation count, and media generation mode. The backend ad service builds normalized variations with angles, hooks, headlines, body copy, CTAs, shot lists, risks, scores, and a media plan.
The ad result schema records a version, platform, size, objective, duration, variation count, warning count, scoring model, media planner model, media generation mode, package asset ID, generated asset count, pending video jobs, and per-variation summaries. This is more durable than a text-only answer because the brief can remain connected to the source files and optional media outputs.
Ads is not an ad-network launch tool. It can plan a campaign and prepare a package, but real network deployment requires external credentials, account approval, rights and claim review, spend limits, and an explicit live action. The repository documents ad-network launch as externally blocked until those conditions exist.
Editor
Editor is the project-state and timeline surface. It accepts source assets, transcripts, references, and a prompt for an edit plan. It can create an editor project, load it, apply commands, record timeline operations, and persist project snapshots and command history as backend assets.
The canonical editor domain stores exact-time fields such as timeline start, source in/out, timeline duration, speed, volume, track ID, dimensions, frame rate, and source duration. Project version numbers and command IDs support stale-write rejection and duplicate command suppression. Ordered autosave exposes Saving, Saved, and Save failed states instead of pretending an unsent change is durable.
Editor preparation can persist FFprobe-derived facts, thumbnails, waveforms, extracted audio, keyframes, and browser-compatible proxies. The current status document is explicit that true trim, split, delete, duplicate, track management, undo/redo, composed preview, audio mixing, timed captions, render jobs, deterministic MP4 export, AI command execution, and complete project versions remain unfinished. The editor is an honest foundation, not yet a finished professional export engine.
Record
Record turns the browser into a capture surface. It discovers camera and microphone devices, requests permission, shows a live preview, supports a teleprompter script, chooses resolution and frame rate, starts and stops MediaRecorder, and stores recorded clips through the backend asset pipeline.
A recorded clip carries scene, resolution, frame rate, camera, microphone, output format, upload status, transcript status, and asset identity. Once persisted, the user can transcribe it, send it to Short Form, or send it to Editor. That handoff is one of Manifest’s most practical loops because it connects capture to downstream reuse instead of leaving recordings trapped in a browser component.
Device permissions and identity-sensitive media require care. The current repository supports local capture and persistence, but the full production model still needs durable consent, rights, retention, voice and likeness governance, and authenticated tenant isolation. A successful browser recording is not automatically a production-safe voice or identity workflow.
Library
Library is the connective tissue across Manifest. It requests persisted backend assets, maps them into a filterable view, and groups them by Today, Yesterday, Last Week, Last Month, or Older. It supports search, tool, kind, source, and lineage filters; newest, oldest, or title sorting; grid or list view; opening a stored asset; and deleting an asset through the authenticated API.
Library tabs include All, Creations, Videos, Ads, Edits, and Uploads. A card can show filename, source tool, kind, timestamp, prompt, model, dimensions, format, duration, tags, and lineage badges. Derived lineage can identify source, transcript, analysis, thumbnail, waveform, parent, ancestor, and related objects.
Library only shows backend truth. If the asset service is loading, unavailable, or empty, the UI says so. A local gradient placeholder is a presentation fallback for a missing thumbnail; it is not presented as a generated media result. Asset bytes are intended to flow through authenticated API delivery rather than a public static upload directory.
The Project Graph
The Project Graph is Manifest’s long-term organizing model. It gives a project typed nodes and edges so the system can answer not only “what file exists?” but also “what source, claim, approval, provider, cost, or release produced this output?” The shared node types include brief, source input, transcript, brand kit, storyboard, campaign, variation, asset, rendition, schedule, approval, release record, job, cost record, timeline, rights record, policy decision, provider receipt, render manifest, export package, identity, consent release, and claim.
| Node type | Meaning in the graph |
|---|---|
brief | The creative or transformation request that starts a project path. |
source_input | An original uploaded, imported, recorded, or linked source. |
transcript | Text and timing derived from media or supplied by the user. |
brand_kit | Brand-facing context that can guide creative or advertising work. |
storyboard | Planned visual structure for a media or advertising workflow. |
campaign | A grouped advertising or content initiative. |
variation | One planned or generated creative alternative. |
asset | A persisted image, video, audio, document, edit, recording, or related object. |
rendition | A derived output or platform-specific representation. |
schedule | A planned publication or timing record. |
approval | A governance decision attached to a versioned object. |
release_record | The record that a governed version was released or revoked. |
job | An asynchronous work item and its status, attempts, costs, and outputs. |
cost_record | Usage and spend evidence connected to a provider or job. |
timeline | Editor project state and time-based composition information. |
rights_record | Rights, consent, or ownership evidence for source and output use. |
policy_decision | A governance or safety decision affecting a project action. |
provider_receipt | Provider submission, status, output, or failure evidence. |
render_manifest | The inputs, profile, and derived outputs required to explain a render. |
export_package | A portable project or delivery package with explicit contents. |
identity | The user, organization, or project context that owns a graph record. |
consent_release | Consent or release evidence for rights-sensitive use. |
claim | A source or advertising claim that may require policy review. |
Edges express derived-from, contains, uses, produced-by, approves, releases, cost-of, supersedes, scheduled-as, depends-on, governed-by, invalidates, and affects. Graph impact analysis can therefore show downstream work when a source, claim, or policy decision changes. The current implementation is partial, but the direction is clear: assets should not be disposable blobs without provenance.
Assets, lineage, and storage
| Storage layer | Current / target | Purpose |
|---|---|---|
| Development metadata | SQLite-backed metadata store | Useful for local tests and development; not the final production persistence contract. |
| Target metadata | PostgreSQL | The documented production direction for tenants, projects, graph records, jobs, governance, and spend. |
| Current objects | Private local upload storage | Files are served through authenticated API routes rather than public static uploads. |
| Target objects | S3-compatible private storage | Required for durable production media, signed access, backup, and scale. |
| Current jobs | SQLite records and local recovery | Job state and reconciliation exist locally; production durability still requires the target queue topology. |
| Target jobs | Redis-backed durable queue + worker | API and worker separation is the intended production shape for long media work. |
Asset records are typed by kind: image, video, audio, document, text, template, campaign, ad, edit, or recording. They also carry a source such as upload, generated, edited, recorded, imported, template, or campaign. Parent asset IDs and metadata lineage connect derived objects to their ancestors.
Image metadata can include prompt sections, references, variants, and edit validation. Video metadata can include provider job IDs, derived thumbnails, posters, spritesheets, downloads, duration, and dimensions. Ads can carry variation summaries, scores, warning counts, media-generation state, and package IDs. Short Form can carry source, transcript, analysis, slate, render, caption, waveform, keyframe, and performance relationships.
The target production design replaces local files and SQLite with PostgreSQL metadata, private S3-compatible objects, and durable queue state. Until that migration is real, production claims must not imply that a local upload directory is a multi-user object store or that a local database is a durable distributed metadata service.
Jobs, recovery, and progress
Long media operations use jobs rather than holding a request open until every frame is done. A job records kind, status, progress, message, model tier, model used, input assets, output assets, warnings, provider metadata, retry state, cost, recovery state, creation time, update time, completion time, and typed errors.
| State | Meaning |
|---|---|
queued | Accepted but waiting for execution. |
planning | The system is resolving a plan or provider action. |
generating | A provider or model operation is producing an output. |
rendering | Media is being transformed into a concrete output. |
validating | The result is being checked against the operation contract. |
completed | The operation produced a durable result and its outputs are recorded. |
failed | The operation stopped with a typed error and no false success is claimed. |
cancelled | The operation was cancelled or its cancellation was reconciled. |
Local recovery can reconcile interrupted video and Short Form jobs and clean temporary render files. The production target adds Redis leases, heartbeats, attempt records, worker separation, and durable retry and reconciliation. The user-visible progress model should always be driven by the job owner and its status response, not by a timer that assumes the provider finished.
Provider and capability truth
The provider gateway is the boundary between product contracts and external model or media providers. The shared provider contract describes capabilities, health, quotes, policy validation, idempotent submission, status, retrieval, reconciliation, cancellation, deletion, deterministic success/failure adapters, and governed compatible failover.
The capability registry reports a tool’s status, human label, reason code, explanation, dependencies, provider route, accepted input types, output limits, price behavior, data boundary class, project permission, and last verified date. The user should see this information before spending time or money on a capability that is offline.
Current provider truth is mixed. OpenAI text and image paths are implemented but unconfigured when the required key or models are unavailable. Video is honest when configured as none. Short Form local processing can be verified, while social extraction and media binaries may be missing. Social adapters exist but need OAuth apps and platform approvals. Live provider validation is intentionally not claimed by local fake provider tests.
Models and prompt assistance
Manifest has a model tier selector shared by supported creation, Short Form, Ads, Editor, and enhancement operations. The frontend can request /api/models, store the selected tier in browser storage, and pass model_tier in typed requests. The backend resolves the actual model ID from private configuration and can return the chosen model for evidence.
Enhance rewrites an existing prompt or script through /api/enhance-prompt. Prompt suggestions use /api/prompt-suggestions to return four completions for a short partial sentence. Both are assistance operations, not guarantees that the downstream media provider will accept or honor every word. When the provider fails, suggestions should disappear or an error should be shown; fake suggestions are not a valid fallback.
Model selection also affects cost and privacy. The final model, provider, data classification, budget, and route should be recorded with the job or asset where relevant. A frontend label such as “High detail” is a preference; the provider receipt is the evidence of what actually ran.
Identity, projects, and roles
Manifest’s backend has an identity and workspace foundation. Session context exposes user, organization, project, role, authentication method, and scopes. The frontend auth bridge connects the embedded tool to the host session and can switch project context through /api/auth/session/project. API keys can be listed, created, and revoked by an administrator.
Roles matter: authenticated users can read their permitted context, editors can perform state-changing creative work, reviewers can make governance decisions, and administrators can manage projects, members, keys, and spend limits. Project-scoped routes should reject requests that do not have a selected project rather than falling back to a global workspace.
The repository’s own audit notes that the auth foundation and production auth truth have not always been at the same maturity level. Production SSO, recovery, quotas, deep tenant isolation, and negative auth tests remain release concerns. This report describes the intended contract and current implementation without claiming that a local owner fallback is safe for public multi-user deployment.
Governance, approvals, and releases
Governance prevents a media system from treating “generated” as equivalent to “approved.” The preflight contract can return rights attestations, policy findings, blocking reasons, target node identity, target version, and check time. Reviewer roles can record an approval decision, create governance records, revise them, revoke them, create a release record, or revoke a release.
Rights can be confirmed, missing, or restricted. Policy findings can be informational, warnings, or blocking. Claims, likeness, consent, source ownership, platform rules, and ad claims may all require a governance record before release. A model’s confidence does not replace the reviewer’s authority.
The target workflow is: create or update source and project objects, preflight rights and policy, reserve spend, generate or transform media, review output and lineage, approve the exact version, create a release record, and keep revocation possible. This is the difference between a creative scratchpad and an operating system that can be trusted with client work.
Spend safety and receipts
Provider calls can cost money, so Manifest includes spend state, monthly limit configuration, reservations, settlement, and cancellation routes. An editor or approved operator can reserve an estimated cost before a provider run; the job can later settle the reservation with the actual cost or cancel it when work does not proceed.
Provider quotes carry provider, capability, currency, estimated and maximum USD cost, expiry, and assumptions. A provider run can be prepared and confirmed with an idempotent record. The job and cost record should preserve input units, output units, generated seconds, asset count, estimated cost, actual cost, and provider receipt so a project can explain how its spend was created.
Local code and deterministic tests can verify reservation races, cancellation, settlement, and stable idempotency. That does not authorize real spend. Live provider calls, paid media operations, and ad-network actions require explicit credentials, limits, and user authorization.
Social is downstream of creation and rendering. The shared contract describes TikTok, Instagram, Facebook, YouTube, and X. Platform descriptors say whether a provider is configured, supports direct publish, supports OAuth, has OAuth implemented, has publishing implemented, and what limitations apply.
The API can list platforms and accounts, start OAuth, receive a callback, create a post draft, list drafts, inspect one post, and attempt publishing. A post includes platform, account, asset ID, caption, hashtags, status, external ID or URL, error, and publish time. Those states are deliberately separate from the asset’s render state.
The current repository records that social adapters are unconfigured or incomplete. No platform should be shown as connected or published merely because the route exists. OAuth app registration, token encryption, scopes, platform review, consent, revocation, rate limits, and audit events are part of the real publishing boundary.
Export and portability
Portability lets the current project be exported and lets an uploaded project package be validated before import. Export is an editor-level project operation and should include the graph, source references, asset metadata, editor snapshots, commands, governance state, provider receipts, and enough manifest information to explain what is included.
Validation must happen before import changes the active project. It should identify schema version, missing files, unsupported assets, lineage gaps, policy issues, and incompatible provider or editor state. A portable project is not just a ZIP of files; it is a package whose relationships and permissions remain explicit.
The long-term benefit is provider and deployment resilience. If a provider disappears, a project should keep its source, output, decisions, receipts, and graph structure. Export and import are therefore reliability and governance features, not only convenience buttons.
Backend route families
The scanned route inventory reports 90 routes with no missing declarations. The route families below show how the backend divides responsibilities. Protected routes require authentication and many state-changing routes require editor, reviewer, or administrator authority.
| Family | Representative routes | Responsibility |
|---|---|---|
| Health and diagnostics | /health, /health/live, /health/dependencies, /health/ready, /api/diagnostics | Runtime health and administrator diagnostics. |
| AI and creation | /api/models, /api/enhance-prompt, /api/prompt-suggestions, /api/creation/generate, /api/creation/edit, /api/creation/video | Model discovery, prompt help, image work, and video job submission. |
| Assets and jobs | /api/assets/*, /api/jobs/* | Upload, list, file delivery, delete, status, cancel, and job persistence. |
| Ads | /api/ads/generate | Structured ad planning and generation. |
| Editor | /api/editor/plan, /api/editor/timeline-operation, /api/editor/project/* | Plan, create, load, and mutate versioned editor projects. |
| Record and transcripts | /api/record/devices, /api/record/enhance-script, /api/transcripts/* | Device discovery, script assistance, and transcript corrections. |
| Short Form | /api/short-form/* | Preflight, intake, preparation, transcription, analysis, slate, render, split-screen, feedback, and posting validation. |
| Projects and graph | /api/projects/*, /api/project-graph/* | Project membership, graph nodes, edges, revisions, and impact. |
| Governance | /api/governance/* | Preflight, approvals, records, releases, revocation, and policy decisions. |
| Providers and spend | /api/providers/contracts, /api/provider-runs/*, /api/spend/* | Provider capabilities, quotes, confirmations, reservations, settlement, and cancellation. |
| Social | /api/social/* | Platform descriptors, OAuth start/callback, accounts, drafts, posts, and publish actions. |
| Portability and host | /api/projects/current/export, /api/projects/current/import/validate, /api/host/context | Portable project packages and host context. |
| Tool status | /api/tool-status | Capability status, dependencies, limits, and last verification information. |
The API also exposes request IDs, explicit CORS decisions, security headers, redacted request logging, and sanitized errors. The frontend client uses credentials, attaches the selected project, forwards CSRF for mutating browser requests when available, and can refresh a failed bearer token for replayable requests. These are integration contracts shared by every Manifest tool.
Frontend architecture
Manifest’s frontend is intentionally split by domain. The shell handles tool selection and shared model state. Creation handles image/video workflows. Short Form owns the long source-to-render pipeline UI. Ads, Editor, Record, and Library each own their local state and API orchestration. Small API clients keep request shapes near the corresponding shared contracts.
The main component sizes reflect product depth: the image creator and Short Form workflow contain the most state because they manage uploads, preview, controls, polling, candidates, variants, and error recovery. Editor is also substantial because it renders the timeline and persistence state. That complexity should be reduced by clear sub-contracts and lazy loading, not by hiding unfinished behavior behind visual polish.
Styles are loaded through the Manifest workspace CSS and real-media CSS. The theme bridge allows the embedded tool to participate in Infinity’s appearance system. The host route imports the Manifest styles and connects the auth bridge, while the Manifest source package remains the owner of its product interface.
Security and production boundaries
The backend has several meaningful hardening measures: explicit bind host, origin allow-listing, security headers, request IDs, sanitized unexpected errors, upload limits, data-URL parsing, MIME and signature checks, private asset delivery, role checks, project context, and redacted logs. State-changing routes are intended to require authentication and appropriate authorization.
The repository still records release blockers. Production SSO, password reset, quota enforcement, full administrative UX, decoder-level media limits, SSRF-safe remote download, durable queues, S3-compatible objects, provider spend enforcement, and complete negative auth verification are not all finished. The auth and storage contracts must be proven with real tenant isolation before exposing customer media through a public reverse proxy.
Sensitive media also needs rights and consent governance. A recording, voice, likeness, brand asset, social token, or private client upload should not be treated like an anonymous stock image. The safest product rule is to preserve source identity, consent and rights evidence, provider route, retention, and approval state alongside the resulting asset.
Operations and deployment
The documented local services are a Next.js frontend on 127.0.0.1:7632 and an Express API on127.0.0.1:8236. The backend health route is /health; readiness is/health/ready. The current runtime was verified during this scan with the frontend root responding and the backend health response returning 200. The embedded Manifest route belongs to the Infinity host rather than the standalone package root.
The target production shape is a same-origin TLS reverse proxy, explicit backend binding, managed PostgreSQL, private object storage, Redis durable queue, separate API and worker, secret management, CI checks, migrations, audits, secret scanning, SBOM, and container checks. Railway configuration declares separate API and worker services under the Manifest root; the production readiness check is the backend health route.
External prerequisites include a valid OpenAI key and enabled models, a configured video provider, Meta, TikTok, Google/YouTube and X OAuth applications, publishing permissions, ad-network credentials and approval, production DNS/TLS, cloud storage, key management, a managed database and queue, and a legal license decision. Missing prerequisites are deployment facts, not frontend bugs.
Current capability truth
| Capability | Repository status | What that means |
|---|---|---|
| Creation Images | implemented_unconfigured | Source and service paths exist, but live image generation needs a valid configured provider. |
| Creation Video | implemented_unconfigured | The UI and job contract exist, but the repository documents no configured video provider as the default. |
| Short Form | verified_local / provider-dependent | The local pipeline and tests are substantial; external extraction, media binaries, model access, and publishing remain environment-dependent. |
| Ads | implemented_unconfigured | Planning, scoring, and media hooks exist, but real model access and ad-network authority are not assumed. |
| Editor | partial local | Project snapshots, commands, preparation, and version checks exist; composed preview, full export, and complete timeline semantics remain incomplete. |
| Record | verified_local / limited | Browser capture and persistence are implemented; device permissions and transcription/enhancement providers affect the complete loop. |
| Library | verified_auth_local | Backend-backed asset history and lineage are implemented locally, subject to the current auth and storage deployment boundaries. |
| Social publishing | implemented_unconfigured | Platform descriptors, account records, OAuth routes, drafts, and publish paths exist, but live OAuth and publishing are not enabled by default. |
| Ad-network launch | externally_blocked | Requires real advertising credentials, platform approval, rights checks, and explicit live authorization. |
The production navigation documentation currently says Creation is the active production workspace and that Short Form, Ads, Editor, Record, and Library may be displayed as Coming Soon. That product-level statement is compatible with the source folder containing implementations and tests: code existence is not the same as public availability. Manifest should expose a capability only when its provider, storage, auth, and safety prerequisites are ready for the environment.
The most important truthfulness rule is simple: no fake generated media, no fake progress, no fake download links, no fake social publishing, no fake approvals, and no green status that hides a missing dependency. Empty, blocked, offline, and unconfigured are valid product states and should be explained clearly.
Recommended workflows
Create an image
Choose Creation, select image mode, describe the desired visual, add references or a mask if needed, pick only supported settings, check capability status, generate, inspect the result, and save the asset. Confirm the Library record contains the prompt, model, source, variant, and parent lineage before reusing it.
Turn a recording into shorts
Record and save the clip, hand it to Short Form, run preflight, prepare media, transcribe if needed, analyze the full source, review candidate clips, choose platforms and caption mode, render, download, and only then consider a social draft or publish action.
Prepare an ad package
Upload the brief and brand references, state the objective and platform, generate variations, inspect risk findings and claims, review the shot list and media plan, reserve spend before paid generation, and keep the output as a governed package rather than launching an ad network automatically.
Build an edit project
Import the source and transcript, request an edit plan, create the project, apply small versioned commands, let autosave settle, reload to confirm persistence, and review the project version. Treat final render and export as separate requirements until the editor’s incomplete criteria are finished.
Troubleshooting
If the Manifest shell loads but a tool cannot generate, check backend health, tool status, model response, provider credentials, selected project, and budget. A 200 frontend response proves only that the UI loaded; it does not prove that the API, database, queue, object store, or model provider is ready.
If an upload fails, verify accepted MIME type, recognizable file signature, size limit, project context, and storage health. If an asset appears in Library without a usable thumbnail, inspect the asset metadata and file-delivery route rather than treating a gradient card as the output.
If Short Form stops during intake or rendering, read the preflight blockers and job error. Missingyt-dlp, ffmpeg, or ffprobe can block local extraction or media work. Unsupported or login-gated social URLs should be reported as such. A transcript-only path may still be valid for planning, but it should not claim that a source video was rendered without a real source asset.
If Editor loses changes, compare project revision and command ID, inspect autosave state, reload the persisted snapshot, and reject stale writes. If a provider job is interrupted, reconcile the job and provider receipt before starting a duplicate request. If authentication fails, do not silently fall back to another user, project, or local owner.
What Manifest is not
- It is not a promise that every visible media control is connected to a live provider.
- It is not a universal social scraper or guaranteed importer for every platform URL.
- It is not a completed professional nonlinear editor until preview, export, and timeline criteria are fully proven.
- It is not an ad-network launcher without credentials, approval, spend authority, rights, and policy review.
- It is not a public multi-tenant SaaS until identity, storage, queues, and tenant isolation are verified in production topology.
- It is not a place to hide fake videos, fake progress, fake downloads, or unverified provider success.
- It is not Infinity itself; it is the media workspace hosted inside Infinity’s wider shell.
Those boundaries are part of the product’s quality. Manifest becomes more useful when its asset graph, provider state, job history, and governance records tell the truth about what happened and what remains unavailable.
Product direction
Manifest’s strongest future is a durable media operating system: every source has identity, every output has lineage, every provider call has a receipt and cost, every claim and likeness has rights context, every release has approval, and every project can be exported without losing its history.
The build order should preserve the current strengths while closing the production gaps: complete the PostgreSQL, object-storage, Redis, and worker substrate; make identity and tenant isolation authoritative; finish the Project Graph; harden provider contracts and spend controls; complete Short Form render and export evidence; finish real Editor operations and MP4 export; add governance and release workflows; then enable social and ad publication only after external approvals and live contract tests.
The wider Website contains documentation-only pages for Infinity,Genesis, Platform, and TRON. Those pages explain neighboring products. This Manifest document stays focused on the media workspace, its real implementation, and the boundaries that make its future trustworthy.