feat(dataset): delete pushed data (dataset rm) [needs design]

[aptracebloc]

Status: tracking / needs design. Detailed scope to be added after Phases 1–4 land — this captures the intent + the open design question so it isn't lost.

Goal

Expose a command to delete data a previous dataset push created — the inverse of push. Already anticipated in code (newDatasetCmd doc: "Future verbs (dataset list, dataset rm) hang off this parent in v0.2.").

What a push creates (so what delete must tear down)

1. MySQL table — training_test_datasets.<table>.
2. PVC files — /data/shared/<table> (final dest) + any /data/shared/.tracebloc-staging/<table> leftovers.
3. Central backend catalog entry — the "edge label metadata" the ingestor syncs.

Open design question (why this needs its own pass)

• CLI-direct teardown — mint token → ephemeral pod that drops the table + rms the PVC dir (mirrors the stage-pod pattern), plus a backend API call to remove the catalog entry. No server change, but the CLI owns destructive cluster ops.
• vs. a jobs-manager delete-ingestion endpoint — mirrors submit-ingestion-run; keeps destructive logic server-side and is cleaner, but needs new work in tracebloc/client + tracebloc/data-ingestors (cross-repo coordination).

Likely shape (subject to the design pass)

• tracebloc dataset rm <table> with --dry-run (show exactly what would be deleted), interactive confirmation (Phase 3), --yes/--force, and a before/after summary (Phases 1–2).
• Probably pairs with a dataset list to see what's deletable.

Acceptance criteria (this issue)

• Design decision recorded (CLI-direct vs server endpoint) + any cross-repo issues filed.
• Detailed scope + acceptance criteria appended here, then implementation issue(s) split out.

Notes

• Destructive → leans on the interactive-confirm (#PHASE3) + summary (#PHASE1/#PHASE2) foundation, which is why it's sequenced after the first batch.

Part of the UX/interactive epic.

🤖 Generated with Claude Code