Parent: #431

Issue Description

Establish the publishing infrastructure to build and distribute multiple persona-targeted extension packages through the VS Code Marketplace and update CI/CD workflows accordingly.

Motivation

With multiple collection packages, the build and release pipeline must support building, testing, and publishing each variant. Marketplace IDs must be reserved and CI must produce the correct artifacts for each collection.

Deliverables

1. Marketplace ID Reservation

Reserve extension IDs for each collection package.
Note additional find since there is no way to reserve Marketplace IDs without creating the extensions, we will use first manual local testing to ensure one new extension works (focus on existing full hve-core and add only hve-developer for the first test, then we can create the rest of the extensions once we have the process down).

Note: A Data Science collection is under evaluation. The HVE Data Science extension already covers this audience and may supersede the need for a separate collection here.

2. CI/CD Workflow Updates

Create or update GitHub Actions workflows to:

• Build all collection packages in parallel (matrix strategy)
• Run validation against each collection's package.json
• Produce .vsix artifacts for each collection
• Support selective publishing (publish specific collections) > !!NOTE update this we always release all packages together whenever a new version is released

3. Release Process Updates

Update the release process (docs/contributing/release-process.md):

• Document multi-package release workflow
• Define versioning strategy (shared version across collections vs. independent)
• Update release-please-config.json if needed for multi-package releases
• Document Marketplace publishing steps for each collection

4. Quality Gates

Establish validation for each collection package:

• Verify each .vsix contains the expected artifacts (no missing, no extras)
• Validate package.json contribution points match included artifact files
• Ensure dependency resolution is correct (no agent without its required prompts/instructions)

Acceptance Criteria

• Marketplace IDs reserved — Superseded by collection-based architecture. Build system handles per-collection identities dynamically.
• CI builds all collection packages successfully
• Each .vsix contains only the artifacts specified by its collection manifest
• Per-persona README files — Superseded by collection READMEs (extension/README.{id}.md) generated by Prepare-Extension.ps1
• Release process documentation covers multi-package publishing
• Quality gate validates artifact completeness per collection (source-level via Validate-Collections.ps1)

Technical Notes

• Consider matrix strategy in GitHub Actions for parallel collection builds
• Version should stay synchronized across collections to avoid confusion
• Publishing can be phased: ship the full package first, then persona packages

package.json On-Disk Strategy (Phase 2 Research)

vsce package reads package.json exclusively from the current working directory. It has no --manifest, --cwd, or --packagePath input flag. The existing packaging scripts (Prepare-Extension.ps1 and Package-Extension.ps1) already dynamically rewrite extension/package.json at build time (overwriting contributes and temporarily modifying version), so this pattern extends naturally to collection builds.

Option A — Single dynamic rewrite (no per-persona files)

One extension/package.json checked in. The build script temporarily overrides name, displayName, and description per collection, generates filtered contributes, builds, then restores the original values.

• Fewer files to maintain
• finally-block restore pattern (already used for version)
• package.json always dirty locally after a build — requires restore or git checkout
• Persona metadata embedded in build script parameters, not inspectable in source

Option B — Per-persona template files on disk (preferred for inner dev loop)

Per-persona template files on disk (e.g., extension/package.developer.json, extension/package.tpm.json). Each contains the static metadata for that persona edition. The build script copies the appropriate template to extension/package.json, generates filtered contributes into it, then runs vsce package.

• Each persona's metadata (name, displayName, description, potential future icon) is git-tracked and inspectable
• Inner dev loop: cp extension/package.developer.json extension/package.json → run prepare → done. No restore step needed because the template files stay clean
• Easier PR review — metadata changes show up as diffs on specific persona files
• Version field still managed centrally (build-time injection or release-please)
• N+1 small files to maintain, but static fields rarely change

Shared constraints (both options)

• .vscodeignore broad wildcards (!.github/agents/** etc.) work unchanged — no per-persona ignore files needed
• CI matrix strategy provides runner-level parallelism (one runner per collection, fresh checkout, no file contention)
• Each collection requires a unique publisher.name combo on the Marketplace; publisher stays ise-hve-essentials for all
• Selective artifact file copying replaces the blanket .github/ tree copy
• When no -Collection is specified, the full package builds exactly as today (backward compatible)

Decision not made yet. Option B is preferred for better inner dev loop and clearer metadata management, but Option A is simpler with fewer files. Both are feasible.

Per-Persona README Files

Each persona collection requires a dedicated README file for the VS Code Marketplace listing. This involves:

• Creating extension/README.developer.md, extension/README.tpm.md, etc. with persona-specific content
• Updating packaging scripts to copy the correct README to extension/README.md before vsce package
• Ensuring the base extension/README.md remains the full hve-core README (backward compatible default)

This follows the same pattern as Option B above — per-persona template files on disk, copied into place at build time. The README swap should occur alongside the package.json template copy in the build workflow.

Additional Context

• Current release config: release-please-config.json
• Current extension packaging: scripts/extension/
• Depends on: Phase 2 (Multi-Package Build System)
• Collection definitions determined by: Phase 6 (Persona-to-Artifact Mapping)
• Related: #251 - Update extension packaging to distribute skills — collection builds must include skills alongside agents, prompts, and instructions
• Publishing extensions: https://code.visualstudio.com/api/working-with-extensions/publishing-extension