Table of Contents

• Core idea
• Goals
• Non-goals
• Recommended decision
  • Runtime implementation
  • Deployment abstraction
  • Cloudflare deployment adapter path
• 1. Hosted Cloudflare Workers Architecture
  • 1.1 High-level architecture
  • 1.2 Core components
• 2. Cloudflare Deployment Model
  • 2.1 MVP model: one Worker per project environment
  • 2.2 Scale model: Workers for Platforms dispatch namespace
  • 2.3 Static assets
• 3. Branching Strategy Recommendation
  • 3.1 Recommended strategy: two environment branches + short-lived AI branches
  • 3.2 Branch responsibilities
  • 3.3 Deployment flow
  • 3.4 Why not GitFlow
  • 3.5 Why not single-branch trunk-only
• 4. Repository Initialization Model
  • 4.1 Required initializer
  • 4.2 Repository structure
  • 4.3 .roguvibe/project.json
  • 4.4 AGENTS.md
• 5. GitHub Repository Automation
  • 5.1 Shared user + PAT model
  • 5.2 Initialization sequence
  • 5.3 Branch protection
  • 5.4 GitHub Environments
• 6. GitHub Actions Workflows
  • 6.1 Validation workflow
  • 6.2 Deployment workflow
  • 6.3 Why the workflow calls roguvibe deploy
• 7. roguvibe.yaml v1
  • 7.1 Recommended manifest
  • 7.2 Cloudflare Worker environment variable model
  • 7.3 Backend configuration boundary
  • 7.4 Secret safety rules
  • 7.5 Fields intentionally not present
  • 7.6 Branch mapping
• 8. Automatic Hostnames and Domains
  • 8.1 Hostname rule
  • 8.2 Project ID source
  • 8.3 Domain routing
• 9. Secrets and Environment Variables
  • 9.1 Secret ownership
  • 9.2 Recommended flow
• 10. AI Agent Skill Model
  • 10.1 Required skills
  • 10.2 Skill contracts
  • 10.3 Agent safety rules
• 11. Rollback Model
  • 11.1 Runtime rollback
  • 11.2 Git alignment after rollback
• 12. Observability and Status
  • 12.1 Deployment status
  • 12.2 User-facing status
  • 12.3 Logs
• 13. Implementation Phases
  • MVP Implementation Phases
  • Phase 0 — Hosted Workers spike
  • Phase 1 — Repo scaffold and branch model
  • Phase 2 — GitHub repo automation
  • Phase 3 — Platform deploy API and CLI
  • Phase 4 — Cloudflare MVP adapter
  • Phase 5 — AI skills and promotion workflow
  • Phase 6 — Workers for Platforms evaluation/migration
• 14. Risks and Mitigations
  • 14.1 Shared GitHub PAT blast radius
  • 14.2 Cloudflare credential leakage
  • 14.3 Branch confusion
  • 14.4 Git/runtime drift after rollback
  • 14.5 Cloudflare limits and product fit
  • 14.6 Non-Worker-compatible generated code
• 15. Recommended MVP Scope
• 16. Final Recommendation
• 17. Primary references

Core idea

Build the same user-facing product as PLAN 4: a Vercel-like deployment platform for generated TypeScript sites/apps/tools with Git-based deployment, roguvibe.yaml, automatic URLs, logs, rollback, and generic Cloudflare Worker runtime configuration.

The implementation changes:

PLAN 4: generated app → platform build → self-hosted Cloudflare workerd runtime pool
PLAN 5: generated app → GitHub Actions CI/CD → platform deploy layer → Cloudflare hosted Workers

Users should not need to understand Cloudflare Workers, Wrangler, dispatch namespaces, routes, assets, compatibility dates, or API tokens. The platform should expose simple concepts:

Project
Environment: development | production
Deployment
URL
Logs
Rollback

Internally, the platform uses Cloudflare hosted Workers, which are powered by Cloudflare's managed V8 isolate runtime.

Goals

