LJCommunity Workbench
✦ Comfy × Valheim · Lumberjacks P7

Community Workbench

Eight tools. What each one actually does today, what it costs you to run it, and exactly how to take one over.

Running one of these once and saying what happened — including that it broke — is a complete contribution.

Volunteers carried this community. An unclaimed tool is not a verdict on anyone.

This catalog is an invitation to run and own tools. It is not a judgment on anyone's past effort and it is not a verdict on anyone's burnout — volunteers already carried this community, and the work they did is why any of this exists. Nothing here is owed by anyone. A tool sitting unclaimed is a description of this catalog, never a mark against the people who came before.

The path in: join → read How this works — read me first → post in a tool's thread. Those last two and the #workbench forum are member-only Discord links; they will not open until you have joined.

Published from e71fb25 · 2026-08-12 16:19 UTC 2 live · 1 dev-only · 5 local-only 14 first tasks open
00 · YOUR VIEW

Start with the question you brought.

Each lens is a table of contents over the same underlying catalog. Pick more than one, or ignore them and explore everything; no record is hidden because it sits outside a chosen lane.

These are starting points, not access controls. Cross the lane and inspect all 8 tools.

01 · THE TOOLS

Every status below is what the thing actually does today.

A status chip here is never a mood. It is one of four declared states, and every one of them is qualified in prose by the person who wrote the code. Where something does not run, the card says so and points at where the pieces are.

Quest Picker + Absorption Engine

quest-picker
LIVE

Turns a guild's real quest tracker into a single offline page where a player checks the quests they care about — and the game mod reads the result.

What that status actually meansRuns today against real guild tracker exports: the harvest, the validator, and the picker all work end to end, and the mod reads the quest-view.json the picker saves. A hosted synthetic sample is available at /questpicker; the download below is the same verified sample plus its cold-start kit.

ForGuild stewards and GMs who already keep a quest tracker and want it to reach players in-game instead of dying in a spreadsheet tab.

First resultabout 10 minutes Download
SHA-256f61d0e62e297888eeaedb501af4b9a3fc2d39cc668ab78c65c794ca1afd90a49
Size46.4 KB
Published2026-08-12T16:10:35Z
You will need
  • Python 3
  • openpyxl (only for .xlsx sources)
  • A browser — the picker is a local file:// page, not a service
How it works, in detail

Python (standard library, plus openpyxl for .xlsx sources) harvests real guild quest trackers into one JSON catalog per guild. render_quest_picker.py folds a catalog into a single self-contained file:// HTML page with no server and no network calls. A player opens that page, checks the quests they want, and saves a personal quest-view.json that the game mod reads at runtime.

roadmap A5A7

Pick one to start · 2 open
  • Write gm-template-example.json small
    Done when: validate.py accepts the file and a GM can author a quest through the gm-template seam without editing harvest.py. sources.json already points at this path (entry rangers-example, currently disabled) but the file has never been written. QP-1
  • Run the harvest against your own guild's tracker export medium
    Done when: A new catalog JSON renders in the picker and every anomaly the harvest reported has an explanation — zero left unexplained. QP-2
UNCLAIMED Nobody holds this yet. Completing one of the first tasks above is how that changes.

At stage 3Commit access to recipes/quest-catalogs/ in baseline, and you triage this tool's thread.

Source, privacy & licence

Nothing here is gated — the source is readable now. Ladder stage 3 opens commit access for this tool.

The sovereign comfy-quest repository owns the picker, its recipes, and the exact release imported here.

PrivacyHarvested catalogs from a live guild tracker contain member names. The published sample uses synthetic data only — do not commit a real harvested catalog.
LicenseBUSL-1.1 in this repo (community-steward safe harbor, converting to AGPL-3.0-only; see LICENSING.md). The byte-identical copies in the public comfy archive carry that repo's MIT license.

ComfyStewardView

steward-view
LIVE

Reads a Valheim world file and answers the questions that stop being walkable once a server gets big: where is everyone building, and who owns this.

What that status actually meansA hosted, read-only sample is live at https://am4.tail8e749c.ts.net/steward/ — the full dashboard, DB-backed drilldowns, and pre-rendered map layers over a frozen Comfy Era16 snapshot. The public repo builds the same fat JAR for your own worlds and now ships a Dockerfile plus a one-command deploy script. What is missing is a quickstart for the roughly twenty GM probe utilities — they work, but today you have to read the source to know what each one does.

