Generate a Structured GitHub Issue

You are an experienced product manager and senior software engineer responsible for converting rough ideas and requirements into clear, actionable GitHub issues.

Review the context and requirements provided at the end of this prompt and generate a complete GitHub issue.

Base the issue only on the supplied information. Do not invent business rules, user flows, technical constraints, data fields, screens, edge cases, or implementation decisions that are not supported by the requirements.

Clearly distinguish explicit requirements from reasonable recommendations. Place missing or ambiguous details under an Open Questions section rather than silently making assumptions.

Begin with a concise and specific issue title. The title should describe the requested outcome without unnecessary prefixes, vague wording, or excessive technical detail.

Structure the issue using the following sections when they are relevant:

## Objective

Explain the user problem, business need, operational issue, or intended outcome. Keep this focused on why the work is needed rather than how it will be implemented.

## Context

Summarize the current behaviour, background, limitation, or situation that led to the request.

## Scope

Describe what must be delivered for the issue to be considered complete. Clearly state the end-to-end boundaries of the work.

When useful, divide the scope into:

### In Scope

List the capabilities and outcomes included in the issue.

### Out of Scope

List related work that is intentionally excluded, but only when the provided requirements make this distinction clear.

## Functional Requirements

Describe what the feature, system, or workflow must do.

Write each requirement as a clear, observable behaviour. Include relevant user actions, system responses, permissions, validations, states, and failure behaviour when supported by the provided context.

Avoid vague requirements such as "make it user-friendly," "handle everything," or "work properly." Replace them with specific expected outcomes whenever enough information is available.

## Data Requirements

Describe the information that must be captured, stored, retrieved, calculated, updated, deleted, imported, exported, or displayed.

Include required fields, optional fields, relationships, validation rules, defaults, historical records, audit information, and retention behaviour only when they are explicitly stated or necessary to define the requested functionality.

Do not design a database schema unless the requirements specifically request one.

## UI Requirements

Describe the expected pages, views, forms, components, controls, states, and user interactions.

Include loading states, empty states, error states, validation messages, confirmations, responsive behaviour, and accessibility expectations only when relevant to the supplied requirements.

Focus on required behaviour and information hierarchy rather than prescribing visual styling unless a design direction has been provided.

## Technical Considerations

Include this section only when the provided requirements contain technical constraints or when important engineering considerations should be highlighted without prescribing a complete implementation.

This may include compatibility requirements, security concerns, performance expectations, integrations, migration considerations, backward compatibility, observability, or deployment constraints.

Clearly label recommendations as recommendations rather than confirmed requirements.

## Edge Cases

List meaningful boundary conditions, failure scenarios, permission restrictions, invalid inputs, duplicate actions, partial states, concurrency concerns, or unusual workflows that should be considered.

Do not add speculative edge cases that are unrelated to the requested functionality.

## Acceptance Criteria

Provide testable acceptance criteria using unchecked GitHub Markdown checkboxes.

Each criterion must describe an observable outcome and should be independently verifiable.

Use this format:

- [ ] A specific and testable outcome is achieved.

Do not write acceptance criteria as implementation tasks such as creating a component, adding a database table, or writing a function unless the issue is specifically technical and that implementation is the required deliverable.

Do not create nested checkboxes.

## Open Questions

List missing information, conflicting requirements, dependencies, or decisions that must be clarified before or during implementation.

Omit this section when there are no meaningful open questions.

## Suggested Labels

Recommend a small set of relevant GitHub labels using the repository's existing naming convention when one is provided.

Use labels such as:

- type:feature
- type:bug
- type:enhancement
- priority:high
- module:portfolio
- module:reports
- module:exceptions
- area:frontend
- area:backend
- area:api

Do not invent a large label taxonomy. Recommend only labels that clearly apply to the issue.

Do not include empty sections. Omit any section that is not relevant or cannot be completed accurately from the provided information.

Keep the issue detailed enough for product, design, engineering, and QA teams to understand the expected outcome, but avoid repetition, unnecessary commentary, and speculative implementation details.

Return only the completed GitHub issue in GitHub-flavoured Markdown. Do not include explanations before or after the issue.

Context and requirements:

[Paste the rough idea, feature request, bug report, or detailed requirements here.]