Skip to main content

​
Context

FORGE Phase 1 (manual mode) returned only 1 task (the epic itself) instead of the expected 7 tasks for Block 8. The prompt was 4,975 chars with generic acceptance criteria — clearly wrong.

​
The Bug

Block issue bodies contained task tables with inline numbering (8.1, 8.2, …) instead of GitHub issue references (#71, #72, …). FORGE’s “Parse Block for Tasks” node uses regex #(\d+) to extract task issue numbers. Inline 8.1 patterns don’t match — FORGE falls back to using the epic issue as the sole task. Before fix (block #30 body): 
| 8.1 | Add pgvector extension | TBD |
| 8.2 | Implement semantic search | TBD |
After fix: 
| #71 | Add pgvector extension | TBD |
| #72 | Implement semantic search | TBD |

​
The Fix

Scripted patch via GitHub API — all 15 open blocks updated in one pass using the task-to-issue mapping from gh api. The script maps TASK X.Y issue titles to their issue numbers, then regex-replaces | X.Y | with | #num | in each block body. After fix: FORGE correctly extracted 7 tasks with individual acceptance criteria and file targets. Prompt grew from 4,975 to 11,336 chars.

​
Business Takeaway

When building automation on top of human-authored content (GitHub issues), the format contract must be explicit and validated. FORGE’s regex-based extraction is fragile — a bulk-creation script that uses inline numbering instead of #refs silently breaks the entire pipeline. The lesson: validate issue body format at creation time, not at consumption time.