# Source helper flow remains unresolved

Observed on 2026-10-08 at compiler source
`4eefd6b7dcbc1269fc9bb0bf528146b01b0eb561`, Go 1.27.1, macOS arm64.

```sh
go run ./cmd/gooo body-context --value-flow --activity Classify \
  --feature-version triple_record_field_flow_v2_shared_v1 \
  examples/text-operations/source.gooo.fixture
```

The command completes and preserves the source-bound export. The value flow is
`UNRESOLVED` with `record-flow:10:14: undefined: HasSuffix`; the model context is
`DECLINED_TO_DETERMINISTIC`. Model predictions and candidate tests are both zero
because this command only exports input, not candidate execution.

The filename body can be compiled and executed in the earlier text-operation
observations. Here the symbolic flow parser builds a local function with record
declarations, but does not carry the source helper definitions into its graph.
Its expression visitor also lacks source-call expansion. Merely adding helper
names to the parser's type environment would not preserve the helper's value
relationships.

The next flow work should retain the called activity's stable identity, actual
argument-to-parameter relationships, returned value and source spans. Shared
node, binding and call-depth bounds must apply across function boundaries.
Renaming locals should preserve relationships. Unsupported paths must retain
an explicit unresolved result. The current 16-category origin feature counts
also merge distinct operators, so resolving helper flow alone will not repair
the existing feature projection.

`context.json` is the unmodified output. This observation does not train a model
or measure native correctness. The `original_source_sha256` and contract digest
are inside the export. `SHA256SUMS` excludes itself.