crewli/dev-docs/ARCH-CONSOLIDATION-WS1-REPORT.md

---
title: ARCH Consolidation — WS-1 Discovery Report
description: Read-only architecture scan output for the April 2026 consolidation sprint
status: draft
owner: architect
created: 2026-04-24
---

# WS-1 — Discovery Pass Report

> Output of the read-only architecture scan kicked off by
> `/dev-docs/ARCH-CONSOLIDATION-2026-04.md` WS-1. Read together with the
> consolidation charter before WS-2 starts. This report is discovery-only:
> **no code, no migrations, no tests were changed.**

## 0. Scan scope and method

- **Date of scan:** 2026-04-24
- **Branch:** `main`
- **Commit scanned:** `f9cc8c0a1be4093c7508df90dcdbe12ebbdb390a`
- **Tools used:** `grep` (via Bash), targeted `Read` on migrations/models/services, four parallel `Explore` sub-agents for breadth. No AST-grep, no static-analysis tooling.
- **In scope:** `api/database/migrations/`, `api/app/Models/` (incl. `FormBuilder/`), `api/app/Models/Scopes/`, `api/app/Services/`, `api/app/Http/Controllers/`, `api/app/Http/Resources/`, `api/app/Http/Requests/`, `api/app/Listeners/`, `api/app/Observers/`, `api/app/Policies/`, `api/app/Providers/`, `api/app/Events/`, `api/app/FormBuilder/`, `api/config/`.
- **Explicitly NOT scanned:** `apps/app/`, `apps/portal/`, `packages/`, `vendor/`, `node_modules/`, `resources/vuexy-admin-*/`, `api/tests/`, VitePress docs at `/docs/`.

---

## 1. Summary table

| ID   | Category | Target                                                                 | Classification                        | Proposed WS |
|------|----------|------------------------------------------------------------------------|---------------------------------------|-------------|
| A-01 | A        | `organisation_user`                                                    | documented-exception-confirm-in-ws4   | ws-4        |
| A-02 | A        | `event_user_roles`                                                     | documented-exception-confirm-in-ws4   | ws-4        |
| A-03 | A        | `crowd_list_persons`                                                   | documented-exception-confirm-in-ws4   | ws-4        |
| A-04 | A        | `event_person_activations`                                             | documented-exception-confirm-in-ws4   | ws-4        |
| A-05 | A        | `user_organisation_tags`                                               | documented-exception-confirm-in-ws4   | ws-4        |
| A-06 | A        | `person_section_preferences`                                           | documented-exception-confirm-in-ws4   | ws-4        |
| A-07 | A        | `mfa_backup_codes`                                                     | documented-exception-confirm-in-ws4   | ws-4        |
| A-08 | A        | `mfa_email_codes`                                                      | documented-exception-confirm-in-ws4   | ws-4        |
| A-09 | A        | `form_submission_section_statuses`                                     | documented-exception-confirm-in-ws4   | ws-4        |
| A-10 | A        | `form_values`                                                          | documented-exception-confirm-in-ws4   | ws-4        |
| A-11 | A        | `form_value_options`                                                   | documented-exception-confirm-in-ws4   | ws-4        |
| B-01 | B        | `form_fields.binding`                                                  | scheduled-ws5                         | ws-5a       |
| B-02 | B        | `form_fields.validation_rules`                                         | scheduled-ws5                         | ws-5b       |
| B-03 | B        | `form_fields.conditional_logic`                                        | scheduled-ws5                         | ws-5c       |
| B-04 | B        | `form_fields.options`                                                  | scheduled-ws5                         | ws-5d       |
| B-05 | B        | `form_field_library.options`                                           | needs-architect-decision              | ws-5d?      |
| B-06 | B        | `form_field_library.validation_rules`                                  | needs-architect-decision              | ws-5b?      |
| B-07 | B        | `form_field_library.default_binding`                                   | needs-architect-decision              | ws-5a?      |
| B-08 | B        | `form_fields.role_restrictions`                                        | needs-architect-decision              | ws-5 / backlog |
| B-09 | B        | `form_fields.translations`                                             | opaque-keep                           | —           |
| B-10 | B        | `form_field_library.translations`                                      | opaque-keep                           | —           |
| B-11 | B        | `form_schemas.settings`                                                | opaque-keep                           | —           |
| B-12 | B        | `form_submissions.schema_snapshot`                                     | opaque-keep                           | —           |
| B-13 | B        | `form_templates.schema_snapshot`                                       | opaque-keep                           | —           |
| B-14 | B        | `form_values.value`                                                    | opaque-keep                           | —           |
| B-15 | B        | `form_webhook_deliveries.payload_snapshot`                             | opaque-keep                           | —           |
| B-16 | B        | `shifts.events_during_shift`                                           | opaque-keep                           | —           |
| B-17 | B        | `persons.custom_fields`                                                | opaque-keep                           | —           |
| B-18 | B        | `person_identity_matches.match_details`                                | opaque-keep                           | —           |
| B-19 | B        | `user_profiles.settings`                                               | opaque-keep                           | —           |
| B-20 | B        | `organisations.settings`                                               | opaque-keep                           | —           |
| B-21 | B        | `events.recurrence_exceptions`                                         | opaque-keep                           | —           |
| B-22 | B        | `activity_log.properties` / `.attribute_changes`                       | opaque-keep (Spatie-owned)            | —           |
| C-01 | C        | `form_schemas.owner_type / owner_id`                                   | domain-justified-keep                 | —           |
| C-02 | C        | `form_submissions.subject_type / subject_id`                           | domain-justified-keep                 | —           |
| C-03 | C        | `activity_log.subject/causer_type`                                     | domain-justified-keep (Spatie)        | ws-7 (index) |
| C-04 | C        | `personal_access_tokens.tokenable_*` (Sanctum)                         | needs-architect-decision              | ws-8        |
| D-01 | D        | Missing migrations for ~30 SCHEMA-documented tables                    | scope-addition-ws-8                   | ws-8        |
| D-02 | D        | `OrganisationScope` has no `form_schema_id` / chain-via-FK strategy    | scope-addition-ws-4 / needs-decision  | ws-4 / new-ws |
| D-03 | D        | Form-builder child models not applying `OrganisationScope`             | scope-addition-ws-4                   | ws-4        |
| D-04 | D        | `ShiftAssignment` / `ShiftWaitlist` / `VolunteerAvailability` without scope | scope-addition-ws-4               | ws-4        |
| D-05 | D        | `Person` has no `SoftDeletes` reachable in model (verify)              | standalone-fix (verify)               | ws-4        |
| D-06 | D        | `activity_log` polymorph columns lack `(type, id)` index               | scope-addition-ws-7                   | ws-7        |
| D-07 | D        | Morph map in `AppServiceProvider` registers 6 owner types, only `event` used | standalone-fix (docs)             | ws-8        |
| D-08 | D        | `form_submissions.subject_type` allow-list lives in two places (`config/form_subjects.php` + morph map) | standalone-fix | ws-2 / ws-8 |

