Repository navigation
Seven inputs, and the ceiling is probably ten - #70
Merged
Merged
Conversation
`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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The first real use of the prior mechanism, on a question my own change raised.
priorbecame the seventhworkflow_dispatchinput oncollect.yml, so I collected on whether there is a cap — via the remote collector, run35757458056, with a prior registered ahead of it.What came back
you may only define up to 10 `inputs` for a `workflow_dispatch` event. Loud, not silent — which is the half that matters.prioris 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:
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-collectionand 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