docs: BACKLOG + ARCH-BINDINGS appendix + RFC v1.2 for registry alignment (WS-6)

Two new BACKLOG entries capture the deliberate v1 deferrals:

  - ARTIST-ADV-BINDING-MODEL — design how artist_advance form data
    relates to Artist + AdvanceSection entities (when, if ever, an
    Eloquent Artist class is needed, and whether bindings are even
    the right abstraction for OUTPUT-shaped advance forms).

  - FORM-BINDING-JSON-PATH — extend binding registry to support
    JSON-path attributes (custom_fields.dietary_preferences etc).
    For v1 the recommendation is TAG_PICKER + tag_categories config.

ARCH-BINDINGS.md gets an appendix explaining the v1 scope decisions
explicitly: why 'artist' has no registry entries (model class
absent + advance forms are OUTPUT-shaped, not provisioning-shaped),
why JSON-path attributes are out of scope (v1 is column-level only),
and how BindingTypeRegistryConsistencyTest prevents future drift.

RFC-WS-6.md → v1.2 with a §3 Q9 addendum tracking the registry
alignment + the 3 renames, 5 removals, and 1 new column landed in
this branch.

Refs: WS-6 sessie 3a binding-target drift audit, sessie 3a.5 cleanup

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

dev-docs/BACKLOG.md

@@ -1142,6 +1142,53 @@ staging-API. Separate workstream from WS-6.
 **Trigger:** pre-release hardening phase.
 **Refs:** RFC-WS-6.md §4 V4.
 
+#### ARTIST-ADV-BINDING-MODEL
+
+WS-6 v1 omits artist binding-target registry entries entirely. The
+artist_advance purpose accepts schemas without bindings (Artist subject
+resolved via portal_token, not via field-to-attribute mapping). For v2,
+decide:
+
+- Should there be an `Artist` Eloquent model class? Currently the
+  `artists` table exists but no class — only the morph map alias points
+  at `App\Models\Artist` (a string).
+- Which artist attributes are bindable from form data? The advance form
+  is OUTPUT-shaped: it gathers info FROM the artist (rider, hospitality,
+  technical needs); it does not provision Artist attributes the way
+  event_registration provisions Person attributes.
+- Is the binding model even the right abstraction for advance forms,
+  or do they use a different sync mechanism (e.g. typed AdvanceSection
+  fields)?
+
+**Trigger:** when v2 design discussions for artist_advance feature
+work begin. May result in registry entries, an Artist model, OR a
+domain-specific alternative to bindings.
+**Refs:** RFC-WS-6.md §3 Q9 v1.2 addendum, ARCH-BINDINGS.md appendix.
+
+#### FORM-BINDING-JSON-PATH
+
+WS-6 v1's binding-target registry handles only top-level model columns.
+JSON-path attributes (e.g. `persons.custom_fields.dietary_preferences`)
+are not bindable in v1. Adding support requires:
+
+- Registry shape extension (path-string syntax:
+  `'custom_fields.dietary_preferences'`)
+- Applicator's `setAttribute` change → typed json_set / array_set helper
+- Conflict resolution: do JSON-path siblings resolve independently?
+- Type-validation: dietary_preferences is a list, but custom_fields
+  itself is JSON — what does identity_key_eligible mean here?
+
+For v1 the recommendation: model dietary_preferences (and similar
+`custom_fields` properties) as a `TAG_PICKER` form_field with a
+tag_categories config. The TAG_PICKER → user_organisation_tags sync
+(per ARCH-FORM-BUILDER §31.10) handles this without requiring
+binding-target column mapping.
+
+**Trigger:** when an organisation requests dietary_preferences (or
+other `custom_fields` properties) as a form binding target. May
+coincide with Crewli's v2 dietary management feature work.
+**Refs:** RFC-WS-6.md §3 Q9 v1.2 addendum, ARCH-BINDINGS.md appendix.
+
 ---
 
 _Laatste update: April 2026_