Repository navigation
Bind DRIVE mini-game shots and rewards to passenger shooters, never the driver #201
Description
Beta gate: named shooter attribution in the legacy DRIVE mini-game
Read-only source audit while reviewing #200: CarCrewSelector validates driver + shooter passenger, and DriveByGame excludes driver from XP update, but DriveByGame passes only targetBlock to DriveByEngine; DriveByEngine performs first-person shooting without selected crew/member IDs. Thus selector eligibility is real, but individual bullets, weapon inventory and kill/stat credit are not bound to named passenger shooters. Do not claim #200 solves this deeper mechanic.
Acceptance
- Explicit passenger-shooter context from immutable confirmed
CarCrewreaches the mini-game; driver, even if shooter-trained, cannot be selected as the in-car firing member. Empty passengers never fire. If active passenger becomes invalid, disable firing/revalidate according to existing match rules without creating a second world-result writer. - Actual selected member's shooting skill and recorded carried weapon/ammo affect only the intended combat parameters; if missing, display fallback honestly and never conjure a weapon. Document whether switching among multiple shooters is playable; disable or constrain rather than silently credit all shooters.
- Exactly-once post-mission XP/heat/loot accounting by named participant; returning/reloading cannot duplicate rewards. Preserve targetBlock and existing single-player encounter contract.
- Tests include dealer driver + shooter passenger, shooter driver + shooter passenger, driver-only/invalid passenger denial, two shooters switching, stale crew, inventory absent, exact-once reward. Real phone/desktop play proof and full frontend/backend gates; no production data or deployment.
Owner: unassigned pending #192 canonical route coordination; reserve DriveByGame.tsx/DriveByEngine.tsx only when an implementer takes this, do not race #197/#192 active branches. This is a gameplay follow-up for outside-beta readiness, not a reason to falsely report #200's UI work as whole-engine completion.
Activity
BrandDead commentedon Oct 1, 2026
Reservation 2026-10-01 (Manus): I own frontend/src/components/driveby/DriveByGame.tsx, DriveByEngine.tsx and a new participant-contract test/helper under components/driveby for #201. First PR will bind selected seated shooter IDs to shots, reject invalid/driver firing, and remove all-shooter XP fanout; #201 remains open until equipment/ammo and authoritative exact-once rewards are fully proven. No overlap with #190 encounter visual, #175 staging, or #192 topdown route. No production database/deploy.
BrandDead commentedon Oct 1, 2026
Reservation amendment before edit: add docs/PROJECT_LOG.md (append-only dated #201 entry) to the exact file list for the participant-only PR. This slice leaves recorded weapon/ammo effects and a durable authoritative exact-once reward receipt OPEN; neither is presented as complete.
BrandDead commentedon Oct 1, 2026
2026-10-01 integration: draft PR #202 (#202) binds named passenger IDs to legacy DRIVE shots/results; shooter-trained drivers cannot fire, duplicate/forged seats are rejected, retry/play-again uses a per-run completion ID, and in-flight valid credit survives later roster changes. Independent review found the replay and post-shot-credit regressions; both were repaired with red→green tests. Final local full gate on commit b798d6e: 1,041 frontend tests passed, 4 skipped; Node 24 build, lint, asset/package checks green; backend 95 passed. Demo DRIVE → live mission was replayed at 375×812, 390×844, and 1440×900, with selected passenger Big Rome and no HUD overlap/page errors. Still OPEN: same-frame stats finalization can be stale; generic 30-round ammo/weapon damage ignores equipped inventory; no durable keyed authoritative receipt across reload/session. PR remains draft and issue remains open; no outside-beta readiness or #175 proof is claimed.