VC / ENGINEERING
VINICIUS CARVALHO / Senior Software EngineerCONTACT CARD ↗

Software engineering that scales, and automates itself.

░▒▓ VC ▓▒░

Senior Software Engineer with over 12 years of experience across architecture, platform and applied AI. I build apps, backends and tooling that help teams ship better.

01 / IDEA02 / SPEC03 / AGENTS04 / PR05 / PRODUCTION

01 / BUILD

Selected work

Shell / TypeScript / Python

monozukuri

Turn a backlog into small, reviewable PRs.

★ 6 · 28/10/2026View project ↗

TypeScript / API / Cache

SavePlace

A social URL. A verifiable place.

★ 0 · 28/10/2026View project ↗

Python / CI / Diagnostics

ci-guard

Diagnose before retrying.

★ 0 · 28/10/2026View project ↗

Swift / SwiftUI / Agent skills

swift-code-reviewer-skill

Layered review. Context first.

★ 38 · 28/10/2026View project ↗

TypeScript / Skills / Templates

Feature-marker

From intent to an executable plan.

★ 11 · 28/10/2026View project ↗

TypeScript / Notion / OAuth

gastandoya-api

Integrations that respect boundaries.

★ 0 · 28/10/2026View project ↗
ArchiveAll repositories ↗

Archive

BUILD / SYSTEMS & DECISIONS

Architecture in motion.

Explore my process and the decisions behind each project. Select a component to understand its responsibility.

THE PIPELINE / SYSTEM MAP

How I structure delivery

A reading of patterns across the six projects: make intent explicit, separate responsibilities and gather evidence before moving forward.

  1. 01 / StepIntent & criteria
  2. 02 / StepSpec & decisions
  3. 03 / StepBoundaries & contracts
  4. 04 / StepIsolated execution
  5. 05 / StepLayered validation
  6. 06 / StepReviewable delivery
  7. 07 / StepFeedback & memory

Step 1 / 7

Intent & criteria

Define the problem, scope and acceptance criteria in readable artifacts. References: Feature-marker and monozukuri.

Step 2 / 7

Spec & decisions

Turn requirements into a technical plan and tasks; challenge gaps before implementation. Reference: Feature-marker.

Step 3 / 7

Boundaries & contracts

Separate extraction, verification and persistence in SavePlace; keep Notion connections in the GastandoYa backend.

Step 4 / 7

Isolated execution

Worktrees, agents and cost controls in monozukuri; execution artifacts remain in the repository.

Step 5 / 7

Layered validation

Review specification adherence and architecture with swift-code-reviewer-skill; classify failures with ci-guard.

Step 6 / 7

Reviewable delivery

monozukuri opens PRs; Feature-marker ends with a local commit and handoff. These are different delivery contracts.

Step 7 / 7

Feedback & memory

Provenance-aware memory in monozukuri and proposed standards in the reviewer inform the next iteration.

Architecture is expressed through decisions and boundaries, as well as the stack.

Connections and conditions
  • Intent & criteria → Spec & decisionsDefines the plan
  • Spec & decisions → Boundaries & contractsMakes contracts explicit
  • Boundaries & contracts → Isolated executionGuides implementation
  • Isolated execution → Layered validationProduces evidence
  • Layered validation → Reviewable deliverySupports review
  • Reviewable delivery → Feedback & memoryRecords learnings
  • Feedback & memory → Intent & criteriaInforms the next iteration
GitHub sourcesFeature-marker / README ↗monozukuri / README ↗SavePlace / README ↗ci-guard / README ↗swift-code-reviewer-skill / README ↗gastandoya-api / README ↗

Illustrative walkthrough of documented components; it does not run the projects. Sources reviewed on 2026-10-28.

Explore components or play the walkthrough.

THE PIPELINE / SYSTEM MAP

monozukuri

Orchestration outside the agent, per-feature execution and memory across deliveries.

  1. 01 / StepBacklog & selection
  2. 02 / StepIsolated worktree
  3. 03 / StepAgent phases
  4. 04 / StepTests & limits
  5. 05 / StepPull request
  6. 06 / StepMemory v2

Step 1 / 6

Backlog & selection

pick ranks or selects features; loop coordinates the work queue.

Step 2 / 6

Isolated worktree

Each feature receives an independent workspace for reviewable changes.

Step 3 / 6

Agent phases

PRD, TechSpec, Tasks and Code run with the configured agent and project skills.

Step 4 / 6

Tests & limits

Validate delivery and respect cost, time and token limits. Checkpoints allow resumption.

Step 5 / 6

Pull request

The result is a separate change accompanied by a summary and evidence for review.

