Skip to content

Seven inputs, and the ceiling is probably ten - #70

Merged
StepenkoAnatoli merged 1 commit into
mainfrom
docs/input-budget
Sep 22, 2026
Merged

StepenkoAnatoli merged 1 commit into
mainfrom
docs/input-budget

Conversation

@StepenkoAnatoli

Copy link
Copy Markdown
Owner

The first real use of the prior mechanism, on a question my own change raised.

prior became the seventh workflow_dispatch input on collect.yml, so I collected on whether there is a cap — via the remote collector, run 35757458056, with a prior registered ahead of it.

What came back

  • The cap is 10, and exceeding it fails at dispatch with you may only define up to 10 `inputs` for a `workflow_dispatch` event. Loud, not silent — which is the half that matters.
  • The witness is weak and the comment says so. A GitHub community discussion quoting that runtime error, which itself calls the figure a soft limit while asking for 25. The official workflow-syntax page says nothing about it — its own "10"s are about concurrency and background steps.
  • The second half came back unanswered. Nothing found says whether a single input value has a length limit. It matters because prior is free text and silent truncation would corrupt a prediction while leaving it looking intact. Recorded as unknown rather than assumed away.

The prior, and how it did

Registered before collecting, chained at seq 1 on the runner:

"I expect the cap to be 10 inputs per workflow_dispatch, which would leave 3 free now that prior is the 7th on collect.yml. I do not know whether there is also a per-input length limit… and I do not know what happens at the limit: rejection at dispatch, or silent truncation, which would be far worse for a prediction."

Half held, half went unclosed. The number was right and the failure mode is the better of the two I named; the length question is still open. That is the honest shape of a 4-page quick collection, and the reason the corpus is not being landed as a decision project — it is a side-check, not a decision.

What the run also proved

The mechanism works end to end on the path that matters: dispatched as an input → registered on the runner at ledger seq 1 → survived the artifact → arrived here with pass provenance/prior-precedes-collection and a chain of 5 entries verifying. Until this run, the remote half was guarded only by a text assertion on YAML.

🤖 Generated with Claude Code

`prior` became the seventh workflow_dispatch input, so I collected on whether
there is a cap - run 35757458056, with a prior registered ahead of it.

The cap is 10 and exceeding it fails AT DISPATCH, which is the reassuring half:
a rejected dispatch is visible, a dropped input would not be. Held to the weaker
claim it deserves, because the only witness is a community discussion quoting
the runtime error, and it calls the figure a soft limit while asking for 25. The
official syntax page says nothing about it.

The other half came back unanswered and is recorded as unanswered: nothing found
says whether a single input VALUE has a length limit. That matters because prior
is free text, and silent truncation would corrupt a prediction while leaving it
looking intact.

Also the first end-to-end proof of the remote prior: dispatched as an input,
registered on the runner at seq 1, survived the artifact, and arrived here
passing prior-precedes-collection. Until this run that half was guarded only by
a text assertion on YAML.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@StepenkoAnatoli
StepenkoAnatoli merged commit 72efd95 into main Sep 22, 2026
3 checks passed
@StepenkoAnatoli
StepenkoAnatoli deleted the docs/input-budget branch September 22, 2026 17:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant