Config

# Real config for the "WPP at Scale" epic — the `wpp-at-scale` slug in
# epics.yaml. No secrets live here — those go in .env.local (gitignored).
# See README.md for setup + the daily routine.
#
# This is one epic's config, not the dashboard's: everything below (epic,
# milestones, people, weights) describes WPP at Scale alone, and a second
# epic gets its own directory beside this one. Run this epic's collection
# with `pnpm collect --epic wpp-at-scale`.
#
# Ticket keys, milestone/feature structure, and owner logins below were
# discovered via read-only JIRA/GitHub API queries and confirmed with the
# project owner. Items marked "PROVISIONAL" below are best-effort starting
# points, not confirmed final — edit freely as the real tier mapping
# becomes clearer.

epic:
  key: BOUN-11204
  title: "WPP at Scale"
  startDate: 2026-07-07 # PR search floor
  # Drives the pace line and the "ahead/behind" read on the burn-up. Change
  # it freely — the chart re-reads it on the next build, and snapshots
  # written before a target existed pick up the current one (see
  # resolveTargetDate in src/lib/dashboard/velocity.ts).
  targetDate: 2026-08-31

jira:
  projectKey: BOUN
  # Raw JIRA status name -> our SubtaskStatus. This is a base hint only —
  # deriveSubtaskStatus (src/lib/classify.ts) upgrades/downgrades it using
  # real GitHub PR state, so a stale "Done" without a shipped PR will not
  # render as shipped. Unmapped status names fall back to "todo" with a
  # console warning at collection time.
  statusMap:
    Done: shipped
    "Code Review": in_review
    # Code complete, waiting to go out with a release. Mapped to staged
    # rather than shipped: the ticket is finished, the code isn't live.
    "To Be Released": staged
    # Product's own review queue (see productReviewStatus below). Only a
    # base hint — a story here with a merged-to-master PR still derives
    # "shipped", and one with an open PR still derives "in_review". It
    # matters only when there's no PR evidence at all, where "somebody is
    # reviewing this" is the honest read.
    "Product Review": in_review
    "In Progress": in_progress
    "To Do": todo
    Blocked: blocked

  # Product sign-off, as of the August 2026 flow change. The old "Product
  # Approval" label no longer gates anything (its automations are off);
  # instead, moving an epic/milestone/feature ticket to Product Review
  # emails its product manager, and approval moves it straight to Done.
  # So for epic work, reaching Done *is* the sign-off.
  productReviewStatus: "Product Review"
  signedOffStatuses: ["Done"]
  # Legacy fallback for tickets approved under the old label-based flow.
  # Remove this line once every tracked feature has been through the new
  # status at least once.
  productSignOffField: customfield_10698

github:
  org: bounceinsights
  # Repos are NOT listed per feature. Every non-archived repo in the org
  # pushed since epic.startDate is searched on each run, and PRs are
  # attributed to subtasks by ticket key in the branch name or title.
  #
  # Listing repos per feature used to be the mechanism, and it silently
  # lost data: a ticket's work routinely spans a UI repo, its API and a
  # shared types package, so scoping the search to `[dashboard]` hid every
  # PR in dashboard-api, ts-types, admin-v2 and cron-api. About two thirds
  # of this epic's pull requests were invisible. Crawling all 25 active
  # repos instead takes ~10s, so there was never a performance reason for
  # the narrower scope either.
  excludeRepos: ["emulator-data"]   # never search these (noisy infra, vendored mirrors)
  includeRepos: []   # always search these, even if not pushed recently

timezone: Europe/Dublin

scoreWeights:
  shipped: 1.0
  # JIRA Done + product sign-off, but no PR proves the code reached
  # master. Weighted the same as shipped: sign-off counts toward
  # progress, but see the (separately tracked) doneUnverified count and
  # statusLabels.ts for why it's never displayed as plain "shipped".
  done_unverified: 1.0
  staged: 0.5
  in_review: 0.3
  in_progress: 0.15
  blocked: 0
  todo: 0