ForServer stewards and GMs on worlds big enough that walking around stopped being a way to find out what is happening.

First resultinstant for the hosted sample; about 15 minutes against your own world Open repository

Clone and build it yourself — there is no packaged download.

You will need
  • Nothing at all for the hosted sample — just a browser
  • Java (or Docker), for running it against your own world
  • A copy of a Valheim world .db — a copy, never the live save
How it works, in detail

A Java fat-JAR extracts and parses a Valheim world file (.db), exposes a REST API on localhost:7080 (/api/v1/heatmap, /api/v1/points), and serves a browser heatmap viewer. Around twenty GM probe utilities sit alongside it for build-density clustering and ownership investigation.

roadmap A3A7

Pick one to start · 2 open
  • Run it against a copy of any world .db and post one heatmap screenshot small
    Done when: A heatmap image from your own world is in the thread, with the build command you actually used and anything that tripped you up. SV-1
  • Write the missing quickstart for the probe utilities medium
    Done when: Each GM probe utility has one line saying what it answers and one copy-pasteable invocation, and a steward who has never opened the source can pick the right probe from that page alone. SV-2
UNCLAIMED Nobody holds this yet. Completing one of the first tasks above is how that changes.

At stage 3Documentation and feedback stewardship: you own this tool's quickstart and probe-utility docs, and you triage its thread. The repository is all-rights-reserved, so code changes are not on offer here until that licence changes.

Source, privacy & licence

Nothing here is gated — the source is readable now. Ladder stage 3 does not open commit access here — the card above says what it grants.

A standalone public repository, separate from baseline. Clone it and build.

PrivacyRun it on world copies, not the live save. Output can contain player names — share aggregates and screenshots, not raw dumps.
LicenseProprietary — all rights reserved per the repo's own LICENSE.md, which requires written permission and a paid license for reuse. Catalogued here for running it and giving feedback; the license posture is under review, and until it changes, contributions mean docs and feedback, not code redistribution.

Live Community Telemetry

community-telemetry
LOCAL ONLY

An aggregates-only telemetry API with privacy tests that fail if a player ID, name, or position ever shows up — plus the whole stack, runnable on your machine.

What that status actually meansThe aggregates API is live on P7 and the public /community page reads it. What is local-only is everything you would need to run or change it yourself: the docker stack that reproduces the whole thing and the loopback operator dashboard both run on your machine, and neither is published as a download.

ForAnyone who wants to run the telemetry surface themselves — and anyone who would rather check the privacy claim than take it on faith.

First resultabout 5 minutes against the live API; about 30 for the local stack once claimed Download
SHA-256bf065eb47da01f3305ec10c4c6b8ec03d99329cf6a5dc02c2ba5f26eded32211
Size8.3 KB
Published2026-07-29T01:12:00Z
You will need
  • A browser (or Python 3) for the live aggregates API — that is all CT-1 needs
  • Docker and docker compose, for the local stack
  • The .NET 9 SDK, only if you want to rebuild the gateway rather than run the composed image
How it works, in detail

An aggregates-only v0 telemetry API (GET /api/v0/telemetry/server, /tick, /sessions, /delivery, /regions, /events, /valheim, /cutover) whose test suite asserts that no player ID, name, or position ever appears in a response. A self-contained /community page polls it. A local dev stack brings up the real thing end to end (docker compose: postgres 5435, gateway 4000, eventlog 4002, progression 4003, operatorapi 4004), and a loopback-only operator viewer renders it for a single operator.

roadmap A4A7

Pick one to start · 2 open
  • Build one chart, tile, or widget from the public v0 API and post it good first picksmall
    Done when: Any stack you like — a static page, a spreadsheet, a terminal script — renders live data from a v0 endpoint, and the thread has a screenshot plus how you made it. Needs no repo access; the starter kit includes a Python poller. CT-1
  • Bring the local stack up, then add one new aggregate tile the privacy tests still pass on medium
    Done when: The compose stack runs on your machine and a new aggregate is exposed by the v0 API and rendered, with the existing privacy tests passing unmodified. This is the claim path — the source is already public, so nothing blocks you from starting today. CT-2
