SOMETHINGS-ON

A guided studio for emerging fashion designers: keep what matters, change one thing, compare the result, and continue.

Comment

Inspiration

Emerging fashion designers often begin with scattered evidence: screenshots, saved products, phone photos, links, and half-formed preferences. Turning that material into a clear design decision can be difficult without formal vocabulary, a team, or expensive tools.

SOMETHINGS-ON is built around a simple working loop:

Collect evidence. Name what stays. Change one thing. Compare. Continue.

The product draws on process-level ideas about visible authorship, restrained edits, and access to creative tools. It does not imitate a living designer or reproduce a label's products, campaigns, logos, or visual identity. References are translated into neutral traits that the designer can approve or reject.

What it does

SOMETHINGS-ON is a guided creative workspace, not a one-click clothing generator and not a blank canvas.

A designer can:

  • Select labels as taste hypotheses and review neutral traits.
  • Choose a durable garment object, such as a T-shirt.
  • Add local images, catalog references, or saved link cards.
  • Search a local Inspiration library containing 600 sourced products from 20 labels.
  • Ask a guided design agent to identify what should remain and propose one intentional change.
  • Request four image candidates for comparison.
  • Choose which candidate becomes the next immutable design version.
  • Inspect the chosen version through linked back, left, and right technical views.
  • Generate a separate fictional-adult Editorial presentation without changing the garment version.
  • View source references, prompts, changes, and parent lineage throughout the process.

The designer remains the author. The system proposes and executes; the designer selects, rejects, branches, or undoes.

How we built it

The frontend uses Vite, React, TypeScript, Tailwind CSS v4, Motion, ChatKit, and locally owned Radix primitives. The backend uses FastAPI, Python, the OpenAI Agents SDK, SQLite, and LanceDB.

The guided design agent is powered by GPT-5.6. It works within a bounded design contract: identify an invariant, name one variable to change, restate KEEP and CHANGE, and offer a reversible decision.

Image iteration uses gpt-image-2. A request produces four candidates tied to one parent version and one generation job. Candidates remain outside version history until the designer chooses one. The selected candidate is then saved as the next immutable child.

For the prepared DevDay story:

  1. Version 01 is a direct OpenAI generation of a washed-charcoal flight bomber over a white T-shirt.
  2. Version 02 edits the exact Version 01 PNG into an inside-out construction study with exposed seams and orange bartacks.
  3. Version 03 edits the exact Version 02 PNG by shortening only the bomber body to a high-hip crop.

Prompts, request IDs, hashes, settings, and parent inputs are recorded. Technical views are derived from the exact chosen canonical raster. Editorial renders are separate records linked to a garment version and cannot replace or alter it.

Codex was the primary development environment for the core implementation. It supported work across the React interface, FastAPI services, catalog indexing, image-generation contracts, persistence boundaries, accessibility states, and validation workflow.

Challenges

The central challenge was preserving authorship while making the system useful. A broad request can easily become an uncontrolled image-generation prompt, so the product narrows each edit to one meaningful variable: proportion, material, construction, finish, placement, color, or mood.

Image lineage required a separate transaction model. The current version must remain visible during generation, comparison, dismissal, or failure. A candidate cannot become design truth until the designer selects it. Later edits must use the exact raster owned by the selected parent rather than a text-only reconstruction or an earlier ancestor.

The product also separates several kinds of visual material:

  • Canonical garment rasters are immutable design truth.
  • Four-way candidates are temporary comparison objects.
  • Technical views are derived inspections.
  • Editorials are separate presentations.
  • React and SVG illustrations are interface elements, not generated garments.

The workspace also needed to remain tactile without losing control. It supports pointer and keyboard panning, pointer-anchored zoom from 35% to 400%, restrained tilt, reset and fit controls, and an in-bounds right-click tool menu.

Accomplishments

  • Built an end-to-end onboarding flow with optional ritual steps, skip and back paths, local persistence, and reduced-motion support.
  • Implemented a searchable 600-product Inspiration catalog with LanceDB full-text search, complete browse facets, and same-origin local image caching.
  • Created a studio canvas with chat on the left, the active design centered, and references arranged around it.
  • Implemented four-candidate comparison so only the designer's selection advances version history.
  • Preserved exact parent-to-child raster lineage for the prepared three-version DevDay story.
  • Added linked back, left, and right technical views generated from the chosen canonical raster.
  • Added a separate Editorial layer for fictional-adult presentation renders.
  • Kept label references as neutral research signals rather than replication instructions.
  • Added honest generation states for queued, running, succeeded, and failed work.
  • Preserved the previous ready version when image generation, persistence, selection, or derived-view work fails.
  • Kept credentials server-side and provided a local read-only conversation fallback when OpenAI or ChatKit configuration is incomplete.
  • Included keyboard controls, semantic state, visible generation text, reduced-motion behavior, and exposed skip, reject, undo, and reset paths.

What we learned

A useful creative agent needs limits that protect the designer's decision rather than replace it. Asking what stays before asking what changes makes the edit legible and gives the designer a concrete basis for comparison.

The image itself is only one part of the product. Parent inputs, prompts, sources, candidate state, technical views, and presentation boundaries are necessary for a designer to understand how a result emerged.

Reliability must also be visible. A failed generation should leave the previous version intact and explain what can happen next. A placeholder or unrelated image would undermine the design conversation.

What's next

Future work can extend the guided edit loop while preserving its boundaries. Possible directions include production-ready authentication and collaboration, licensed or project-owned replacement assets for the research catalog, richer object and reference workflows, and deeper manufacturing-oriented tools such as specifications or tech packs.

The next step should remain the same in principle: make the designer's decision clearer without taking authorship away.

How Codex accelerated the work

Codex was the primary development environment for the core implementation. It helped coordinate changes across the frontend and backend while keeping the product grounded in its copy, architecture, image-iteration, accessibility, and safety contracts.

That was especially useful for work that crossed system boundaries: connecting ChatKit to project context, keeping candidate sets separate from immutable versions, enforcing exact-raster edit inputs, serving local catalog images, preserving presentation boundaries, and maintaining consistent failure behavior across API and UI states.

Built With

Share this project:

Updates