spec · supabase_json
BezelIQ Studio spec
spec artifact · for BezelIQ Studio · status approved
open questions
| id | question |
|---|---|
| OQ-5.1 | Should Ops Studio be rewritten as native Vue components, or remain an iframe over the live cockpit until the operational surface stabilizes? |
| OQ-5.2 | Should Marketing Studio's archived project row be restored as an active project artifact record, or should Marketing remain represented only as a product surface inside the BezelIQ Studio project? |
Agent Handoff
Start Here
spec artifact · for BezelIQ Studio · status approved
Completion Evidence
No explicit evidence field yet. Require tests, screenshots, linked PRs, or reviewed outputs before marking complete.
Open Questions
- OQ-5.1: id: string, question: string
- OQ-5.2: id: string, question: string
Structured Payload
Machine-readable source fields
phase
id
main
name
BezelIQ Studio Current Implementation
status
implemented
depends on
No items captured.
version
1
features
| id | name | scope | phase id | scenarios | edge cases |
|---|---|---|---|---|---|
| FEAT-1.1 | Project Scaffold | Initialize the repo with Vite + Vue 3, install dependencies, wire Dreamborn Forge CSS, and verify the dev server starts with forge tokens active. Does not include any page components or routes. | phase-1 | - Dev server starts clean: name: string, then: string, when: string, given: string - Forge tokens are active: name: string, then: string, when: string, given: string - dreamborn.css is self-hosted: name: string, then: string, when: string, given: string | - item: case: string, expected: string |
| FEAT-1.2 | Supabase Client | Create and export a single initialized Supabase client from src/lib/supabase.js. Auth is configured in the client but no route guards are implemented. Does not include any queries — just the client singleton. | phase-1 | - Client initializes from env vars: name: string, then: string, when: string, given: string - Missing env vars are caught at startup: name: string, then: string, when: string, given: string - Auth is configured but not enforced: name: string, then: string, when: string, given: string | - item: case: string, expected: string |
| FEAT-1.3 | Vue Router + Route Structure | Define all application routes using Vue Router 4 in history mode. Phase 2-4 routes render stub components with a placeholder message. All routes are wrapped by AppShell. Does not include AppShell implementation — that is FEAT-1.4. | phase-1 | - All defined routes are navigable: name: string, then: string, when: string, given: string - Undefined route shows not-found view: name: string, then: string, when: string, given: string - Route params are accessible: name: string, then: string, when: string, given: string - Nested route params are accessible: name: string, then: string, when: string, given: string | - item: case: string, expected: string - item: case: string, expected: string |
| FEAT-1.4 | Platform Shell | AppShell.vue — persistent layout with left nav sidebar and content area. Sidebar shows BezelIQ wordmark, all studio links, and active state. Content area renders <router-view />. Desktop only (min-width: 1024px). Does not include the studio picker page — that is FEAT-1.5. | phase-1 | - Shell persists across route navigation: name: string, then: string, when: string, given: string - Active studio is highlighted in nav: name: string, then: string, when: string, given: string - Clicking a nav studio item navigates: name: string, then: string, when: string, given: string - Coming soon studios are visible but non-navigable: name: string, then: string, when: string, given: string - Cockpit nav item opens external link: name: string, then: string, when: string, given: string | - item: case: string, expected: string |
| FEAT-1.5 | Studio Picker | The / route renders a grid of studio cards — Dev Studio (active), Sales/Marketing/Finance (coming soon), Cockpit (external link). Each card shows studio name, one-line description, and status. Clicking Dev Studio navigates to /dev. | phase-1 | - Studio picker renders all studios: name: string, then: string, when: string, given: string - Dev Studio card navigates: name: string, then: string, when: string, given: string - Coming soon cards are non-navigable: name: string, then: string, when: string, given: string - Cockpit card opens external link: name: string, then: string, when: string, given: string | - item: case: string, expected: string |
| FEAT-2.1 | Dev Studio Project List | The /dev route renders a list of all Studio projects with artifact completion status. Reads studio_projects and studio_artifacts tables. Does not include any write operations. | phase-2 | - Project list renders with artifact status: name: string, then: string, when: string, given: string - Empty state when no projects exist: name: string, then: string, when: string, given: string - Clicking a project navigates to detail: name: string, then: string, when: string, given: string - New Project button navigates to intake: name: string, then: string, when: string, given: string - Projects are ordered by creation date descending: name: string, then: string, when: string, given: string | - item: case: string, expected: string - item: case: string, expected: string |
| FEAT-2.2 | New Project Intake Form | The /dev/new route renders a multi-section intake form. On submit, creates a row in studio_projects and writes the INTENT.json artifact to studio_artifacts. Navigates to /dev/:projectId on success. All INTENT.json fields from the template are represented as form inputs. | phase-2 | - Intake form renders all INTENT.json sections: name: string, then: string, when: string, given: string - Successful submit creates project and artifact: name: string, then: string, when: string, given: string - Required field validation blocks submit: name: string, then: string, when: string, given: string - Dynamic list fields allow add and remove: name: string, then: string, when: string, given: string - Cancel navigates back to project list: name: string, then: string, when: string, given: string | - item: case: string, expected: string - item: case: string, expected: string |
| FEAT-2.3 | Project Detail Dashboard | The /dev/:projectId route renders a project overview with four artifact status cards (INTENT, BLUEPRINT, SPEC, POLICY). Each card shows artifact status and links to the artifact view. A Build section shows readiness state. Read-only in this phase — no writes. | phase-2 | - Dashboard renders artifact status cards: name: string, then: string, when: string, given: string - Missing artifact card prompts creation: name: string, then: string, when: string, given: string - Existing artifact card links to view: name: string, then: string, when: string, given: string - Build readiness indicator reflects approval state: name: string, then: string, when: string, given: string - All artifacts approved enables Build: name: string, then: string, when: string, given: string - Project not found shows error: name: string, then: string, when: string, given: string | - item: case: string, expected: string - item: case: string, expected: string |
| FEAT-3.1 | ArtifactView Shell | A single parameterized component at src/views/ArtifactView.vue that handles the /dev/:projectId/intent, /dev/:projectId/blueprint, /dev/:projectId/spec/:phaseId, and /dev/:projectId/policy routes. Responsible for loading the artifact, routing to the correct renderer, and wiring approve/reject actions. Does not implement any per-type rendering — that is FEAT-3.2 through 3.5. | phase-3 | - ArtifactView loads the correct artifact by route: name: string, then: string, when: string, given: string - ArtifactView handles missing artifact gracefully: name: string, then: string, when: string, given: string - Edit mode toggles between rendered view and editor: name: string, then: string, when: string, given: string - Approve action updates artifact status: name: string, then: string, when: string, given: string - Reject action updates artifact status: name: string, then: string, when: string, given: string - Back navigation returns to project detail: name: string, then: string, when: | - item: case: string, expected: string |
| FEAT-3.2 | INTENT Renderer + Editor | Rendered human view and structured editor for artifact_type=intent. Renderer displays all INTENT.json fields as readable sections. Editor provides form inputs matching each field. No raw JSON visible to the user at any point. | phase-3 | - INTENT renderer displays all sections: name: string, then: string, when: string, given: string - INTENT editor pre-fills from existing content: name: string, then: string, when: string, given: string - INTENT editor save writes updated content: name: string, then: string, when: string, given: string - Approving INTENT resets to draft on next edit: name: string, then: string, when: string, given: string | - item: case: string, expected: string |
| FEAT-3.3 | BLUEPRINT Renderer + Editor | Rendered human view and structured editor for artifact_type=blueprint. Renderer displays stack, schema tables, API operations, and env vars as readable formatted sections. Editor provides structured inputs — not a JSON text field. | phase-3 | - BLUEPRINT renderer displays schema as a table: name: string, then: string, when: string, given: string - BLUEPRINT renderer displays stack and services: name: string, then: string, when: string, given: string - BLUEPRINT renderer displays API operations: name: string, then: string, when: string, given: string - BLUEPRINT editor allows adding and editing tables: name: string, then: string, when: string, given: string | - item: case: string, expected: string - item: case: string, expected: string |
| FEAT-3.4 | SPEC Renderer + Editor | Rendered human view and structured editor for artifact_type=spec. Renderer displays phase features as readable behavior contracts. Editor provides structured inputs for scenarios, error states, edge cases, and completion contract criteria. One SPEC artifact per phase. | phase-3 | - SPEC renderer displays features as behavior contracts: name: string, then: string, when: string, given: string - SPEC renderer highlights open questions: name: string, then: string, when: string, given: string - SPEC renderer shows phase metadata: name: string, then: string, when: string, given: string - SPEC editor allows adding scenarios to a feature: name: string, then: string, when: string, given: string | - item: case: string, expected: string - item: case: string, expected: string |
| FEAT-3.5 | POLICY Renderer + Editor | Rendered human view and structured editor for artifact_type=policy. Renderer displays rules as a table grouped by severity. Hard rules are visually distinct from warn rules. Editor allows adding, editing, and removing rules. | phase-3 | - POLICY renderer displays rules grouped by severity: name: string, then: string, when: string, given: string - POLICY renderer shows rule count summary: name: string, then: string, when: string, given: string - POLICY editor allows adding a new rule: name: string, then: string, when: string, given: string - POLICY editor allows removing a rule: name: string, then: string, when: string, given: string | - item: case: string, expected: string - item: case: string, expected: string |
| FEAT-4.1 | Build View | The /dev/:projectId/build route renders a live view of agent task progress for the project. Reads agent_tasks from the platform Supabase instance filtered by project_id. Realtime subscription keeps the view current as tasks are claimed and completed. Read-only — no writes except via exec gate actions in FEAT-4.2. | phase-4 | - Build view renders task list for project: name: string, then: string, when: string, given: string - Realtime subscription updates task status live: name: string, then: string, when: string, given: string - Blocked task is visually prominent: name: string, then: string, when: string, given: string - Completed tasks show output reference: name: string, then: string, when: string, given: string - Empty state when no tasks exist: name: string, then: string, when: string, given: string - Build completion state: name: string, then: string, when: string, given: string | - item: case: string, expected: string - item: case: string, expected: string - item: case: string, expected: string |
| FEAT-4.2 | Exec Gate Approval Flow | Exec gate tasks (role=exec, status=assigned) appear in the build view as a distinct approval queue. Each gate shows the task brief and two actions: Approve and Block. Both actions POST to hcs-post-server after a confirmation step. A reason is required to block. | phase-4 | - Exec gate tasks appear in a distinct queue: name: string, then: string, when: string, given: string - Approve posts task.complete to HCS: name: string, then: string, when: string, given: string - Block posts task.blocked to HCS with reason: name: string, then: string, when: string, given: string - No exec gate tasks shows empty queue state: name: string, then: string, when: string, given: string - Realtime updates exec gate queue: name: string, then: string, when: string, given: string | - item: case: string, expected: string - item: case: string, expected: string - item: case: string, expected: string |
| FEAT-5.1 | Two-layer Studio Shell | Replace the original Dev-only sidebar with a persistent icon rail plus contextual flyout. The shell is shared by Ops Studio, Dev Studio, Marketing Studio, Sales Studio, Finance Studio, and product routes. | phase-5 | ||
| FEAT-5.2 | Ops Studio Embedded Cockpit | The /ops route embeds the live Ops Studio cockpit through /cockpit-frame so operations monitoring lives inside BezelIQ Studio instead of a separate cockpit-only surface. | phase-5 | ||
| FEAT-5.3 | Current Dev Studio Project List | The /dev route must list all active/non-archived Studio projects from RedKey Supabase, not only rows tied to one client or a stale hard-coded project set. | phase-5 | ||
| FEAT-5.4 | Marketing Studio Frame | The /marketing route and nested Marketing routes embed the standalone Marketing Studio service through /marketing-frame while preserving the shared Studio shell. | phase-5 | ||
| FEAT-5.5 | Product and Tool Routes | Studio includes product/tool access alongside studios, including the AD SEO product page and route continuity for external product surfaces. | phase-5 |
project id
bezeliq-studio
updated at
2026-05-03T20:28:40.637Z
open questions
| id | question |
|---|---|
| OQ-5.1 | Should Ops Studio be rewritten as native Vue components, or remain an iframe over the live cockpit until the operational surface stabilizes? |
| OQ-5.2 | Should Marketing Studio's archived project row be restored as an active project artifact record, or should Marketing remain represented only as a product surface inside the BezelIQ Studio project? |
phase inventory
| id | name | status | feature count |
|---|---|---|---|
| phase-1 | Foundation + Platform Shell | approved | 5 |
| phase-2 | Dev Studio: Project List + Intake | approved | 3 |
| phase-3 | Artifact Views | approved | 5 |
| phase-4 | Build View + Exec Gate | approved | 2 |
| phase-5 | Unified Shell, Ops Studio, Marketing Frame, and Product Routes | implemented | 5 |
cross feature constraints
- All components must use <script setup> composition API syntax
- All colors, spacing, and typography must use --db-* forge tokens — no hardcoded values
- data-register='forge' must be present on the app root element before any component renders
- No external font or CDN requests — verified by POLICY rule no-external-fonts
- Supabase client must be imported from src/lib/supabase.js — never initialized inline in a component
- studio_projects and studio_artifacts tables are the only write targets in this phase
- All Supabase queries use the singleton client from src/lib/supabase.js
- Loading states must be explicit — never a blank screen while data is fetching
- All status badges use forge status tokens — no custom colors
- All forge design token constraints from Phase 1 cross_feature_constraints carry forward
- No artifact type ever renders its raw JSON content — Studio always renders a human view
- Approve action always requires a confirmation step — never a single click
- Saving any change to an approved artifact resets its status to draft
- All renderer components are read-only — no inline editing without explicitly entering edit mode
- All forge design token constraints from Phase 1 carry forward
- Renderer and Editor components for each type live in src/components/artifacts/ — not inlined into ArtifactView
- agent_tasks is read-only from Studio — the only writes to platform tables are HCS messages via hcs-post-server
- Realtime subscriptions must be removed in onUnmounted — per POLICY rule realtime-cleanup
- HCS topic IDs (task.topic_id) are used internally for POST bodies but never surfaced as visible text in the UI
- All exec gate actions require confirmation — no single-click irreversible actions
- All forge design token constraints from Phase 1 carry forward
- BezelIQ Studio's live project database must include a current BezelIQ Studio project record so /dev does not imply that the Studio work stopped at the old Dev-only phase.
- The Studio project artifacts must include phases 1-5, with phase 5 covering unified shell, Ops, Marketing, product routes, and production env reconciliation.
- The deployed Studio bundle must be built with Vite Supabase env variables; otherwise Dev Studio project list regresses to the null-client load-error branch.
- Ops Studio remains a live iframe integration over the cockpit frame until the cockpit is fully migrated into Vue components.
- Marketing Studio remains an embedded standalone service until its data and screens are folded into the main Vue app.