Events & Tourism

> Levererad i D-EVENTS milstolpe **`767f53a2.m-1`** (spec

• F13.00.01 Shipped

  event-tabellen som förstaklassig, tenant-skopad rad (kind major｜tournament_series｜camp｜corporate｜private｜tour_package, i18n-titel, period, tidszon, land, mjuka venue-/tävlingsreferenser)

  ✅ 767f53a2.m-1 (t-1)
• F13.00.02 Shipped

  Livscykeln draft → published → archived som ren, DB-fri statusmaskin i internal/events — inga FSM-if-satser i handlern, och medvetet INTE ett approval-flöde

  ✅ 767f53a2.m-1 (t-1)
• F13.00.03 Shipped

  Publiceringsgrind som faktiskt biter: tenantens default_locale i titeln, giltig period, aktivt land i nationskatalogen, laddbar IANA-zon och giltig slug — brist ⇒ 422 med SAMTLIGA fält-fel och oförändrad status

  ✅ 767f53a2.m-1 (t-1/t-2)
• F13.00.04 Shipped

  Arrangörens sex rutter (POST/GET /v1/events, GET/PATCH /v1/events/{id}, POST …/publish, POST …/archive) gatade på events:manage — även läsningarna; optimistisk låsning (428/412), idempotent skapande och EN audit-rad per lyckad mutation

  ✅ 767f53a2.m-1 (t-2)
• F13.00.05 Shipped

  Publik, oautentiserad, tvärs-tenant event-kalender (GET /v1/public/events[/{id}]) med from/to-fönster och country_code/kind-filter — exakt publicerade+publika rader i icke-arkiverade tenants

  ✅ 767f53a2.m-1 (t-2)
• F13.00.06 Shipped

  Publik projektion som WHITELIST (ingen status/tenant_id/org_node_id/version/is_public); ett utkast är byte-identiskt oskiljbart från ett okänt id

  ✅ 767f53a2.m-1 (t-2)
• F13.00.07 Shipped

  seed-events: deterministisk, konvergerande och tidsankrad fixtur — tre publicerade+publika rader (SWE major, SWE camp, FRA tour package) och de tre negativen som aldrig får synas publikt

  ✅ 767f53a2.m-1 (t-1)
• F13.00.08 Shipped

  Anmälan/biljetter (event_ticket_type, event_registration, event.capacity_sold) — se F13.02

  ✅ 767f53a2.m-2
• F13.00.09 Shipped

  Lägerdetaljer, resor, ackreditering, VIP och EVENT-tenantens livscykel

  ✅ m-3…m-11 (livscykeln levererad i 767f53a2.m-11, se F13.08)

> **Ägare:** D-EVENTS **`767f53a2.m-6`** (bud & utvärdering, planeringstidslinje,

• F13.01.01 Planned

  World Championship event management

  ⊘ delvis: m-6/m-7/m-8/m-9 har levererat bud, tidslinje, arenor, boende, transport, ceremonier, budget, ackreditering, volontärer och VIP-hospitality; raden som HELHET (ett mästerskaps hela livscykel) har ingen egen leverans
• F13.01.02 Planned

  Continental Championship management

  ⊘ samma som F13.01.01 — delarna levereras av m-6/m-7/m-8/m-9, aldrig raden som helhet
• F13.01.03 Shipped

  Event bid submission and evaluation — event_bid (sanktionsorgan, budget som heltal+valuta, publiksiffra, utvärderingspoäng 0—100, opak dokumentreferens), högst ETT icke-terminalt bud per event som DATABASINVARIANT, och beslutet registrerat genom F1-6-typen event_bid (OnApprove ⇒ awarded + stämplat decision_on; inlämnaren kan aldrig besluta sitt eget ärende)

  ✅ 767f53a2.m-6 (t-1 backend + t-2 fliken *Bud & utvärdering* på /evenemang, inkl. eventlistans kolumn *Sanktion* ur budets eget fält; bevis tools/gate/devents-m6-e2e.mjs)
• F13.01.04 Shipped

  Event planning timeline and milestones — event_milestone med position som adress (upptagen plats ⇒ 409, aldrig en tyst ompackning), todo｜in_progress｜done och completed_at som SERVERNS stämpel; mjuk radering frigör platsen

  ✅ 767f53a2.m-6 (t-1 backend + t-2 fliken *Tidslinje* med Upp/Ned som positions-PATCH och serverns 409 i klartext; bevis tools/gate/devents-m6-e2e.mjs)
• F13.01.05 Shipped

  Venue selection and approval — event_venue_link (mjuk venue_ref inom tenanten, roll, banantal) med resolverad arenaprojektion i EN join och F1-6-typen event_venue_link (OnApprove ⇒ approved). Länken är ett GODKÄNNANDE, aldrig en bokning — homologering/inspektion ägs av D-VENUE

  ✅ 767f53a2.m-6 (t-1 backend + t-2 fliken *Venues* med arenaväljare ur GET /v1/venues och ärlig venue_resolved-degradering; bevis tools/gate/devents-m6-e2e.mjs)
• F13.01.06 Shipped

  Accommodation management for delegations — event_lodging_allotment (förhandlat rumsblock hos ett EXTERNT boende: enhet room｜bed, optionens utgång som en DAG, statusmaskinen enquiry→quoted→contracted + cancelled med status-sömmen som ENDA skrivare) och event_lodging_assignment (delegationens andel, bunden till en RIKTIG anmälningsrad — aldrig en fritextruta). Kapaciteten är MÄTT (sum(quantity) under for update på blockraden i samma transaktion), aldrig en räknarkolumn: två samtidiga fördelningar ger exakt en 201 och en 409

  ✅ 767f53a2.m-7 (t-1 backend + fixtur; kontrakt specs/api/endpoints/major-event-hosting.md)
• F13.01.07 Shipped

  Transport logistics coordination — event_transport_line (shuttle-/transferplanen: två ändpunkter, turtäthet där null betyder ÄRLIGT "på beställning", trafikfönstret som väggklocka HH:MM båda-eller-ingen, flotta som antal × platser, statusmaskinen planned→quoted→booked + cancelled). Linjen är en PLAN — ruttplanering, kartor och fordonsspårning är icke-mål

  ✅ 767f53a2.m-7 (t-1 backend + fixtur; kontrakt specs/api/endpoints/major-event-hosting.md)
• F13.01.08 Shipped

  Accreditation system (players, officials, VIP, volunteers) — accreditation (ansökan → F1-6-beslut → utfärdat pass → återkallelse) med den SLUTNA zonvokabulären som databasinvariant, accreditation_zone_grant (BR30:s event-zon, request-typen event_zone_access, F1-7-svepet accreditation_zone_access_expiry), QR-passets HMAC-token med PINNAD domänseparation (tom nyckel ⇒ 503, aldrig ett osignerat pass; tokenet lagras aldrig — pass_kid är ett nyckel-ID) och grinden POST /v1/accreditations/scan som ren beslutsfunktion med pinnad ordning (tenant → kid → status → fönster → zon) och append-only-logg där VARJE nekande skrivs. media ingår INTE — den kedjan är D-COMM:s (040878a9.m-6), och API:t avvisar kategorin med 422 + hänvisning i stället för att skapa en andra sanningskälla

  ✅ 767f53a2.m-8 (t-1 backend + fixtur; kontrakt specs/api/endpoints/accreditation.md; adminfliken *Ackreditering*, appkortet och den publika ytan levereras i t-2)
• F13.01.09 Shipped

  Ceremony planning (opening, closing, medal) — event_ceremony (i18n-titel, tider, MJUK venue_ref som resolvas till venue eller ÄRLIGT null, producent, körschema, flaggprotokoll där custom kräver sin not) med publiceringen som EGEN söm och grinden "titel i tenantens default_locale". Den publika programpanelen GET /v1/public/events/{id}/ceremonies är en EXAKT whitelist på åtta fält — producer/flag_protocol/is_published läcker aldrig

  ✅ 767f53a2.m-7 (t-1 backend + publik rutt + fixtur; kontrakt specs/api/endpoints/major-event-hosting.md)
• F13.01.10 Shipped

  VIP and hospitality management — event_suite + vip_package (tier bronze｜silver｜gold｜platinum, de slutna inclusions/amenities-vokabulärerna som DATABASINVARIANTER, publicering som EGEN söm — aldrig via PATCH) + vip_booking + vip_booking_guest: priset LÅSES på bokningen (unit_price_minor/currency/deposit_pct/final_payment_due_at snapshottas ur paketet, D-4), summorna HÄRLEDS (events.SplitDeposit — depositionen avrundad, slutbetalningen som RESIDUAL, D-5), platserna MÄTS under radlås och confirmed/completed skrivs ENBART av F1-11:s OnSuccess-hookar (vip_booking_deposit/vip_booking_final). Ingen publik köpväg (D-10 — VIP säljs som avtal; publikt finns bara den STÄNGDA läsprojektionen GET /v1/public/events/{id}/vip-packages, som exkluderar opublicerat i SQL:en och aldrig bär concierge_content)

  ✅ 767f53a2.m-9 (t-1 backend + fixtur; kontrakt specs/api/endpoints/vip-hospitality.md; adminfliken *VIP & hospitality* och den publika VIP-sektionen levereras i t-2)
• F13.01.11 Shipped

  Event budget and P&L tracking — event_budget_line + event.budget_currency: pengar som HELTAL i minsta enhet med TECKNET i kind (revenue｜cost), serverns egna totaler (forecast_*_minor + täckningen lines_with_actual) och ett MÄTT utfall ur evenemangets egna bekräftade anmälningar. En rad utan källa svarar actual: null — aldrig 0 — och bekräftade pengar i en annan valuta ger currency_mismatch i stället för en påhittad kursomräkning

  ✅ 767f53a2.m-7 (t-1 backend + fixtur; kontrakt specs/api/endpoints/major-event-hosting.md)

> **Ägare:** D-EVENTS **`767f53a2.m-2`** (anmälan, biljetter, betalning via arrangörens

• F13.02.01 Shipped

  Spectator ticket sales (online) — publikt, oautentiserat köp med engångs-token + kvitto, serverberäknat pris, atomisk kapacitet och fall 2-betalkedja (arrangörens eget konto)

  ✅ 767f53a2.m-2 (t-2)
• F13.02.02 Shipped

  Ticket types (day pass, full event) — event_ticket_type-katalogen med pris/valuta som heltal, kapacitet, försäljningsfönster, max_per_order, publicerings-flagga och pris-frysning när typen bär en betald anmälan

  ✅ 767f53a2.m-2 (t-1/t-2)
• F13.02.03 Shipped

  Delegation registration (national teams) — subject_kind='delegation' skapar en F1-6-begäran av typen delegation (ingen egen FSM); beslut fattas på de generiska steg-endpointerna

  ✅ 767f53a2.m-2 (t-2)
• F13.02.04 Shipped

  Media accreditation requests — ägs av D-COMM, inte av D-EVENTS (raden var FELRIKTAD): media_credential med publik ansökan, F1-6-beslut, QR-kort och egen grind ligger i 040878a9.m-6. D-EVENTS m-8 bygger därför varken tabell, ansökan, beslut, QR eller grind för media och rör aldrig D-COMM:s rader — category='media' på ackrediteringsrutten svarar 422 validation_failed med en detail som pekar på POST /v1/public/media-credentials/apply

  ✅ 040878a9.m-6 (D-COMM; se även m-8:s avvisning i specs/api/endpoints/accreditation.md § *media — känt men avvisat*)
• F13.02.05 Shipped

  Volunteer registration and management — subject_kind='volunteer' öppnad på m-2:s BÅDA anmälningsdörrar (autentiserad + publik, m-2:s ordning verbatim): UTAN biljettyp (ticket_type_id ⇒ 422), utan belopp, utan att ta en åskådarplats och med reserved_until = null — hållningssvepet rör henne aldrig. Formulärfälten (role_preference mot skiftens egen slutna rollmängd, availability, message) bor i event_volunteer_profile (1—1) skriven i SAMMA transaktion, och gästkvittot bär hennes EGNA pass (volunteer_shifts) utan att m-2:s whitelist luckras upp

  ✅ 767f53a2.m-8 (t-1 backend + fixtur; kontrakt specs/api/endpoints/volunteers.md; adminfliken *Volunteers* och den publika volontärsektionen levereras i t-2)
• F13.02.06 Shipped

  Volunteer shift scheduling — volunteer_shift (sluten rollmängd, fönster, kapacitet, is_open_for_signup) + volunteer_assignment som EGEN rad: bemanningen MÄTS (count(*) under for update på skiftraden i samma transaktion), lagras aldrig, och tilldelningens ordning är kontrakt — radlås → anmälan → dubblett → överlapp → kapacitet → insert ⇒ 409 volunteer_shift_full｜…_overlap｜volunteer_assignment_exists. Den FÖRSTA accepterade tilldelningen flippar anmälan reserved → confirmed genom m-2:s EGEN övergång; en avbokning STÄNGER raden (withdrawn), den raderas aldrig, och ett pass med levande tilldelningar går inte att ta bort (409 volunteer_shift_in_use)

  ✅ 767f53a2.m-8 (t-1 backend + fixtur; kontrakt specs/api/endpoints/volunteers.md)
• F13.02.07 Planned

  Event merchandise pre-orders

  ⊘ ingen ägare — m-9 byggde VIP-hospitality och INTE merch; varken D-KIOSK eller BILL har en förbeställningsmodell (m-2:s spec §2 faktum 16)
• F13.02.08 Shipped

  Kapacitet som databasen avgör: två villkorade UPDATE:ar (typ → event), noll rader ⇒ 422 event_sold_out — sista platsen kan inte översäljas under samtidighet

  ✅ 767f53a2.m-2 (t-1/t-2)
• F13.02.09 Shipped

  Hållningens TTL + F1-7-svepet event_registration_hold_expiry: en förfallen obetald reservation avbokas och SLÄPPER sin plats; en sen betalning återtar platsen om den finns, annars flaggas den för återbetalning

  ✅ 767f53a2.m-2 (t-2)
• F13.02.10 Shipped

  Arrangörens anmälningslista + kapacitetsöversikt (allt räknat i SQL) och avbokning som släpper platsen; en betald anmälan avbokas aldrig tyst utan pengaflöde

  ✅ 767f53a2.m-2 (t-2)

> **Ägare:** D-EVENTS **`767f53a2.m-3`** (läger-/turistpaketkatalogen, instruktörerna,

• F13.03.01 Shipped

  Training camp directory (find camps worldwide) — camp-tabellen + publika, oautentiserade, tvärs-tenant katalogen GET /v1/public/camps och den publika turismytan /resor (sektionen *Träningsläger*) med serverfiltrering på nivå, land, period och destination

  ✅ 767f53a2.m-3 (t-1/t-2)
• F13.03.02 Shipped

  Petanque travel packages (tournament + accommodation) — ett turistpaket ÄR ett event av kind tour_package med camp-detaljer (ingen egen pakettabell, D-15); egen katalogsektion på /resor och kopplingen till tävlingen via event-radens befintliga mjuka competition_ref

  ✅ 767f53a2.m-3 (t-1/t-2)
• F13.03.03 Planned

  Destination guides (best boulodromes, local clubs, events)

  ⊘ D-CMS (redaktionellt innehåll; m-3 renderar ingen attrapp)
• F13.03.04 Planned

  Travel companion finder (players looking for travel partners)

  ⊘ ingen ägare — funktionen finns inte i D-EVENTS vision och ingen annan domän äger den
• F13.03.05 Planned

  Club exchange program facilitation

  ⊘ D-CMS (visionen kallar det *"publikt katalog-/CMS-innehåll"*)
• F13.03.06 Planned

  Petanque-friendly accommodation directory

  ⊘ ingen ägare — ingen boendedomän finns i huset
• F13.03.07 Shipped

  Lägrets katalogfält: destination, nivå (app-validerad lista), includes (boende/måltider/transfer/banor/utrustning + måltidsplan), minsta deltagarantal och en mjuk media_ref mot D-COMM:s bibliotek — bilden serveras publikt av D-COMM:s egen gate, som prövar samtycket per anrop

  ✅ 767f53a2.m-3 (t-1/t-2)
• F13.03.08 Shipped

  Instruktörsprofiler per läger (camp_instructor: namn, roll, bio, ordning) med arrangörens credential-text märkt som arrangörens uppgift — huset har inget credential-register, så "verifierad certifiering" påstås aldrig (D-3; D-EDU äger den dagen den finns)

  ✅ 767f53a2.m-3 (t-1/t-2)
• F13.03.09 Shipped

  Katalogens från-pris är mätt, inte lagrat: from_price = minimum över eventets publika, säljbara biljettyper (m-2:s event_ticket_type); saknas en sådan typ står det *"Pris meddelas"* — aldrig 0 och aldrig en statisk reserv (D-2)

  ✅ 767f53a2.m-3 (t-1/t-2)
• F13.03.10 Shipped

  Kalenderintegration/krockdetektering mot andra event i samma land och period (GET /v1/camps/{id}/conflicts) — serverberäknad och rådgivande, aldrig en spärr (D-11)

  ✅ 767f53a2.m-3 (t-1/t-2)
• F13.03.11 Shipped

  Arrangörskonsolen /lager-turistpaket bakom camp:manage: listan, flaggan för läger-event utan detaljrad (D-8), If-Match-låst redigering, instruktörslistan, krockpanelen och anmälnings-/betalstatus ur m-2:s mätta kapacitetsöversikt bakom sin egen events:manage-grind

  ✅ 767f53a2.m-3 (t-2)
• F13.03.12 Planned

  Deltagarkommunikation runt lägret

  ⊘ D-COMM/D-PUSH — D-EVENTS emitterar event, äger inga kanaler (visionens Out of scope)
• F13.03.13 Planned

  Recensioner av läger (review_summary)

  ⊘ ingen ägare — varken substrat, behörighetsmodell eller moderering finns (D-4); venue_reviews är D-VENUE:s anläggningsrecensioner

> **Ägare:** D-EVENTS **`767f53a2.m-9`** (VIP-paket, suiter, deposit- och slutbetalningsflöde —

• F13.04.01 Shipped

  Corporate event booking (team building, company tournaments) — private_event_package_template (kind='corporate') + private_event_booking med prislås (pricing_model/unit_price_minor/currency/deposit_pct/gästspannet snapshotas ur mallen, D-3) och statusmaskinen enquiry → deposit_pending → confirmed, cancelled terminal. Ingen approval_request: en företagsdag är ett avtal, inte ett ärende

  ✅ 767f53a2.m-10 (t-1 backend + fixtur; adminkonsolen /event-bokningar i t-2)
• F13.04.02 Shipped

  Private event organization (weddings, parties) — samma kedja med kind ∈ {wedding, party, conference}; bröllopets tomma banscope (court_ids = '{}') betyder hela anläggningen, upplöst i debiteringsögonblicket (D-6), så en bana som läggs till efteråt också blockeras

  ✅ 767f53a2.m-10 (t-1)
• F13.04.03 Planned

  Equipment rental for events

  ⊘ ingen ägare — m-10 bygger den inte (uttryckligt icke-mål i milestones/767f53a2.m-10/spec.md): mallens *ingår*-text är arrangörens egna ord, inte en artikelkatalog. D-EQUIP äger PL:s EGEN uthyrning av poängtavlekit, inte en anläggnings festutrustning
• F13.04.04 Planned

  Event instructor/animator booking

  ⊘ ingen ägare — m-10 bygger den inte (uttryckligt icke-mål): huset har inget instruktörsregister med tillgänglighet att boka mot (m-3:s camp-instruktörer är arrangörens uppgift, user_ref alltid null). En bokningsknapp mot en tom katalog vore en yta som ljuger
• F13.04.05 Shipped

  Event package pricing and booking — pricing_model (per_person｜flat) + price_minor/currency på mallen; totalen härleds av events.PrivateEventTotal och depositionen av den återanvända events.SplitDeposit (BR29.01, default 30 %, 0 = ingen deposition ⇒ bokningen bekräftas utan betalrad i samma rutt). Ingen handler räknar en procent, ingen klient sätter ett pris (ett belopp i kroppen ⇒ 422)

  ✅ 767f53a2.m-10 (t-1)
• F13.04.06 Shipped

  VIP hospitality tiers (Bronze/Silver/Gold/Platinum) per event — vip_package per major-event med tier ur den slutna mängden, i18n-namn, inclusions[] som DDL-check (en okänd förmån går inte att lagra — ytan skriver ut den i klartext för en betalande gäst), pris + deposit_pct + final_payment_due_at som paketets egna fält, och is_published som flippas ENBART via POST …/publish｜unpublish. Depositionen (BR28.01) och slutbetalningen (BR28.02) körs som fall 2-betalningar mot arrangörens EGET payee-konto (PAY-2-resolvat), och F1-7-svepet vip_final_payment_sweep initierar residualen vid förfallodagen — det debiterar aldrig tyst (D-9; ett off-session-mandat ägs av PAY-3)

  ✅ 767f53a2.m-9 (t-1)
• F13.04.07 Shipped

  Suite-allokering med oversubscription-skydd — event_suite (kapacitet, view_type, amenities[] som DDL-check) och POST /v1/vip-packages/{id}/allocate-suite: select … for update på suiteraden FÖRE mätningen sum(seats) över suitens levande paket, i SAMMA transaktion som skrivningen ⇒ två samtidiga allokeringar mot samma sista platser ger exakt en 200 och en 422 vip_suite_oversubscribed (BR28.03, kod oförändrad). Samma disciplin på bokningen: paketets rest mäts under for update på paketraden ⇒ 422 vip_capacity_exceeded (BR28.04). Flera paket får dela en suite så länge summan ryms; ett if i handlern hade sett grönt ut sekventiellt och fallit under samtidighet

  ✅ 767f53a2.m-9 (t-1)
• F13.04.08 Shipped

  VIP concierge content pack — vip_package.concierge_content (jsonb, app-validerad form) är arrangörens REDIGERADE innehåll: synligt för arrangören och i bokningens läsvy, aldrig i den publika projektionen (det tillhör den betalande gästen). Bokförd avvikelse (D-11): *intro-video, talking points och player storylines* som GENERERAT innehåll byggs inte — ingen domän i huset producerar dem, och en knapp som fabricerar text är en yta som ljuger; mockupens *"Generate today's package"* finns därför inte

  ✅ 767f53a2.m-9 (t-1) för det redigerade paketet · ⊘ ingen ägare för genererat innehåll
• F13.04.09 Shipped

  Wedding/corporate package templates per venue (photogenic profile, availability, deposit-flow) — mallen bär photogenic_profile_i18n (publiceringsgrindens andra krav, visas publikt), availability_note_i18n (en TEXT, ingen regelmotor) och deposit_pct; tillgängligheten är en rådgivande fråga (POST /v1/private-events/availability) över båda källorna (icke-cancelled court_bookings + planned｜confirmed court_allocations, BR29.02) medan det bindande skyddet är GiST-EXCLUDE-constrainten ⇒ 409 venue_already_booked under samtidighet (D-5)

  ✅ 767f53a2.m-10 (t-1)
• F13.04.10 Shipped

  Private-event QR-checkin-kit (A4 4-up A6 cards, signed JWT per gäst) — GET …/qr-kit.pdf renderar ceil(guest_count/4) A4-sidor on-demand i Go (bokförd avvikelse D-8: ingen blob, ingen signed URL — inget artefaktläckage och ingen inaktuell fil), korten bär m-8:s tokenform med EGET domänprefix och bokningens eventfönster, POST …/rotate-qr dödar varje utskrivet kort och POST /v1/private-events/scan fäller verdiktet mot RADEN + skriver en private_event_checkin_scan-rad (incheckade MÄTS som distinkta guest_idx med allowed, D-9). Saknad master ⇒ 503, aldrig ett osignerat kort

  ✅ 767f53a2.m-10 (t-1); adminflikens incheckningsläge i t-2 (⊘ ingen app-skanner — D-9)
• F13.04.11 Shipped

  Photogenic venue profile + discover-grid (heritage, garden, capacity-filter) — GET /v1/public/private-event-packages (ingen auth, ingen tenant-header) med serverns filter kind/country/guests och en STÄNGD projektion (code, kind, name, photogenic_profile, includes, price, gästspannet, venue {name, city, country}) — aldrig tenant_id, court_ids, is_published, deposit_pct eller kontaktdata. Förfrågan (POST /v1/public/private-event-enquiries) går bakom klubb-inquiryns tre mjuka abuse-grindar. Ingen publik kassa (D-10): ett privat event prissätts i dialog

  ✅ 767f53a2.m-10 (t-1 backend + kontrakt; den publika ytan i t-2)

> **Ägare:** D-CMS (redaktionellt innehåll). Ingen D-EVENTS-milstolpe äger raderna — de är kultur-/heritage-innehåll, inte logistik.

• F13.05.01 Planned

  Petanque history and heritage content

  ⊘ D-CMS
• F13.05.02 Planned

  Hall of fame / legends registry

  ⊘ D-CMS
• F13.05.03 Planned

  Historic competition archive

  ⊘ D-CMS
• F13.05.04 Planned

  Museum and exhibition listings

  ⊘ D-CMS
• F13.05.05 Planned

  Cultural events calendar (festivals, exhibitions)

  ⊘ D-CMS

> **Ägare:** D-EVENTS m-4/m-5 (tävlingsresor, hotell/transfer bakom leverantörsneutralt interface, rese-koordinatorrollen). Ingen av dem är byggd ännu.

• F13.06.01 Planned

  Hotel booking for competitions via Booking.com API

  ⊘ m-4/m-5
• F13.06.02 Planned

  Travel schedule per player/team

  ⊘ m-4/m-5
• F13.06.03 Planned

  Bus/transfer booking

  ⊘ m-4/m-5
• F13.06.04 Planned

  Travel coordinator role in admin

  ⊘ m-4/m-5
• F13.06.05 Planned

  Per-player travel expenses and accounting

  ⊘ m-4/m-5

> **Ägare:** D-EVENTS **`767f53a2.m-4`** (byggarens och förbundets sida: de tre tabellerna

• F13.07.01 Shipped

  Squad-itinerary CRUD per event/training-camp (team manager-ägd) — squad_itinerary med optimistisk låsning, framåt-bara statusmaskin (draft → active → completed), audit per mutation och konsolen /resor med lista, skapa-flöde och If-Match-låst redigering

  ✅ 767f53a2.m-4 (t-1/t-2)
• F13.07.02 Shipped

  Traveller-management (player/coach/medical/staff) med passnumret som secret-referens (pl-kv://, aldrig klartext i något lager) — de tre skyddade fälten är frånvarande nycklar för den som varken är resans manager eller bär events:traveller:read, och ytan visar då *"Skyddat fält"* i stället för ett tomt redigerbart fält

  ✅ 767f53a2.m-4 (t-1/t-2)
• F13.07.03 Shipped

  Itinerary-leg-management (flight/train/transfer/hotel/meal/training/meeting/match) — legs adresserade på seq (upptagen plats ⇒ 409, aldrig en tyst ompackning), resenärstilldelning där tom lista = hela delegationen, status på sin egen rutt och ändringsflippen (materiell PATCH ⇒ changed; ett rent seq-byte flippar aldrig) med märket i konsolen

  ✅ 767f53a2.m-4 (t-1/t-2)
• F13.07.04 Shipped

  Flygstatus-pollen (BR27.04) via den leverantörsneutrala porten FlightStatusProvider — jobbet itinerary_flight_poll (F1-7, now injicerad, batch-takat, per-rad-felhantering) sveper legs med kind='flight' + external_ref på AKTIVA resor och skriver kolumnen flight_status, den enda kod som gör det. Deterministisk mock lokalt/test (PL1042 ⇒ delayed), ingen adapter i produktion ⇒ ärligt överhopp med logg i stället för en status ingen observerat; en störning flippar leggen till changed genom SAMMA söm som managerns egen ändring och emitterar notisen, medan första observationen null → on_time skriver kolumnen UTAN flip och UTAN notis (brus är inte omtanke). Resenären ser flygets eget märke i appen först när något faktiskt observerats

  ✅ 767f53a2.m-5 (t-1/t-2)
• F13.07.05 Shipped

  Per-resenär filtrerad /me-vy med kalenderexport (BR27.01) — GET /v1/itineraries/{id}/me (självguardad på tokenets sub; icke-resenär och draft-resa ⇒ 404, oskiljbart från okänt id), självlistan GET /v1/me/itineraries, självmutationen av MINA kost-/tillgänglighetsnoter (hård whitelist + If-Match) och ICS-exporten GET /v1/itineraries/{id}/me.ics på husets BEFINTLIGA calendar_feed_token med stabila UID:n (itinerary:<leg-id> — en flyttad leg uppdateras i stället för att dubbleras) plus källan i det personliga flödet. Appens yta /min-resa: tidslinjen i UTC, mina skyddade fält (passnumret som referensens EXISTENS, aldrig maskerade siffror), ICS-knappen och offline-läget med ärlig hämtningstidpunkt

  ✅ 767f53a2.m-5 (t-1/t-2)
• F13.07.06 Shipped

  itinerary_changed-notisen till påverkade resenärer (BR27.03) — emissionsfanouten dispatchar genom D-COMM:s pipe till unionen av leggens adresserade resenärer FÖRE och EFTER mutationen (tom traveller_ids = alla; en resenär som lyfts bort är påverkad), best-effort EFTER commit så ett pipe-fel aldrig fäller mutationen. [ÄNDRAT] -prefixet byggs i KOD (variabeln change_label), inte i en tenants mall, så det inte kan tappas bort; katalogposten bär variabelkontraktet och seeden lägger en aktiv in_app-mall i demo-tenanten. Ett rent seq-byte, en no-op-PATCH och en mutation på ett utkast ger NOLL dispatcher. Kanalerna (e-post/SMS/push) ägs oförändrat av D-COMM/D-PUSH

  ✅ 767f53a2.m-5 (t-1/t-2)
• F13.07.07 Shipped

  National-team squad-submission: utbytesfilen petanque-life-v1 (delegation ur staff/coach, spelare med licensnummer och verifierings-URL på husets EGEN publika verifieringsrutt) med deadline-spårning (CEP −2 mån / FIPJP −3 mån ur eventets start) — ett saknat obligatoriskt spelarfält är ett fältfel travellers.<id>.<kolumn>, aldrig en tom sträng i en fil ett förbund agerar på, och konsolens räknare läser serverns deadline_at/overdue

  ✅ 767f53a2.m-4 (t-1/t-2)

> Levererad i D-EVENTS milstolpe **`767f53a2.m-11`** (spec

• F13.08.01 Shipped

  Self-service-onboarding av event-arrangör genom D-SIGNUP:s befintliga publika intag (org_type=event + de två valfria full-dates expected_first_event_date/expected_end_date); en ren public_form-ansökan auto-godkänns synkront genom samma maskinflip som affiliate, medan operator_created behåller operatörens veto. Abuse-grindarna (honeypot, turnstile) står orörda framför allt

  ✅ 767f53a2.m-11 (t-1)
• F13.08.02 Shipped

  Provisionering med tenant_type='event', depth 0 och inga org_nodes — plus livscykelprofilen och den SMALA rollmallen event_organiser_admin ⇒ exakt {events:manage, camp:manage} på första admin, allt i samma transaktion som tenanten. Ingen ny capability införs

  ✅ 767f53a2.m-11 (t-1)
• F13.08.03 Shipped

  Venue-/host-länkning som F1-6-ärende (event_tenant_link) i måltenantens scope med ETT sekventiellt steg (tenant-config.manage): pending → accepted｜rejected｜revoked, OnApprove skriver dessutom tenant_peer_link-raden och revoke tar bort den. Ingen egen FSM, ingen egen beslutsrutt — beslutet fattas på motorns generiska steg-endpoints

  ✅ 767f53a2.m-11 (t-1)
• F13.08.04 Shipped

  Länktvånget: en EVENT-tenants evenemang får peka på en annan tenants arena först när motparten sagt ja (422 event_tenant_venue_link_required). Egen/null venue_ref och alla andra tenant-typer är oförändrade, och ett redan tilldelat evenemang påverkas aldrig av ett senare återkallande

  ✅ 767f53a2.m-11 (t-1)
• F13.08.05 Shipped

  Publik per-tenant-kalender (GET /v1/public/tenants/{code}/events) — m-1:s publika projektion återanvänd (ingen andra projektion), from/to som överlappning, och 404 i exakt samma form för okänd kod, arkiverad och suspenderad tenant (sonderingslagen)

  ✅ 767f53a2.m-11 (t-1)
• F13.08.06 Shipped

  Livscykelprofilen (GET｜PATCH /v1/tenant/event-lifecycle, If-Match obligatorisk, whitelist-PATCH) och arrangörens egen arkivering (POST …:archive) genom husets ENDA livscykelsöm. En arkiverad tenant svarar 409 read_only_tenant medan läsningarna lever vidare — bokförd avvikelse mot legacy-specens 410

  ✅ 767f53a2.m-11 (t-1)
• F13.08.07 Shipped

  Auto-arkiveringen som F1-7-jobb (event_tenant_auto_archive, dagligen): 30 dygn efter deklarerat serieslut, inget framtida evenemang och automatiken på. Single-fire (villkoren står i själva skrivningen), klockan injiceras, batchen är takad — och predikatet är EN ren funktion som jobbet och sys-vyns kandidatflagga delar

  ✅ 767f53a2.m-11 (t-1)
• F13.08.08 Shipped

  Operatörens läs-bara flottöversikt (GET /v1/sys/event-tenants) med MÄTTA tal (events_total, events_future, links_pending, links_accepted, äldsta väntande länkens ålder) och kandidatflaggan. Ingen mutationsrutt finns under prefixet — operatören ser flottan, arrangören äger sin miljö

  ✅ 767f53a2.m-11 (t-1)
• F13.08.09 Shipped

  Fixtur i seed-events: TVÅ demo-arrangörer drivna genom exakt det riktiga intaget + fast-tracken, ETT publicerat publikt demo-evenemang, EN accepterad host-länk mot SWE (motorns egen Approve), EN öppen begäran mot FRA och den andra arrangörens arkivering genom jobbets egen söm — konvergent, tidsankrad och ägar-skopad

  ✅ 767f53a2.m-11 (t-1)
• F13.08.10 Planned

  Migration till host-tenant (POST /event-tenant/{id}/migrate-to-host)

  ⊘ uttryckligt non-goal i m-11 — att flytta event-, anmälnings- och resultatrader mellan tenants är ett eget arbete; halvbyggd hade den varit värre än obyggd
• F13.08.11 Planned

  Ytorna: webbintagets event-delta, adminens arrangörskonsol och sys-sektionen

  ⊘ 767f53a2.m-11 t-2