You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two things, both about the submission path rather than any one entry.
1. The submit form blocks at the last step
At heyclau.de/submit, preflight returns:
✅ Local checks pass.
⚠️This can be submitted, but the private gate will route it to manual maintainer review.
…and then the submit button stays disabled, labelled Fix blockers, with no blockers listed above it. So the page says it can be submitted and simultaneously refuses to submit it.
Reproduced twice on a completely fresh form fill (reloaded the page, re-entered every field), in both Chrome and Safari, so it does not look browser-specific or like stale client state. The only remaining preflight message is the advisory one quoted above.
Two smaller things found while getting that far, in case they are useful on their own:
With skillType: capability-pack, preflight returns capability-pack skills require verified_at — but the form has no input for verified_at. Selecting general clears it. (verifiedAt does exist in the content schema, so the field is real, just not exposed.)
safety_notes and privacy_notes are validated per line at 320 characters. That limit is not stated on the form, so the first attempt failed on both fields with no hint about why.
2. Direct PRs and issues are a closed loop for external accounts
CONTRIBUTING lists "Open a direct PR" as the advanced path, and says explicitly:
a PR with no linked issue is fine — neither is farming
I filed one (#5741), fixed the one concrete defect the review found — three dates were a day ahead of UTC, my mistake — and re-filed (#5742). All 19 checks passed on the second one and the review confirmed the dates were corrected. Both were closed by LoopOver for the same reason:
No linked issue detected; Maintainer requires a linked issue
But .github/ISSUE_TEMPLATE/config.yml has blank_issues_enabled: false and the only template is product-feature.yml, so CreateIssue returns a permissions error for an outside account. Looking at recently merged external PRs, all of them link issues that you opened.
So for a content entry right now: the form does not submit, a direct PR is auto-closed for lacking a linked issue, and an outside account cannot create the issue that would satisfy it.
I am not re-filing a third PR — it would close for the same structural reason, which is not a fix. Is there a route I have missed, or is the form the only intended path for content and this is simply blocked until it is fixed?
Happy to give more detail on the form behaviour if that helps — I have the exact field values and the preflight responses. For context the entry was content/skills/red-handed.mdx, one file, pnpm validate:content:strict exit 0.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Two things, both about the submission path rather than any one entry.
1. The submit form blocks at the last step
At heyclau.de/submit, preflight returns:
Local checks pass.This can be submitted, but the private gate will route it to manual maintainer review.…and then the submit button stays disabled, labelled
Fix blockers, with no blockers listed above it. So the page says it can be submitted and simultaneously refuses to submit it.Reproduced twice on a completely fresh form fill (reloaded the page, re-entered every field), in both Chrome and Safari, so it does not look browser-specific or like stale client state. The only remaining preflight message is the advisory one quoted above.
Two smaller things found while getting that far, in case they are useful on their own:
skillType: capability-pack, preflight returnscapability-pack skills require verified_at— but the form has no input forverified_at. Selectinggeneralclears it. (verifiedAtdoes exist in the content schema, so the field is real, just not exposed.)safety_notesandprivacy_notesare validated per line at 320 characters. That limit is not stated on the form, so the first attempt failed on both fields with no hint about why.2. Direct PRs and issues are a closed loop for external accounts
CONTRIBUTING lists "Open a direct PR" as the advanced path, and says explicitly:
I filed one (#5741), fixed the one concrete defect the review found — three dates were a day ahead of UTC, my mistake — and re-filed (#5742). All 19 checks passed on the second one and the review confirmed the dates were corrected. Both were closed by LoopOver for the same reason:
But
.github/ISSUE_TEMPLATE/config.ymlhasblank_issues_enabled: falseand the only template isproduct-feature.yml, soCreateIssuereturns a permissions error for an outside account. Looking at recently merged external PRs, all of them link issues that you opened.So for a content entry right now: the form does not submit, a direct PR is auto-closed for lacking a linked issue, and an outside account cannot create the issue that would satisfy it.
I am not re-filing a third PR — it would close for the same structural reason, which is not a fix. Is there a route I have missed, or is the form the only intended path for content and this is simply blocked until it is fixed?
Happy to give more detail on the form behaviour if that helps — I have the exact field values and the preflight responses. For context the entry was
content/skills/red-handed.mdx, one file,pnpm validate:content:strictexit 0.All reactions