Repository navigation
[Feature] F3.1: Explicit release-unit manifests and scoped versions #8217
Description
Activity
Lead-reviewed readiness audit at accepted Core main
8802a883d6069d689d110008c904787b3b691042confirms that the existing whole-solution inventory/proof, release-unit dependency/inventory guards and artifact-only executor admission/recovery provide reusable primitives. They do not currently select Core, Studio and Extensions independently; the release-unit example remains Slack-only. Normal production keeps imported product-wideIsPackable=false, while explicit nonpublishing proof mode already builds the consolidated package set. Neither is a selected-product release capability.The smallest future implementation slice remains a selected-product manifest/plan: exact selected and excluded artifacts, compatible already-published dependency checks, applicable product tests and scoped immutable/monotonic version/tag identities. Missing or ambiguous dependencies must fail explicitly without silently publishing another product. Product-qualified tag syntax can be proposed by the lead through a reviewed ADR; reopen an owner decision only if material semantic version or support policy is unresolved. Preserve finer connector/coupled units and both unchanged Studio npm IDs with exact same-run pairing; #8679 owns that paired artifact/consumer proof.
Selected real artifact/test/provenance proof and controlled publication/recovery are subsequent required outcomes. Preserve the original fixed 225-package 3.10 executor, inventory/version/provenance/admission and expiry gates unchanged; a separately reviewed product-selected mode needs its own immutable artifacts and authority. A green dry-run, old whole-candidate receipt or workflow input is not selected-product release acceptance. This audit did not query feeds or prove dependency/version availability, publisher protection or actual uploads.
Keep sequencing distinct: Core 3.8/3.9 replacement maintenance publisher capability is required before source archival under the settled archive-first decision; it does not wait for full 3.10 certification. The aligned first consolidated 3.10 baseline governs activation of later independent 3.10 product streams. Actual uploads and archival retain their concrete approval boundaries.
Planning evidence only: #8677 remains the sole active Task and #8679 the sole next-ready Task. No additional Task was created or activated, no repository code changed, and no publisher or source authority changed.
Readiness refinement at reviewed Core head
cfcf178671f33909d7fa04a0435e41a9964ca549confirms that independent product releases are still required work, not an existing capability.Current reusable pieces are the evaluated package inventory, bounded release-unit manifest validation, legacy release-skill manifest/archive checks and artifact-only admission/recovery patterns. Normal Studio/Extensions packability remains disabled; whole-solution proof mode does not select products. The current Packages workflow chooses feed/actions rather than a Core/Studio/Extensions package subset. The existing executor is fixed to the original immutable 225-package 3.10 candidate and expiry; it must not be relabelled or widened to authorize different artifacts. Current proof counts belong to each fresh run receipt.
The smallest coherent delivery is:
- A nonpublishing product/unit plan and prerequisite preflight: exact included/excluded IDs, source/version/tag/artifact/test scope, already-available compatible dependencies, and explicit failure instead of implicit dependency publication.
- Selected-scope artifact/test/consumer proof, preserving finer connector/coupled release units and the exact paired Studio npm distributions established by [Task] Build and prove paired Studio npm archives from Core without publishing #8679.
- A separately reviewed selected-artifact publisher/recovery path: upload only reviewed original bytes, retain selected scope through partial recovery, and obtain actual operational admission/approval separately.
The first consolidated 3.10 release remains aligned under its accepted baseline decision. Separately, the already-selected archive-first sequence requires replacement Core 3.8/3.9 maintenance publisher capability before retiring the old source publishers; it does not wait for full 3.10 certification. Reconcile release documentation with these settled decisions during implementation. No new product-owner choice is needed for this refinement.
This is source-grounded readiness only: no product-selected builds, feed availability checks, publisher provisioning or upload occurred. #8677 remains the sole active delivery Task; #8679 stays next and #8683 stays queued.
Individual-product release planning refreshed against 1d58bb1. This remains required and unimplemented; #8679 is still the sole active delivery Task.
The bounded sequence is: (1) nonpublishing selected-product plan and dependency prerequisite gate, (2) selected real artifacts and clean consumers against already available compatible dependency packages, (3) selected artifact-only publisher and recovery under #8220. Each Core/Studio/Extensions row must positively prove its own version/artifact/check set, exclusion of other products from publication, and explicit failure for missing or incompatible prerequisites. Studio retains the exact existing two-package npm relationship. Preserve the first aligned 3.10 baseline and finer release units.
A source-confirmed dependency gap must be addressed in the artifact slice: Studio Elsa.Studio.Core and Extensions Elsa.WorkflowContexts/Elsa.Studio.WorkflowContexts retain cross-product ProjectReference entries in both UseProjectReferences branches. That switch alone cannot prove released-dependency consumption. Verify evaluated dependency groups, actual final package metadata and clean consumers; do not infer compatibility from a successful source-project build or silently publish dependencies.
Lead read the complete Sol 6.1 plan and independently verified all 29 source hashes against exact Git blobs. Plan SHA-256
dadce09be1a0f7bedded1d41d6f7f0bbcb9fd0757c9873e06a1b2b3f7d24c845; source/provider evidence953adcdf639b6b213d0b41c87d40da137378f729675395f712295d8e4c466b14. This planning performed no builds, dependency-feed availability checks or publication. #8683 still owns new Core maintenance descendant admission/provenance; #8220 owns live publishing authority, recovery and cutover. No new owner policy decision is needed to prepare the first nonpublishing slice when the queue permits it; concrete operational approvals remain separate.Reviewed a concrete readiness proposal for the first nonpublishing selected-product plan; this creates no Task or second active implementation.
Use a small closed plan envelope bound to exact Core source/tree and evaluated ownership/inventory: one selected product/version, exact selected/excluded artifacts, outgoing dependency prerequisites, and a separate affected-test closure. Reuse narrow existing release-unit/version/tag checks without loosening immutable historical manifests or invoking the old multi-repository publisher. Proposed new tags use product-qualified identities (
products/{product}/{line}/{version}), with a separate namespace for registered finer units; historical bare tags remain untouched. These are reviewable implementation choices, not created/reserved tags.The first aligned baseline rule applies to 3.10. Supported 3.8/3.9 maintenance plans instead need their own reviewed available line baseline/artifacts and compatibility evidence plus #8683 admission; they must not wait for a future 3.10 release. Studio selection retains both exact existing npm IDs as one coordinated pair. Unknown/missing/incompatible dependency evidence blocks readiness and never expands publication to other products.
Minimum slice proof: three truthful product plan outputs, exact selected/excluded bijection, immutable version/tag controls, dependency/TFM joins, distinct-version fixtures without global version leakage, and normal/optimized failure contracts. Blocked plan outputs alone cannot close actual independent artifact/consumer or publisher acceptance. Live feed availability, candidate artifacts, publication and tag/ref activation are not claimed.
The lead read the proposal, corrected an npm-ID typo, scoped the baseline rule correctly, and verified all seven bound source inputs unchanged from 902 through a221. Reviewed private proposal SHA-256:
da70affdd9659da735e24f7c186e2e65eb91561a3877bfed079ea82f54bed611. Queue remains #8679 sole active, #8683 next; #8217/#8220 remain required.The next bounded implementation deliverable is now #8688, natively parented here and dependent on acceptance of #8683 on main. Board state is Todo / Not Ready / Verification Pending; #8683 remains the sole active Task. No product-release implementation or publication is claimed yet.
Source scope was resolved against actual refs and historical Studio manifests/workflows: Core 3.8/3.9 uses Core's own release-line commit/tree and separate published-version history; Studio/Extensions use matching #8683-admitted Core continuations. Both historical Studio lines contain the existing npm pair, whose generated same-run tarball/version/dependency must receive its own artifact/consumer proof. Accepted #8679 proves current/main only. A structural 3.10 product plan must remain release-ineligible until the approved first aligned baseline is satisfied.
#8688 will implement one-product plans and fresh read-only version/prerequisite checks with exact selected/excluded membership and explicit ineligibility. It cannot widen selection or auto-publish prerequisites. Actual selected artifacts/clean consumers, then selected-artifact publisher/recovery under #8220, remain subsequent required work. No permanent ref/tag/version allocation, publisher activation, upload or archival is performed.
Publisher/recovery readiness checkpoint after #8688 acceptance: #8693 remains the sole active delivery Task and is preparing actual selected-product artifact/consumer evidence. The lead verified all 11 immutable source pins in an independent audit against actual main 570aaa9.
The next publisher must consume the same sealed original selected bytes, keep Studio's npm pair atomic, and reconcile matching/missing/conflicting/unverifiable remote outcomes before uploading only verified missing items. Existing 225-package 3.10 recovery and Slack simulation are fixed contracts/patterns, not accepted general maintenance publishers.
Independent production product tag syntax remains a proposal. The earlier
products/{product}/{line}/{version}suggestion in comment6078230384 was not an approval or reservation. Tag allocation stays outside #8693; the lead will prepare a concrete reviewed policy decision before activation. This does not block artifact verification or nonpublishing publisher design.The #8220 authority snapshot must be refreshed before cutover approval, including protected environment/credential scope, all relevant publisher refs and in-flight jobs, preservation of Core 2.x delivery, contributor routing and recovery. No publisher activation, upload, permanent ref/tag, source-authority retirement or archival occurred. Audit JSON SHA-256 ee283e6321909b61d438442f1cddd0fac7c8b0f9d8415af37f32997956a5b322; this is planning evidence, not #8693 acceptance.
Explicit owner requirement — separate product releases, 2026-10-08
The owner requested the ability to release Core, Studio and Extensions individually from the consolidated repository. The release entrypoint must allow selecting one product, preserve its existing package identities, and avoid automatically publishing unchanged other products. Required dependencies must already be available at compatible versions or produce an explicit prerequisite failure; product selection must not silently publish those dependencies. Preserve the first consolidated 3.10 aligned baseline and the existing finer connector/coupled-unit release model.
Required acceptance for this capability:
This is a separate required deliverable. Do not expand active maintenance continuation #8683 into a generic release-engine rewrite or reopen completed structural #8667. Refine the implementation slice from current release tooling and accepted manifest/provenance primitives before scheduling it.
Program: #8194
Parent: #8198
Planning ID: F3.1
Outcome and scope
Define machine-readable release units, scoped monotonic versions, compatibility metadata, change records, and immutable tag conventions. Model coupled backend/Studio pairs as explicit release units while preserving independent shell releases.
Acceptance criteria
Readiness
Selected-product planner #8688 is accepted. Actual selected artifacts and controlled publisher/recovery are not yet accepted; this Feature remains open and outside the worker queue.
Task #8693 remains open and unaccepted, Todo / Not Ready / Verification Pending, with all seven acceptance criteria open. The required native proof awaits the owner's MySQL/.NET10 support decision; its exact-head controller CI remains in the lead's separate verification lane. Task #8636 is now the sole active delivery Task, In Progress / Assigned / Verification Pending. See the authoritative delivery checkpoint. Controller #8694 is pushed at29147db1019bd583fd2a3631c2b647a39d80ae42. All48 controller pins match independently reviewed parent2cd, where237 tests passed in each mode; fresh final-head focused checks passed eight per mode. Final integration has independent APPROVE + HIGH; full-PR coverage is independently APPROVE + HIGH with73 current blobs/83 prior references verified by the lead; all30 current checks are terminal (23 SUCCESS / seven expected SKIPPED), with consolidated originalartifact11685548301 independently audited and admitted by the lead (bounded receipt); native acceptance remains pending; Greptile5/5 and CodeRabbit have completed with no unresolved threads. Studio main-forward #8703 is normally merged as3cc81c652906fc0e18a2ec0c6732308440f8c720 after independent approval, two lead passes, Greptile5/5, CodeRabbit and25 terminal gates (20 SUCCESS / five expected SKIPPED). Actual parents/tree/source bytes match the independently reviewed prospective merge and preserve the separate main documentation addition. The prior six-cell native failure and MySQL/.NET10 decision remain unresolved. #8636 is active for the bounded updater correction; no product compatibility policy or acceptance gate is waived. No selected-artifact, publisher/recovery or cutover acceptance is claimed.
Pipeline follow-up — implemented, integration pending
9e989359fe50db6980593ab2089828c3a24de683broadens the release-plan workflow path filters toscripts/integration-program/**,.agents/skills/elsa-release/scripts/**anddocs/integration-program/**, together with the selected workflow/action paths. These cover the imported runtime/test helpers, maintenance containment/register/candidates and Secrets ownership inputs identified by PR8692 comment4233486842. Lead checked all 12 specifically identified input paths against the frozen patterns. Implementation is present on the hosted-control branch; current-head PR CI and ordinary integration remain pending, so this follow-up is not yet closed.Follow AGENTS.md, existing test/ conventions and dated ADRs under doc/adr/. Scope is Elsa 3 unless explicitly a portability assessment. Repository consolidation includes Core, all Extensions, and Studio; release boundaries remain explicit and independent.
Hierarchy: native parent/sub-issue relationships verified on 2026-09-23. Explicit blocking dependencies are configured separately; Markdown links remain references. See #8194.
Source/release refresh at22:24UTC confirmed all35 advertised3.8/3.9 release refs in Core main and latest stable3.9.0 across all three repositories. The nine-value Studio carryover is now on actual main through8703; one upstream grammar value is intentionally corrected and documented. No additional Extensions code arrival was found. Full selected product/TFM coverage remains required; targeted local passes do not replace the six-cell hosted proof.