update roadmap

docs/peps/PEP-TEMPLATE.md

@@ -0,0 +1,171 @@
+# PEP-XXXX: Title
+
+<!--
+Instructions:
+1. Copy this file to PEP-XXXX-short-title.md (pick the next available number)
+2. Fill in all sections below
+3. Submit as a PR to docs/peps/
+4. Delete these instructions before submitting
+-->
+
+| Field | Value |
+|---|---|
+| **PEP** | XXXX |
+| **Title** | |
+| **Status** | Draft |
+| **Author(s)** | Name (@github-handle) |
+| **Sponsor** | _(required for non-maintainers)_ |
+| **Created** | YYYY-MM-DD |
+| **Tracking Issue** | _(filled after acceptance)_ |
+| **Target Release** | _(filled after acceptance)_ |
+
+## Summary
+
+<!--
+One paragraph. What is this proposal, and why should someone care?
+A reader should be able to decide whether to keep reading from this section alone.
+-->
+
+## Motivation
+
+<!--
+Why is this change needed? What problem does it solve? Who benefits?
+Include concrete examples or user stories where possible.
+Link to GitHub issues, Discord discussions, or community meeting notes that motivated this proposal.
+-->
+
+### Goals
+
+<!--
+Bulleted list of what this PEP aims to achieve.
+-->
+
+### Non-Goals
+
+<!--
+Bulleted list of what this PEP explicitly does NOT aim to achieve.
+Being clear about scope prevents scope creep during review and implementation.
+-->
+
+## Design
+
+<!--
+The core of the proposal. Describe the technical design in enough detail that:
+1. Someone familiar with the codebase could implement it
+2. Someone unfamiliar could understand the approach and trade-offs
+
+Structure this section however makes sense for your proposal. Common subsections:
+-->
+
+### User-Facing Configuration
+
+<!--
+If this feature involves configuration changes, show the YAML that users would write.
+Include a complete, working example — not pseudocode.
+-->
+
+```yaml
+# Example configuration
+```
+
+### Architecture
+
+<!--
+How does this fit into Plano's existing architecture?
+Which crates/components are affected? What's the data flow?
+Diagrams are welcome (use Mermaid or link to an image).
+-->
+
+### API Changes
+
+<!--
+Any new or changed HTTP endpoints, headers, or response formats.
+-->
+
+### Behavior
+
+<!--
+Describe the runtime behavior in detail.
+What happens on the happy path? What happens on errors?
+How does this interact with existing features (routing, streaming, tracing, etc.)?
+-->
+
+## Alternatives Considered
+
+<!--
+What other approaches did you evaluate? Why did you choose this design over them?
+This section demonstrates thoroughness and helps reviewers understand the design space.
+
+For each alternative:
+- Brief description of the approach
+- Why it was rejected (trade-offs, complexity, limitations)
+-->
+
+## Compatibility
+
+<!--
+Does this change break any existing behavior? If so:
+- What breaks?
+- What's the migration path?
+- Should there be a deprecation period?
+
+If this is purely additive, say so explicitly.
+-->
+
+## Observability
+
+<!--
+How will operators know this feature is working correctly?
+- New metrics, traces, or log entries?
+- Integration with existing Agentic Signals?
+- Dashboard or alerting recommendations?
+-->
+
+## Security Considerations
+
+<!--
+Does this change affect Plano's security posture?
+- New attack surfaces?
+- Authentication/authorization implications?
+- Data handling (PII, credentials, etc.)?
+
+If not applicable, briefly explain why.
+-->
+
+## Test Plan
+
+<!--
+How will this be tested?
+- Unit tests (which crates?)
+- Integration tests
+- E2E tests (new demo or test scenario?)
+- Performance/load testing considerations
+
+Be specific enough that a reviewer can evaluate coverage.
+-->
+
+## Implementation Plan
+
+<!--
+How will this be implemented? Suggested breakdown:
+- Phases or PRs (if the work is large enough to split)
+- Which crates/files are primarily affected
+- Estimated complexity (small / medium / large)
+- Any dependencies on other work
+-->
+
+## Open Questions
+
+<!--
+Unresolved design questions that you'd like feedback on during review.
+Number them so reviewers can reference specific questions.
+
+Remove this section (or mark all as resolved) before the PEP is accepted.
+-->
+
+## References
+
+<!--
+Links to related GitHub issues, discussions, external documentation,
+research papers, or prior art in other projects.
+-->