docs(steering): resource decision and question log (PR-1..3 proposals, R/P/N items)

Persistent log of the resource-design discussion: the user's proposals
(generic supply map incl. provisioned supply; a resource provider proxy
between the controller and upstream providers; datasets in the map with
staging as data provisioning) with analysis, the user's 2026-10-11 input
(duration/decay must-have but future; RBAC in the apiserver, discuss later;
OCI containers via application profiles; CSI compatibility preferred;
GPU/topology scheduler-first and extensible), the open R1-R9/P1-P9 items
and new questions N1-N4, C3. resource-model.md, the provisioner research,
roadmap and CLAUDE.md point at it.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Rongsong Shen 2026-10-12 04:00:47 +00:00
parent bab73826f0
commit 5b05d51b7a
Signed by untrusted user: rshen
GPG key ID: 80533536B0EB651C
5 changed files with 99 additions and 21 deletions

View file

@ -178,6 +178,8 @@ A partitioned old owner can finish a cloud call already in flight. Mitigations:
## Open questions for the user
(Tracked since 2026-10-11 as P1–P9 in `.kiro/steering/resource-questions.md`, which is authoritative for their status. PR-2 there proposes generalizing this daemon into a resource provider proxy.)
1. Should the JSON-lines persistent-provider framing be specified now, though not implemented in v1 (decision 1)?
2. Is Go via CGO into libxce acceptable for the provisioner daemon, or is a CGO-free daemon required (re-implementing failover/rejoin)?
3. Is `peer-authentication-hardening` (per-role opcode allowlist) a hard dependency before the provisioner ships?