**Counts per category:** `A: 11, B: 22, C: 4, D: 8` (total findings: 45).

---

## 2. Category A — Non-ULID primary keys

ULID baseline established by SCHEMA §3.5.11 Rule 1 and ARCH §3 besluit 5 ("ULID consistent overal, ook pivots"). All other business tables (40+ tables) use ULID correctly and are not listed individually. Only the non-ULID tables appear below.

### A-01 — `organisation_user`
- **Current PK type:** `int AI` (via `$table->id()`)
- **Source of truth:** `api/database/migrations/2026_04_07_210000_create_organisation_user_table.php:14` — inline comment `// int AI for join performance`. No model (pure pivot).
- **SCHEMA.md section:** §3.5.1 — documented as pivot, no ULID mandate.
- **Classification:** `documented-exception-confirm-in-ws4`
- **Note:** Pure pivot (user ↔ organisation). ARCH §3 besluit 5 demands ULID everywhere including pivots; this is the canonical example of a decision to re-confirm or reverse.

### A-02 — `event_user_roles`
- **Current PK type:** `int AI`
- **Source of truth:** `api/database/migrations/2026_04_07_240000_create_event_user_roles_table.php:14` — comment `// int AI for join performance`. No model.
- **SCHEMA.md section:** §3.5.1 — pivot-like (event ↔ user ↔ role).
- **Classification:** `documented-exception-confirm-in-ws4`

### A-03 — `crowd_list_persons`
- **Current PK type:** `int AI`
- **Source of truth:** `api/database/migrations/2026_04_08_240000_create_crowd_list_persons_table.php:14`. No model.
- **SCHEMA.md section:** §3.5.5 — pivot (crowd list ↔ person).
- **Classification:** `documented-exception-confirm-in-ws4`

### A-04 — `event_person_activations`
- **Current PK type:** `int AI`
- **Source of truth:** `api/database/migrations/2026_04_08_410000_create_event_person_activations_table.php:14`. No model.
- **SCHEMA.md section:** §3.5.5 — join table (event ↔ person) tracking sub-event activation.
- **Classification:** `documented-exception-confirm-in-ws4`

### A-05 — `user_organisation_tags`
- **Current PK type:** `int AI`
- **Source of truth:** `api/database/migrations/2026_04_10_110000_create_user_organisation_tags_table.php:14`. Model: `api/app/Models/UserOrganisationTag.php` — **does not** use `HasUlids`.
- **SCHEMA.md section:** §3.5.5a — pivot (user ↔ organisation ↔ person_tag).
- **Classification:** `documented-exception-confirm-in-ws4`
- **Note:** A model *exists* here, unlike A-01/A-02/A-03/A-04. If WS-4 confirms the ULID mandate for pivots, this migration is non-trivial: existing keys referenced by the model must be rewritten.

### A-06 — `person_section_preferences`
- **Current PK type:** `int AI`
- **Source of truth:** `api/database/migrations/2026_04_12_200003_create_person_section_preferences_table.php:14`. Model: `api/app/Models/PersonSectionPreference.php` — no `HasUlids`.
- **SCHEMA.md section:** §3.5.5b.
- **Classification:** `documented-exception-confirm-in-ws4`

