New policy domains
A policy domain is one category of thing a pupil might try, such as picking up a paper or telephoning out.
Adding one means changing every layer that has an opinion about it.
The outline below is the intended structure and is not yet written.
The model
The record under policy/policySubComponents, its validation, and where it is normalised.
The reader
Parsing, the version gate, and rejecting values the enforcement layers cannot honour.
The creator
Which test-case families the domain produces: architecture, aspect-oriented programming (AOP), Phobos, or a combination.
The enforcement layers
The architecture rule, the AOP advice and toolbox, and the Phobos configuration section. A domain that is expressible but enforced by only some layers must say so explicitly in its documentation.
The documentation contract
One page under Policy Reference for what an instructor writes, and one page in the contributor Policy section for how it is enforced. Both are pinned by the documentation structure tests.
Verification
Positive and negative controls in each layer that claims to enforce the domain.
Notes
- The asymmetry to avoid: a field that parses and validates but is never dispatched. Timeouts are the current example of a domain that is generated but not yet executed in Postcompile.