BlitzRift — Mine. Collect. Bank. Steal the lead.

ROADMAP · THE WORK BEHIND THE RIFT

Roadmap

See what is next, what is flying, and what your feedback changed. Optimism now comes with a status column.

CURRENT DEVELOPMENT SLICE

First complete expedition

A Blitzer receives a diegetic adventure transmission, flies through a portal into an authored destination, recovers valuables and returns home with clear outcomes. Build reusable adventures and believable travel, then verify the first complete expedition for a small Steam playtest.

5 shipped · 1 in development · 1 planned

  1. TASK-25 Gate travel is not ship destructionShipped
  2. TASK-26 Modular authored adventures and shared lifecycleShipped
  3. TASK-27 Replace adventure briefing card with visor transmissionsShipped
  4. TASK-28 Animated portal passage and combined journey acceptanceShipped
  5. TASK-22 First expedition: verify the Steam acquisition-to-bank loopIn progress
  6. TASK-23 First expedition: make existing opportunities understandableNext up
  7. TASK-24 First expedition: refresh the weekend playtester handoffShipped
Development notes

October 2 correction requested by Mike: the latest adventure requests are committed to this slice, not deferred for weekend readiness. Development order: TASK-25 separate gate suspension from death; TASK-26 authored adventure definitions and shared lifecycle; TASK-27 replace the rejected modal briefing with short replayable visor transmissions; TASK-28 integrate animated portal entry/loop/exit and combined journey acceptance. TASK-22/23/24 provide the first-expedition reliability, readability and handoff acceptance pass. Detailed criteria: tasks/prd-adventure-modules-and-presentation.md; design/sector-admission.md; design/pilot-information.md. Mike supplies portal artwork and reviews rendered visual studies; a placeholder can exercise the adapter first. Steam 52.230 remains the published baseline; local source travel is not hosted readiness. No hidden roster, persistent flight paragraphs, invented guardian/deadline knowledge or automatic acceptance from test results. Timed closure/loss requires durable recovery; hosted provisioning and release activation remain subsequent explicitly authorized work. Record verified progress today; the calendar does not establish readiness.

Changes to this slice

Started with 3 work items. 4 added since the start; 0 currently removed.

TASK-25 · Gate travel is not ship destruction — Added after the start
TASK-26 · Modular authored adventures and shared lifecycle — Added after the start
TASK-27 · Replace adventure briefing card with visor transmissions — Added after the start
TASK-28 · Animated portal passage and combined journey acceptance — Added after the start

Changes are recorded in each work item's activity.

Ready for testing means a build is available. In testing means validation is underway. A slice is optional; organizer review decides when work is shipped.

In progress

FEATURE-22 · Prospecting and discovery opportunities

Own the hunt and discovery experience: give blitzers readable clues and meaningful choices about where to search, what to investigate and which finds merit recovery. The intended loop is hunt → discover → choose cargo → reach an eligible buyer → secure the reward. Rich mineral deposits are one possible discovery, not the entire progression model. Surface crystals may provide truthful approximate clues; exact search mechanics and artifact placement rules still need design. Avoid automatically revealing every prize, turning all discoveries into interchangeable payouts, or reducing ordinary rewards to manufacture grind. Gold remains Queen-exclusive. Scope boundaries: FEATURE-22 owns search clues and discovery opportunities. FEATURE-36 owns distinct cargo identity, quantities and capacity; FEATURE-37 owns exclusive buyer eligibility and sale; FEATURE-38 owns rare-cargo signals and exceptional transport journeys; FEATURE-40 owns recovered discoveries and collections. Finding or carrying an artifact does not bank it; an ordinary port cannot secure an artifact it does not accept. First integrated experiment: ordinary bulk cargo plus one discoverable artifact and one reachable exclusive buyer, using the supporting features above. If the artifact is rare or higher, its carrier signal is required as part of that experiment. Do not defer that signal while treating a rare artifact as complete. This is a bounded prototype spanning related items, not a claim that all supporting features belong to FEATURE-22 or are implemented. Longer journeys and broader content follow after the small loop works. Acceptance: a new blitzer can interpret clues, make an informed search choice, recognize a distinctive find and understand its buyer requirement before committing to transport. Playtesting should demonstrate purposeful exploration and recovery decisions beyond filling the hold at the nearest rock. Verify cockpit/chase readability and achievable recovery within sector lifetime. Cargo accounting, sale integrity and carrier-signal tests remain owned by the supporting items. Exact mechanics and reward balance remain open.

Feature · 1 blitzer supportedOpen item
In progress

FEATURE-21 · Stored consumables and specialist outposts

Stored consumables and inventory are locally implemented, not placeholder slots: six stable slots of 10 units each, capacity/stacking, deliberate selection/use, occupied-slot cycling, fuel boosts and hull repair. Two missile mounts are separate. Unused items/missiles drop on death and persist only within the active sector; no cross-sector or restart persistence. Slot move/swap/merge is available in the own-syndicate port shop. Sources: design/consumables-and-missiles.md and docs/plans/port-shop.md. Local authoritative custody, peer and display checks exist; live and physical-controller acceptance remain open. Specialist supply outposts, broader stock and supply balance remain unfinished; shield packs are unavailable. Exclusive artifact buyers remain FEATURE-37, using FEATURE-36 cargo; no competing market model.

