bert.hausmans
e3c9211e3f
Adds PurposeGuardProvider as a parallel interface to PurposeDefinition (value object stays untouched). Seven concrete providers, one per v1.0 purpose, each declaring its publish-guard list. Registry resolves and caches providers via guards_class config key. Universal guards (MaxOneIdentityKeyPerTargetEntity, AppendStrategyRequiresCollectionTarget, NoAmbiguousTrustLevels, IdentityKeyBindingsOnlyInFirstSection) wire into every purpose. The section guard is a cheap no-op when section_level_submit=false. ArtistAdvanceGuards omits RequiresIdentityKeyBinding because the artist subject is resolved via portal token, not form data. Same reasoning for supplier_intake (production_request) and the auth-based purposes. Includes a cross-cutting BindingTypeRegistryConsistencyTest that verifies tasks 5/7/8 do not contradict each other (registry ↔ guards ↔ purpose required_bindings). Refs: RFC-WS-6.md §3 (Q9, Q13) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
22 lines
571 B
PHP
22 lines
571 B
PHP
<?php
|
|
|
|
declare(strict_types=1);
|
|
|
|
namespace App\FormBuilder\Purposes;
|
|
|
|
use App\FormBuilder\Publishing\PublishGuard;
|
|
|
|
/**
|
|
* RFC-WS-6 §3 (Q13) — parallel interface to PurposeDefinition.
|
|
*
|
|
* The value object stays untouched (it's a frozen contract); guards
|
|
* live here so a new purpose can be added by composing two artifacts:
|
|
* 1. a PurposeDefinition entry in config/form_builder/purposes.php
|
|
* 2. a class implementing PurposeGuardProvider
|
|
*/
|
|
interface PurposeGuardProvider
|
|
{
|
|
/** @return list<PublishGuard> */
|
|
public function publishGuards(): array;
|
|
}
|