File USER-IN-0002: reusable account/session-status UI component

Operator ran into an extended, opaque troubleshooting session in
informed-decision: the decision overview uses a 12h MFA-freshness
window while opening a memo to review/approve uses a strict 900s
window, so the overview kept working while every review page silently
refused, with no session-status visibility and no logout affordance
in that app's UI to diagnose or recover from it.

Requests a reusable account/session-status component (identity,
assurance freshness, logout) that informed-decision, vergabe-teilnahme
and other consumer UIs can mount, built against user-engine's
identity/assurance model. Notes USER-WP-0036 as directly reusable
prior art, and flags -- as a remark, not a decision -- that the actual
component likely belongs in a distinct small repository rather than in
headless user-engine itself or vendored per consumer, to avoid
coupling every consumer's frontend build to user-engine's release
cycle.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: sonnet
Assistant-Process: 169987@bnt-lap001
Assistant-Session: 322ef1ef-9048-4021-8570-b6d6f6347999

intakes/intakes.md

@@ -1,5 +1,72 @@
 # Intake records
 
+## USER-IN-0002 — Reusable account/session-status UI component (identity, freshness, logout) for consumer apps
+
+```yaml
+id: USER-IN-0002
+kind: intake
+title: 'Reusable account/session-status UI component (identity, freshness, logout)
+  for consumer apps'
+status: open
+origin: cross-repo
+origin_ref: informed-decision review-approval session, 2026-09-27
+priority: medium
+owner: user-engine
+requested_by: operator
+description: >-
+  Trigger: an operator (platform-root) spent an extended troubleshooting
+  session in informed-decision unable to tell why a memo review had gone from
+  workable to "Review unavailable" / "The permission service refused this
+  review action." The actual cause was legible only by reading flex-auth's
+  policy_observations rows directly on the running pod: the decision overview
+  uses a lenient 12-hour MFA-freshness window (informed-decision.compact-sitting
+  `list` rule) while opening a specific memo to review/approve uses a strict
+  900-second window (the same package's `read`/`accept`/etc rule) — so the
+  overview kept working while every review page silently refused, with no way
+  for the operator to see their own session's assurance age or do anything
+  about it short of blindly re-authenticating and hoping. informed-decision's
+  upper-right corner today is a bare "Signed in as uid=..." string with no
+  session detail and no logout affordance.
+
+  REQUESTED: a reusable, embeddable account/session-status web UI component
+  that a consuming app mounts in place of that string. At minimum it should
+  show the verified identity, the session's current assurance level and how
+  stale it is, and offer a logout action; ideally it also makes legible when a
+  consuming app's own binding-grade action will need a fresher sign-in before
+  the user hits a wall (informed-decision review/accept as the concrete case,
+  but this is a general PEP/binding-surface problem, not specific to one app).
+  Consumers named so far: informed-decision (replacing today's plain string),
+  vergabe-teilnahme, and other user-facing UIs across the estate as they come
+  up.
+
+  Prior art worth reusing rather than re-deriving: USER-WP-0036 (account
+  situational awareness) already separated "login state," "active access,"
+  and "allowed access" for user-engine's own portal account page, including
+  exactly the login-state-absent and multi-tenant-active cases this component
+  would also need to represent. This request is not asking for a from-scratch
+  design; it's asking whether that page's model and API surface can be
+  packaged for reuse rather than reimplemented per consumer.
+
+  ARCHITECTURE CONCERN (operator's own framing, not a decision): the
+  component needs to move in lockstep with user-engine/key-cape's identity
+  and assurance model, but every consuming app pulling in a UI dependency on
+  user-engine directly is the wrong shape — user-engine is headless by its
+  own INTENT.md, and coupling every consumer's frontend build to user-engine's
+  release cycle is exactly the kind of dependency growth this request wants
+  to avoid. REMARK: implementing the actual shippable component (a web
+  component, a small JS package, a server-rendered partial — user-engine's
+  call) may be best done in a **distinct, small repository** that consumers
+  depend on directly, with user-engine owning the data/API contract that
+  repository renders against, rather than folding UI code into user-engine
+  itself or vendoring copies per consumer. This repo owns the identity/account
+  domain the component represents, so scoping the actual shape (new repo or
+  not, contract surface, versioning/dependency story) is left to user-engine's
+  judgment rather than decided here.
+created: "2026-09-27"
+updated: "2026-09-27"
+```
+
+
 ## USER-IN-0001 — Declaration requested: state this repository's layer in INTENT.md (security layer model §11)
 
 ```yaml