FileTools

The filesystem tools over a FileBackend (design §4.32): ls, read_file, write_file, edit_file, delete, glob and grep, as AgentTools.

val files = StateFileBackend()
Agent.builder("coder", client).withTools(ToolSet.of(FileTools(files)*).fold(e => throw ..., identity))

The backend does the work and owns its obligations - locks, replay, bounds and tenant (§4.25); the tools translate arguments into backend calls and results into bounded text:

• '''Paths''' are absolute (/src/a.scala): ., .. and empty segments are refused, never normalised.
• '''Resources''' (C2): Read of the path for ls and read_file; Write for write_file and edit_file; Delete for delete; and for glob and grep the envelope of every path they may read (<path>/<pattern>, <path>/&#42;&#42;), which a permission rule decides as a whole.
• '''Locks''': each mutation holds backend.locks(path), so two mutations of one file in one model message apply in order, the second against the first's result. Reads take no lock, so a read in the same message as a write is not ordered with it: over thread state it sees the file as it was before the message (the batch's snapshot); over an external backend (a store, a workspace) it may see either version.
• '''Bounds''': read_file returns at most readLimit lines, each cut at maxLineChars; ls, glob and grep at most maxResults entries, and say when they stopped; every result is at most maxResultChars.

Do not register these beside llm4s-agent-tools' host file tools: read_file and write_file are both suites' names, and a ToolSet refuses a duplicate.