{{--
    The ✓ button of CR-10, in both of the shapes it takes.

    ONE partial for three screens — the dashboard's Pending Tasks card, the show
    page's Follow Up History and the follow-up page's — for the same reason
    history.blade.php is one partial for two: the control is the same control,
    and three copies would be three chances for one of them to post to the wrong
    route or to skip the gate.

    Props (passed via @include):
        $task   the FollowUp. Its inquiry does not have to be loaded: nothing
                here reads one, so the partial still runs no queries.

    ## Two shapes, decided by the type (CR-10 §6.1, §6.3)

      document task   a real POST form with the house `onsubmit="return
                      confirm(…)"` guard — the pattern every destructive row
                      action in this application uses (see
                      inquiries/partials/actions.blade.php). There is nothing to
                      collect: completing one writes today's date and no
                      conclusion, so a dialog would be a dialog with one button.
                      It needs no Javascript at all.
      activity task   a plain button that opens the shared conclusion dialog,
                      re-targeted at this row by nrems-pending-tasks.js from the
                      `data-task` payload below. A conclusion is required there
                      (decision D11), and this is what collects it.

    Neither shape is a link. A GET that completes a task would be followed by
    any crawler or link prefetcher on the page.

    ## Why the document form is PUSHED rather than written here

    Because one of the three screens would otherwise nest it. The follow-up page
    draws its Follow Up History INSIDE `#nrems_follow_up_form` (that page is one
    big form with the timeline at the foot of it), and a <form> inside a <form>
    is not markup a browser keeps — the inner one is dropped at parse time, and
    the ✓ would have submitted the follow-up page instead of completing the
    task. Silently, and only on that one screen.

    So the <button> stays here, in the row, and the <form> it submits is pushed
    onto the `nrems_task_forms` stack, which partials/complete-task-modal.blade.php
    renders at page level where no form can contain it. HTML5's `form="…"`
    attribute is what ties the two back together; it is the feature that exists
    for exactly this case, and it is in every browser this application supports.

    The pairing is safe by construction rather than by convention: the same
    partial that renders the stack is the one that carries the dialog, so a
    screen that offers the ✓ at all has already included both.

    ## The gate

    `@can('complete', $task)` — App\Policies\FollowUpPolicy, which is row-scoped
    rather than permission-scoped. On the dashboard the query has already
    applied the same rule in SQL, so the check is a second opinion there; in the
    two history timelines it is the only one, because those pages show every
    entry of an inquiry to anybody who may read it.

    ## Escaping — and why the payload is json_encode() and NOT Js::from()

    Two different contexts, two different escapers, and CR-20 exists because
    this partial used the wrong one for the attribute.

      `data-task`      an HTML ATTRIBUTE, read back by
                       getAttribute() + JSON.parse(). So: json_encode() inside
                       `{{ }}`, which is the chain every payload attribute in
                       this application uses (see
                       inquiries/partials/booking-action.blade.php's
                       `data-inquiry`, and `data-strings` on the dialog root).
                       json_encode writes the JSON, `{{ }}` runs it through e()
                       so the quotes and angle brackets become entities the
                       parser keeps inside the attribute, and the browser hands
                       the script the JSON back with those entities decoded —
                       parseable, and a task label cannot break out of it.

                       Js::from() is for the OTHER context. It emits a JS
                       *expression* — literally `JSON.parse('…')` — which is
                       correct inside a <script> and, inside an attribute, is
                       just a string that begins "JSON.parse(". That is
                       what shipped here, and JSON.parse() choked on it in
                       nrems-pending-tasks.js's payloadOf(), silently: the ✓ on
                       every Personal Meeting, Site Visit and Follow Up Call
                       did nothing, on all three screens, from CR-10 until
                       QA-1's ISSUE-1 found it (CR-20 §U1). The catch that
                       swallowed it now console.error()s.

      `onsubmit=…`     an INLINE SCRIPT (an event-handler attribute is JS, not
                       data), and the sentence is interpolated straight into a
                       confirm() call. So: Js::from(), which is exactly right
                       here and stays. It is a lang string rather than anything
                       user-supplied either way.

    Nothing here is rendered unescaped.
--}}
@php
    /** @var \App\Models\FollowUp $task */
    $completeUrl = route('follow_ups.complete', ['followUp' => $task->getKey()]);
    $formId = 'complete_task_form_'.$task->getKey();
@endphp
@can('complete', $task)
    @if ($task->type->isDocumentTask())
        <button type="submit"
                form="{{ $formId }}"
                class="btn-icon text-success"
                title="{{ __('inquiries.actions.complete_task') }}"
                aria-label="{{ __('inquiries.actions.complete_task') }}">
            <i class="fa-solid fa-check" aria-hidden="true"></i>
        </button>

        @push('nrems_task_forms')
            <x-form.open :id="$formId" :action="$completeUrl" method="POST" :novalidate="false" class="d-none"
                         onsubmit="return confirm({{ Js::from(__('inquiries.complete_confirm')) }});" />
            <x-form.close />
        @endpush
    @else
        {{-- `data-task-id` is what the reopen path matches on after a rejected
             submit: the server says which task failed, the script finds this
             button and opens the dialog against it again. --}}
        <button type="button"
                class="btn-icon text-success nrems-task-complete"
                data-task-id="{{ $task->getKey() }}"
                data-task="{{ json_encode(['url' => $completeUrl, 'label' => $task->type->label()], JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES) }}"
                title="{{ __('inquiries.actions.complete_task') }}"
                aria-label="{{ __('inquiries.actions.complete_task') }}">
            <i class="fa-solid fa-check" aria-hidden="true"></i>
        </button>
    @endif
@endcan