Summary
The public Pi edit tool schema appears to flatten two mutually exclusive edits[] item modes into one object whose fields are all optional. This allows a model or host serializer to emit both find/replace and line-range fields in the same item, after which the runtime rejects the request with:
edit: edits[0] mixes find/replace and line-range fields
Reproduction
Observed with @cortexkit/aft-pi@0.50.0 (gitHead: 2fc4e9d0f51de762a2dc46c6669b6506d54041f6). The following tool arguments were emitted:
{
"edits": [
{
"content": "Research required: **no**. ...",
"startLine": 14,
"endLine": 14,
"oldString": "",
"newString": "",
"replaceAll": false,
"occurrence": 1
}
]
}
The intended operation is a line-range edit. The oldString, newString, replaceAll, and occurrence fields are empty/default values, but they are still present. A minimal mixed request such as this also reproduces the error:
{
"edits": [
{
"oldString": "old",
"startLine": 1
}
]
}
Expected behavior
The generated schema should make the two item modes mutually exclusive so that a model/host cannot validly emit both field families:
- find/replace:
oldString, newString, replaceAll, occurrence
- line-range:
startLine, endLine, content
Alternatively, the adapter could remove only known serializer-generated empty/default sentinels when the other mode is complete, while preserving rejection of meaningful mixed edits.
Evidence
The error is correct for a genuinely mixed item, but the current schema does not structurally express that such an item is invalid. A nested oneOf with closed variants, plus a schema-emission regression test, may be the smallest durable fix. Root-level unions may have host compatibility constraints, so only the nested item shape may need to change.
Environment
@cortexkit/aft-pi@0.50.0
- Provider/model:
api2api / gpt-5.6-sol
- Host: Pi
No repository files were changed while isolating this report.
Summary
The public Pi
edittool schema appears to flatten two mutually exclusiveedits[]item modes into one object whose fields are all optional. This allows a model or host serializer to emit both find/replace and line-range fields in the same item, after which the runtime rejects the request with:edit: edits[0] mixes find/replace and line-range fieldsReproduction
Observed with
@cortexkit/aft-pi@0.50.0(gitHead: 2fc4e9d0f51de762a2dc46c6669b6506d54041f6). The following tool arguments were emitted:{ "edits": [ { "content": "Research required: **no**. ...", "startLine": 14, "endLine": 14, "oldString": "", "newString": "", "replaceAll": false, "occurrence": 1 } ] }The intended operation is a line-range edit. The
oldString,newString,replaceAll, andoccurrencefields are empty/default values, but they are still present. A minimal mixed request such as this also reproduces the error:{ "edits": [ { "oldString": "old", "startLine": 1 } ] }Expected behavior
The generated schema should make the two item modes mutually exclusive so that a model/host cannot validly emit both field families:
oldString,newString,replaceAll,occurrencestartLine,endLine,contentAlternatively, the adapter could remove only known serializer-generated empty/default sentinels when the other mode is complete, while preserving rejection of meaningful mixed edits.
Evidence
packages/pi-plugin/src/tools/hoisted.tspackages/aft-bridge/src/path-aliases.tscrates/aft/src/subc_translate.rsThe error is correct for a genuinely mixed item, but the current schema does not structurally express that such an item is invalid. A nested
oneOfwith closed variants, plus a schema-emission regression test, may be the smallest durable fix. Root-level unions may have host compatibility constraints, so only the nested item shape may need to change.Environment
@cortexkit/aft-pi@0.50.0api2api / gpt-5.6-solNo repository files were changed while isolating this report.