# Sprint 6a Interview Transcript

## Q1: Signal Source Matching Strategy

**Question**: The research found `GdSignalConnection` has `signal_source` (e.g. 'self.order_accepted' or 'Events.order_accepted') and `target` (handler callable). How should we parse signal_source to extract the signal name for matching?

**Answer**: Strip prefix, match signal name only. e.g. 'Events.order_accepted' → match on 'order_accepted'. Catches connections regardless of source object.

## Q2: TSCN Connection Support

**Question**: Should trace_flow also follow .tscn editor-wired connections, or only code-based .connect() calls?

**Answer**: Code connections only for now. Simpler first implementation. .tscn connections can be added later.

## Q3: Failure Point Detection Sophistication

**Question**: How sophisticated should failure point detection be?

**Answer**: Simple regex heuristics. Detect 'if not/null/empty: return' patterns. Good enough for v1, easy to extend later.

## Q4: Trigger Matching Strategy

**Question**: Should we support fuzzy/substring matching, or require exact function/signal names?

**Answer**: Exact match only. trigger='accept_order' only matches func named exactly 'accept_order'. Clear, predictable.

## Q5: File Layout Convention

**Question**: Should trace_flow follow the existing pattern (helper in `flow/__init__.py`, registration in `server.py`), or use separate `trace_flow.py`?

**Answer**: Follow existing pattern: `flow/__init__.py` + `server.py`. Consistent with how dependency_graph, signal_map etc. are structured.

## Q6: Multiple Entry Points

**Question**: When trace_flow finds multiple entry points for a trigger, should it trace from all matches or disambiguate?

**Answer**: Trace from all matches. Return all flows. Let the AI/user see all paths. Simpler implementation.

## Q7: Output Detail Level

**Question**: Should the output include raw source lines or just metadata?

**Answer**: Metadata only. file, function, line, action, emits, calls. Keeps output compact.
