feat: Multi-Package Extension Build System

[katriendg]

Issue Description

Extend the extension packaging workflow to build multiple persona-targeted .vsix packages from a single codebase. Each collection package contains only the artifacts relevant to a specific persona while the full package retains all artifacts.

Motivation

A single monolithic package forces every user to receive all 61 artifacts regardless of role. Persona-targeted packages reduce noise, improve discoverability, and provide a clearer value proposition per audience.

Deliverables

1. Collection Manifest Schema

Create scripts/linting/schemas/collection.schema.json defining:

• id - Unique collection identifier (e.g., hve-developer)
• name, displayName, description - Marketplace metadata
• personas - Array of persona IDs this collection targets
• include / exclude objects with glob patterns per artifact type (agents, prompts, instructions)

2. Collection Manifest Files

Create manifests in extension/collections/ for each persona-targeted collection. Initial set to be determined by team input (Phase 6), but the system should support:

• A full collection containing all artifacts (default) (hve-core-all)
• Per-persona collections filtered by the artifact registry
• Additional collections added without code changes (manifest-only)

3. Prepare-Extension.ps1 Enhancement

Modify scripts/extension/Prepare-Extension.ps1 to:

• Accept a -Collection parameter pointing to a collection manifest
• Read the artifact registry to resolve persona-based filtering
• Apply include/exclude glob patterns from the manifest
• Generate a package.json with collection-specific metadata (name, displayName, description)
• Fall back to current behavior (full package) when no collection is specified
• Resolve handoff dependencies dynamically from agent frontmatter:
  • Parse each collected agent's frontmatter handoffs field to discover navigation targets
  • If a handoff target matches the collection's maturity filter, include it in the package
  • Iterate until transitive closure is complete (handoff targets may themselves have handoffs)
  • This replaces storing handoff relationships in the registry's requires.agents, which caused circular dependencies (resolved in Phase 1)
• Migrate maturity source from frontmatter to registry (deferred from Phase 1b feat: Migrate Maturity Metadata to Registry and Remove from Frontmatter #438):
  • Add Get-RegistryData function to load and parse .github/ai-artifacts-registry.json
  • Update Get-DiscoveredAgents, Get-DiscoveredPrompts, Get-DiscoveredInstructions to read maturity from registry instead of frontmatter
  • Remove maturity extraction from Get-FrontmatterData (currently defaults to "stable" when absent)
  • Update Pester tests in scripts/tests/extension/Prepare-Extension.Tests.ps1 for registry-based maturity lookup

4. Package-Extension.ps1 Enhancement

Modify scripts/extension/Package-Extension.ps1 to:

• Accept a -Collection parameter
• Pass collection context through to Prepare-Extension.ps1
• Output .vsix files named by collection (e.g., hve-developer.vsix)

Acceptance Criteria

• Collection manifest schema validates all manifest files
• Prepare-Extension.ps1 -Collection developer produces a package.json with only developer-relevant artifacts
• Package-Extension.ps1 without -Collection builds the full package (backward compatible)
• Each collection package contains universal artifacts plus persona-specific artifacts
• Collection manifests reference persona IDs from the artifact registry
• Artifact dependency resolution ensures agents include their required prompts and instructions
• Handoff dependencies are resolved dynamically from agent frontmatter (not from registry requires.agents)
• Transitive handoff closure includes all reachable handoff targets matching the maturity filter
• Prepare-Extension.ps1 reads maturity from registry instead of frontmatter (deferred from feat: Migrate Maturity Metadata to Registry and Remove from Frontmatter #438)
• Pester tests validate registry-based maturity filtering for Stable vs PreRelease channels

Technical Notes

• Collection manifests use glob patterns matching artifact names (e.g., task-*, git-*)
• The registry's requires field ensures dependent artifacts are included even if not matched by persona filter
• Extension IDs follow pattern: ise-hve-essentials.hve-{persona}
• package.json template in extension/ serves as the base; collection metadata overrides specific fields

Handoff Resolution Strategy

The registry's requires.agents field captures only runtime dispatch dependencies (agents invoked via runSubagent). Handoff targets (the handoffs frontmatter field in agent files) represent UI navigation buttons that users click to transition between agents. These are excluded from the registry to avoid circular dependencies.

During packaging, handoff dependencies are resolved dynamically:

1. Collect agents matching the collection's persona and maturity filters from the registry
2. Parse each agent's frontmatter handoffs field to discover navigation targets
3. For each handoff target that matches the maturity filter, include it in the package
4. Repeat until no new agents are added (transitive closure)

This ensures agents like memory are included when packaging rpi-agent (which lists memory as a handoff) without creating circular dependency entries in the registry. The frontmatter handoffs field is the single source of truth for these relationships, avoiding redundant data.

Additional Context

• Current packaging: scripts/extension/Prepare-Extension.ps1
• Current extension manifest: extension/package.json
• Depends on: Phase 1 (Registry Design and Schema)
• Absorbs deferred work from: Phase 1b (feat: Migrate Maturity Metadata to Registry and Remove from Frontmatter #438 — maturity source migration from frontmatter to registry)
• Collection contents 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
• Maturity migration research: .copilot-tracking/research/2026-02-06-maturity-migration-research.md
• Handoff resolution decision: Phase 1 restricted requires.agents to runtime dispatch only; handoff targets resolved dynamically from frontmatter during packaging (see Phase 1 acceptance criteria)