@willbooster/shared-lib 10.3.0 → 10.4.0

package/dist/githubTemplates.cjs

@@ -1,5 +1,5 @@
 "use strict";const e=[{heading:`Why`,requirement:`the problem, with the numbers or observations behind it, and why this approach over the alternatives`},{heading:`Requirements`,requirement:"the requirements the change must satisfy and the guarantees it must keep, one per line, each marked `required` (asked for by the requester, or an existing contract callers depend on) or `chosen` (the implementer's own decision, which a simpler design may replace); copy the requester's instructions here as given, whether they came from an issue or a conversation, and keep the list when the body is later rewritten unless the requester's instructions changed"},{heading:`Customer Summary`,requirement:`behavior, workflow, or user-visible changes, written for readers who know nothing about the implementation`},{heading:`Technical Summary`,requirement:`decisions and their reasons, data flow, where to look (the files that matter most), and what to check hardest: the parts whose correctness is argued rather than proven`},{heading:`Testing`,requirement:`commands run, tests added, and what was NOT exercised and why`},{heading:`Notes`,requirement:`known limitations, compatibility and migration, follow-up work; delete this section if there is none`}],t=[{heading:`Problem`,requirement:`what happens, and what should happen instead`},{heading:`Evidence`,requirement:`reproduction steps, logs, run IDs, or links`},{heading:`Impact`,requirement:`who or what is affected, and how badly`},{heading:`Proposal`,requirement:`the fix you have in mind, and the root cause if known`}],n=[{heading:`Background and goal`,requirement:`the problem being solved, for whom, and what outcome counts as success`},{heading:`Behavior`,requirement:`every user- or caller-observable behavior, including inputs, outputs, error cases, edge cases, and interactions with existing behavior, stated precisely enough that two implementers would build the same thing`},{heading:`Acceptance criteria`,requirement:`checkable conditions (Given/When/Then or an equivalent) that decide whether the implementation is done`},{heading:`Scope and non-goals`,requirement:`what the change covers and what it deliberately leaves out, so an implementer knows where to stop`},{heading:`Design constraints`,requirement:`the data, API, schema, UI, and configuration changes, naming, and the existing code or conventions the implementation must fit — as far as the writer intends to constrain them, with everything else explicitly left to the implementer`},{heading:`Compatibility and migration`,requirement:`what existing data, users, callers, or configurations are affected and how the transition happens`},{heading:`Verification`,requirement:`how the change is tested or demonstrated, including what needs no test and why`},{heading:`Open questions`,requirement:`undecided points, each with its options; empty once the specification is implementable`}];function r(e){return e.map(e=>`- **${e.heading}**: ${e.requirement}`).join(`
 `)}function i(e){return e.map(e=>`## ${e.heading}\n\n<!-- ${e.requirement.charAt(0).toUpperCase()}${e.requirement.slice(1)}. -->`).join(`
 
-`)}exports.BUG_ISSUE_SECTIONS=t,exports.CHANGE_ISSUE_SECTIONS=n,exports.PULL_REQUEST_SECTIONS=e,exports.renderSectionChecklist=r,exports.renderSectionTemplate=i;
+`)}exports.BUG_ISSUE_SECTIONS=t,exports.CHANGE_ISSUE_SECTIONS=n,exports.PULL_REQUEST_REQUIREMENTS_RULES="- Requirements section: one line per requirement, taken from the requester's instructions as they were given (the issue, the conversation that asked for the change), each marked `required` (asked for, or an existing contract callers depend on) or `chosen` (your own decision, which a simpler design may replace). Never infer a requirement from the diff: when no issue, PR message, or conversation states the request, write `required: not recorded — ask the requester` as the only request-derived line (a `required` line for an existing contract callers depend on may still be listed) and say so in Notes.\n- Record rule: an existing Requirements section is a record, not a description of the diff. Keep its `required` lines as they are, rewriting them only when the requester's instructions changed (then from the updated instructions, dropping a line only when the requester removed it; with no instructions available, keep them unchanged); add a `chosen` line for a new decision, and replace or remove one when the decision it records changed. A section that merely describes the implementation, or holds only the template's placeholder or a `required: not recorded` line, is not a record: write it afresh by the rule above.\n- Place the section where the template puts it; when the template has no such heading, right after the issue-closing line, or at the top of the body when there is none.\n- Never drop or weaken a `required` line to fit what was implemented: when one cannot hold in the diff, keep it and say so in Notes.",exports.PULL_REQUEST_SECTIONS=e,exports.renderSectionChecklist=r,exports.renderSectionTemplate=i;
 //# sourceMappingURL=githubTemplates.cjs.map

package/dist/githubTemplates.cjs.map

@@ -1 +1 @@
-{"version":3,"file":"githubTemplates.cjs","names":[],"sources":["../src/githubTemplates.ts"],"sourcesContent":["/**\n * A section of a PR or issue body: its heading and what the section must state. `requirement`\n * starts lowercase and ends without punctuation, so that it reads both as a placeholder sentence\n * (capitalized, with a period appended) and as a checklist clause after the heading.\n */\nexport interface TemplateSection {\n  readonly heading: string;\n  readonly requirement: string;\n}\n\n/** Sections of a pull request body, in the order they appear in the PR template. */\nexport const PULL_REQUEST_SECTIONS: readonly TemplateSection[] = [\n  {\n    heading: 'Why',\n    requirement: 'the problem, with the numbers or observations behind it, and why this approach over the alternatives',\n  },\n  {\n    heading: 'Requirements',\n    requirement:\n      \"the requirements the change must satisfy and the guarantees it must keep, one per line, each marked `required` (asked for by the requester, or an existing contract callers depend on) or `chosen` (the implementer's own decision, which a simpler design may replace); copy the requester's instructions here as given, whether they came from an issue or a conversation, and keep the list when the body is later rewritten unless the requester's instructions changed\",\n  },\n  {\n    heading: 'Customer Summary',\n    requirement:\n      'behavior, workflow, or user-visible changes, written for readers who know nothing about the implementation',\n  },\n  {\n    heading: 'Technical Summary',\n    requirement:\n      'decisions and their reasons, data flow, where to look (the files that matter most), and what to check hardest: the parts whose correctness is argued rather than proven',\n  },\n  {\n    heading: 'Testing',\n    requirement: 'commands run, tests added, and what was NOT exercised and why',\n  },\n  {\n    heading: 'Notes',\n    requirement: 'known limitations, compatibility and migration, follow-up work; delete this section if there is none',\n  },\n];\n\n/** Sections of a bug report, in the order they appear in the issue template. */\nexport const BUG_ISSUE_SECTIONS: readonly TemplateSection[] = [\n  { heading: 'Problem', requirement: 'what happens, and what should happen instead' },\n  { heading: 'Evidence', requirement: 'reproduction steps, logs, run IDs, or links' },\n  { heading: 'Impact', requirement: 'who or what is affected, and how badly' },\n  { heading: 'Proposal', requirement: 'the fix you have in mind, and the root cause if known' },\n];\n\n/**\n * Sections a change specification must settle before a third party can implement it, defined\n * once so that the issue template and any tool that drafts or reviews specifications against\n * these sections cannot drift apart; checklist consumers render it with `renderSectionChecklist`.\n * The first three sections suffice for a small change, so they come first.\n */\nexport const CHANGE_ISSUE_SECTIONS: readonly TemplateSection[] = [\n  {\n    heading: 'Background and goal',\n    requirement: 'the problem being solved, for whom, and what outcome counts as success',\n  },\n  {\n    heading: 'Behavior',\n    requirement:\n      'every user- or caller-observable behavior, including inputs, outputs, error cases, edge cases, and interactions with existing behavior, stated precisely enough that two implementers would build the same thing',\n  },\n  {\n    heading: 'Acceptance criteria',\n    requirement:\n      'checkable conditions (Given/When/Then or an equivalent) that decide whether the implementation is done',\n  },\n  {\n    heading: 'Scope and non-goals',\n    requirement: 'what the change covers and what it deliberately leaves out, so an implementer knows where to stop',\n  },\n  {\n    heading: 'Design constraints',\n    requirement:\n      'the data, API, schema, UI, and configuration changes, naming, and the existing code or conventions the implementation must fit — as far as the writer intends to constrain them, with everything else explicitly left to the implementer',\n  },\n  {\n    heading: 'Compatibility and migration',\n    requirement: 'what existing data, users, callers, or configurations are affected and how the transition happens',\n  },\n  {\n    heading: 'Verification',\n    requirement: 'how the change is tested or demonstrated, including what needs no test and why',\n  },\n  {\n    heading: 'Open questions',\n    requirement: 'undecided points, each with its options; empty once the specification is implementable',\n  },\n];\n\n/** Renders sections as markdown bullets (`- **Heading**: requirement`). */\nexport function renderSectionChecklist(sections: readonly TemplateSection[]): string {\n  return sections.map((section) => `- **${section.heading}**: ${section.requirement}`).join('\\n');\n}\n\n/** Renders sections as markdown headings, each followed by its requirement as a placeholder comment. */\nexport function renderSectionTemplate(sections: readonly TemplateSection[]): string {\n  return sections\n    .map(\n      (section) =>\n        `## ${section.heading}\\n\\n<!-- ${section.requirement.charAt(0).toUpperCase()}${section.requirement.slice(1)}. -->`\n    )\n    .join('\\n\\n');\n}\n"],"mappings":"aAWA,MAAa,EAAoD,CAC/D,CACE,QAAS,MACT,YAAa,sGACf,EACA,CACE,QAAS,eACT,YACE,6cACJ,EACA,CACE,QAAS,mBACT,YACE,4GACJ,EACA,CACE,QAAS,oBACT,YACE,yKACJ,EACA,CACE,QAAS,UACT,YAAa,+DACf,EACA,CACE,QAAS,QACT,YAAa,sGACf,CACF,EAGa,EAAiD,CAC5D,CAAE,QAAS,UAAW,YAAa,8CAA+C,EAClF,CAAE,QAAS,WAAY,YAAa,6CAA8C,EAClF,CAAE,QAAS,SAAU,YAAa,wCAAyC,EAC3E,CAAE,QAAS,WAAY,YAAa,uDAAwD,CAC9F,EAQa,EAAoD,CAC/D,CACE,QAAS,sBACT,YAAa,wEACf,EACA,CACE,QAAS,WACT,YACE,kNACJ,EACA,CACE,QAAS,sBACT,YACE,wGACJ,EACA,CACE,QAAS,sBACT,YAAa,mGACf,EACA,CACE,QAAS,qBACT,YACE,0OACJ,EACA,CACE,QAAS,8BACT,YAAa,mGACf,EACA,CACE,QAAS,eACT,YAAa,gFACf,EACA,CACE,QAAS,iBACT,YAAa,wFACf,CACF,EAGA,SAAgB,EAAuB,EAA8C,CACnF,OAAO,EAAS,IAAK,GAAY,OAAO,EAAQ,QAAQ,MAAM,EAAQ,aAAa,CAAC,CAAC,KAAK;CAAI,CAChG,CAGA,SAAgB,EAAsB,EAA8C,CAClF,OAAO,EACJ,IACE,GACC,MAAM,EAAQ,QAAQ,WAAW,EAAQ,YAAY,OAAO,CAAC,CAAC,CAAC,YAAY,IAAI,EAAQ,YAAY,MAAM,CAAC,EAAE,MAChH,CAAC,CACA,KAAK;;CAAM,CAChB"}
+{"version":3,"file":"githubTemplates.cjs","names":[],"sources":["../src/githubTemplates.ts"],"sourcesContent":["/**\n * A section of a PR or issue body: its heading and what the section must state. `requirement`\n * starts lowercase and ends without punctuation, so that it reads both as a placeholder sentence\n * (capitalized, with a period appended) and as a checklist clause after the heading.\n */\nexport interface TemplateSection {\n  readonly heading: string;\n  readonly requirement: string;\n}\n\n/** Sections of a pull request body, in the order they appear in the PR template. */\nexport const PULL_REQUEST_SECTIONS: readonly TemplateSection[] = [\n  {\n    heading: 'Why',\n    requirement: 'the problem, with the numbers or observations behind it, and why this approach over the alternatives',\n  },\n  {\n    heading: 'Requirements',\n    requirement:\n      \"the requirements the change must satisfy and the guarantees it must keep, one per line, each marked `required` (asked for by the requester, or an existing contract callers depend on) or `chosen` (the implementer's own decision, which a simpler design may replace); copy the requester's instructions here as given, whether they came from an issue or a conversation, and keep the list when the body is later rewritten unless the requester's instructions changed\",\n  },\n  {\n    heading: 'Customer Summary',\n    requirement:\n      'behavior, workflow, or user-visible changes, written for readers who know nothing about the implementation',\n  },\n  {\n    heading: 'Technical Summary',\n    requirement:\n      'decisions and their reasons, data flow, where to look (the files that matter most), and what to check hardest: the parts whose correctness is argued rather than proven',\n  },\n  {\n    heading: 'Testing',\n    requirement: 'commands run, tests added, and what was NOT exercised and why',\n  },\n  {\n    heading: 'Notes',\n    requirement: 'known limitations, compatibility and migration, follow-up work; delete this section if there is none',\n  },\n];\n\n/**\n * How a tool that writes or rewrites a PR body fills the Requirements section of\n * `PULL_REQUEST_SECTIONS`, as markdown bullets for an agent's instructions. Skills that draft PR\n * bodies render this text instead of restating it, so the writers and the reviewers that read the\n * section as the boundary a fix must keep never disagree on what a line means.\n */\nexport const PULL_REQUEST_REQUIREMENTS_RULES = `- Requirements section: one line per requirement, taken from the requester's instructions as they were given (the issue, the conversation that asked for the change), each marked \\`required\\` (asked for, or an existing contract callers depend on) or \\`chosen\\` (your own decision, which a simpler design may replace). Never infer a requirement from the diff: when no issue, PR message, or conversation states the request, write \\`required: not recorded — ask the requester\\` as the only request-derived line (a \\`required\\` line for an existing contract callers depend on may still be listed) and say so in Notes.\n- Record rule: an existing Requirements section is a record, not a description of the diff. Keep its \\`required\\` lines as they are, rewriting them only when the requester's instructions changed (then from the updated instructions, dropping a line only when the requester removed it; with no instructions available, keep them unchanged); add a \\`chosen\\` line for a new decision, and replace or remove one when the decision it records changed. A section that merely describes the implementation, or holds only the template's placeholder or a \\`required: not recorded\\` line, is not a record: write it afresh by the rule above.\n- Place the section where the template puts it; when the template has no such heading, right after the issue-closing line, or at the top of the body when there is none.\n- Never drop or weaken a \\`required\\` line to fit what was implemented: when one cannot hold in the diff, keep it and say so in Notes.`;\n\n/** Sections of a bug report, in the order they appear in the issue template. */\nexport const BUG_ISSUE_SECTIONS: readonly TemplateSection[] = [\n  { heading: 'Problem', requirement: 'what happens, and what should happen instead' },\n  { heading: 'Evidence', requirement: 'reproduction steps, logs, run IDs, or links' },\n  { heading: 'Impact', requirement: 'who or what is affected, and how badly' },\n  { heading: 'Proposal', requirement: 'the fix you have in mind, and the root cause if known' },\n];\n\n/**\n * Sections a change specification must settle before a third party can implement it, defined\n * once so that the issue template and any tool that drafts or reviews specifications against\n * these sections cannot drift apart; checklist consumers render it with `renderSectionChecklist`.\n * The first three sections suffice for a small change, so they come first.\n */\nexport const CHANGE_ISSUE_SECTIONS: readonly TemplateSection[] = [\n  {\n    heading: 'Background and goal',\n    requirement: 'the problem being solved, for whom, and what outcome counts as success',\n  },\n  {\n    heading: 'Behavior',\n    requirement:\n      'every user- or caller-observable behavior, including inputs, outputs, error cases, edge cases, and interactions with existing behavior, stated precisely enough that two implementers would build the same thing',\n  },\n  {\n    heading: 'Acceptance criteria',\n    requirement:\n      'checkable conditions (Given/When/Then or an equivalent) that decide whether the implementation is done',\n  },\n  {\n    heading: 'Scope and non-goals',\n    requirement: 'what the change covers and what it deliberately leaves out, so an implementer knows where to stop',\n  },\n  {\n    heading: 'Design constraints',\n    requirement:\n      'the data, API, schema, UI, and configuration changes, naming, and the existing code or conventions the implementation must fit — as far as the writer intends to constrain them, with everything else explicitly left to the implementer',\n  },\n  {\n    heading: 'Compatibility and migration',\n    requirement: 'what existing data, users, callers, or configurations are affected and how the transition happens',\n  },\n  {\n    heading: 'Verification',\n    requirement: 'how the change is tested or demonstrated, including what needs no test and why',\n  },\n  {\n    heading: 'Open questions',\n    requirement: 'undecided points, each with its options; empty once the specification is implementable',\n  },\n];\n\n/** Renders sections as markdown bullets (`- **Heading**: requirement`). */\nexport function renderSectionChecklist(sections: readonly TemplateSection[]): string {\n  return sections.map((section) => `- **${section.heading}**: ${section.requirement}`).join('\\n');\n}\n\n/** Renders sections as markdown headings, each followed by its requirement as a placeholder comment. */\nexport function renderSectionTemplate(sections: readonly TemplateSection[]): string {\n  return sections\n    .map(\n      (section) =>\n        `## ${section.heading}\\n\\n<!-- ${section.requirement.charAt(0).toUpperCase()}${section.requirement.slice(1)}. -->`\n    )\n    .join('\\n\\n');\n}\n"],"mappings":"aAWA,MAAa,EAAoD,CAC/D,CACE,QAAS,MACT,YAAa,sGACf,EACA,CACE,QAAS,eACT,YACE,6cACJ,EACA,CACE,QAAS,mBACT,YACE,4GACJ,EACA,CACE,QAAS,oBACT,YACE,yKACJ,EACA,CACE,QAAS,UACT,YAAa,+DACf,EACA,CACE,QAAS,QACT,YAAa,sGACf,CACF,EAca,EAAiD,CAC5D,CAAE,QAAS,UAAW,YAAa,8CAA+C,EAClF,CAAE,QAAS,WAAY,YAAa,6CAA8C,EAClF,CAAE,QAAS,SAAU,YAAa,wCAAyC,EAC3E,CAAE,QAAS,WAAY,YAAa,uDAAwD,CAC9F,EAQa,EAAoD,CAC/D,CACE,QAAS,sBACT,YAAa,wEACf,EACA,CACE,QAAS,WACT,YACE,kNACJ,EACA,CACE,QAAS,sBACT,YACE,wGACJ,EACA,CACE,QAAS,sBACT,YAAa,mGACf,EACA,CACE,QAAS,qBACT,YACE,0OACJ,EACA,CACE,QAAS,8BACT,YAAa,mGACf,EACA,CACE,QAAS,eACT,YAAa,gFACf,EACA,CACE,QAAS,iBACT,YAAa,wFACf,CACF,EAGA,SAAgB,EAAuB,EAA8C,CACnF,OAAO,EAAS,IAAK,GAAY,OAAO,EAAQ,QAAQ,MAAM,EAAQ,aAAa,CAAC,CAAC,KAAK;CAAI,CAChG,CAGA,SAAgB,EAAsB,EAA8C,CAClF,OAAO,EACJ,IACE,GACC,MAAM,EAAQ,QAAQ,WAAW,EAAQ,YAAY,OAAO,CAAC,CAAC,CAAC,YAAY,IAAI,EAAQ,YAAY,MAAM,CAAC,EAAE,MAChH,CAAC,CACA,KAAK;;CAAM,CAChB"}

