/**
 * ReviewReason — discriminator for `type: 'review'` WorkItems.
 *
 * Surfaces on the review WorkItem's `metadata.reviewReason` so the TL queue
 * can render context-appropriate UI (red badge on `off_track_kr`, neutral
 * badge on `scheduled_review`, escalation banner on `max_retries_exceeded`).
 *
 * The type was extracted out of `mission-reminder.service.ts` (REVIEW-1)
 * once a second producer (BRIDGE-1) needed to tag review WorkItems with
 * reasons it owns (`max_retries_exceeded`, `task_blocked`). Co-locating the
 * vocabulary at the type layer keeps both producers honest about which
 * reasons exist and avoids per-call-site string drift.
 *
 * @module types/review-reason
 */
/**
 * Enumerated values of {@link ReviewReason} for runtime iteration / validation.
 * Kept in declaration order to mirror the type alias.
 */
export const REVIEW_REASONS = [
    'scheduled_review',
    'off_track_kr',
    'no_active_work',
    'phase_complete',
    'max_retries_exceeded',
    'task_blocked',
];
/**
 * Type guard for {@link ReviewReason}.
 *
 * Validates payloads coming off persisted WorkItems whose `metadata` field is
 * `Record<string, unknown>` — without this guard, downstream UIs and audit
 * tooling would have to cast and risk silent drift if a producer adds an
 * unrecognised reason string.
 *
 * @param value - Unknown candidate string
 * @returns True iff `value` is a registered ReviewReason
 *
 * @example
 * ```typescript
 * const reason = workItem.metadata?.reviewReason;
 * if (isReviewReason(reason)) {
 *   render(reason); // narrowed to ReviewReason
 * }
 * ```
 */
export function isReviewReason(value) {
    return typeof value === 'string' && REVIEW_REASONS.includes(value);
}
//# sourceMappingURL=review-reason.types.js.map