Check if this issue is valid — if so, understand the root cause and fix it. At trigger-spec-pipelines.ps1, line 9:

<comment>Failed `gh workflow run` calls are silently ignored, yet the script unconditionally reports success with "All pipelines triggered." Consider checking `$LASTEXITCODE` after each `gh` call and tracking/reporting failures.</comment>

<file context>
@@ -0,0 +1,17 @@
+foreach ($spec in $specDirs) {
+    if (Test-Path "$spec\spec.md") {
+        Write-Host "Triggering speckit-pipeline for $spec..."
+        gh workflow run speckit-pipeline.yml -f feature_dir="$spec"
+        # Small delay to prevent API rate limiting
+        Start-Sleep -Seconds 2
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At trigger-spec-pipelines.ps1, line 4:

<comment>Filter `"0*"` doesn't match the comment's stated intent ("directories that start with a number"). It silently excludes any future directory starting with a non-zero digit (e.g. `100-*`). With 47 features already, this ceiling is foreseeable.</comment>

<file context>
@@ -0,0 +1,17 @@
+$ErrorActionPreference = "Continue"
+
+# Find all directories that start with a number (e.g., 001-ocr-parser)
+$specDirs = Get-ChildItem -Directory -Filter "0*" | Select-Object -ExpandProperty Name
+
+foreach ($spec in $specDirs) {
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At trigger-spec-pipelines.ps1, line 9:

<comment>Hardcoded `--ref chore/pipeline-automation` looks like a development/testing leftover. After this PR merges and the branch is deleted, all workflow dispatches from this script will fail. Remove the `--ref` flag so the workflow runs against the repository's default branch.</comment>

<file context>
@@ -6,9 +6,9 @@ $specDirs = Get-ChildItem -Directory -Filter "0*" | Select-Object -ExpandPropert
     if (Test-Path "$spec\spec.md") {
         Write-Host "Triggering speckit-pipeline for $spec..."
-        gh workflow run speckit-pipeline.yml -f feature_dir="$spec"
+        gh workflow run speckit-pipeline.yml --ref chore/pipeline-automation -f feature_dir="$spec"
         # Small delay to prevent API rate limiting
-        Start-Sleep -Seconds 2
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/speckit-pipeline.yml, line 16:

<comment>For `push`-triggered runs, `inputs.feature_dir` is always empty, so `github.run_id` is used — making every concurrency group unique and removing queuing protection. Two near-simultaneous pushes changing specs can now race on the PR-creation step. Consider falling back to a stable value like `github.sha` or keeping the original `github.ref` for push events:
```yaml
group: speckit-pipeline-${{ github.ref }}-${{ inputs.feature_dir || 'push' }}

</details>

```suggestion
  group: speckit-pipeline-${{ github.ref }}-${{ inputs.feature_dir || 'push' }}

Check if this issue is valid — if so, understand the root cause and fix it. At GEMINI.md, line 1:

<comment>A UTF-8 BOM character (`\uFEFF`) was introduced at the start of the file. UTF-8 files don't need a BOM, and it can cause the first heading to be silently misinterpreted by markdown parsers and CI lint checks.</comment>

<file context>
@@ -1,13 +1,15 @@
-# specs Development Guidelines
+# specs Development Guidelines
 
 Auto-generated from feature specifications. Last updated: 2026-03-01
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At 044-mcts-foundation/research.md, line 1:

<comment>A UTF-8 BOM (U+FEFF) was introduced at the start of the file. This invisible character precedes the `#` heading and can cause markdown parsers and linting tools (e.g., markdownlint MD041) to fail to recognize the first-line heading.</comment>

<file context>
@@ -1,4 +1,4 @@
-# Phase 0: Research & Architecture Decisions (FEAT-044)
+# Phase 0: Research & Architecture Decisions (FEAT-044)
 
 ## 1. MCTS Arena Allocator in Python
</file context>