Automattic / Automattic/wp-codebox

Move optional workload systems out of the mandatory runtime core

Aperta
#2,434 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub
Lingua principale
TypeScript
Stelle
16
Fork
4
Merge medio
59m
PR unite (30g)
131

Descrizione

Parent: #2429

## Problem

`runtime-core` now owns substantial fuzz-suite execution and builders, adversarial campaigns, benchmark contracts/substrates, WordPress discovery plans, browser exploration contracts, and specialized quality artifacts. `runtime-playground` and the CLI contain their corresponding runners and commands.

These systems are valuable, but they are optional workloads built on Codebox. Making all of them part of the mandatory core contract and CLI expands dependencies, commands, schemas, tests, documentation, and release risk for every consumer.

The architecture already says Codebox is not an evaluation harness. Core should provide composable runtime primitives; workload packages should provide evaluation policy and orchestration.

## Desired shape

Keep generic primitives in core:

- bounded command execution;
- observations and evidence references;
- transport-fault and service-control interfaces where backend-neutral;
- snapshots/checkpoints;
- artifact integrity and provenance;
- runtime capability negotiation.

Move optional systems into independently built extension packages inside the monorepo, beginning with:

- fuzzing and WordPress fuzz-suite builders;
- adversarial campaign orchestration;
- benchmark orchestration and scoring-oriented contracts;
- specialized visual-comparison and adaptive-exploration policy above generic browser capture.

## Acceptance criteria

- The default core/runtime/CLI can execute a contained WordPress command without loading optional workload packages.
- Optional workload packages depend on public Codebox contracts and register commands/capabilities through an extension mechanism.
- Generic browser capture and runtime observations remain available without importing quality-suite policy.
- Fuzz, adversarial, benchmark, and specialized visual systems have independent builds and tests.
- Existing public workflows migrate before old core commands and exports are removed.
- `runtime-core` has a documented size/responsibility budget preventing workload policy from returning to the mandatory package.

## AI assistance

- **Model:** OpenAI gpt-5.6-sol
- **Tool:** OpenCode
- **Used for:** Classified mandatory runtime primitives versus optional workload systems and drafted the extension extraction tracker under Chris Huber's direction.

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Direzione di ricerca

Inizia mappando i sistemi opzionali attualmente gestiti da runtime-core, runtime-playground e dalla CLI, separando le primitive generiche del runtime dalla policy del workload. Esamina i contratti pubblici, i comandi, le capacità, le esportazioni e i test esistenti prima di definire i confini dei pacchetti di estensione. Il lavoro è completato quando i pacchetti opzionali vengono compilati e testati in modo indipendente, i workflow esistenti vengono migrati e i criteri di accettazione sono soddisfatti senza caricare la policy del workload nel core/runtime/CLI predefinito.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
typescript
Ambito
build-system, cli, tooling
Tipo di issue
Refactoring
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Attiva
Chiarezza
Abbastanza chiara
Idoneità per principianti
35/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.