# Behov og summering av utstyr

Dette dokumentet beskriver **produktregler** for hvordan systemet skal tenke på utstyrsbehov, summering og visning — ikke teknisk implementasjon (se `README.md`).

## Formål

Gi oversikt over **hva som trengs** til produksjon (per artist, per scene/dag, og aggregater), slik at teknikere og innkjøp kan planlegge. Systemet **lagrer ikke scenekapasitet** og **avgjør ikke** hva som må bestilles; det viser behov og fordeling slik data er registrert.

## Grunnenhet for «samtidig behov»

- Alle beregninger av **maks samtidig behov** og **gjenbruk over tid** gjelder **per scene og per dag**.
- To scener samme dag gir **to uavhengige** behovsprofiler (flytting av fysisk utstyr mellom scener er utenfor denne regelen).
- Festivalomspennende «én pool» brukes **ikke** i denne modellen med mindre det senere dokumenteres som eget behov.

## Maks samtidige (hovedregel)

For valgt **scene + dag** skal tallene reflektere **maksimalt behov som er aktivt på samme tid**, ikke summen av alle artister som spiller i løpet av dagen.

Praktisk tolkning: bruk **timeplan** (start/slutt) til å se når flere acts overlapper; for hvert tidspunkt summeres behovet for de som er aktive da — deretter tas **maksimum over dagen** for hver utstyrstype/gruppe dere summerer på.

## Sekvensiell gjenbruk

Utstyr som brukes **etter hverandre** (samme dag, samme scene) skal **ikke** dobbeltelles som om hvert show trenger egen kopi uten videre.

Eksempel: én Shure SM58 til vokal som brukes av to band i separate tidsluker uten overlapp — **ett** behov for den dagen på den scenen (innenfor samme ressursgruppe / summeringsnøkkel som teknikere er enige om).

## Spesifikasjon og merker

Alt som er angitt som **spesifikt** i data (modell, merke, detaljer i navn eller spec) skal **vises**. **Tekniker** gjør endelig tolkning, substitusjon og prioritering.

## Artist, band og medlemmer

- **Artist = band** er tilstrekkelig i dagens modell.
- Behov for **utstyr per bandmedlem** kan komme senere (egen dimensjon eller linjer) — påvirker primært **nedbryting** av oversikten, ikke nødvendigvis definisjonen av «samtidig» (medlemmer i samme band er vanligvis samtidige).

## Kilder (intern / ekstern / artist)

Systemet skal kunne vise **fordeling på kilde** slik det er bokført, typisk:

- **Intern** (venue / felles rigg)
- **Ekstern** (innleie)
- **Artist** (medbringer)

Dette er **beholdningsklassifisering i planen**, ikke automatisk avstemming mot kapasitet.

## Hva systemet ikke gjør (i denne spesifikasjonen)

- Lagrer **ikke** tilgjengelig kapasitet per scene eller per dag.
- **Bestemmer ikke** automatisk hva som må bestilles — det er tekniker/produksjon utenfor appens ansvar, basert på vist behov.

## Relasjon til data i `db.json`

- **Utstyr** ligger på `equipment` (artist, scene, antall, kategori, spec, kilde, status, osv.).
- **Når** artister spiller ligger i `schedule` / artists `performances` (dato, start, slutt, scene).

Fremtidige visninger og API-er som implementerer reglene over må bruke **både** utstyrsrader **og** programtider, og respektere avgrensningen **scene + dag**.

## Forutsetninger (implementasjon v1)

- **Kobling program ↔ utstyr:** For valgt **dag** og **scene** tas med artister som har minst én opptreden (`schedule` / `performances`) med `date` og `stage` som matcher. Utstyrsrader telles bare når **`equipment.stage` er lik valgt scene** og **`equipment.artist`** er en av disse artistene. Rader der utstyret er knyttet til en **annen** `equipment.stage` enn den valgte vises **ikke** i rapporten for den scenen (unngår feil scene; korriger data eller bruk annen fane).
- **Summeringsnøkkel:** Gruppering etter normalisert `cat` + normalisert `name` (små variasjoner i tekst kan gi flere nøkler til navn er ryddet).
- **To talltyper i visning/API:**
  - **Maks samtidig:** Sweep over dagen ut fra overlappende spilletider; for hver nøkkel summeres behov for alle artister som er **på scenen samtidig**, deretter tas **maksimum** over tid (sekvensiell gjenbruk: to band etter hverandre uten overlapp gir ikke addert topp for samme nøkkel).
  - **Kildekolonner (intern / ekstern / artist / ukjent):** Enkle **summer av `qty`** per `source` over alle utstyrsrader som inngår i nøkkelen for aktuelle artister den dagen på scenen — **ikke** tidssegmentert; det viser «hva som er bokført som ansvar/medbringer», ikke nødvendigvis samme tall som maks samtidig.

## Implementasjon (v1) i kodebasen

- **API:** `GET /api/behov?date=YYYY-MM-DD&stage=<stageId>` returnerer JSON med summer per nøkkel (se over). Lesing krever ikke admin.
- **Dokument i nettleser:** `GET /docs/behoov-summering` (samme markdown som denne filen).
- **UI:** Egen fane **Behov** i webappen med valg av dag og scene, tabell og kort hjelpetekst med lenke til dokumentet.
- **Logikk:** [`lib/behoov.mjs`](lib/behoov.mjs) (beregning), koblet fra [`server.mjs`](server.mjs). Tester: `npm run test:behoov`.