Interface Collection

Design problem

A technology list does not tell a prospective client or employer what kinds of products a developer can design, build, and launch. They need to compare projects by task and representative user flow, then inspect a detailed project page or a live site. The English and Russian versions must present the same projects and decisions.

How a change reaches release

1. 01

   Bound the change

   Before work starts, the affected product, change boundary, and verifiable result are recorded. Agents receive non-overlapping areas; shared decisions and final integration stay with the lead. This keeps parallel work reviewable and gives incompatible edits an explicit integration gate.

2. 02

   Generate every view from checked data

   The card, project page, technology map, and both locale versions are built from one typed record. Registry validation fails when a project is missing from a required view or lacks English or Russian copy.

3. 03

   Debug the containerized web/API boundary

   In Aster Ridge, the web application and API run in separate containers. Hot reload covers routine debugging. After dependency changes, the team resynchronizes the mounted volumes; after Docker or Compose changes, it rebuilds the images. Logs and readiness probes show whether the failure is in the API, proxy, or web application. Before release, the same production configuration runs locally: web waits for a healthy API, only the web service is exposed, and the API remains inside the container network.

4. 04

   Let Coolify select the deployment targets

   Every deployed application owns a Dockerfile and a set of watched inputs. When the publication branch changes, Coolify matches the changed paths against that matrix: an application-local change rebuilds one deployment, a shared package rebuilds only its consumers, and documentation changes rebuild none. The matrix is validated against all eight deployment applications and covered by path-selection tests, so a missing application or invalid rule is caught before release.

5. 05

   Release the reviewed commit and inspect the result

   The release contract moves the exact reviewed commit to the publication branch instead of manufacturing a separate snapshot with the same files. Before that update, the built English and Russian routes are inspected in the browser at representative widths. After deployment, the published commit identifier is checked against the selected source commit and the active history. The released version can therefore be reproduced and traced to its source change.

Architecture with a visible effect

• One record, several views

  The catalog, technology map, and project pages receive the same localized data. A visitor sees the same task, representative flow, and stack regardless of where they enter the collection.

• The portfolio does not impersonate the products

  Each project keeps its own routes, data, runtime, and release. The portfolio explains the work and, when a public address exists, opens the product separately. A working demonstration does not depend on the catalog shell.

• The map returns to a readable card

  Selecting a project in the technology map sends only its identifier to the catalog. The catalog scrolls to and highlights the matching card; narrow screens keep the ordinary list. Exploration stays connected to readable project information without a second shared client-state system.