[Feature]: P2 presentation publishing, brand kits, and ecosystem

[roomote-community]

Parent

• [Feature]: Add configurable cross-chat rich presentation profiles #1058

Goal

Extend Presentation Profiles into reusable branded publishing and a safe ecosystem for richer outputs and custom skills.

Scope

• Add reusable brand kits and branded exports using allowlisted assets and style tokens.
• Support durable publishable documentation and site outputs.
• Add safe interactive report components with sandbox and provider-aware fallbacks.
• Support profile import, export, and sharing with schema/version validation.
• Let custom skills declare compatible recipes and output types without coupling analysis logic to visual treatment.
• Document self-hosted rendering dependencies, resource budgets, storage retention, cleanup, limits, and troubleshooting.
• Extend observability and compatibility validation for publishing and ecosystem outputs.

Acceptance criteria

• Users can create reusable brand kits without unrestricted executable assets or styles.
• Profiles can produce publishable docs and sites with durable source links and status labels.
• Interactive reports are sandboxed, accessible, and degrade safely on unsupported providers.
• Profiles can be imported, exported, shared, and version-validated.
• Custom skills can declare compatible recipes and outputs through a documented contract.
• Published outputs preserve static equivalents, alt text, transcripts, citations, and privacy controls.
• Self-hosted requirements and operational limits are documented and tested.

Dependency

Blocked by the P0 foundation and P1 profile storage/customization capabilities.

[easonLiangWorldedtech]

@roomote

[roomote-community]

I'm on it. I started a task for this issue, and I'll keep updates here.

See task

[roomote-community]

Thanks for the mention. What would you like me to help with on this issue: scope it, draft an implementation plan, or work on a specific acceptance criterion?

[roomote-community]

I've analyzed this issue and here's my proposed implementation plan:

1. Gate P2 on explicit P0/P1 contracts. Treat [Feature]: P0 presentation profile contract, selection, and native delivery #1060's versioned profile/media package and [Feature]: P1 reusable presentation profiles and customization #1062's immutable profile revisions, ownership, defaults, and quality gates as prerequisites. P2 should consume those shared schemas from packages/types/src/ rather than introduce a second profile format. Add P2 schema versions and migration fixtures so imported definitions can be validated against supported profile, recipe, output, and brand-kit contract versions.

2. Model brand kits as immutable, allowlisted revisions. Add brand-kit and brand-kit-version tables in packages/db/src/schema.ts, following the immutable revision/snapshot pattern used for environment configuration and the ownership model established by P1. Store only bounded design tokens and references to validated first-party artifacts: colors, approved font families, spacing/radius scales, logos, and image assets. Reject scripts, remote URLs, arbitrary HTML, unrestricted CSS, credentials, and secret-like fields at the Zod boundary. Profiles should reference a stable kit ID plus immutable version so existing exports remain reproducible.

3. Keep publication lifecycle separate from task artifacts. Continue using task_artifacts and apps/api/src/handlers/artifacts/ for generated source/static/media files, but add a publication record for stable slug/ID, owner, source task/run, profile and brand versions, visibility, status (proposed, in-progress, or shipped), current publication revision, and publish/unpublish/expiry timestamps. Publication revisions should reference an immutable manifest of artifacts, citations, alt text, transcripts, static equivalents, and privacy review results. This avoids turning expiring signed artifact URLs into the public identity and preserves source provenance while allowing retention cleanup.

4. Add server-owned management and publishing APIs. Add DB helpers plus API/tRPC procedures for brand-kit CRUD-by-revision, asset validation, profile import/export/share/clone, publication preview/publish/update/unpublish, and status/visibility changes. Reuse artifact authorization and path validation from apps/api/src/handlers/artifacts/auth.ts, service.ts, and storage.ts; require deployment-admin rights for shared kits/profiles and owner access for personal variants. Imported bundles should be declarative JSON/YAML, reject unknown/newer schema versions, report compatibility errors before persistence, and never embed credentials or private artifact URLs.

5. Build one safe renderer for task and published surfaces. Extract the safe rendering contract behind apps/worker/src/mcp/roomote-mcp-server/show-widget.ts and apps/web/src/app/(sandbox)/task/[taskId]/messages/acp/ShowWidgetPreview.tsx so published reports use the same parser-backed sanitization, iframe sandbox, bounded markup/CSS, theme tokens, and network restrictions. Brand kits should lower into CSS variables and allowlisted asset URLs rather than raw CSS. Interactive components should come from a small registry of semantic component types; every component must have keyboard/accessibility behavior and a pre-generated static/text equivalent. Unsupported providers continue through the P0 media fallback contract instead of receiving executable markup.

6. Add durable docs/site publication views. Add public/private publication routes in apps/web/ that resolve a publication revision, render documentation/site output, show the applied profile/brand version and status label, and expose durable source/citation links only when authorized. Keep private-by-default visibility, explicit publish confirmation, no indexing for non-public outputs, revocation, and source redaction checks. Extend ArtifactViewerContent.tsx only for previewing publication manifests; do not make generic artifacts implicitly public.

7. Define a custom-skill compatibility manifest, not visual logic in skills. Extend the existing marketplace/manual skill contract in packages/types/src/environment-config.ts with an optional validated presentation capability manifest declaring supported semantic input, recipe IDs/versions, required features, and output kinds. Runtime skill setup in apps/worker/src/run-task/agent-home.ts and workspace/workspace-manager.ts should surface that manifest to profile resolution. Compatibility validation should fail early with a reason when a profile requests unsupported recipes, outputs, renderer features, or provider capabilities; analysis instructions remain in the skill while recipes/styles/renderers remain shared platform concerns.

8. Add observability, retention, and cleanup as part of the lifecycle. Record bounded metadata for brand/profile/publication versions, renderer version, validation result, selected output, provider fallback, publication state transitions, and cleanup outcomes without recording generated private content. Extend artifact cleanup to retain files referenced by live publication revisions, collect superseded/expired revisions according to policy, and make partial publish failures retryable and observable. Define byte, asset-count, page, component, render-time, memory, and storage budgets in shared constants and enforce them at API and renderer boundaries.

9. Cover security, compatibility, accessibility, and operations in tests and docs. Add schema/database/API tests for ownership, immutable revisions, imports across supported/unsupported versions, malicious assets/styles, publication visibility, unpublish/revocation, retention, and concurrent revision creation. Extend apps/worker/src/mcp/roomote-mcp-server/__tests__/show-widget.test.ts, web renderer tests/stories, and artifact handler tests for sandbox escape attempts, component fallbacks, reduced motion, alt text/transcripts, citations, and static-equivalent preservation. Add public documentation under apps/docs/ for brand kits, publishing, import/export, custom-skill manifests, privacy, self-hosted renderer dependencies, storage/retention, budgets, cleanup, limits, and troubleshooting, and validate it with the docs package checks.

I recommend delivering this issue in three reviewable slices: brand-kit/import contracts, then publication lifecycle and static docs/sites, then interactive components plus custom-skill capability manifests. The maintainer-owned decision is the initial publication visibility model; I recommend private-by-default publications with an explicit public transition and immutable public revisions, because that is safest for task-derived repository content and still supports durable sharing.

This approach reuses the existing artifact pipeline, widget sandbox, immutable configuration patterns, and custom-skill installation flow while adding stable publication identity and keeping executable presentation behavior inside Roomote-controlled renderers.

Please tag @roomote if you'd like me to implement this, or reply with feedback on the plan.