@anchrd/intel-ui 0.19.0 → 0.21.0

package/src/resource-menu/resource-menu.tsx

@@ -1,10 +1,6 @@
-import type {
-  Flow,
-  FlowValidation,
-  Node,
-  ResourceVerb,
-  UnreadableNodes,
-} from "@anchrd/intel-contract";
+import type { Flow, FlowValidation } from "@anchrd/intel-contract/flow";
+import type { Node } from "@anchrd/intel-contract/node";
+import type { ResourceGrant, ResourceVerb, UnreadableNodes } from "@anchrd/intel-contract/share";
 import { useMutation, useQuery, useQueryClient } from "@tanstack/react-query";
 import { useNavigate, useRouterState } from "@tanstack/react-router";
 import {
@@ -33,13 +29,14 @@ import {
   DropdownMenuSubTrigger,
   DropdownMenuTrigger,
 } from "@/components/ui/dropdown-menu";
-import { flowEntry } from "@/data/intel-data-provider/intel-data-provider.ts";
+import { flowEntry, IntelRequestError } from "@/data/intel-data-provider/intel-data-provider.ts";
 import type { TreeEntry } from "@/data/intel-data-provider/intel-data-provider.types.ts";
 import { useI18n } from "@/i18n/i18n-context.tsx";
 import { useBundleImport } from "@/import-bundle/import-bundle.tsx";
 import { Modal } from "@/modal/modal.tsx";
 import { useIntelRouterContext } from "@/router/router-context.ts";
 import { selectedFrom } from "@/router/selection-search.ts";
+import { useUserName } from "@/user-name/user-name.ts";
 
 /**
  * What a resource's own actions are, at the place the resource stands (#24).
@@ -580,10 +577,76 @@ function NodeLinksPanel({ node, close }: { node: Node; close(): void }) {
 // flows, which is where a permission decision belongs (ADR-0004 §2). Which verbs it offers is the
 // server's answer, not this component's: `execute` never appears on a document, because a document
 // has nothing to run.
+/**
+ * One row of the grant list.
+ *
+ * ⚠️ It is a component rather than a line inside the `map` because of `useUserName`, and that hook
+ * is the point: until #431 a `user` grant printed its raw id — `2C9lEhT82upO82abPjHFAvs24a7Vdd3J`
+ * beside the word "Read" — which tells the reader nothing about who they let in and puts an
+ * identifier on a screen that has no reason to carry one. `user-name.ts` already had the rule
+ * ("never fall back to the id, show nothing instead", #258); this row was the last place breaking it.
+ *
+ * ⚠️ Intel can resolve exactly ONE id today: the signed-in person's. A foreign one is not "a name we
+ * could probably guess" but genuinely unanswerable — Intel has no user directory (#261) — so what
+ * stands there is what is true: an account, unnamed. The day #261 lands, `useUserName` starts
+ * answering and this row needs no change.
+ */
+function GrantRow({ grant, onRevoke }: { grant: ResourceGrant; onRevoke(grantId: string): void }) {
+  const i18n = useI18n();
+  const userName = useUserName(grant.principal.type === "user" ? grant.principal.id : null);
+  // ⚠️ An `email` grant keeps showing the ADDRESS, even where a name is known, and that is a
+  // decision rather than an oversight (#431, review finding). The grant is bound to the address —
+  // `db-grants.ts` matches `lower(principal_id)` against whoever signs in — not to an account.
+  // Putting a name there would claim a binding that does not exist, and it would be wrong the moment
+  // somebody else verifies that address.
+  const who =
+    grant.principal.type === "email"
+      ? grant.principal.email
+      : grant.principal.type === "user"
+        ? (userName ?? i18n.t("node.someUser"))
+        : i18n.t("node.organization");
+  return (
+    <li className="flex items-center justify-between gap-3 rounded-md border p-3 text-sm">
+      <span className="min-w-0 truncate">
+        {who}
+        <span className="ml-2 text-xs text-muted-foreground">
+          {i18n.t(`node.verb.${grant.verb}`)}
+        </span>
+      </span>
+      <button
+        type="button"
+        onClick={() => onRevoke(grant.id)}
+        aria-label={i18n.t("node.revokeShare")}
+        className="rounded-md p-2 text-destructive outline-none hover:bg-muted focus-visible:ring-2 focus-visible:ring-ring"
+      >
+        <Trash2 aria-hidden="true" className="size-4" />
+      </button>
+    </li>
+  );
+}
+
+/**
+ * Which of the three principals the dialog can SET (#431).
+ *
+ * ⚠️ `user` is deliberately absent, and it is a decision rather than an omission. Setting one means
+ * naming a Gate user id, and Intel has no way to turn a person into an id or an id into a person
+ * (#261) — so the only offer this dialog could make is a field for a raw ULID, which is worse than
+ * the address it would replace: unverifiable when typed and unreadable afterwards. It stays reachable
+ * over the API and over MCP, where the caller already holds the id. The day #261 lands it becomes a
+ * picker, not a text field.
+ *
+ * ⚠️ `organization` IS here, and the reason is the asymmetry it removes: the dialog could already
+ * DRAW an organization grant ("Everyone in the organization") and not make one, and MCP could make
+ * one all along — a person had strictly less reach than a model on the same tree. It needs nothing
+ * Intel does not have, because there is nothing to name.
+ */
+type SharePrincipalKind = "email" | "organization";
+
 function SharePanel({ node, close }: { node: Node; close(): void }) {
   const { data } = useIntelRouterContext();
   const i18n = useI18n();
   const queryClient = useQueryClient();
+  const [principalKind, setPrincipalKind] = useState<SharePrincipalKind>("email");
   const [email, setEmail] = useState("");
   const [verbs, setVerbs] = useState<ResourceVerb[]>(["read"]);
   // What the grant just made does not cover. It survives the form being cleared, because it is the
@@ -604,7 +667,10 @@ function SharePanel({ node, close }: { node: Node; close(): void }) {
         last = (
           await data.shareNode({
             resourceId: node.id,
-            principal: { type: "email", email },
+            principal:
+              principalKind === "organization"
+                ? { type: "organization" }
+                : { type: "email", email },
             verb,
             expiresAt: null,
             idempotencyKey: crypto.randomUUID(),
@@ -615,6 +681,10 @@ function SharePanel({ node, close }: { node: Node; close(): void }) {
     },
     onSuccess: (result) => {
       setEmail("");
+      // ⚠️ The choice is cleared with the address, not left standing. It survived a successful grant
+      // until the review of #431 caught it, and "everyone in the organization" is the one setting
+      // that must never be the quiet default for the NEXT grant somebody makes in the same dialog.
+      setPrincipalKind("email");
       setUnreadable(result);
     },
     // ⚠️ `onSettled`, not `onSuccess`. One request per verb means a run can end halfway: three verbs
@@ -637,12 +707,39 @@ function SharePanel({ node, close }: { node: Node; close(): void }) {
     },
   });
 
+  /**
+   * The one refusal in this dialog that names something the reader has to act on.
+   *
+   * ⚠️ Taking back `organization` + `execute` on a folder is refused with `409
+   * folder_execute_in_use` while flows from outside still call into it (`nodes.ts`,
+   * `revokeGrant`) — and the refusal's `detail` is the only place the CALLERS are named. Rendering
+   * it as the generic "access was not changed" threw exactly that away and left the reader with a
+   * dialog that refuses and will not say why, for the one grant that is hardest to undo.
+   *
+   * ⚠️ The server's own words, on purpose. `callersDetail` names the flows this actor may see and
+   * only COUNTS the rest, so it is actionable without becoming a directory of the tree — a
+   * translated stand-in would either lose the names or need them separately, and the wire carries
+   * prose rather than a list (#448). The lead-in sentence above it is translated; this line is the
+   * evidence under it.
+   */
+  const revokeInUse =
+    revoke.error instanceof IntelRequestError && revoke.error.code === "folder_execute_in_use"
+      ? revoke.error.message
+      : null;
+
   return (
     <Modal title={i18n.t("node.share")} close={close}>
-      {(share.isError || revoke.isError || grants.isError) && (
-        <p role="alert" className="mb-4 text-sm text-destructive">
-          {i18n.t("node.shareFailed")}
-        </p>
+      {revokeInUse ? (
+        <div role="alert" className="mb-4 space-y-1 text-sm text-destructive">
+          <p>{i18n.t("node.revokeInUse")}</p>
+          <p className="text-xs">{revokeInUse}</p>
+        </div>
+      ) : (
+        (share.isError || revoke.isError || grants.isError) && (
+          <p role="alert" className="mb-4 text-sm text-destructive">
+            {i18n.t("node.shareFailed")}
+          </p>
+        )
       )}
       {/* ⚠️ `status`, not `alert`, and beside the grant rather than in place of it: the access was
           given. A node reference across the folder edge is a possible failure, not a way around
@@ -664,29 +761,14 @@ function SharePanel({ node, close }: { node: Node; close(): void }) {
       )}
       <ul className="mb-5 max-h-44 space-y-2 overflow-y-auto">
         {grants.data?.items.map((grant) => (
-          <li
+          <GrantRow
             key={grant.id}
-            className="flex items-center justify-between gap-3 rounded-md border p-3 text-sm"
-          >
-            <span className="min-w-0 truncate">
-              {grant.principal.type === "email"
-                ? grant.principal.email
-                : grant.principal.type === "user"
-                  ? grant.principal.id
-                  : i18n.t("node.organization")}
-              <span className="ml-2 text-xs text-muted-foreground">
-                {i18n.t(`node.verb.${grant.verb}`)}
-              </span>
-            </span>
-            <button
-              type="button"
-              onClick={() => revoke.mutate(grant.id)}
-              aria-label={i18n.t("node.revokeShare")}
-              className="rounded-md p-2 text-destructive outline-none hover:bg-muted focus-visible:ring-2 focus-visible:ring-ring"
-            >
-              <Trash2 aria-hidden="true" className="size-4" />
-            </button>
-          </li>
+            grant={grant}
+            onRevoke={(grantId) => {
+              share.reset();
+              revoke.mutate(grantId);
+            }}
+          />
         ))}
         {grants.data?.items.length === 0 && (
           <li className="text-sm text-muted-foreground">{i18n.t("node.noGrants")}</li>
@@ -695,20 +777,99 @@ function SharePanel({ node, close }: { node: Node; close(): void }) {
       <form
         onSubmit={(event) => {
           event.preventDefault();
+          // ⚠️ The other mutation's error is cleared before this one starts, in both directions. A
+          // refused withdrawal keeps its `409` until something resets it, and `revokeInUse` takes
+          // precedence over the general sentence — so without this, a share that failed AFTER a
+          // refused withdrawal said nothing at all, and the reader was left reading a sentence
+          // about the wrong action. That is the exact failure mode #430 removed one level up.
+          revoke.reset();
           share.mutate();
         }}
         className="space-y-4 border-t pt-5"
       >
-        <label className="block text-sm font-medium">
-          {i18n.t("node.email")}
-          <input
-            type="email"
-            required
-            value={email}
-            onChange={(event) => setEmail(event.target.value)}
-            className="mt-2 w-full rounded-md border bg-background px-3 py-2 outline-none focus-visible:ring-2 focus-visible:ring-ring"
-          />
-        </label>
+        {/* ⚠️ Two of the three principals, and the missing one is a decision — see
+            `SharePrincipalKind`. Radios rather than a select: there are two, and a reader has to see
+            that granting to the whole organization is a thing this dialog does at all. */}
+        <fieldset className="space-y-2">
+          <legend className="text-sm font-medium">{i18n.t("node.shareWith")}</legend>
+          {(["email", "organization"] as const).map((kind) => (
+            <label key={kind} className="flex items-center gap-2 text-sm">
+              <input
+                type="radio"
+                name="share-principal"
+                checked={principalKind === kind}
+                onChange={() => setPrincipalKind(kind)}
+                aria-describedby={kind === "email" ? "share-email-hint" : "share-organization-hint"}
+                className="size-4 border outline-none focus-visible:ring-2 focus-visible:ring-ring"
+              />
+              <span>
+                {i18n.t(kind === "email" ? "node.shareWithEmail" : "node.shareWithOrganization")}
+              </span>
+            </label>
+          ))}
+        </fieldset>
+        {principalKind === "email" ? (
+          <div>
+            {/* ⚠️ The hint stands OUTSIDE the label and is tied on with `aria-describedby`. Inside
+                it, its words would become part of the field's accessible NAME — a screen reader
+                would announce the whole paragraph as the label of the input, and every query by
+                label would have to spell it out too. */}
+            <label className="block text-sm font-medium">
+              {i18n.t("node.email")}
+              <input
+                type="email"
+                required
+                value={email}
+                onChange={(event) => setEmail(event.target.value)}
+                aria-describedby="share-email-hint"
+                className="mt-2 w-full rounded-md border bg-background px-3 py-2 outline-none focus-visible:ring-2 focus-visible:ring-ring"
+              />
+            </label>
+            {/* ⚠️ What this says is what Intel knows, and no more (#431). It cannot check whether an
+                address belongs to anybody — Gate owns identity and offers Intel no lookup (#261) —
+                and a dialog that stayed silent about that let a typo become a grant that is valid,
+                permanent and completely without effect, with nobody on either side to notice. Naming
+                the uncertainty is the honest half of what the ticket asks for; the other half needs
+                Gate. */}
+            <p id="share-email-hint" className="mt-1 text-xs text-muted-foreground">
+              {i18n.t("node.emailHint")}
+            </p>
+          </div>
+        ) : (
+          /* ⚠️ `aria-live` on the CONTAINER, which is already mounted whenever this branch is on
+              screen — not on the warning inside it. A live region has to exist before its content
+              changes, so putting it on a paragraph that appears at the same moment announces
+              nothing. The gap it closes: `Run` is ticked while the focus sits in the verb fieldset,
+              far from here, and the sentence about what is being made would otherwise arrive in
+              silence. (The other way in is covered already: `aria-describedby` on the radio reads
+              this whole box out when the radio takes focus.) */
+          <div
+            id="share-organization-hint"
+            aria-live="polite"
+            className="space-y-2 rounded-md border bg-muted p-3 text-xs"
+          >
+            <p className="text-muted-foreground">{i18n.t("node.shareOrganizationHint")}</p>
+            {/* ⚠️ `organization` + `execute` on a folder is not one grant among four: it is the
+                definition of a LIBRARY (ADR-0004 §3) — the one grant a flow may call across a folder
+                edge for, so flows from anywhere in the tree may then reach in. Two clicks in this
+                dialog now do what used to take an API call, and the reader has to be told what they
+                are about to make BEFORE they make it.
+
+                ⚠️ The second sentence is the one that matters most, because it is about the way
+                back: `revokeGrant` refuses with `folder_execute_in_use` while callers remain, so
+                this is the single hardest grant in the product to undo. Naming the consequence after
+                the fact would be the "wrong sentence" class anchrd/core#111 collects.
+
+                It is a warning and not a block, deliberately: the library is a documented, wanted
+                shape, MCP has always been able to make one, and refusing it here would put a person
+                back below a model on the same tree — the very asymmetry this ticket removed. */}
+            {verbs.includes("execute") ? (
+              <p role="note" className="font-medium text-destructive">
+                {i18n.t("node.shareLibraryWarning")}
+              </p>
+            ) : null}
+          </div>
+        )}
         <fieldset className="space-y-2">
           <legend className="text-sm font-medium">{i18n.t("node.verbs")}</legend>
           {(grants.data?.applicableVerbs ?? []).map((verb) => (

package/src/save-button/save-button.tsx

@@ -14,18 +14,28 @@ import { Modal } from "@/modal/modal.tsx";
  * ⚠️ The accessible name names the state as well — "Saved" and "Save unsaved changes" are two
  * different pieces of information, and a screen reader gets neither the fill nor the dot. The
  * visible word stays a prefix of it, so speech input still reaches the button by what it reads.
+ *
+ * ⚠️ At rest there are TWO states, not one, and `stored` is what tells them apart (#432). A
+ * document that has never been written has nothing to save either — and calling that "Saved" is the
+ * one sentence an editor must never say untruthfully: whoever reads it closes the tab. The button
+ * was already unclickable in that state, which is exactly why it went unnoticed for so long; the
+ * tooltip and the accessible name kept claiming a version that does not exist. "Nothing to save"
+ * says less and stays true in both readings.
  */
 export function SaveButton({
   dirty,
   saving,
+  stored,
   onSave,
 }: {
   dirty: boolean;
   saving: boolean;
+  /** Whether what is being edited has content on the server at all. */
+  stored: boolean;
   onSave(): void;
 }) {
   const i18n = useI18n();
-  const label = i18n.t(dirty ? "common.saveDirty" : "common.saved");
+  const label = i18n.t(dirty ? "common.saveDirty" : stored ? "common.saved" : "common.saveNothing");
   return (
     <TooltipProvider delayDuration={300}>
       <Tooltip>

package/src/tools/tools.tsx

@@ -1,7 +1,15 @@
-import { serverOf, type ToolCapability, type ToolServer } from "@anchrd/intel-contract";
+import { serverOf, type ToolCapability, type ToolServer } from "@anchrd/intel-contract/tool";
 import { useQuery } from "@tanstack/react-query";
 import { useRouterState } from "@tanstack/react-router";
-import { AlertTriangle, ChevronRight, PlugZap, ShieldOff, Timer, Wrench } from "lucide-react";
+import {
+  AlertTriangle,
+  ChevronRight,
+  HelpCircle,
+  PlugZap,
+  ShieldOff,
+  Timer,
+  Wrench,
+} from "lucide-react";
 import * as React from "react";
 import { Button } from "@/components/ui/button";
 import { Collapsible, CollapsibleContent, CollapsibleTrigger } from "@/components/ui/collapsible";
@@ -65,8 +73,36 @@ function groupByServer(
 // visit. A second attempt after a refusal would be a redirect loop with an unchanging answer, and
 // the marker in the URL only survives until the next navigation — the browser session remembers it
 // instead (#60).
+//
+// ⚠️ It records that an attempt was STARTED, never that one was answered (#426). A sign-in that
+// crashed on the way leaves exactly the same note as one that came back, so nothing may read it as
+// a verdict about anybody: it only keeps the screen from walking in a circle on its own, and what
+// the reader is told comes from the marker in the URL instead. That is the whole distinction — the
+// note is never cleared to make a second attempt possible; the button is what makes one possible.
 const SignInAttemptKey = "intel.portal-sign-in-attempted";
 
+/**
+ * What came back from the silent walk — and "nothing" is one of the answers (#426).
+ *
+ * The marker in the URL is the only thing that ever says why the walk ended, and it is absent in two
+ * situations that look identical from here: the attempt never ran, or it broke before it could
+ * return. Neither is a decision about access, so neither may borrow the sentence that describes one
+ * — the rule `packages/ui/CLAUDE.md` keeps from #350: **a missing statement is a reason to say less,
+ * never to refuse more.** Saying "no access" for `none` sent a reader hunting through portal
+ * policies while the sign-in had answered 500 (#425).
+ */
+type PortalAnswer = "refused" | "expired" | "failed" | "none";
+
+function portalAnswerOf(connectError: string | null): PortalAnswer {
+  if (connectError === null) return "none";
+  if (connectError === "portal_sign_in_expired") return "expired";
+  // The two codes Intel itself writes when somebody was actually turned away — by the portal, or by
+  // Gate before the portal was ever asked. Every other marker is machinery, not policy.
+  return connectError === "portal_sign_in_refused" || connectError === "permission_required"
+    ? "refused"
+    : "failed";
+}
+
 // Reading `sessionStorage` throws outright in a few privacy modes, so the guard is a try, not a
 // feature check. Losing the note costs one extra redirect, and the marker the refusal leaves in the
 // URL still ends the walk — it must never cost the screen.
@@ -109,10 +145,30 @@ export function Tools() {
     typeof window === "undefined"
       ? null
       : new URLSearchParams(window.location.search).get("connectError");
-  const refused = connectError !== null;
-  const accessDenied =
-    connectError === "portal_sign_in_refused" || connectError === "permission_required";
-  const [signingIn, setSigningIn] = React.useState(false);
+  const answer = portalAnswerOf(connectError);
+  // What the screen DID about that answer, which is a third thing beside the catalog and the marker.
+  //
+  // ⚠️ Only `none` starts undecided. `useEffect` runs after the paint, so a state that always began
+  // at `deciding` would push a "Loading" frame in front of all four notices — and three of them are
+  // already settled at the first render, because their answer stands in the URL. It would flash at
+  // exactly the readers who just arrived out of a redirect. `none` is the one that genuinely has to
+  // wait: its walk starts one tick after the catalog arrives, and "we do not know" in between is a
+  // sentence the screen takes back immediately.
+  const [walk, setWalk] = React.useState<"deciding" | "running" | "stopped">(
+    answer === "none" ? "deciding" : "stopped",
+  );
+
+  const startSignIn = React.useCallback(() => {
+    // ⚠️ `setItem`, and the marker is not cleared anywhere on this path. Pressing the button STARTS
+    // an attempt, which is the only thing the marker ever claims — clearing it would buy the click
+    // nothing (no code in this path reads it) and cost the next visit: an attempt that dies without
+    // ever coming back with a marker would be followed by a silent redirect nobody asked for, on a
+    // screen that has just said it does not understand what is happening. The second attempt this
+    // browser session owes its reader is this button, never a re-armed guard.
+    attemptStore()?.setItem(SignInAttemptKey, "1");
+    setWalk("running");
+    data.startPortalSignIn("/tools");
+  }, [data]);
 
   // ⚠️ Nobody is asked to start this. The portal sign-in is a browser redirect, so the screen
   // begins it itself the moment the catalog says there is no portal session yet — that is the whole
@@ -126,11 +182,14 @@ export function Tools() {
       attempts?.removeItem(SignInAttemptKey);
       return;
     }
-    if (refused || attempts?.getItem(SignInAttemptKey)) return;
+    if (answer !== "none" || attempts?.getItem(SignInAttemptKey)) {
+      setWalk("stopped");
+      return;
+    }
     attempts?.setItem(SignInAttemptKey, "1");
-    setSigningIn(true);
+    setWalk("running");
     data.startPortalSignIn("/tools");
-  }, [catalog.data, data, refused]);
+  }, [catalog.data, data, answer]);
 
   return (
     <div className="min-h-full p-8">
@@ -151,43 +210,12 @@ export function Tools() {
             </Button>
           </Notice>
         ) : !catalog.data.portalConnected ? (
-          signingIn ? (
+          walk === "deciding" ? (
+            <p className="text-sm text-muted-foreground">{i18n.t("common.loading")}</p>
+          ) : walk === "running" ? (
             <p className="text-sm text-muted-foreground">{i18n.t("tools.signingIn")}</p>
-          ) : connectError === "portal_sign_in_expired" ? (
-            // Ran out of time on the consent screen. Nothing is broken and nobody was refused, so
-            // neither of the other two sentences fits — and this one is the only case the reader
-            // can fix alone, by starting over (#95).
-            <Notice
-              icon={<Timer aria-hidden="true" className="mx-auto size-8 text-muted-foreground" />}
-              title={i18n.t("tools.connectExpired")}
-              help={i18n.t("tools.connectExpiredHelp")}
-            >
-              <Button variant="outline" onClick={() => data.startPortalSignIn("/tools")}>
-                {i18n.t("tools.connectRetry")}
-              </Button>
-            </Notice>
-          ) : accessDenied || !refused ? (
-            // The end of the silent walk for somebody no Access policy carries. It is a sentence
-            // about access, not an invitation to connect: there is nothing they could click that
-            // would change the answer, and what the portal replied is not repeated here.
-            <Notice
-              alert
-              icon={
-                <ShieldOff aria-hidden="true" className="mx-auto size-8 text-muted-foreground" />
-              }
-              title={i18n.t("tools.noAccess")}
-              help={i18n.t("tools.noAccessHelp")}
-            />
           ) : (
-            // Every other marker is machinery, not policy: the sign-in broke before anyone could
-            // be allowed or refused. Saying "no access" here sent the last reader hunting through
-            // Access policies while the real fault sat in a failed client registration (#93).
-            <Notice
-              alert
-              icon={<PlugZap aria-hidden="true" className="mx-auto size-8 text-destructive" />}
-              title={i18n.t("tools.connectFailed")}
-              help={i18n.t("tools.connectFailedHelp")}
-            />
+            <PortalNotice answer={answer} i18n={i18n} onRetry={startSignIn} />
           )
         ) : catalog.data.items.length === 0 ? (
           <Notice
@@ -212,6 +240,81 @@ export function Tools() {
   );
 }
 
+/**
+ * The end of the silent walk, in the words of whatever ended it — one sentence per answer, and no
+ * sentence shared between two of them (#426).
+ *
+ * ⚠️ Only `refused` is a statement about ACCESS, and only it is a dead end: there is nothing the
+ * reader could press that would change the answer, so nothing is offered. The other two are the
+ * machinery and the silence, and both are worth another attempt — which is the button the screen
+ * lacked entirely while the marker in `sessionStorage` made the first attempt the only one.
+ */
+function PortalNotice({
+  answer,
+  i18n,
+  onRetry,
+}: {
+  answer: PortalAnswer;
+  i18n: I18n;
+  onRetry: () => void;
+}) {
+  if (answer === "refused") {
+    return (
+      <Notice
+        alert
+        icon={<ShieldOff aria-hidden="true" className="mx-auto size-8 text-muted-foreground" />}
+        title={i18n.t("tools.noAccess")}
+        help={i18n.t("tools.noAccessHelp")}
+      />
+    );
+  }
+  // Ran out of time on the consent screen. Nothing is broken and nobody was refused, so neither of
+  // the other sentences fits (#95).
+  if (answer === "expired") {
+    return (
+      <Notice
+        icon={<Timer aria-hidden="true" className="mx-auto size-8 text-muted-foreground" />}
+        title={i18n.t("tools.connectExpired")}
+        help={i18n.t("tools.connectExpiredHelp")}
+      >
+        <Button variant="outline" onClick={onRetry}>
+          {i18n.t("tools.connectRetry")}
+        </Button>
+      </Notice>
+    );
+  }
+  // A marker that is neither of the two access answers is machinery, not policy: the sign-in broke
+  // before anyone could be allowed or refused. Saying "no access" here sent the last reader hunting
+  // through Access policies while the real fault sat in a failed client registration (#93).
+  if (answer === "failed") {
+    return (
+      <Notice
+        alert
+        icon={<PlugZap aria-hidden="true" className="mx-auto size-8 text-destructive" />}
+        title={i18n.t("tools.connectFailed")}
+        help={i18n.t("tools.connectFailedHelp")}
+      >
+        <Button variant="outline" onClick={onRetry}>
+          {i18n.t("tools.connectRetry")}
+        </Button>
+      </Notice>
+    );
+  }
+  // No marker at all, and an attempt already made in this browser session: it never came back. The
+  // screen says exactly that — not "no access", which is a decision nobody made here.
+  return (
+    <Notice
+      icon={<HelpCircle aria-hidden="true" className="mx-auto size-8 text-muted-foreground" />}
+      title={i18n.t("tools.connectUnknown")}
+      help={i18n.t("tools.connectUnknownHelp")}
+    >
+      <Button variant="outline" onClick={onRetry}>
+        {i18n.t("tools.connectRetry")}
+      </Button>
+    </Notice>
+  );
+}
+
 /**
  * The catalog, under the portal's servers where there are any.
  *