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#
| Environment | Approval authority | Allowed refs | Secrets | Variables |
|---|---|---|---|---|
codex-maintainer | human-maintainer | default-branch | OPENAI_API_KEY | None |
npm-publish | human-release | release-tags | None | None |
documentation-production | human-release-infrastructure | release-tags | FASTLY_OBJECT_STORAGE_ACCESS_KEY_ID, FASTLY_OBJECT_STORAGE_SECRET_ACCESS_KEY | FASTLY_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#
| ID | Meaning | Codex posture | Separate human decision | Boundary |
|---|---|---|---|---|
defect | Defect | May prepare implementation | No | Supported behavior does not match the documented or tested contract. |
hardening | Hardening | May prepare implementation | No | Reliability, security, diagnostics, performance, or test strength improves without widening supported behavior. |
documentation | Documentation | May prepare implementation | No | Documentation, examples, generated references, or presentation change without runtime behavior expansion. |
evidence | Evidence | May prepare implementation | No | A reproduction, benchmark, fixture, experiment, or usage report records information without creating a product promise. |
scope-expansion | Scope expansion | Analysis only until approved | Yes | New authoring syntax, capability, provider, effect, public entry point, compatibility promise, or product behavior is proposed. |
architecture | Architecture | Analysis only until approved | Yes | A protected boundary, trust assumption, ownership rule, execution contract, or governance mechanism changes. |
release | Release | Analysis only until approved | Yes | Versioning, 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#
| ID | Boundary | Decision kind | Current contract update | Meaning |
|---|---|---|---|---|
public-authoring-api | Public authoring API | architecture | Required | The provider-neutral TypeScript handler and exported application types. |
effect-capability-model | Effect and capability model | architecture | Required | The explicit operations a guest can request and the authority a host can realize. |
continuation-runtime | Continuation runtime | architecture | Required | Suspension, resumption, timeout, identity, and lifecycle semantics between effects. |
lowerer-trust | Lowerer trust boundary | architecture | Required | Discovery and execution of package-owned lowerers and the first-party trust restriction. |
provider-registry | Provider registry | architecture | Required | Provider namespace resolution, exact scoped-package bootstrap, provider contracts, host bindings, and target realization. |
configuration-contract | Configuration contract | architecture | When affected | Public project configuration fields, defaults, precedence, and runtime constraints. |
runtime-target-fluidity | Runtime target fluidity | architecture | Required | The stable runtime authoring contract and the explicit boundary between native, JavaScript, and future sidecar execution targets. |
package-publication | Package publication contract | release | When affected | Published package set, exports, support tiers, exact versions, and packed payloads. |
maintenance-control-plane | Maintenance control plane | architecture | Required | Agent authority, scope policy, repository workflows, ownership, and review gates. |
documentation-deployment | Documentation deployment contract | release | When affected | Immutable version objects, mutable promotion surfaces, Object Storage delivery, public routing, and production activation. |
release-authority | Release authority | release | When affected | Version, 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 ID | Availability | Command |
|---|---|---|
maintenance-policy | Portable | node scripts/validate-maintainer-control-plane.cjs |
publication-control-plane | Portable | node scripts/validate-publication-workflows.cjs |
release-preflight | Portable | node scripts/release-preflight.cjs --check |
documentation | Portable | npm run docs:check |
unit | Portable | node wasm/scripts/run-wasm-tests.cjs --profile unit --no-report |
native | Portable | node wasm/scripts/run-wasm-tests.cjs --profile native --no-report |
javascript | Portable | node wasm/scripts/run-wasm-tests.cjs --profile javascript --no-report |
conformance | Portable | node wasm/scripts/run-wasm-tests.cjs --profile conformance --no-report |
cli | Portable | node wasm/scripts/run-wasm-tests.cjs --profile cli --no-report |
providers | Dependency-bound | node wasm/scripts/run-wasm-tests.cjs --profile providers --no-report |
build | Dependency-bound | pnpm build |
release | Dependency-bound | npm 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.
| Action | Reviewed version | Commit SHA |
|---|---|---|
actions/checkout | v7.0.0 | 9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 |
actions/setup-node | v6.4.0 | 48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e |
actions/upload-artifact | v7.0.1 | 043fb46d1a93c77aae656e7c1c64a875d1fc6a0a |
actions/download-artifact | v8.0.1 | 3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c |
actions/github-script | v9.0.0 | 3a2844b7e9c422d3c10d287c895573f7108da1b3 |
openai/codex-action | v1.11 | 52fe01ec70a42f454c9d2ebd47598f9fd6893d56 |
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#
| Form | Initial class | Labels |
|---|---|---|
bug.yml | defect | type:defect, status:needs-reproduction |
documentation.yml | documentation | type:documentation, area:documentation |
scope-proposal.yml | scope-expansion | type:scope-proposal, decision:human-required |
support.yml | evidence | type: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:
- Native Codex GitHub review can be enabled in Codex settings and follows the nearest
AGENTS.mdfile. - The manual Codex maintainer review workflow runs from the protected
codex-maintainerenvironment, 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.