Development and verification

Repository boundary

Reusable package source belongs in this repository. Site implementations belong under C:\CodeProjects\Sites, and reusable Astro operating doctrine belongs under C:\CodeProjects\Platforms\Astro.

Install pinned development dependencies

npm ci

The lockfile pins the development verification environment, including Astro, Starlight, TypeScript, and Node type declarations.

Run the complete local source gate

npm run verify

This runs:

npm run typecheck
npm test

The typecheck compiles package source, tests, and the real Astro/Starlight type fixture without emitting files. The test suite exercises configuration, event, provider, lifecycle, Astro integration, and Starlight wrapper behavior.

Inspect the package surface

npm pack --dry-run

The package allowlist intentionally includes src, docs, and CHANGELOG.md; npm also includes required metadata such as package.json, README.md, and LICENSE. Including docs keeps links from the packaged README usable. Repository governance, tests, checkpoints, and development fixtures must not enter the package artifact.

The artifact intentionally contains Astro-native TypeScript source rather than compiled JavaScript. Test both Astro loading and ordinary TypeScript resolution; plain Node.js 22 import from node_modules is outside the current contract.

The repository enforces LF for text files through .gitattributes. Release tarballs should be packed from a clean export of the committed tree, not from a platform-normalized working copy, and package members must be checked against the corresponding Git blobs before consumer qualification.

Consumer qualification

Before release or site integration, qualify an exact tarball in clean stock Astro and Starlight consumers. Bind the evidence to the package hash, consumer commit and lockfile, generated runtime chunk, installed versions, and command results.

At minimum, run the consumer’s clean install, production build, production-only dependency audit, and hosting dry-run. A dry-run is not authorization to deploy.

Current restrictions

main is the authoritative integrated development branch. Short-lived working branches may be used for bounded changes, but they must be merged or otherwise integrated deliberately and removed when their work is complete; a permanent Codex development branch is not part of the release model. Tags, GitHub Releases, npm publication, and production package integration are separate release activities.

Version choice and artifact qualification are separate from release authority. See Versioning and releases.