package/dist/githubTemplates.d.ts

@@ -9,6 +9,13 @@ export interface TemplateSection {
 }
 /** Sections of a pull request body, in the order they appear in the PR template. */
 export declare const PULL_REQUEST_SECTIONS: readonly TemplateSection[];
+/**
+ * How a tool that writes or rewrites a PR body fills the Requirements section of
+ * `PULL_REQUEST_SECTIONS`, as markdown bullets for an agent's instructions. Skills that draft PR
+ * bodies render this text instead of restating it, so the writers and the reviewers that read the
+ * section as the boundary a fix must keep never disagree on what a line means.
+ */
+export declare const PULL_REQUEST_REQUIREMENTS_RULES = "- Requirements section: one line per requirement, taken from the requester's instructions as they were given (the issue, the conversation that asked for the change), each marked `required` (asked for, or an existing contract callers depend on) or `chosen` (your own decision, which a simpler design may replace). Never infer a requirement from the diff: when no issue, PR message, or conversation states the request, write `required: not recorded \u2014 ask the requester` as the only request-derived line (a `required` line for an existing contract callers depend on may still be listed) and say so in Notes.\n- Record rule: an existing Requirements section is a record, not a description of the diff. Keep its `required` lines as they are, rewriting them only when the requester's instructions changed (then from the updated instructions, dropping a line only when the requester removed it; with no instructions available, keep them unchanged); add a `chosen` line for a new decision, and replace or remove one when the decision it records changed. A section that merely describes the implementation, or holds only the template's placeholder or a `required: not recorded` line, is not a record: write it afresh by the rule above.\n- Place the section where the template puts it; when the template has no such heading, right after the issue-closing line, or at the top of the body when there is none.\n- Never drop or weaken a `required` line to fit what was implemented: when one cannot hold in the diff, keep it and say so in Notes.";
 /** Sections of a bug report, in the order they appear in the issue template. */
 export declare const BUG_ISSUE_SECTIONS: readonly TemplateSection[];
 /**

package/dist/githubTemplates.js

@@ -1,5 +1,5 @@
-const e=[{heading:`Why`,requirement:`the problem, with the numbers or observations behind it, and why this approach over the alternatives`},{heading:`Requirements`,requirement:"the requirements the change must satisfy and the guarantees it must keep, one per line, each marked `required` (asked for by the requester, or an existing contract callers depend on) or `chosen` (the implementer's own decision, which a simpler design may replace); copy the requester's instructions here as given, whether they came from an issue or a conversation, and keep the list when the body is later rewritten unless the requester's instructions changed"},{heading:`Customer Summary`,requirement:`behavior, workflow, or user-visible changes, written for readers who know nothing about the implementation`},{heading:`Technical Summary`,requirement:`decisions and their reasons, data flow, where to look (the files that matter most), and what to check hardest: the parts whose correctness is argued rather than proven`},{heading:`Testing`,requirement:`commands run, tests added, and what was NOT exercised and why`},{heading:`Notes`,requirement:`known limitations, compatibility and migration, follow-up work; delete this section if there is none`}],t=[{heading:`Problem`,requirement:`what happens, and what should happen instead`},{heading:`Evidence`,requirement:`reproduction steps, logs, run IDs, or links`},{heading:`Impact`,requirement:`who or what is affected, and how badly`},{heading:`Proposal`,requirement:`the fix you have in mind, and the root cause if known`}],n=[{heading:`Background and goal`,requirement:`the problem being solved, for whom, and what outcome counts as success`},{heading:`Behavior`,requirement:`every user- or caller-observable behavior, including inputs, outputs, error cases, edge cases, and interactions with existing behavior, stated precisely enough that two implementers would build the same thing`},{heading:`Acceptance criteria`,requirement:`checkable conditions (Given/When/Then or an equivalent) that decide whether the implementation is done`},{heading:`Scope and non-goals`,requirement:`what the change covers and what it deliberately leaves out, so an implementer knows where to stop`},{heading:`Design constraints`,requirement:`the data, API, schema, UI, and configuration changes, naming, and the existing code or conventions the implementation must fit — as far as the writer intends to constrain them, with everything else explicitly left to the implementer`},{heading:`Compatibility and migration`,requirement:`what existing data, users, callers, or configurations are affected and how the transition happens`},{heading:`Verification`,requirement:`how the change is tested or demonstrated, including what needs no test and why`},{heading:`Open questions`,requirement:`undecided points, each with its options; empty once the specification is implementable`}];function r(e){return e.map(e=>`- **${e.heading}**: ${e.requirement}`).join(`
-`)}function i(e){return e.map(e=>`## ${e.heading}\n\n<!-- ${e.requirement.charAt(0).toUpperCase()}${e.requirement.slice(1)}. -->`).join(`
+const e=[{heading:`Why`,requirement:`the problem, with the numbers or observations behind it, and why this approach over the alternatives`},{heading:`Requirements`,requirement:"the requirements the change must satisfy and the guarantees it must keep, one per line, each marked `required` (asked for by the requester, or an existing contract callers depend on) or `chosen` (the implementer's own decision, which a simpler design may replace); copy the requester's instructions here as given, whether they came from an issue or a conversation, and keep the list when the body is later rewritten unless the requester's instructions changed"},{heading:`Customer Summary`,requirement:`behavior, workflow, or user-visible changes, written for readers who know nothing about the implementation`},{heading:`Technical Summary`,requirement:`decisions and their reasons, data flow, where to look (the files that matter most), and what to check hardest: the parts whose correctness is argued rather than proven`},{heading:`Testing`,requirement:`commands run, tests added, and what was NOT exercised and why`},{heading:`Notes`,requirement:`known limitations, compatibility and migration, follow-up work; delete this section if there is none`}],t="- Requirements section: one line per requirement, taken from the requester's instructions as they were given (the issue, the conversation that asked for the change), each marked `required` (asked for, or an existing contract callers depend on) or `chosen` (your own decision, which a simpler design may replace). Never infer a requirement from the diff: when no issue, PR message, or conversation states the request, write `required: not recorded — ask the requester` as the only request-derived line (a `required` line for an existing contract callers depend on may still be listed) and say so in Notes.\n- Record rule: an existing Requirements section is a record, not a description of the diff. Keep its `required` lines as they are, rewriting them only when the requester's instructions changed (then from the updated instructions, dropping a line only when the requester removed it; with no instructions available, keep them unchanged); add a `chosen` line for a new decision, and replace or remove one when the decision it records changed. A section that merely describes the implementation, or holds only the template's placeholder or a `required: not recorded` line, is not a record: write it afresh by the rule above.\n- Place the section where the template puts it; when the template has no such heading, right after the issue-closing line, or at the top of the body when there is none.\n- Never drop or weaken a `required` line to fit what was implemented: when one cannot hold in the diff, keep it and say so in Notes.",n=[{heading:`Problem`,requirement:`what happens, and what should happen instead`},{heading:`Evidence`,requirement:`reproduction steps, logs, run IDs, or links`},{heading:`Impact`,requirement:`who or what is affected, and how badly`},{heading:`Proposal`,requirement:`the fix you have in mind, and the root cause if known`}],r=[{heading:`Background and goal`,requirement:`the problem being solved, for whom, and what outcome counts as success`},{heading:`Behavior`,requirement:`every user- or caller-observable behavior, including inputs, outputs, error cases, edge cases, and interactions with existing behavior, stated precisely enough that two implementers would build the same thing`},{heading:`Acceptance criteria`,requirement:`checkable conditions (Given/When/Then or an equivalent) that decide whether the implementation is done`},{heading:`Scope and non-goals`,requirement:`what the change covers and what it deliberately leaves out, so an implementer knows where to stop`},{heading:`Design constraints`,requirement:`the data, API, schema, UI, and configuration changes, naming, and the existing code or conventions the implementation must fit — as far as the writer intends to constrain them, with everything else explicitly left to the implementer`},{heading:`Compatibility and migration`,requirement:`what existing data, users, callers, or configurations are affected and how the transition happens`},{heading:`Verification`,requirement:`how the change is tested or demonstrated, including what needs no test and why`},{heading:`Open questions`,requirement:`undecided points, each with its options; empty once the specification is implementable`}];function i(e){return e.map(e=>`- **${e.heading}**: ${e.requirement}`).join(`
+`)}function a(e){return e.map(e=>`## ${e.heading}\n\n<!-- ${e.requirement.charAt(0).toUpperCase()}${e.requirement.slice(1)}. -->`).join(`
 
-`)}export{t as BUG_ISSUE_SECTIONS,n as CHANGE_ISSUE_SECTIONS,e as PULL_REQUEST_SECTIONS,r as renderSectionChecklist,i as renderSectionTemplate};
+`)}export{n as BUG_ISSUE_SECTIONS,r as CHANGE_ISSUE_SECTIONS,t as PULL_REQUEST_REQUIREMENTS_RULES,e as PULL_REQUEST_SECTIONS,i as renderSectionChecklist,a as renderSectionTemplate};
 //# sourceMappingURL=githubTemplates.js.map

package/dist/githubTemplates.js.map

@@ -1 +1 @@
-{"version":3,"file":"githubTemplates.js","names":[],"sources":["../src/githubTemplates.ts"],"sourcesContent":["/**\n * A section of a PR or issue body: its heading and what the section must state. `requirement`\n * starts lowercase and ends without punctuation, so that it reads both as a placeholder sentence\n * (capitalized, with a period appended) and as a checklist clause after the heading.\n */\nexport interface TemplateSection {\n  readonly heading: string;\n  readonly requirement: string;\n}\n\n/** Sections of a pull request body, in the order they appear in the PR template. */\nexport const PULL_REQUEST_SECTIONS: readonly TemplateSection[] = [\n  {\n    heading: 'Why',\n    requirement: 'the problem, with the numbers or observations behind it, and why this approach over the alternatives',\n  },\n  {\n    heading: 'Requirements',\n    requirement:\n      \"the requirements the change must satisfy and the guarantees it must keep, one per line, each marked `required` (asked for by the requester, or an existing contract callers depend on) or `chosen` (the implementer's own decision, which a simpler design may replace); copy the requester's instructions here as given, whether they came from an issue or a conversation, and keep the list when the body is later rewritten unless the requester's instructions changed\",\n  },\n  {\n    heading: 'Customer Summary',\n    requirement:\n      'behavior, workflow, or user-visible changes, written for readers who know nothing about the implementation',\n  },\n  {\n    heading: 'Technical Summary',\n    requirement:\n      'decisions and their reasons, data flow, where to look (the files that matter most), and what to check hardest: the parts whose correctness is argued rather than proven',\n  },\n  {\n    heading: 'Testing',\n    requirement: 'commands run, tests added, and what was NOT exercised and why',\n  },\n  {\n    heading: 'Notes',\n    requirement: 'known limitations, compatibility and migration, follow-up work; delete this section if there is none',\n  },\n];\n\n/** Sections of a bug report, in the order they appear in the issue template. */\nexport const BUG_ISSUE_SECTIONS: readonly TemplateSection[] = [\n  { heading: 'Problem', requirement: 'what happens, and what should happen instead' },\n  { heading: 'Evidence', requirement: 'reproduction steps, logs, run IDs, or links' },\n  { heading: 'Impact', requirement: 'who or what is affected, and how badly' },\n  { heading: 'Proposal', requirement: 'the fix you have in mind, and the root cause if known' },\n];\n\n/**\n * Sections a change specification must settle before a third party can implement it, defined\n * once so that the issue template and any tool that drafts or reviews specifications against\n * these sections cannot drift apart; checklist consumers render it with `renderSectionChecklist`.\n * The first three sections suffice for a small change, so they come first.\n */\nexport const CHANGE_ISSUE_SECTIONS: readonly TemplateSection[] = [\n  {\n    heading: 'Background and goal',\n    requirement: 'the problem being solved, for whom, and what outcome counts as success',\n  },\n  {\n    heading: 'Behavior',\n    requirement:\n      'every user- or caller-observable behavior, including inputs, outputs, error cases, edge cases, and interactions with existing behavior, stated precisely enough that two implementers would build the same thing',\n  },\n  {\n    heading: 'Acceptance criteria',\n    requirement:\n      'checkable conditions (Given/When/Then or an equivalent) that decide whether the implementation is done',\n  },\n  {\n    heading: 'Scope and non-goals',\n    requirement: 'what the change covers and what it deliberately leaves out, so an implementer knows where to stop',\n  },\n  {\n    heading: 'Design constraints',\n    requirement:\n      'the data, API, schema, UI, and configuration changes, naming, and the existing code or conventions the implementation must fit — as far as the writer intends to constrain them, with everything else explicitly left to the implementer',\n  },\n  {\n    heading: 'Compatibility and migration',\n    requirement: 'what existing data, users, callers, or configurations are affected and how the transition happens',\n  },\n  {\n    heading: 'Verification',\n    requirement: 'how the change is tested or demonstrated, including what needs no test and why',\n  },\n  {\n    heading: 'Open questions',\n    requirement: 'undecided points, each with its options; empty once the specification is implementable',\n  },\n];\n\n/** Renders sections as markdown bullets (`- **Heading**: requirement`). */\nexport function renderSectionChecklist(sections: readonly TemplateSection[]): string {\n  return sections.map((section) => `- **${section.heading}**: ${section.requirement}`).join('\\n');\n}\n\n/** Renders sections as markdown headings, each followed by its requirement as a placeholder comment. */\nexport function renderSectionTemplate(sections: readonly TemplateSection[]): string {\n  return sections\n    .map(\n      (section) =>\n        `## ${section.heading}\\n\\n<!-- ${section.requirement.charAt(0).toUpperCase()}${section.requirement.slice(1)}. -->`\n    )\n    .join('\\n\\n');\n}\n"],"mappings":"AAWA,MAAa,EAAoD,CAC/D,CACE,QAAS,MACT,YAAa,sGACf,EACA,CACE,QAAS,eACT,YACE,6cACJ,EACA,CACE,QAAS,mBACT,YACE,4GACJ,EACA,CACE,QAAS,oBACT,YACE,yKACJ,EACA,CACE,QAAS,UACT,YAAa,+DACf,EACA,CACE,QAAS,QACT,YAAa,sGACf,CACF,EAGa,EAAiD,CAC5D,CAAE,QAAS,UAAW,YAAa,8CAA+C,EAClF,CAAE,QAAS,WAAY,YAAa,6CAA8C,EAClF,CAAE,QAAS,SAAU,YAAa,wCAAyC,EAC3E,CAAE,QAAS,WAAY,YAAa,uDAAwD,CAC9F,EAQa,EAAoD,CAC/D,CACE,QAAS,sBACT,YAAa,wEACf,EACA,CACE,QAAS,WACT,YACE,kNACJ,EACA,CACE,QAAS,sBACT,YACE,wGACJ,EACA,CACE,QAAS,sBACT,YAAa,mGACf,EACA,CACE,QAAS,qBACT,YACE,0OACJ,EACA,CACE,QAAS,8BACT,YAAa,mGACf,EACA,CACE,QAAS,eACT,YAAa,gFACf,EACA,CACE,QAAS,iBACT,YAAa,wFACf,CACF,EAGA,SAAgB,EAAuB,EAA8C,CACnF,OAAO,EAAS,IAAK,GAAY,OAAO,EAAQ,QAAQ,MAAM,EAAQ,aAAa,CAAC,CAAC,KAAK;CAAI,CAChG,CAGA,SAAgB,EAAsB,EAA8C,CAClF,OAAO,EACJ,IACE,GACC,MAAM,EAAQ,QAAQ,WAAW,EAAQ,YAAY,OAAO,CAAC,CAAC,CAAC,YAAY,IAAI,EAAQ,YAAY,MAAM,CAAC,EAAE,MAChH,CAAC,CACA,KAAK;;CAAM,CAChB"}
+{"version":3,"file":"githubTemplates.js","names":[],"sources":["../src/githubTemplates.ts"],"sourcesContent":["/**\n * A section of a PR or issue body: its heading and what the section must state. `requirement`\n * starts lowercase and ends without punctuation, so that it reads both as a placeholder sentence\n * (capitalized, with a period appended) and as a checklist clause after the heading.\n */\nexport interface TemplateSection {\n  readonly heading: string;\n  readonly requirement: string;\n}\n\n/** Sections of a pull request body, in the order they appear in the PR template. */\nexport const PULL_REQUEST_SECTIONS: readonly TemplateSection[] = [\n  {\n    heading: 'Why',\n    requirement: 'the problem, with the numbers or observations behind it, and why this approach over the alternatives',\n  },\n  {\n    heading: 'Requirements',\n    requirement:\n      \"the requirements the change must satisfy and the guarantees it must keep, one per line, each marked `required` (asked for by the requester, or an existing contract callers depend on) or `chosen` (the implementer's own decision, which a simpler design may replace); copy the requester's instructions here as given, whether they came from an issue or a conversation, and keep the list when the body is later rewritten unless the requester's instructions changed\",\n  },\n  {\n    heading: 'Customer Summary',\n    requirement:\n      'behavior, workflow, or user-visible changes, written for readers who know nothing about the implementation',\n  },\n  {\n    heading: 'Technical Summary',\n    requirement:\n      'decisions and their reasons, data flow, where to look (the files that matter most), and what to check hardest: the parts whose correctness is argued rather than proven',\n  },\n  {\n    heading: 'Testing',\n    requirement: 'commands run, tests added, and what was NOT exercised and why',\n  },\n  {\n    heading: 'Notes',\n    requirement: 'known limitations, compatibility and migration, follow-up work; delete this section if there is none',\n  },\n];\n\n/**\n * How a tool that writes or rewrites a PR body fills the Requirements section of\n * `PULL_REQUEST_SECTIONS`, as markdown bullets for an agent's instructions. Skills that draft PR\n * bodies render this text instead of restating it, so the writers and the reviewers that read the\n * section as the boundary a fix must keep never disagree on what a line means.\n */\nexport const PULL_REQUEST_REQUIREMENTS_RULES = `- Requirements section: one line per requirement, taken from the requester's instructions as they were given (the issue, the conversation that asked for the change), each marked \\`required\\` (asked for, or an existing contract callers depend on) or \\`chosen\\` (your own decision, which a simpler design may replace). Never infer a requirement from the diff: when no issue, PR message, or conversation states the request, write \\`required: not recorded — ask the requester\\` as the only request-derived line (a \\`required\\` line for an existing contract callers depend on may still be listed) and say so in Notes.\n- Record rule: an existing Requirements section is a record, not a description of the diff. Keep its \\`required\\` lines as they are, rewriting them only when the requester's instructions changed (then from the updated instructions, dropping a line only when the requester removed it; with no instructions available, keep them unchanged); add a \\`chosen\\` line for a new decision, and replace or remove one when the decision it records changed. A section that merely describes the implementation, or holds only the template's placeholder or a \\`required: not recorded\\` line, is not a record: write it afresh by the rule above.\n- Place the section where the template puts it; when the template has no such heading, right after the issue-closing line, or at the top of the body when there is none.\n- Never drop or weaken a \\`required\\` line to fit what was implemented: when one cannot hold in the diff, keep it and say so in Notes.`;\n\n/** Sections of a bug report, in the order they appear in the issue template. */\nexport const BUG_ISSUE_SECTIONS: readonly TemplateSection[] = [\n  { heading: 'Problem', requirement: 'what happens, and what should happen instead' },\n  { heading: 'Evidence', requirement: 'reproduction steps, logs, run IDs, or links' },\n  { heading: 'Impact', requirement: 'who or what is affected, and how badly' },\n  { heading: 'Proposal', requirement: 'the fix you have in mind, and the root cause if known' },\n];\n\n/**\n * Sections a change specification must settle before a third party can implement it, defined\n * once so that the issue template and any tool that drafts or reviews specifications against\n * these sections cannot drift apart; checklist consumers render it with `renderSectionChecklist`.\n * The first three sections suffice for a small change, so they come first.\n */\nexport const CHANGE_ISSUE_SECTIONS: readonly TemplateSection[] = [\n  {\n    heading: 'Background and goal',\n    requirement: 'the problem being solved, for whom, and what outcome counts as success',\n  },\n  {\n    heading: 'Behavior',\n    requirement:\n      'every user- or caller-observable behavior, including inputs, outputs, error cases, edge cases, and interactions with existing behavior, stated precisely enough that two implementers would build the same thing',\n  },\n  {\n    heading: 'Acceptance criteria',\n    requirement:\n      'checkable conditions (Given/When/Then or an equivalent) that decide whether the implementation is done',\n  },\n  {\n    heading: 'Scope and non-goals',\n    requirement: 'what the change covers and what it deliberately leaves out, so an implementer knows where to stop',\n  },\n  {\n    heading: 'Design constraints',\n    requirement:\n      'the data, API, schema, UI, and configuration changes, naming, and the existing code or conventions the implementation must fit — as far as the writer intends to constrain them, with everything else explicitly left to the implementer',\n  },\n  {\n    heading: 'Compatibility and migration',\n    requirement: 'what existing data, users, callers, or configurations are affected and how the transition happens',\n  },\n  {\n    heading: 'Verification',\n    requirement: 'how the change is tested or demonstrated, including what needs no test and why',\n  },\n  {\n    heading: 'Open questions',\n    requirement: 'undecided points, each with its options; empty once the specification is implementable',\n  },\n];\n\n/** Renders sections as markdown bullets (`- **Heading**: requirement`). */\nexport function renderSectionChecklist(sections: readonly TemplateSection[]): string {\n  return sections.map((section) => `- **${section.heading}**: ${section.requirement}`).join('\\n');\n}\n\n/** Renders sections as markdown headings, each followed by its requirement as a placeholder comment. */\nexport function renderSectionTemplate(sections: readonly TemplateSection[]): string {\n  return sections\n    .map(\n      (section) =>\n        `## ${section.heading}\\n\\n<!-- ${section.requirement.charAt(0).toUpperCase()}${section.requirement.slice(1)}. -->`\n    )\n    .join('\\n\\n');\n}\n"],"mappings":"AAWA,MAAa,EAAoD,CAC/D,CACE,QAAS,MACT,YAAa,sGACf,EACA,CACE,QAAS,eACT,YACE,6cACJ,EACA,CACE,QAAS,mBACT,YACE,4GACJ,EACA,CACE,QAAS,oBACT,YACE,yKACJ,EACA,CACE,QAAS,UACT,YAAa,+DACf,EACA,CACE,QAAS,QACT,YAAa,sGACf,CACF,EAQa,EAAkC,6/CAMlC,EAAiD,CAC5D,CAAE,QAAS,UAAW,YAAa,8CAA+C,EAClF,CAAE,QAAS,WAAY,YAAa,6CAA8C,EAClF,CAAE,QAAS,SAAU,YAAa,wCAAyC,EAC3E,CAAE,QAAS,WAAY,YAAa,uDAAwD,CAC9F,EAQa,EAAoD,CAC/D,CACE,QAAS,sBACT,YAAa,wEACf,EACA,CACE,QAAS,WACT,YACE,kNACJ,EACA,CACE,QAAS,sBACT,YACE,wGACJ,EACA,CACE,QAAS,sBACT,YAAa,mGACf,EACA,CACE,QAAS,qBACT,YACE,0OACJ,EACA,CACE,QAAS,8BACT,YAAa,mGACf,EACA,CACE,QAAS,eACT,YAAa,gFACf,EACA,CACE,QAAS,iBACT,YAAa,wFACf,CACF,EAGA,SAAgB,EAAuB,EAA8C,CACnF,OAAO,EAAS,IAAK,GAAY,OAAO,EAAQ,QAAQ,MAAM,EAAQ,aAAa,CAAC,CAAC,KAAK;CAAI,CAChG,CAGA,SAAgB,EAAsB,EAA8C,CAClF,OAAO,EACJ,IACE,GACC,MAAM,EAAQ,QAAQ,WAAW,EAAQ,YAAY,OAAO,CAAC,CAAC,CAAC,YAAY,IAAI,EAAQ,YAAY,MAAM,CAAC,EAAE,MAChH,CAAC,CACA,KAAK;;CAAM,CAChB"}

