Define a host storage-admission contract for write-capable Runtime commands

オープン
  • 何か問題がありますか？
#347 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
12/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go, json
領域
cli, devops

調査の方向性

The pinned evidence points to internal/audit/audit.go (append records, line limits, cooperative append lock) and internal/mcp/server.go (per-message bounds) as the starting places. The issue asks for an inventory of write-capable CLI and MCP paths plus a versioned storage-admission contract, which is design work rather than a single fix. Done would mean a documented contract and tests for concurrent writers, ENOSPC during staged writes, and recovery, and that is not a first-timer task.

索引モデルが issue の本文から書いたものです。

説明

Consumer: Desk #685, the v0.14.0 aggregate local-storage acceptance requirement.

This is a host-integration contract request based on pinned source inspection, not a disk-exhaustion reproduction or a claim of observed data loss. Per-object limits, process deadlines and bounded protocol output do not by themselves establish an aggregate filesystem budget.

Please identify an existing supported contract, or specify a versioned component contract, through which a host can reserve a finite write envelope before growth or external effects. It must cover startup/recovery, temporary and coexisting files, persistent results, concurrent/background writers and descendants. A component may instead document and prove an exact no-growth or finite-growth command contract where appropriate.

The host needs:

  • Exact original store/root identities and the complete permitted write destinations, preserving existing authority and descriptor contracts.
  • Bounds for logical bytes, allocation allowance and namespace growth, including settlement/recovery headroom. A persistent process needs per-operation admission or a proven finite lifetime allowance.
  • Refusal before admitted capacity is exceeded, with typed quota/storage uncertainty; no replay of completed effects after a persistence failure.
  • A crash/restart and cancellation contract retaining reservations until the admitted writers can no longer grow.
  • Focused concurrent-writer, staged-write/ENOSPC and recovery tests, plus a discoverable contract/version.

An externally enforced filesystem/confinement backend is another possible route; this issue does not assume such a backend already exists or change supported deployment requirements. Desk owns host admission and integration. Component owners decide the implementation and release milestone. No pin, code, milestone or release change is requested by filing this question.

Pinned evidence: Runtime v0.39.0 at 12793d2dd24d18549567ac422711a2b3c1489f04.

  • Audit writer contract appends project-owned evaluation records; its line limits and cooperative append lock do not state a host-wide storage reservation.
  • MCP server bounds individual messages. That is distinct from filesystem growth.

Please inventory the write-capable CLI/MCP paths, including selected audit/lock/signing destinations and temporary/recovery writes, and distinguish genuinely read-only commands. Preserve the original selected project and audit semantics; making required writes read-only is not acceptance. These inspected files do not constitute an exhaustive writer audit, and this report does not assert that every MCP command writes.

主要言語
Go
スター
2
フォーク
6
平均マージ
2時間 22分
マージ済み PR（30日）
89

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Judgment-Pack/judgment-pack-runtime のほかの issue

Judgment-Pack/judgment-pack-runtime の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。