Record IDR-007: FIO-004 confinement covers the getDataFile surface

Resolves CH-009's blocking open question: the bridge confines paths
reached through getDataFile/getDataDirectory, not raw java.io calls
that bypass it, matching the architecture record's existing sandbox
scoping (threads/reflection/sockets already scoped out). FileAttack
is not ported as FIO-004 evidence; FileOutputStreamAttack is.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011GShGLuFwRpnWNY2WL5Vz5

Author: flemming-n-larsen

.clue/id-ledger.yaml

@@ -10,7 +10,7 @@ counters:
     DES: "8"
     EVT: "15"
     G: "2"
-    IDR: "6"
+    IDR: "7"
     OQ: "4"
     P: "1"
     PDR: "2"
@@ -443,6 +443,11 @@ entries:
       state: live
       prefix: IDR
       component: "6"
+    - id: IDR-007
+      kind: numeric
+      state: reserved
+      prefix: IDR
+      component: "7"
     - id: OQ-001
       kind: numeric
       state: live

changes/CH-009-m004-file-io-sandboxing/open-questions.md

@@ -1,15 +1,5 @@
-## Blocking
+## Resolved
 
 ### Does `FIO-004` cover raw `java.io` access, or only access reached through `getDataFile`/`getDataDirectory`?
 
