user-engine/intakes/intakes.md

# 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"
state_hub_intake_id: "01a0e45f-37cc-7131-bbc8-856c0d4ba44b"
```


## USER-IN-0001 — Declaration requested: state this repository's layer in INTENT.md (security layer model §11)

```yaml
id: USER-IN-0001
kind: intake
title: 'Declaration requested: state this repository''s layer in INTENT.md (security
  layer model §11)'
status: answered
origin: cross-repo
origin_ref: net-kingdom security-layer-model_v0.4 §11
priority: low
owner: user-engine
requested_by: gate-house
proposed_layer: Engine
description: 'A conformance sweep on 2026-08-28 found this repository has no layer
  declaration of its own. It carries a layering review note gate-house wrote into
  the top of its INTENT.md on 2026-08-24, and that note names a layer — but the words
  are gate-house''s, sitting above a line admitting the body is unadapted. Section
  11 has since been amended to say so explicitly: a layer stated about a repository
  by another repository is not a declaration; only the repository''s own file, in
  its own voice, conforms. Seven of fifteen estate-authored repositories have declared;
  this is one of the eight that have not, and the standard does not claim adoption
  on the basis of notes gate-house wrote. REQUESTED: state the layer in INTENT.md
  in your own voice, or contest it. PROPOSED LAYER: Engine. Users, accounts, memberships.
  Your boundary contract (net-kingdom/canon/standards/user-engine-boundary-contract_v0.1.md)
  holds unchanged; the only addition is making explicit that subject context is an
  input to the authorization decision and never a decision. Contesting is a real option
  and costs nothing — the three repositories that reviewed this model each returned
  a correction, two of which changed the standard. If the proposed layer is wrong
  for what this repository actually does, that is more useful to us than a label added
  to close a checkbox. Standard: net-kingdom/canon/standards/security-layer-model_v0.4.md.'
created: '2026-08-28T21:02:12.760565Z'
updated: '2026-08-29'
answered: '2026-08-29'
answer: >-
  Own-voice declaration in INTENT.md: layer Engine, role PIP. Subject
  context is a claim, never a decision. Protected mutations are PEP-shaped
  without changing layer. Not contested. Runtime follow-through is
  USER-WP-0024. Assessment:
  history/2026-08-29-security-layer-scope-intent-assessment.md.
state_hub_intake_id: "01a04cff-d5fc-7425-ad88-70149544855f"
```