Frontend package publication boundaries

Frontend plugins publish ordinary source-bearing Python wheels/sdists, not an independently prebuilt frontend release. Core explicitly assembles separate remotes from installed inputs. See the package contract and image workflow. The old original-wheel-pair reconstruction/receipt tools are no longer supported.

Local and CI checks

Use a compatible core checkout/image, Python 3.14, Node 22, Yarn 4.9.1 and matching Chromium/system libraries. Owner source units run through core's common tooling; private runtime and genuine test dependencies remain owner-locked. From /app in a disposable prepared backend container, with the owner checkout available:

poetry run python devtools/frontend_ci.py --plugin /plugins/whitebox-plugin-NAME --output /opt/application-check

This explicitly selects one owner, runs its source suite, builds and installs its ordinary wheel, records the installed dependency bytes, then runs owner/contract App checks with explicit assembly. Demo Mode additionally runs the demo path. The gate mutates its disposable interpreter; do not use a shared installation. It neither publishes nor manufactures dependency release archives. Installed RECORD evidence proves current payload bytes, not original dependency wheel bytes. Successful source tests alone do not prove installed federation behavior.

The owner scope collects only that owner's applicable installed specs and core bootstrap/transport checks; contract adds the shared-runtime probe. Controlled specs live under federation/application/ and do not run in live/LambdaTest mode. Dependency and support-only packages supply helper files without collecting their specs in an owner gate. VideoJS's MP4 scenario additionally installs its ordinary owner-packaged media fixture; Demo Mode's specific scenarios run with demo selection. See adding an installed integration scenario for placement and the distinct source/live/controlled modes.

The output's installed.json records the selected distributions and RECORD-owned file hashes. logs/application/<scope>/generation.json records assembly inputs, the physical generation ID and remote inventories; backend/session logs and browser failure attachments sit under the same scope. Check the source-suite output, installed selection and relevant scope results together. These inventories are byte correspondence, not a signature or a promise of original archive provenance.

Plugin CI selects normal core main unless a feature MR explicitly supplies KERNEL: #<branch>. That opt-in must agree with the plugin source branch, and a missing explicitly selected core ref fails instead of falling back. Core must already provide the shared CI templates and compatible assembly contract. Publication retains ordinary Python conventions and checks out the exact RELEASE_REVISION emitted by versioning, never a moving branch tip.

Publication ordering

Git refs and package uploads across repositories are not transactional. Publish the coordinated providers before consumers pin them; validate the installed set and fresh assembled image before publishing the consumer. The source-bearing owners and old standalone frontend core are incompatible, as are prebuilt-only owners and the new assembly core. Keep coordinated feature work isolated until compatible refs/packages are available; do not treat branch labels or version strings as proof of matching bytes or green CI.

Required-but-unavailable provider refs or packages block consumer checks. Resolve that ordering explicitly rather than widening the gate to rebuild every dependency, weakening admission, or enabling a startup compiler. Selecting a core branch for a feature check does not authorize merging incompatible intermediate main.

Package publication, external CI/sandbox actions, deployments and MR/branch edits need their own approval. Local gates authorize none of those actions. Deployment uses a complete matched Python/tool/generation image, with worker restart and client reload; rollback restores that complete prior set, not merely a selector.