GO — Healthy across all four use cases

• Last commit 1d ago
• 9 active contributors
• Distributed ownership (top contributor 49% of recent commits)
• MIT licensed
• CI configured
• Tests present
• ⚠ Scorecard: known vulnerabilities detected (scored 0/10 by OpenSSF)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against dependency CVEs from deps.dev and OpenSSF Scorecard}

Bootstrap 5.3.8 is an open-source HTML/CSS/JS front-end framework that provides a comprehensive system of pre-built responsive UI components (grids, modals, dropdowns, carousels, tooltips, etc.) via compiled CSS (dist/css/bootstrap.css) and vanilla JavaScript plugins (dist/js/bootstrap.js). It solves the problem of hand-crafting cross-browser responsive layouts and interactive components from scratch, offering both a CDN-ready drop-in and a Sass-based customization pipeline via scss/bootstrap.scss. Source SCSS lives in scss/ (entry point: scss/bootstrap.scss, component partials in scss/), JavaScript plugins are individual ES modules under js/src/ (e.g., js/src/modal.js, js/src/tooltip.js) bundled by build/rollup.config.mjs into dist/. Documentation is a separate Astro/MDX site under site/ with its own build pipeline.

Web developers and UI engineers who need production-ready responsive components without writing custom CSS from scratch — ranging from freelancers rapidly prototyping marketing sites to enterprise teams standardizing internal dashboards. Contributors are typically experienced CSS/JS engineers comfortable with Sass architecture, Rollup bundling, and cross-browser compatibility.

Bootstrap is one of the most mature front-end frameworks in existence, with 160k+ GitHub stars, active development since 2011, and currently at stable v5.3.8. CI is extensive: .github/workflows/ contains separate pipelines for JS tests (js.yml), CSS linting (css.yml), BrowserStack cross-browser testing (browserstack.yml), bundle size tracking (bundlewatch.yml), CodeQL security scanning (codeql.yml), and spell checking (cspell.yml). Verdict: production-ready, actively maintained.

Risk is very low for consumers: Bootstrap has no runtime JavaScript dependencies (Popper.js was internalized). For contributors, the build chain has many moving parts — Sass compilation, PostCSS RTL transforms, Rollup bundling, clean-css minification, and SRI hash generation (build/generate-sri.mjs) must all stay in sync. The .bundlewatch.config.json enforces strict file size budgets, meaning even small additions can break CI. Dependency on BrowserStack for cross-browser testing in CI means external service availability affects PR checks.

Active work is on Bootstrap 5.3.x maintenance: the repo tracks a v4-dev branch for Bootstrap 4 legacy support, workflows include a node-sass.yml suggesting ongoing Sass compatibility testing, and release-drafter.yml automates changelog generation for upcoming patch releases. The publish-nuget.yml workflow indicates active NuGet package publishing pipeline work.

git clone https://github.com/twbs/bootstrap.git cd bootstrap npm install npm start # runs Sass watcher + docs dev server in parallel

Daily commands: npm start # parallel: Sass watch + docs Astro dev server npm run css # full CSS pipeline: compile → prefix → RTL → minify npm run js # full JS pipeline via Rollup npm run test # Jest unit tests for JS plugins npm run docs-serve # docs site only

• js/dist/base-component.js — Defines the base class all Bootstrap JS components extend, establishing lifecycle, data storage, and disposal patterns every contributor must understand.
• build/rollup.config.mjs — Controls how all JavaScript bundles (ESM, UMD, bundle) are compiled and output to dist/, making it essential for understanding the build pipeline.
• build/postcss.config.mjs — Configures PostCSS transforms (autoprefixer, RTL, minification) applied to all compiled CSS output.
• build/build-plugins.mjs — Orchestrates building individual JS plugin files, defining the entry point structure for all component outputs.
• .browserslistrc — Declares the browser support matrix that drives autoprefixer and Babel transforms across all CSS and JS build outputs.
• build/banner.mjs — Defines the license banner prepended to every compiled dist file, required for legal compliance in all build outputs.
• build/change-version.mjs — Automates version string updates across all source files during releases, making it critical for understanding the release workflow.

• BaseComponent (js/dist/base-component.js) (Vanilla JS) — Provides shared constructor, getInstance, getOrCreateInstance, dispose, and data-map logic for all components.
  • Failure mode: Memory leaks if dispose() is not called; duplicate instances if data map is bypassed.
