Define no aggregate ceiling on portable tool definitions

[omry]

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.

[chatgpt-codex-connector]

You have reached your Codex usage limits for security reviews. Please try again later.

[omry]

@codex, regular review 6f0f5e8

[omry]

PR-cycle state — maintained automatically. Do not edit.

{
  "acceptance": [
    "the design states plainly that no aggregate ceiling is defined on a definition as a whole, covering package, payload, record, and closure-contribution counts and aggregate data size",
    "the reasoning is recorded: embedded tools set a floor and never a ceiling, and no client allocation budget generalizes across the hardware Reploy targets",
    "what would make an aggregate ceiling answerable is stated, and tied to repository publication and publisher authorization",
    "per-unit parsing limits are unchanged and keep their own justification",
    "PTD-07 no longer carries aggregate byte or record-count limits"
  ],
  "approval": {
    "approved_revision_fingerprint": "sha256:3988e3092e80be9f8562a7e9fa929715de14da871ff953e73ec6e92a5326877d",
    "evidence": {
      "delivery_deferral_ledger_digest": "sha256:4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
      "required_checks": [
        [
          "Linux CI checks",
          "success"
        ],
        [
          "Target smoke (darwin-amd64)",
          "success"
        ],
        [
          "Target smoke (darwin-arm64)",
          "success"
        ],
        [
          "Target smoke (linux-amd64)",
          "success"
        ],
        [
          "Target smoke (linux-arm64)",
          "success"
        ],
        [
          "Windows host smoke (windows-amd64)",
          "success"
        ],
        [
          "Windows host smoke (windows-arm64)",
          "success"
        ]
      ],
      "review_request": {
        "body_digest": "sha256:196ef10f805cb8f49353afcee46d135554a1f562500ae671f518f27651319b3a",
        "id": 5331461668
      },
      "review_result": {
        "body_digest": "sha256:50b5f1c32f45c625c94b139264197df28ea00a0113676301276edf2b2000a64b",
        "id": 5331477497
      },
      "revision_fingerprint": "sha256:3988e3092e80be9f8562a7e9fa929715de14da871ff953e73ec6e92a5326877d",
      "thread_dispositions": {
        "resolved": 1,
        "total": 1
      }
    },
    "evidence_fingerprint": "sha256:36cb9a560955cf5c47770e7d5b06a8c0bc3feadf51439507c6089fedcf35d168",
    "rounds": 2
  },
  "checks": {
    "conclusion": "success",
    "count": 7
  },
  "delivery_deferral_ledger_digest": "sha256:4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945",
  "delivery_deferrals": [],
  "exclusions": [
    "per-unit limits on file bytes, JSON depth and members, string sizes, and per-record arrays remain, since they bound one file's parse rather than declaring how large a definition may be",
    "reference-edge depth remains with them because it bounds recursion, not size",
    "PTD-13 acquisition limits are untouched: they bound a transfer against a size the artifact record already declares"
  ],
  "findings": [
    {
      "disposition": "fixed in e7fca0286a02 by revising the contract, not restoring the ceiling. Removing the aggregate limits left PTD-07 self-contradictory: acceptance still said limits apply before unbounded work and the title still said Bounded, while per-record edge and depth limits never fire on a wide catalog. bounded is now defined as three properties that hold at any catalog size, the load-bearing one being that no allocation or traversal is sized by a count a record declares rather than by observed content. Acceptance requires the linear-cost property to be proven by a synthetic wide-catalog case.",
      "id": "preserve-an-aggregate-bound-for-catalog-loading",
      "location": "docs/PORTABLE_TOOL_DEFINITION_IMPLEMENTATION_PLAN.md:389",
      "round": 1,
      "severity": "P2"
    }
  ],
  "intent": "the normative design listed non-raiseable limits on aggregate definition bytes, record count, and selected-closure contributions. No basis for those numbers exists, so the design now states that no aggregate ceiling is defined and records why.",
  "pull_request": {
    "base": {
      "ref": "pr91",
      "sha": "9c8b1def483a"
    },
    "head": {
      "ref": "pr93",
      "sha": "e7fca0286a02"
    },
    "number": 93,
    "repository": "github.com/omry/reploy"
  },
  "retires": "the open P2 on PR 86 asking that the selected-closure contribution cap be assigned to PTD-09. There is no such cap to assign once this lands.",
  "review": {
    "request": "@codex, regular review e7fca0286a021de0e0b72b3497d537c76f76b6aa",
    "result": "Codex Review - no issues on e7fca0286a"
  },
  "revision_fingerprint": "sha256:3988e3092e80be9f8562a7e9fa929715de14da871ff953e73ec6e92a5326877d",
  "rounds": [
    {
      "attempt": 1,
      "findings": 1,
      "resulting_head": "e7fca0286a02",
      "reviewed_head": "6f0f5e89918b"
    },
    {
      "attempt": 2,
      "findings": 0,
      "note": "clean",
      "resulting_head": "e7fca0286a02",
      "reviewed_head": "e7fca0286a02"
    }
  ],
  "scope_authority": {
    "docs/PORTABLE_TOOL_DEFINITION_DESIGN.md": "sha256:4c8fa535721baf22f67486a46b0b4a04eb7054713d0a892e2d6f9667bba914b6",
    "docs/PORTABLE_TOOL_DEFINITION_IMPLEMENTATION_PLAN.md": "sha256:971113afcedea93da5df3fab42433a1e5f9fea62554f02a3f630e306b9455f00"
  },
  "slice_kind": "durable authority amendment, not a PTD task",
  "version": 3
}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6f0f5e8991

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[omry]

@codex, regular review e7fca02

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Swish!

Reviewed commit: e7fca0286a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".