The current adapter/capability design assumes a destination is a concrete filepath or directory. But destination spans can take multiple forms depending on the operation and domain, and there is currently no system for handling this variation.
"rename all .txt files to .md" - destination is a bare extension
"convert all images to webp" - destination is a format
"move all files to /archive" - destination is a directory path
"crop the video to 1920x1080" - destination is a dimension (in-place, no output path)
"transcode to h264" - destination is a codec
All of these produce a DESTINATION span correctly. The problem is downstream. If the subclassifier needs to type them, the slot mapper needs to route them, and the command builder needs to construct different things from each.
A bare extension like .md needs to be understood as a per file output pattern, not a static path. The command builder would need to derive output filenames per input file (file.txt -> file.md). A format like webp looks like a bare word with no structural markers, so the subclassifier needs domain aware vocabulary to type it correctly
Some destinations are not paths at all (codecs, dimensions, extensions) but the slot schema currently only models filepath as a destination type. Multi destination spans (where both a format and a path are specified, e.g. "convert to webp and save to /output") are not accounted for at all (need to also work on compound queries with more complex phrases)
What Needs Deciding
- What destination types exist beyond filepath, and should they be first class slot types or subtypes
- How the subclassifier types destination spans in a domain-aware way
- How the command builder handles per file output derivation for pattern based destinations
- Whether multi destination spans are in scope or explicitly deferred
The current adapter/capability design assumes a destination is a concrete filepath or directory. But destination spans can take multiple forms depending on the operation and domain, and there is currently no system for handling this variation.
All of these produce a
DESTINATIONspan correctly. The problem is downstream. If the subclassifier needs to type them, the slot mapper needs to route them, and the command builder needs to construct different things from each.A bare extension like
.mdneeds to be understood as a per file output pattern, not a static path. The command builder would need to derive output filenames per input file (file.txt -> file.md). A format like webp looks like a bare word with no structural markers, so the subclassifier needs domain aware vocabulary to type it correctlySome destinations are not paths at all (codecs, dimensions, extensions) but the slot schema currently only models filepath as a destination type. Multi destination spans (where both a format and a path are specified, e.g. "convert to webp and save to /output") are not accounted for at all (need to also work on compound queries with more complex phrases)
What Needs Deciding