[F3] Self-service Profile management (Phase 2)

[anmolg1997]

Workstream: product-ux | Estimate: 8d normal → 4d AI-assisted | Phase: 3

Why

Per the 2026-06-12 call: business users editing profiles/rules = subscription-tier feature, NOT day-one. Flag-gated (A5). 'It will just populate a YAML file.'

Scope

• Profiles/rules editor UI writing the external config dirs
• Validation + preview (uses identification-block schema)
• Gated behind a tenant flag

Acceptance criteria

• With flag off: invisible. With flag on: YAML round-trips losslessly

---

From the enterprise-readiness backlog (codebase audit + pharma/GxP research + tooling survey, 2026-06-12).

[anmolg1997]

Redefined + deferred. Maps to the product's Phase-2 'customer self-service Profile management' (rule libraries, Profile templates, cross-site forks). Not MVP.

See planning/RECONCILIATION.md (PR #156) for the full product↔engineering mapping.

[anmolg1997]

Now concretely specified — this IS the Profile self-service entitlement. PROFILES_FEATURE_SPEC §8.2 defines self-service Profile authoring as a per-tenant entitlement, defaulting to OFF, that gates the entire client Profile surface. In the default support-operated mode the client sees no Profiles nav at all; turning this entitlement on is what makes the Profile surface visible to the client's Team Lead / Site Head (§8.1).

So: M1 (#158) ships the support-operated default of this same surface; #130 is the Phase-2 self-service unlock of it — same screens, different operating mode. Enabling the entitlement only changes who operates Profiles and whether the client sees the surface; it does not alter authoring behaviour or existing approved Profiles (§8.2). The entitlement flag itself lands with config/feature-flags (#109).