feat: Todo MVP — REST API, in-memory store, and vanilla JS frontend

[algorithm-conduction]

Summary

Implements the Todo MVP as described in the OpenSpec change proposal. The app exposes a four-endpoint REST API backed by an in-memory store, served alongside a vanilla HTML/JS single-page frontend. No database or authentication is required for this MVP. All files carry EUPL-1.2 license headers per Conduction B.V. conventions.

Spec Reference

https://github.com/algorithm-conduction/todo-app/blob/hydra/spec/openspec/design.md

Changes

• package.json — project manifest; declares express as runtime dep, supertest + vitest as dev deps; sets type:module for ESM
• src/store.js — in-memory todo store with list, create, update, remove, and reset exports
• src/server.js — Express app wiring GET/POST/PATCH/DELETE on /api/todos; exported for testing, self-starts when run directly
• public/index.html — vanilla JS SPA that fetches from the API; supports add, toggle-complete, and delete
• test/api.test.js — integration tests using supertest + vitest covering all four spec scenarios

Test Coverage

• test/api.test.js — POST /api/todos returns 201 with id/title/completed:false
• test/api.test.js — GET /api/todos returns 200 and array containing created todo
• test/api.test.js — PATCH /api/todos/:id marks todo completed, returns 200
• test/api.test.js — PATCH /api/todos/:id returns 404 for unknown id
• test/api.test.js — DELETE /api/todos/:id returns 204
• test/api.test.js — todo absent from GET list after deletion
• test/api.test.js — DELETE /api/todos/:id returns 404 for unknown id

[clydebarcode-conduction]

[WARNING] Mass Assignment — Unfiltered PATCH body applied to todo object
Tool: Manual review (Semgrep, Gitleaks, Trivy returned 0 findings)
Rule: OWASP A03:2021 – Injection / Mass Assignment
File: src/store.js:20 (also src/server.js:31)
Issue: The PATCH /api/todos/:id handler forwards req.body directly into Object.assign(todo, fields) with no field whitelist. A caller can overwrite the internal id field, breaking the in-memory store's referential integrity. Any future sensitive field added to the todo model (e.g. owner, role) would be immediately writable by untrusted clients without any code change.
Fix: Whitelist the accepted mutable fields before the assign:

const { title, completed } = fields;
const allowed = {};
if (title !== undefined) allowed.title = title;
if (completed !== undefined) allowed.completed = !!completed;
Object.assign(todo, allowed);

[clydebarcode-conduction]

[SUGGESTION] Missing HTTP security headers
Tool: Manual review
Rule: OWASP A05:2021 – Security Misconfiguration
File: src/server.js:12
Issue: The Express application sets no security-related HTTP response headers. Without X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Content-Security-Policy, and Referrer-Policy, the application is exposed to MIME-type sniffing, clickjacking, and data leakage via Referer headers.
Fix: Add the helmet package and mount it before other middleware:

import helmet from 'helmet';
app.use(helmet());

This sets all recommended security headers with safe defaults in a single line.

[juanclaude-conduction]

[CRITICAL] PATCH endpoint allows mass-assignment — spec deviation
File: src/server.js:31
Issue: update(id, req.body) passes the raw request body directly to Object.assign(todo, fields) in the store. The spec defines PATCH as accepting only { completed: boolean }, but any client can currently send { id: 99 } to overwrite the todo ID, or { title: "hijacked" } to silently rewrite the title, or inject arbitrary keys onto the object. This is a correctness violation against the OpenSpec design.
Fix: Destructure only the permitted field before calling update. In server.js PATCH handler, replace update(id, req.body) with update(id, { completed: req.body.completed }). Optionally validate that typeof req.body.completed === 'boolean' and return 400 otherwise.

[clydebarcode-conduction]

[SUGGESTION] No authentication or authorization on any API endpoint
Tool: Manual review
Rule: OWASP A01:2021 – Broken Access Control
File: src/server.js:16–41
Issue: All four REST endpoints (GET, POST, PATCH, DELETE /api/todos) are accessible to any client with network reachability, with no session, token, or identity check. In its current in-memory-only form the blast radius is limited to the server process lifetime, but if persistence is added this becomes a data-integrity risk.
Fix: For an MVP, adding a static bearer token check via middleware is sufficient. For production, integrate a proper auth layer (e.g. JWT, OAuth2, or session cookies with CSRF protection).

[juanclaude-conduction]

[CRITICAL] package.json missing EUPL-1.2 license declaration
File: package.json
Issue: package.json is a newly introduced file. The spec and Conduction B.V. conventions require EUPL-1.2 headers on all new files. JSON cannot carry SPDX comment headers; the canonical equivalent for an npm manifest is the "license" field. It is absent. Without it, the licensing status of the package is ambiguous.
Fix: Add "license": "EUPL-1.2" to package.json (e.g., after the "description" field).

[clydebarcode-conduction]

Tool scan summary (Semgrep · Gitleaks · Trivy)

Tool	Findings
Semgrep (p/security-audit, p/secrets, p/owasp-top-ten)	0 findings
Gitleaks	0 findings
Trivy	not present

No automated findings to triage. The WARNING and SUGGESTIONs above are from manual review of the diff.

[FALSE POSITIVE] — N/A: no Semgrep or Gitleaks findings were raised.

[juanclaude-conduction]

[WARNING] No ESLint (lint) script defined in package.json
File: package.json
Issue: There is no "lint" script in package.json. The project is TypeScript-adjacent (ESM modules, modern JS) and has no automated style/lint enforcement. Without a lint gate, style drift and potential logic errors (e.g., unused imports, implicit coercions) will not be caught in CI.
Fix: Add ESLint to devDependencies and define "lint": "eslint src test" in the scripts block. A minimal .eslintrc.json with "env": { "node": true } and "parserOptions": { "ecmaVersion": 2022, "sourceType": "module" } is sufficient.

[clydebarcode-conduction]

{ "pass": true, "blocking": [] }

Verdict: PASS — No critical or blocking security issues found.

The mass-assignment WARNING (src/store.js:20) should be addressed before this service handles multi-tenant or persistent data, but it is not blocking for an in-memory MVP. The two SUGGESTIONs (security headers, authentication) are standard hardening steps for any path toward production.

[juanclaude-conduction]

[WARNING] Unused import createRequire in src/server.js
File: src/server.js:5
Issue: import { createRequire } from 'module'; is present but createRequire is never referenced anywhere in the file. Dead imports add noise, confuse readers into thinking CJS interop is happening, and would be caught by a linter.
Fix: Remove line 5 (import { createRequire } from 'module';).

[juanclaude-conduction]

[SUGGESTION] No error handling in frontend async fetch calls
File: public/index.html:58-80
Issue: toggle(), deleteTodo(), and the form submit handler all await fetch(...) without checking res.ok or catching network errors. A failed PATCH or DELETE will silently call load() anyway, leaving the UI in a potentially stale/inconsistent state with no feedback to the user.
Fix: For each fetch call, check res.ok before proceeding (e.g., if (!res.ok) { alert('Operation failed'); return; }), or wrap in a try/catch. For an MVP this is optional, but even a console.error on failure would help debugging.

[juanclaude-conduction]

{ "pass": false, "blocking": ["PATCH endpoint allows mass-assignment of arbitrary todo fields — spec only permits { completed: boolean } (src/server.js:31)", "package.json missing EUPL-1.2 license declaration (no "license" field)"] }