Feature · 0 blitzers supportedOpen item
In progress

FEATURE-13 · Ship services and cosmetics

Ship-service foundation implemented locally: own-syndicate dockside loadout shop, full hull repair, hull packs and guided missiles, confirmed wallet settlement/refunds, capacity checks, and slot move/swap/merge. September 29 replay history is scoped per admitted wallet session. Evidence: docs/plans/port-shop.md; 115 curated fast/gameplay steps and two-peer purchase/arrangement/sale checks passed for that correction. Live wallet/service acceptance remains open. Cosmetics, decals and other hulls are not purchasable; exterior bay presentation is deferred until cosmetics exist. Accomplishment-earned cosmetics remain proposal work under docs/plans/career-recognition-and-leaderboards.md and FEATURE-40. Recognition/cosmetics only for initial rank rewards; no rank-based stat bonuses or basic-tool gates. Ship affiliation, ship choice and skin remain separate.

Feature · 0 blitzers supportedOpen item
In progress

FEATURE-14 · Ranks and achievements

Rank foundation implemented and locally verified September 26: confirmed common/uncommon/rare/gold/diamond units earn 1/3/5/10/50 points; actual credits give event-time syndicate standing; artifacts give discovery/standing, no rank. Authoritative versioned awards preserve earned tiers; spending, losses and sponsor changes do not erase rank. Existing Flight Board, sponsor cards and quiet visor identity show recognition. No XP bar, flight promotion banner or rank-based power. Evidence: docs/plans/career-ledger-implementation.md and career-balance.md. Human 80–120-hour pacing and live service acceptance remain unverified. Remaining proposal: docs/plans/career-recognition-and-leaderboards.md v0.2, September 27, supersedes the older achievement shortlist: 29 planned achievements (11 promotions, 18 distinctions), 23 achievable with the two playable sponsors; docked recognition/career review, cosmetic recognition and public opt-in website leaderboards require their recorded decisions. This does not approve new presentation, rewards, Steam configuration or additional playable syndicates. Steam is an output, not progression authority. FEATURE-39 owns facts, FEATURE-40 collections, FEATURE-13 cosmetics. TASK-7–11 retain environment, haul, evidence, mirror and provenance gaps where applicable; missing provenance cannot be invented.

Feature · 0 blitzers supportedOpen item
In progress

FEATURE-36 · Typed cargo and capacity-based hold

Confirmed updated direction: cargo cells measure physical capacity; six inventory slots hold and select identifiable objects/stacks. Bulk minerals occupy cells without consuming slots. Artifacts and future supplies/deployables consume one slot per object/stack plus their physical capacity cost. Exact future capacities and stack limits remain design decisions. The first live prototype uses Mike's 3D artifact model and alpha inventory icon, one four-cell relic and deliberate trade; six slots are now functional in the local branch, superseding the earlier placeholder-equipment interpretation. Item definitions, per-instance identity/quantity/charges/condition, slot ownership and action capabilities are separate. Selection alone never sells, consumes or activates. Future repair items, missiles, grenades, mines and buffs need their own authoritative behaviors and tests; metadata is not implementation. Acceptance: server-authoritative slot/capacity limits, stable identity through pickup/drop/transfer/sale, atomic invalid-manifest rejection, readable cockpit/chase icons and replay-safe actions. No across-sector cargo persistence assumed.

Feature · 0 blitzers supportedOpen item
In progress

FEATURE-37 · Specialist cargo markets and exclusive buyers

Confirmed: some artifacts HAVE to be traded at particular markets absent from the current normal port. This is exclusive acceptance, not a price bonus. Normal ports may sell supported bulk cargo but must leave unsupported artifacts aboard, occupying space and at risk; no banking/storage shortcut secures them. Only an eligible buyer completes the sale and associated recovery accomplishment. Show or let players discover buyer requirements before a long trip; exact discovery method is open. First experiment: one specialist destination in a sector with a viable reachable route. Acceptance: incompatible buyer refuses only unsupported cargo; successful authorized sale awards once; retries/disconnects do not duplicate cargo or credits. Depends on typed cargo and existing account wallet. Owner-approved interaction update: inventory-object trading is deliberate. Docking makes the item eligible but does not sell it. Select the slot, then explicitly invoke Trade at an eligible buyer. Show the fixed object payout separately from bulk exchange rates. Bulk unloading remains automatic. Server validation binds action to the requesting blitzer, current slot and item identity; stale or repeated requests cannot sell a replacement object or award twice.

Feature · 0 blitzers supportedOpen item
In progress

FEATURE-38 · Exceptional artifact journeys and rare-cargo signatures