### A-07 — `mfa_backup_codes`
- **Current PK type:** `int AI`
- **Source of truth:** `api/database/migrations/2026_04_15_200001_create_mfa_backup_codes_table.php:14`. Model: `api/app/Models/MfaBackupCode.php` — no `HasUlids`.
- **SCHEMA.md section:** §3.5.1a.
- **Classification:** `documented-exception-confirm-in-ws4`
- **Note:** Security-adjacent table. Potential rationale: ephemeral rows, high turnover, single-owner lookup. Flag for WS-4 explicit decision.

### A-08 — `mfa_email_codes`
- **Current PK type:** `int AI`
- **Source of truth:** `api/database/migrations/2026_04_15_200003_create_mfa_email_codes_table.php:14`. Model: `api/app/Models/MfaEmailCode.php` — no `HasUlids`.
- **SCHEMA.md section:** §3.5.1a.
- **Classification:** `documented-exception-confirm-in-ws4`

### A-09 — `form_submission_section_statuses`
- **Current PK type:** `int AI`
- **Source of truth:** `api/database/migrations/2026_04_19_100007_create_form_submission_section_statuses_table.php:14`. Model: `api/app/Models/FormBuilder/FormSubmissionSectionStatus.php` — no `HasUlids`.
- **SCHEMA.md section:** §3.5.12.
- **Classification:** `documented-exception-confirm-in-ws4`

### A-10 — `form_values`
- **Current PK type:** `int AI`
- **Source of truth:** `api/database/migrations/2026_04_19_100009_create_form_values_table.php:15` — explicit comment: `// Integer AI PK: EAV table, joined heavily — int joins faster than ULID joins (ARCH §4.4).` Model: `api/app/Models/FormBuilder/FormValue.php` — no `HasUlids`.
- **SCHEMA.md section:** §3.5.12 (form_values).
- **Classification:** `documented-exception-confirm-in-ws4`
- **Note:** The migration's inline comment references `ARCH §4.4` — a rationale predating the consolidation charter. ARCH-CONSOLIDATION §3 besluit 5 overrides that rationale unless the architect confirms the EAV performance exception.

### A-11 — `form_value_options`
- **Current PK type:** `int AI`
- **Source of truth:** `api/database/migrations/2026_04_19_100010_create_form_value_options_table.php:14`. Model: `api/app/Models/FormBuilder/FormValueOption.php` — no `HasUlids`.
- **SCHEMA.md section:** §3.5.12.
- **Classification:** `documented-exception-confirm-in-ws4`
- **Note:** Populated by `FormValueObserver`; rebuilt on every form value save. Volatile pivot data.

---

### Category A — summary

- **Total non-ULID tables:** 11 business tables + 14 framework/Spatie/Laravel tables (all expected, not listed).
- **Undocumented violations:** none — every non-ULID PK either has an inline migration comment justifying it, or is a pure pivot without a model.
- **WS-4 decision needed:** all 11 tables. ARCH §3 besluit 5 says "ULID consistent overal, ook pivots" without exceptions — so the migration comments stating "int AI for join performance" are now in conflict with the charter. WS-4 must explicitly confirm (retain exceptions) or reverse (migrate all).

---

## 3. Category B — JSON columns with queryable data

Rule 2 whitelist (SCHEMA §3.5.11): opaque config, free-text arrays, rider data, submission diff snapshots, events_during_shift. No JSON path query (`whereJsonContains`, `JSON_EXTRACT`, `->>`, `whereJsonLength`, etc.) was found anywhere in the backend. Every JSON column is read as a whole blob via the cast array. Classification therefore leans heavily on charter decisions and column intent, not on observed query patterns.

**Note on legacy tables:** migration `2026_04_20_100000_drop_remaining_legacy_registration_tables.php` already dropped `registration_form_fields`, `registration_field_templates`, and `person_field_values`. Their JSON columns are not part of the current schema and are not listed here.

### B-01 — `form_fields.binding`
- **Current use:** Conditional logic binding config (computed fields, dynamic visibility). Read as blob, validated/applied during submission in `FormValueService`.
- **Sample usage:** `api/app/Services/FormBuilder/FormValueService.php` (accesses `$field->binding`)
- **Classification:** `scheduled-ws5` (ARCH §3 besluit 6, WS-5a)
- **Proposed target:** new `form_field_bindings` table per ARCH §6.1.

### B-02 — `form_fields.validation_rules`
- **Current use:** Field validation schema (min/max, regex, required, tag_categories). Read as blob, passed to `FormFieldRuleBuilder` for runtime validation.
- **Sample usage:** `api/app/Services/FormBuilder/FormValueService.php` (`is_array($field->validation_rules)…`)
- **Classification:** `scheduled-ws5` (WS-5b)
- **Proposed target:** `form_field_validation_rules` table per ARCH §6.6.

### B-03 — `form_fields.conditional_logic`
- **Current use:** Skip-logic and visibility rules (if X=Y, show this field). Read as blob to extract dependent field slugs.
- **Sample usage:** `api/app/Services/FormBuilder/FormFieldService.php` (`extractConditionSlugs()`)
- **Classification:** `scheduled-ws5` (WS-5c)
- **Proposed target:** `form_field_conditional_logic` table. Charter flags AND/OR tree shape as sub-decision during WS-5c.

