// Deactivates a user — sets `deactivatedAt` with a normal update. The user's
// row stays in the table and remains visible to queries; the convention is
// that your auth layer refuses to authenticate a subject whose `deactivatedAt`
// is set. (Contrast softDelete(), which hides + anonymises the row.)

import { defineMutation } from '@voltro/protocol'
import { Schema } from 'effect'

export const deactivateUser = defineMutation({
  name: 'users.deactivate',
  target: { table: 'users', op: 'update' },
  // Stamps `deactivatedAt` on a caller-named row. Open only because the table
  // is this demo's own output (no seed, one writer, no tenant scope) — the
  // decision itself is "anyone may lock anyone out", which is precisely the
  // shape you must NOT ship. This is the first procedure in this template to
  // grow a `guards: [{ scope: 'users:admin' }]` once an auth strategy gives you
  // a caller to name.
  openAccess:
    'flips `deactivatedAt` on a caller-named row of the demo `users` table — reversible, and '
    + 'the table holds only rows this same open surface created. An account-locking action: '
    + 'guard it in the same change that adds authentication.',
  input: Schema.Struct({ id: Schema.String }),
  output: Schema.Struct({
    id: Schema.String,
    email: Schema.String,
    name: Schema.String,
    deactivatedAt: Schema.NullOr(Schema.Date),
  }),
})