Clarify missing feature requirements before implementation

[Copilot]

The problem statement is a template with unfilled placeholders (<FEATURE NAME>, <criterion 1-3>, <explicit list>). Per Rule #1: "Do not guess. If anything is ambiguous, ask up to 5 targeted questions and WAIT."

Blocked on Requirements

5 Questions requiring answers:

1. Feature name - What specific feature should be built?
2. User outcome - What is the 1-2 sentence user-visible outcome?
3. Acceptance criteria - What are the 3-5 specific, testable criteria?
4. In scope - What is explicitly included?
5. Out of scope - What is explicitly excluded?

Repository Context

• Stack: React 18, Vite 6, TailwindCSS, Base44 SDK
• Commands: npm run build, npm run lint, npm run dev
• Phase: Q1 2025 - Security hardening, testing infrastructure

Next Steps

Once requirements are clarified:

• Context scan (identify patterns, constraints)
• Implementation plan
• Code + tests + docs
• Security review (CodeQL)
• Final verification

Status: Awaiting requirements to proceed.

Original prompt

🚀 Copilot Coding Agent — One-Shot Feature-to-PR (GitHub.com)

You are the GitHub.com Copilot CODING AGENT. Execute this end-to-end as ONE coherent PR.

Mission

Build:
Outcome: <1–2 sentence description of the user-visible outcome>

Non-Negotiable Rules

1. Do not guess. If anything is ambiguous, ask up to 5 targeted questions in an issue comment and WAIT.
2. One PR only. Keep diffs reviewable; smallest blast radius possible.
3. Follow repo guardrails in this order:
   • .github/copilot-instructions.md
   • .github/instructions/*.instructions.md that apply to touched paths
   • README.md + relevant docs/*
4. Definition of Done includes: code + tests + docs + edge cases + security + (if applicable) analytics/observability + governance updates.
5. No secrets / no PII. Redact tokens and sensitive fields in logs/events; never hardcode credentials.
6. Server-side authZ. Any write path must enforce authorization on the server, not just UI.

Acceptance Criteria (must be demonstrably met)

Functional

• <criterion 1>
• <criterion 2>
• <criterion 3>

Edge Cases / Reliability

• Handles null/empty inputs, boundary values, invalid states
• Proper error handling (no silent failures)
• Retries/timeouts/backoff where applicable
• Idempotency / concurrency safety where applicable

Security

• Input validation at trust boundaries
• AuthN/AuthZ enforced for any protected operation
• No secret leakage; no PII in logs/events
• Dependency risk assessed (no new vulnerable deps; justify if added)

Analytics / Observability (if applicable)

• Uses existing repo logging/metrics/tracing patterns
• Emits structured events for key actions
• Documents event catalog (names, fields, redaction rules)

Governance / Documentation

• Updates docs (README and/or docs/*) to reflect behavior and usage
• Adds/updates ADR if architecture meaningfully changes
• Updates CHANGELOG/release notes if present and user-visible behavior changes

Quality Gates

• Unit tests added/updated for success + failure paths
• Integration/e2e tests added/updated if the repo uses them
• Build/lint/typecheck/test passes in CI

Required Workflow (follow exactly)

Step 0 — Context Scan (must do first)

• Identify build/test/lint commands from repo config
• Identify existing patterns for: auth, validation, errors, logging, analytics
• Identify closest existing feature/module to mirror
• Identify any constraints from CI/workflows/rulesets

Step 1 — Plan (post before major edits)

Post a brief plan including:

• Files to change (list)
• New modules/components (if any)
• Test plan (what you’ll add and what it proves)
• Rollback plan (how to revert safely)

Step 2 — Implement

• Make minimal, cohesive changes
• Keep code modular and typed (if stack supports)
• Add robust error handling and defensive checks

Step 3 — Tests

• Add/extend tests for criteria + edge cases
• Ensure deterministic tests (no flaky time/network dependency)

Step 4 — Docs + Governance

• Update docs and (if needed) ADR / security notes / runbooks

Step 5 — Final PR Description (must include)

In the PR description include:

• Summary of changes
• Files changed
• Verification commands + expected output
• Security review notes (CodeQL/deps/secret scanning status if visible)
• Risk assessment + mitigations

Scope Controls

In scope

Out of scope

Technical Notes / Constraints (fill if known; otherwise discover in Step 0)

• Runtime / language:
• Frameworks:
• Auth model:
• Data model / DB:
• Observability stack:
• Performance constraints:
• Backward compatibility requirements:

Start Now

Begin with Step 0. If ambiguous, ask questions. Otherwise, proceed to Step 1 plan, then implement and open the PR.

---

💡 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

Kick off development of a new user-visible feature by adding the initial implementation plan; no functional code or user-facing changes yet.

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

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Copilot]

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