### B-04 — `form_fields.options`
- **Current use:** Field-specific UI metadata (select choices, radio buttons). Read as whole blob in resources.
- **Sample usage:** `api/app/Http/Resources/FormBuilder/FormFieldResource.php`
- **Classification:** `scheduled-ws5` (WS-5d)
- **Proposed target:** `form_field_options` table per ARCH §6.6.

### B-05 — `form_field_library.options`
- **Current use:** Library-level default UI options copied to new fields at instantiation.
- **Sample usage:** `api/app/Services/FormBuilder/FormFieldService.php`
- **Classification:** `needs-architect-decision`
- **Proposed target:** if WS-5d splits `form_fields.options` into its own table, should the library-level defaults follow the same split or remain inline? Two consistent outcomes: (a) split both (library becomes a template row in the new options table), (b) keep library JSON as opaque "seed-data" and hydrate on instantiation. Needs a call before WS-5d starts.

### B-06 — `form_field_library.validation_rules`
- **Classification:** `needs-architect-decision` — same shape of decision as B-05, but for validation rules.

### B-07 — `form_field_library.default_binding`
- **Classification:** `needs-architect-decision` — same shape as B-05, but for bindings.
- **Note:** The migration column name (`default_binding`) suggests it was designed to pre-fill a binding on new fields. If WS-5a's `form_field_bindings` table is the target, the natural mapping is "library rows may define default bindings which are cloned". Architect to confirm.

### B-08 — `form_fields.role_restrictions`
- **Current use:** Role-based visibility (portal-only, admin-only) read in `FieldAccessService`.
- **Sample usage:** `api/app/Services/FormBuilder/FieldAccessService.php` (`$field->role_restrictions…`)
- **Classification:** `needs-architect-decision`
- **Reason:** Not in ARCH's committed WS-5 split list, but semantically akin to a queryable enum set. If WS-5 is expanded to "everything structured on form_fields becomes relational", this one belongs with them; if WS-5 is kept to the four committed splits, it stays JSON.

### B-09 / B-10 — `form_fields.translations`, `form_field_library.translations`
- **Current use:** I18n label/help text overrides per field. Read-only, per-field UI.
- **Classification:** `opaque-keep` — translations are flat key-value bags by locale, not queried anywhere. Splitting them into a relational translations table would be speculative.

### B-11 — `form_schemas.settings`
- **Current use:** Form-level configuration blob. Charter explicitly (§3 besluit 6) says `form_schemas.settings` should *shrink* to "echt opaque config (rendering hints)" after WS-5 completes. Today the blob is small and read as-is.
- **Classification:** `opaque-keep` — provided WS-5 a/b/c/d land. Re-confirm at end of WS-5 that nothing queryable has crept back in.

### B-12 / B-13 / B-15 — `form_submissions.schema_snapshot`, `form_templates.schema_snapshot`, `form_webhook_deliveries.payload_snapshot`
- **Current use:** Immutable snapshots for audit/replay.
- **Classification:** `opaque-keep` — SCHEMA.md Rule 2 explicitly allows submission diff snapshots.

### B-14 — `form_values.value`
- **Current use:** EAV storage of actual answers. Filtering is done via denormalised `value_indexed`, `value_number`, `value_date` typed columns; the `value` JSON itself is read as a blob.
- **Classification:** `opaque-keep`
- **Note:** This is an intentional EAV+denormalised-filter-column pattern. Valid as long as the typed columns cover all filter cases; WS-5/WS-6 should verify that when bindings read answers, they read from the typed columns or from the cast array, not via JSON path.

### B-16 — `shifts.events_during_shift`
- **Classification:** `opaque-keep` — whitelisted in Rule 2.

### B-17 — `persons.custom_fields`
- **Current use:** Legacy registration-time extras (section preferences and similar). Read as blob.
- **Sample usage:** `api/app/Http/Controllers/Api/V1/ShiftAssignmentController.php` (accesses `custom_fields['section_preferences']`)
- **Classification:** `opaque-keep` — but flag for WS-6 FormBindingApplicator: once bindings land, `custom_fields` becomes redundant for bindable attributes. Track shrinkage after WS-6 lands so this column can be reassessed (deletion → BACKLOG, not sprint scope).

### B-18 — `person_identity_matches.match_details`
- **Classification:** `opaque-keep` — scoring metadata, never queried on nested keys.

### B-19 — `user_profiles.settings`
- **Classification:** `opaque-keep`.

### B-20 — `organisations.settings`
- **Classification:** `opaque-keep`.

### B-21 — `events.recurrence_exceptions`
- **Current use:** Array of excluded dates (RFC 5545 EXDATE pattern).
- **Classification:** `opaque-keep` — flat date list, never queried on positions.

### B-22 — `activity_log.properties` / `attribute_changes`
- **Classification:** `opaque-keep` (Spatie-managed).

---

### Category B — summary

- **Queryable-must-split found in practice:** 0. No `whereJsonContains`, `JSON_EXTRACT`, or `->>` usage exists anywhere in the backend.
- **Scheduled WS-5 splits confirmed:** 4 (`form_fields.binding`, `.validation_rules`, `.conditional_logic`, `.options`).
- **Open architect decisions:** 4 (`form_field_library.options`, `.validation_rules`, `.default_binding`, `form_fields.role_restrictions`).
- **Genuinely opaque (keep):** 14.

