demo-vault-buttons

A vitest suite that opens every note of a plugin’s in-repo demo-vault/, clicks each code-button in it against a real Obsidian, and fails on any button that errors or never reports a result.

A demo vault’s buttons are the one part of it no other gate can check. lint:md reads the markdown, the coverage suite (registerDemoVaultCoverageSuite) checks the authoring conventions, and neither executes anything — a button whose require('/demoSetup.ts') path is wrong, or that calls an API that has since changed shape, fails at click time and nowhere else.

The companion half — seeding the temp vault with the demo-vault tree, its .obsidian config, and the CodeScript Toolkit binary that turns ```code-button fences into buttons — is buildDemoVaultPopulate in obsidian-integration-testing; hand its result to the project’s globalSetup and name CodeScript Toolkit in enableCommunityPlugins.

Interfaces

Interface	Description
ClickButtonTimeouts	The waiting budgets a single button click is allowed. Both are spent inside ONE transport call, so it is their SUM that assertClickBudgetsFitTransportCap bounds.
DemoVaultButtonResult	The outcome of clicking one button.
DemoVaultNote	One demo-vault note and how many buttons its source declares.
ExpectedNonOkButton	A button that is EXPECTED not to report success, so the suite does not fail on it.
RegisterDemoVaultButtonSuiteOptions	The options for registerDemoVaultButtonSuite.

Functions

Function	Description
assertClickBudgetsFitTransportCap	Refuses a settle/result budget pair that a single transport call could never honour. clickButton waits for the button to mount and then for its result INSIDE ONE evalInObsidian closure, so the transport’s script timeout bounds their sum rather than either one alone — and RegisterDemoVaultButtonSuiteOptions lets a consumer raise each independently, with nothing summing them. Raising settleTimeoutInMilliseconds to 20 000 for one slow note is an ordinary thing to do and silently puts the pair at the cap. Throwing here, at suite registration, is the whole value: the failure it replaces is a WebDriverError: script timeout raised mid-run against whichever button happened to be slowest, naming the transport and neither budget.
countRenderedButtons	Counts the buttons a note’s source will actually render. Three kinds of ```code-button fence render no clickable button, and a vault that DOCUMENTS code buttons is full of the first two: - A fence nested inside a longer or different fence (a markdown ```` or ~~~ block) is a markdown SAMPLE shown to the reader; the renderer never sees it as a block. - An isRaw: true fence renders its output directly and no button element at all. - A fence whose info string carries anything after code-button uses the legacy argument syntax, which renders an error banner asking to update the config rather than the button. Counting any of them makes the suite’s shortfall assertion unsatisfiable — it demands more buttons than the note can ever render — and an assertion that cannot pass gates nothing. The scan follows CommonMark’s fence rules: a fence closes only on a run of the SAME character at least as long as the opener, with no info string, and one left open runs to the end of the document, where it still renders.
findDuplicateCaptions	Finds the captions declared by more than one button. The suite addresses a button by its caption — it collects the captions that mounted and clicks the button carrying each one — so two buttons sharing a caption collapse into one: the second is never clicked, and the note reads as declaring a button that never rendered.
formatFailures	Builds the assertion message for a note’s failing buttons. The captured output is included because a button’s failure is a runtime one — the stack CodeScript Toolkit prints under it is the only diagnosis there is.
listNotesWithButtons	Lists the demo vault’s notes that declare at least one code-button, walking group folders too. A vault big enough to need grouping puts its walkthroughs in numbered folders — and a root-only walk finds NONE of them, which is worse than it sounds: a vault whose notes are all grouped reports zero notes, and one that is partly grouped silently gates only the ungrouped part. Fixture and asset folders are still skipped, so what is walked is walkthroughs and nothing else.
listRenderedButtonCaptions	Lists the captions of the buttons a note’s source will actually render, in source order. Which fences render a button is decided exactly as countRenderedButtons describes. A caption is read from the fence’s own config block; a fence naming none takes CodeScript Toolkit’s default, (no caption), which is what its button then shows.
registerDemoVaultButtonSuite	Registers a vitest suite that clicks every code-button in the repo’s demo vault. One it per note, and one evalInObsidian per button: a single closure runs as one CDP Runtime.evaluate, which the harness caps at 30 s, so a note with a dozen buttons would otherwise time out as a whole rather than reporting which button failed.
selectUnexpectedFailures	Picks the buttons that failed and were not expected to.

Variables

Variable	Description
CODE_SCRIPT_TOOLKIT_PLUGIN_ID	CodeScript Toolkit’s manifest id. It is still the plugin’s original fix-require-modules id, which no longer matches its name — the id is published, so it cannot be changed.