[Feature]: P1 reusable presentation profiles and customization

[roomote-community]

Parent

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

Goal

Build reusable Presentation Profile intelligence, storage, templates, quality gates, and web customization on top of the P0 contract.

Scope

• Add the five built-in profiles: BA explainer, manager feature update, release recap, documentation walkthrough, and marketing story.
• Add reusable recipes and allowlisted visual templates.
• Add the Roomote web Present composer with profile, audience, recipe, style, output, preview, Use once, and Save as preset controls.
• Add organization and user profile storage with immutable versions, defaults, cloning, and ownership controls.
• Support named profiles, commands where provider command surfaces exist, and the Present this action.
• Display the applied profile/version and offer relevant change/save actions.
• Add accessibility and source-accuracy quality gates, including static equivalents, alt text, motion transcripts, captions, reduced-motion handling, readable mobile previews, and status/source verification.
• Document profile configuration, precedence, cloning, provider support, and self-hosted storage/retention requirements.

Acceptance criteria

• All five built-in profiles are available and use composable skills, recipes, styles, and delivery settings.
• Users can select profiles by name, natural language, supported command surfaces, quick action, and web composer.
• Organization profiles are shareable and versioned.
• Users can clone shared profiles into personal variants and choose defaults.
• Explicit choices override task, user, organization, and automatic defaults.
• The applied profile and immutable version are visible in every presentation result.
• Motion outputs require a readable PNG/text equivalent, alt text, and transcript.
• Material claims are source-checked and labeled proposed, in progress, or shipped.
• Private data, secrets, and raw transcripts are prevented from entering public media.
• Web and provider interaction paths have automated and visual coverage.

Dependency

Blocked by completion of the P0 contract and delivery foundation.

[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]

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

1. Treat the P0 contract in [Feature]: P0 presentation profile contract, selection, and native delivery #1060 as the entry gate. Build P1 against P0's canonical versioned profile, recipe, style, delivery, resolved-selection, result-metadata, and typed media schemas under packages/types/src/; do not introduce a second P1-only representation. Snapshot the selected profile ID and immutable version into the task launch/result metadata so later profile edits cannot change an existing presentation.

2. Add dedicated immutable profile persistence. Extend packages/db/src/schema.ts and migrations with profile identity/ownership, immutable profile-version snapshots, and default-selection records. Reuse the advisory-lock, deduplication, and monotonically increasing revision pattern from packages/db/src/lib/environment-config-versions.ts. In Roomote's current deployment model, treat a deployment-shared profile as the organization scope: admins manage shared profiles, members own personal profiles, shared profiles can be cloned but not mutated by members, and deleting or superseding a profile must preserve versions referenced by tasks.

3. Define and ensure the five built-ins as validated data. Add BA explainer, manager feature update, release recap, documentation walkthrough, and marketing story definitions using composable P0 skill/recipe/style/delivery references. Follow the idempotent built-in/custom ensure pattern in packages/db/src/lib/custom-automations.ts and seed patterns in packages/db/src/fixtures/seed.ts; mark built-ins immutable, keep definitions free of deployment/private content, and create a new version only when the normalized definition changes.

4. Implement one authoritative resolver and management layer. Add DB helpers plus apps/web/src/trpc/commands/presentation-profiles/, expose them through apps/web/src/trpc/routers/_app.ts, and use protectedProcedure from apps/web/src/trpc/init.ts. Support list/detail/history, create, clone, create-new-version, choose user/deployment default, and preview/resolve operations. Enforce admin rights for deployment-shared records and owner rights for personal records in the command layer. Preserve P0 precedence exactly: explicit message choices, action/composer choice, task override, user default, deployment default, then automatic recommendation.

5. Add profile management and the Present composer in the web app. Extend apps/web/src/components/settings/SettingsShell.tsx and the existing personal/admin settings patterns with shared and personal profile management, version history, cloning, and default selection. Integrate a compact Present this action into the existing task action/composer surfaces around apps/web/src/components/tasks/TaskPromptInput.tsx and apps/web/src/app/(sandbox)/task/[taskId]/prompt-input/PromptInput.tsx, with profile, audience, recipe, constrained style, output, preview, Use once, and Save as preset controls. Submit only validated allowlisted values and a resolved profile/version reference through the P0 launch contract.

6. Expose selection and applied-version metadata consistently. Map named and natural-language selection to the same resolver, and add commands only on provider surfaces that already support commands/actions. Extend task/result rendering, including apps/web/src/app/(sandbox)/task/[taskId]/sidebar-panels/TaskInfoPanel.tsx, to show the applied profile and version and offer context-appropriate change, clone, save, static, and motion actions. Consume typed P0 metadata rather than inferring presentation state from arbitrary payload keys.

7. Add pre-render quality and privacy gates. Before media is accepted for delivery, require source/status metadata for material claims, label claims as proposed/in progress/shipped, reject secrets/private-source leakage and raw transcript inclusion, and require alt text plus a readable PNG/text equivalent and transcript for motion. Web/widget output must honor reduced motion, captions/controls, keyboard operation, non-color status cues, and narrow mobile readability. Keep sensitive values out of telemetry and apply the existing ph-no-capture treatment where previews can contain task content.

8. Use provider capability mapping rather than duplicating profile logic. Keep profiles and actions provider-neutral in packages/communication/src/provider.ts and messages.ts; update Slack, Discord, Teams, and Telegram adapters only to expose supported named-command/action paths and preserve P0's native-media/fallback behavior. Unsupported callbacks should degrade to an explicit conversational or web-composer path instead of silently disappearing.

9. Cover storage, resolution, UI, providers, and visible behavior. Add database tests for concurrent version creation, deduplication, immutable references, defaults, cloning, ownership, and deletion rules; tRPC tests for authorization and validation; resolver tests for every precedence level; component tests for settings/composer/result metadata, keyboard/focus/accessibility, reduced motion, and mobile layout; and provider mock tests for supported actions and fallbacks. Add sandbox visual coverage for the composer, profile/version display, and narrow previews, while retaining [Feature]: P0 presentation profile contract, selection, and native delivery #1060's real-client smoke suite for proprietary-client rendering.

10. Document configuration and operations. Update apps/docs/tasks.mdx, personal-settings.mdx, communications.mdx, and self-hosting/architecture guidance with built-ins, schema constraints, precedence, cloning/version behavior, provider support, accessibility/source guarantees, artifact storage limits, retention/cleanup, and optional rendering dependencies.

A practical delivery order is persistence and resolver first, then built-ins and APIs, settings management, composer/result actions, quality gates/provider exposure, and finally full test/docs coverage. This keeps P1 dependent on #1060's stable contract while reusing Roomote's existing immutable-version, protected-command, settings, task metadata, artifact, and provider-adapter patterns.

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

[roomote-community]

I reviewed #1062 against the current repository and prepared a decision-complete P1 implementation plan: view the plan.

Key decisions:

• map “organization” profiles to Roomote’s existing deployment-shared scope rather than introducing a new organization entity;
• store system, deployment, and personal profiles with append-only immutable versions, exact-version cloning, and server-enforced ownership/defaults;
• resolve precedence once and snapshot the applied profile/version into the task run;
• build the web composer, Present this, Use once, and Save as preset on the same shared resolver and sanitized renderer;
• block delivery when accessibility, source/status, privacy, or static-fallback requirements fail.

Implementation remains blocked on #1060. The current develop branch has the sandboxed widget/fallback foundation, but not #1060’s full Presentation Profile schema, typed media contract, precedence resolver, native delivery, and deterministic motion → PNG → text fallback. The plan defines those as prerequisite interfaces rather than duplicating them in P1.