WooCommerce Site Generator

A factory for WooCommerce static site implementations, generated by Data Machine and validated by Homeboy in CI.

Ideas live as GitHub issues. Static storefronts arrive as pull requests: raw HTML/CSS/assets that are imported through Static Site Importer in Homeboy CI, with metrics and a Playground preview posted back as review evidence.

Concurrency is the strategy. The system is designed to produce many credible starting points fast, not one perfect store slowly.

Volume over perfection. If a hundred stores land in a day, the cost of any individual one being wrong is small, and the cost of finding a good one is just clicking a link.

---

Three agents, one substrate

                +---------------------+
                |   wc-idea-agent     |
                |  (industry-aware    |
                |   concept finder)   |
                +-----------+---------+
                            |
                            v
                  open GitHub issue
                  status:idea-ready
                            |
                            v
                +-----------+------------+
                | wc-static-site-agent   |
                | (raw static storefront |
                |   for the concept)     |
                +-----------+------------+
                            |
                            v
                    PR with static-site
                    branch: static/<slug>
                    label: target:static-site
                            |
                            v
                    Homeboy WordPress extension
                    runs Static Site Importer
                    against the PR in CI
                    (PHP-WASM + SQLite, no host,
                     no browser required)
                            |
                            v
                    PR comment with metrics
                    + Playground preview link
                    + import-report.json artifact
                            |
                            v
                +-----------+------------+
                | php-transformer-       |
                | iterator-agent         |
                | (upstream repair PRs)  |
                +-----------+------------+
                            |
                            v
                    focused upstream PR
                    + regression test
                    + callback comment

Every layer is intentionally generic on its own:

• Data Machine doesn't know about WooCommerce.
• The agents don't know about Playground.
• The flows don't know about validation.
• Homeboy WordPress extension doesn't know about Static Site Importer.
• Playground doesn't know about Homeboy.

This repo is the only place all of them meet.

---

Agents

Agents are narrow on purpose. The idea agent decides what should exist. The static site agent decides how to implement the selected issue as reviewable site output.

wc-idea-agent

Reads the recent issue corpus, picks the strongest distinct concept inside the industry the flow specifies, and files a status:idea-ready issue.

Industry / problem space lives on flow user messages, not in the agent. Adding a new industry lane is a flow file, not an agent change.

Issue title shape: 🛒 <Concept Name> — <one-liner>. Issue body sections, in order:

1. Recommended Concept
2. Who It Serves
3. What It Sells
4. Why It Could Work
5. Issue Overlap Check
6. Next Step

The idea agent does not generate static sites. It produces work items.

wc-static-site-agent

Reads one open status:idea-ready issue and authors a static HTML/CSS storefront PR for it. The PR opens with target:static-site. Validation happens in CI.

PR title shape: 🧱 <Concept Name> — static storefront. Branch: static/<slug>. Files under static-sites/<slug>/.

The static site agent does not invent concepts. It only implements existing issues.

php-transformer-iterator-agent

Consumes grouped SSI finding packets from a static-site validation run and turns actionable transformer gaps into focused upstream PRs. It routes each group to chubes4/static-site-importer, chubes4/html-to-blocks-converter, chubes4/block-format-bridge, or chubes4/wc-site-generator, uses an isolated DMC worktree for that repo, applies the smallest supported transformer fix, adds or updates regression coverage, runs targeted checks, opens the upstream PR with evidence, and comments back on the source generated-site PR.

Fallback issues are reserved for groups that cannot yet produce a safe patch because the evidence is incomplete, ownership is ambiguous, or targeted verification cannot be established.

---

Validation Lane

Static-site PRs trigger a Homeboy CI workflow that:

1. Boots WordPress Playground inside GitHub Actions.
2. Installs Static Site Importer via playground_blueprint.
3. Runs wp static-site-importer import-theme on the PR's static-sites/<slug>/index.html.
4. Reads the resulting import-report.json and emits importer metrics + the report itself as a Homeboy bench artifact.
5. Captures source/imported visual parity screenshots.
6. Posts a PR comment with the metrics, screenshot artifact, and a Playground preview link that re-imports the site live in the reviewer's browser.

