CryptoPust

Work / Engineering case study

Lootwright

Lootwright turns deliberately submitted Path of Exile build material into a structured workflow for traceable analysis and human-readable upgrade planning.

LiveOpen SourcePre-alpha
View Live Application (external)View Source on GitHub (external)

01 / Project introduction

A Laravel-based tool for easier Path of Exile workflows.

Lootwright is intended to make certain Path of Exile workflows easier. It accepts build material that is deliberately submitted and turns it into a structured workflow for traceable analysis and human-readable upgrade planning.

The repository currently provides an application foundation, bounded PoB format intake, workflow and persistence contracts, policy controls, and fixture-backed analysis surfaces. It does not claim to be a completed end-user MVP or to provide authoritative production game findings.

02 / Problem

Make submitted build data easier to follow.

The problem boundary is deliberately narrow: a build is submitted by the person asking for analysis, then the application organizes the available facts into traceable analysis and human-readable upgrade planning.

Unsupported or ambiguous facts are meant to remain visible. The project does not present production findings, prioritized upgrades, or Manual Trade Recipes as available outcomes.

03 / Implementation

Repository-visible implementation.

RuntimePHP 8.4 · Laravel 13.25
ApplicationInertia 3 · Vue 3 · TypeScript
PresentationTailwind CSS · shadcn-vue · Vite
PersistencePostgreSQL system of record
Runtime servicesLaravel cache and queue abstractions
Optional infrastructureRedis · Laravel Horizon
Provider adapterDefault-off, policy-gated OpenAI Responses adapter
Deployment targetLaravel Cloud pre-alpha staging

03 / Implementation detail

One release artifact, separated by responsibility.

Lootwright is structured as a Laravel modular monolith. HTTP, CLI, and background work share one application artifact and security boundary, while the framework-independent core remains under src/.

Typed application use cases and ports connect the delivery layer to isolated domain packages. Build intake has separate PoE1 and PoE2 adapters. Analysis, recommendations, and manual trade planning are expressed as domain/application contracts rather than calculations in controllers or UI.

  1. 01HTTP / InertiaValidated user input and typed requests
  2. 02Application portsWorkflow use cases and policy boundaries
  3. 03Domain coreNormalized facts, rules, findings and recipes
  4. 04InfrastructurePostgreSQL, encrypted storage, queues and adapters

04 / Engineering considerations

Deliberate constraints are part of the implementation.

Decision 01 / Deterministic core

Keep authoritative calculations framework-independent.

Problem: findings and recommendations need to be reproducible and explainable without AI, storage, clocks, or network state.

Decision: parsing contracts, normalized facts, analysis, ranking, and manual recipe construction live in pure PHP packages with explicit evidence, ordering, precision, and ruleset identity.

Why it matters: the same canonical input and ruleset can be tested and compared without Laravel or provider behavior changing the result.

Decision 02 / Format-only intake

Accept deliberate PoB input without fetching or executing it.

Problem: build imports cross a hostile input boundary and can carry ambiguous edition or malformed XML data.

Decision: use bounded, independent PoE1 and beta PoE2 parsers with strict Base64/zlib/XML limits, root-based edition evidence, explicit warnings, and no URL fetch, Lua execution, or client access.

Why it matters: unsupported or ambiguous facts stay visible instead of being silently guessed.

Decision 03 / Policy gate

Make external capabilities deny-by-default.

Problem: game data, providers, and external links can change policy or provenance without changing application code.

Decision: every external capability passes an exact Policy and Provenance Gate; missing, ambiguous, expired, or mismatched evidence denies execution.

Why it matters: configuration cannot quietly broaden integrations, and policy decisions are auditable without logging raw user content.

Decision 04 / Workflow persistence

Use an idempotent, encrypted handoff for queued work.

Problem: a queued analysis cannot rely on request memory, and retries must not create a second logical result.

Decision: persist an encrypted raw artifact only for the bounded queue handoff, keep opaque metadata and hashes in PostgreSQL, use owner-scoped idempotency, and delete the raw object after terminal parsing or expiry.

Why it matters: worker retries, duplicate delivery, and deletion remain explicit workflow states rather than hidden side effects.

05 / Current status

Built deliberately. Still evolving.

Work in progress

The repository describes Lootwright as open-source pre-alpha work. Format-only PoB intake, domain/application contracts, policy and provenance controls, persistence orchestration, evaluation harnesses, and fixture-backed UI foundations are implemented.

The production boundary remains intentionally closed: there is no approved immutable PoE1 ruleset catalog, no authoritative deterministic PoE1 analyzer, and no production findings, prioritized upgrades, or Manual Trade Recipes. PoE2 remains a separate beta format reader, not an active analysis path. Optional OpenAI execution is also policy-gated and default-off.

06 / Technical evidence

Inspect the implementation directly.

The repository and live application are the available external evidence for this case study.

View Source (GitHub)View Live (external)

Next step

Have a backend problem of your own?

Start a Technical Review