Pulse 1.0.0-beta.1 betaExact, immutable release documentation.Browse latest
Documentation platform maintainersactiveReviewed 2026-08-01Review by 2027-01-12

Maintenance policy reference#

Pulse uses a machine-readable maintenance policy so repository automation and Codex receive the same scope boundaries. The policy is advisory about product direction and mandatory about process: Codex may analyze, review, and prepare bounded patches, while a human retains architecture, merge, repository-setting, and release authority.

  • Policy schema: pulse.maintenance-policy.v2
  • Policy version: 6
  • Release: 1.0.0-beta.1
  • Reviewed: 2026-08-01
  • Resident maintainer: Codex
  • Merge authority: human-only
  • Release authority: human-only
  • Protected Codex environment: codex-maintainer
  • Codex secret: OPENAI_API_KEY

Protected environments#

EnvironmentApproval authorityAllowed refsSecretsVariables
codex-maintainerhuman-maintainerdefault-branchOPENAI_API_KEYNone
npm-publishhuman-releaserelease-tagsNoneNone
documentation-productionhuman-release-infrastructurerelease-tagsFASTLY_OBJECT_STORAGE_ACCESS_KEY_ID, FASTLY_OBJECT_STORAGE_SECRET_ACCESS_KEYFASTLY_OBJECT_STORAGE_BUCKET, FASTLY_OBJECT_STORAGE_REGION, FASTLY_OBJECT_STORAGE_ENDPOINT, PULSE_DOCUMENTATION_ORIGIN, PULSE_DOCUMENTATION_BASE_PATH

Production environments are release-control boundaries. Codex may inspect failures and prepare patches, but it cannot approve an environment, receive production credentials outside the declared job, publish packages, promote documentation, or activate infrastructure.

Change classes#

IDMeaningCodex postureSeparate human decisionBoundary
defectDefectMay prepare implementationNoSupported behavior does not match the documented or tested contract.
hardeningHardeningMay prepare implementationNoReliability, security, diagnostics, performance, or test strength improves without widening supported behavior.
documentationDocumentationMay prepare implementationNoDocumentation, examples, generated references, or presentation change without runtime behavior expansion.
evidenceEvidenceMay prepare implementationNoA reproduction, benchmark, fixture, experiment, or usage report records information without creating a product promise.
scope-expansionScope expansionAnalysis only until approvedYesNew authoring syntax, capability, provider, effect, public entry point, compatibility promise, or product behavior is proposed.
architectureArchitectureAnalysis only until approvedYesA protected boundary, trust assumption, ownership rule, execution contract, or governance mechanism changes.
releaseReleaseAnalysis only until approvedYesVersioning, publication, signing, provenance, package composition, or release-channel behavior changes.

A normal human code review is still required for every merge. “Separate human decision” means the change also alters scope, architecture, or release authority and must be acknowledged before implementation is treated as approved direction.

Protected boundaries#

IDBoundaryDecision kindCurrent contract updateMeaning
public-authoring-apiPublic authoring APIarchitectureRequiredThe provider-neutral TypeScript handler and exported application types.
effect-capability-modelEffect and capability modelarchitectureRequiredThe explicit operations a guest can request and the authority a host can realize.
continuation-runtimeContinuation runtimearchitectureRequiredSuspension, resumption, timeout, identity, and lifecycle semantics between effects.
lowerer-trustLowerer trust boundaryarchitectureRequiredDiscovery and execution of package-owned lowerers and the first-party trust restriction.
provider-registryProvider registryarchitectureRequiredProvider namespace resolution, exact scoped-package bootstrap, provider contracts, host bindings, and target realization.
configuration-contractConfiguration contractarchitectureWhen affectedPublic project configuration fields, defaults, precedence, and runtime constraints.
runtime-target-fluidityRuntime target fluidityarchitectureRequiredThe stable runtime authoring contract and the explicit boundary between native, JavaScript, and future sidecar execution targets.
package-publicationPackage publication contractreleaseWhen affectedPublished package set, exports, support tiers, exact versions, and packed payloads.
maintenance-control-planeMaintenance control planearchitectureRequiredAgent authority, scope policy, repository workflows, ownership, and review gates.
documentation-deploymentDocumentation deployment contractreleaseWhen affectedImmutable version objects, mutable promotion surfaces, Object Storage delivery, public routing, and production activation.
release-authorityRelease authorityreleaseWhen affectedVersion, channel, publication, deployment, signing, and provenance decisions.