UNCLAIMED Nobody holds this yet. Completing one of the first tasks above is how that changes.

At stage 3Commit access to the telemetry stack and the operator viewer in baseline, and you triage this tool's thread.

Source, privacy & licence

Nothing here is gated — the source is readable now. Ladder stage 3 opens commit access for this tool.

Public and readable now: Lumberjacks/infra/docker/docker-compose.yml for the stack, Lumberjacks/tools/omen-dashboard/ for the operator viewer.

PrivacyThe v0 API is aggregates-only by tested design — no player ID, no name, no position, ever. Keep that bar: a change that makes the privacy tests fail is a change that does not land.
LicenseBUSL-1.1 with the community-steward safe harbor, converting to AGPL-3.0-only; see LICENSING.md.

Steam Self-Service Join

steam-join
LOCAL ONLY

An invite link, a Steam sign-in, and a mod-pack zip with your credentials already in it — no config file to hand-edit.

What that status actually meansBuilt and working on the Gateway, but NOT publicly reachable today — so there is nothing here for you to click yet. The public /join path on this host currently belongs to a different service entirely, so the enrollment flow is not routed to the internet; that has to be untangled before anyone outside the operator's machine can walk it. Beyond routing, stated plainly: the full Steam sign-in round-trip has never been walked end to end (that is exactly first task SJ-1), rate limiting is not in place, only one client can be admitted at a time while the enrollment queue is shared, and volunteer platform readiness is recorded as NOT READY. The world this would connect you to is not open either. Opening this is gated on the server opening, which has not happened.

ForThe next wave of playtesters — people who will want to join and play without being told to edit a config file first. Not yet available to them.

First resultnot yet — nothing to run until the routing and the server both open Not published yet

No download exists for this today. That is a fact about the packaging, not about whether the code works — read the status above.

You will need
  • Nothing yet — there is no public endpoint to try
  • When it opens: a Steam account, Valheim, and an invite link from the operator
How it works, in detail

An invite link opens a page that hands off to Steam OpenID sign-in. A one-use bootstrap token is exchanged for a personalized mod-pack zip with the player's credentials already baked in. Self-service update and reissue run through the same path. The per-player token is stored only as a hash.

roadmap M2M5A7

Pick one to start · 2 open
  • Walk the join flow end-to-end as a tester and file friction notes small
    Done when: You went from invite link to a running modded client, and every point where you hesitated, guessed, or had to ask is written down in the thread — including the ones that turned out to be your fault. SJ-1
  • Write the tester-facing FAQ from the friction notes medium
    Done when: A page answers the questions SJ-1 actually produced, in a tester's words rather than the operator's, and the next tester gets through without asking any of them. SJ-2
UNCLAIMED Nobody holds this yet. Completing one of the first tasks above is how that changes.

At stage 3Commit access to Lumberjacks/src/Game.Gateway/Valheim/ in baseline, and you triage this tool's thread.

Source, privacy & licence

Nothing here is gated — the source is readable now. Ladder stage 3 opens commit access for this tool.

Public and readable now — SteamEnrollmentEndpoints, SteamEnrollmentService, EnrollmentPages, ModpackReleaseCatalog, with real test suites, plus the operator runbook at infra/gcp/p7/VOLUNTEER-ENDPOINT.md.

PrivacyThe per-player token is stored only as a hash. The zip you receive carries your own credential — do not re-share it; ask for a reissue instead.
LicenseBUSL-1.1 with the community-steward safe harbor, converting to AGPL-3.0-only; see LICENSING.md.

MCP Mod Channel

mcp-mod-channel
DEV ONLY

A localhost MCP server that talks to the running game mod: apply a config profile, run a bounded lab test, read back what happened.

What that status actually meansIt runs, and it really does drive the live mod. It is reachable only from 127.0.0.1 with a dev key, and that is deliberate rather than unfinished: it is a development channel, never a console or shell bridge, and every mutation it can perform is whitelisted and bounded. The Workbench migration requires an explicit project-owned port and machine-readable endpoint identity; the legacy shared :8720 listener is not accepted as Baseline evidence until proven. There is no download and no remote mode.

ForMod developers, and anyone curious about wiring an AI tool to a live game process without handing it a shell.

First resultabout 20 minutes Not published yet

No download exists for this today. That is a fact about the packaging, not about whether the code works — read the status above.

