Bezel Team playground-generation-protocol design-001
playground-generation-protocol artifact · for Bezel Team · phase design-001 · status draft
- Should preview storage use content.preview in v1 or create studio_artifact_previews immediately?
- Should playground generation run as a script first, backend route second, or platform task first?
- Should generated playgrounds be public URLs, signed URLs, or authenticated app routes? Recommendation: authenticated/sandboxed app route for customer data; public only for internal dogfood without sensitive data.
playground-generation-protocol artifact · for Bezel Team · phase design-001 · status draft
No explicit evidence field yet. Require tests, screenshots, linked PRs, or reviewed outputs before marking complete.
- Should preview storage use content.preview in v1 or create studio_artifact_previews immediately?
- Should playground generation run as a script first, backend route second, or platform task first?
- Should generated playgrounds be public URLs, signed URLs, or authenticated app routes? Recommendation: authenticated/sandboxed app route for customer data; public only for internal dogfood without sensitive data.
Machine-readable source fields
bezel.playground-generation-protocol
Artifact Playground Generation Protocol
1
Canonical artifacts remain the source of truth. Playgrounds are generated human-review surfaces derived from artifacts so customers can see, test, and comment before build.
2026-05-04T14:57:26.058Z
bezel-team
Wireframe Playground for Bezel Dogfood Screens
- project.overview
- discovery.chat
- screen.map
Justin can visually review the first three Bezel screens and request changes against screen/component ids.
wireframe-spec/design-001
Interactive static HTML showing phase rail, current-step header, next-action panel, discovery chat with extracted facts, screen map cards, Ask Bezel, and model perspectives.
Claude Sonnet for quality; cheaper model acceptable for mechanical regeneration once template stabilizes.
Model returns one complete HTML document with inline CSS/JS, no external dependencies, and clear screen/component ids matching source artifact ids.
Allow model comparison for playground alternatives, but require one accepted synthesis/preview before build.
- Artifact exists as draft or approved studio_artifacts row.
- User or Dreamborn operator clicks Generate Playground.
- Backend job sends artifact content plus playground system prompt to selected model.
- Generated HTML is validated/sanitized enough for sandboxed preview and uploaded to Supabase Storage.
- Preview metadata is stored and linked to artifact id/version.
- Customer opens playground in sandboxed iframe or new preview route.
- Customer comments/requested changes attach to artifact ids, screen ids, state ids, or component ids.
- Accepted changes patch the canonical artifact, not the generated HTML.
- Build plan/agent briefs use approved artifacts and may reference playground preview as visual evidence.
Store preview metadata under studio_artifacts.content.preview if schema changes are not desired.
Create studio_artifact_previews table for production once implementation begins.
- id
- artifact_id
- project_id
- artifact_type
- phase_id
- source_version
- preview_type
- model
- storage_bucket
- storage_path
- public_url
- status
- created_at
- created_by
- error
- Should preview storage use content.preview in v1 or create studio_artifact_previews immediately?
- Should playground generation run as a script first, backend route second, or platform task first?
- Should generated playgrounds be public URLs, signed URLs, or authenticated app routes? Recommendation: authenticated/sandboxed app route for customer data; public only for internal dogfood without sensitive data.
manual_button
Manual generation avoids runaway model cost, avoids regenerating on every edit, makes debugging easier, and keeps review intentional.
Generate Playground
- generate after artifact approval
- generate on explicit revision request
- compare playground variants from multiple models
Screen + Wireframe Design
Turn screen-map, wireframe-spec, and screen-state-spec artifacts into sandboxed interactive previews for HITL review.
Later, generate architecture diagrams, workflow simulations, and release-review previews from other artifacts.
The generated HTML/playground is disposable evidence and review UI. Approved artifact content drives architecture, plan, and build briefs.
- Generated HTML is untrusted and must run in sandboxed iframe or isolated preview route.
- No customer secrets, service keys, credentials, or private environment values are included in generation prompts.
- Generated HTML must use static/sample data derived from artifact content, not live privileged APIs.
- No arbitrary external scripts by default.
- Preview URLs are evidence/review aids, not production deployments.
- Playground comments and accepted changes write back through controlled Bezel APIs, not from generated HTML directly.
- not_generated
- generating
- ready
- needs_regeneration
- failed
- approved_for_reference
- Generate Playground
- Open Playground
- Regenerate
- View Source Artifact
- View Playground Feedback
- Comment on screen/component
- Request change
- Approve preview
- Back to artifact
- View model evidence
- question
- request_change
- approval
- concern
- scope_change
Material feedback must become artifact patches, open questions, revision tasks, or decisions before build planning.
- artifact_id
- screen_id
- flow_id
- state_id
- component_id
| purpose | phase id | artifact type |
|---|---|---|
| Generate interactive preview for project.overview, discovery.chat, and screen.map. | design-001 | wireframe-spec |
| Generate visual screen inventory/review board. | design-001 | screen-map |
| Generate state matrix review surface once artifact exists. | design-001 | screen-state-spec |