---

## 4. Category C — Polymorphic relations

### C-01 — `form_schemas.owner_type / owner_id`
- **Defined in:** `api/database/migrations/2026_04_19_100002_create_form_schemas_table.php:18–19`. Model: `api/app/Models/FormBuilder/FormSchema.php:92` (`owner()`).
- **Allowed types (observed):** morph map registers `event`, `user`, `user_profile`, `person`, `company`, `organisation`. Only `event` is actively used in queries (`FilterRegistryController`, `PublicFormController`). The other five are placeholders for future purposes (USER_PROFILE etc.).
- **Morph map status:** fully registered in `api/app/Providers/AppServiceProvider.php:73–122` via `Relation::enforceMorphMap(...)`.
- **Index on (type, id):** yes — `$table->index(['owner_type', 'owner_id'], 'fs_owner_idx')`.
- **Classification:** `domain-justified-keep` (ARCH §1 P4).

### C-02 — `form_submissions.subject_type / subject_id`
- **Defined in:** `api/database/migrations/2026_04_19_100006_create_form_submissions_table.php:20–21`. Model: `FormSubmission.php:80` (`subject()`). Inverse example: `Person.php:108` (`formSubmissions()`).
- **Allowed types (observed):** `person`, `user`, `user_profile`, `company`, `organisation`, `event` — same morph map keys as C-01. Active uses in `FieldAccessService`, `FormSubmissionService` (via `morphKeyFor()`).
- **Morph map status:** registered (same provider).
- **Index on (type, id):** yes — `fs_subject_idx`.
- **Classification:** `domain-justified-keep` (ARCH §1 P4).

### C-03 — `activity_log.subject_type/subject_id` and `causer_type/causer_id`
- **Defined in:** `api/database/migrations/2026_04_07_120000_create_activity_log_table.php:17, 19` via `nullableMorphs()`.
- **Allowed types (observed):** ~23 domain models + 8 form-builder models, all registered in the single `enforceMorphMap` call.
- **Morph map status:** fully registered; `Activity::saving` hook in `AppServiceProvider.php:145–161` adds impersonation context.
- **Index on (type, id):** **no** — `nullableMorphs()` does NOT auto-create a `(type, id)` composite index, unlike `morphs()` and `ulidMorphs()`. The pair is unindexed on both `subject_*` and `causer_*`.
- **Classification:** `domain-justified-keep` (Spatie-framework); **WS-7 should add indexes** if/when the activity log is queried by subject.

### C-04 — `personal_access_tokens.tokenable_type / tokenable_id`
- **Defined in:** `api/database/migrations/2026_04_07_100000_create_personal_access_tokens_table.php:15` via `ulidMorphs('tokenable')`.
- **Allowed types (observed):** Sanctum default (`User` in practice); no morph-map entry.
- **Morph map status:** NOT in `enforceMorphMap` — Sanctum uses FQCN in the DB.
- **Index on (type, id):** yes — `ulidMorphs()` auto-indexes.
- **Classification:** `needs-architect-decision`
- **Note:** Low urgency. If the team wants strict morph-map consistency ("no FQCN in DB anywhere"), add a `user` alias and document in ARCH. Otherwise leave Sanctum alone. Decide in WS-8 when docs are rewritten.

---

### Category C — summary

- **Polymorphs found:** 4 relation pairs (2 domain, 2 framework).
- **Domain polymorphs both justified and correctly indexed:** C-01, C-02.
- **Framework polymorphs:** C-03 (Spatie), C-04 (Sanctum).
- **Only real action item:** C-03 missing `(type, id)` index — candidate scope-addition for WS-7.
- **No inconsistency:** no logical relation is modelled polymorphically in one place and typed-FK in another. No unused single-target polymorphs (C-01 has only `event` in active use today, but the other five owner types are committed purpose targets per ARCH §3 besluit 4, so keeping it polymorphic is justified).

---

## 5. Category D — Other architecture smells

### D-01 — Many tables documented in SCHEMA.md have no migration
- **Location:** SCHEMA.md §3.5.4, §3.5.6, §3.5.7, §3.5.8, §3.5.9 vs `api/database/migrations/`.
- **Smell:** The following tables are fully documented in SCHEMA.md but no `Schema::create(...)` migration exists for them:
  - §3.5.4: `volunteer_festival_history`, `post_festival_evaluations`, `festival_retrospectives`
  - §3.5.6: `accreditation_categories`, `accreditation_items`, `event_accreditation_items`, `accreditation_assignments`, `access_zones`, `access_zone_days`, `person_access_zones`
  - §3.5.7: `performances`, `stages`, `stage_days`, `advance_submissions`, `artist_contacts`, `artist_riders`, `itinerary_items`
  - §3.5.8: `briefing_templates`, `briefings`, `briefing_sends`, `communication_campaigns`, `messages`, `message_replies`, `broadcast_messages`, `broadcast_message_targets`
  - §3.5.9: `check_ins`, `show_day_absence_alerts`, `scanners`, `inventory_items`, `event_info_blocks`, `event_info_block_crowd_types`, `production_requests`, `material_requests`
