Most-valuable-to-craft per profession page - follow-up D from #98 [depends on A, enhanced by C] #103

Closed
opened 2026-07-07 06:54:04 +00:00 by coilysiren · 2 comments
Owner

The "most valuable to craft, per profession" page from the #98 design: a jobs-page-like layout leaning hard into the Supply-gaps signal, listing the highest-value things to craft for each profession. This is follow-up D, and it settles the open "what does valuable mean" question Kai flagged.

Depends on #98-A (the recipe -> skill mapping that gives the per-profession grouping). Enhanced by #98-C (true margin). Do not start until A has landed.

North star: margin-weighted opportunity = expected profit per unit x how much you can actually sell, shipped in two phases:

  • Phase 1 (data available once A lands) - revenue opportunity. opportunity = market median unit price (market.py) x unmet demand qty (logistics.py supplyGaps.demandQty), boosted when reason in {no_supply, thin_supply}, gated by a liquidity floor from trades.py byItem currency volume so one thin trade cannot top the board. Label it honestly as revenue, not profit.
  • Phase 2 (after C) - true margin. Swap median unit price for margin = median unit price - rolled-up cost. Same demand weighting. Now it answers the incumbents' real question: what earns the most to craft right now.

The grouping by profession needs A's recipe -> skill mapping even for Phase 1, so the whole page is gated on A.

Scope & done

Model on pages/Jobs.tsx: one section per profession/specialty, reuse RankList bars, reuse the supply-gap severity treatment (glyph + label + color, never color alone) for the "why this ranks" callouts. One heading tier, minimal prose. vitest tests. Update docs/FEATURES.md. Green on ward exec test + lint. Full reasoning on #98.

The "most valuable to craft, per profession" page from the #98 design: a jobs-page-like layout leaning hard into the Supply-gaps signal, listing the highest-value things to craft for each profession. This is follow-up **D**, and it settles the open "what does valuable mean" question Kai flagged. **Depends on #98-A** (the recipe -> skill mapping that gives the per-profession grouping). **Enhanced by #98-C** (true margin). Do not start until A has landed. ## The definition of "valuable" (recommended on #98) North star: **margin-weighted opportunity = expected profit per unit x how much you can actually sell**, shipped in two phases: - **Phase 1 (data available once A lands) - revenue opportunity.** `opportunity = market median unit price (market.py) x unmet demand qty (logistics.py supplyGaps.demandQty)`, boosted when `reason in {no_supply, thin_supply}`, gated by a liquidity floor from `trades.py byItem` currency volume so one thin trade cannot top the board. Label it honestly as revenue, not profit. - **Phase 2 (after C) - true margin.** Swap median unit price for `margin = median unit price - rolled-up cost`. Same demand weighting. Now it answers the incumbents' real question: what earns the most to craft right now. The **grouping by profession** needs A's recipe -> skill mapping even for Phase 1, so the whole page is gated on A. ## Scope & done Model on `pages/Jobs.tsx`: one section per profession/specialty, reuse `RankList` bars, reuse the supply-gap severity treatment (glyph + label + color, never color alone) for the "why this ranks" callouts. One heading tier, minimal prose. vitest tests. Update `docs/FEATURES.md`. Green on `ward exec` test + lint. Full reasoning on #98.
Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-eco-app-103 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T17:10:39Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)
  • Resolved: coilyco-gaming/eco-app#103 · branch issue-103 · harness codex · workflow direct-main
  • Run: engineer-codex-eco-app-103 · ward v0.451.0 · dispatched 2026-07-08T17:10:39Z
  • Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Issue body as seeded:

The "most valuable to craft, per profession" page from the #98 design: a jobs-page-like layout leaning hard into the Supply-gaps signal, listing the highest-value things to craft for each profession. This is follow-up **D**, and it settles the open "what does valuable mean" question Kai flagged.

**Depends on #98-A** (the recipe -> skill mapping that gives the per-profession grouping). **Enhanced by #98-C** (true margin). Do not start until A has landed.

