docs: add repository intake forms #52
No reviewers
claude-bot-andresmgsl
glm-bot-andresmgsl
kimi-bot-andresmgsl
andres
Labels
No labels
attention
blocked
blocker:ci-red
blocker:conflict
blocker:drill-pending
blocker:unrequested
bug
claimed
documentation
enhancement
epic
merge-next
needs-ruling
needs-triage
offsite
post-merge
ready
release
scope:ci
scope:cli
scope:docs
scope:manifests
scope:packaging
stale
state:addressing
state:bots-reviewing
state:building
state:needs-human
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: heavy-duty/stoke#52
Loading…
Reference in a new issue
No description provided.
Delete branch "build/50-issue-templates"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Refs #50
Acceptance criteria
.github/ISSUE_TEMPLATE/contains exactlyconfig.yml,proposal.yml, andwork-order.yml.proposal.ymlis byte-identical to ceremony 0.6.3.work-order.ymldiffers from ceremony 0.6.3 only bygh→stokein the body-file guidance.config.ymldisables blank issues and links to heavy-duty/stoke proposal intake without a ceremony URL.CONTRIBUTING.mdlinks the proposal form.npm testandnpm run check:governancepass; governance reports 4 identities and 5 scopes.ci / testis green on this head.scope:packaging,scope:ci, andscope:docsfrom the base map (run 834).Worklog
changelog.d/50.md.Round log
Round at
fd22c160Round passed with no written reply.
docs: add repository intake formsto WIP: docs: add repository intake forms📣 round answered at head
fd22c16069WIP: docs: add repository intake formsto docs: add repository intake forms🔧 addressing round on head
fd22c16069Round analysis:
changelog.d/50.mdremains required, andscope:packagingis correctly derived alongsidescope:ciandscope:docs; I will make no code, branch, label, or head change.labels-scoperesult, then record that metadata reconciliation in the Worklog.No reviewer verdicts exist on this head, so there are no additional blocking or non-blocking review points to resolve.
Round answered whole at head
fd22c1606925e2c9da9542c09fb230de6c35f44a.scope:packaging,scope:ci, andscope:docs, matching run 834’slabels-scoperesult.changelog.d/50.md, all three derived scope labels, and the implementation unchanged; no commit or push was made, so the head did not move.ci / testandlabels / labels) reportSUCCESS.There were no reviewer verdicts or additional review points on this head.
📣 round answered at head
fd22c16069🔎 reviewing head
fd22c16069Reviewed in a detached worktree at this head (
npm cifirst). Acceptance criteria as they settled:.github/ISSUE_TEMPLATE/holds exactlyconfig.yml,proposal.yml,work-order.yml.proposal.ymlbyte-identical to Forgejo ceremony0.6.3— sha256502e6ec7…d4c90bon both sides.work-order.ymldiffers in exactly one hunk / one line:gh→stoke issue create --body-file.stoke issue create --body-fileexists (src/cli.js:763,README.md:515).config.ymlone hunk, URL re-pointed at stoke;blank_issues_enabled: false;grep -c heavy-duty/ceremony→ 0.CONTRIBUTING.mdlinks the proposal form.npm test133/133;check:governance→4 identities resolved; 5 scope rows valid..github/**fromlabeler.ymlmakescheck:governanceexit 1, naming all three new files. Restored.ci / testandlabels / labelsgreen on this head (runs 833/834).aa9fa005…), and re-deriving withpath.matchesGlobyieldsscope:packaging,scope:ci,scope:docs.issue_templatescriterion — correctly unticked;Refs #50, no closing keyword anywhere in the PR body.Verdict next.
🔎 reviewing head
fd22c16069.github/ISSUE_TEMPLATE/contains exactly the three required files.proposal.ymlis byte-identical to ceremony0.6.3.work-order.ymldiffers from ceremony0.6.3only by thegh→stokephrase.config.ymlhasblank_issues_enabled: false, noheavy-duty/ceremonyURL, and points to heavy-duty/stoke.CONTRIBUTING.mdlinks the proposal form.npm test(133 passing) andnpm run check:governance(4 identities, 5 scopes) locally..github/**glob makescheck:governancefail with the three new files listed as unmapped.ci / testandlabels / labelsreport success; PR carries the three derived scope labels.🔎 reviewing head
fd22c16069Approve — head
fd22c1606925e2c9da9542c09fb230de6c35f44a, reviewed whole in a detached worktree (withnpm ci, which a fresh stoke worktree needs or 55 tests fail on a missingcommander).Every pre-merge criterion on #50 holds, and I checked each by running it rather than reading it.
Against #50's acceptance criteria
.github/ISSUE_TEMPLATE/holdsconfig.yml,proposal.yml,work-order.ymland nothing else.proposal.ymlbyte-identical to ceremony0.6.3. sha256502e6ec7b71156904e81ed3444c1c4411e7386004fae27e7d2a636a5a2d4c90bon both the shipped file and the file fetched fromrepos/heavy-duty/ceremony/raw/.github/ISSUE_TEMPLATE/proposal.yml?ref=0.6.3— the Forgejo tag, which is the line that matters here; the same-numbered tag on github.com is a different tree, and comparing against it would have been a false claim.work-order.ymldiffers in exactly one hunk.diff -uagainst the fetched0.6.3original shows one changed line and nothing else:`gh issue create --body-file`→`stoke issue create --body-file`. That command is real at this head —--option('--body-file <path>')on theissue createcommand atsrc/cli.js:763, documented atREADME.md:515— so the adaptation replaces a wrong instruction with a correct one rather than a plausible one.config.yml. Also exactly one hunk against0.6.3: the contact-link URL re-pointed from ceremony toheavy-duty/stoke.blank_issues_enabled: falseretained;grep -c 'heavy-duty/ceremony' .github/ISSUE_TEMPLATE/config.yml→0. Thename:/about:prose is untouched, as decision 4 required.CONTRIBUTING.mdL54. The sentence that made this a repaired promise rather than an adopted doctrine now links the form; the link is intact on one line and renders.npm test→ 133 pass / 0 fail.npm run check:governance→governance: 4 identities resolved; 5 scope rows valid— five rows, so no scope row was added, as decision 7 required.ci / testgreen on this head.successfrom run 833 (ci.yml,pull_request, headfd22c160), alongsidelabels / labelssuccessfrom run 834.Refs #50, and I scanned the whole body for a closing keyword preceding#50in any position, including prose and code spans — there is none. The three other mentions areRefs #50, "owned by triage on issue #50", and "Claim issue #50". This is the shape #151 exists to enforce, and it is right.Beyond the criteria
.github/**from thescope:cirow in.github/labeler.ymland re-rancheck:governance: exit 1,tracked paths have no scope mapping: .github/ISSUE_TEMPLATE/config.yml, .github/ISSUE_TEMPLATE/proposal.yml, .github/ISSUE_TEMPLATE/work-order.yml, .github/labeler.yml, .github/labels.conf. All three new files are named, so the coverage is that row's and not incidental. I restored the file and re-ran; clean tree, governance green again.yaml.safe_loadsucceeds on all three:Proposal (anyone)with 4 body entries,Work order (triage only)with 7, and neither carries alabels:key — matching ceremony, which is what byte-identity buys.TRIAGE.mdandLABELS.mdare named in prose, never linked, so vendoring them at.ceremony/breaks no link. The ceremony issue numbers (#24 D2,#18) appear only inside YAML comments, which never render, so they cannot resolve to stoke's own issues.changelog.d/50.mdmatches the existing fragment shape (- <sentence> (#50).) and is present, as a contributor-facing change owes.chore: trigger synchronize verificationcommit is noise in the history, but the criterion demanding asynchronizerun's derivation is what required it. Not a nit worth carrying.What I could not verify, and what I relied on instead
labels-scope:log line, read directly. This Forgejo exposes no run-log endpoint —actions/runs/834,.../logs, andactions/jobs/834/logsall return 404 through the sanctioned wrapper. What I have isactions/tasks: run 834 islabels.yml,pull_request_target, headfd22c160,success. So instead of reading the line I re-derived the answer independently, with the samepath.matchesGlobscripts/check-governance.js:115-118uses, over the PR's five changed paths against the labeler map:scope:packaging, scope:ci, scope:docs— exactly the PR's labels. The criterion's own reason for demanding a log read (defect 8 on #36: a label event re-derives from the head map) does not bite here, because this PR does not touch.github/labeler.yml— basebef059d7and head both carry sha256aa9fa005cbdad5fc6fe4f1d52eefe52ca84dc7c3b2569f79617fc92fe05f4eca, so base-derived and head-derived sets are necessarily identical. Runs 843-846 (label events at 16:03-16:04Z) therefore cannot have produced a different set either.?template=proposal.ymlURLs resolve to a form. They cannot be measured before the merge: #50 itself records thatissues/new?template=…returns 303 to login on this instance for ceremony (which has the form) and stoke (which does not) alike. I checked what is checkable — owner, repo, and template filename each match the file actually shipped — and left the rest to the post-merge endpoint check.GET /repos/heavy-duty/stoke/issue_templatescriterion, and theblank_issues_enabled: falseAPI-door probe. Both are post-merge by construction (the endpoint reads the default branch) and #50 assigns them to triage. Not gating this verdict, and I did not attempt either.Verdict: approve — head
fd22c1606925e2c9da9542c09fb230de6c35f44a, reviewed whole against issue #50's acceptance criteria, the repo's load-bearing constraints, and the code.Every pre-merge criterion verified by running it, not by reading the checkboxes:
.github/ISSUE_TEMPLATE/holds exactlyconfig.yml,proposal.yml,work-order.ymland nothing else (ls).proposal.ymlis byte-identical to ceremony0.6.3: md5bdf2f444b9dc1374526b29791749b572on both sides, the reference fetched fresh from the raw endpoint atref=0.6.3.work-order.ymldiffers from ceremony0.6.3in exactly one line —gh issue create --body-file→stoke issue create --body-file(one hunk, nothing else).config.yml:blank_issues_enabled: false; the single contact-link URL re-pointed toheavy-duty/stoke/issues/new?template=proposal.yml;name:/about:copied as-is;grep -c 'heavy-duty/ceremony'→0.CONTRIBUTING.md's work-issue sentence now links that exact proposal-form URL.npm test: 133/133 pass.npm run check:governance: exit 0, printinggovernance: 4 identities resolved; 5 scope rows valid. Both run by me in a detached throwaway worktree at this head..github/**entry fromlabeler.ymlmakescheck:governanceexit 1 naming all three new template files; map restored and re-run green afterwards.ci / testgreen on this head (combined commit status forfd22c160: success).#Nanywhere in the PR body;Refs #50keeps the post-merge template-endpoint criterion with triage, as the issue directs.What I could not verify directly, and what I relied on instead: the raw
labels-scope:log line from synchronize run 834. The actions job-log endpoints (tasks/{id}/logs,runs/{id}/jobs,jobs/{id}/logs) all return 404 through the sanctioned forge wrapper, so I could not re-read the line itself. Relied on: (1) triage's recorded measurement in #50 (run 834,pull_request_target, headfd22c160, loggedscope:packaging,scope:ci,scope:docs); (2) thelabels / labelsjob reports success pinned to this exact head in the commit status; (3) independent recomputation from the unmodified base map over this PR's five changed paths —.github/**→scope:ci,*.md→scope:docs,changelog.d/**→scope:packaging— yielding exactly that trio; and (4) all three scope labels present on the PR. The criterion's arithmetic is reproduced; only the raw log line is quoted second-hand.The empty head commit
chore: trigger synchronize verificationis the issue-directed mechanism for producing the synchronize run the scope criterion reads — intentional, consistent with the worklog, and it changes no file.The post-merge API-intake probe (issue creation under
blank_issues_enabled: false) is owed before triage closes #50, not before merge — not a PR gate.Approved.
Reviewed against issue #50 acceptance criteria and the repo's load-bearing constraints:
.github/ISSUE_TEMPLATE/contains exactlyconfig.yml,proposal.yml, andwork-order.yml.proposal.ymlis byte-identical to ceremony0.6.3.work-order.ymldiffers from ceremony0.6.3only by the singlegh→stokephrase in the body-file guidance.config.ymlsetsblank_issues_enabled: false, contains noheavy-duty/ceremonyURL, and links toheavy-duty/stoke/issues/new?template=proposal.yml.CONTRIBUTING.mdlinks the proposal form on the promised sentence.changelog.d/50.mdrecords the contributor-facing change.npm testpasses (133 tests) andnpm run check:governancereportsgovernance: 4 identities resolved; 5 scope rows valid..github/**glob from.github/labeler.ymlmakescheck:governanceexit 1 and name the three new template files as unmapped.ci / testandlabels / labelsare green on this head, and the PR carries the derived scopesscope:ci,scope:docs, andscope:packaging.What I could not verify: the post-merge
issue_templatesAPI endpoint check is explicitly owned by triage on #50 and is intentionally not checked before merge; everything else I verified locally or via CI.