feat(intent): personal surfaces phase A — identity/personal/sensitive + the generated my-controller

[delchev]

One model, two generated surfaces

For entities that are a person's own records (vacation requests, timesheet day allocations), one generated UI is wrong for everybody: the back-office user needs everything; the person needs a surface bound to themselves with confidential fields absent. Per-role field rules sprinkled through one UI rot and leak; this PR generates a second, scoped surface instead — safe by construction.

The DSL (three words)

- name: Employee
  identity: email        # matched against the logged-in username

- name: VacationRequest
  fields:
    - { name: dailyRate, type: decimal, sensitive: true }
  relations:
    - { name: Employee, kind: manyToOne, to: Employee, personal: true }

What gets generated (phase A: the REST contract)

An additional <Entity>MyController per personalized entity:

• reads filtered to the current user's mapped identity record (Criteria.eq(identityProperty, User.getName())); no mapping row → empty, never an error;
• the owner FK forced server-side on create/update — whatever the client sends is overwritten; re-parenting is not a personal-surface operation;
• foreign and missing records are the same 404;
• sensitive fields stripped from responses and ignored on writes (kept values on update) — enforcement is in the serialization, not the UI;
• composition children inherit the scope through their direct parent (requireMyParent ancestor guard);
• immutable/immutableWhen guards preserved; the power controller is untouched.

Parser validations: identity must be an own string field; one personal relation per entity; target must declare identity (same-model at parse, cross-model at generation, loud); sensitive never on the PK or the identity field.

Tests

• IntentParserTest (5 new) + EdmIntentGeneratorTest (emission of identityProperty/relationshipPersonal/relationshipIdentityProperty/sensitiveProperty).
• IntentEmissionCoverageIT — fixture gains the Person/Claim/ClaimLine slice (the IT user maps via an email: admin seed) and asserts both layers: the generated tokens, then the published app over REST — scoped list with the sensitive field null, 404 for the foreign row, spoofed owner/rate on create forced/ignored, update keeps the stored sensitive value, child lines guarded through the parent. Green in 46s.

Design & phasing

PERSONALIZATION_PLAN.md (repo root, HARMONIA_RUNTIME_PLAN.md-style) records the agreed decisions and the follow-up phases: B personal UI ("My …" pages), C My Shell (/services/web/my/ aggregating all personal perspectives), D per-user task assignment for personal processes, E collection-driven generation, F item-dialog readOnly.

🤖 Generated with Claude Code

[delchev]

All six phases are now on this branch (one commit each), plus the agreed label: display-name feature:

Phase	What landed
A	identity/personal/sensitive DSL + the generated scoped <Entity>MyController (row filter, forced owner, ancestor guard for children, sensitive stripping)
label	entity label: → stored read-only Name recomputed on every write path; dropdown resolution prefers it everywhere (fixes raw-id lookups; labels compose across hops via {Parent.Name})
D	assignee: personal → flowable:assignee resolved through the identity mapping, carried in the start payload (assignee expressions evaluate at task creation, inside Process.start)
F	document item dialog renders readOnly columns as values, not fake-editable controls
B	generated personal UI: a "My …" list per personal root + a form per personal entity (owner/sensitive never rendered; children as embedded panels — x-h-calendar with date-click booking for detailCalendar children), SPA routes + sidebar section, perspectives on the new application-personal-perspectives extension point
C	My Shell (resources-my, /services/web/my/): the personal counterpart of the application shell — task-first (Inbox is the home page), aggregates every module's personal pages under one group
E	schedules[].generate.children[] — collection-driven generation: one child per matching row of a local entity or per working day of the month, nested to two levels (the monthly timesheet pre-generation shape)

Everything is asserted in IntentEmissionCoverageIT at both layers per the emission contract — the full fixture publishes and passes in ~50s, including live checks that the personally-assigned task lands in the owner's Inbox and the My Shell aggregation lists the published personal perspective.

Two platform gotchas found live and encoded in the docs: the perspectives extension service silently drops a perspective whose groupId matches no group (and a group definer must carry items: []), and BPMN assignee expressions evaluate inside Process.start so per-user variables must ride the start payload.

Formatting validated across all touched modules; the release-profile javadoc gate passes on engine-intent (rebased over #6261).

🤖 Generated with Claude Code