Route studio create --from URLs through Data Liberation

[chubes4]

Summary

• Routes studio create --from <url> through the bundled Data Liberation CLI.
• Uses Data Liberation's portable HTML site directory as the handoff to the Static Site Importer materialization path landed in Add studio create --from for static sources #4725.
• Makes CI and non-interactive capture output plain and bounded, without spinner control sequences.
• Rejects a completed SSI receipt when its nested import validation rejects the materialized content.
• Checks bundled SQLite integration files before URL capture begins.

Flow

1. Studio validates bundled SQLite support before expensive URL capture.
2. Studio invokes the bundled Data Liberation CLI with the source URL, deterministic output base, and --resume.
3. Data Liberation captures the portable website directory.
4. Studio stages the portable site through Static Site Importer, which owns WordPress materialization.
5. Studio accepts only a completed SSI receipt whose nested quality validation also passes.

Completion Gate

This PR and Automattic/data-liberation-agent#119 remain draft while Static Site Importer and Blocks Engine mature. The portable-HTML handoff is integrated here for proving and iteration; it is not ready to replace the existing Data Liberation path until representative external sites can be imported mostly reliably as static, editable WordPress sites through this canonical flow.

Data Liberation owns complete portable HTML capture, Static Site Importer owns deterministic WordPress materialization, and Blocks Engine owns HTML-to-block conversion. Remaining failures should be fixed in those owning layers using generic primitives. Individual generated sites still require exact frontend parity, usable block-editor output, and zero fallback blocks before acceptance.

Validation

• Focused Studio CLI create and Data Liberation client tests: 84 passed.
• Focused Studio CLI ESLint passed.
• Studio CLI TypeScript check passed.
• git diff --check passed.

Dependency State

Automattic/data-liberation-agent#119 remains open, draft, and unmerged at 6a81d1a3, based directly on Data Liberation main at 505a04c1. This PR vendors that exact reviewed snapshot.

AI Assistance

openai/gpt-5.6-terra via OpenCode was used to implement and verify the focused CLI import reporting follow-up. Chris Huber remains responsible for the submitted changes.

[chubes4]

CI follow-up pushed in 7d7f45d8c:

• Unit lane now runs npm run test -- --tagsFilter='!e2e', keeping tagged CLI integration suites in the dedicated serialized CLI E2E lane.
• Filtered Unit verification passed: 211 files, 2747 passed, 60 skipped.
• Focused start-stop.e2e.test.ts passed: 2/2.
• The full local CLI E2E lane remains machine-sensitive under concurrent Playground/PHP load; isolated lifecycle coverage passes and the existing dedicated lane remains serialized.

AI assistance: openai/gpt-5.6-sol via OpenCode diagnosed the CI lane overlap, drafted the one-line test-selection change, and ran verification. Chris Huber remains responsible for the change.

[chubes4]

1,145-route scale validation

The latest branch head (ca6191a59) is pushed and the end-to-end Richlynn run completed successfully through this Studio CLI path.

• Source: https://www.richlynngroup.com/
• Routes: 1,145/1,145 completed
• Batches: 124/124 completed
• Final state: zero failed or pending batches
• WordPress routes: 1,148 unique page URIs, no duplicate paths
• Cache: 5,364 network requests avoided
• Recovery: resumed across compiler interruption, encoded Unicode paths, transient HTML classification, and canonical route collisions

This proves the Studio orchestration and dependent SSI batching path can handle the target scale. It does not mark the generated site as fidelity-complete: Richlynn still has 13,055 core/html blocks, 1,235 reported fallbacks, 396 retained external assets, and no exact visual/editor parity proof. The generated site remains evidence under the zero-fallback gate.

Dependency PRs:

• Support resumable large URL site imports static-site-importer#798
• Harden bounded site artifact compilation blocks-engine#776

Validation on the pushed Studio head: npx vitest run apps/cli/commands/site/tests/create.test.ts apps/cli/lib/tests/run-wp-cli-command.test.ts (66/66 passed).

AI assistance: openai/gpt-5.6-sol via OpenCode was used for scale-run diagnosis, implementation support, verification, and drafting this evidence update. Chris Huber remains responsible for the submitted changes.

[borkweb]

The /liberate command already imports static sites into Studio via the blocks-engine 🕺

You can do so via: /liberate ~/path/to/static/site

That being said, switching out liberate's tooling to a different set of direct calls would make sense if the php-transformer has caught up to the JS approach! I also like the direct CLI command that you have for it.

[chubes4]

@borkweb I have not compared the outputs side by side, but I was hoping the approaches could coexist initially. This PR intentionally avoids disrupting existing behavior.

Longer term, I think Data Liberation could own the browser-dependent stages: client-side rendering, runtime behavior, and the visual feedback loop, and use the Studio CLI to materialize the site.

The shared contract would be a clean HTML-based website artifact, regardless of the original source.

I think that refactoring can be explored separately from this PR. Redirecting /liberate is not necessary for this primitive to exist.