• Alert (js/dist/alert.js) (Vanilla JS, CSS transitions) — Handles dismissal of alert elements with animation and event emission.
  • Failure mode: Alert remains in DOM if close button lacks correct data-bs-dismiss attribute.
• Carousel (js/dist/carousel.js) (Vanilla JS, CSS transitions, touch events) — Manages slide transitions, auto-play, touch/swipe, and keyboard navigation for image carousels.
  • Failure mode: Auto-play continues even when carousel is not visible if pause-on-hover is misconfigured.
• Rollup Build Pipeline (build/rollup.config.mjs) (Rollup, Babel) — Compiles all JS source into ESM, UMD, and bundled dist variants.
  • Failure mode: Missing entry point causes a component to be absent from the bundle without a build error.
• PostCSS Pipeline (build/postcss.config.mjs) (PostCSS, Autoprefixer, cssnano) — Transforms compiled CSS with autoprefixer, RTL flipping, and minification.
  • Failure mode: Outdated browserslist cache causes stale prefixes to be omitted from output.

• SCSS source files → PostCSS pipeline — Sass compiles SCSS to plain CSS which PostCSS then transforms.
• PostCSS pipeline → dist/css/ — Final LTR, RTL, and minified CSS files are written to the dist directory.
• JS source (js/src/) → Rollup bundler — ES module source files are resolved, transpiled via Babel, and bundled.
• Rollup bundler → dist/js/ — UMD, ESM, and bundle variants are written as dist JS files.
• dist/ assets → generate-sri.mjs — SRI script reads dist files and outputs integrity hashes for documentation.

Add a new JavaScript component

1. Create the new component source file extending BaseComponent, following the pattern of existing components. (js/dist/base-component.js)
2. Register the new component entry point in the Rollup config so it gets its own dist file. (build/rollup.config.mjs)
3. Add the component to the build-plugins script so it is compiled as an individual plugin. (build/build-plugins.mjs)
4. Add a size budget entry for the new component bundle to prevent unnoticed bloat. (.bundlewatch.config.json)

Add a new CSS utility or component style

1. Create or edit the relevant SCSS partial; utilities live in scss/utilities/, components in scss/. (dist/css/bootstrap-utilities.css)
2. Verify PostCSS config will apply autoprefixer and RTL transforms to the new styles. (build/postcss.config.mjs)
3. Check that both LTR and RTL dist files are regenerated correctly after build. (dist/css/bootstrap.rtl.css)

Cut a new release

1. Run the version-change script to update version strings across all source files. (build/change-version.mjs)
2. Rebuild all dist assets and regenerate SRI hashes for CDN consumption. (build/generate-sri.mjs)
3. Package example zips for the release artifact. (build/zip-examples.mjs)
4. Confirm bundle size budgets pass before tagging. (.bundlewatch.config.json)

Add browser support for a new target

1. Add or adjust the target query in the browserslist config, which drives both Autoprefixer and Babel. (.browserslistrc)
2. Verify Babel transpilation config still covers the new target correctly. (.babelrc.js)
3. Re-run the CSS workflow to ensure new vendor prefixes are generated. (.github/workflows/css.yml)

• Sass/SCSS — Enables variables, mixins, and nesting for maintainable, themeable CSS at scale.
• Rollup — Produces clean ESM and UMD bundles with tree-shaking, keeping individual component files small.
• PostCSS + Autoprefixer — Automatically adds vendor prefixes based on the browserslist target, removing manual prefix maintenance.
• Vanilla JS (no framework) — Keeps Bootstrap dependency-free (except optional Popper) so it works in any stack.
• BrowserStack — Provides real cross-browser testing coverage without maintaining a physical device lab.

• Ship both ESM and UMD builds

  • Why: Supports modern bundlers (Vite, webpack) via ESM while remaining usable via CDN script tags with UMD.
  • Consequence: Doubles the number of JS dist files to maintain and increases build time.

• Vanilla JS only, no framework dependency

  • Why: Maximises compatibility and keeps bundle size minimal.
  • Consequence: More verbose component code compared to reactive-framework equivalents; no reactive data binding.

• Generate RTL CSS as a separate file

  • Why: Avoids shipping RTL rules to LTR users, keeping the default bundle lean.
  • Consequence: Teams supporting both directions must load and switch between two stylesheets.

• CSS-only utilities generated at build time

  • Why: Eliminates runtime class generation overhead and makes output fully static.
  • Consequence: Customisation requires a Sass build step rather than simple JS config.

