docs(steering): resource log: job input/output through provisioned volumes (PR-6, N6-N11)

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

.kiro/steering/resource-questions.md

@@ -76,6 +76,29 @@ silently.
   - **Later:** scheduler-driven staging (shortfall as provisioning demand), automatic LRU eviction, dataset quotas, and writable datasets.
 - **Open:** whether v1 job placement should *require* a copy (a hard constraint) or only prefer one; and what the dataset registry is (config, REST object, or both).
 
+### PR-6: job input/output through provisioned volumes (status: discussing)
+- **User (2026-10-11):** use volume provisioning for job input and output.
+- **Context:**
+  - bug-1936 rejects `-i/-o/-e`, `out_dir` and `transfer_files` at submit, because no field carries them to the job and the worker never stages files.
+  - bug-1937 defers stage-in/out to a future spec.
+  - Worker file fetch is locked to its own output path (bug-1508).
+- **Proposal:** job I/O as claims (`resource-claims`):
+  - **Input claims (read-only):** from a dataset copy (PR-5), for large or shared inputs; from files uploaded at submit, which a provider puts into a per-job input volume (the new home of `transfer_files`/`-f`); or from an existing standalone claim (model weights, a previous job's output).
+  - **Output claim (read-write):** per job (template) or a named standalone claim.
+    - `-o/-e` and `out_dir` resolve inside it.
+    - Results are fetched through the API server from the provider, not the worker (this removes the bug-1508 restriction).
+    - Retention policy: keep until fetched, or N days.
+    - Optional export after the job (stage-out) to another volume, object storage or the user's home directory.
+  - **Placement in the job:** the sandbox mounts the claims at fixed points (`/xce/in`, `/xce/out`) or at profile-allowed paths. Direct-mode jobs get the paths through environment variables.
+  - **v1 provider: a directory provider on a shared filesystem.** Create is `mkdir` with an owner and a quota, publish is a bind mount or path, delete is removal. CSI, cloud block and burst-buffer volumes plug into the same contract later.
+  - **Default:** jobs without I/O options keep today's behaviour.
+- **Affects:**
+  - `resource-claims` (adds job I/O as its first use, ahead of checkpoints);
+  - `job-sandbox-execution` (mount points);
+  - the apiserver submit/fetch path (lifts the bug-1936 rejections once claims exist);
+  - `application-profile` (default I/O claims, allowed paths);
+  - PR-5 (inputs from datasets).
+
 ## CSI notes (2026-10-11, for C3 and R4)
 Source: the CSI specification, from general knowledge; to be checked against the current spec version during design.
 
@@ -151,8 +174,15 @@ Source: the CSI specification, from general knowledge; to be checked against the
 | N2b | Can one proxy serve several kinds (cloud and storage), or one kind each? | open | Leaning: any mix; the lease is per provider, not per kind. |
 | N3 | Dataset model (PR-3): identity and versions, read-only vs updatable, capacity accounting at each location, eviction policy, who triggers staging (scheduler demand, user, admin)? | discussing | User 2026-10-11: start with a simplified model. Proposal **PR-5** below. |
 | N4 | User RBAC in the apiserver vs component authorization in the controller (which daemon roles may call which opcodes): confirm both layers exist and where each check lives. | leaning | User 2026-10-11: XCE delegates access control to the API server, and the controller trusts it. Implication: the trust is only sound if the controller knows a request really comes from the apiserver (or another legitimate component). Today `validate_host()` accepts every peer (`src/controller/join.c:13-16`), so anything that reaches the controller port bypasses RBAC. Component authentication with a per-role opcode allowlist (`peer-authentication-hardening`, P3) is what makes the delegation safe, especially once proxies can spend money. |
+| N6 | PR-6: with I/O claims, should `-o/-e/-i` and `out_dir` be accepted again even when no output claim is configured (e.g. a default per-job output directory claim), or stay rejected? | open | |
+| N7 | PR-6: where do uploaded inputs live between submit and job start (provider volume, apiserver staging area), and is there a size limit? | open | Large inputs should be datasets (PR-5). |
+| N8 | PR-6: retention and quota defaults for output claims; who is charged (pool counter per project)? | open | |
+| N9 | PR-6: multi-host jobs: a read-write-many output (shared filesystem), or per-host outputs collected after the job? | open | |
+| N10 | PR-6: job arrays: one output claim with a subdirectory per element, or one claim per element? | open | Leaning: one claim, subdirectories (cheap). |
+| N11 | PR-6: requeue and restart: reuse the same output claim or create a new one? How does it relate to checkpoint claims? | open | |
 | C3 | CSI compatibility: nice-to-have or a must? If a must, which side: the controller plugin through the proxy, the node plugin on the worker, or both? | discussing | Background and recommendation in "CSI notes" below (2026-10-11). |
 
 ## History
+- 2026-10-11: user asked whether volume provisioning can carry job input and output → PR-6; questions N6–N11 added.
 - 2026-10-11: user input on N1 (hosts join directly; asked how to unify → PR-4), N2 (multiple proxies → leaning), N3 (a simplified model first → PR-5), N4 (access control delegated to the API server, the controller trusts it → leaning, with the component-authentication implication), C3 (asked for more on CSI → CSI notes). N2a and N2b added.
 - 2026-10-11: created from the resource-model discussion. User input recorded for PR-1, PR-2 and PR-3 (proposals) and for R3, R4, R5, R6 and R8. Questions N1–N4 and C3 added.