Context
Yazelix Nova consumes the published pane-orchestrator and popup packages; it does not build either plugin in the main runtime repository. The two child repositories still carry substantially similar Rust/Nix WASI build recipes, including Fenix toolchain construction, cargo-auditable suppression, Cargo hook control, pinned CARGO and RUSTC behavior, target-libdir preflight, serialized compilation, wasm installation checks, and zellijPluginWasmPackageContract metadata.
Issue #635 proved that this duplication can drift. The immediate failure class is already mitigated by package contract metadata and release validation, so this is not a Nova v1 blocker. The remaining question is whether sharing the builder would reduce total ownership or merely replace two local recipes with a third repository and more cross-repo coupling.
Decision to make
Evaluate the smallest honest ownership model:
- Keep two contract-validated child-local recipes as accepted duplication.
- Extract a neutral reusable Nix builder consumed by both plugin repositories.
- Use another existing genuinely generic owner only if it does not make either plugin depend on an unrelated product repository.
Do not place the builder in Nova main or make one plugin repository the accidental infrastructure owner for the other.
Extraction contract
Proceed with extraction only if it produces a net simplification across the ecosystem:
- Both child repositories consume the same published builder revision.
- The shared owner contains the generic Fenix wasm32-wasip1 toolchain, cargo-auditable disabling, Cargo hook boundary, pinned CARGO and RUSTC environment, target-libdir preflight, serialized Cargo build, wasm install checks, and package-contract metadata.
- Child repositories provide only package-specific source, name, Cargo lock or hash data, output wasm name, and other irreducibly local inputs.
- Both duplicated local build recipes are deleted in the same transaction.
- Nova continues consuming published child package outputs and validating contract metadata; it gains no plugin build implementation or child build-script inspection.
Acceptance criteria
- Measure current duplicated implementation and the proposed shared shape by LOC, number of owners, flake inputs, release steps, and failure boundaries.
- Record the chosen owner and rejected alternatives.
- If sharing is simpler, migrate pane-orchestrator and popup through published child revisions and prove Linux plus Darwin package contracts without local overrides.
- If sharing adds more ownership or coupling than it removes, close this issue with accepted-duplication evidence and retain the existing contract validator.
- Do not block Nova v1 on this evaluation unless another real packaging failure invalidates the current mitigation.
Ownership
This is post-v1 child-package infrastructure coordinated from the Yazelix product backlog. Concrete source edits belong to the repository that owns the shared builder and to the two plugin child repositories. Nova main owns only integration pins and release evidence.
Context
Yazelix Nova consumes the published pane-orchestrator and popup packages; it does not build either plugin in the main runtime repository. The two child repositories still carry substantially similar Rust/Nix WASI build recipes, including Fenix toolchain construction, cargo-auditable suppression, Cargo hook control, pinned CARGO and RUSTC behavior, target-libdir preflight, serialized compilation, wasm installation checks, and zellijPluginWasmPackageContract metadata.
Issue #635 proved that this duplication can drift. The immediate failure class is already mitigated by package contract metadata and release validation, so this is not a Nova v1 blocker. The remaining question is whether sharing the builder would reduce total ownership or merely replace two local recipes with a third repository and more cross-repo coupling.
Decision to make
Evaluate the smallest honest ownership model:
Do not place the builder in Nova main or make one plugin repository the accidental infrastructure owner for the other.
Extraction contract
Proceed with extraction only if it produces a net simplification across the ecosystem:
Acceptance criteria
Ownership
This is post-v1 child-package infrastructure coordinated from the Yazelix product backlog. Concrete source edits belong to the repository that owns the shared builder and to the two plugin child repositories. Nova main owns only integration pins and release evidence.