• Does not provide a JavaScript application framework or component lifecycle beyond DOM manipulation
• Does not handle server-side rendering (SSR) or hydration
• Does not include data fetching, state management, or routing
• Does not support IE 11 (explicitly dropped in Bootstrap 5)
• Does not ship icon assets (Bootstrap Icons is a separate project)
• Does not provide form validation logic beyond CSS states

• Avg cyclomatic complexity: ~6 — Bootstrap's JS components are individually simple (low cyclomatic complexity per function), but the carousel and modal components contain multi-branch state machines that raise the average.
• Largest file: dist/js/bootstrap.bundle.js (3,800 lines)
• Estimated quality issues: ~3 — Main issues are committed dist artifacts, scattered version strings, and absence of TypeScript types in source (mitigated by separate @types/bootstrap package).

• Distributing compiled artifacts in source control (Medium) — dist/: The entire dist/ directory of compiled CSS and JS is committed to the repository, causing large diffs on every release and merge conflicts.
• Duplicate build outputs (ESM + UMD + bundle) (Low) — dist/js/: Six JS variants (normal, min, bundle, esm, esm.min, bundle.min) are all committed, multiplying storage and CI artifact size.
• Hard-coded version strings requiring scripted replacement (Medium) — build/change-version.mjs: Version strings scattered across multiple files must be updated via a custom script rather than a single source of truth, creating risk of missed replacements.

• dist/css/bootstrap.css (Bundle size / payload) — The full unminified CSS bundle is large (70 KB+ gzipped); projects not using PurgeCSS or Sass imports will ship unused utility classes.
• build/rollup.config.mjs (Build performance) — Building all six JS variants sequentially in CI increases build time; parallelisation is limited by the current config structure.
• js/dist/carousel.js (Runtime performance) — Carousel touch and swipe event listeners are attached on every initialisation with no passive flag enforcement, which can cause scroll jank on mobile.

1. The css-rtl npm script requires the LTR CSS to be compiled first (css-compile) — running it standalone will fail or produce stale output. 2) Node version is pinned in .nvmrc; mismatches cause Sass or native addon failures — always run nvm use first. 3) BrowserStack tests (browserstack.yml) require BROWSERSTACK_USERNAME and BROWSERSTACK_ACCESS_KEY secrets and won't run on forks without them. 4) SRI hashes in docs must be manually regenerated via build/generate-sri.mjs after any dist change, or CDN integrity checks break. 5) .browserslistrc controls both Autoprefixer and Babel targets simultaneously — changing it affects both CSS output and JS transpilation.

