Pulse documentation

Start with a working project, then follow the guides and concepts as you need more detail. Pulse uses TypeScript handlers, explicit schemas and capabilities, a .pulse/config.ts project profile, and the pulse CLI. The synchronized release catalog defines package versions and support tiers.

1. Start and ship a first project

1. Getting started — install and create a first project.
2. Project lifecycle — the normal init → doctor → test → dev → build journey and the advanced inspect/compile branches.
3. Beta scope — what the release guarantees and deliberately excludes.
4. Canonical examples — source-bound projects, including Entities, events, and the resource-backed Pulse context MCP server.

2. Follow a task-oriented guide

• Static Router authoring
• Explicit JSON schemas
• Fetching and composing data
• Project lifecycle
• Static events and outbound emission
• Migrate an Express service
• Node build and execution
• Fastly deployment candidates — including links to bindings and GRIP/Fanout.
• Troubleshooting

3. Understand the model

1. Architecture overview — application, compiler, runtime and provider responsibilities.
2. Targets and host work — choose a target and distinguish current support from future hosts.
3. Contracts and providers — bindings, eligibility and host realization.
4. Effects and continuations — execution ownership, concurrency and failure.
5. Structured and opaque bodies — data ownership and bounded reads.
6. Compilation and lowering — how eligible Native source becomes Wasm.
7. Entity engine, adapters, and facades — protocol boundaries around governed operations.
8. Package-owned lowering — advanced extension and trust details.

For deeper implementation invariants, see the linked Architecture contracts. Architecture vision describes direction rather than release support.

4. Use a package directly

• @pulse-compute/pulse
• @pulse-compute/runtime
• @pulse-compute/cli
• @pulse-compute/provider-fastly
• @pulse-compute/grip
• @pulse-compute/assets
• @pulse-compute/crypto
• @pulse-compute/jwt
• @pulse-compute/entities
• @pulse-compute/mcp
• @pulse-compute/s3
• All package support tiers
• Implementation packages

5. Look up exact behavior

• Reference overview
• Canonical API
• Provider and target compatibility
• Managed handler TypeScript and JavaScript
• Native build optimization — default recipe, fallback and optional build settings.
• CLI
• Project configuration
• Diagnostics and remediation
• Environment variables
• Shell completion
• Compatibility import migration — for projects using older package subpaths.
• CLI machine specification
• Normalized configuration JSON Schema bundle — resolved CLI/provider options; use the authored property map above for .pulse/config.ts.

6. Authors and contributors

• Pulse-aware package authoring
• Contributor guide index
• Package-owned lowerer contract
• Add a first-party package-owned lowerer
• Entities lowering maintainer reference
• Add a core provider
• Changelog
• Package support and extension boundaries

Entry points for tools and agents

For an application task, start with this index, the installed package guides and project lifecycle. Pin the selected package version, project root and profile before interpreting commands. The CLI ships this documentation under its package's docs/ directory, plus API.md and cli-spec.json; use pulse --help for the supported command list.

For a change to Pulse itself, first read the repository's root and nearest AGENTS.md, then choose one named Entry Point and its canonical owners. Installed application documentation is not a substitute for repository maintenance policy. See the contributor workflow.

Diagnosing command results explains JSON streams, evidence limits and recovery. A release number alone does not identify uncommitted source or prove that a local artifact matches it.