Screenplay generation: concepts referenced only from child records and read models are dropped, including PII-marked ones

[woksin]

Summary

Concepts are only emitted when referenced from positions the generator declares (event/command properties, query parameters and returns). Concepts that are referenced only from inside complex child records or read-model properties are dropped from the document — silently, with no diagnostic. In a real application this includes PII-marked concepts, so the generated document understates the application's PII surface — which cuts directly against Screenplay's "concepts carry compliance" design goal.

Evidence (real application)

Diffing the generated Ada document (105 concepts) against the source (120 Core concept types, counting ConceptAs<T> and EventSourceId<T> derivatives) shows 15 concepts missing, none of which appear as a top-level event/command property type:

Concept	PII	Where it lives
FirstName	yes	inside PersonalDetails child record
LastName	yes	inside PersonalDetails child record
PhoneNumber	yes	inside PersonalDetails child record
AnswerText	yes	inside RequirementAnswer child record (carried by events via IEnumerable<RequirementAnswer>)
CriterionNote	yes	inside evaluation child records
EvaluationScore, SkillName, VoucherLineHours, WebsiteUrl, ActivityFeedKey, MagicLinkRecipientId, TripletexInvoiceId, TripletexPaymentId, TripletexCustomerPaymentId, RequestEmailParserConfigurationId	no	child records / read-model-only positions

All five PII concepts carry [PII] and validation rules in source (FirstName: NotEmpty().MaximumLength(100), PhoneNumber: Matches(@"^\+?[\d\s\-().]{7,20}$"), …) — none of that reaches the document.

Related: the document does reference the child record types themselves in event property positions, e.g.

event TimesheetMonthApproved
  ...
  days ApprovedDayLine[]

ApprovedDayLine is never declared anywhere in the document — the Screenplay grammar has no complex-type declaration construct (companion language issue filed on Cratis/Screenplay). So today the document both references shapes it cannot define and loses the concepts inside them.

Suggested fix

1. Emit concepts transitively: when registering a type reference, walk complex record types' members and register the concepts found there. Concepts are declarable today — nothing in the grammar blocks this — and it restores the PII/validation story even while child-record shapes remain undeclarable.
2. Diagnose the shape loss: when an event/command/read-model property references a complex record type, emit an Information diagnostic that its shape (and any nested compliance annotations) cannot be expressed, so the loss is visible per the generator's nothing-dropped-silently principle.

Environment

• Cratis.Arc.Screenplay 20.65.0 (Analysis/Types/TypeRegistry.cs)

[woksin]

Correction to the evidence in this issue, checked against the current Ada tree while implementing it (PR #2408).

Only 7 of the 15 concepts listed here are recoverable, and none of the three PII ones are among them.

FirstName, LastName, PhoneNumber, WebsiteUrl, MagicLinkRecipientId, TripletexInvoiceId, TripletexPaymentId and TripletexCustomerPaymentId are not referenced by any artifact in the current source:

• FirstName and LastName appear nowhere outside their own declaration files (Source/Core/Common/FirstName.cs, LastName.cs).
• PhoneNumber appears only in an interface method signature and its implementation — ContactPointHash Hash(PhoneNumber phone) in Source/Core/Network/Consultants/MatchIndex/MatchIndex.cs — never as a property of an event, command or read model.
• WebsiteUrl appears only in specs.
• The three Tripletex ids appear only as handler-returned event source ids, which are already reported as SP0013.

The issue's table states that PersonalDetails carries FirstName/LastName/PhoneNumber. It carries FullName, DisplayName and Bio.

So these are not concepts the generator was dropping — they are concepts the application does not reference. Declaring them would contradict the registry's rule of declaring only what is referenced, and would put types in the document that no artifact uses. They were therefore deliberately not declared.

What the fix does deliver. Concepts are now registered transitively through complex record members, cycle-safe and in ordinal order. On this application:

• concepts 105 → 130
• @pii 27 → 29, with AnswerText and CriterionNote both emitting as String @pii with their validate blocks intact
• the 7 recoverable ones are AnswerText, CriterionNote, EvaluationScore, SkillName, VoucherLineHours, ActivityFeedKey, RequestEmailParserConfigurationId

A new SP0035 also reports each record whose shape cannot be declared (13 of them here), which is the upstream gap in Cratis/Screenplay#29.

The PII concern in the title still stands as a principle — a document that silently omits which fields are personal data is worse than one that omits them loudly — it just does not apply to the three fields named here.