Vertera - Coding-Agent Workflows for Production Frontends by Fedor DorodnovVertera - Coding-Agent Workflows for Production Frontends by Fedor Dorodnov

Vertera - Coding-Agent Workflows for Production Frontends

Fedor Dorodnov

Fedor Dorodnov

Vertera storefront: composition based on the live English homepage. The case describes local coding-agent workflows for the existing applications.
Vertera storefront: composition based on the live English homepage. The case describes local coding-agent workflows for the existing applications.
Vertera includes three independent frontend applications: Boss, with a storefront, account area, checkout and SSR; Admin for operational work; and Partner for the partner workspace. My work in this case was designing and integrating local coding-agent workflows into development of these existing production applications.
I adapted agent engineering practices to the actual Angular repositories: task intake, source analysis, bounded specialist handoffs, implementation, review and recorded outcomes. Practices developed in School Platform became tools for maintaining an existing product with its own components, APIs and team conventions.

A Local Engineering Environment Alongside the Product

Agent instructions, plans and local tool configuration are kept outside shared Git tracking through local exclusions. This keeps engineering context close to the code while maintaining a boundary between the local workflow setup and application changes.
Git exclusions alone cannot establish that production is unaffected. Product changes still need their own checks. The engineering work here is to define what may change, where the source of truth lives, which components are affected and what evidence supports the result.

From a Request to a Checkable Task

The workflow starts with the issue, branch, scope and expected result. Before implementation, it calls for finding the existing owner of the behavior, its callers and the closest reusable mechanism. A specialist receives the goal, allowed paths, write boundaries and expected return format.
Responsibilities are separated across repository analysis, frontend, GraphQL, styles, localization, design and verification. The coordinator retains the overall context and integration work. Design instructions require Figma facts before implementation, followed by checks of dimensions, typography, states and SCSS decisions. MCP configuration includes documentation, Figma and memory tools.
A watchdog separately checks consistency between the plan, task metadata, branch, staging and required material. Its result concerns the workflow state. Code and application checks remain distinct.
The documented task flow separates bounded specialist work, workflow-consistency checks and code or design review.
The documented task flow separates bounded specialist work, workflow-consistency checks and code or design review.

Example: Letting the API Contract Define the UI Change

One Admin task required four new LocalHub event types. Adding entries to a single dropdown would have been incomplete: the change involved the generated GraphQL schema, shared options, separate list filters, a display pipe, forms and mutation-field mapping.
I approached the change from the API contract: inspect the enum, examine creation and update inputs separately, then trace every interface using the values. The new types were aligned across creation options, filters and display labels.
Changing an existing event's type remained unavailable because the update input did not contain typeConst. The interface respected that API boundary. Full schema regeneration also exposed adjacent compilation issues, which were addressed in the change. The saved task record includes passing lint and build checks after those fixes; these are historical results, not a new run for this case study.
Admin event types were aligned across creation, filters and labels. Existing-event type editing was excluded because the update API did not expose that field.
Admin event types were aligned across creation, filters and labels. Existing-event type editing was excluded because the update API did not expose that field.

Example: Reusing Gallery Navigation Behavior

A Boss task concerning product-gallery arrows required tracing Swiper behavior and the existing main-banner implementation. The solution used explicit controls, a shared appCursorFollowNav directive and a slider-hover-nav SCSS mixin for the banners and product slider. Repeated behavior and styles gained a shared owner, while mobile pagination was retained.
The plan records local lint, build and diff checks. Manual browser visual verification remained open in that record, so this case does not claim completed cross-browser acceptance.
A shared directive and SCSS mixin support banner and product-slider navigation. These are explanatory diagrams; manual browser visual acceptance remained open.
A shared directive and SCSS mixin support banner and product-slider navigation. These are explanatory diagrams; manual browser visual acceptance remained open.

Outcome and Engineering Value

The result is a local agent-development environment adapted to three existing applications, with concrete changes grounded in API contracts, component reuse and recorded checks. It shows how I connect task definition, engineering analysis, agent work and frontend implementation.
This does not claim authorship of the entire commerce platform or backend, guaranteed absence of regressions or measured time savings. The applications' production context is owner-confirmed; the technical examples are supported by current source and saved task records.
Stack and tools: Angular, TypeScript, Apollo/GraphQL, SCSS, SSR, Figma, MCP, Python checks, Git.
This experience is relevant to teams introducing AI agents into an existing frontend codebase while retaining control over contracts, responsibilities and change quality.
Like this project

Posted Sep 15, 2026

Local AI-agent workflows across three Angular applications, with scoped tasks, API contracts, specialist review and engineering checks.