RFC process

How to propose a change to the protocol: when an RFC is needed, the template, the lifecycle from Draft to Accepted, and what happens after.

Any normative change to HCP goes through an RFC. This keeps the spec small and the reasons for each rule on record.

When you need an RFC

You need one if your change:

Adds, removes, or changes the meaning of any field in surface.json or policy.json.
Adds or changes a MUST, SHOULD, or MAY in the Specification.
Adds a capability, a Binding mode, an adapter kind, or a land.
Changes the exec or result envelope.
Changes a lifecycle stage or an availability flag.

You do not need one for typo fixes, clarifying prose, new examples, new informative sections, or SDK-only changes that do not alter conformance.

Before writing

Search existing RFCs in hcp-protocol/rfcs/.
Check Non-goals. If your proposal touches one, say so and argue the cost of the boundary.
Open an issue titled RFC idea: <title> to test interest. Two thumbs from maintainers or one from an implementer is enough to proceed.

Template

Copy rfcs/0000-template.md to rfcs/NNNN-<kebab-title>.md:

# RFC NNNN — <Title>

- **Status:** Draft
- **Authors:**
- **Replaces:**            <spec section or prior RFC, if any>
- **Tracking:**            <issue link>

## Summary
One paragraph.

## Motivation
What breaks today. Evidence: a pack, a runtime, or a corpus.

## Specification
Normative text, using RFC 2119 keywords, written so it can be pasted into spec/.

## Conformance
Which vectors change or are added (§14.5).

## Compatibility
Minor or major? What happens to 1.x packs and runtimes?

## Drawbacks

## Alternatives

Requirements:

The Specification section must be paste-ready spec text.
Every new MUST needs at least one conformance vector.
State the version impact.

Lifecycle

Draft ──▶ Review ──▶ Final comment (7 days) ──▶ Accepted ──▶ Implemented ──▶ Active
   │          │                                     │
   └──────────┴───────────── Rejected / Withdrawn ──┘

Status	Meaning
Draft	PR open; author iterating
Review	A maintainer is sponsoring; discussion on the PR
Final comment	Seven days; any maintainer may object with reasons
Accepted	Merged into `rfcs/`; spec editor lands text in `spec/`; docs regenerate
Implemented	Reference SDK ships it; vectors pass
Active	Released in a protocol version
Rejected	Closed with reasons recorded in the RFC
Withdrawn	Author closed

An RFC is Accepted when it exits Final comment without unresolved objections and has two maintainer approvals (steering approval for major changes).

After acceptance

Spec editor updates spec/ and the Specification pages.
Conformance vectors are added to packages/sdk/src/conformance.test.ts.
Versioning §13.5 lists the change.
The RFC's status is updated in place.

Accepted RFCs

RFC	Title	Version	Status
0001	Wrap hardening: named commands, installer family, land `local`, confirm	HCP/1.1	Accepted, Implemented

Open proposals are tracked on the Roadmap.