milestones:
  - id: M1
    title: "Core Operational Efficiency"
    tier: full
    owner: ruzwid
    ticket: BOUN-11205
    features:
      - key: BOUN-11207
        code: "F1.1"
        owner: ruzwid
      - key: BOUN-11208
        code: "F1.2"
        owner: VivekMurarkaIndIre
      - key: BOUN-11209
        code: "F1.3"
        owner: gelbh
      - key: BOUN-11210
        code: "F1.4"
        owner: gelbh
      - key: BOUN-11211
        code: "F1.5"
        owner: EmadNazzal

  - id: M2
    title: "Expansion & Follow-On Builds"
    # Full tier, matching M1: these are four different owners' active
    # feature work, where light tier is explicitly the condensed shape for
    # a single owner's milestone (see MethodologyFooter).
    tier: full
    owner: ruzwid
    ticket: BOUN-11206
    features:
      # Keys, codes and owners read from JIRA (children of BOUN-11206) on
      # 2026-08-12. Note F2.9 exists in JIRA but is absent from the
      # milestone description's "Features Included" list — the ticket tree
      # is the source of truth here, so it is tracked.
      - key: BOUN-11212
        code: "F2.1"
        owner: VivekMurarkaIndIre
      - key: BOUN-11213
        code: "F2.2"
        owner: ruzwid
      # Unassigned in JIRA (pending a decision from Walr) — owner defaults
      # to the milestone owner, same convention as DF4.1.1.
      - key: BOUN-11214
        code: "F2.3"
        owner: ruzwid
      - key: BOUN-11255
        code: "F2.4"
        owner: gelbh
      - key: BOUN-11340
        code: "F2.5"
        owner: EmadNazzal
      - key: BOUN-11341
        code: "F2.6"
        owner: ruzwid
      - key: BOUN-11423
        code: "F2.7"
        owner: gelbh
      - key: BOUN-11496
        code: "F2.8"
        owner: gelbh
      - key: BOUN-11514
        code: "F2.9"
        owner: gelbh

  - id: M3
    title: "WPP API Platform"
    tier: light
    owner: TonyCasey
    # M3 and M4 are always read together — one owner, one platform build —
    # so they share a sidebar section and one milestone filter chip. The
    # grouping used to be a hardcoded ["M3","M4"] in src/lib/dashboard/nav.ts,
    # which is exactly the kind of thing a second epic can't inherit.
    group: m3-m4
    ticket: BOUN-11290
    features:
      - key: BOUN-11291
        code: "F3.1"
        owner: TonyCasey
      - key: BOUN-11292
        code: "F3.2"
        owner: TonyCasey
      - key: BOUN-11293
        code: "F3.3"
        owner: TonyCasey
      - key: BOUN-11294
        code: "F3.4"
        owner: TonyCasey

  - id: M4
    title: "WPP Dashboard"
    # PROVISIONAL: inferred "light" from the Tony Casey / M3 ownership
    # pattern — not explicitly stated anywhere. Easy to flip to "full".
    tier: light
    owner: TonyCasey
    group: m3-m4   # see M3 above
    ticket: BOUN-11248
    features:
      - key: BOUN-11465
        code: "F4.1"
        owner: TonyCasey
      - key: BOUN-11466
        code: "F4.2"
        owner: TonyCasey
      - key: BOUN-11467
        code: "F4.3"
        owner: TonyCasey
      - key: BOUN-11468
        code: "F4.4"
        owner: TonyCasey
      # Doesn't match the F#.# pattern and is unassigned in JIRA (owner
      # defaulted to the milestone owner) — kept as-is per project owner:
      # "there might be a reason for that naming."
      - key: BOUN-11516
        code: "DF4.1.1"
        owner: TonyCasey

people:
  ruzwid: Ruzzell
  VivekMurarkaIndIre: Vivek
  TonyCasey: Tony
  gelbh: Tomer
  EmadNazzal: Emad

# JIRA's assignee `displayName` -> GitHub login. Doesn't reuse `people`
# above because JIRA's string is a full name (or, for Vivek, a bare
# username) rather than the short first name `people` maps to — so a
# ticket's assignee needs its own explicit lookup back to a login.
jiraAssignees:
  Ruzzell Widjaja: ruzwid
  vivek.murarka: VivekMurarkaIndIre
  Tony Casey: TonyCasey
  Tomer Gelbhart: gelbh
  Emad Nazzal: EmadNazzal

# login -> average colour of their GitHub avatar, used as a subtle
# background tint behind PersonChip badges. Regenerate with
# `pnpm avatar-colors` (also picks up review-only logins that aren't in
# `people` above, e.g. Madjda) and paste the result back in here.
peopleColors:
  EmadNazzal: "#c5a995"
  Madjda: "#919D8E"
  TonyCasey: "#241f1d"
  VivekMurarkaIndIre: "#5c616e"
  gelbh: "#716461"
  ruzwid: "#c0bad1"

# login -> JIRA accountId, for the Jira button on each People card. JIRA
# Cloud dropped username/displayName from JQL, so this can't be derived
# from anything already collected — a person with no entry here simply
# gets no Jira button. Find an id by opening someone's JIRA profile: the
# URL ends /jira/people/<accountId>.
jiraAccounts: {}

# login -> Slack member ID, for the DM button on each People card. Same
# rule: no entry, no button. Slack profile -> ⋮ -> Copy member ID.
slackIds: {}