• Sass @use / @forward module system — Bootstrap 5 migrated from @import to @use/@forward, meaning scss/bootstrap.scss composes component partials with explicit namespacing — understanding this is required to customize Bootstrap's Sass variables correctly.
• RTLCSS — build/postcss.config.mjs uses RTLCSS to automatically flip directional CSS properties (margin-left→margin-right, etc.) to generate dist/css/*.rtl.css variants without hand-authoring them.
• Subresource Integrity (SRI) — build/generate-sri.mjs produces SHA-384 hashes embedded in CDN <script>/<link> tags in docs, preventing CDN-served file tampering — critical for Bootstrap's widely-used CDN distribution model.
• UMD (Universal Module Definition) — Rollup outputs both UMD (bootstrap.js, works via <script> tag) and ESM (bootstrap.esm.js, works with bundlers) formats simultaneously — understanding UMD explains why Bootstrap works both ways without configuration.
• CSS Logical Properties — Bootstrap 5.3 incrementally adopts CSS logical properties (margin-inline-start instead of margin-left) to reduce the need for separate RTL stylesheets — relevant when reading recent scss/ changes.
• Bundlewatch size regression CI — .bundlewatch.config.json enforces per-file byte budgets in CI, a pattern that prevents accidental bundle bloat — understanding it is essential before adding any new utilities or plugins.
• PostCSS plugin pipeline — build/postcss.config.mjs chains Autoprefixer (adds vendor prefixes per .browserslistrc) and RTLCSS in a single PostCSS pass over compiled CSS — changes to either plugin order affect all dist CSS outputs.

• twbs/bootstrap-npm-starter — Official starter template for projects consuming Bootstrap via npm with Sass customization, the recommended companion for Bootstrap users.
• foundation/foundation-sites — Direct alternative CSS/JS front-end framework solving the same responsive UI component problem in the same ecosystem.
• tailwindlabs/tailwindcss — Alternative approach to the same problem (responsive UI styling) using utility classes instead of pre-built components — the main modern competitor.
• twbs/icons — Official Bootstrap Icons library, a companion repo designed to be used alongside Bootstrap components.
• necolas/normalize.css — Predecessor/foundation concept — Bootstrap historically included normalize.css as its CSS reset base before implementing its own reboot.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add a GitHub Actions workflow for NuGet package validation before publish-nuget.yml runs

The repo has a .github/workflows/publish-nuget.yml workflow but no corresponding pre-publish validation workflow that verifies the NuGet package contents (e.g., correct dist CSS/JS files are bundled, version strings match package.json version 5.3.8). A pre-validation step would catch broken releases before they hit NuGet consumers. This is especially valuable since Bootstrap is consumed via NuGet by the .NET/ASP.NET ecosystem.

• [ ] Inspect .github/workflows/publish-nuget.yml to understand what artifacts it expects and how versioning is handled
• [ ] Create .github/workflows/validate-nuget.yml that triggers on pull requests targeting main
• [ ] Add a step that runs build/change-version.mjs in dry-run mode and asserts the output version matches the version field in package.json (currently 5.3.8)
• [ ] Add a step that builds the dist CSS/JS via npm run css && npm run js and checks that expected output files exist in dist/css/ and dist/js/ before any publish step
• [ ] Add a step that validates composer.json version consistency against package.json version

Add unit tests for build/change-version.mjs covering edge cases in version string replacement

The build/change-version.mjs script is a critical build utility that rewrites version strings across multiple files (JS banners, SCSS variables, composer.json, etc.) when cutting a release. Currently there are no dedicated unit tests for this script visible in the repo. A regression here could silently ship a release with mismatched version strings across dist files, which has historically caused user confusion. Adding tests using Node's built-in node:test runner (already implied by the ESM .mjs convention in the build folder) would be a well-scoped, high-value contribution.

• [ ] Read build/change-version.mjs thoroughly to identify all version replacement patterns and file targets it modifies
• [ ] Create build/tests/change-version.test.mjs using Node's native node:test and assert modules (no new dependencies needed)
• [ ] Write a test that sets up a temporary directory with fixture files mimicking package.json, scss/_variables.scss, and composer.json with a known old version string
• [ ] Assert that after running the version-change logic, all fixture files contain the new version string and no stale references remain
• [ ] Add an edge-case test for pre-release version strings (e.g., 5.3.9-beta.1) to ensure regex patterns handle semver pre-release suffixes correctly
• [ ] Wire the new test file into the scripts section of package.json under a test-build script and add it to .github/workflows/js.yml or a new build-scripts.yml workflow

Add RTL-specific visual regression smoke tests to the existing CSS workflow

Bootstrap ships full RTL CSS variants (e.g., dist/css/bootstrap-grid.rtl.css, dist/css/bootstrap-reboot.rtl.css) generated via css-rtl npm script using PostCSS. The .github/workflows/css.yml workflow compiles and lints CSS but does not verify that RTL output files are actually generated and non-empty after the build. Contributors refactoring build/postcss.config.mjs or .browserslistrc could silently break RTL output. Adding explicit file-existence and non-empty-content assertions in the CSS workflow closes this gap.

• [ ] Open .github/workflows/css.yml and locate the step that runs npm run css
• [ ] After the npm run css step, add a new step that uses a shell script to assert all expected RTL files exist: dist/css/bootstrap.rtl.css, `

1. Add Jest unit tests for js/src/scrollspy.js edge cases (offset calculation with sticky headers) — test coverage for this plugin appears thinner than modal.js or tooltip.js. 2) The build/change-version.mjs script updates version strings but has no corresponding test — add a unit test verifying it correctly patches package.json, scss/_variables.scss, and banner.mjs. 3) Several .github/ISSUE_TEMPLATE fields reference v5.3 hardcoded — create a script or workflow step that auto-updates issue template version references when package.json version bumps.

• Medium · Outdated or Potentially Vulnerable Transitive Dependencies — package.json / devDependencies. Bootstrap 5.3.8 relies on a build chain with multiple npm dependencies (sass, postcss, rollup, cleancss, etc.). While the primary package itself is a CSS/JS framework with no runtime server-side code, transitive dependencies in the devDependency tree may contain known CVEs. Without a full lockfile audit (package-lock.json or yarn.lock), it is impossible to confirm all dependencies are at safe versions. Tools like npm audit should be run to surface any issues. Fix: Run npm audit --audit-level=moderate regularly and pin all dependency versions. Use Dependabot (already configured via .github/dependabot.yml) and ensure its alerts are acted upon promptly. Review and update dependencies before each release.
• Medium · Potential XSS Risk via Dynamic HTML in JavaScript Components — dist/js/bootstrap.bundle.js, src/js/util/sanitizer.js (inferred). Bootstrap's JavaScript components (tooltips, popovers, modals, etc.) historically accepted HTML content through data attributes such as data-bs-content, data-bs-title, and template options. If user-supplied input is passed into these options without sanitization, it can lead to Cross-Site Scripting (XSS). Bootstrap does include a built-in sanitizer for these cases, but misconfiguration by downstream consumers (e.g., setting sanitize: false) disables this protection entirely. The partial file listing does not show the full JS source, but this is a well-known historical attack surface for this framework. Fix: Ensure sanitize: true (the default) is always used when initializing Tooltip and Popover components. Never pass unsanitized user input into Bootstrap JS component options. Implement a Content Security Policy (CSP) to mitigate XSS impact. Educate downstream developers about the risks of disabling sanitization.
• Medium · Missing Content Security Policy (CSP) in Documentation/Distribution — dist/css/, dist/js/, site/src/ (documentation templates). The repository does not appear to define or recommend a Content Security Policy in its distributed files or documentation snippets. As a widely-used frontend framework, Bootstrap's example HTML pages and starter templates should include CSP headers or meta tags to guide implementers. Without CSP, XSS attacks through Bootstrap's dynamic HTML features have a greater impact. Fix: Add recommended CSP headers to Bootstrap's documentation and starter templates. At minimum, document what CSP directives are needed for Bootstrap to function correctly (e.g., for inline styles used by some components). Provide a sample strict CSP configuration.
• Low · Source Maps Exposed in Distribution Files — dist/css/*.map, dist/js/*.map. Bootstrap ships .map (source map) files alongside its minified CSS and JS distributions (e.g., bootstrap.min.css.map, bootstrap.bundle.js.map). When deployed directly to production without restriction, source maps expose the original unminified source code, making it easier for attackers to understand the internal structure of the application using Bootstrap and identify potential exploitation vectors. Fix: Do not deploy source map files to public production environments, or restrict access to them via server configuration (e.g., deny access to *.map files in nginx/Apache). Source maps should only be accessible to authenticated developers or served to browser DevTools under specific conditions.
• Low · No Subresource Integrity (SRI) Enforced in Default CDN Usage Examples — build/generate-sri.mjs, documentation HTML templates. Bootstrap documentation and CDN usage examples recommend loading Bootstrap from a CDN. If SRI hashes are not included in the <script> and <link> tags in all examples, a compromised CDN could serve malicious JavaScript or CSS to end users of sites built with Bootstrap. The build system includes build/generate-sri.mjs suggesting SRI is considered, but inconsistent application across all documentation examples remains a risk. Fix: Ensure all CDN usage examples in the documentation include integrity and crossorigin attributes with valid SRI hashes. Automate SRI hash generation and validation as part of the release pipeline. The existing generate-sri.mjs script should be verified to cover all distributed assets.
• Low · Workflow Permissions and Supply Chain Risk in GitHub Actions — undefined. The repository uses multiple GitHub Actions workflows (.github/workflows/*.yml). If any workflow uses pull_request_target triggers with checkout of unt Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/twbs/bootstrap shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live twbs/bootstrap repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/twbs/bootstrap.

What it runs against: a local clone of twbs/bootstrap — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in twbs/bootstrap | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of twbs/bootstrap. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/twbs/bootstrap.git
#   cd bootstrap
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of twbs/bootstrap and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "twbs/bootstrap(\\.git)?\\b" \\
  && ok "origin remote is twbs/bootstrap" \\
  || miss "origin remote is not twbs/bootstrap (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "js/dist/base-component.js" \\
  && ok "js/dist/base-component.js" \\
  || miss "missing critical file: js/dist/base-component.js"
test -f "build/rollup.config.mjs" \\
  && ok "build/rollup.config.mjs" \\
  || miss "missing critical file: build/rollup.config.mjs"
test -f "build/postcss.config.mjs" \\
  && ok "build/postcss.config.mjs" \\
  || miss "missing critical file: build/postcss.config.mjs"
test -f "build/build-plugins.mjs" \\
  && ok "build/build-plugins.mjs" \\
  || miss "missing critical file: build/build-plugins.mjs"
test -f ".browserslistrc" \\
  && ok ".browserslistrc" \\
  || miss "missing critical file: .browserslistrc"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/twbs/bootstrap"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.