This whole loop runs without a hosted WordPress site. PHP runs as WebAssembly in CI; the database is SQLite. The Playground preview link the reviewer clicks does the same import in their browser.

The Homeboy WordPress extension capability that makes this possible (playground_workloads) is generic. SSI is just one consumer; any WordPress plugin can be exercised the same way in CI.

---

How Concepts Stay Distinct

• Before opening an issue, the idea agent reads the recent issue corpus (open + recently-closed).
• Material overlap means the candidate is dropped and no issue is opened.
• Adjacent but differentiated means the differentiation is stated in the issue body so reviewers see why it isn't a duplicate.

When concurrency increases, two idea runs can briefly race. The intent is to tolerate a small collision rate and rely on volume to outweigh the few duplicates. Heavier dedup belongs in the agent layer, not the repo.

---

How Static Sites Stay Valid

Every static site must:

1. Use realistic ecommerce structure: header, nav, hero, product grids, category modules, cards, prices, CTAs, footer.
2. Use stable semantic hooks: header, nav, main, section, footer, .hero, .product-card, .price, .cta, .brand, .collection.
3. Use local assets only: no remote stylesheets, fonts, scripts, or images.
4. Import cleanly through Static Site Importer with low fallback / freeform / invalid-block counts.

Items 1-3 are prompt rules. Item 4 is enforced by the CI validation lane.

---

What This Repo Contains

wc-site-generator/
  README.md
  homeboy.json                       Homeboy config: WordPress extension + base playground_blueprint
  .github/
    workflows/
      static-site-validation.yml     SSI import in Playground for target:static-site PRs
      php-transformer-iterator.yml   Manual PR-first upstream repair iterator
      playground-stage-5.yml         Data Machine idea-agent proof in Playground CI
  bundles/
    wc-idea-agent/                   Data Machine bundle: concept generation
    php-transformer-iterator-agent/  Data Machine bundle: upstream transformer repair iteration
  static-sites/                      generated raw HTML/CSS storefronts for SSI validation
    <slug>/
      index.html
      assets/styles.css
  resources/                         reusable theme bases / shared assets
  scripts/                           optional dev helpers

The agents are portable Data Machine bundles. The idea agent bundle is tracked here. The downstream implementation lane is the static site agent.

---

How To Review A Generated Site

You don't need any of the agent infrastructure to review a generated site. From a PR:

1. Inspect the generated static site files or artifact linked from the PR body.
2. Review the Homeboy/SSI metrics and import report posted by CI.
3. If you like it, merge the PR. The source idea issue auto-closes via Closes #<issue>.
4. If it misses the concept, leave the issue open so the static site agent can retry.

That's the loop. Generate. Validate. Review. Decide. Repeat.

---

Operating The Loop

The agents run as Data Machine bundles in the selected runtime. The host needs:

1. Data Machine + Data Machine Code plugins active.
2. A GitHub credential profile in DMC scoped to this repo with Contents, Issues, and Pull requests write access.
3. An AI provider configured (today: OpenAI, model gpt-5.5).
4. The bundles imported and pointed at chubes4/wc-site-generator.

Install or refresh a bundle:

studio wp datamachine agent install bundles/wc-idea-agent

Run a flow manually:

studio wp datamachine flow run <flow-id> --drain

Each agent ships with a default manual flow. The idea agent additionally ships a set of industry-tuned flows; add more by dropping new flow JSON into bundles/wc-idea-agent/flows/ and reinstalling.

Once the loop is observed end-to-end, scheduling is enabled and concurrency is increased. There is no auto-merge step. Merging is a human decision.

---

Future Direction

The longer-term direction is documented in Extra-Chill/homeboy-extensions#422: run the whole loop — including Data Machine itself — inside Playground in CI. At that point the repo doesn't need a Studio host at all, and the agent + validation cycle lives entirely in GitHub.

The validation lane already proves the substrate works for any WordPress plugin. SSI is the first consumer; Data Machine in Playground is the natural next step.