v0.5.1 — Deletion, cascade safety & audit trail
Every core entity in CodePlans can now be deleted safely: consistent confirmation with blast-radius disclosure in the UI, matching delete tools in the MCP API, a real audit trail behind every mutation, and role-based authorization — so deleting something you don't own or didn't create isn't just discouraged by the UI, it's actually blocked, identically, whether the request comes from a person clicking a button or an agent calling a tool.
What's new
- MCP delete tools:
delete_task,delete_work_item,delete_code_plan,delete_release— each returns the affected-row counts (unlinked plans, detached assets, etc.) so an agent caller isn't surprised by a cascade it can't see. - Confirmation everywhere: wired the previously dead-code
deleteCodePlanAction/deleteReleaseActioninto real UI buttons, and added confirmation dialogs to every join/edge removal (asset dependencies, plan-asset targets, release-plan/asset links) that had none before. Every confirm dialog states what else will be affected, not just "are you sure?" - Centralized audit log: every mutation — create, update, delete — now writes to the activity log from one shared place in the mutation layer, so both the web UI and MCP tools are covered automatically. Previously only one code path (WorkItem delete) logged anything, and MCP had zero audit coverage at all.
- Standardized attribution:
createdBy/updatedBynow exist on tasks, products, organizations, and the join tables that lacked them, plus a data migration backfilling attribution on existing rows (from already-reliable legacy fields where available; an explicit org-owner approximation only where nothing else exists, for tasks). - Delete authorization: a new shared library (
lib/db/authz.ts) enforces one rule everywhere — an org owner or admin can delete anything in their org; everyone else can only delete what they created or what's assigned to them. - Fixed a privilege-escalation bug: role-change actions had no server-side authorization check at all — any org member could promote themselves to owner/admin. Now gated to the organization's actual owner.
Upgrading
Run pnpm db:migrate before deploying to apply two additive migrations: attribution columns (0019) and a one-time backfill of created_by_id for existing rows (0020, data-only, no schema change). Both were verified against a real, previously-unmigrated, populated database — not just a fresh schema.
pnpm install --frozen-lockfile
pnpm db:migrateValidation
270 tests passing (30 new this release), pnpm build, and a disposable real-data migration/backfill verification (confirmed 100% accurate attribution backfill, no foreign-key violations).
Implemented across #60–#68, version-tagged in #69.
Full changelog: v0.5.0...v0.5.1