The Crucible joins the 3D assembly scene with visible socket, chipset, and power diagnostics.Interface 1 / 7
The prototype includes a dedicated 3D configuration interface and visible compatibility feedback.
Prototype interfaces · demo data
Current product boundary
BASE 60 is an advanced portfolio prototype, not a production store. The storefront, builder, compatibility logic, data layer, and payment foundations are implemented; production authentication, payment reconciliation, live telemetry, broader automated tests, and a complete accessibility review remain future work.
01 / Product status
Advanced prototype
Ongoing development · not launched
02 / Ownership
Product + full stack
Concept · interface · 3D · commerce · data
03 / Platform
Next.js commerce + WebGL
PostgreSQL · Prisma · Three.js
04 / Evidence level
Functional foundations
Real interfaces · synthetic telemetry
Foundry dossier / The hidden system
01—06
The spectacle only works because the rules underneath are real.
Next: why PC buying is a constraint problem—and how the compatibility resolver keeps domain logic independent from the 3D scene.
02 / The constraint problem
02 / COMPATIBILITY
A beautiful build is still wrong if the parts disagree.
PC configuration is a chain of physical, electrical, and platform constraints. BASE 60 makes those rules visible before a customer commits to a build.
Resolver contract
The compatibility layer receives a component manifest and returns structured findings. The 3D scene consumes that result; it does not own the rules.
resolveCompatibility(manifest)
COMPATIBLE / READY
CONFLICT / EXPLAIN
A pure resolver keeps domain decisions testable, reusable, and independent from presentation timing.
The buyer's question
Will these parts actually work together?
The interface answers with a reason, not a mysterious disabled button: socket mismatch, memory generation conflict, insufficient power, or a clearance limit.
FEEDBACK BEFORE CHECKOUT
The rule surface
6 RULE FAMILIES
Six families carry the engineering risk.
Each family maps to a decision the resolver can explain. The list is intentionally concrete: it gives the visual builder an operational vocabulary.
01
Socket + chipset
Match CPU and motherboard sockets, then account for chipset and BIOS support.
02
Memory generation
Keep DDR generation, capacity, and board limits aligned with the selected platform.
03
Power + connectors
Compare system demand with PSU capacity and the connectors the build requires.
04
GPU clearance
Check card length against chassis clearance before a physical fit becomes a return.
05
Cooling envelope
Validate cooler height, radiator dimensions, and the case's thermal headroom.
06
M.2 + expansion
Respect M.2 slots, lane sharing, and the expansion layout of the chosen board.
Architecture / Separation of concerns
ONE SOURCE OF TRUTH
One source of truth, four ways to experience it.
The same result can guide a product card, a builder alert, a cart guard, or an admin review because the rule engine is not coupled to one screen.
01
Manifest
Selected parts and their compatibility metadata enter as structured input.
02
Rules
Pure checks compare sockets, dimensions, power, thermals, and expansion.
03
Shared state
Zustand carries the build and structured alerts across the experience.
04
3D feedback
The Crucible renders the current assembly and makes conflicts legible.
The visual layer can animate, explain, and recover from a conflict without silently rewriting the domain decision.
03 / The operations layer
03 / OPERATIONS LAYER
The customer sees a store. The team needs a command center.
The Overseer gives the product a second audience: the people who maintain the registry, move orders through fulfilment, and watch the signals behind the experience.
01 / NODE
Registry
Product identity, technical attributes, inventory, and media stay coherent as modules are added.
02 / NODE
Dispatch
Order records and fulfilment states become a deliberate operational sequence instead of a hidden backend detail.
03 / NODE
Telemetry
Signals make sales velocity and stock saturation visible—without pretending demo values are production analytics.
Module deployment
A product is more than a photo and a price.
The ingestion flow treats a hardware module as a system record: its identity, specifications, allocation, and visual assets arrive together.
VISUAL INGEST TERMINAL
READY / DEMO
01
Core identity
Name, SKU, manufacturer, and category establish a stable registry record.
02
Technical parameters
Processor, dimensions, compatibility metadata, and other domain facts stay structured.
03
Stock allocation
Pricing and initial inventory are captured as part of the same deployment flow.
04
Visual assets
Upload and preview product media before it enters the public catalogue.
The interface and upload flow are portfolio evidence. Cloud delivery, production validation, and permission hardening remain future work.
Order operations
ORDER STATE / 04
Every order is a state change someone has to own.
The order workspace exposes the handoffs between payment, review, clearance, and fulfilment so the system can be operated—not merely admired.
DISPATCH HUB
SEEDED RECORDS / NOT LIVE
01
Queued
A new order enters the operational queue with its manifest and customer context.
02
Review
The team checks the order details and the selected configuration before fulfilment.
03
Cleared
A valid order can move forward with an explicit operational status.
04
Complete
The final state closes the loop for the team and the customer.
The interface demonstrates the intended order-management surface. Webhooks, idempotency, fulfilment integrations, and refund handling are not claimed as complete.
Signals / Evidence boundary
A dashboard is useful only when its numbers have provenance.
The Overseer visual language makes operational signals easy to scan, while the case study stays precise about what the current prototype can prove.
FOUNDRY TELEMETRY
SYNTHETIC SAMPLE
ACTIVE TRANSFERS
008
FOUNDRY HEALTH
99.2%
SIGNAL STRENGTH
99.8 MS
The dashboard composition and visualization direction are real interface evidence. The displayed metrics are seeded demonstration values, not measured adoption, revenue, or live operations results.
05 / What the prototype proves
05 / CURRENT STATE
BASE 60 is a connected product idea with real engineering underneath.
The prototype demonstrates how storefront, compatibility logic, a 3D builder, cart foundations, and operations can behave as one system—not five disconnected screens.
Current classification
Advanced prototype · ongoing
The decisions that hold it together
DECISION RECORD / 001—003
The visual language is expressive. The architecture stays deliberate.
Three choices keep the foundry concept useful instead of decorative.
D-01
Rules before spectacle
Compatibility is modeled as a separate resolver so the 3D scene can explain decisions without becoming the source of truth.
D-02
Server + client islands
Catalog and commerce foundations stay server-friendly while interactive builder state lives where the feedback needs to be immediate.
D-03
Signals with provenance
The Overseer makes operations visible, but demo records and telemetry are labeled instead of being presented as business results.
The next build
NOT SHIPPED / NEXT BUILD
Make the foundry trustworthy in production.
The roadmap is deliberately practical: harden the boundary between an impressive prototype and a dependable commerce product.
Add production authentication, role-aware admin permissions, protected media workflows, and audit trails for sensitive operations.
N-03
Measure the real system
Replace seeded telemetry with live aggregation, add automated coverage for compatibility and checkout, and optimize 3D loading for constrained devices.
N-04
Finish the human layer
Run a full keyboard, screen-reader, reduced-motion, contrast, and localization review across the storefront, builder, and operations surfaces.
End of dossier / Start of conversation
Build the difficult product, then make its rules visible.
BASE 60 is a working exploration of how expressive frontend work can carry serious domain logic. The next version is where those foundations become a production system.
