Henrique Krause.

Harness gives each project an external environment shared by its Git worktrees. Eleven independent skills cover context, modular planning, handoffs, agent coordination, peer deliberation, change maps and engineering workflows on Codex and Claude Code, backed by one shared instruction file. The workflows guide agents to the context relevant to each task.

Project context outside the repository

Each repository or monorepo has one local environment. Its short map helps agents discover applicable constraints and find relevant context. Useful knowledge lives in Markdown files organized by subject. Temporary plans, team configuration and continuation context exist only when needed; small solo changes require no work record.

Focused workflows and scoped context

Macro plans are modular regardless of the number of agents. Implementation and review fronts can reference the same deliverables while keeping their execution context separate. Handoffs transfer responsibility through canonical file references rather than copied conversations.

When requested, peer deliberation brings agents together to develop an analysis, decision or proposal. Participants contribute and challenge ideas as equals, refine a shared synthesis and preserve material disagreement. Coordination organizes the exchange without deciding which view must prevail.

Execution records and change maps

When an orchestration is organized in fronts, the agents that did the work leave run records and events as they deliver: what changed, the attention points and flows they proved, and the tests behind them. A change map consolidates those records with Git facts into a layered view of the change for review and QA, shown by a local read-only viewer. Solo work needs no records.

Two hosts, one set of instructions

A single instruction file serves Codex and Claude Code: Codex reads it directly, Claude Code imports it, and each host applies a short section of its own. Host mechanics such as memory and managed worktrees are handled by the plugin, so the person sets only practical choices such as language, branch conventions and testing policy.

Worktrees and safe persistence

Worktrees that Harness creates live inside the project environment; worktrees managed by the host are accepted where they are. Cooperating agents can alternate writes in one front; independent writing fronts use separate checkouts. The Python helper protects Markdown updates against overwriting an intervening change.

After a work item is complete, useful knowledge is consolidated and retained deliverables are preserved with updated references before temporary context is moved to the environment trash, which the person purges when convenient. Material still needed by another front or pending handoff remains available. Worktree retirement is a separate decision.

Aviões grew out of a game my girlfriend and I play: counting the planes we see together. I built the app to record our sightings and keep a history of a game that is still part of our everyday lives.

The experience has three main views: a counter, a diary, and a scoreboard. Consecutive sightings by the same person form a streak in the diary. Groups are private and invite-only, each with its own history.

Local recording and synchronization

Once a group has loaded, sightings can still be recorded without an internet connection. The browser keeps a copy of the data in IndexedDB and an ordered queue of pending operations. The interface updates the count without waiting for the server to confirm the change.

When connectivity returns, the server processes the pending operations and applies them to Postgres, the source of truth. It recognizes operations that have already been processed so that retrying a request does not create duplicate records.

This divides responsibility between the two sides: the browser handles interaction and offline recording, while the server validates changes and maintains the shared state.

Group access and application structure

Every read or write of group data goes through a server-side membership check. The server derives identity and permissions from the authenticated session and its own access checks.

The project brings together an installable web app and a separate administration app in a monorepo. They share packages for authentication, data access, types, and localization. The administration app handles users and groups, while the main app stays focused on counting.

Shell explores a chat interface built around a single conversation. It opens with a text field and a block cursor; messages fill the screen as the conversation develops.

The application combines the visual language of terminals with multiline input, prompt history, and Markdown responses.

Native text input with a custom presentation

The block cursor is drawn over a native text field. Its appearance is custom, while editing, selection, and text entry continue to rely on the browser’s standard behavior.

Keyboard controls support sending messages, adding line breaks, retrieving earlier prompts, and clearing the conversation. Waiting and error states are also announced to assistive technologies.

Responses arrive in full before being displayed with a word-by-word reveal animation. The effect is disabled when reduced motion is preferred.

Conversation state and model integration

The browser holds the active conversation in memory and sends it to a Server Action with each new message. The server validates the structure and order of the messages before calling the OpenAI Responses API. The API key stays on the server, and requests disable API response storage.

Reloading the page or clearing the chat removes the local history. Clearing also invalidates in-flight responses, preventing a request that finishes later from repopulating the conversation.