- **Why it matters this sprint:** SCHEMA.md is the charter's stated "truth for 'as built'" (§3). Today it documents roughly 30 tables that don't exist. Rule 4 of §3.5.11 even prescribes required indexes on `check_ins`, `briefing_sends`, `performances`, `advance_sections`, `person_section_preferences` — two of those (`check_ins`, `briefing_sends`) have no table. WS-8's SCHEMA rewrite needs to either (a) remove these and move them to a separate "Planned modules" document, or (b) mark each row as `STATUS: planned`. Either way, SCHEMA.md cannot be trusted as-is during WS-4 through WS-7.
- **Proposed workstream:** `ws-8` (primary); also informs `ws-4` scope bounds (we don't migrate PKs on tables that don't exist).
- **Classification:** `scope-addition-ws-8`

### D-02 — `OrganisationScope` strategies don't cover `form_schema_id` or any FK chain beyond one level
- **Location:** `api/app/Models/Scopes/OrganisationScope.php` (whole file). Acknowledged explicitly in the class comment of `api/app/Models/FormBuilder/FormSchemaWebhook.php:13–22`: *"OrganisationScope's column strategies (organisation_id / event_id / festival_section_id) do not cover form_schema_id — extending the scope to a new strategy is out of scope for S1."*
- **Smell:** The scope supports only three strategies: direct `organisation_id`, via `event_id`, via `festival_section_id`. Form-builder child tables (`form_schema_sections`, `form_fields`, `form_submissions`, `form_values`, `form_value_options`, `form_submission_delegations`, `form_submission_section_statuses`, `form_schema_webhooks`, `form_webhook_deliveries`) all scope via `form_schema_id` or deeper — none of which the scope can resolve. The `FormSchemaWebhook` comment calls out the caller discipline required: *"NEVER query FormSchemaWebhook::query() without an eager constraint."*
- **Why it matters this sprint:** The architecture's tenancy guarantee (`CLAUDE.md` > Multi-tenancy: "Every query on event data MUST scope on organisation_id") relies on developer discipline for these models instead of on a global scope. One forgotten eager constraint in a future controller is a cross-org data leak. WS-6 adds a new service (`FormBindingApplicator`) that will traverse submission → schema → org — exactly the path the scope doesn't currently model.
- **Proposed workstream:** `ws-4` (extend scope with a new strategy: `form_schema_id` and possibly a generic `through_fk_chain` strategy). Alternative: `new-ws` if the architect decides to solve this more broadly (e.g., declarative scope chain in models).
- **Classification:** `scope-addition-ws-4` (or `needs-architect-decision` for the "extend strategy" vs "add-on new-ws" split).

### D-03 — Form-builder child models don't register `OrganisationScope`
- **Location:** `api/app/Models/FormBuilder/FormSchemaSection.php`, `FormField.php`, `FormSubmission.php`, `FormValue.php`, `FormValueOption.php`, `FormSubmissionDelegation.php`, `FormSubmissionSectionStatus.php`, `FormSchemaWebhook.php`, `FormWebhookDelivery.php`.
- **Smell:** None of the 9 form-builder child models call `static::addGlobalScope(new OrganisationScope())`. `FormSchema`, `FormFieldLibrary`, `FormTemplate` do register it (direct `organisation_id`). The child models rely on the caller-discipline workaround in D-02.
- **Why it matters this sprint:** Same as D-02 (tenancy leak risk via direct `Model::query()` calls), but here the fix does not require extending the scope class — it requires either adopting a new strategy once D-02 is resolved, or denormalising `organisation_id` onto the child tables (which ARCH §3 besluit 3 already commits to for `form_submissions`).
- **Proposed workstream:** `ws-4` (coupled to D-02). Note that charter §3 besluit 3 already commits to adding `organisation_id` to `form_submissions` — so `FormSubmission` is trivially fixable by the existing `organisation_id` strategy. The remaining 8 models still need D-02's extension.
- **Classification:** `scope-addition-ws-4`

### D-04 — Non-form-builder event-data models missing `OrganisationScope`
- **Location:** `ShiftAssignment.php`, `ShiftWaitlist.php`, `VolunteerAvailability.php`, `PersonSectionPreference.php`, `PersonIdentityMatch.php`, `UserInvitation.php`, `EmailChangeRequest.php`, `EmailLog.php`, `UserOrganisationTag.php`, `ImpersonationSession.php`, `MfaBackupCode.php`, `MfaEmailCode.php`, `TrustedDevice.php`, `UserProfile.php`, `OrganisationEmailSettings.php`, `OrganisationEmailTemplate.php`.
- **Smell:** Several of these are event-data (`ShiftAssignment`, `ShiftWaitlist`, `VolunteerAvailability`, `PersonSectionPreference`, `PersonIdentityMatch`) and should apply `OrganisationScope` via one of the existing strategies (`festival_section_id`, `event_id` on parents). Others (`MfaBackupCode`, `MfaEmailCode`, `TrustedDevice`, `UserProfile`, `OrganisationEmailSettings/Templates`, `EmailLog`, `EmailChangeRequest`, `UserInvitation`, `ImpersonationSession`) are user-scoped or organisation-scoped audit/admin data where the scope's suitability depends on intent (is this a per-user record, a per-org admin record, or a cross-org super-admin record?).
- **Why it matters this sprint:** At minimum the five event-data models (`ShiftAssignment`, `ShiftWaitlist`, `VolunteerAvailability`, `PersonSectionPreference`, `PersonIdentityMatch`) are tenancy-leak-prone and in the hot path for WS-5 and WS-6 work. Fixing them now with existing strategies (`festival_section_id` via parent Shift; `event_id` on the model; or denormalised `organisation_id` for the Person-identity models) is low-cost and unblocks safer refactor work downstream.
- **Proposed workstream:** `ws-4` for event-data models. User/admin-scoped items: `backlog` with a separate ticket per model.
- **Classification:** `scope-addition-ws-4`