1. Provide a Vercel-like deployment experience for generated TypeScript apps/sites/tools.
2. Use Cloudflare hosted Workers as the runtime instead of self-hosting workerd.
3. Use GitHub repositories as the source of truth for vibe-coded app code.
4. Use GitHub Actions hosted runners to execute CI/CD pipelines.
5. Provide a simple branching model for non-engineering users and AI agents.
6. Initialize each project repo locally and in GitHub with required branches, workflows, manifest, and agent instructions.
7. Hide Cloudflare-specific deployment details behind a platform CLI/API.
8. Keep roguvibe.yaml simple and free of infrastructure knobs like memory request/limit.
9. Support development and production deployments.
10. Make the repo lifecycle manageable by AI skills: initialize, change, deploy to development, promote to production, rollback.

Non-goals

1. Do not build or operate a self-hosted Cloudflare workerd runtime pool.
2. Do not expose raw Cloudflare Worker concepts as the primary user interface.
3. Do not require non-engineering users to use Git directly.
4. Do not support arbitrary Docker apps in this runtime tier.
5. Do not initially support languages beyond TypeScript/JavaScript.
6. Do not put Cloudflare account API tokens into user-owned generated app repos unless there is no platform-token alternative.
7. Do not include memory request/limit fields in roguvibe.yaml.

Recommended decision

roguvibe deploy --environment development --commit "$GITHUB_SHA"
roguvibe deploy --environment production --commit "$GITHUB_SHA"
roguvibe validate
roguvibe status --environment production
roguvibe rollback --environment production --to <deployment-id>

GitHub Actions runner
  → roguvibe CLI
  → Platform Deploy API
  → Cloudflare Deploy Adapter
      → MVP adapter: per-project/per-environment Worker
      → Scale adapter: Workers for Platforms dispatch namespace

1.1 High-level architecture

User / AI agent
  ↓
Generated TypeScript app repo on GitHub
  ↓ push / PR / promotion
GitHub Actions hosted runner
  ↓
install + validate + test + build
  ↓
roguvibe CLI
  ↓
Platform Deploy API
  ↓
Cloudflare Deploy Adapter
  ↓
Cloudflare hosted Workers
  ↓
<repo-name>--<project-id>-dev.sirogu.com
<repo-name>--<project-id>.sirogu.com

1.2 Core components

2.1 MVP model: one Worker per project environment

Each project gets two Cloudflare Worker services:

roguvibe-<project-id>-development
roguvibe-<project-id>-production

Branch mapping:

development branch → development environment → roguvibe-<project-id>-development
production branch  → production environment  → roguvibe-<project-id>-production

Hostnames:

<repo-name>--<project-id>-dev.sirogu.com  → development Worker
<repo-name>--<project-id>.sirogu.com      → production Worker

Strengths:

• Simple mental model.
• Easy to debug in Cloudflare dashboard.
• Easy to map one environment to one Worker.
• Works well with wrangler deploy --env or Cloudflare API.
• Fastest path to MVP.

Weaknesses:

• Many Workers over time.
• More route/domain objects to manage.
• Cloudflare account limits and naming limits must be watched.
• Cross-project shared routing and policy are harder than with a central dispatcher.

Decision:

Use this for MVP unless Cloudflare account/product constraints make Workers for Platforms immediately necessary.

2.2 Scale model: Workers for Platforms dispatch namespace

For a larger multi-tenant platform, use Cloudflare Workers for Platforms:

Wildcard/custom domain route
  ↓
Platform dispatcher Worker
  ↓
Dispatch namespace
  ↓
User Worker script for project/environment/version

Conceptual mapping:

Host: <repo-name>--<project-id>.sirogu.com
  → dispatcher reads host
  → lookup project-id + environment in platform registry
  → dispatch to user Worker in namespace

Strengths:

• Better fit for a platform deploying code on behalf of many projects.
• Centralized dispatch/routing logic.
• Fewer top-level Worker services.
• Easier to implement platform-level policies.
• Better long-term abstraction for many user apps/tools.

Weaknesses:

• More Cloudflare-specific architecture.
• More complex local testing.
• More custom deploy code.
• Requires validating product limits, pricing, and account availability.

Decision:

Design the platform deploy layer so the MVP adapter can be replaced by a Workers for Platforms adapter without changing generated repos.

2.3 Static assets

Use Cloudflare Workers Static Assets for new static/full-stack projects when the project shape fits.

Recommended mapping:

build.output.server → Worker module entrypoint
build.output.assets → Workers Static Assets directory

For full-stack apps:

• Worker handles API/server routes.
• Static assets are served through the Worker assets binding.
• SPA fallback can use Cloudflare asset not-found handling.

