EV data feedback reports: users submit corrections/missing info (with spec-path selection) + GitHub issue workflow

[TheTechArch]

Goal

Let logged-in users submit structured feedback about EVKX EV data: errors/corrections, missing information, or both. Feedback should be tied to a specific EV model/variant and ideally a specific specification field. Admins can review, resolve, and optionally push the feedback into GitHub issues for tracking and implementation.

Why

• Improve data quality with community input while keeping editorial control.
• Make feedback actionable (structured + evidence).
• Create a transparent pipeline from “user report” → “fixed” via GitHub.

---

Naming options (pick later)

• Data Feedback
• EV Data Correction
• Report a Data Issue
• Suggest an Update
• EV Spec Feedback

---

User submission flow (logged in)

Required selections

1. EV selection

• Model + variant (based on EVKX structure)

2. Area

• Battery / Range & charging
• Performance
• Drivetrain (suspension/brakes/steering)
• Exterior
• Interior
• UI & controls
• Infotainment
• Lighting
• ADAS
• Cargo/towing
• Pricing/availability (optional)
• Other

3. Feedback type

• Correction (something is wrong)
• Missing info (something is absent)
• Both

Specification field selection

Let the user select the exact spec that is wrong/missing:

• UI provides a searchable dropdown/tree of specs for that EV (human labels)
• Store the underlying spec path (e.g. /battery.capacityNominalKWh, /charge.dc.maxPowerKw, etc.)
• Allow selecting multiple fields (optional), or one primary field + additional fields.

Feedback content

• “What’s wrong / what should it be?”

• Proposed value(s) (optional structured input depending on field type)

• Source / evidence:

  • Attachments (uses Community attachments system: images + PDF)
  • Links (official docs, reviews, forum posts)

• Optional metadata:

  • Region (EU/US/CN etc.)
  • Model year
  • Software version (if relevant)
  • Confidence: “I measured it”, “from manual”, “from press release”, etc.

After submit

• User sees status and can view their submitted feedback history.

---

Admin/review workflow

States

• New
• Needs info (request more from user)
• Accepted (actionable)
• Rejected (not correct / not verifiable)
• Duplicate (link to existing)
• Implemented (data updated)
• Published (optional: shown as “fixed thanks to …”)

Admin actions

• Comment back to user (request more details)
• Edit internal notes
• Map to spec paths (if user didn’t)
• Link to EV issue tracker entry (optional)
• Convert to GitHub issue or link to existing GH issue
• Mark resolved + optionally record what changed

---

GitHub integration (tracking)

Two options (support one first):

Option A: Manual “Create GitHub issue” button (preferred)

• Admin clicks “Create GitHub issue”

• Generates a prefilled GH issue title/body:

  • EV + variant
  • Spec path(s)
  • Current value (snapshot)
  • Suggested value
  • Evidence links/attachments references
  • User report id for traceability

• Store returned GitHub issue URL/id on the feedback report.

Option B: Automatic creation rules (later)

• Auto-create GH issue when admin sets status to “Accepted”

Note: If you don’t want API integration yet, still implement fields:

• githubIssueUrl (nullable)
• “Copy as GitHub issue markdown” button

---

Acceptance criteria

• Logged-in users can submit feedback tied to a specific EV model/variant.
• Users must select an area and feedback type (correction/missing/both).
• Users can select at least one specification field via UI and it stores a stable spec-path.
• Users can attach images/PDF evidence (using the shared attachment system).
• Admin can review feedback, change status, and respond with comments.
• Admin can create/link a GitHub issue and store the URL on the feedback report.
• Feedback items are searchable/filterable by model, area, status, and feedback type.
• Duplicate handling exists (mark as duplicate and link to original).

---

Suggested data model

EvDataFeedbackReport

• id (GUID)
• createdByUserId
• evModelId, evVariantId?
• area (enum)
• type (Correction | MissingInfo | Both)
• title (short summary)
• description (long)
• status (enum as above)
• country?, modelYear?, softwareVersion?
• adminNotes?
• githubIssueUrl?
• createdAt, updatedAt

EvDataFeedbackSpecRef

• id
• feedbackReportId
• specPath (string, e.g. /battery...)
• label (what user saw in UI)
• currentValueSnapshot? (string/json)
• suggestedValue? (string/json)

EvDataFeedbackComment

• id
• feedbackReportId
• authorUserId (user or admin)
• message
• createdAt

Attachments use CommunityAttachment with:

• ownerType = DataFeedbackReport
• ownerId = feedbackReportId

---

UI requirements

• “Report data issue” entry points:

  • On EV model page (“Report an error / suggest missing info”)
  • On spec pages/sections (preselect area and spec path)

• Spec selector:

  • searchable list grouped by area
  • shows current value to reduce noise (“EVKX says: 77.4 kWh”)

• User dashboard:

  • “My feedback reports” list with statuses

---

Tasks

Backend

• Schema + migrations (reports, spec refs, comments)
• CRUD endpoints for user submissions + list “my reports”
• Admin endpoints for moderation/status updates/comments
• Attachments wiring (ownerType DataFeedbackReport)
• Store GitHub issue URL + audit log

Frontend

• Feedback report form (EV selection, area, type, spec selector, details, attachments)
• Admin review UI (filters, detail view, status + comments + GitHub link/create)
• User “My feedback” page

GitHub workflow

• “Copy as GitHub issue” markdown generator (minimum)
• (Optional) Direct GitHub API integration to create issue + store URL

---

Extra features (nice to have)

• Duplicate suggestions (based on same EV + spec path + similar title)
• Reputation/quality signals (“verified contributor” later)
• Public “Changelog: fixed thanks to community” feed