Development Issues & Improvements Tracker

The living backlog for NEFOXX. Every issue, observation, technical-debt item, enhancement, security risk, UX inconsistency, performance optimisation, or process improvement identified during development, testing, code review, or user discussions is captured here — so nothing known goes untracked.

This tracker lives in the developer portal (not in src/), so it is version-controlled and reviewed but never shipped in the application build. The backlog data is in Tracker Backlog.

Mandatory lifecycle. Recording, reviewing, and grooming this tracker is a required part of the development lifecycle — see CLAUDE.md → Development Issues & Improvements Tracker (Mandatory). Items are added after confirmation with the user/team, prioritised, and revisited until resolved or consciously deferred. The tracker must never be left stale.

When to add an entry

Whenever any of the following is identified (during a user interaction or development) and confirmed, add a row — don't fix-and-forget or notice-and-move-on:

• A bug or latent defect · a security risk · a performance bottleneck
• Technical debt · an architectural concern · a scalability/reliability gap
• A UI/UX inconsistency · a documentation gap
• A developer-experience friction · a deployment/operational process improvement
• Any enhancement opportunity across product, testing, or tooling

If it is a fast fix you are making right now, still log it (Status → Resolved in the same pass) so the history and verification are captured.

ID convention

NFX-### — zero-padded, monotonically increasing, never reused (e.g. NFX-001, NFX-042). Allocate the next number from the top of the backlog table. IDs are permanent references usable in commits, PRs, code comments, and memory entries.

Field specification

Every entry carries the full field set. The backlog table shows the scan columns; each ID links to a detail block holding the rest.

Field	Required	Notes
ID	✅	NFX-###, permanent.
Date Reported	✅	ISO YYYY-MM-DD.
Reported By / Source	✅	User · Developer · Code Review · Testing · Monitoring · Discussion.
Priority	✅	Critical · High · Medium · Low.
Severity	for bugs	Blast radius if it manifests (Crash/Data-loss · Major · Minor · Cosmetic).
Feature Name	✅	Top-level feature/area (e.g. Zoom Live Classes, Psychology Builder, Platform/EF).
Sub-feature	✅	Specific component/module (e.g. poll panel, crypto.ts).
Issue Type	✅	Bug · Enhancement · Technical Debt · Performance · Security · UI/UX · Documentation · Process Improvement · Architecture · Reliability · Scalability · Testing · Developer Experience.
Domain(s)	optional	Continuous-improvement dimensions this touches (may be several).
Description	✅	What it is; enough context to act without re-investigation.
Impact	✅	Who/what is affected and how badly if left unaddressed.
Proposed Solution / Action Items	✅	Concrete next steps (checklist where useful).
Owner	if applicable	Person accountable, else —.
Effort	optional	S · M · L (or points) — for planning.
Status	✅	Open · In Progress · Blocked · Resolved · Closed · Deferred.
Target Release / Milestone	optional	When it is planned to land, else Backlog.
Related Links	optional	Commits/PRs, migrations, EF names, memory entries, other NFX-###.
Resolution Date	when done	ISO date it moved to Resolved/Closed.
Verification	when done	How the fix was validated (tests run, manual check, metrics).
Last Updated	✅	ISO date of the most recent change to the entry.
Remarks / Notes	optional	Anything else — decisions, deferral rationale, follow-ups.

Status lifecycle

Open ──▶ In Progress ──▶ Resolved ──▶ Closed
  │           │
  ▼           ▼
Deferred    Blocked

• Open — logged, not started. · In Progress — actively being worked. · Blocked — waiting on a dependency (note it in Remarks). · Resolved — fixed + verified, pending final sign-off. · Closed — done and accepted. · Deferred — a conscious decision to postpone (record why + a revisit trigger).

Priority guidance

• Critical — production crash, data loss, security breach, or release blocker. Address immediately.
• High — significant user impact, risk, or debt that will worsen; schedule into the current/next milestone.
• Medium — meaningful improvement; schedule when capacity allows.
• Low — nice-to-have / minor polish; batch opportunistically.

Review cadence (never let it go stale)

• Every working session / PR: log newly-confirmed items; update the status of anything you touched.
• Release planning: review all Open/In Progress/Blocked, (re)prioritise, assign Target Release, and either action or consciously Defer (with a reason) — nothing sits unreviewed.
• Periodic groom: re-validate Deferred items against their revisit trigger; archive Closed items older than a couple of releases into the Resolved/Closed section.

Reporting views

The backlog supports quick slicing by scanning the table columns: by Priority (triage), by Issue Type / Domain (theme reporting — e.g. all Security or all Testing debt), by Feature (readiness of a module), and by Status/Target (release burn-down). Keep the table sorted with Active items first (Critical→Low), Resolved/Closed archived below.