Phase 1 — Core System & Security Modules#
Status: shipped on branch phase-1/core-security (pending push + merge to master).
Depends on: Phase 0.
Why first? Every other module needs working access control, system settings, and audit logging.
Modules — delivered#
| Module | API | Jira |
|---|---|---|
| Auth login + rehash-on-login | POST /api/v1/auth/login | BFC-13 |
| Login Activity tracking | MnxLoginActivity inserts on every login attempt | BFC-13 |
| User Access Information | GET /api/v1/users/me/access | BFC-14 |
| Group Setup | GET/POST/PUT/DELETE /api/v1/groups (writes flag-gated) | BFC-15 |
| License Information | GET /api/v1/license, /summary | BFC-29 |
| Self-guided help / tutorial | GET /api/v1/help/sections, /documents | BFC-30 |
| Favorites | GET/POST/DELETE /api/v1/users/me/favorites | BFC-23 |
| UI Conventions / Main Menu | GET /api/v1/navigation/menu | BFC-25 |
| System Settings | GET /api/v1/settings, PUT /{id} (writes flag-gated) | BFC-22 |
| Global Search | GET /api/v1/search?q=&types=&take= | BFC-24 |
| Dockerfile + health endpoints | Dockerfile + GET /health + GET /ready | BFC-20 |
| Docs pipeline | Hugo + Cloudflare Pages | BFC-36 |
| MX Chat — architecture ADR | ADR 0007 (Proposed) | BFC-27 |
Modules — deferred#
| Module | Reason | Jira |
|---|---|---|
| MX Chat MVP | Blocked on product input per ADR 0007 § “Decisions required” | BFC-28 |
| Calendar API | No legacy calendar table exists; greenfield module needs product scope | BFC-26 |
Cross-cutting deliverables#
- 7 ADRs — 0001 (auth model, amended with corrected Encrypted algorithm), 0004 (additive-only migration), 0005 (group → role/claim mapping), 0006 (Cube-2.0-owned rehash persistence), 0007 (MX Chat proposed)
- JWT with
mod_admin,grp,role,itarclaims — derived from legacy security graph per ADR 0005 - Feature flags:
EnableGroupWrites,EnableFavoritesWrites,EnableSettingsWrites— all default false - Global exception middleware +
ProblemDetails - Rate limiter (per-user + per-IP fallback)
- Serilog request logging + correlation ID middleware
- Health checks —
/healthliveness,/readywith SQL Server dependency - 91 automated tests passing (Data.Tests + Web.Tests + IntegrationTests)
Exit criteria — met#
- A user logs in through the new Auth API and receives their real roles / permissions
- System Settings, Group Setup, and Login Activity are servable from the new API and match legacy output (verified locally against
compAdminon staging DB) - Feature-flag mechanism is proven end-to-end (writes off by default; toggle enables them)
- Rollback plan documented for each module (Dry-Run § 4.5)
Sign-off gates#
- Migration Dry-Run — BFC-17. Reviewer executes 3 SQL files against staging and fills in the report template.
- UAT Plan — BFC-35. QA + reviewer + product each run the golden-path scripts and sign off.
Only after both are complete does Phase 1 merge to master.
Known limitations at ship time#
Tracked as follow-up tickets (full detail):
- BFC-31 — machine keys still in
appsettings.json(blocked on ops / secrets store) - BFC-32 —
GroupWritepolicy tightening (blocked on reviewer) - BFC-33 —
/users/{userId}/accesscross-tenant guard (blocked on reviewer) - BFC-34 — failed-attempt tracking + auto-lockout (blocked on product)
None of the above block Phase 1 sign-off — the reviewer acknowledges them per UAT Plan § 7.
Risks — resolved#
Legacy password hash format may not match what we assumed.Resolved 2026-09-04: Encrypted algorithm confirmed against staging usercompAdmin. Algorithm documented in ADR 0001 as amended.Group / permission model is spread acrossResolved: ADR 0005 captures the end-to-end mapping; implementation inAspMnxGroup,AspnetMembership,MnxUser*. The mapping is not trivial.Manex.Web.Auth.TokenService+UserAccessService.