package/dist/index.cjs

@@ -1 +1 @@
-"use strict";Object.defineProperty(exports,Symbol.toStringTag,{value:`Module`});const e=require("./appEnv.cjs"),t=require("./assert.cjs"),n=require("./githubTemplates.cjs"),r=require("./sleep.cjs"),i=require("./error.cjs"),a=require("./humanize.cjs"),o=require("./mail.cjs"),s=require("./parseCommandLineArgs.cjs"),c=require("./shuffle.cjs"),l=require("./sqlite.cjs"),u=require("./zenkaku.cjs");exports.BUG_ISSUE_SECTIONS=n.BUG_ISSUE_SECTIONS,exports.CHANGE_ISSUE_SECTIONS=n.CHANGE_ISSUE_SECTIONS,exports.PULL_REQUEST_SECTIONS=n.PULL_REQUEST_SECTIONS,exports.ensureTruthy=t.ensureTruthy,exports.errorify=i.errorify,exports.getAppEnv=e.getAppEnv,exports.getConnectionLevelSqlitePragmas=l.getConnectionLevelSqlitePragmas,exports.getPersistentSqlitePragmas=l.getPersistentSqlitePragmas,exports.humanizeNumber=a.humanizeNumber,exports.ignoreEnoent=i.ignoreEnoent,exports.ignoreEnoentAsync=i.ignoreEnoentAsync,exports.ignoreError=i.ignoreError,exports.ignoreErrorAsync=i.ignoreErrorAsync,exports.mailTemplates=o.mailTemplates,exports.parseCommandLineArgs=s.parseCommandLineArgs,exports.renderSectionChecklist=n.renderSectionChecklist,exports.renderSectionTemplate=n.renderSectionTemplate,exports.shuffle=c.shuffle,exports.sleep=r.sleep,exports.withRetry=i.withRetry,exports.zenkakuAlphanumericalsToHankaku=u.zenkakuAlphanumericalsToHankaku;
+"use strict";Object.defineProperty(exports,Symbol.toStringTag,{value:`Module`});const e=require("./appEnv.cjs"),t=require("./assert.cjs"),n=require("./githubTemplates.cjs"),r=require("./sleep.cjs"),i=require("./error.cjs"),a=require("./humanize.cjs"),o=require("./mail.cjs"),s=require("./parseCommandLineArgs.cjs"),c=require("./shuffle.cjs"),l=require("./sqlite.cjs"),u=require("./zenkaku.cjs");exports.BUG_ISSUE_SECTIONS=n.BUG_ISSUE_SECTIONS,exports.CHANGE_ISSUE_SECTIONS=n.CHANGE_ISSUE_SECTIONS,exports.PULL_REQUEST_REQUIREMENTS_RULES=n.PULL_REQUEST_REQUIREMENTS_RULES,exports.PULL_REQUEST_SECTIONS=n.PULL_REQUEST_SECTIONS,exports.ensureTruthy=t.ensureTruthy,exports.errorify=i.errorify,exports.getAppEnv=e.getAppEnv,exports.getConnectionLevelSqlitePragmas=l.getConnectionLevelSqlitePragmas,exports.getPersistentSqlitePragmas=l.getPersistentSqlitePragmas,exports.humanizeNumber=a.humanizeNumber,exports.ignoreEnoent=i.ignoreEnoent,exports.ignoreEnoentAsync=i.ignoreEnoentAsync,exports.ignoreError=i.ignoreError,exports.ignoreErrorAsync=i.ignoreErrorAsync,exports.mailTemplates=o.mailTemplates,exports.parseCommandLineArgs=s.parseCommandLineArgs,exports.renderSectionChecklist=n.renderSectionChecklist,exports.renderSectionTemplate=n.renderSectionTemplate,exports.shuffle=c.shuffle,exports.sleep=r.sleep,exports.withRetry=i.withRetry,exports.zenkakuAlphanumericalsToHankaku=u.zenkakuAlphanumericalsToHankaku;

