Skip to content
Documentation
1.0.0-beta.9 · exact release

Contributing to Pulse

Source fda16de1b352 · Published v1.0.0-beta.9

These pages describe changes to the synchronized Pulse repository. They are not application-author extension APIs.

  1. Choose the owning contract and read the root and nearest AGENTS.md. Use the architecture overview when ownership is unclear.
  2. Classify the change with the scope policy. That page owns the PR declaration and protected-boundary rules. Obtain human direction before widening a contract; record existing direction in the PR.
  3. Make the smallest coherent change in canonical sources. For documentation, use the documentation update loop to regenerate installed copies and references.
  4. Run npm run maintainer:check and the focused checks selected for the diff. Testing Pulse owns task selection, dependency requirements and evidence rules. Ordinary changes do not require a local aggregate release seal.
  5. Open a PR with the scope declaration, what changed, checks completed, and any dependency-bound checks still outstanding. Include the tested revision and working-tree state; an interrupted check is incomplete evidence.

Use the repository-pinned Node and pnpm versions and restore the frozen lockfile with lifecycle scripts disabled before dependency-bound checks. The release manifest owns the supported package and target set. Human maintainers retain merge, settings and release authority.

  • Pulse-aware package authoring — ordinary JavaScript packages, bounded package-root Native lowering, trusted builders, and the separate scoped-provider boundary.
  • Add a provider toolchain — descriptor, bindings, runtime, target, namespace bootstrap, diagnostics, docs, and tests.

The current release executes only trusted first-party lowerer builders. Built-in provider shorthand is release-owned, while an exact scoped project provider may export the versioned ./toolchain contract without self-registration or dependency scanning. Changes that widen either executable trust boundary require an explicit security and compatibility design, not only another manifest or package export.