Initialize a backend + frontend monorepo layout with build tooling so an AI
agent can develop the app incrementally.

Acceptance contract (checked by automated probes):

• A README.md at the repo root that documents how to run the app; the words
  "backend" and "frontend" must both appear in it.
• An agent guide at backend/AGENTS.md and another at frontend/AGENTS.md.
• An AGENTS.md at the repo root describing the stack (languages,
  frameworks, layout) and carrying the commands kept in session memory:
  a run: line (the command that runs the app) and a test: line (the
  command that runs the tests). Memory is re-read after every completed
  task.

Define the flower pot entity (id, name, species, watering_interval_hours,
last_watered_at) persisted in a SQLite database, with a schema/migration
file defining the pots table.

Acceptance contract (checked by automated probes): the SQL file must sit at
one of these exact paths — backend/schema.sql, backend/db/schema.sql,
backend/migrations/001_pots.sql, backend/sql/schema.sql, or
backend/src/schema.sql. It must CREATE TABLE pots with the columns listed
above and be valid SQLite DDL (sqlite3 applies it to an empty database).
The implementation language of the app is otherwise unconstrained here, but
note that later tasks boot the backend via npm.

Expose POST /api/pots to create, GET /api/pots and GET /api/pots/:id to
read, PUT/PATCH /api/pots/:id to update, and DELETE /api/pots/:id to
remove, backed by the SQLite pot store.

Acceptance contract (checked by automated probes):

• The backend is Node-based and starts with
  npm --prefix backend run dev -- --port <port> — the probes choose the
  port and expect the server to be listening within ~3 seconds.
• POST /api/pots accepts JSON {name, species, watering_interval_hours,
  last_watered_at?} and returns HTTP 201 (or 200) with the created pot as
  JSON, including its id.
• GET /api/pots returns a JSON array of pots (or {"pots": [...]}), each
  carrying id and name.
• PUT /api/pots/:id accepts partial updates of name,
  watering_interval_hours and last_watered_at.
• GET/PUT/DELETE on an unknown id must return 404; DELETE on an existing
  pot returns 204 (or 200).

Compute which pots are due for watering based on last_watered_at and
watering_interval_hours, and expose the result via GET /api/notifications.

Acceptance contract (checked by automated probes): a pot is due when
last_watered_at + watering_interval_hours is in the past. GET
/api/notifications returns HTTP 200 with JSON that includes each due pot's
name and omits pots that are not due. POST /api/pots must honour a
last_watered_at timestamp supplied by the caller (the probes create both an
overdue and a freshly watered pot this way). Backend boots the same way as
in the previous task.

Render a list of flower pots with a form to add a new pot and a remove
control per pot, talking to the backend REST API.

Acceptance contract (checked by automated probes):

• The frontend starts with npm --prefix frontend run dev -- --port <port>.
  The probes export BACKEND_PORT (and VITE_BACKEND_PORT) with the backend's
  port — read it in your dev-server config and proxy /api requests to
  http://localhost:$BACKEND_PORT (or call that origin directly with CORS
  enabled on the backend).
• The UI is driven through the accessibility tree by a headless browser:
  the pot-name field must be the FIRST text input on the root page and the
  form submit the FIRST button. Submitting with only the name filled must
  create a pot (other fields may default).
• Each pot row renders the pot's name, and the row's remove control is the
  first button that appears after the name in the accessibility tree.

Show a notifications panel listing pots that are due for watering,
refreshed from GET /api/notifications.

Acceptance contract (checked by automated probes): the panel lives on the
root page and its root element has id="notifications" — the probes read
the panel's text through that selector. After a page load/reload the panel
shows the names of due pots; pots that are not due must not appear inside
the panel (they may still appear in the pot list from the earlier task).
Backend and frontend boot the same way as in the earlier tasks
(npm --prefix <workspace> run dev -- --port <port>, with BACKEND_PORT /
VITE_BACKEND_PORT exported to the frontend).

Verify the full backend + frontend stack runs end to end: pots can be added
through the UI, due watering reminders surface in the notifications panel,
and removing a pot clears it from the UI.

Same startup and UI contract as the earlier tasks (npm dev servers with
--port, BACKEND_PORT exported to the frontend, accessibility-tree driven
UI, notifications panel rooted at id="notifications"). Additionally,
PUT /api/pots/:id must accept a last_watered_at update so the probes can
make the UI-created pot overdue.