From e7fca0286a021de0e0b72b3497d537c76f76b6aa Mon Sep 17 00:00:00 2001 From: Omry Yadan Date: Tue, 18 Aug 2026 23:40:18 +0800 Subject: [PATCH] Define no aggregate ceiling on portable tool definitions The design listed non-raiseable limits on aggregate definition bytes, record count, and selected-closure contributions alongside the per-unit parsing limits. No basis for those numbers exists. Measuring the definitions this campaign embeds establishes a floor and never a ceiling, because the tools a definition may describe are open-ended. A client allocation budget does not generalize either: Reploy is general purpose and runs on hardware from large servers to single-board computers. A schema limit is an interoperability promise about which client must be able to consume any legal definition, and that question only arises once definitions travel between authors and clients. Repository publication, publisher authorization, and third-party definitions are all outside this campaign, and every definition here is embedded and first-party. So the design now states plainly that no aggregate ceiling is defined, that this is deliberate rather than pending, and what would have to become true for one to be answerable. The per-unit limits are unchanged and keep their own justification: they stop a single malformed or hostile file from exhausting a parser, which needs no estimate of how large a legitimate definition might be. Reference-edge depth stays with them because it bounds recursion rather than size. PTD-07 no longer carries aggregate byte and record-count limits. This also retires the open finding on the plan PR asking that the selected-closure contribution cap be assigned to PTD-09: there is no such cap to assign. --- docs/PORTABLE_TOOL_DEFINITION_DESIGN.md | 31 +++++++++++++++---- ...BLE_TOOL_DEFINITION_IMPLEMENTATION_PLAN.md | 21 ++++++++++--- 2 files changed, 42 insertions(+), 10 deletions(-) diff --git a/docs/PORTABLE_TOOL_DEFINITION_DESIGN.md b/docs/PORTABLE_TOOL_DEFINITION_DESIGN.md index 49a5eb67..a3971b40 100644 --- a/docs/PORTABLE_TOOL_DEFINITION_DESIGN.md +++ b/docs/PORTABLE_TOOL_DEFINITION_DESIGN.md @@ -571,12 +571,31 @@ for every portable-tool record and do not substitute the public record schema for either token. Digest output is exactly `sha256:` followed by 64 lowercase hexadecimal characters. -Core schema policy also places non-raiseable limits on individual and aggregate -definition bytes, record count, reference-edge count and depth, string and -array sizes, and selected-closure contributions. Definitions cannot raise those -limits. Publication and consumption apply the same versioned limits before -allocating or traversing the complete graph, preventing an authenticated but -pathological definition from exhausting client or repository resources. +Core schema policy places non-raiseable limits on what a single unit may +contain: individual definition bytes, JSON nesting depth and member count, +string sizes, reference-edge depth, and per-record array sizes. Definitions +cannot raise those limits. Publication and consumption apply the same versioned +limits before decoding a record, so one malformed or hostile file cannot exhaust +a parser. + +No upper limit is defined on a definition as a whole. Neither the number of +packages, payloads, records, or closure contributions, nor any aggregate data +size, is bounded by a declared ceiling. This is deliberate rather than pending. +No basis for such a number exists: the tools a definition may describe are +open-ended, so measuring the tools already embedded establishes a floor and +never a ceiling; and Reploy is general purpose, running on hardware from large +servers to single-board computers, so no allocation budget generalizes across +clients. A definition is as large as the tool it describes genuinely requires, +and a selected closure is as large as the request it resolves genuinely +requires. + +An aggregate ceiling becomes answerable only alongside repository publication +and publisher authorization. Those introduce definitions authored by someone +other than the client's operator, and with them the question of which client +must be able to consume any published definition. That question, not a number +chosen in advance, is what would determine the limit. Until then every +definition is embedded and first-party, the per-unit limits above bound what any +single record or file may contain, and nothing bounds their sum. ## Acquisition Model diff --git a/docs/PORTABLE_TOOL_DEFINITION_IMPLEMENTATION_PLAN.md b/docs/PORTABLE_TOOL_DEFINITION_IMPLEMENTATION_PLAN.md index d65af8a8..3af8f1d9 100644 --- a/docs/PORTABLE_TOOL_DEFINITION_IMPLEMENTATION_PLAN.md +++ b/docs/PORTABLE_TOOL_DEFINITION_IMPLEMENTATION_PLAN.md @@ -383,10 +383,23 @@ Non-goals: filesystem catalog discovery or acquisition. ### PTD-07: Load Bounded Hierarchical Portable Tool Catalogs Scope: add injected-filesystem loading, ownership and namespace discovery, -aggregate byte/record/edge/depth limits, and duplicate/digest checks. - -Acceptance: limits apply before unbounded work; misplaced and duplicate records -fail; synthetic loader tests pass; no tool-specific case enters the loader. +reference edge and depth limits, and duplicate/digest checks. The normative +design defines no aggregate byte or record-count ceiling, so this slice adds +none, and `bounded` here does not mean a ceiling on catalog size. It means +three properties that hold however large the catalog is: each record's parse is +bounded by the per-unit limits before that record is decoded; traversal and +recursion are bounded by the edge and depth limits; and no allocation, buffer, +or traversal is ever sized by a count a record declares, only by content the +loader has already observed. Loading a catalog of `n` records therefore costs +work and retention linear in `n`, which is the operator's own embedded input, +rather than work a record can inflate. + +Acceptance: per-record limits apply before each record is decoded; no +allocation or traversal is sized by a declared count rather than observed +content; loader work and retention stay linear in the records actually present, +proven by a synthetic wide-catalog case rather than asserted; misplaced and +duplicate records fail; synthetic loader tests pass; no tool-specific case +enters the loader. Non-goals: graph semantics or request resolution.