fugu: workflow parser rejects a bare-int access index (accepts "0"/[0] but not 0)

[philluiz2323]

Bug

_normalize_access in src/trinity/fugu/workflow.py validates one access_list entry of a Conductor workflow proposal. It accepts a scalar string digit ("0" → [0]), None/"" (→ []), and lists of indices — but a bare scalar int (0) falls through every branch to return None, which rejects the entire workflow.

Reproduce (offline, no GPU)

from trinity.fugu.workflow import parse_workflow
parse_workflow('model_id=[0,1]\nsubtasks=["solve","answer"]\naccess_list=[[], 0]',   3)  # (None, False)  <- dropped
parse_workflow('model_id=[0,1]\nsubtasks=["solve","answer"]\naccess_list=[[], "0"]', 3)  # parses fine

The two proposals are semantically identical (step 1 reads step 0), but the bare-int form is rejected, so parsed_ok=False, training_reward=0.0, is_correct=0.

Impact

A bare integer index is the most natural thing a model emits for "read step N", and the parser's stated design goal is to avoid false negatives / not lose recoverable valid outputs. Rejecting it depresses parse-rate on otherwise-valid workflows.

Fix

Add a bare-int branch to _normalize_access (rejecting bool, which subclasses int) that returns [acc] when 0 <= acc < step_index, matching the accepted "0" / [0] forms.

Location

src/trinity/fugu/workflow.py, _normalize_access (~lines 192–232).