# 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" ```