- Status: Draft | Under Review | Accepted | Rejected | Implemented | Superseded
- Author(s): Your Name (@github-handle)
- Created: YYYY-MM-DD
- Last Updated: YYYY-MM-DD
- Target Repository: the repository this RFC targets (e.g. toolhive, toolhive-studio, toolhive-registry-server) | multiple
- Related Issues: toolhive#1234 (if applicable)
A brief (2-3 sentence) description of the proposed change. This should be clear enough that someone can understand the essence of the proposal without reading the full document.
Describe the problem this RFC is trying to solve. Include:
- What is the current behavior or limitation?
- Who is affected by this problem?
- Why is this problem worth solving?
List the specific goals this RFC aims to achieve:
- Goal 1
- Goal 2
- Goal 3
Explicitly state what this RFC does NOT aim to address. This helps set scope and prevents scope creep:
- Non-goal 1
- Non-goal 2
Describe your proposed solution in detail. This section should be comprehensive enough for someone to implement the solution.
Provide an overview of the design. Include diagrams where helpful (Mermaid diagrams are encouraged):
flowchart LR
A[Component A] --> B[Component B]
B --> C[Component C]
Break down the implementation details:
Describe changes to existing components or new components being introduced.
Document any API changes, including:
- New endpoints or methods
- Modified signatures
- Deprecated functionality
// Example API change (use the language of the target repository)
type NewInterface interface {
Method(ctx context.Context, param string) (Result, error)
}Document any new configuration options:
# Example configuration
newFeature:
enabled: true
setting: valueDescribe any changes to data models, schemas, or storage.
This section is required. Security is a core concern for every project in this repository. Address the following:
- What are the potential threats introduced by this change?
- Who are the potential attackers and what are their capabilities?
- How does this change affect authentication?
- What authorization checks are required?
- Are there any changes to permission models?
- What sensitive data does this feature handle?
- How is data protected at rest and in transit?
- Are there any data retention or deletion considerations?
- What user input does this feature accept?
- How is input validated and sanitized?
- What are the potential injection vectors?
- Does this feature require any secrets or credentials?
- How are secrets stored and accessed?
- Are secrets properly rotated and revocable?
- What security-relevant events should be logged?
- Are there any compliance requirements?
- What security controls are implemented?
- How do these mitigations address the identified threats?
Describe alternative approaches you considered and why you chose the proposed solution:
- Description
- Pros
- Cons
- Why not chosen
- Description
- Pros
- Cons
- Why not chosen
- Is this change backward compatible?
- If not, what is the migration path?
- Are there any deprecation timelines?
- How does this design accommodate future changes?
- Are there extensibility points?
Outline the implementation approach:
- Task 1
- Task 2
- Task 3
- Task 4
List any dependencies on other work or external factors.
Describe how this feature will be tested:
- Unit tests
- Integration tests
- End-to-end tests
- Performance tests
- Security tests
What documentation needs to be created or updated?
- User documentation
- API documentation
- Architecture documentation
- Runbooks or operational guides
List any unresolved questions that need to be addressed during the review:
- Question 1
- Question 2
- Link to relevant documentation
- Link to related RFCs or proposals
- Link to external specifications or standards
| Date | Reviewer | Decision | Notes |
|---|---|---|---|
| YYYY-MM-DD | @reviewer | Under Review | Initial submission |
| Repository | PR | Status |
|---|---|---|
| toolhive | #XXXX | Merged |