package/dist/index.d.ts

@@ -1,6 +1,6 @@
 export { getAppEnv } from './appEnv.js';
 export { ensureTruthy } from './assert.js';
-export { BUG_ISSUE_SECTIONS, CHANGE_ISSUE_SECTIONS, PULL_REQUEST_SECTIONS, renderSectionChecklist, renderSectionTemplate, } from './githubTemplates.js';
+export { BUG_ISSUE_SECTIONS, CHANGE_ISSUE_SECTIONS, PULL_REQUEST_REQUIREMENTS_RULES, PULL_REQUEST_SECTIONS, renderSectionChecklist, renderSectionTemplate, } from './githubTemplates.js';
 export { errorify, ignoreError, ignoreEnoent, ignoreErrorAsync, ignoreEnoentAsync, withRetry } from './error.js';
 export { humanizeNumber } from './humanize.js';
 export { mailTemplates } from './mail.js';

package/dist/index.js

@@ -1 +1 @@
-import{getAppEnv as e}from"./appEnv.js";import{ensureTruthy as t}from"./assert.js";import{BUG_ISSUE_SECTIONS as n,CHANGE_ISSUE_SECTIONS as r,PULL_REQUEST_SECTIONS as i,renderSectionChecklist as a,renderSectionTemplate as o}from"./githubTemplates.js";import{sleep as s}from"./sleep.js";import{errorify as c,ignoreEnoent as l,ignoreEnoentAsync as u,ignoreError as d,ignoreErrorAsync as f,withRetry as p}from"./error.js";import{humanizeNumber as m}from"./humanize.js";import{mailTemplates as h}from"./mail.js";import{parseCommandLineArgs as g}from"./parseCommandLineArgs.js";import{shuffle as _}from"./shuffle.js";import{getConnectionLevelSqlitePragmas as v,getPersistentSqlitePragmas as y}from"./sqlite.js";import{zenkakuAlphanumericalsToHankaku as b}from"./zenkaku.js";export{n as BUG_ISSUE_SECTIONS,r as CHANGE_ISSUE_SECTIONS,i as PULL_REQUEST_SECTIONS,t as ensureTruthy,c as errorify,e as getAppEnv,v as getConnectionLevelSqlitePragmas,y as getPersistentSqlitePragmas,m as humanizeNumber,l as ignoreEnoent,u as ignoreEnoentAsync,d as ignoreError,f as ignoreErrorAsync,h as mailTemplates,g as parseCommandLineArgs,a as renderSectionChecklist,o as renderSectionTemplate,_ as shuffle,s as sleep,p as withRetry,b as zenkakuAlphanumericalsToHankaku};
+import{getAppEnv as e}from"./appEnv.js";import{ensureTruthy as t}from"./assert.js";import{BUG_ISSUE_SECTIONS as n,CHANGE_ISSUE_SECTIONS as r,PULL_REQUEST_REQUIREMENTS_RULES as i,PULL_REQUEST_SECTIONS as a,renderSectionChecklist as o,renderSectionTemplate as s}from"./githubTemplates.js";import{sleep as c}from"./sleep.js";import{errorify as l,ignoreEnoent as u,ignoreEnoentAsync as d,ignoreError as f,ignoreErrorAsync as p,withRetry as m}from"./error.js";import{humanizeNumber as h}from"./humanize.js";import{mailTemplates as g}from"./mail.js";import{parseCommandLineArgs as _}from"./parseCommandLineArgs.js";import{shuffle as v}from"./shuffle.js";import{getConnectionLevelSqlitePragmas as y,getPersistentSqlitePragmas as b}from"./sqlite.js";import{zenkakuAlphanumericalsToHankaku as x}from"./zenkaku.js";export{n as BUG_ISSUE_SECTIONS,r as CHANGE_ISSUE_SECTIONS,i as PULL_REQUEST_REQUIREMENTS_RULES,a as PULL_REQUEST_SECTIONS,t as ensureTruthy,l as errorify,e as getAppEnv,y as getConnectionLevelSqlitePragmas,b as getPersistentSqlitePragmas,h as humanizeNumber,u as ignoreEnoent,d as ignoreEnoentAsync,f as ignoreError,p as ignoreErrorAsync,g as mailTemplates,_ as parseCommandLineArgs,o as renderSectionChecklist,s as renderSectionTemplate,v as shuffle,c as sleep,m as withRetry,x as zenkakuAlphanumericalsToHankaku};

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@willbooster/shared-lib",
-  "version": "10.3.0",
+  "version": "10.4.0",
   "description": "Shared library for WillBooster projects",
   "repository": {
     "type": "git",
@@ -49,7 +49,7 @@
     "@types/node": "26.4.0",
     "@willbooster/oxfmt-config": "1.2.2",
     "@willbooster/oxlint-config": "1.4.8",
-    "@willbooster/wb": "22.1.5",
+    "@willbooster/wb": "22.3.2",
     "build-ts": "21.0.12",
     "oxfmt": "0.65.0",
     "oxlint": "1.80.0",