RFC-TIMETABLE v0.2 Session 1 — Artist Timetable foundation #15
Reference in New Issue
Block a user
Delete Branch "feat/timetable-session-1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Wat
RFC-TIMETABLE v0.2 Session 1 — Artist Timetable & Engagement Module foundation.
Per RFC §12, Session 1 of 6. Closes BACKLOG: ARCH-09. Opens BACKLOG:
ART-OBSERVER-ADVANCE-AGGREGATE, RFC-TIMETABLE-V0.2-DOC-CLEANUP,
RFC-TIMETABLE-V0.2-PORTAL-TOKEN-SCHEMA-AMEND.
Belangrijkste deliverables
stages, stage_days, artist_engagements, performances, advance_sections,
advance_submissions)
app/Enums/Artist/with Dutch label() methodsper RFC §5.3-§5.4
delete cascade) and PerformanceObserver (D14 version bump)
12 engagements with status mix, 13 performances incl. parked + B2B pair)
PURPOSE_SUBJECT_FQCNswitched from string-literal toArtist::classRFC-traceability
enums + observers + dev fixture)
endpoints, frontend
Test delta
inverted advance_submissions retention assertion)
for same-shape pre-existing patterns; tracked under existing
TECH-LARASTAN-02 and TECH-LARASTAN-07 identifier tickets)
Doc updates
Deviations recorded
see RFC-TIMETABLE-V0.2-PORTAL-TOKEN-SCHEMA-AMEND
in place — see RFC-TIMETABLE-V0.2-DOC-CLEANUP
Volgt
Session 2 — Backend API + business logic (Spatie permissions, Policies,
Services, FormRequests, controllers, routes, activity log, scheduled
DemoteExpiredOptions command, transactional cascade-bump endpoint).
PortalTokenController stores hash('sha256', \$plainToken) — a 64-char hex digest. RFC v0.2 §5.3's "ULID unique nullable" annotation is loose; in practice the column holds a hash, not a ULID. char(26) silently truncates under MySQL strict mode (1406 Data too long) — surfaced when PortalTokenSecurityTest exercised the auth path against the new schema. Widen to varchar(64) to fit the hash. Schema dump regenerated against crewli_test. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>advance_submissions.advance_section_id FK changed from cascadeOnDelete to nullOnDelete; column made nullable. Aligns implementation with RFC v0.2 §5.4 audit-immutability ("submissions remain for retention compliance") — when ArtistEngagementObserver::deleted hard-deletes a section, its submissions persist as orphans rather than disappearing. Migration edited in place (branch unpushed, dev-only). Observer docblock + test assertion updated to match. Removed pre-existing follow-up comment that documented the deviation. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>Schema reality (varchar(64), accommodating SHA-256 hex digest) diverges from RFC v0.2 §5.3 ("ULID unique nullable"). Session 1 implementation is correct; RFC needs amendment in next legitimate cycle. Tracked under RFC-TIMETABLE-V0.2-PORTAL-TOKEN-SCHEMA-AMEND. Distinct from RFC-TIMETABLE-V0.2-DOC-CLEANUP (which covers stale cross-references). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>