Openclaw Website Development System Workflow Spec

# OpenClaw Website Development System Workflow Spec

Status: Proposed  
Date: 2026-03-10  
Audience: Product, design, web engineering, runtime engineering, operations  
Related: [openclaw-web-platform-spec.md](./openclaw-web-platform-spec.md), [openclaw-web-technical-architecture.md](./openclaw-web-technical-architecture.md), [openclaw-local-bridge-protocol-spec.md](./openclaw-local-bridge-protocol-spec.md), [../pi_agent_rust/docs/openclaw-v2-program-upgrade-spec.md](../pi_agent_rust/docs/openclaw-v2-program-upgrade-spec.md), [../pi_agent_rust/docs/openclaw-v2-technical-architecture-spec.md](../pi_agent_rust/docs/openclaw-v2-technical-architecture-spec.md)

## 1. Goal

This document defines the first detailed Manus-style system workflow to be implemented on top of the existing OpenClaw web project.

The `Website Development System` is the flagship V2 template because it lets a user use OpenClaw itself to plan, write, structure, coordinate, and publish a website.

It should work across three environments:

- web control plane for intake, orchestration, review, and result pages
- local OpenClaw runtime for sensitive planning, coding, or content work
- optional cloud hosts for long-running jobs, Browser Operator work, scheduled checks, and publish workflows

## 2. Why This System Should Be First

This system is strategically valuable because it:

- directly demonstrates the hybrid local + web + cloud model
- creates high-clarity outputs that are easy to review and sell
- naturally exercises Browser Operator, artifacts, automations, and Vault
- can be used to build the company’s own website and customer sites
- maps well to the existing `systems`, `tasks`, `artifacts`, and `executionTarget` structures already present in the web codebase

## 3. Current Web Foundation To Reuse

The existing `/Users/lu/开发项目/claw/web` project already provides a strong starting base.

### 3.1 Existing technical base

- Next.js App Router
- TypeScript
- Prisma schema with `Workspace`, `System`, `TaskRun`, `Artifact`, `Automation`, `Device`, and `CloudHost`
- public landing page and authenticated app shell
- systems and task pages
- bridge linking and control-plane scaffolding
- control-plane repository abstraction with memory and Prisma modes

### 3.2 Existing product surfaces to extend

Current routes already imply the correct control-plane shape:

- `/`
- `/app/dashboard`
- `/app/systems`
- `/app/tasks`
- `/api/bridge/*`
- `/api/tasks/*`

The Website Development System should extend this rather than introduce a disconnected parallel product.

## 4. Product Definition

The Website Development System is a guided system template that turns a user’s website goal into:

- a structured strategy brief
- a page and content architecture
- implementation-ready tasks
- content and SEO assets
- optional publish and monitoring workflows

This system should feel like a combination of:

- strategist
- information architect
- copywriter
- implementation planner
- SEO operator
- QA operator
- publisher

## 5. Primary User Types

### 5.1 Solo founder

Needs a company site, product landing page, docs site, waitlist page, or launch page.

### 5.2 Agency or studio

Needs repeatable site-delivery workflows for multiple clients.

### 5.3 Internal product team

Needs marketing sites, feature pages, docs, and release pages with repeatable governance.

### 5.4 Creator or operator

Needs a personal brand site, content hub, or campaign microsite.

## 6. User Promise

The workflow promise should be:

> Give OpenClaw your business context, constraints, and goals. It will help you shape the site, draft the pages, prepare implementation, and coordinate publish steps across your local computer and cloud tools.

## 7. Core Workflow Stages

The system should be built as a staged flow, not a single freeform chat.

### Stage 1: Intake

Collect structured inputs:

- company or project name
- site goal
- target audience
- offer / product / service
- preferred tone
- desired pages
- examples / competitor URLs
- required integrations
- preferred stack
- CMS requirement
- domain / hosting status

### Stage 2: Discovery

System performs:

- competitor scan
- positioning comparison
- reference collection
- target audience synthesis
- messaging risk detection

Likely execution target:

- local for sensitive inputs
- cloud or hybrid for large web research

### Stage 3: Strategy brief

Generate:

- positioning statement
- primary call to action
- user journey summary
- messaging hierarchy
- page recommendations
- design direction notes

### Stage 4: Site architecture

Generate:

- sitemap
- page inventory
- navigation model
- content block plan per page
- CMS content type suggestions

### Stage 5: Page content package

Generate:

- homepage copy
- product/service page copy
- about page copy
- FAQ
- CTA variants
- SEO titles and descriptions
- structured section briefs

### Stage 6: Delivery plan

Generate:

- implementation tickets
- design/system notes
- recommended components
- data model and CMS mapping
- launch checklist

### Stage 7: Build / publish handoff

Support:

- local runtime coding tasks
- repository handoff
- CMS entry creation
- cloud-based publish jobs
- pre-launch QA pass

### Stage 8: Post-launch operations

Support:

- SEO follow-up tasks
- content refresh suggestions
- conversion optimization backlog
- uptime / publish verification workflows

## 8. Recommended Team Blueprint

Suggested role set:

### 8.1 `website_strategist`

Responsible for positioning, audience, and message hierarchy.

### 8.2 `information_architect`

Responsible for sitemap, page model, navigation, and content structure.

### 8.3 `website_copywriter`

Responsible for page-level copy and CTA variations.

### 8.4 `implementation_planner`

Responsible for component plans, engineering work packages, and handoff instructions.

### 8.5 `seo_operator`

Responsible for metadata, keyword mapping, internal linking plan, and search readiness.

### 8.6 `qa_reviewer`

Responsible for consistency checks, missing-content checks, and launch readiness review.

### 8.7 `publisher_operator`

Responsible for CMS/publish/deployment actions and validation.

## 9. Key Outputs

The system should always target a concrete artifact set.

### 9.1 Primary artifact

`WEBSITE_DELIVERY_PACKAGE`

Contains:

- executive summary
- positioning brief
- sitemap
- page briefs
- page copy
- design cues
- implementation backlog
- CMS model outline
- launch checklist

### 9.2 Secondary artifacts

- competitor research memo
- SEO content sheet
- publish checklist
- QA report
- post-launch optimization backlog

## 10. Result Page Requirements

Every website project should end in a result page accessible from web.

The result page must show:

- project overview
- selected execution mode
- linked local device or cloud host
- current stage progress
- sitemap
- page content preview
- implementation package summary
- artifacts generated
- next-step actions
- Vault restore point information

Suggested next-step actions:

- continue editing locally
- create implementation tasks
- export markdown package
- publish to CMS
- run QA review
- schedule post-launch audit
- clone system for another site version

## 11. Execution Target Rules

The website workflow should be able to split work by target.

### 11.1 Local-preferred tasks

Use local runtime by default for:

- sensitive business strategy
- local codebase edits
- proprietary product docs processing
- prompt-heavy refinement loops

### 11.2 Cloud-preferred tasks

Use cloud when available for:

- competitor crawling
- scheduled audits
- publish pipelines
- repetitive Browser Operator checks
- recurring SEO scans

### 11.3 Hybrid tasks

Use hybrid when:

- planning happens locally
- evidence gathering happens in cloud
- final approval happens in web

## 12. Browser Operator Usage

Browser Operator should be a visible stage tool, not a hidden side-effect.

Recommended browser tasks:

- collect competitor page structures
- inspect headline and CTA patterns
- verify metadata and schema presence
- check live pages after publish
- gather lighthouse-like quality observations later

Each browser run should emit evidence that can be attached to artifacts.

## 13. Membership And Plan Gating

This system should plug into the web membership model.

### 13.1 Free plan

- limited website projects
- no cloud publish jobs
- limited artifact retention
- limited competitor scans

### 13.2 Pro plan

- more active website systems
- artifact export
- local bridge linking
- limited automations

### 13.3 Team / Business plan

- shared workspaces
- cloud jobs
- publish workflows
- role-based collaboration
- higher artifact and Vault retention

### 13.4 Enterprise later

- advanced permissions
- approval workflows
- SSO
- audit exports

## 14. CMS And Content Model Requirements

This workflow must connect naturally to CMS-managed sites.

Suggested CMS-oriented entities:

- site project
- page brief
- section brief
- SEO metadata block
- FAQ item
- testimonial item
- CTA block
- blog/article seed later

This lets the result package map into CMS creation or export later.

## 15. Data Model Extensions

The current Prisma schema already supports the broad control-plane objects. For the Website Development System, add metadata conventions before adding many new tables.

### 15.1 `System.metadata`

Store website-specific values such as:

```json
{
  "templateType": "website_development",
  "websiteMode": "marketing_site",
  "brandName": "OpenClaw",
  "primaryGoal": "product_launch",
  "preferredStack": "nextjs",
  "cmsMode": "contentful_or_headless",
  "domainStatus": "planning"
}
```

