Compliance Templates — Slice 4: mandatory flag + completeness validator (advisory)

Parent PRD

#676

What to build

Introduce the mandatory flag as the declarative enforcement primitive (supersedes writing a compliance rule) and the completeness validator that consumes it — in advisory mode only here (blocking-at-publish is slice 5).

• Admin — a mandatory checkbox per field; a warning when a field is both mandatory and has a default (the default will satisfy the check — PRD user story 14).
• Backend — a pure completeness validator (own module, no DB/HTTP) that, given a schema + stored values, returns a result object { passed, failure_messages }. A mandatory field is satisfied if a valid value exists or the field has a non-empty default (effective-value semantics). Symmetric with the existing synchronous workflow-trigger check that returns a pass flag. Add a completeness endpoint returning the result object for an entity. Table-driven unit tests per PRD Testing Decisions §2 (mandatory-with-default passes, mandatory-no-default-unfilled fails, non-mandatory-unfilled passes, effective-value fallback, MultiEnum/Range/Boolean edge cases).
• Frontend — an advisory status indicator on the product showing when mandatory fields are still unset. Never blocks anything in this slice.

Acceptance criteria

• Admin can mark any field mandatory
• Admin sees a warning when a field is both mandatory and has a default
• Pure completeness validator returns a result object (passed + human-readable failure messages)
• Mandatory-with-default = satisfied; mandatory-no-default-unset = fail; non-mandatory-unset = pass
• Completeness endpoint returns the result object for a given (entity_type, entity_id)
• Product shows an advisory indicator of unset mandatory fields; nothing is blocked
• Table-driven unit tests cover the matrix incl. MultiEnum/Range/Boolean edge cases

Blocked by

• Blocked by #707
• Blocked by #708

User stories addressed

• User story 6
• User story 14
• User story 19

Start with the parent PRD (#676) and resolve the blockers in #707 and #708 before locating the existing synchronous workflow-trigger check. Then trace the admin, backend, endpoint, and product entry points described here. Done means the advisory validator, result endpoint, UI indicator, warning, and table-driven edge-case tests satisfy every acceptance criterion without blocking actions.