Support regex selectors for preset commands, templates, and scripts

Start with preset manifest validation, the resolver, and command registration, composition, reconciliation, and cleanup paths described in the issue. Run the existing preset tests and inspect specify preset info; done means exact-name behavior remains intact, regex selectors validate and match concrete resources correctly, diagnostics show matches, and reconciliation covers integration and preset changes.

Description

Preset manifests currently require a separate provides.templates entry for every command, template, or script that a preset augments. This creates substantial repetition when the same cross-cutting guidance should apply to several resources.

For example, applying the same implementation guidance to speckit.plan, speckit.tasks, and speckit.implement currently requires three entries that differ only by name.

Add support for regex selectors by allowing the existing name field to use a regex: prefix.

Proposed syntax

provides:
  templates:
    - type: command
      name: 'regex:^speckit\.(plan|tasks|implement)$'
      file: commands/workflow-guidance.md
      strategy: append

    - type: template
      name: 'regex:.*-template$'
      file: templates/common-policy.md
      strategy: prepend

    - type: script
      name: 'regex:^check-.*$'
      file: scripts/check-wrapper.sh
      strategy: wrap

Existing exact-name declarations remain unchanged:

provides:
  templates:
    - type: command
      name: speckit.plan
      file: commands/plan-guidance.md
      strategy: append

Matching semantics

• A name beginning with regex: is interpreted as a regular expression.
• Matching uses full-name matching semantics rather than substring search.
• The expression operates on the logical resource name, not its path, filename, or extension.
• Regex declarations match only concrete resource names available from lower layers in the resolution stack:
  • lower-priority presets
  • installed and enabled extensions
  • Spec Kit core
• Regex declarations do not match other regex declarations.
• Matching is recalculated whenever the relevant preset, extension, or integration state changes.
• A regex that currently matches no resources produces a warning rather than failing installation.
• Invalid regular expressions fail preset validation with a clear error.

Supported strategies

Existing composition restrictions continue to apply:

Resource type	Supported strategies
Command	replace, prepend, append, wrap
Template	replace, prepend, append, wrap
Script	replace, wrap

Each matched resource behaves as though the preset contained a separate exact-name entry using the same file and strategy.

Resolution behavior

For templates and scripts, the resolver can test regex declarations while resolving a requested concrete resource name.

Commands require expansion into concrete command names before registration because commands are materialized into the active integration's command or skill directory. Expanded command names should then use the existing registration, composition, reconciliation, and cleanup paths.

Preset diagnostics should display both the selector and its concrete matches. For example:

regex:^speckit\.(plan|tasks|implement)$
  - speckit.plan
  - speckit.tasks
  - speckit.implement

Acceptance criteria

• Exact-name preset entries retain their current behavior.
• regex: selectors are supported for commands, templates, and scripts.
• Regex matching uses logical resource names and full-match semantics.
• Invalid expressions are rejected during manifest validation.
• An unmatched expression produces an actionable warning.
• Command selectors are expanded and materialized for the active integration.
• Command matches are reconciled when presets or extensions are added, removed, enabled, disabled, or reprioritized.
• Command matches are reconciled when the active integration changes.
• Template and script selectors participate in normal runtime resolution.
• Existing strategy restrictions remain enforced.
• Regex declarations cannot recursively match other regex declarations.
• specify preset info and resolution diagnostics show the concrete resources matched by each selector.
• Tests cover matching against core, extension, and lower-priority preset resources.
• Tests cover invalid, unmatched, and overlapping selectors.
• Existing preset tests and collection count are preserved.

Motivation

This enables concise cross-cutting presets for concerns such as:

• security and compliance guidance
• language or framework conventions
• organization-wide workflow policy
• shared command instructions
• common template sections
• script wrappers

The feature preserves the existing preset composition model while removing the need to enumerate every affected resource separately.

Out of scope

• Matching filesystem paths or extensions
• Structural Markdown section merging
• Capturing groups or substitutions in output filenames
• Regex selectors that create new resource names
• Regex declarations matching other regex declarations