RFC プロセス

## Motivation

<!-- Why does the protocol need this change? What problem does it solve? -->

## Scope

<!-- Exactly what changes — schemas, tasks, normative text. Be specific about field names,
     enum values, and affected task types. -->

## Alternatives considered

<!-- What other approaches were evaluated? Why were they ruled out?
     Include at least one non-obvious alternative. -->

## Compatibility impact

<!-- Is this breaking? What must downstream implementers change to keep working?
     State explicitly: breaking or non-breaking, and why. -->

## Reviewer checklist

- [ ] Motivation is clear and not redundant with existing functionality
- [ ] Scope is specific enough to implement without further clarification
- [ ] Alternatives section covers at least one non-obvious alternative
- [ ] Compatibility impact accurately states breaking vs. non-breaking
- [ ] Wire-format or schema snippet included (for schema or task changes)

## Decision record

**Status:** accepted | rejected | deferred
**Date:** YYYY-MM-DD
**Discussion:** <!-- link to WG meeting notes or async discussion thread -->
**Vote outcome:** N in favor, N opposed, N abstained

## Rationale

<!-- 2–4 sentences on why the WG reached this conclusion. -->

## Dissent

<!-- Record any minority position, even when it did not change the outcome.
     Example: "Two reviewers preferred adding the field as optional rather than
     required, citing implementation burden for smaller sellers. The WG agreed
     that required enforcement is necessary for audit correctness."
     If the vote was unanimous and all reviewers confirmed no dissent: state that explicitly. -->

## Next steps

<!-- Who is opening the spec PR? Any conditions on the implementation? -->