3.1 Recommended strategy: two environment branches + short-lived AI branches

Use a simple environment-branch model:

development  = default branch, development environment
production   = protected branch, production environment
ai/<task>    = short-lived AI implementation branch

This is intentionally simpler than GitFlow and more explicit than trunk-based deployment for non-engineering users.

"test it"     → development
"publish it"  → production

push/merge to development → deploy development
merge to production       → deploy production

3.2 Branch responsibilities

ai/add-login-page
ai/fix-dashboard-filter
ai/update-backend-config

3.3 Deployment flow

AI/user requests change
  ↓
AI creates ai/<task> from development
  ↓
AI edits code
  ↓
AI opens PR to development
  ↓
validation workflow passes
  ↓
AI merges PR to development
  ↓
GitHub Actions deploys development
  ↓
user reviews development URL

User says "publish" / "release to production"
  ↓
AI verifies development deployment is healthy
  ↓
AI opens PR: development → production
  ↓
production validation passes
  ↓
AI merges PR after approval policy is satisfied
  ↓
GitHub Actions deploys production
  ↓
platform records production deployment

3.4 Why not GitFlow

Avoid classic GitFlow with develop, release/*, hotfix/*, and version branches.

Reasons:

• Too many branch concepts for non-engineering users.
• Too much ceremony for generated apps/sites/tools.
• Harder for AI agents to explain and recover from mistakes.
• Most projects only need development and production.

3.5 Why not single-branch trunk-only

Single-branch trunk deployment is simple for experienced engineers, but less ideal here.

Problems:

• Non-engineering users need a clear separation between "try it" and "publish it".
• AI agents need a safe place to land changes before production.
• Production promotion should be explicit.

Trunk-based can be revisited later for advanced users.

4.1 Required initializer

Create a platform command:

roguvibe project init <project-name>

Inputs:

project name
GitHub owner/org
app type: site | app | tool
non-sensitive Worker env vars
secret names required by the app

Outputs:

local git repo
GitHub repo
initialized branches
workflow files
roguvibe.yaml
project metadata
platform registry record
Cloudflare deployment placeholders

4.2 Repository structure

Recommended generated repo:

.
├── .github/
│   └── workflows/
│       ├── validate.yml
│       └── deploy.yml
├── .roguvibe/
│   ├── project.json
│   └── branch-policy.md
├── src/
│   └── index.ts
├── public/
├── AGENTS.md
├── roguvibe.yaml
├── package.json
├── package-lock.json
├── tsconfig.json
└── README.md

4.3 .roguvibe/project.json

Machine-readable metadata for AI agents and workflows:

{
  "version": 1,
  "projectId": "p_abc123",
  "appName": "request-dashboard",
  "platform": "roguvibe",
  "manifest": "roguvibe.yaml",
  "branches": {
    "development": "development",
    "production": "production"
  },
  "environments": {
    "development": {
      "url": "https://request-dashboard--p-abc123-dev.sirogu.com"
    },
    "production": {
      "url": "https://request-dashboard--p-abc123.sirogu.com"
    }
  }
}

This file should not contain secrets.

4.4 AGENTS.md

Each repo should include explicit AI operating rules:

# AI Agent Instructions

## Branches

- Use `development` for development deployments.
- Use `production` only for production releases.
- Create task branches as `ai/<short-task-name>` from `development`.
- Never commit directly to `production`.
- Promote by opening a PR from `development` to `production`.

## Commands

- Validate: `npm run validate`
- Test: `npm test`
- Build: `npm run build`
- Platform validation: `npx roguvibe validate`

## Deployment

- Pushing to `development` deploys development.
- Merging to `production` deploys production.
- Do not edit `.github/workflows/*` unless the task explicitly asks for CI/CD changes.
- Do not add Cloudflare secrets to the repo.

5.1 Shared user + PAT model

MVP assumption:

Each project repo is created under a shared GitHub user/org using a shared machine user + PAT.

Use a fine-grained PAT where possible.

Minimum capabilities likely needed:

• Create repositories under the target owner/org.
• Read/write repository contents.
• Manage repository metadata.
• Manage Actions secrets/variables.
• Manage environments.
• Manage branch protection rules.
• Create PRs and merge PRs if AI promotion is automated.

Security warning:

A shared PAT is high blast-radius. Store it only in the platform secret manager, rotate it regularly, and log every repo operation. The long-term target should be a GitHub App with per-repository installation permissions.

5.2 Initialization sequence

1. Platform receives create-project request.
2. Platform creates local scaffold from template.
3. Platform initializes git repo.
4. Platform commits initial files.
5. Platform creates GitHub repo with shared machine user/PAT.
6. Platform pushes `development` branch.
7. Platform creates `production` branch from the same initial commit.
8. Platform sets default branch to `development`.
9. Platform creates GitHub Environments: development, production.
10. Platform creates repo variables: ROGUVIBE_PROJECT_ID, ROGUVIBE_API_URL.
11. Platform creates environment secret: ROGUVIBE_DEPLOY_TOKEN.
12. Platform configures branch protection.
13. Platform registers project in platform DB.
14. Platform provisions Cloudflare Worker placeholders or dispatch namespace mapping.
15. Platform triggers first development deployment.

5.3 Branch protection

Recommended rules:

5.4 GitHub Environments

Create two GitHub Environments:

development
production

Use them for:

• Environment-specific secrets.
• Deployment history in GitHub UI.
• Optional production approval.
• Environment-specific URLs.

Recommended secret strategy:

Repository/environment contains only ROGUVIBE_DEPLOY_TOKEN.
Cloudflare API token stays in platform secret manager.

Avoid putting these in generated app repos:

CLOUDFLARE_API_TOKEN
CLOUDFLARE_ACCOUNT_ID
Cloudflare zone tokens
backend admin/root credentials
API keys
database passwords
bearer tokens

6.1 Validation workflow

.github/workflows/validate.yml:

name: Validate

on:
  pull_request:
    branches:
      - development
      - production
  workflow_dispatch:

permissions:
  contents: read

jobs:
  validate:
    runs-on: tke-fe-small-runner
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-node@v5
        with:
          node-version: 22
          cache: npm

      - run: npm ci
      - run: npm run typecheck --if-present
      - run: npm test --if-present
      - run: npm run build
      - run: npx roguvibe validate

6.2 Deployment workflow

.github/workflows/deploy.yml:

name: Deploy

on:
  push:
    branches:
      - development
      - production
  workflow_dispatch:
    inputs:
      environment:
        description: Environment to deploy
        required: true
        type: choice
        options:
          - development
          - production

permissions:
  contents: read
  deployments: write

concurrency:
  group: deploy-${{ github.ref_name }}
  cancel-in-progress: false

jobs:
  resolve:
    runs-on: tke-fe-small-runner
    outputs:
      environment: ${{ steps.env.outputs.environment }}
    steps:
      - id: env
        shell: bash
        run: |
          if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then
            echo "environment=${{ inputs.environment }}" >> "$GITHUB_OUTPUT"
          elif [ "${{ github.ref_name }}" = "production" ]; then
            echo "environment=production" >> "$GITHUB_OUTPUT"
          else
            echo "environment=development" >> "$GITHUB_OUTPUT"
          fi

  deploy:
    needs: resolve
    runs-on: tke-fe-small-runner
    timeout-minutes: 30
    environment: ${{ needs.resolve.outputs.environment }}
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-node@v5
        with:
          node-version: 22
          cache: npm

      - run: npm ci
      - run: npm run build
      - run: npx roguvibe validate

      - name: Deploy through RoguVibe
        env:
          ROGUVIBE_API_URL: ${{ vars.ROGUVIBE_API_URL }}
          ROGUVIBE_PROJECT_ID: ${{ vars.ROGUVIBE_PROJECT_ID }}
          ROGUVIBE_DEPLOY_TOKEN: ${{ secrets.ROGUVIBE_DEPLOY_TOKEN }}
          ROGUVIBE_ENVIRONMENT: ${{ needs.resolve.outputs.environment }}
        run: |
          npx roguvibe deploy \
            --project "$ROGUVIBE_PROJECT_ID" \
            --environment "$ROGUVIBE_ENVIRONMENT" \
            --commit "$GITHUB_SHA"

6.3 Why the workflow calls roguvibe deploy

This keeps generated repos stable even if the Cloudflare implementation changes:

Today: roguvibe deploy → per-environment Worker
Later: roguvibe deploy → Workers for Platforms dispatch namespace

Generated repos do not need to change.

7.1 Recommended manifest

version: 1

app:
  name: request-dashboard
  type: app

source:
  entrypoint: src/index.ts
  assets: public

build:
  command: npm run build
  output:
    server: dist/worker.js
    assets: dist/public

env:
  vars:
    API_BASE_URL:
      development: https://api-dev.example.com
      production: https://api.example.com
    FEATURE_FLAG_EXAMPLE:
      development: "true"
      production: "false"
  secrets:
    - BACKEND_API_KEY
    - DB_USERNAME
    - DB_PASSWORD

7.2 Cloudflare Worker environment variable model

Use roguvibe.yaml as the platform-level abstraction for Cloudflare Worker environment configuration.

The manifest can define:

• env.vars: non-sensitive text/JSON values safe to commit to Git.
• env.secrets: secret names only. Values are never stored in Git.

This mirrors Cloudflare Workers' distinction between environment variables and secrets:

• plain environment variables are available to the Worker through env.<NAME> and may be stored as configuration;
• secrets are sensitive values exposed to the Worker through the same env.<NAME> interface but must be stored securely outside the repo.

Example Worker usage:

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const response = await fetch(`${env.API_BASE_URL}/health`, {
      headers: {
        Authorization: `Bearer ${env.BACKEND_API_KEY}`,
      },
    });

    return response;
  },
};

7.3 Backend configuration boundary

Backend provisioning and database/backend product selection are out of scope for this plan. Another workstream owns that research and discovery.

This platform only needs to ensure deployed Cloudflare Worker apps can receive and use backend connection configuration through the generic env.vars / env.secrets model. Examples:

API_BASE_URL        → env.vars
BACKEND_API_KEY    → env.secrets
DB_HOST            → env.vars or env.secrets depending on sensitivity
DB_USERNAME        → env.secrets
DB_PASSWORD        → env.secrets

For HTTP backends, generated apps can use standard fetch. For direct TCP backends, validate Cloudflare Workers connect() support and product limits before committing to a template.

7.4 Secret safety rules

Vibe coders and AI agents must not push secret values to Git.

Rules:

1. env.vars may contain only non-sensitive values.
2. env.secrets may contain only secret names, never secret values.
3. Secret values must be written through platform UI/API/CLI, not by editing roguvibe.yaml.
4. The platform stores secret values in its secret manager.
5. The Cloudflare Deploy Adapter writes secret values to Cloudflare Worker secrets during deploy.
6. Generated repos may include .dev.vars.example or .env.example with placeholder values only.
7. Generated repos must ignore local secret files such as .dev.vars, .env, and .env.local.
8. CI must run secret scanning before deploy and fail if likely credentials are committed.
9. roguvibe validate must reject suspicious env.vars values that look like credentials.
10. Pre-commit hooks should run the same secret scan locally where possible.

Validation heuristics:

• Reject env.vars keys matching sensitive names: *_KEY, *_SECRET, *_TOKEN, *_PASSWORD, *_PASS, *_USERNAME, DATABASE_URL, DB_URL.
• Reject high-entropy values in env.vars.
• Reject URL values in env.vars that contain credentials, such as postgres://user:pass@host/db.
• Reject committed .env, .dev.vars, .env.local, or similar local secret files.
• Allow only placeholder values in *.example files.

Recommended CLI flow:

roguvibe secret set BACKEND_API_KEY --environment development
roguvibe secret set DB_PASSWORD --environment production

The CLI sends secret values directly to the platform API. It must not write them to roguvibe.yaml or commit them to Git.

7.5 Fields intentionally not present

Do not include:

resources:
  memoryMb: 128
  cpu: 1
  replicas: 2

Cloudflare Workers resource behavior should be handled by Cloudflare limits and platform policy, not by vibe-coder manifest fields.

7.6 Branch mapping

Branch mapping should be convention-based for MVP:

development branch → development environment
production branch  → production environment

Do not require users to configure this in roguvibe.yaml unless advanced branch mapping is introduced later.

8.1 Hostname rule

Hostnames are always assigned automatically. There is no hostname field in roguvibe.yaml.

Use the GitHub repository name as <repo-name> / app name:

GitHub repo: request-dashboard
app name: request-dashboard

Development:

<repo-name>--<project-id>-dev.sirogu.com

Production:

<repo-name>--<project-id>.sirogu.com

Example:

request-dashboard--p-abc123-dev.sirogu.com
request-dashboard--p-abc123.sirogu.com

8.2 Project ID source

project-id is generated by the platform control plane during roguvibe project init / project creation.

Recommended source of truth:

Platform projects table: id = p_abc123

The generated ID is then written to non-secret repo metadata and GitHub variables:

.roguvibe/project.json → projectId
GitHub Actions variable → ROGUVIBE_PROJECT_ID
Platform DB → canonical project record

Rules:

• The platform DB is canonical.
• .roguvibe/project.json is a checked-in convenience copy for AI agents and local tooling.
• ROGUVIBE_PROJECT_ID is used by GitHub Actions to identify the project during deploy.
• The project ID should be immutable after creation.
• The project ID should be short, URL-safe, globally unique, and not derived from the repo name.

8.3 Domain routing

MVP with per-environment Workers:

<repo-name>--<project-id>-dev.sirogu.com → development Worker
<repo-name>--<project-id>.sirogu.com     → production Worker

Scale model with dispatcher:

*.sirogu.com → dispatcher Worker → project/environment Worker

All generated apps are reachable through their assigned Cloudflare Worker hostname.

9.1 Secret ownership

There are three classes of secrets:

ROGUVIBE_DEPLOY_TOKEN

CLOUDFLARE_API_TOKEN
CLOUDFLARE_ACCOUNT_ID
CLOUDFLARE_ZONE_ID

API_BASE_URL
FEATURE_FLAG_EXAMPLE

BACKEND_API_KEY
DB_USERNAME
DB_PASSWORD

9.2 Recommended flow

User/AI declares non-sensitive env vars in roguvibe.yaml
  ↓
User/platform registers secret values through platform UI/API/CLI
  ↓
Platform stores secret values in secret manager
  ↓
Deployment validates that every env.secret name has a value for the target environment
  ↓
Cloudflare Deploy Adapter writes vars/secrets to Worker environment bindings
  ↓
Worker receives env.API_BASE_URL / env.BACKEND_API_KEY / env.DB_PASSWORD

Generated repos should contain secret references, not secret values.

10.1 Required skills

Create platform skills for AI agents:

/skill:init-project
/skill:change-app
/skill:deploy-development
/skill:promote-production
/skill:rollback
/skill:diagnose-deployment

10.2 Skill contracts

10.3 Agent safety rules

Agents must follow these rules:

1. Never commit directly to production.
2. Never add Cloudflare API tokens to the repo.
3. Never add backend admin/root credentials, API keys, passwords, or token values to generated app code or roguvibe.yaml.
4. Never change branch protection unless explicitly instructed.
5. Prefer PR-based changes into development.
6. Promote only from development to production.
7. Treat platform deployment registry as the source of truth for deployment status.

11.1 Runtime rollback

Rollback should not require rebuilding.

Select previous successful deployment
  ↓
Platform Deploy API calls Cloudflare rollback/version activation
  ↓
Environment route points to previous Worker version/deployment
  ↓
Platform records rollback event

11.2 Git alignment after rollback

Runtime rollback can make production runtime differ from the production branch HEAD.

Recommended policy:

1. Perform runtime rollback immediately for incident recovery.
2. AI agent opens a follow-up PR to align production branch with the rollback target if needed.

This balances fast recovery with Git auditability.

12.1 Deployment status

Platform should track:

project id
environment
git repo
git branch
git commit SHA
build run id
Cloudflare Worker name/script id
Cloudflare deployment/version id
hostname
status
created at
created by

12.2 User-facing status

Expose simple statuses:

Building
Deploying
Live
Failed
Rolled back

12.3 Logs

Initial MVP:

• Link to GitHub Actions run logs for build failures.
• Store platform deploy logs.
• Show Cloudflare deployment errors.

Later:

• Cloudflare Workers runtime logs integration.
• Per-request logs.
• Error summaries.
• Deployment health checks.

MVP Implementation Phases

This MVP is a narrow proof of concept inside the current repository. It should test whether this repo can deploy a simple static HTML site to Cloudflare Workers and expose it at this fixed hostname:

roguvibe-design--p-plan5demo.sirogu.com

The MVP should not build the RoguVibe CLI, control plane, project database, repo initializer, secret manager, deployment registry, rollback UI, or Workers for Platforms adapter. Use Cloudflare's default tooling where possible, especially Wrangler and the official Wrangler GitHub Action.

The MVP site should live under:

mvp/roguvibe-design/

The site should be an HTML version of this PLAN 5 document. The HTML version must preserve the same information as the Markdown plan, but present it as an easy-to-read static site with strong navigation and reading UX. It should also include D1-backed anchored threaded comments so the deployed Worker proves static asset delivery, API routing, and persistence in one flow.

{
  "name": "roguvibe-design-p-plan5demo",
  "main": "./src/worker.ts",
  "compatibility_date": "2025-06-01",
  "assets": {
    "directory": "./public",
    "binding": "ASSETS"
  },
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "roguvibe-design-p-plan5demo",
      "database_id": "__D1_DATABASE_ID__"
    }
  ],
  "routes": [
    {
      "pattern": "roguvibe-design--p-plan5demo.sirogu.com",
      "custom_domain": true
    }
  ]
}

name: Deploy RoguVibe Design MVP

on:
  push:
    branches:
      - main
    paths:
      - "mvp/**"
  workflow_dispatch:

permissions:
  contents: read

jobs:
  deploy:
    runs-on: tke-fe-small-runner
    timeout-minutes: 15
    env:
      MVP_DIR: mvp/roguvibe-design
      HOSTNAME: roguvibe-design--p-plan5demo.sirogu.com
      WORKER_NAME: roguvibe-design-p-plan5demo
      D1_DATABASE_NAME: roguvibe-design-p-plan5demo
    steps:
      - uses: actions/checkout@v6

      - name: Render Wrangler config
        shell: bash
        run: |
          test -f "$MVP_DIR/public/index.html"
          sed             -e "s#__WORKER_NAME__#$WORKER_NAME#g"             -e "s#__HOSTNAME__#$HOSTNAME#g"             -e "s#__D1_DATABASE_ID__#$D1_DATABASE_ID#g"             "$MVP_DIR/wrangler.template.jsonc" > "$MVP_DIR/wrangler.jsonc"

      - name: Apply D1 migrations
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: d1 migrations apply roguvibe-design-p-plan5demo --remote --config mvp/roguvibe-design/wrangler.jsonc

      - name: Deploy with Wrangler
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          command: deploy --config mvp/roguvibe-design/wrangler.jsonc

Select text in a paragraph or list item
  ↓
[Comment on selection]
  ↓
Open comment drawer
  ↓
Write root comment with commenter name
  ↓
Other readers add named replies to the same thread

Phase 0 — Hosted Workers spike

Estimated duration: 1 week.

Steps:

1. Create a minimal generated TypeScript Worker app.
2. Deploy manually to Cloudflare hosted Workers.
3. Test Workers Static Assets.
4. Test automatic custom domain/route automation using repo name + platform project ID.
5. Test Worker environment variables and secrets for generic backend configuration such as API URL/IP, API key, username, and password.
6. Test rollback/version behavior.
7. Document required Cloudflare account permissions and limits.

Success criteria:

• TypeScript app deploys to Cloudflare Workers.
• Static assets work.
• Worker runtime can connect to the configured backend using env.vars / env.secrets and scoped credentials.
• Custom development and production hostnames work.
• Rollback path is confirmed.

Phase 1 — Repo scaffold and branch model

Estimated duration: 1–2 weeks.

Steps:

1. Define template repo structure.
2. Define roguvibe.yaml v1.
3. Add AGENTS.md template.
4. Add .roguvibe/project.json template.
5. Implement local scaffold generation.
6. Implement development and production branch initialization.
7. Add validation and deploy workflows.
8. Document AI skill rules.

Success criteria:

• New local repo can be generated.
• Branches are initialized deterministically.
• Workflows exist and validate.
• AI instructions are present and machine-readable metadata is present.

Phase 2 — GitHub repo automation

Estimated duration: 1–2 weeks.

Steps:

1. Implement GitHub repo creation with shared machine user/PAT.
2. Push initialized branches.
3. Set default branch to development.
4. Create GitHub Environments.
5. Set repo variables and environment secrets.
6. Apply branch protection.
7. Create initial PR/promotion flow test.

Success criteria:

• Platform can create a ready-to-use GitHub repo.
• development and production branches exist.
• Branch protections are active.
• GitHub Actions runs on PR and push.

Phase 3 — Platform deploy API and CLI

Estimated duration: 2–3 weeks.

Steps:

1. Implement roguvibe validate.
2. Implement roguvibe deploy.
3. Implement deploy-token authentication.
4. Implement platform deployment registry.
5. Implement environment mapping.
6. Store deployment status and GitHub run metadata.
7. Return deployment URL and status to GitHub Actions.

Success criteria:

• GitHub Actions can deploy through roguvibe deploy.
• Platform registry records deployment metadata.
• Failed deployments show actionable errors.
• Generated repos do not need Cloudflare credentials.

Phase 4 — Cloudflare MVP adapter

Estimated duration: 2–4 weeks.

Steps:

1. Implement per-project/per-environment Worker naming.
2. Upload Worker module and static assets.
3. Configure Worker environment variables and secrets.
4. Configure custom domains/routes.
5. Implement automatic development and production hostname generation from repo name + project ID.
6. Implement rollback to previous successful deployment/version.

Success criteria:

• Push to development deploys development Worker.
• Merge to production deploys production Worker.
• Automatically assigned development and production hostnames work.
• Rollback works without rebuild.

Phase 5 — AI skills and promotion workflow

Estimated duration: 1–2 weeks.

Steps:

1. Implement /skill:change-app workflow.
2. Implement /skill:deploy-development workflow.
3. Implement /skill:promote-production workflow.
4. Implement /skill:rollback workflow.
5. Add status polling for GitHub Actions and platform deployment status.
6. Add safe failure recovery docs.

Success criteria:

• AI agent can make a change safely through ai/<task>.
• AI agent can deploy development.
• AI agent can promote development to production.
• AI agent can roll back production.

Phase 6 — Workers for Platforms evaluation/migration

Estimated duration: 2–4 weeks after MVP usage data.

Steps:

1. Validate Workers for Platforms account/product availability.
2. Build proof of concept dispatcher Worker.
3. Upload user Workers to dispatch namespace.
4. Map hostnames to dispatched Worker scripts.
5. Compare limits, cost, operational complexity, and rollback model.
6. Implement Cloudflare Deploy Adapter v2 behind existing platform API.
7. Migrate one pilot project without repo workflow changes.

Success criteria:

• Existing generated repo workflow remains unchanged.
• Platform can deploy through dispatch namespace.
• Dispatcher resolves hostnames to correct project/environment.
• Rollback and logs remain supported.

14.1 Shared GitHub PAT blast radius

Risk:

• A shared PAT can create/modify many repos.

Mitigation:

• Use fine-grained PAT.
• Store only in platform secret manager.
• Rotate regularly.
• Audit every GitHub API call.
• Move to GitHub App when feasible.

14.2 Cloudflare credential leakage

Risk:

• Cloudflare tokens in generated repos would compromise runtime infrastructure.

Mitigation:

• Generated repos receive only ROGUVIBE_DEPLOY_TOKEN.
• Platform owns Cloudflare credentials.
• Use scoped Cloudflare API token.
• Audit deploy adapter calls.

14.3 Branch confusion

Risk:

• Users or agents merge wrong branches.

Mitigation:

• Use environment-named branches: development, production.
• Set development as default.
• Protect production.
• Include AGENTS.md and .roguvibe/project.json.
• Encode branch rules in skills.

14.4 Git/runtime drift after rollback

Risk:

• Runtime rollback may not match production branch HEAD.

Mitigation:

• Record rollback events.
• Show active deployment SHA.
• AI opens follow-up revert/alignment PR.

14.5 Cloudflare limits and product fit

Risk:

• Per-project Worker model may hit account limits or become operationally noisy.

Mitigation:

• Keep Cloudflare Deploy Adapter boundary.
• Track Worker counts and route counts.
• Evaluate Workers for Platforms before scaling broadly.

14.6 Non-Worker-compatible generated code

Risk:

• Generated TypeScript app may use unsupported Node APIs.

Mitigation:

• Provide templates.
• Run compatibility validation in CI.
• Prefer Web APIs.
• Keep framework adapter constraints explicit.