Delete an archived task type

Hard-delete a custom task type that the customer wants to recreate with the same key.

When to use this

Customer archived a task type, then asks to add it back with a different display name or baseline. The unique-key partial index allows recreation since the archived row stays out of the active set, but they want a clean UI without the archive entry.
The archived row was a typo/mistake the customer wants to forget existed.

Do not use this if the task type has any events on it (select count(*) from events where task_type_key = '$KEY' and org_id = '$ORG'). The events have a foreign-key style dependency on the key string; deleting the row would orphan them. In that case, leave the row archived and have the customer recreate with a different key.

Steps

const { createClient } = require("@supabase/supabase-js");
const c = createClient(process.env.URL, process.env.KEY);

(async () => {
  const orgId = "...";
  const key = "...";

  // 1. Pre-check: ensure no events depend on this key
  const { count } = await c
    .from("events")
    .select("id", { count: "exact", head: true })
    .eq("org_id", orgId)
    .eq("task_type_key", key);
  if (count && count > 0) {
    console.error(`STOP: ${count} events reference this task type. Aborting.`);
    return;
  }

  // 2. Confirm it is actually archived
  const { data: row } = await c
    .from("task_types")
    .select("id, key, display_name, archived_at")
    .eq("org_id", orgId)
    .eq("key", key)
    .maybeSingle();
  if (!row) {
    console.log("not found");
    return;
  }
  if (!row.archived_at) {
    console.error(`STOP: row exists but is not archived. Use the UI archive flow first.`);
    return;
  }

  // 3. Hard delete
  const { error, count: deleted } = await c
    .from("task_types")
    .delete({ count: "exact" })
    .eq("id", row.id);
  if (error) {
    console.error(error);
    return;
  }
  console.log(`deleted ${deleted} row(s)`);
})();

What stays behind

The audit log entries in task_type_audit_log for the archive action remain. That is intentional: the operational history (who archived this, when) is preserved even when the row itself is gone.
Any task_type_overrides row tied to the deleted key is also removed by the cascade-delete relationship.