The current scope is a development experiment: a temporary session, without accounts, persistent history, or the usage controls needed to operate as a public service.

this is where i collect what i've been building. i write a little about each project: what it does, my part in it, and why i made certain decisions.

i kept the page close to a small journal, with a single column, text links, and projects that open right in the list. it's available in english, portuguese, and japanese.

notes alongside the code

each project's text lives in a .portfolio/project.md file in its own repository, with separate files for translations. during the build, the site looks for those files in my public github repositories and brings the projects together here.

that lets me update a project's description in the same place i work on it. markdown leaves room for text and images without needing a separate editor.

let’s talk

i added a few ways to start a conversation. you can compare a job with the work and experience i've shared, or find a time in my calendar. booking sends an invitation with a google meet link.

this is a place for thoughts that do not need to become a finished argument right away. each note has room to change, with its translations kept nearby.

the repository holds the writing and prepares its audio. the portfolio reads that content and presents it, but the collection can exist without the site.

published notes include ai-generated narration and timing data for following along with the text. generating that audio is part of publication, so listening does not trigger another generation.

I built Live Translation as a focused experiment in real-time voice interaction. A person chooses two languages, speaks in either one, and hears a natural translation in the other. The project stays deliberately narrow because the architecture is the main subject: what belongs in the application, and what can remain inside a realtime model?

One agent instead of a pipeline

An earlier version split the experience across a transcription session and a separate translation session. That created a boundary between partial and finalized turns, two WebRTC connections, short-lived client credentials, and a queue to coordinate one model with the other.

The current version uses one GPT-Live-1 session instead. The model receives the microphone audio, identifies which of the two configured languages was spoken, and returns the translation as audio. This reduces application-owned synchronization and gives the model responsibility for the part of the interaction that is inherently conversational.

That trade-off is intentional. The application has less control over intermediate text, but the session has fewer moving parts and a smaller failure surface.

A trusted signaling boundary

The browser owns microphone permission and the WebRTC peer connection. The server receives the SDP offer, validates the language pair, creates the Live session with the project API key, and returns the SDP answer.

This keeps the credential boundary explicit without turning the server into a media proxy. Audio continues over the negotiated WebRTC connection, while the server remains responsible for session configuration and lifecycle initialization.

The route also gives the application one place to observe provider failures. A wide event records the request, selected languages, model, duration, outcome, and safe provider metadata without storing SDP or audio.

Translation as an agent contract

The language selectors are not only presentation controls. They become part of the session contract passed to the agent.

The instructions define two directions: primary to secondary and secondary to primary. They also define the quality boundary: the response should preserve meaning, intent, tone, names, numbers, and register, while avoiding literal word-for-word output. The agent is told to translate only, not to answer, acknowledge, explain, or start a normal conversation.

That keeps the application policy small and makes the intended behavior legible at the point where the realtime session is created.

A status-first interface

The visible interface intentionally does not display transcript messages or a reactive agent illustration. It keeps the user oriented with the selected language pair, connection status, start/end controls, and errors.

Audio playback uses a hidden media sink. This leaves the interface quiet while preserving the actual voice interaction. It also makes the boundary between product surface and transport implementation easier to reason about: the browser exposes the session state, while the Live connection carries the conversation.

An experiment with a clear edge

Live Translation is not yet a public translation service. It has no accounts, persistence, recordings, production rate limiting, or external tools. The next questions are about translation quality, interruption behavior, evaluation, and the operational controls required around a paid realtime session.

For now, the value is in the reduced architecture: one agent, one audio path, one server-side signaling boundary, and a small interface that makes the behavior easy to test.

A voice companion with a small interface

Dot is a browser-based voice experiment centered on a pixel orb and a single call control. Starting a call reveals a fixed waveform for the microphone. The orb responds to the model's audio, keeping the two sides of voice conversation visually distinct. Text conversation shares the same screen, with a persistent composer, user bubbles, and assistant Markdown.

The interface uses neutral colors and solid controls. The call button turns red when it ends or cancels a session. Text replies use semantic typography and simple code containers; accessible labels and contextual errors explain controls and failures. The orb adapts the Orbkit SHDR-14 shader, and the waveform uses the base renderer from ElevenLabs UI with centered bars and a gradual release into silence.