Confirmed: some very special artifacts require a long, lucrative journey to an exclusive buyer. Every rare-or-higher artifact signals to other players while aboard. Ordinary ports cannot secure them. Depends on typed cargo and exclusive buyers. Proposed first scope is within one sector; multi-sector transport is a separate decision. Detection range, pulse frequency, exact-position disclosure and reward amounts are NOT settled. Candidate: recognizable limited-range signature, stronger for exceptional finds; clear carrier notice before pickup and while aboard. Proposed stolen artifacts retain buyer and signature requirements. Acceptance/design tests: viable buyer before sector closure, carrier/observer readability, fair pursuit and escape, no permanent global dogpile; define dropped-cargo signal, death, disconnect and expiry rules before implementation. No guaranteed escort/party feature.

Feature · 0 blitzers supportedOpen item
In progress

FEATURE-39 · Account career record and notable hauls

Confirmed account career ledger and minimum rank display implemented locally September 26. The transaction-bound ledger preserves exact gem composition, confirmed credits, event-time sponsor, discovery identity, revisions and versioned rank awards; retries cannot double-award and unknown historical composition is not invented. Local backend 44/44 tests, real HTTP lost-response/reconnect/other-sponsor coverage, and display lifecycle checks passed. See docs/plans/career-ledger-implementation.md. Full live acceptance and release/wallet environment isolation remain open. Remaining: durable haul IDs, deposit membership/finalization and late-receipt recovery (TASK-8), notable outcomes and career review/public read API. September 27 recognition/leaderboard additions remain proposals in docs/plans/career-recognition-and-leaderboards.md. Hauls, not flights, are counted: a docking visit with bulk cargo starts at berth capture and ends when empty, or on earlier undock/death/disconnect. Wallet backpressure does not end it; empty docking is not a haul; artifact trade is a separate recovery. Value is confirmed deposits within the visit, size is units unloaded. No historical haul reconstruction from aggregate amounts.

Feature · 0 blitzers supportedOpen item
In progress

FEATURE-40 · Recovered discoveries and personal collections

Make some cargo a discovery worth securing, not just money. Start with a small authored collection and one selected personal recovery goal; no giant catalog or invented regions/mineral counts. Collection progress belongs to the account. Artifacts requiring exclusive buyers count as recovered only at an accepting market; finding/carrying is not permanent recovery. Optional encountered-vs-recovered display and stolen-find eligibility need decisions; proposed stolen recovery counts, without rewarding duplicate claims. Depends on typed cargo, exclusive sale events and career record. Acceptance: identity and collection progress survive confirmed recovery/rejoin, one-time unlocks are retry-safe, wrong port cannot grant recovery, unknown entries do not obscure required navigation. Evaluate whether players launch again and change routes; do not reduce base payouts to manufacture grind. 2026-09-17 Steam proposal audit: TASK-9 requires an explicit versioned collection set for completion achievements; a mutable catalog size or count alone cannot establish membership or stable unlock criteria. Preserve prior earned facts and define catalog additions/removals and backfill. TASK-7 covers account/environment isolation. These are proposal gaps, not a claim that new collections or achievement milestones are approved.

Feature · 0 blitzers supportedOpen item
In progress

FEATURE-55 · Unified Blitzer information: visor, contextual actions and outcome log

Unified Blitzer information has migrated to the Blitzer Visor; physical cockpit displays and the chase strip are retired. Current contract: design/pilot-information.md and design/blitzer-visor.md through v1.6. Implemented locally: bounded 4:3 field, information hierarchy, hull/cargo/inventory, one target block and bracket identity, edge bearings, confirmed rank/identity, contextual actions, and integrated missile warnings. Local exported migration and later lifecycle/priority/rendered checks are recorded in the contracts and docs/plans/guided-missiles.md / career-ledger-implementation.md. Remaining FEATURE-55 work includes the reviewable important-outcome log and human readability/new-player acceptance across bright/complex scenes and physical input variants. Shop outcomes persist as documented but do not constitute the general log. Preserve clear outside view, one primary presentation per event, action-before-advisory and critical priority, physical berth guidance, capture suppression and cleanup. No restored physical/chase instruments or persistent normal-flight explanatory banners. Debug metadata remains separate. Existing Details describe the historical pre-migration design; the later approved visor contract supersedes that surface allocation.

Feature · 1 blitzer supportedOpen item
In progress

TASK-22 · First expedition: verify the Steam acquisition-to-bank loop

Audit the released Steam experience from syndicate selection and deployment through launch, flight/braking, finding resources, collection, return, docking and confirmed banking; then a second trip. Exercise loaded-ship death, respawn, leave/rejoin and confirmed wallet persistence. Fix reproducible blockers with scoped regression coverage. Record exact build, input, camera and evidence; distinguish released 52.230 from local protocol-54 adventure work. Acceptance: full round trip works, confirmed funds survive rejoin, no duplicated cargo or stuck recovery, and failures have understandable outcomes. Complete automated/local verification before asking Mike to recruit a group. Human newcomer comprehension and hardware acceptance remain explicit pending checks, not inferred from automation.

Task · 0 blitzers supportedOpen item

Recent activity

Completed slices

Raid the Hive together

5 shipped · 5 at start · 1 added · 1 deferred

Development: discover, carry and trade with clear pilot information

0 shipped · 5 at start · 0 added · 4 deferred

Development: usability and mining

1 shipped · 5 at start · 0 added · 4 deferred