-`CAP-004`'s criteria name the ported classic test robots `FileAttack` and `FileOutputStreamAttack` as `FIO-004`'s evidence plan. Reading them in `C:/Code/robocode/robocode.tests.robots/src/main/java/tested/robots/`:
-
-- `FileOutputStreamAttack` calls `getDataFile("test")`, then opens a plain `java.io.FileOutputStream` on the returned `File`. This is exactly the path this change's resolver covers: `getDataFile` re-roots the name, and whatever opens the resulting `File` sees an already-confined path. Porting this robot needs no scope decision.
-- `FileAttack` never calls `getDataFile` at all. It opens `new FileInputStream("C:\\MSDOS.SYS")` and `new FileOutputStream("C:\\Robocode.attack")` directly. In classic, this is blocked by the JVM `SecurityManager`'s `checkRead`/`checkWrite` — a mechanism this repository's own architecture record says is out of scope: `docs/architecture/README.md` lists "threads, reflection, and sockets" as sandbox gaps "scoped out rather than forgotten," and `AGENTS.md` records that JDK 24 removed `SecurityManager` outright, which is why classic needs its own older JDK to run at all. A resolver inside `getDataFile` cannot see or redirect a call that never goes through it.
-
-Two ways to resolve this, neither of which this change should choose on its own:
-
-1. **Narrow `FIO-004` to the `getDataFile`-reached surface.** Port `FileOutputStreamAttack` as `FIO-004`'s evidence; drop `FileAttack` or retarget it at a different criterion (or a documented, deliberately out-of-scope gap alongside threads/reflection/sockets). This keeps `CAP-004` inside the boundary the architecture record already drew.
-2. **Widen scope to intercept raw `java.io` calls from robot code.** This would need a mechanism the bridge does not have today — a security-manager successor (Java's replacement APIs), a custom `FileSystemProvider`, or bytecode instrumentation of robot jars at wrap time — and is a materially larger and separately-plannable piece of work, arguably its own capability rather than a corner of `CAP-004`.
-
-This change proceeds on option 1's assumption (resolver-surface confinement only, `FileAttack` excluded or retargeted) unless directed otherwise, because option 2 is a different-shaped change that this plan door's own scope note (`docs/architecture/README.md`'s "scoped out rather than forgotten") argues against undertaking implicitly. Flagging here rather than deciding silently, per the scope-change rule in `AGENTS.md`.
+Decided: the resolver-surface reading. See `IDR-007`. `FileOutputStreamAttack` ports as `FIO-004` evidence; `FileAttack` (raw `java.io`, no `getDataFile` call) is not ported under `FIO-004`.

changes/CH-009-m004-file-io-sandboxing/proposal.md

@@ -2,17 +2,17 @@
 id: CH-009
 type: change
 status: proposed
-links: [P-001, M-004, CAP-004, C-005, FIO-001, FIO-002, FIO-003, FIO-004, IDR-002]
+links: [P-001, M-004, CAP-004, C-005, FIO-001, FIO-002, FIO-003, FIO-004, IDR-002, IDR-007]
 title: Confine robot file I/O to the robot's data directory
 ---
 
 # CH-009 — Confine robot file I/O to the robot's data directory
 
 ## What
 
-Give `RobotData.getDataFile`/`getDataDirectory` — the one resolution point `robocode.RobocodeFileOutputStream` and `robocode.RobocodeFileWriter` already route through — the confinement classic Robocode has and the bridge does not: an absolute or traversing path a robot names is re-rooted inside the robot's data directory rather than passed through, and the directory's total size is capped at the documented 200000-byte quota. Move `FIO-001`, `FIO-002`, `FIO-003` out of `@draft` with integration evidence, and give `C-005` machine enforcement in place of the agent-judgment note it currently carries.
+Give `RobotData.getDataFile`/`getDataDirectory` — the one resolution point `robocode.RobocodeFileOutputStream` and `robocode.RobocodeFileWriter` already route through — the confinement classic Robocode has and the bridge does not: an absolute or traversing path a robot names is re-rooted inside the robot's data directory rather than passed through, and the directory's total size is capped at the documented 200000-byte quota. Move `FIO-001`, `FIO-002`, `FIO-003`, `FIO-004` out of `@draft` with integration evidence, and give `C-005` machine enforcement in place of the agent-judgment note it currently carries.
 
-`FIO-004`'s scope is a blocking open question (see `open-questions.md`) and is not committed to by this proposal until it is answered.
+`FIO-004`'s scope was a blocking open question, resolved as `IDR-007`: confinement covers the `getDataFile`/`getDataDirectory` surface, not raw `java.io` calls that bypass it entirely (classic blocks those with a JVM `SecurityManager` this bridge does not have and the architecture record already scopes out, alongside threads/reflection/sockets).
 
 ## Why
 

changes/CH-009-m004-file-io-sandboxing/tasks.md

@@ -1,10 +1,10 @@
-- [ ] Resolve the blocking open question on `FIO-004`'s scope before starting its task below.
+- [x] Resolve the blocking open question on `FIO-004`'s scope — decided as `IDR-007`: resolver-surface confinement only.
 - [ ] Implement the single resolution point in `RobotData`: re-root an absolute or drive-rooted `filename` argument inside the data directory, resolve `..` traversal inside the directory rather than escaping it, and keep `getDataDirectory`/`getDataFile` agreeing as `IDR-002` already requires — serves `FIO-001`, `FIO-002`.
 - [ ] Add the 200000-byte data-directory quota at the same resolution point (tracking bytes written across the directory's lifetime, refusing further writes with the same `IOException` classic raises) — serves `FIO-003`.
 - [ ] Port classic's `TestFileWriteSize` conformance robot/test (`C:/Code/robocode/robocode.tests.robots/.../FileWriteSize.java` and its test) for `FIO-003`'s quota-exceeded evidence, and a companion positive case that stays under quota.
-- [ ] Port `FileOutputStreamAttack` (and, depending on the open question's answer, `FileAttack` or a retargeted equivalent) as conformance evidence for `FIO-001`/`FIO-004` under `ARCH-003`'s tier.
+- [ ] Port `FileOutputStreamAttack` as conformance evidence for `FIO-001`/`FIO-004` under `ARCH-003`'s tier (`FileAttack` is not ported, per `IDR-007`).
 - [ ] Add a focused unit case for `FIO-002`: writing through `getDataFile(name)` and listing `getDataDirectory()` see the same file, for both a plain name and a re-rooted absolute/traversing one.
-- [ ] Remove `@draft` from `FIO-001`, `FIO-002`, `FIO-003` in `CAP-004/criteria.md`; leave `FIO-004` `@draft` if its scope is narrowed to a criterion this change does not fully close, or resolve it if the answer lets it close here.
+- [ ] Remove `@draft` from `FIO-001`, `FIO-002`, `FIO-003`, and `FIO-004` in `CAP-004/criteria.md`, narrowing `FIO-004`'s scenario text to the `getDataFile`-reached surface per `IDR-007`.
 - [ ] Update `CAP-004/design.md` and `CAP-004/README.md` to describe the resolver as implemented rather than intended, and update `C-005` from `enforcement: agent` to its machine-enforced state (or promote-with-residual note if `FIO-004` stays partly open).
 - [ ] Update `P-001`'s evidence-door table (`M-119`–`M-122` equivalents don't exist for `FIO-00x`; confirm the milestone-status row for `M-004` and any doors naming `FIO-001`..`FIO-004`) to reflect what closed.
 - [ ] Run the tier-1 unit suite and the focused tier-2 conformance tests with the matched local Tank Royale API/runner pair; retain any environment limitation in the handoff.

docs/decisions/IDR-007-file-io-confinement-covers-the-getdatafile-surface.md

@@ -0,0 +1,27 @@
+---
+id: IDR-007
+type: decision
+status: inferred
+author: agent
+accepted-by: []
+links: [CAP-004, C-005]
+title: File I/O confinement covers the getDataFile/getDataDirectory surface, not raw java.io calls
+---
+
+# IDR-007 — File I/O confinement covers the `getDataFile`/`getDataDirectory` surface, not raw `java.io` calls
+
+## Decision
+
+`FIO-004` is satisfied by confining paths reached through `getDataFile`/`getDataDirectory` — the surface `RobotData` resolves and `RobocodeFileOutputStream`/`RobocodeFileWriter` route through. A robot that bypasses that surface entirely, opening `java.io.FileInputStream`/`FileOutputStream` on an arbitrary path with no call to `getDataFile`, is not confined by this capability.
+
+## Context
+
+Classic's own conformance robots test both cases. `FileOutputStreamAttack` calls `getDataFile("test")` before opening a stream, so it is confined by construction once `RobotData`'s resolver re-roots the name. `FileAttack` opens `C:\MSDOS.SYS` and `C:\Robocode.attack` directly, with no `getDataFile` call anywhere in the path; classic blocks it with the JVM `SecurityManager`'s `checkRead`/`checkWrite`, a mechanism JDK 24 removed outright and this bridge does not reproduce.
+
+## Why this way
+
+`docs/architecture/README.md` already draws this line: "the rest of classic's sandbox... threads, reflection, and sockets are real gaps that are scoped out rather than forgotten." Raw-`java.io` interception is the same shape of gap — it needs a security-manager successor, a custom `FileSystemProvider`, or bytecode instrumentation of robot jars, none of which exist in this bridge today, and building one is a separately-scoped capability rather than a corner of `CAP-004`'s resolver work. Confining the surface the bridge actually controls, and naming the rest as a known boundary, keeps the claim `CAP-004` makes checkable instead of quietly wider than what was built.
+
+## Consequences
+
+`FileOutputStreamAttack` ports as `FIO-004` evidence; `FileAttack` is not ported under `FIO-004` (it may be recorded elsewhere as a documented out-of-scope gap alongside threads/reflection/sockets, but that is not this decision's obligation to do). A future capability proposing raw-`java.io` confinement would need its own criteria and cannot piggyback on `FIO-004`'s current wording without first revising it.

docs/decisions/README.md

@@ -30,4 +30,5 @@ A decision that changes a methodology contract inventories every live carrier th
 - [IDR-004 — EVT-007's cross-engine death-order claim is retired; survivor delivery is measured directly](IDR-004-evt-007-scoped-to-observable-survivor-delivery.md) · `inferred` — Retire `EVT-007` and mint `EVT-014`: a surviving robot receives another robot's death event on each engine.
 - [IDR-005 — EVT-001's priority-order claim is retired; the filter boundary is measured directly](IDR-005-evt-001-scoped-to-classic-filter-behavior.md) · `inferred` — `EVT-001` retires and `EVT-015` measures the observable filter behavior.
 - [IDR-006 — Report legacy handler exceptions at the bridge callback boundary](IDR-006-report-legacy-handler-exceptions-at-the-bridge-boundary.md) · `inferred` — `BotPeer` invokes every legacy robot event callback inside a bridge-owned boundary.
+- [IDR-007 — File I/O confinement covers the getDataFile/getDataDirectory surface, not raw java.io calls](IDR-007-file-io-confinement-covers-the-getdatafile-surface.md) · `inferred` — `FIO-004` is satisfied by confining paths reached through `getDataFile`/`getDataDirectory` — the surface `RobotData` resolves and `RobocodeFileOutputStream`/`RobocodeFileWriter` route through.
 <!-- clue:index:end -->