Includes the BMAD install config, the initiative ticket tree, the portal context-resources scripts, and the .gitignore change that tracks BMAD files (generated _bmad/render/ is ignored). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Sk72AxLwQnYttF6VFSxQLt
3.6 KiB
tracker_id, key, type, title, parent, covers, after, assignee, risk
| tracker_id | key | type | title | parent | covers | after | assignee | risk | ||
|---|---|---|---|---|---|---|---|---|---|---|
| epic | A user can sign in to the live portal | initiative-ping-mee-portal |
|
high |
A user can sign in to the live portal
Description
The platform baseline: the container, configuration, the Active Directory adapter, sign-in through authentik, sessions with roles, the page shell with preferences, and the scheduler with the mail outbox. When it is done, a person signs in to the portal running on the Linux host and sees their own name from Active Directory in the new layout; every later epic builds on it.
Outcome
The admin can sign in to the live portal through authentik and see their own name from AD in the page shell, which proves every layer connects.
Requirements
Owned from the spec: CAP-1 (sign-in, roles, sessions, throttling base) and the shell and preference parts of CAP-9. Groundwork for CAP-10 (container, configuration, health) and CAP-8 (audit foundation) is laid here; their completion is in the third epic.
- CAP-1 — spec SPEC.md, Capabilities (PRD FR-1 to FR-4)
- CAP-9, shell part — PRD FR-29, FR-31; EXPERIENCE.md Foundation and Information Architecture
- CAP-10, groundwork — PRD FR-26, FR-27; architecture AD-13, AD-18
Done when
- A user in the test OU signs in through the portal's own OIDC application in authentik and lands in the page shell showing their name from AD.
- A user outside the Publisher and Admin groups cannot open Publisher or Admin pages by direct address; a disabled or locked AD account is refused.
- Sessions end after 1 hour idle and 4 hours total; repeated sensitive requests are refused before any AD call.
- The container starts only with valid environment variables, answers its health check without AD, and runs on the Linux host behind Zoraxy.
- Theme, language and German form of address can be chosen and are kept per device; the layout works on a phone.
- The scheduler ticks and the mail outbox sends a test e-mail through the configured SMTP server.
Boundaries
The portal's platform and sign-in only. Not profile, password or picture features (epic-account-self-service), not announcements or the Admin pages (epic-announcements-and-administration). Touch points owned here: Active Directory, authentik, Zoraxy, IONOS mail.
References
- parent — _bmad-output/initiative-ping-mee-portal/initiative-ping-mee-portal.md, section Requirements
- spec — _bmad-output/specs/spec-ping-mee-self-service-platform/SPEC.md, CAP-1, CAP-9, CAP-10
- architecture — _bmad-output/architecture/architecture-ping-mee-self-service-platform-2026-10-15/ARCHITECTURE-SPINE.md, AD-1 to AD-7, AD-11 to AD-13, AD-15, AD-18, AD-19
- design — _bmad-output/ux-designs/ux-ping-mee-self-service-platform-2026-10-15/DESIGN.md and EXPERIENCE.md, mock-ups key-dashboard.html
- constraint — SPEC.md, section Constraints
Notes
- Decision: tracer bullet is the scaffold followed by sign-in; the first visible result is the user's name in the shell at entry 6 (2026-10-15).
- Decision: a closing Refactor sweep is proposed by default; no end-to-end suite for this epic unless the user asks (2026-10-15).
- Decision: the checkpoints agreed in the spec's stories carry over: plan review on entries 1, 4 and 5, and a pause after entry 5 (user, 2026-10-15).
- Assumption: Zoraxy appends the real client IP as the last
X-Forwarded-Forentry; to be checked with a test request when the container is first deployed behind it. - Assumption: the exact AD attribute names for the password policy are verified in the test OU during entry 4.
- Source conflict: none found.