docs: adopt astro-chartjs-editor 1.3.1, live offset control

[kurkle]

Summary

• Bump @kurkle/astro-chartjs-editor devDependency ^1.0.0 → ^1.3.1 (resolves to 1.3.1, confirmed via npm ls).
• customize.md: inline the separate options block into config, so the default config tab shows the whole sample instead of three lines of glue plus an extra tab.
• offset.md: rebuilt as three side-by-side charts variants (offset: 0 / 1 / 2), each built by a makeConfig(offset) factory that creates its own fresh dataset objects. All three variants use the exact same underlying data values (generated once), so the only difference between them is color assignment. See "Offset — why choices was replaced with charts" below for why this isn't a choices control.
• docs/styles/starlight.css: added to the existing :root block (heading scale) and added a new .content-panel rule, per the fleet convention of never replacing this file's existing rules.
• bar.md / update.md: checked, no changes. Neither fence has a title= attribute duplicating the page h1. update.md's "Add data" action is a real action (pushes new data points) and stays as-is.
• repeat.md: left unchanged — see "Repeat — left alone" below.

Verification

• npm ls @kurkle/astro-chartjs-editor → chartjs-plugin-autocolors@0.0.0-development → @kurkle/astro-chartjs-editor@1.3.1.
• rm -rf node_modules/.astro once before the first build (pre-1.3.1 cache had no version stamp), then npm run docs built cleanly (9 pages generated, no errors) on every iteration.
• Served the real build with astro preview and drove it with Playwright at 1400×900 and 1200-wide. Every changed page rendered non-blank charts, measured by counting non-transparent canvas pixels:
  • bar: 85 794 px (1400w) / 37 064 px (1200w)
  • customize: 72 886 / 45 912
  • offset (3 charts total): 56 715 / 148 695 (bigger at 1200w because the 2-column grid at 1400w becomes a 1-column stack of larger charts at 1200w — confirmed by screenshot, not a bug)
  • repeat (unchanged): 74 635 / 39 368
  • update: 374 532 / 190 116
• customize.md code panel now shows exactly 2 tabs (config, data) instead of 3 — confirmed by screenshot.
• npm run lint and npm test (fixture tests + kurkle-check-package, 14 tests / 19 package checks) pass. The pre-commit hook additionally ran typecheck/build/docs, all green, on both commits.

Offset — why choices was replaced with charts

The first version of this PR gave offset.md a choices radio. It updated the live option value and its on-page readout, but never actually recolored the bars — I measured this with MD5 hashes of canvas-only screenshots (identical across offset 0/1/2 after full animation settle) and with a diagnostic action that read chart.data.datasets[i].backgroundColor straight off the live chart (also identical). Root cause: chartjs-plugin-autocolors's default 'dataset' mode only assigns a color once per dataset object (dataset.backgroundColor = dataset.backgroundColor || background), and the editor's choices mechanism only clones config containers along the changed path — since offset lives under options, config.data (and every dataset object in it) is reused by reference across the rebuild, so the already-colored objects never get touched again. This was not a regression: the pre-existing buttons had the identical limitation (verified — clicking through the old Offset: 0/1/2 buttons only ever changed the plugins.title text; bars were pixel-identical before and after on main).

Per the coordinator's direction, offset.md now uses charts instead: three fixed variants (offset: 0, 1, 2), each produced by makeConfig(offset), which builds its own datasets array from a shared values array on every call. Because each variant gets brand-new dataset objects, autocolors colors each one independently — no shared, already-colored objects to get stuck.

Measured proof it works, by sampling each chart's rendered bar colors directly off its canvas (Playwright + getImageData, run left-to-right at the row with the most distinct color runs):

• The three canvases are pairwise different: canvas MD5s f7ab53b8…, 51345668…, e6610aa3… — all distinct.
• Comparing bar colors position-by-position between offset: 0 and offset: 1 directly (no shift): 0/23 bars match — every single bar's color changed.
• Comparing offset: 0's bar N+1 to offset: 1's bar N (i.e. "shifted by one color"): 21/22 match (95%).
• Comparing offset: 1's bar N+1 to offset: 2's bar N: 21/22 match (95%).
• Example (first 3 bars, RGB): offset: 0 → 202,81,81 / 128,52,52 / 52,128,128; offset: 1 → 128,50,50 / 82,203,203 / 143,203,82; note offset:1's bar 1 ≈ offset:0's bar 2, confirming the one-step shift.
• Total non-transparent pixel count (a proxy for total bar area/height) is identical across all three charts at a given width — confirms the underlying data values are unchanged and only color differs, as intended.

This is exactly what the sample's prose now describes: three charts sharing the same data, each with its own autocolors instance whose palette starts one color further along.

Repeat — left alone

I did not apply the analogous choices conversion to repeat.md, because that sample is different from offset.md: its existing "edit repeat in the code panel and click Run" workflow actually works. I verified this directly — editing repeat: 3 → 1 in the live code editor and clicking Run re-executes the whole script, producing fresh dataset objects and a genuinely different, correctly-recolored chart (confirmed by canvas screenshot: distinct per-bar coloring before/after, matching a real repeat-of-1 pattern). A choices control there would hit the exact same stale-object issue diagnosed above and would be a real regression — replacing a working interaction with a non-working one. repeat.md is left exactly as it is on main, pending a decision on how (or whether) to work around the underlying editor/plugin interaction for that sample too.

Separately, while diagnosing this I found what looks like an unrelated one-line typo in src/index.js's setColors(): for mode: 'data' it sets dataset.border = border instead of dataset.borderColor = border, so per-datapoint border colors are silently dropped. Not fixed here — confirmed with the coordinator this is a fix:-type change to published plugin source that needs its own PR and test, after this one lands.

Test plan

• npm ls @kurkle/astro-chartjs-editor resolves to 1.3.1
• npm run docs builds without errors (both commits)
• All 5 sample pages render non-blank charts at 1400w and 1200w (measured ink pixel counts above)
• customize.md shows 2 tabs instead of 3
• offset.md's three charts are pairwise distinct and each one's palette is the previous one shifted by one color (measured, numbers above)
• repeat.md unchanged from main (confirmed via git diff and the GitHub compare API)
• npm run lint passes (pre-existing warnings only, unchanged from main)
• npm test passes (14 fixture tests, 19 package checks)

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying chartjs-plugin-autocolors with    Cloudflare Pages

Latest commit:	713f610
Status:	✅  Deploy successful!
Preview URL:	https://c95891fa.chartjs-plugin-autocolors.pages.dev
Branch Preview URL:	https://docs-sample-structure.chartjs-plugin-autocolors.pages.dev

View logs

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud