Repository navigation
Investigation record: steps[].arguments and the finding's rootCause and why are still unbounded #63
Description
What happens
Found while implementing #57 (#62). D-4 and D-6 cap the reasoning, text, answer and raw tool-call arguments in the investigation record, but three fields still have no length limit in config/schemas/v1/agent-investigation.schema.json or in sdk/src/cloudfall/investigation.py:
spec.steps[].arguments: the parsed arguments of the operation that ran, which can hold the same long text as the rawtoolCalls[].argumentsthat D-6 capsfinding.rootCausefinding.why
All three come from the model's output, which can quote host output (the reason given for D-4 and D-6).
Question
Should these get a cap too, and if so which part should be kept? steps[].arguments is structured, so a cut may not fit there; refusing may be the better rule.
Activity
shipmill-romamo commentedon Oct 9, 2026
Triage: implement, once the rule is settled. It waits on your decision in the next comment. The gap is confirmed on #62's branch:
steps[].arguments,finding.rootCauseandfinding.whyhave nomaxLength. This change bounds stored state and a published schema, so it goes through the design gate. D-4 and D-6 don't cover these fields.shipmill-romamo commentedon Oct 9, 2026
@romamo Decision needed: how should the investigation record bound
steps[].arguments,finding.rootCauseandfinding.why?rootCauseandwhyat 8000 characters, keeping the start and marking the cut as D-6 does. Refuse to record a step whose serializedargumentsexceed 8000 characters, since structured arguments can't be cut and stay meaningful (recommended)steps[].arguments, that means storing a cut string in place of the objectrootCauseandwhyare short by the prompt's format, andsteps[].argumentsis what really ran, so it should be kept wholeReply here with a number or your own answer. shipmill takes this up on the tick after your reply.
romamo commentedon Oct 9, 2026
1 — cap
rootCauseandwhyat 8000 characters, keeping the start and marking the cut as D-6 does; refuse to record a step whose serializedargumentsexceed 8000 characters(decision by @romamo, given in chat; posted by Claude on his behalf)
shipmill-romamo commentedon Oct 9, 2026
Triage: implement, taking up @romamo's answer (option 1).
Design:
finding.rootCauseandfinding.why: keep at most 8000 characters, keeping the start and marking the cut as D-6 does (_head_text); the schema getsmaxLengthon bothspec.steps[].arguments: a call whose parsed arguments serialize to more than 8000 characters is refused before it runs, with outcomeinvalidand an error telling the model the limit. The step is recorded with empty arguments{}, as a call with non-JSON arguments already is, sosteps[]only ever holds arguments that ran whole. The trace's rawtoolCalls[].argumentskeeps its D-6 cut copy, so what the model sent stays visibleRecorded as D-8 in a docs PR before the implementer starts.
shipmill-romamo commentedon Oct 9, 2026
Triage: PRs for this issue:
docs/decisions.mdfinding.rootCauseandfinding.whykeep their first 8000 characters with a cut mark, and the schema bounds both; a call whose arguments serialize (ensure_ascii=False) to more than 8000 characters is refused before it runs and recorded as aninvalidstep with{}, while the trace keeps the marked start of the raw argumentsTrade-off: a saved record from before this change with a longer finding line no longer validates against the schema, as with D-6.
Merge pull request #64 from cloudfall-dev/docs/decision-63
shipmill-romamo commentedon Oct 9, 2026
Released in v0.6.0rc11.