chore: meta-issue — define trigger conditions for opening F.2 hybrid implementation

[ardelperal]

Issue 7 — [META] chore: meta-issue — define trigger conditions for opening F.2 hybrid implementation

Context

The F.1 spike closed with: "Recommend opening separate issues for F.2 / F.3 / F.4 when work begins". This issue is the guard that prevents F.2 from being opened speculatively. F.2 should be opened ONLY when concrete trigger conditions are met, not because "the spike is there and we have time".

Trigger conditions for opening F.2

F.2 should be opened when ALL of the following hold:

1. The 12 structural-recognition gaps from the F.1 spike are addressed in regex (per Issue feat(upgrade): target fork repository ardelperal/codegraph for version checks #4). F.2 is justified only when regex has been pushed as far as it can go.
2. A second concrete pain point emerges that regex fundamentally can't solve (not "would be cleaner with AST" — must be "impossible in regex without breaking other tests"). Examples:
   • Complex nested generic types in late-binding calls
   • Multi-line RaiseEvent signatures with complex parameter types
   • VBA constructs introduced in a newer Access version that break the regex layer
   • Performance: a real-world project has .cls files >10000 lines where extraction takes >5s per file (per Issue feat(upgrade): run git pull and rebuild on source checkout upgrades #3)
3. A user-visible bug has been open for >30 days and the regex layer can't fix it without breaking other tests
4. The team has bandwidth for a multi-week refactor that requires rewriting the VBA extraction pipeline (F.3 coverage matrix alone is its own work)

When conditions 1 + (any of 2-4) are met, open the F.2 issue with:

• The specific pain point (cited from a concrete bug report, perf measurement, or regression)
• The regex-attempted-fix and why it failed
• The link back to this guard issue
• A reforked estimate based on the F.1 spike's pre-processing checklist (6 steps + AST walk + Access layer)

Acceptance criteria

• This issue stays open until F.2 is either opened (with rationale matching the trigger) or formally cancelled with a comment
• Each time a candidate F.2 pain point surfaces in another issue, comment here with "+1" or "-1"
• When 2 "+1"s accumulate from different concerns (regex-fatal bug + perf ceiling + future-version-required, etc.), F.2 is justified

Suggested approach

Keep this issue as a living document. Update it as new pain points accumulate. Don't close it until F.2 ships or the team explicitly decides "we'll never do F.2 — the regex layer is good enough".

When closing, document the rationale: either "F.2 shipped, see #N" or "F.2 cancelled because: (specific reasons)".

Files touched

None — this is a meta-issue for tracking. The close-rationale gets written in the closing comment.