[WIP] Implement next roadmap feature with production quality

[Copilot]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

Original prompt

You are acting as a senior engineer working inside THIS repository. Your mission is to implement the next roadmap feature safely and completely, with production-grade quality.

SCOPE RULE:

“Next feature” MUST be determined from ROADMAP.md or other repo planning sources (docs/, /planning, Issues, Milestones). Use the repo’s explicit ordering/priority markers (“Next”, “Now”, milestone order, top unchecked item). If multiple candidates exist, choose the smallest clearly-next increment and justify the selection.
NON-NEGOTIABLE WORKFLOW (do not skip steps):

Repo Scan (read-only, before any edits)

Identify: stack, build system, test runner, lint/format rules, CI expectations, folder conventions, architecture patterns.
Locate planning sources: ROADMAP.md, docs/, issues, milestones, /planning, ADRs.
Identify the “next feature” strictly by ordering. Quote/point to the exact roadmap line or planning reference you used.
Assumptions (MUST be listed before coding)

List every assumption you must make (numbered, minimal).
If a missing detail could cause the wrong behavior/security posture, implement the smallest SAFE version and mark the gap as a follow-up.
Acceptance Criteria (MUST be explicit, before coding) Convert the roadmap item into acceptance criteria:

User-visible behavior (UX flows, UI states, copy if relevant)
API/DB behavior (contracts, migrations, backward compatibility)
Error states (validation failures, timeouts, offline, partial failures)
Observability (logs/metrics/traces patterns used in repo)
Security invariants (authn/authz, input validation, secrets handling, least privilege)
Implementation Considerations (MUST be written before coding) Write a concise, repo-specific section addressing:

Architecture fit: where this belongs in the existing modules/layers
Data model considerations: schema changes, migrations, defaults, indexing, rollback strategy
Integration points: external APIs, feature flags, config, environment variables
Edge cases: concurrency, idempotency, retries, partial failure handling
Compatibility: versioning strategy, backward compatibility, deprecation notes
Developer ergonomics: maintainability, testability, naming conventions, dependency boundaries
Performance & Security Notes (MUST be written before coding)

Performance:
Identify likely hot paths (DB queries, network calls, render loops, large payloads)
Plan mitigation (pagination, caching, batching, avoiding N+1, debouncing, streaming where relevant)
Define a “good enough” performance target appropriate to repo context
Security:
Threat model for this feature (at minimum: authz boundaries, input trust boundaries, injection/XSS/CSRF as applicable)
Required controls (validation, encoding, rate limits/throttling patterns used in repo, secure defaults)
Secrets handling: never log secrets, never commit secrets; use existing secret/config approach
Plan (short, before edits)

Files/modules to touch
New components/endpoints/schemas
Migration strategy (if DB changes) + rollback steps
Test plan: unit/integration/e2e + how to run locally
Release plan: feature flagging or phased rollout if the repo uses it
Implement (edits begin here)

Implement end-to-end (frontend/backend as needed).
Follow existing patterns, naming, formatting, and code style.
Avoid drive-by refactors. Only refactor when it directly improves feature correctness/maintainability.
Add robust error handling: typed guards, validation, safe defaults, timeouts, retries only where appropriate.
Do not introduce new dependencies unless clearly justified; if added, document and update lockfiles.
Refactor (only if necessary)

Refactor only what’s tightly coupled to the feature or clearly broken.
Do not change behavior outside scope unless required; if behavior changes, document and add tests.
Tests + Debug (MUST be thorough) Add/extend tests covering:

Happy path
Edge cases and boundary conditions
Negative/error paths
Security-relevant cases (authz boundaries, injection/XSS/CSRF/SSRF where relevant) Ensure:
Full test suite passes
Lint/format passes
CI expectations are met (align config/scripts)
Documentation (MUST be updated)

Update canonical docs for this repo: README, /docs, inline comments, ADRs (as applicable).
Update API docs (OpenAPI/Swagger/etc.) if endpoints/contracts changed.
Add/Update a “How to verify” section with exact commands + expected outcomes.
Final Output (MUST include all sections below) A) Summary of changes (what/why, scoped) B) Changelog entry in Keep a Changelog style under “Unreleased”:

Added / Changed / Fixed / Security C) How to run tests + how to manually verify (commands + expected results) D) Assumptions (restate) + follow-up tasks discovered E) Implementation Considerations (final, updated if plan changed during implementation) F) Performance & Security Notes (final, updated with what you actually did) G) Recommended Next Steps (MUST be actionable)
RECOMMENDED NEXT STEPS (MANDATORY CONTENT REQUIREMENTS)

Provide 5–10 concrete next steps, prioritized...

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

---

Summary by cubic

Sets up the plan to build the next roadmap feature with production quality. Adds acceptance criteria, assumptions, implementation notes, performance/security considerations, a test plan, and manual verification steps to ensure a safe rollout.

^{Written for commit 3192054. Summary will update on new commits.}

[Copilot]

Copilot wasn't able to review any files in this pull request.

[qodo-code-review]

ⓘ Your approaching your monthly quota for Qodo. Upgrade your plan

PR Code Suggestions ✨

No code suggestions found for the PR.