Path classification is intentionally conservative. Touching a protected path does not prove that a contract changed; it ensures the pull request names the boundary and receives deliberate review.

Validation catalog#

Check IDAvailabilityCommand
maintenance-policyPortablenode scripts/validate-maintainer-control-plane.cjs
publication-control-planePortablenode scripts/validate-publication-workflows.cjs
release-preflightPortablenode scripts/release-preflight.cjs --check
documentationPortablenpm run docs:check
unitPortablenode wasm/scripts/run-wasm-tests.cjs --profile unit --no-report
nativePortablenode wasm/scripts/run-wasm-tests.cjs --profile native --no-report
javascriptPortablenode wasm/scripts/run-wasm-tests.cjs --profile javascript --no-report
conformancePortablenode wasm/scripts/run-wasm-tests.cjs --profile conformance --no-report
cliPortablenode wasm/scripts/run-wasm-tests.cjs --profile cli --no-report
providersDependency-boundnode wasm/scripts/run-wasm-tests.cjs --profile providers --no-report
buildDependency-boundpnpm build
releaseDependency-boundnpm run release:seal

Portable checks use the normal lockfile-pinned workspace installation and do not require the release-only dependency bundle or external provider credentials. Dependency-bound checks remain required before publication when their affected paths are touched.

Reviewed GitHub Actions#

Every external action used by a checked-in workflow is pinned to a full reviewed commit SHA. The human-readable version is retained as a comment, but tags do not determine execution.

ActionReviewed versionCommit SHA
actions/checkoutv7.0.09c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0
actions/setup-nodev6.4.048b55a011bda9f5d6aeb4c2d9c7362e8dae4041e
actions/upload-artifactv7.0.1043fb46d1a93c77aae656e7c1c64a875d1fc6a0a
actions/download-artifactv8.0.13e5f45b2cfb9172054b4087a40e8e0b5a5461e7c
actions/github-scriptv9.0.03a2844b7e9c422d3c10d287c895573f7108da1b3
openai/codex-actionv1.1152fe01ec70a42f454c9d2ebd47598f9fd6893d56

Pull-request declaration#

Every pull request includes a machine-readable Markdown comment with:

<!-- pulse-maintainer-declaration:start -->
Change class: defect
Scope: inside-developer-preview
Protected boundaries: none
Human decision: not-required
<!-- pulse-maintainer-declaration:end -->

The deterministic scope gate compares that declaration with changed paths. It fails only for a missing or contradictory declaration; a correctly declared architecture, scope, or release decision remains visible and relies on CODEOWNER/branch-rule approval rather than pretending an agent can approve it.

Issue intake#

FormInitial classLabels
bug.ymldefecttype:defect, status:needs-reproduction
documentation.ymldocumentationtype:documentation, area:documentation
scope-proposal.ymlscope-expansiontype:scope-proposal, decision:human-required
support.ymlevidencetype:support

Labels are synchronized by the manual Maintainer labels workflow. Issue labels classify incoming evidence; they do not authorize implementation or widen the Beta contract.

Codex operation#

The repository supports two complementary paths:

  1. Native Codex GitHub review can be enabled in Codex settings and follows the nearest AGENTS.md file.
  2. The manual Codex maintainer review workflow runs from the protected codex-maintainer environment, uses the policy-specific prompt in a read-only permission profile, validates its output against the generated maintainer-review schema, and posts a structured review to the selected pull request.

Neither path can merge, publish, change repository settings, or approve a protected-boundary decision. The environment secret is released only after the repository owner's configured protection rules pass.

Browse other documentation