Text that follows the reader's pace

Text requests stream through a local endpoint using GPT-6 Luna with no reasoning or application tools. Development can use Codex-managed ChatGPT sign-in; the API provider uses API-key access and is the production default. A startup spinner and sign-in dialog keep authentication separate from the conversation controls.

Received text enters a presentation buffer. A non-cyclic clock varies update intervals, increases chunk size when the queue grows, and bounds the remaining delay after transport completion. The displayed text retains its original Markdown and Unicode content. The agent orb stays below the latest reply and moves smoothly when its height changes.

A send spacer lifts the user's new message to the top even before the transcript fills the screen. Reply growth and reader scrolling consume that space without restoring it. Streaming does not scroll the viewport; returning to the latest content is an explicit action. Page-level typing and editing shortcuts open the composer outside active voice calls, editable controls, and modal dialogs.

Quiet Zen sound cues accompany meaningful interactions. Agent typing selects some visible updates with small variations in timing, gain, and playback rate. The preference is persistent and can be muted; no audio or conversation history is saved by the application.

Dictating a text message

The microphone control records locally and reuses the fixed waveform for input feedback. Stop transcribes with the selected provider and appends the result to the existing draft; Check submits the same merged text through the text conversation. Cancel discards the recording and preserves the draft. Calls and dictation are mutually exclusive, and the call control disappears once text messages exist.

Only Stop or Check uploads audio. Recordings are bounded to five minutes and 25,000,000 bytes, and resources close on completion, cancellation and failure. Transcription independently selects OpenAI GPT Transcribe or ElevenLabs Scribe v2 through server-only configuration and credentials. OpenAI remains the default; ElevenLabs detects language automatically with audio-event tagging and speaker diarization disabled. There is no automatic fallback, and Codex sign-in is separate. Errors leave the draft intact and remain available for dismissal or retry.

Keeping signaling separate from audio

The browser requests microphone permission and creates a WebRTC connection. A standalone Node.js/Hono backend endpoint, shared by web development and preview, exchanges the connection offer with OpenAI using the official TypeScript SDK. The browser receives the session identifier and SDP answer. Credentials and model configuration remain on the server.

Audio travels over the negotiated WebRTC connection rather than through the application server. GPT-Live-1 manages the spoken conversation, with GPT-6 Luna configured as its Responses backend using no reasoning effort. Tool calls are disabled, and the other model settings use the API defaults.

Treating playback as its own responsibility

Receiving audio packets does not establish that a browser is playing them. The playback investigation used a local WebRTC connection and synthetic audio to check that distinction without spending API credits.

A native audio element consumes the model's remote stream. A separate Web Audio analyser measures that stream for the orb, while another analyser observes the microphone for the waveform. Microphone audio is never routed to the speakers. The waveform follows speech quickly and returns gradually to its idle state.

Session lifecycle code owns these resources outside the React components. It handles connection setup, cancellation, playback failures, and disconnection. Ending a call silences both sides and waits for the server's close acknowledgment before releasing the connection, with a timeout for incomplete finalization. Unexpected player errors or interruptions also release the microphone rather than leaving a silent call connected.

A local prototype with explicit limits

Dot has no application user database, saved conversations, or recordings. Local text development uses the user's Codex-managed ChatGPT account. Interface sound preferences are stored locally; transcripts remain in browser memory. It does not request OpenAI session storage. The signaling and transcription endpoints accept matching localhost origins; publishing a service for other users would require authentication and request controls around the paid API.

Focused unit tests cover the session contract, input/output separation, cancellation, playback failure, cleanup, waveform behavior, deferred dictation uploads, recording limits, transcript insertion and sending, authentication, paced text, spacer consumption, keyboard editing, and sound selection. Local Chrome verification confirmed playback with synthetic audio. A complete conversation against OpenAI and real microphone dictation remain separate live validation steps. Scribe v2 account access and transcription quality have not been verified with live requests. Uploaded recordings follow the selected provider’s data policy, retention settings and billing even though Dot keeps no local recording history.