Platform follow-ups

The user approved these eight outcomes, in order. A source change does not count as a public acceptance. Keep the existing Rust owners, authorization, languages, revision checks and private publication path. Preserve the parked compatibility experiment outside main. Reuse the existing checkout and app contracts.

Task 1: Shorter verification and clear delivery state

Measure the latest successful CI run. Partition the existing registry into independent jobs with separate PostgreSQL, Qdrant and artifacts. Every registered suite must run exactly once at the outer level, and its nested security repetitions remain intact. Preserve instrumented coverage, source provenance and failure admission. Publish before/after timings only after a real successful run.

Validation: partition rejects duplicate, missing and unknown suites; actual CI executes all partitions and combines same-source coverage without lowered floors.

Task 2: Agentic workspace inside Studio

Integrate constrained composition with current grids and detail/approval/import routes. The host owns data, authorization, status and action execution. A natural language request creates a usable view that can be pinned and reopened. Unknown components and cross-tenant bindings reject before display.

Validation: real model output, authorized API data, pin/reload, role revocation, malformed and injected composition, browser screenshots.

Task 3: Guided app creation

Complete one consultation app from a merchant description: product relation, upload, status, settings, form and admin view. Show usable private preview and specific unresolved bindings before publication. Reuse existing app generation.

Validation: create, configure, submit, manage, publish and roll back with current rights, languages and stored versions. No new privileged runtime.

Task 4: App upgrade checks

Compare installed and proposed versions against stored data, schema, consumers and saved examples. Show required migration and reject incompatible activation. Use existing migration, examples and exact-digest release approval contracts.

Validation: compatible update, required migration, failing saved example, stale approval, private validation and restore of the previous version.

Task 5: Browser customer simulations

Reuse saved profiles and scenarios against two explicit frontend versions in a real browser. Capture failed steps and screenshots with links to the editor. Keep all writes within synthetic private shops and simulated payment.

Validation: same profiles before/after, reproducible failure, stop/resume and browser evidence; do not report synthetic API checks as browser usability.

Task 6: Consistent shop and app designers

Use shared compact component choices and contextual agent interaction. Keep large preview, visible drop targets, reordering, deletion and undo. Reference design analysis must show its interpretation and proposed actual change.

Validation: browser drag/drop, keyboard alternative, undo, selected agent target, reference proposal/review, saved revision and private/live separation.

Task 7: Complete inward migration

Run the existing WooCommerce adapter against an actual disposable WooCommerce shop containing variants, media, categories, pages, customers and order history. Reconcile IDs, totals and counts, preview privately and place a simulated order.

Validation: actual source service, interrupted resume, replay, source/target comparison, storefront and checkout. Local provider fixtures are identified.

Task 8: Restore and operational chain

Restore a backup into an isolated environment, then inspect shops, app data, orders and access. Verify simulated payment, test mail, invoice, cancellation and simulated refund through existing services. Recheck Apple configuration separately.

Validation: recorded restore source, actual restored data and isolation, complete order chain. External account configuration that is missing stays explicit.

Shared interfaces

Tasks 2, 3 and 6 use the same context-aware agent and native view bindings. Tasks 3 and 4 use the current app manifest, record migration and release digest. Task 5 tests the versions produced by 4 and 6. Task 7 retains inward migration and shares the simulated order chain with 8. No second queue, permission model or ledger.