Files
apf_portal/docs/decisions
Julien Gautier 04138b435a
CI / scan (pull_request) Successful in 4m4s
CI / commits (pull_request) Successful in 4m4s
CI / check (pull_request) Successful in 4m59s
CI / a11y (pull_request) Successful in 1m31s
CI / perf (pull_request) Successful in 5m25s
feat(portal): /api/me/capabilities + cross-app menu links + real role label
PR 3 of 3 — final piece of the user-menu / profile / cross-app
chantier.

BFF
  * New `MeModule` ships `GET /api/me/capabilities`, a curated view
    derived from the active user-portal session. Returns
    `{ canAccessAdmin: boolean }` today; the shape is deliberately
    binary so the SPA cannot reconstruct the raw `roles` claim. 401
    on missing session, consistent posture with `/auth/me`.
  * ADR-0009 amended: new "Curated public view" section codifies
    the "no raw roles on `/auth/me`, capabilities is the release
    valve" stance; the routes table grows a row for the endpoint.

portal-shell
  * New `CapabilitiesService` (app-local) calls the BFF on auth-state
    flip and exposes `canAccessAdmin` as a signal. Anonymous
    sessions short-circuit to the all-false default without firing
    a request.
  * Header's `userMenuItems` is now a `computed` — the "Open Portal
    Admin" entry appears in the dropdown only when
    `canAccessAdmin()` is true, pointing at
    `environment.adminAppUrl`.
  * Sidebar role widget reads the auth + capabilities signals to
    render one of three labels ("Anonymous" / "User" /
    "Administrator") in place of the hardcoded "Anonymous".

portal-admin
  * Symmetric: unconditional "Open Portal Shell" entry in the admin
    user menu, pointing at `environment.shellAppUrl`. Anyone who
    can reach portal-admin can reach portal-shell, so no
    capabilities check needed.

i18n
  * `header.userMenu.openAdmin`, `sidebar.role.{administrator,user}`,
    `sidebar.role.aria` reshaped to take the role as a placeholder.
2026-05-15 16:05:50 +02:00
..

Architectural Decision Records

This project records architecturally-significant decisions as ADRs in the MADR 4.0.0 format. References: adr.github.io.

Why ADRs

ADRs capture the why behind a decision — context, drivers, options considered, trade-offs accepted — at the moment the decision is made. They make architecture reviewable, onboarding faster, and prevent the same debate from being re-litigated later.

Conventions

  • Format: MADR 4.0.0. Start from template.md.
  • Filename: NNNN-kebab-case-title.md, e.g. 0007-adopt-tailwind-for-design-tokens.md.
  • Numbering: globally sequential 4-digit prefix. Numbers never reset, never get reused — even when an ADR is superseded or deprecated.
  • Layout: flat folder. ADRs are not nested into category subfolders; topical organization happens via tags.
  • Tags: every ADR carries a tags: array in the MADR frontmatter, drawn from the tag vocabulary below. An ADR may carry several tags. Propose new tags (or renames) in the same PR that needs them; never invent ad-hoc tags inline.
  • Status lifecycle: proposedaccepted → optionally deprecated or superseded by [ADR-NNNN](NNNN-other.md). Update the YAML frontmatter; never delete an ADR.
  • Index maintenance: every ADR addition or status change must update the Index below in the same commit.

When to write an ADR

Write one whenever a development decision is non-trivial: tool or library choice, framework pattern, security control, perf budget, a11y target, naming convention, deprecation, breaking change, or any choice that future contributors would benefit from understanding the why of.

Tag vocabulary

The vocabulary below is the source of truth. It is intentionally coarse — propose extensions only when an existing tag genuinely doesn't fit, and avoid overly narrow tags.

Tag Scope
frontend UI, Angular, components, design system, client-side state
backend API, BFF, server-side services
security AuthN, AuthZ, sessions, CSP, dependency scanning, secret management
performance Perf budgets, caching, bundle size, Lighthouse
accessibility WCAG, a11y testing, keyboard, ARIA, contrast
infrastructure CI/CD, hosting, deployment, runtime
observability Logs, metrics, traces, correlation IDs, monitoring
data Persistence, schemas, migrations, data flow
process Team conventions, workflows, repo policy

Status: starter vocabulary, to be refined as ADRs accumulate. Update this table whenever a tag is added, renamed, or retired.

Index

ADRs are listed in numerical order. To slice by topic, filter on the Tags column.

# Title Status Tags Date
0001 Use ADRs to record architectural decisions accepted process 2026-04-29
0002 Adopt Nx monorepo with the apps preset accepted infrastructure, frontend, backend 2026-04-29
0003 Workspace and app naming convention accepted process 2026-04-29
0004 Frontend stack — Angular (latest LTS), standalone, zoneless, Signals, CSR-only, Vitest accepted frontend 2026-04-29
0005 Backend stack — NestJS over Express, Fastify, Hono accepted backend 2026-04-29
0006 Persistence — PostgreSQL with Prisma accepted data, backend 2026-04-29
0007 Pre-commit hooks and Conventional Commits accepted process 2026-04-29
0008 Identity model — multi-tenant Entra ID for workforce, dual-audience design for future External ID accepted security, data 2026-04-29
0009 Authentication flow — OIDC Authorization Code + PKCE via MSAL Node, BFF session pattern accepted security, backend 2026-04-29
0010 Session management — opaque session IDs in cookies, payload in self-hosted Redis with AES-GCM at rest accepted security, backend, infrastructure 2026-04-29
0011 MFA enforcement — Entra ID Conditional Access baseline, BFF claim sanity-check, step-up hooks designed-in accepted security 2026-04-29
0012 Observability — Pino structured logs + OpenTelemetry tracing, W3C Trace Context propagation, stdout + collector accepted observability, backend, frontend 2026-04-29
0013 Audit trail — separated append-only Postgres schema, decoupled from app logs accepted security, observability, data 2026-04-29
0014 Downstream API access — On-Behalf-Of pattern, unified DownstreamApiClient, audience-aware authorization accepted security, backend 2026-04-29
0015 CI/CD pipeline — Gitea Actions, trunk-based + squash-merge, thin YAML over portable scripts accepted infrastructure, process 2026-04-30
0016 Accessibility baseline — WCAG 2.2 AA + targeted AAA, Angular CDK + spartan-ng + Tailwind, APF panel testing accepted accessibility, frontend, process 2026-04-30
0017 Performance budgets — Core Web Vitals + Lighthouse CI gates, bundle budgets, BFF p95/p99 SLOs accepted performance, frontend, backend, process 2026-04-30
0018 Environment configuration — Angular environment.ts, BFF env vars, audit pool split accepted frontend, backend, infrastructure, process 2026-05-10
0019 Internationalisation — @angular/localize, build-time per-locale bundles, /fr + /en path-based routing accepted frontend, accessibility, performance, process 2026-05-11
0020 portal-admin — dedicated SPA for portal administration, sharing the existing BFF accepted frontend, backend, security, infrastructure, process 2026-05-11
0021 Phase-2 security baseline — helmet, CORS allowlist, double-submit CSRF, rate limiting, structured error envelope accepted security, backend 2026-05-13