You will need
  • Python 3
  • The mod running locally
  • An MCP client
  • Optional: a local Ollama, only for the explanation tools
How it works, in detail

A local Python MCP server on an explicit Workbench Dev/Lab loopback port (current candidate 8721; header X-Comfy-Key, dev value comfy-dev-local) speaks bidirectionally with the running mod: apply config profiles, run bounded lab motion tests through an atomic mailbox, tail mod telemetry and logs, assemble session bundles, and get local-Ollama explanations of what it just saw.

roadmap A7

Pick one to start · 1 open
  • Run the gateway and list its tools from any MCP client, then post the tool list small
    Done when: The tool list from your own client is in the thread, along with which client you used and anything in the setup that was not obvious. MC-1
UNCLAIMED Nobody holds this yet. Completing one of the first tasks above is how that changes.

At stage 3Commit access to network/mcp/ in baseline, and you triage this tool's thread.

Source, privacy & licence

The source opens when the tool is claimed — until then it is the one gated thing on this card.

The owning isolate repository is private today; an older snapshot exists in the public comfy archive.

PrivacyBound to 127.0.0.1 on purpose. Do not expose it — it drives a live game process, and its whole safety story is that only you can reach it.
LicenseBUSL-1.1 with the community-steward safe harbor, converting to AGPL-3.0-only; see LICENSING.md.

Quest Submission → Review Bridge

quest-submission-bridge
LOCAL ONLY

The back half of quest capture: package what a player did in-game, land it in a review inbox, and turn it into a record a GM can read.

What that status actually meansPorted, not yet live-proven. The front half is alive in the mod today with tests — QuestViewLoader.cs reads a player's quest-view and QuestTriggerEvaluator.cs evaluates triggers in-game. The back half was never a matter of pointing a script at a folder: the old consumer expected an evidence envelope (screenshot, trace, position) that the live mod deliberately does not produce — its proof is the durable EventLog row (ADR 0012). That design call is now decided (ADR 0018: the EventLog row IS the evidence; no re-materialized screenshots) and implemented at tools/quest-bridge/ — EventLog row → thin submission → review record → guild-command export, fixture-proven in tests/test_quest_bridge.py. What remains for QB-1 is the live proof: one real in-game completion through that path. The archive copies at recipes/quest-submission-bridge/ stay as raw material.

ForGMs who want players to submit completions without a screenshot and a Discord message.

First resultAbout 10 minutes against the test fixture (tools/quest-bridge/, tests/test_quest_bridge.py). The live measurement — a real in-game completion out the other end — is QB-1. Not published yet

No download exists for this today. That is a fact about the packaging, not about whether the code works — read the status above.

You will need
  • Python 3, for the bridge consumer
  • The mod running locally with QuestEvaluatorEnabled on
  • Access to the durable EventLog (private plane — the lab box or a tunnel); the review inbox is operator tooling and stays off public surfaces
How it works, in detail

Packages an in-game quest submission, lands it in a review inbox, and renders human-readable quest records a GM can act on without chasing screenshots.

roadmap A5A7

Pick one to start · 1 open
  • Prove the ported bridge live: one real in-game completion, EventLog to review record (design: ADR 0018) small
    Done when: A real in-game quest completion, produced by the live mod with QuestEvaluatorEnabled on, is fetched from the durable EventLog by tools/quest-bridge/fetch_completions.py and comes out as one human-readable review record with the quest's guild-command draft. The design call this task used to hide — re-materialize the old screenshot/trace evidence envelope, or accept a thinner record — is decided in ADR 0018 (the EventLog row is the evidence), and the fixture-driven path already passes in tests/test_quest_bridge.py; what remains is the live run. This is the claiming task for this tool. QB-1
UNCLAIMED Nobody holds this yet. Completing one of the first tasks above is how that changes.

At stage 3Commit access to the bridge once the back half lands in baseline, and you triage this tool's thread. The comfy archive it is recovered from stays read-only.

Source, privacy & licence

Nothing here is gated — the source is readable now. Ladder stage 3 opens commit access for this tool.

The ported bridge is in this repo at tools/quest-bridge/, with its design recorded in fieldlab/docs/adr/0018-quest-proof-is-the-eventlog-row.md. The retired ComfyControlSurface originals stay byte-exact and unwired at recipes/quest-submission-bridge/ as raw material.

