[Work Packet]: Add generic test resource CRUD

[juscghwe]

Goal

The application proves a full CRUD flow through the M1 scaffold using a generic, disposable test resource.

This confirms that the stack can perform:

frontend --> backend API --> SQLite --> backend API --> frontend

before medication-domain behavior is added in later milestones.

Suggested branch name

fullstack/add-generic-test-resource-crud

Expected task size

Medium: a few focused sessions

Scope

• Add one generic test resource for CRUD validation
• Use a clearly non-domain resource name:
  • API route: /api/dev-notes
  • SQLite table: dev_notes
• Add a small SQLite table for the test resource
• Add backend API endpoints for basic CRUD
• Add barebone frontend controls to:
  • create a test item
  • list existing test items
  • update a test item
  • delete a test item
• Keep the frontend intentionally simple and disposable
• Use this resource to validate API shape, database access, and frontend / backend integration

Suggested API shape

GET    /api/dev-notes
POST   /api/dev-notes
PUT    /api/dev-notes/:id
DELETE /api/dev-notes/:id

Suggested minimal data shape

{
  "id": 1,
  "text": "Example Note",
  "createdAt": "2026-06-22T18:00:00.000Z",
  "updatedAt": "2026-06-22T18:00:00.000Z"
}

Suggested SQL table

CREATE TABLE IF NOT EXISTS dev_notes (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  text TEXT NOT NULL,
  created_at TEXT NOT NULL,
  updated_at TEXT NOT NULL
);

Explicit non-goals / boundaries

• Do not over-engineer validation, permissions, or error handling yet
• Do not add medication CRUD yet
• Do not add user accounts yet
• Do not add authentication yet
• Do not treat the generic test resource as production domain logic

Files / areas likely affected

• backend/src/db
• backend/src/routes
• backend/src/modules if the test resource gets its own temporary module
• frontend
• CI workflow as CRUD validation is added automatically
• Documentation only if setup or validation steps need clarification

Definition of done

• Generic SQLite table exists or is created on startup
• Backend can create a test resource
• Backend can list test resources
• Backend can update a test resource
• Backend can delete a test resource
• Frontend can trigger all CRUD operations
• Frontend displays current test resources
• Data persists in SQLite across container restarts
• Existing health endpoints still work

Validation

• Start the app through the existing Docker/dev workflow
• Open the frontend in the browser
• Create a test item
• Refresh the page and confirm the item still exists
• Update the item and confirm the changed value is shown
• Delete the item and confirm it disappears
• Restart the container and confirm persistence behavior works as expected
• Call the API endpoints manually with curl or another HTTP client
• CI workflow

Follow-up ideas

• Add automated API tests for the generic CRUD resource
• Add standardized API response shape
• Add standardized error response shape
• Add first real migration runner