### D-05 — Verify `Person` has `SoftDeletes` (SCHEMA Rule 3 YES list)
- **Location:** `api/app/Models/Person.php` — verify trait usage.
- **Smell:** Rule 3 lists `persons` in the soft-delete-YES list. Most of the YES-list models were spot-checked OK. `Person.php` was not directly verified line-by-line during the scan — before WS-2 start, verify `use SoftDeletes` is present on both the model and as `$table->softDeletes()` in the `create_persons_table.php` migration.
- **Why it matters this sprint:** If `Person` lacks soft delete but SCHEMA says it should have it, the ARTIST_ADVANCE / EVENT_REGISTRATION workflows (WS-6) cannot rely on documented recovery semantics.
- **Proposed workstream:** `ws-4` (trivial verification + fix if needed).
- **Classification:** `standalone-fix (verify first)`

### D-06 — `activity_log` morph columns lack `(type, id)` composite indexes
- **Location:** `api/database/migrations/2026_04_07_120000_create_activity_log_table.php:17, 19` — `nullableMorphs()` does not auto-index.
- **Smell:** If any admin feature needs "show all activity for this person" or "what did user X do", the query is a full-scan on `subject_type`/`causer_type`.
- **Why it matters this sprint:** Observability (WS-7) is likely to surface queries that need these indexes — better to add them while we're already migrating.
- **Proposed workstream:** `ws-7` (observability foundation likely drives the first such queries).
- **Classification:** `scope-addition-ws-7`

### D-07 — Morph map registers 6 owner types for form_schemas, only one (`event`) in practice
- **Location:** `api/app/Providers/AppServiceProvider.php:73–122`; usage: `api/app/Http/Controllers/Api/V1/FilterRegistryController.php`, `PublicFormController.php`.
- **Smell:** `event`, `user`, `user_profile`, `person`, `company`, `organisation` are all registered as `form_schemas.owner_type` possibilities, but five of the six are never assigned anywhere. Charter §3 besluit 4 commits to seven purposes (EVENT_REGISTRATION, ARTIST_ADVANCE, SUPPLIER_INTAKE, POST_EVENT_EVALUATION, INCIDENT_REPORT, SIGNATURE_CONTRACT, USER_PROFILE) — so the registered types are forward-looking, not dead.
- **Why it matters this sprint:** Not an architectural issue today. Documentation item for WS-8: explicitly link the morph-map entries to the purpose registry so that reviewers can see *why* each owner type is registered even when unused. Avoids a future `"why is `organisation` in the morph map?"` half-day of archaeology.
- **Proposed workstream:** `ws-8` (docs).
- **Classification:** `standalone-fix`

