Use read-only modded recipe exports in pricing evidence #179

New issue

Closed

opened 2026-07-29 06:18:10 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-07-29 06:18:10 +00:00

Member

Context

Eco App’s recipe and cost surfaces currently start from a bundled vanilla Eco Gnome export. Player-facing pricing evidence becomes misleading on a modded server when its recipe graph, output quantities, or upgrades differ. The existing DataExporter path can provide the needed server data without player-state writes.

What to build

Define and land the narrow read-only ingestion path that replaces or overlays the bundled vanilla recipe seed with the server’s exported recipe, item, skill, and tag data. The pricing surfaces must show exactly which source produced a result and when it was exported.

Acceptance criteria

The application can load a valid DataExporter-shaped modded recipe export without a parser fork.
Recipe and item-pricing responses identify source, export timestamp/version, and whether the result is vanilla fallback or server-specific.
Missing, malformed, stale, or unavailable export data degrades to the existing vanilla seed with an explicit warning; it never silently presents vanilla results as modded.
The ingestion contract is read-only: it does not write game state, player state, store state, or pricing configuration.
Fixture-based tests cover valid modded input and every fallback path.
Operator/deployment prerequisites and the handoff boundary are documented.

Production activation dependency

Application implementation can start against the bundled vanilla seed and DataExporter-shaped fixtures.
Production activation with server-specific Sirens data depends on eco-ops #71.
Until #71 supplies a verified export and handoff, responses must continue to identify vanilla fallback explicitly.

Non-goals

Building a bespoke RecipeManager dumper.
Managing player profiles, updating store prices, or adding a write-capable game API.
Self-hosting or modifying Eco Calc.

## Context Eco App’s recipe and cost surfaces currently start from a bundled vanilla Eco Gnome export. Player-facing pricing evidence becomes misleading on a modded server when its recipe graph, output quantities, or upgrades differ. The existing DataExporter path can provide the needed server data without player-state writes. ## What to build Define and land the narrow read-only ingestion path that replaces or overlays the bundled vanilla recipe seed with the server’s exported recipe, item, skill, and tag data. The pricing surfaces must show exactly which source produced a result and when it was exported. ## Acceptance criteria - [ ] The application can load a valid DataExporter-shaped modded recipe export without a parser fork. - [ ] Recipe and item-pricing responses identify source, export timestamp/version, and whether the result is vanilla fallback or server-specific. - [ ] Missing, malformed, stale, or unavailable export data degrades to the existing vanilla seed with an explicit warning; it never silently presents vanilla results as modded. - [ ] The ingestion contract is read-only: it does not write game state, player state, store state, or pricing configuration. - [ ] Fixture-based tests cover valid modded input and every fallback path. - [ ] Operator/deployment prerequisites and the handoff boundary are documented. ## Production activation dependency - Application implementation can start against the bundled vanilla seed and DataExporter-shaped fixtures. - Production activation with server-specific Sirens data depends on [eco-ops #71](https://forgejo.coilysiren.me/coilyco-gaming/eco-ops/issues/71). - Until #71 supplies a verified export and handoff, responses must continue to identify vanilla fallback explicitly. ## Non-goals - Building a bespoke `RecipeManager` dumper. - Managing player profiles, updating store prices, or adding a write-capable game API. - Self-hosting or modifying Eco Calc.

coilyco-ops added the

autonomy

live-collab

priority

labels

2026-07-29 06:18:16 +00:00

coilyco-ops added

and removed