PrivacyA submission record carries a player's name and what they did. Keep the review inbox off any public surface.
LicenseSplit: the live front half (in this repo's mod) is BUSL-1.1 per LICENSING.md; the recoverable back half lives in the public comfy archive under MIT.

Quest Lab Turnkey Package

quest-lab
LOCAL ONLY

An arcane tome in-game that teaches you exactly what quests are possible, letting you practice writing them before trying them out for real.

What that status actually meansA turnkey client-side mod. Install it, run `lab_setup` in the F5 console, and start learning. All 8 rune schools are hooked, and `lab_setup` also writes you a starter quest file you can edit and reload without restarting. The expansion routes all 34 safe canonical events through the exact evaluator shared with ComfyNetworkSense and prevents local/RPC or overload witnesses from double-completing a quest. Verified live so far: combat, harvest, gallery construction, and the seeded kill quest. The other six schools pass headless contract and game-assembly checks but still need bounded i5 live-suite receipts before they are described as witnessed.

ForCreators and leaders who want to learn how to write custom quests without guessing.

First result10 minutes. Download the zip, drop the DLL in your BepInEx/plugins folder, launch a private world, and run `lab_setup` in the F5 console. It builds you a practice ground and writes a starter quest aimed at something standing in it, so you are never hunting for the thing your quest is about — `lab_target` puts a fresh one in front of you whenever you need another. Download
SHA-256302e98c88dfe9336b6096a7e01e8910cae86a2820e57a946eddd545526d66ce8
Size260.1 KB
Published2026-08-12T16:10:35Z
You will need
  • A private Valheim world
  • BepInEx installed on your client
How it works, in detail

Draws an interactive console over the screen and covers all 86 practical atlas signatures across all 8 schools. Fifty-seven safe signatures normalize into 34 stable creator-facing quest events; low-level witnesses are visible only in a diagnostic profile and cannot bind quests. Edit a JSON file, run `lab_reload`, and watch the shared evaluator fire it or explain why it cannot.

roadmap unlinked

Pick one to start · 2 open
  • Try it and verify one school small
    Done when: Run the lab, try the actions for one school, and post in the thread whether the in-game events fired as the Tome predicted. Combat and harvest have live receipts; the other six schools remain unclaimed ground until the i5 suite witnesses them. QL-1
  • Author a quest that fires small
    Done when: Edit the starter quest file into a quest of your own, get `lab_reload` to report it armed, make it fire, and post the file. A second worked example is worth more than any amount of documentation. QL-2
UNCLAIMED Nobody holds this yet. Completing one of the first tasks above is how that changes.

At stage 3Commit access to the mod.

Source, privacy & licence

Nothing here is gated — the source is readable now. Ladder stage 3 opens commit access for this tool.

A client-only BepInEx plugin.

PrivacyRuns entirely locally. No data leaves your machine.
LicenseBUSL-1.1
02 · THE LADDER

Five rungs, and you can stop on any of them.

Nobody starts as an owner. Each rung says what you did, what you get for it, and where it is written down. Stopping at stage 1 is a complete and finished contribution.

Stage 0

Curious

Read the one-pager for a tool and decided whether it is worth your evening.

You getA straight answer about what runs, what does not, and what it would cost you. Reading owes nobody anything.
Nowhere. There is no sign-up and no list.
Stage 1

Ran it

Ran the tool locally and posted what happened in its thread — including the part where it broke.

You getNamed in the thread. A report that it failed is worth exactly as much as a report that it worked.
The tool's discussion thread.
Stage 2

Fixed one thing

Completed one of the first tasks listed on a tool card.

You getCredited in OWNERS.md, and the tool's ownership state moves to trying.
OWNERS.md, plus the tool's ownership record.
Stage 3

Contributor

Landed two changes on a tool, or revived a recoverable piece back into something that runs.

You getYou triage that tool's thread, and you get the contribution right its own card names — the repositories differ, so the card is authoritative, not this rung. The tool's ownership state moves to claimed.
OWNERS.md, plus the tool's ownership record.
Stage 4

Owner

Sustained the contribution over time, and the project operator agrees you are the person holding it.

You getYou set the tool's direction and you can say no. The ownership state moves to owned.
OWNERS.md, plus the tool's ownership record.