Website Generator Module

Status: draft / active reference
Module: Project Blueprints
Source: ../intake/2026-06-07-w2-website-generator-module.txt
Related: ../standards/website-generator-stack.md, ../standards/web-publishing-automation.md, ../standards/web-hosting-provider-strategy.md

Purpose

This blueprint defines the RSYSTEM module for generating professional client-facing web artifacts:

• surveys,
• instructions,
• landing pages,
• beta pages,
• quick publication pages,
• small client panels.

The goal is not to generate random pages from scratch every time. The goal is to combine:

• structured AI content generation,
• reusable visual templates,
• conditional layout logic,
• automated publishing.

Core Idea

Use a templated, automated and conditional system.

brief / client need
  -> structured JSON
  -> template selection
  -> generated page or app
  -> automated deploy
  -> URL and status saved back to RSYSTEM

This keeps quality high while still allowing each output to feel different.

Three Layers

1. Content Generation Layer

Claude Code, another coding agent, n8n or a future RSYSTEM agent generates structured content:

• page title,
• audience,
• problem,
• offer,
• sections,
• checklist items,
• questions,
• instructions,
• CTA,
• tone,
• constraints,
• required assets.

The output should be structured data, not a single text blob.

2. UI Template Layer

RSYSTEM should maintain several reusable templates:

• landing,
• survey,
• step-by-step instruction,
• beta page,
• dashboard / client panel.

Templates should render structured data and expose controlled variation:

• layout variant,
• color system,
• section order,
• CTA style,
• form style,
• visual density,
• language,
• level of formality.

3. Publishing And Automation Layer

n8n coordinates the publishing workflow:

• receive the brief or payload,
• select the template,
• trigger code/content generation,
• commit or update the target repo,
• deploy to the selected provider,
• save URL, status, timestamp and logs,
• notify Rafał or the client.

Recommended Output Types

Output Type	Default Stack	Template Family	Notes
Landing page	Astro + Cloudflare	landing	Fast, SEO/content-oriented, good for branch pages
Survey / form	Astro + Cloudflare or Next.js + Vercel	survey	Use n8n webhook for submissions
Client instruction	Astro or Next.js	instruction	Static for simple guides, interactive for flows
Beta page	Next.js + Vercel	beta	Good for preview URL and client testing
Client panel	Next.js + Vercel	dashboard	Use for login, state, tables and workflows

Structured Payload

Every generation should start from a predictable payload.

Minimal fields:

{
  "project_type": "landing | survey | instruction | beta | dashboard",
  "industry": "string",
  "audience": "string",
  "language": "pl | en",
  "tone": "formal | practical | premium | technical | friendly",
  "goal": "string",
  "sections": [],
  "cta": {
    "label": "string",
    "target": "string"
  },
  "constraints": [],
  "template_preferences": {
    "layout_variant": "string",
    "visual_density": "compact | balanced | editorial",
    "interaction_level": "static | form | interactive"
  }
}

Extended fields can include:

• brand,
• offer,
• objections,
• proof points,
• required form fields,
• automation webhook target,
• deployment target,
• preview mode,
• owner,
• expiry date.

Template Selection Rules

Use conditional routing:

• If it is mostly content, choose Astro + Cloudflare.
• If it needs login, data views or app logic, choose Next.js + Vercel.
• If it is a simple survey, choose Astro or static form with n8n webhook.
• If it is part of a larger app, choose Next.js.
• If it needs a backend service or longer runtime, consider Render.
• If it only needs automation and status flow, keep n8n as the orchestration layer.

UX Quality Rules

Generated pages must not feel like disposable AI output.

Each generated artifact should have:

• clear hierarchy,
• specific audience language,
• one dominant action,
• readable mobile layout,
• professional spacing,
• controlled visual variation,
• no generic filler copy,
• no unexplained automation internals exposed to clients.

Variation Rules

Variation should come from structured choices, not chaos.

Allowed variation:

• layout family,
• section order,
• color palette,
• visual density,
• card/list/table emphasis,
• CTA placement,
• form length,
• tone and vocabulary,
• industry-specific examples.

Do not vary:

• security basics,
• accessibility basics,
• source tracking,
• status reporting,
• deployment metadata,
• data ownership rules.

n8n Flow

Recommended flow:

Intake trigger
  -> validate payload
  -> classify output type
  -> choose template family
  -> generate structured content
  -> generate or update page files
  -> commit to Git
  -> deploy to Vercel / Cloudflare / Render
  -> store URL and deployment status
  -> notify owner

Planner Role

RSYSTEM Planner should store:

• template inventory,
• generation rules,
• accepted payload schemas,
• examples of good generated outputs,
• links to generated pages,
• decisions about stack and hosting,
• lessons learned from client usage.

Open Questions

• Should generated pages live in one mono-repo or separate repos per branch/client?
• Should RSYSTEM use a shared component library for generated websites?
• Should each generated artifact have an expiry/review date?
• Should generated surveys save directly to n8n, database, Google Sheets or Notion?
• Should the first implementation be Astro-first or Next.js-first?

Next Actions

• Compare this blueprint with the remaining n8n implementation file.
• Define first 5 template families.
• Create a site.config / generation payload convention.
• Create first demo flow: brief -> generated survey -> deployed preview URL.