## The definition of "valuable" (recommended on #98)

North star: **margin-weighted opportunity = expected profit per unit x how much you can actually sell**, shipped in two phases:

- **Phase 1 (data available once A lands) - revenue opportunity.** `opportunity = market median unit price (market.py) x unmet demand qty (logistics.py supplyGaps.demandQty)`, boosted when `reason in {no_supply, thin_supply}`, gated by a liquidity floor from `trades.py byItem` currency volume so one thin trade cannot top the board. Label it honestly as revenue, not profit.
- **Phase 2 (after C) - true margin.** Swap median unit price for `margin = median unit price - rolled-up cost`. Same demand weighting. Now it answers the incumbents' real question: what earns the most to craft right now.

The **grouping by profession** needs A's recipe -> skill mapping even for Phase 1, so the whole page is gated on A.

## Scope & done

Model on `pages/Jobs.tsx`: one section per profession/specialty, reuse `RankList` bars, reuse the supply-gap severity treatment (glyph + label + color, never color alone) for the "why this ranks" callouts. One heading tier, minimal prose. vitest tests. Update `docs/FEATURES.md`. Green on `ward exec` test + lint. Full reasoning on #98.

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.451.0).

— Codex, via ward agent

<!-- ward-agent-reservation --> 🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-eco-app-103` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T17:10:39Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh** — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-gaming/eco-app#103` · branch `issue-103` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-eco-app-103` · ward `v0.451.0` · dispatched `2026-07-08T17:10:39Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). **Issue body as seeded:** ``` The "most valuable to craft, per profession" page from the #98 design: a jobs-page-like layout leaning hard into the Supply-gaps signal, listing the highest-value things to craft for each profession. This is follow-up **D**, and it settles the open "what does valuable mean" question Kai flagged. **Depends on #98-A** (the recipe -> skill mapping that gives the per-profession grouping). **Enhanced by #98-C** (true margin). Do not start until A has landed. ## The definition of "valuable" (recommended on #98) North star: **margin-weighted opportunity = expected profit per unit x how much you can actually sell**, shipped in two phases: - **Phase 1 (data available once A lands) - revenue opportunity.** `opportunity = market median unit price (market.py) x unmet demand qty (logistics.py supplyGaps.demandQty)`, boosted when `reason in {no_supply, thin_supply}`, gated by a liquidity floor from `trades.py byItem` currency volume so one thin trade cannot top the board. Label it honestly as revenue, not profit. - **Phase 2 (after C) - true margin.** Swap median unit price for `margin = median unit price - rolled-up cost`. Same demand weighting. Now it answers the incumbents' real question: what earns the most to craft right now. The **grouping by profession** needs A's recipe -> skill mapping even for Phase 1, so the whole page is gated on A. ## Scope & done Model on `pages/Jobs.tsx`: one section per profession/specialty, reuse `RankList` bars, reuse the supply-gap severity treatment (glyph + label + color, never color alone) for the "why this ranks" callouts. One heading tier, minimal prose. vitest tests. Update `docs/FEATURES.md`. Green on `ward exec` test + lint. Full reasoning on #98. ``` Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.451.0). </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Member

WARD-OUTCOME: done - added the per-profession craft-value board on /jobs
The jobs page now ranks liquid supply-gap crafts by true margin, and the existing roster and progression flows stayed intact. The only friction was the frontend toolchain gap in this container, which I had to bridge with corepack before the ward test and lint gates could run. I am confident in the result, but the liquidity-floor threshold is still a heuristic worth tuning if live data feels too sparse.

WARD-OUTCOME: done - added the per-profession craft-value board on /jobs The jobs page now ranks liquid supply-gap crafts by true margin, and the existing roster and progression flows stayed intact. The only friction was the frontend toolchain gap in this container, which I had to bridge with corepack before the ward test and lint gates could run. I am confident in the result, but the liquidity-floor threshold is still a heuristic worth tuning if live data feels too sparse.
Sign in to join this conversation.
No description provided.