### D-08 — `form_submissions.subject_type` allow-list in two places
- **Location:** `api/config/form_subjects.php` (used by `StoreFormSubmissionRequest` validation) vs `api/app/Providers/AppServiceProvider.php:73–122` (morph map).
- **Smell:** Both files list the allowed subject types. They are expected to stay in sync, per a comment in `AppServiceProvider`, but the sync is enforced by developer discipline only — no test or compile-time guard.
- **Why it matters this sprint:** WS-2 (purpose registry) is the natural place to consolidate. If purposes define their `subject_type` via value object (per charter §6.4), then both `config/form_subjects.php` and the morph map entries can be derived from the same source.
- **Proposed workstream:** `ws-2` (consolidate into purpose registry), or `ws-8` (docs-only, if the de-dupe isn't done).
- **Classification:** `scope-addition-ws-2`

---

### Category D — summary

- **Tenancy-leak-prone models without scope:** 14 (9 form-builder + 5 other event-data). Fixable within WS-4 provided `OrganisationScope` gets a `form_schema_id` strategy.
- **Scope class itself needs extension:** 1 (D-02).
- **Indexes missing on framework polymorph:** 1 (`activity_log`).
- **SCHEMA.md drift:** ~30 tables documented without migrations — a WS-8 problem, not a WS-4 problem.
- **Duplication between config and morph map:** 1 (D-08).
- **Verification needed before fix:** 1 (`Person` soft-delete, D-05).

---

## 6. Scope implications

### WS-2 — Purpose registry
- **Scope:** confirmed + minor expansion.
- **Addition:** D-08 — merge `config/form_subjects.php` into the purpose registry so that `subject_type` per purpose comes from one source. Lightweight.

### WS-3 — Eén SPA consolidatie
- **Scope:** unchanged by WS-1. Frontend-only workstream; this scan did not cover it.

### WS-4 — ULID consistency + denormalized submission columns
- **Scope:** significantly expanded.
- **Confirmed in initial list:** pivot-ULID migration for A-01 through A-11 (if architect reaffirms besluit 5). `organisation_user`, `event_user_roles`, `crowd_list_persons`, `event_person_activations` were implied but not explicit; `mfa_backup_codes`, `mfa_email_codes` and `user_organisation_tags` are additions to the initial charter expectations. `form_values` and `form_value_options` carry the strongest inline-comment justification to keep — flag them as the first exceptions the architect must rule on.
- **Added:** D-02 (extend `OrganisationScope` with `form_schema_id` strategy), D-03 (register scope on 9 form-builder child models), D-04 (register scope on 5 event-data non-form models), D-05 (verify `Person` soft-delete). Denormalised `organisation_id` on `form_submissions` (besluit 3) makes D-03 easier for `FormSubmission` specifically.
- **Risk:** WS-4 as written was 2-3 days. With D-02/D-03/D-04 additions, expect 4-5 days.

### WS-5 — JSON-kolom-opsplitsing
- **Scope:** confirmed for WS-5a/b/c/d on `form_fields`. **Open questions:** B-05, B-06, B-07 (library-level JSON mirrors) and B-08 (`role_restrictions`) — architect to rule before WS-5 starts.
- **Minimum viable:** if architect rules "library stays JSON, `role_restrictions` stays JSON", WS-5 is exactly the 4 committed splits.
- **Maximum scope:** if architect rules "all three library columns + role_restrictions also split", that adds 4 more sub-workstreams to WS-5.

### WS-6 — FormBindingApplicator
- **Scope:** confirmed. No surprises.
- **Addition:** when the applicator writes back to `persons.custom_fields` (B-17), document the shrinkage plan so B-17 can move from `opaque-keep` to `deprecated-remove` in a later sprint.

### WS-7 — Observability foundation
- **Scope:** confirmed + small addition.
- **Addition:** D-06 — add `(subject_type, subject_id)` and `(causer_type, causer_id)` indexes on `activity_log` when the observability stack starts asking questions of the log.

### WS-8 — Documentation consolidation
- **Scope:** expanded significantly.
- **Addition D-01 is the big one.** SCHEMA.md has ~30 tables documented without migrations. WS-8 must decide: (a) extract them into `/dev-docs/ARCH-PLANNED-MODULES.md` and reduce SCHEMA.md to built-only tables, or (b) add a `status: planned` marker per row. Either way WS-8 is no longer "rewrite v2.0 of SCHEMA.md" but "reduce SCHEMA.md to reality + separate planned-module doc".
- **Additions D-07, D-08 (partial), C-04:** all docs/clarification work that lands naturally here.
- **Risk:** WS-8 as written was 2-3 days. With D-01 added, expect 4-5 days; the "planned modules" document is non-trivial because it has to preserve the indexing/soft-delete intent SCHEMA.md captured.

### Candidates for backlog or a new workstream
- **None require a new workstream** — all findings map cleanly onto WS-2/4/5/7/8. D-02 might warrant a mini-WS ("scope extension") if the architect wants to solve the FK-chain problem generically rather than adding a `form_schema_id` strategy.

---

## 7. Questions for the architect

Ordered by how much they block downstream scoping; answer before WS-2 starts.

1. **Re-confirm or reverse ARCH §3 besluit 5 ("ULID overal, ook pivots") for the 11 non-ULID tables in Category A.** Pivots with inline "int AI for join performance" comments (A-01 – A-04) are straightforward pivot-exception candidates. `form_values` and `form_value_options` (A-10, A-11) cite `ARCH §4.4` in the migration itself as performance rationale — is that rationale still valid, or overridden by the consolidation charter? Either answer is fine; both must be explicit.

2. **Does `OrganisationScope` grow a new strategy, or do we denormalise `organisation_id` onto every form-builder child table?** D-02 + D-03 are the same problem from two angles. A new `form_schema_id` strategy is one migration to the scope class. Denormalising columns is ~8 migrations plus backfill. Pick one approach for WS-4.

3. **Scope of WS-5: four committed columns, or also the three library mirrors (B-05/06/07) and `role_restrictions` (B-08)?** Keeping WS-5 to just `form_fields` is the minimum charter commitment; expanding to library + role_restrictions makes the form-builder relational story complete in one sprint but adds 3-4 days.

4. **`personal_access_tokens.tokenable` (C-04): add a morph-map alias for consistency, or leave Sanctum's default FQCN-in-DB pattern untouched?** Cosmetic; pick a direction so WS-8 can document it.

5. **WS-8 SCHEMA.md rewrite: "built-tables-only + separate planned-modules doc", or "single file with `status: planned` markers"?** D-01 means WS-8 has to pick a shape before starting the rewrite.

6. **`form_submissions.subject_type` allow-list (D-08): consolidate under WS-2 purpose registry, or leave the two-file pattern and add a CI test that keeps them in sync?** Either works; WS-2 scope depends on the answer.