Step 6 / 6

Memory v2

Store learnings, provenance and application context; the router injects summaries before detail.

Isolate work and preserve context without coupling the workflow to one agent.

Connections and conditions
  • Backlog & selection → Isolated worktreeSelects a feature
  • Isolated worktree → Agent phasesProvides isolation
  • Agent phases → Tests & limitsDelivers changes
  • Tests & limits → Pull requestDelivery validation
  • Pull request → Memory v2Preserves learnings
  • Memory v2 → Agent phasesReuses context
GitHub sourcesmonozukuri / README ↗

Illustrative walkthrough of documented components; it does not run the projects. Sources reviewed on 2026-10-28.

Explore components or play the walkthrough.

THE PIPELINE / SYSTEM MAP

SavePlace

From social evidence to a verified place, with explicit saving.

  1. 01 / StepPublic URL
  2. 02 / StepCache & idempotency
  3. 03 / StepAI extraction
  4. 04 / StepPlaceProvider
  5. 05 / StepReview & evidence
  6. 06 / StepPrivate library

Step 1 / 6

Public URL

The supported input is a public TikTok URL; the adapter obtains official oEmbed metadata.

Step 2 / 6

Cache & idempotency

Reuse source analysis and replay; PostgreSQL separates reusable cache from private per-session history.

Step 3 / 6

AI extraction

Metadata supports structured candidates. Prompt, tokens, estimated cost and latency are recorded.

Step 4 / 6

PlaceProvider

Google Places confirms geographic identity. Only the provider can mark a place as verified.

Step 5 / 6

Review & evidence

Ambiguity or missing evidence becomes a review state, without inventing an address or coordinates.

Step 6 / 6

Private library

An explicit click saves a verified place to the session library; saved data can be managed later.

AI proposes candidates. The provider verifies the place. The person decides to save.

Connections and conditions
  • Public URL → Cache & idempotencyLooks up existing analysis
  • Cache & idempotency → AI extractionCache miss
  • AI extraction → PlaceProviderSends candidates
  • PlaceProvider → Review & evidenceResult or ambiguity
  • Review & evidence → Private libraryExplicit confirmation
  • Cache & idempotency → Review & evidenceCache hit or replay
GitHub sourcesSavePlace / README ↗

Illustrative walkthrough of documented components; it does not run the projects. Sources reviewed on 2026-10-28.

Explore components or play the walkthrough.

THE PIPELINE / SYSTEM MAP

ci-guard

A CI failure becomes a classified decision with budgets and verification.

  1. 01 / StepCI snapshot
  2. 02 / StepClassification
  3. 03 / StepRetry budget
  4. 04 / StepVerify the green
  5. 05 / StepLedger & human decision
  6. 06 / StepFix or investigate

Step 1 / 6

CI snapshot

Capture failing checks and logs before any rerun attempt.

Step 2 / 6

Classification

Distinguish branch, infrastructure, flaky test, dependency and unknown failures. Python scripts make no LLM calls.

Step 3 / 6

Retry budget

Eligible failures may retry only within per-job, per-PR and minutes budgets.

Step 4 / 6

Verify the green

A flaky test that turns green requires additional verification on the same SHA.

Step 5 / 6

Ledger & human decision

Record flakiness history; recommend quarantine when criteria apply. A person decides.

Step 6 / 6

Fix or investigate

branch_failure requires a fix; unknown requires manual log inspection. Exhausted budgets stop retries.

Fixing code, investigating and retrying are different paths.

Connections and conditions
  • CI snapshot → ClassificationCollects evidence
  • Classification → Retry budgetFailure eligible for retry
  • Classification → Fix or investigateBranch or unknown
  • Retry budget → Verify the greenFlaky turned green
  • Retry budget → Fix or investigateBudget exhausted
  • Verify the green → Ledger & human decisionRecords verification
GitHub sourcesci-guard / README ↗

Illustrative walkthrough of documented components; it does not run the projects. Sources reviewed on 2026-10-28.

Explore components or play the walkthrough.

THE PIPELINE / SYSTEM MAP

swift-code-reviewer-skill

One review core adapted to four agent runtimes.

  1. 01 / StepDiff, spec & standards
  2. 02 / StepAgent wrappers
  3. 03 / StepSeven layers
  4. 04 / StepPrioritized report
  5. 05 / StepRecurring patterns

Step 1 / 5

Diff, spec & standards

Read changes, acceptance criteria and project standards before assessing code.

Step 2 / 5

Agent wrappers

Claude, Codex, Gemini and Kiro receive instructions in each runtime’s formats and paths.

Step 3 / 5

Seven layers

