coilyco-gaming/eco-app
2
0
Fork 0
Code Issues 16 Pull requests Projects Releases Packages Wiki Activity Actions

Probe: what recipe data is Eco Gnome actually giving us today? (de-risks #98 follow-up A) #105

New issue
Open
opened 2026-07-07 06:54:05 +00:00 by coilysiren · 1 comment
coilysiren commented 2026-07-07 06:54:05 +00:00
Owner
Copy link

De-risk the recipe/pricing roadmap (#98, follow-ups A-E) by establishing exactly what recipe data Eco Gnome is actually giving us today, versus what is still aspirational. Follow-up A (the keystone recipe ingest) cannot be scoped for real until this is answered. This is a research / consult probe.

Background

The #98 design assumed a bespoke Eco RecipeManager exporter, then the director correction pointed out Eco Gnome is itself a recipe exporter - so A should ingest Eco Gnome's output. But whether that output is reachable now is unconfirmed: the current integration is only a homepage link-out to eco-gnome.com (Home.tsx), and the self-host + DataExporter path (#40, coilyco-bridge/deploy/services/eco-gnome) is blocked on kai-server mod-ops (ward#585 / eco-ops#30). Read docs/calculator.md and #40 first.

Questions to answer concretely

  1. eco-gnome-mod export format (https://github.com/Eco-Gnome/eco-gnome-mod): what exactly does the DataExporter dump for recipes, skills, and items - which fields (ingredients + quantities, product, station, required skill + level, labor, calories, craft time, variants, table tier), what serialization (JSON/CSV), and delivered how (file on disk, HTTP endpoint, DB rows)?
  2. The bundled ecocraft/eco_gnome_data.json (vanilla recipe/item data in the eco-gnome image): what is its shape, and is it usable as a seed for eco-app's own /preview/recipes.json without the mod being installed at all?
  3. The self-hosted instance: is coilyco-bridge/deploy/services/eco-gnome / eco-gnome.coilysiren.me actually deployed and running? If so, does its Postgres or any app endpoint expose recipes we could read directly? (The advisor holds the tailnet + AWS live-observe set - check the live service, do not guess.)
  4. The mod on kai-server: is the DataExporter mod installed on the live Eco server yet, or is that still gated on ward#585 / eco-ops#30?
  5. Bottom line: what recipe fields can eco-app obtain today, by what concrete path, and what remains blocked and on what. Recommend the specific data source follow-up A should target (bundled JSON seed now vs modded export later vs read the self-hosted DB), and whether A can start now or must wait.

Deliverable

Post a comment on this issue stating available-now vs blocked, the recommended concrete source for A, and any newly-discovered blocker worth its own issue. No code change - this is a probe that unblocks A's scoping.

De-risk the recipe/pricing roadmap (#98, follow-ups A-E) by establishing exactly what recipe data Eco Gnome is actually giving us today, versus what is still aspirational. Follow-up **A** (the keystone recipe ingest) cannot be scoped for real until this is answered. This is a research / consult probe. ## Background The #98 design assumed a bespoke Eco `RecipeManager` exporter, then the director correction pointed out **Eco Gnome is itself a recipe exporter** - so A should ingest Eco Gnome's output. But whether that output is reachable now is unconfirmed: the current integration is only a homepage link-out to eco-gnome.com (`Home.tsx`), and the self-host + DataExporter path (#40, `coilyco-bridge/deploy/services/eco-gnome`) is blocked on kai-server mod-ops (ward#585 / eco-ops#30). Read `docs/calculator.md` and #40 first. ## Questions to answer concretely 1. **eco-gnome-mod export format** (https://github.com/Eco-Gnome/eco-gnome-mod): what exactly does the DataExporter dump for recipes, skills, and items - which fields (ingredients + quantities, product, station, required skill + level, labor, calories, craft time, variants, table tier), what serialization (JSON/CSV), and delivered how (file on disk, HTTP endpoint, DB rows)? 2. **The bundled `ecocraft/eco_gnome_data.json`** (vanilla recipe/item data in the eco-gnome image): what is its shape, and is it usable as a seed for eco-app's own `/preview/recipes.json` without the mod being installed at all? 3. **The self-hosted instance**: is `coilyco-bridge/deploy/services/eco-gnome` / `eco-gnome.coilysiren.me` actually deployed and running? If so, does its Postgres or any app endpoint expose recipes we could read directly? (The advisor holds the tailnet + AWS live-observe set - check the live service, do not guess.) 4. **The mod on kai-server**: is the DataExporter mod installed on the live Eco server yet, or is that still gated on ward#585 / eco-ops#30? 5. **Bottom line**: what recipe fields can eco-app obtain **today**, by what concrete path, and what remains blocked and on what. Recommend the specific data source follow-up A should target (bundled JSON seed now vs modded export later vs read the self-hosted DB), and whether A can start now or must wait. ## Deliverable Post a comment on this issue stating available-now vs blocked, the recommended concrete source for A, and any newly-discovered blocker worth its own issue. No code change - this is a probe that unblocks A's scoping.
coilyco-ops commented 2026-07-07 06:58:27 +00:00
Member
Copy link

🔎 ward agent advisor

ward agent advisor --driver claude ran a one-shot standard research pass on this question:

Probe what recipe data Eco Gnome is actually giving us today, to de-risk follow-up A (#100). Answer concretely: (1) what eco-gnome-mod's DataExporter dumps for recipes/skills/items - fields, serialization, delivery mechanism; (2) the shape of the bundled ecocraft/eco_gnome_data.json and whether it works as a seed for /preview/recipes.json without the mod; (3) whether coilyco-bridge/deploy/services/eco-gnome / eco-gnome.coilysiren.me is actually deployed and whether its Postgres or any endpoint exposes readable recipes - check the live service over the tailnet, do not guess; (4) whether the DataExporter mod is installed on kai-server yet or still blocked on ward#585 / eco-ops#30; (5) the bottom line - what recipe fields eco-app can obtain today, by what path, what's still blocked, and the specific data source A should target plus whether A can start now. Read docs/calculator.md and #40 first, and inspect the eco-gnome-mod and eco-gnome-website GitHub repos. Post the findings as a comment on this issue.

Probe result: what Eco Gnome recipe data we can get today

Bottom line up front: Follow-up A can start now. The keystone seed for /preview/recipes.json is the vanilla ecocraft/eco_gnome_data.json bundled in the eco-gnome-website repo/image - a complete, well-structured recipe graph (1,453 recipes, 1,526 items, 43 skills, 142 tags) in exactly the same schema the DataExporter mod emits. So A is not blocked; only server-accurate (modded) numbers are blocked, and they arrive as a drop-in replacement of the same file later. Do not target the self-hosted DB - it exposes no readable recipe endpoint and currently holds no Sirens data.

1. What eco-gnome-mod's DataExporter dumps (fields / serialization / delivery)

Serialization: a single JSON file, eco_gnome_data.json, Newtonsoft.Json indented (DataExporter.ExportAll -> File.WriteAllText("eco_gnome_data.json", ...)).

Delivery: written to the Eco server root folder on disk, automatically on server start and on-demand via /EcoGnome export (admin chat command). It is not HTTP-pushed - the mod's EcoGnomeApi.cs only calls the website for server/user registration and price sync (register-server, register-user, user-prices, categories-items-v2), never to upload recipe data. Getting the file into a website instance is a separate step (the website's POST /api/server/upload-data?apiKey= or its in-app ImportData path).

Top-level shape: { Version, Skills[], Items[], Tags[], Recipes[] }.

Recipe fields (RecipeExported, confirmed against both the mod source and the bundled file) - every field #98/A wanted is present:

  • Name, FamilyName (variant family - sibling recipes share it; IsDefault flags the canonical one), LocalizedName (24 languages)
  • Ingredients[] and Products[] - each { ItemOrTag, Quantity: { BaseValue, Modifiers[] } } (ingredients+quantities and products+yields, tag-or-item aware)
  • CraftingTable (station item name), RequiredSkill + RequiredSkillLevel
  • Labor - a DynamicValue whose BaseValue is recipeFamily.LaborInCalories, i.e. labor cost = calories (they are the same field in Eco; there is no separate calorie number)
  • CraftMinutes - craft time, a DynamicValue
  • IsBlueprint, IsDefault
  • The Modifiers[] on Quantity/Labor/CraftMinutes carry Skill/Module/Talent dynamic effects ({DynamicType, Item, ValueType}), so speed/labor/yield bonuses are captured for accurate pricing.

Skill fields: Name, LocalizedName, MaxLevel, LaborReducePercent[] (per-level), Talents[].
Item fields: lean - Name, LocalizedName, FuelCalories (all crafting detail lives on recipes).
Tag fields: Name, LocalizedName, AssociatedItems[] (resolves ItemOrTag ingredients to concrete items).

Gap to note for A: there is no explicit "table tier" field - tier is inferable from CraftingTable + RequiredSkillLevel, not first-class.

2. The bundled ecocraft/eco_gnome_data.json - shape and seed-viability

Yes, it is directly usable as a seed with no mod installed. It sits at ecocraft/eco_gnome_data.json in eco-gnome-website (6.3 MB), is baked into the published image, and is fetchable raw (https://raw.githubusercontent.com/Eco-Gnome/eco-gnome-website/master/ecocraft/eco_gnome_data.json -> HTTP 200, 6,293,819 bytes). It is the identical schema the mod produces (same ExportedData record: Skills/Items/Tags/Recipes), so ingest code written against it is forward-compatible with the eventual modded export - the later swap changes only the contents, not the parser.

The one caveat that matters for scoping: this bundle is vanilla base-game data. Sirens' server is "highly modded" (20+ mods: Biochemist, Animal Husbandry, Greenhouses, BunWulf Agricultural/HardwareCo, Librarian, ...). The vanilla seed will omit every modded recipe/item and any modded stat changes. Fine for building and demoing A's pipeline; not server-accurate until Phase 2.

3. The self-hosted instance (live check over the network)

It IS deployed and serving. https://eco-gnome.coilysiren.me responds with server: Kestrel and a Blazor app (405 to HEAD on /, 400 with query params) - a live ASP.NET Core / .NET 9 process, not a placeholder. The deploy slot (coilyco-bridge/deploy/services/eco-gnome) pins ghcr.io/eco-gnome/eco-gnome-website@sha256:7b6ded5e... with a postgres:17 sidecar.

Doc-drift flag: docs/calculator.md and the deploy README still frame the rollout as "remaining to go live." The live probe shows it is already up. Worth a one-line eco-app docs correction (same-repo cleanup, not a separate issue).

But it is not a usable recipe source for A:

  • No REST read path for the recipe graph. The website's only GET endpoints (/api/eco/server-prices, /api/eco/user-prices, /api/eco/categories-items-v2) return prices only - {Name, MinPrice, DefaultPrice, MaxPrice} style. Recipes/items/skills go in (via POST /api/server/upload-data or the Blazor ImportData UI) and never come back out over HTTP. Reading them would mean querying Postgres directly, which is a ClusterIP service (not tailnet-exposed) - a much heavier coupling than parsing a static JSON.
  • It holds no Sirens data anyway. GET /api/eco/server-prices?ecoServerId=test returns "Can't find server. Did you register your server..." - no Eco server is registered against it, so at best it contains the vanilla seed, the same data we can read straight from the bundle.

4. The DataExporter mod on kai-server

Not installed / still gated. The live game server (eco.coilysiren.me, 0.13.0.4) advertises "20+ mods" but does not list EcoGnome/DataExporter among them, and both docs/calculator.md (Phase 2) and the deploy README state the modded export waits on the eco mod-ops pipeline, ward#585 / eco-ops#30. Nothing observed contradicts that - treat the modded export as still blocked.

5. Bottom line for follow-up A

Path Recipe fields obtainable Status Notes
Bundled eco_gnome_data.json (fetch raw / vendor a copy) Full schema: ingredients+qty, products+yield, station, skill+level, labor(=calories), craft time, family/variant, blueprint flag, localized names, tag associations Available now Vanilla-only. MIT-licensed - keep Eco-Gnome attribution.
Modded DataExporter export Same schema, server-accurate (Sirens' mods) Blocked on ward#585 / eco-ops#30 Drop-in replacement of the same file.
Self-hosted DB / endpoints Prices only via REST; recipes only via direct Postgres Not viable No recipe REST endpoint; DB internal-only; unseeded with our data.

Recommendation for A: target the bundled eco_gnome_data.json schema as the ingest contract and seed /preview/recipes.json from it now (vendor a pinned copy in-repo, or fetch at build - it's MIT, ~6 MB, keep the attribution already recorded in the deploy ATTRIBUTION.md). Because the mod emits the identical shape, A's parser needs no rework when Phase 2 lands - the modded file simply replaces the vanilla one, and only then does A gain Sirens' modded recipes. A does not need to wait on ward#585 / eco-ops#30; that dependency only upgrades the data from vanilla to server-accurate, not the code.

No new blocker discovered that warrants its own issue. The only follow-up is the same-repo doc correction noted in (3) - fold it into A's PR or a trivial docs touch-up, not a separate tracked issue.

Researched and posted automatically by ward agent advisor --driver claude (ward#179). This is one-shot research, not a carried change - verify before acting on it.

— Claude (she/her), via ward agent

### 🔎 ward agent advisor `ward agent advisor --driver claude` ran a one-shot **standard** research pass on this question: > Probe what recipe data Eco Gnome is actually giving us today, to de-risk follow-up A (#100). Answer concretely: (1) what eco-gnome-mod's DataExporter dumps for recipes/skills/items - fields, serialization, delivery mechanism; (2) the shape of the bundled ecocraft/eco_gnome_data.json and whether it works as a seed for /preview/recipes.json without the mod; (3) whether coilyco-bridge/deploy/services/eco-gnome / eco-gnome.coilysiren.me is actually deployed and whether its Postgres or any endpoint exposes readable recipes - check the live service over the tailnet, do not guess; (4) whether the DataExporter mod is installed on kai-server yet or still blocked on ward#585 / eco-ops#30; (5) the bottom line - what recipe fields eco-app can obtain today, by what path, what's still blocked, and the specific data source A should target plus whether A can start now. Read docs/calculator.md and #40 first, and inspect the eco-gnome-mod and eco-gnome-website GitHub repos. Post the findings as a comment on this issue. --- ## Probe result: what Eco Gnome recipe data we can get **today** **Bottom line up front:** Follow-up A **can start now**. The keystone seed for `/preview/recipes.json` is the vanilla `ecocraft/eco_gnome_data.json` bundled in the eco-gnome-website repo/image - a complete, well-structured recipe graph (1,453 recipes, 1,526 items, 43 skills, 142 tags) in **exactly the same schema the DataExporter mod emits**. So A is not blocked; only *server-accurate (modded) numbers* are blocked, and they arrive as a drop-in replacement of the same file later. Do **not** target the self-hosted DB - it exposes no readable recipe endpoint and currently holds no Sirens data. --- ### 1. What eco-gnome-mod's DataExporter dumps (fields / serialization / delivery) **Serialization:** a single **JSON** file, `eco_gnome_data.json`, `Newtonsoft.Json` indented (`DataExporter.ExportAll` -> `File.WriteAllText("eco_gnome_data.json", ...)`). **Delivery:** written to the **Eco server root folder on disk**, automatically on server start and on-demand via `/EcoGnome export` (admin chat command). **It is not HTTP-pushed** - the mod's `EcoGnomeApi.cs` only calls the website for server/user *registration* and *price sync* (`register-server`, `register-user`, `user-prices`, `categories-items-v2`), never to upload recipe data. Getting the file *into* a website instance is a separate step (the website's `POST /api/server/upload-data?apiKey=` or its in-app ImportData path). **Top-level shape:** `{ Version, Skills[], Items[], Tags[], Recipes[] }`. **Recipe fields** (`RecipeExported`, confirmed against both the mod source and the bundled file) - every field #98/A wanted is present: - `Name`, `FamilyName` (**variant family** - sibling recipes share it; `IsDefault` flags the canonical one), `LocalizedName` (24 languages) - `Ingredients[]` and `Products[]` - each `{ ItemOrTag, Quantity: { BaseValue, Modifiers[] } }` (**ingredients+quantities and products+yields**, tag-or-item aware) - `CraftingTable` (**station** item name), `RequiredSkill` + `RequiredSkillLevel` - `Labor` - a DynamicValue whose `BaseValue` is `recipeFamily.LaborInCalories`, i.e. **labor cost = calories** (they are the same field in Eco; there is no separate calorie number) - `CraftMinutes` - **craft time**, a DynamicValue - `IsBlueprint`, `IsDefault` - The `Modifiers[]` on Quantity/Labor/CraftMinutes carry Skill/Module/Talent dynamic effects (`{DynamicType, Item, ValueType}`), so speed/labor/yield bonuses are captured for accurate pricing. **Skill fields:** `Name`, `LocalizedName`, `MaxLevel`, `LaborReducePercent[]` (per-level), `Talents[]`. **Item fields:** lean - `Name`, `LocalizedName`, `FuelCalories` (all crafting detail lives on recipes). **Tag fields:** `Name`, `LocalizedName`, `AssociatedItems[]` (resolves `ItemOrTag` ingredients to concrete items). *Gap to note for A:* there is **no explicit "table tier" field** - tier is inferable from `CraftingTable` + `RequiredSkillLevel`, not first-class. ### 2. The bundled `ecocraft/eco_gnome_data.json` - shape and seed-viability **Yes, it is directly usable as a seed with no mod installed.** It sits at `ecocraft/eco_gnome_data.json` in eco-gnome-website (6.3 MB), is baked into the published image, **and is fetchable raw** (`https://raw.githubusercontent.com/Eco-Gnome/eco-gnome-website/master/ecocraft/eco_gnome_data.json` -> HTTP 200, 6,293,819 bytes). It is the **identical schema** the mod produces (same `ExportedData` record: `Skills/Items/Tags/Recipes`), so ingest code written against it is forward-compatible with the eventual modded export - the later swap changes only the *contents*, not the parser. **The one caveat that matters for scoping:** this bundle is **vanilla base-game data**. Sirens' server is "highly modded" (20+ mods: Biochemist, Animal Husbandry, Greenhouses, BunWulf Agricultural/HardwareCo, Librarian, ...). The vanilla seed will **omit every modded recipe/item and any modded stat changes**. Fine for building and demoing A's pipeline; not server-accurate until Phase 2. ### 3. The self-hosted instance (live check over the network) **It IS deployed and serving.** `https://eco-gnome.coilysiren.me` responds with `server: Kestrel` and a Blazor app (`405` to HEAD on `/`, `400` with query params) - a live ASP.NET Core / .NET 9 process, not a placeholder. The deploy slot (`coilyco-bridge/deploy/services/eco-gnome`) pins `ghcr.io/eco-gnome/eco-gnome-website@sha256:7b6ded5e...` with a `postgres:17` sidecar. > **Doc-drift flag:** `docs/calculator.md` and the deploy README still frame the rollout as "remaining to go live." The live probe shows it is **already up**. Worth a one-line eco-app docs correction (same-repo cleanup, not a separate issue). **But it is not a usable recipe source for A:** - **No REST read path for the recipe graph.** The website's only GET endpoints (`/api/eco/server-prices`, `/api/eco/user-prices`, `/api/eco/categories-items-v2`) return **prices only** - `{Name, MinPrice, DefaultPrice, MaxPrice}` style. Recipes/items/skills go *in* (via `POST /api/server/upload-data` or the Blazor ImportData UI) and never come back out over HTTP. Reading them would mean querying **Postgres directly**, which is a ClusterIP service (not tailnet-exposed) - a much heavier coupling than parsing a static JSON. - **It holds no Sirens data anyway.** `GET /api/eco/server-prices?ecoServerId=test` returns *"Can't find server. Did you register your server..."* - no Eco server is registered against it, so at best it contains the vanilla seed, the same data we can read straight from the bundle. ### 4. The DataExporter mod on kai-server **Not installed / still gated.** The live game server (`eco.coilysiren.me`, `0.13.0.4`) advertises "20+ mods" but **does not list EcoGnome/DataExporter** among them, and both `docs/calculator.md` (Phase 2) and the deploy README state the modded export **waits on the eco mod-ops pipeline, ward#585 / eco-ops#30**. Nothing observed contradicts that - treat the modded export as still blocked. ### 5. Bottom line for follow-up A | Path | Recipe fields obtainable | Status | Notes | |---|---|---|---| | **Bundled `eco_gnome_data.json`** (fetch raw / vendor a copy) | Full schema: ingredients+qty, products+yield, station, skill+level, labor(=calories), craft time, family/variant, blueprint flag, localized names, tag associations | **Available now** | Vanilla-only. MIT-licensed - keep Eco-Gnome attribution. | | **Modded DataExporter export** | Same schema, **server-accurate** (Sirens' mods) | **Blocked** on ward#585 / eco-ops#30 | Drop-in replacement of the same file. | | **Self-hosted DB / endpoints** | Prices only via REST; recipes only via direct Postgres | **Not viable** | No recipe REST endpoint; DB internal-only; unseeded with our data. | **Recommendation for A:** target the **bundled `eco_gnome_data.json` schema** as the ingest contract and seed `/preview/recipes.json` from it now (vendor a pinned copy in-repo, or fetch at build - it's MIT, ~6 MB, keep the attribution already recorded in the deploy `ATTRIBUTION.md`). Because the mod emits the identical shape, A's parser needs no rework when Phase 2 lands - the modded file simply replaces the vanilla one, and only then does A gain Sirens' modded recipes. **A does not need to wait on ward#585 / eco-ops#30**; that dependency only upgrades the data from vanilla to server-accurate, not the code. **No new blocker discovered that warrants its own issue.** The only follow-up is the same-repo doc correction noted in (3) - fold it into A's PR or a trivial docs touch-up, not a separate tracked issue. --- Researched and posted automatically by `ward agent advisor --driver claude` (ward#179). This is one-shot research, not a carried change - verify before acting on it. <!-- ward-agent-reply --> <!-- ward-agent-signature --> — Claude (she/her), via `ward agent`
coilyco-ops added
P3
 and removed
P2
 labels 2026-07-10 09:00:46 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
issue-109
issue-106
ward-salvage/eco-app-a58b14ad
issue-104
No results found.
Labels
Clear labels   
burndown-2026-06
Backlog burndown June 2026

  
headless
Safe for autonomous warded engineer carry

  
consult
'A human decision, design, or external action must happen first. Fail-closed default for unlabeled/low-confidence.

  
headless
Agent can take it from open issue to merged change with no human in the loop. The auto-burndown queue.

  
interactive
Agent does the work but pauses at a human checkpoint mid-flight (design choice, destructive step, human-only verification).

  
P0
priority tier

  
P1
priority tier

  
P2
priority tier

  
P3
priority tier

  
P4
priority tier

No labels
burndown-2026-06
headless
consult
headless
interactive
P0
P1
P2
P3
P4
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-gaming/eco-app#105
No description provided.