### 15.2 `TaskRun.inputPayload`

Use structured payloads for stage launches:

```json
{
  "workflowType": "website_development",
  "stage": "strategy_brief",
  "siteProjectId": "site_123",
  "input": {
    "businessName": "Example",
    "audience": "AI product teams",
    "pages": ["home", "pricing", "docs"]
  }
}
```

### 15.3 `Artifact.metadata`

Add render-friendly metadata:

```json
{
  "workflowType": "website_development",
  "artifactRole": "delivery_package",
  "stageCoverage": ["discovery", "strategy", "architecture", "copy"],
  "siteProjectId": "site_123"
}
```

## 16. Recommended Additional Domain Layer

Before introducing many database tables, add a web-domain layer in `src/lib` that describes website workflow semantics.

Suggested files:

```text
src/lib/
  website-system.ts
  website-system-types.ts
  website-system-service.ts
  website-system-render.ts
```

Responsibilities:

- define workflow stages
- validate task inputs
- build artifact sections
- map control-plane records into page models
- keep workflow logic out of route handlers

## 17. UI Information Architecture For This System

### 17.1 New routes to add

Recommended app routes:

- `/app/templates/websites`
- `/app/websites`
- `/app/websites/[websiteId]`
- `/app/websites/[websiteId]/brief`
- `/app/websites/[websiteId]/artifacts/[artifactId]`
- `/app/websites/[websiteId]/publish`

### 17.2 Launch flow

Recommended flow:

1. choose `Website Development System`
2. complete structured intake form
3. choose execution preference: local / cloud / hybrid
4. create system
5. launch first stage task
6. land on website project result page

### 17.3 Website project page sections

- overview
- strategy
- sitemap
- content package
- implementation plan
- artifacts
- automations
- Vault history
- publish controls

## 18. API Direction

Add dedicated route handlers instead of overloading generic endpoints too early.

Suggested API surface:

- `POST /api/websites`
- `GET /api/websites`
- `GET /api/websites/:id`
- `POST /api/websites/:id/launch-stage`
- `GET /api/websites/:id/artifacts`
- `POST /api/websites/:id/publish`
- `POST /api/websites/:id/run-audit`

These endpoints should internally map to existing control-plane concepts:

- create `System`
- create `TaskRun`
- attach `Artifact`
- create `Automation`

## 19. Vault Integration Requirements

This workflow must exercise the V2 Vault model from the beginning.

### 19.1 Required restore points

Auto-create checkpoints at:

- after intake completion
- after strategy brief acceptance
- before implementation package generation
- before publish
- after successful publish

### 19.2 Common Vault actions

Users should be able to:

- duplicate the site system for a variant
- branch for a redesign
- restore pre-publish state
- compare two content versions

## 20. Automation Opportunities

The Website Development System should be one of the first systems with obvious automation value.

Recommended early automations:

- weekly SEO audit
- publish checklist run
- competitor snapshot refresh
- homepage metadata verification
- content freshness reminder

## 21. Implementation Plan Against Current Web Codebase

### Phase 1: workflow shell

Implement:

- template landing page
- website intake form
- website project creation
- website system metadata conventions
- first result page shell

### Phase 2: task and artifact pipeline

Implement:

- stage launch endpoints
- structured task payloads
- website delivery package artifact renderer
- artifact viewing route

### Phase 3: bridge and hybrid execution

Implement:

- local launch approval from website project page
- local device selection in workflow launch
- hybrid run state on result pages

### Phase 4: publish and CMS actions

Implement:

- publish page
- CMS export or push adapters
- cloud publish task support
- post-publish audit run

### Phase 5: team and billing maturity

Implement:

- shared review
- role-aware actions
- plan-based limits
- richer automation controls

## 22. Immediate Engineering Tasks

1. Add `website-system-types.ts` and `website-system-service.ts`
2. Create `/app/templates/websites` and `/app/websites` routes
3. Add structured website intake form model
4. Add `workflowType` and `stage` conventions to task payloads
5. Add website artifact rendering helpers
6. Add website-specific mock/demo data before Prisma-backed persistence is complete
7. Extend dashboard navigation with template-first entry

## 23. Acceptance Criteria

This workflow spec is implementation-ready when the team can use it to build:

- a website template launcher
- a website project object backed by existing control-plane entities
- structured stage execution
- result pages for website delivery packages
- local/cloud/hybrid launch decisions
- Vault-aware checkpoints
- publish and audit follow-up hooks