Specification, Swift, SwiftUI, performance, security, architecture and project standards.

Step 4 / 5

Prioritized report

Findings by file and severity, with actions to guide the next review.

Step 5 / 5

Recurring patterns

Group repeated findings and propose project rules; suggestions are not automatic approval.

Review code against intent and project standards.

Connections and conditions
  • Diff, spec & standards → Agent wrappersProvides review context
  • Agent wrappers → Seven layersShares the core
  • Seven layers → Prioritized reportOrganizes findings
  • Prioritized report → Recurring patternsDetects recurrence
  • Recurring patterns → Diff, spec & standardsProposes new standards
GitHub sourcesswift-code-reviewer-skill / README ↗

Illustrative walkthrough of documented components; it does not run the projects. Sources reviewed on 2026-10-28.

Explore components or play the walkthrough.

THE PIPELINE / SYSTEM MAP

Feature-marker

The package installs assets; the agent drives work and leaves artifacts in the repository.

  1. 01 / StepInstaller & templates
  2. 02 / StepAgent request
  3. 03 / StepPRD → Spec → Tasks
  4. 04 / StepImplementation grill
  5. 05 / StepImplement & verify
  6. 06 / StepLocal commit & handoff

Step 1 / 6

Installer & templates

Copy the skill and templates for Claude, Codex or Gemini; the CLI does not execute the workflow.

Step 2 / 6

Agent request

Invoke the skill in a Git project and work on a feature branch.

Step 3 / 6

PRD → Spec → Tasks

Produce readable Markdown files in tasks/{slug}, preserving intent and plan.

Step 4 / 6

Implementation grill

Challenge scope, tests and handoff before implementation; resolve gaps in the artifacts.

Step 5 / 6

Implement & verify

Run tasks and verification inside the agent runtime, preserving unrelated work.

Step 6 / 6

Local commit & handoff

Deliver a branch and push/PR commands. The workflow does not publish or open PRs automatically.

Skill distribution and feature execution have separate responsibilities.

Connections and conditions
  • Installer & templates → Agent requestMakes the skill available
  • Agent request → PRD → Spec → TasksMakes intent explicit
  • PRD → Spec → Tasks → Implementation grillReviews the plan
  • Implementation grill → Implement & verifyResolves gaps
  • Implement & verify → Local commit & handoffDelivers evidence
GitHub sourcesFeature-marker / README ↗

Illustrative walkthrough of documented components; it does not run the projects. Sources reviewed on 2026-10-28.

Explore components or play the walkthrough.

THE PIPELINE / SYSTEM MAP

gastandoya-api

From per-user OAuth to normalized expenses for the iOS app.

  1. 01 / StepiOS app
  2. 02 / StepBackend & OAuth
  3. 03 / StepPer-user connection
  4. 04 / StepDatabase discovery
  5. 05 / StepExpense service
  6. 06 / StepExpenseDTO → iOS

Step 1 / 6

iOS app

Start authorization and consume backend endpoints with the documented headers.

Step 2 / 6

Backend & OAuth

Start authorization, validate state on callback and exchange the code for a token on the server.

Step 3 / 6

Per-user connection

UserNotionConnectionStore uses KV when configured or memory as fallback. Tokens are not sent to the client.

Step 4 / 6

Database discovery

Discover databases through Blocks API or Search API and handle pagination and selection.

Step 5 / 6

Expense service

Query the selected database and normalize records into ExpenseDTO.

Step 6 / 6

ExpenseDTO → iOS

The app receives normalized data; the OAuth callback returns through an intermediate deep link.

Connections stay on the server; the client consumes an expense contract.

Connections and conditions
  • iOS app → Backend & OAuthAuthorizes the connection
  • Backend & OAuth → Per-user connectionStores token on server
  • Per-user connection → Database discoveryProvides Notion connection
  • Database discovery → Expense serviceConfigured database
  • Expense service → ExpenseDTO → iOSNormalizes response
  • ExpenseDTO → iOS → iOS appDisplays expenses
GitHub sourcesgastandoya-api / README ↗

Illustrative walkthrough of documented components; it does not run the projects. Sources reviewed on 2026-10-28.

Explore components or play the walkthrough.

02 / STACK

From interface to infrastructure.

Consistent interfaces start with contracts, tokens and reusable components.

03 / LOG

Software is continuous craftsmanship.

My background connects mobile engineering, architecture and developer tooling. My work also explores AI agents and software delivery workflows.

Vinicius Carvalho
● ● ●engineering.log

Mercado Livre

Grupo OLX

TELUS Digital

$ git log --oneline_

04 / CONNECT

Let’s build something.