Builders log.

We built greatVibe around one idea: every piece of AI work should be a card you can see, track, and act on. That is the GVTurn.

Across the first three weeks, 418 commits and 63,000 lines of code made GVTurns real. The system started simple. A card with a title and some output. Then it grew. Choices so you can steer AI work with a click. Status tracking so you know what is done, what is waiting, what needs attention.

By week three, GVTurns had flows, topics, and a curator that stitches the graph together. A single card is useful. A connected graph of cards changes how you work.

The greatVibe dashboard is where humans and AI meet. Deno, server-rendered HTML, live WebSocket updates. No framework. No build step. Fast, direct code.

240 commits shaped the console into something clear and responsive. Cards stream in as AI works. Each card renders rich HTML. Tables, code blocks, SVG diagrams, interactive widgets with inline scripts.

We shipped in phases. Each phase built on the last. No big rewrites. Steady, visible progress. The dark theme runs through everything. It looks good at 2am when you are debugging a mesh node.

AI that cannot be audited cannot be trusted. We built the audit layer from day one.

Every GVTurn has a drift score. Did it include HTML output? Did it have at least two choices? The system tracks compliance rates and raises alerts when they drop below thresholds.

The audit system is not punishment. It is feedback. When drift metrics show cards are missing choices, the interaction loop is broken. The system surfaces that. Then it gets fixed.

ACE stands for Architecture, Context, Execution. Every file in greatVibe has a companion .ace file that documents what it does, why it exists, and how it connects to everything else.

The workflow is strict. Read the folder ACE. Read the file ACE. Then write code. This is how we scale AI-assisted development. The AI does not need to rediscover intent from code structure. The intent is written down, next to the code.

ACE files are not for humans to read. They are for machines to consume. That distinction changes how you write them.

We wanted AI to work with real documents. Not summaries. Not screenshots. The actual cells and formulas.

Two Python drivers: one for Excel, one for Word. FastAPI services. The Excel driver uses openpyxl to read and write cells, xlcalculator to evaluate formulas. The ExcelGrid renderer in konui shows computed values with a formula bar above.

This is not a toy integration. Gravient runs a six-year financial model through it. Revenue projections, OpEx breakdowns, scenario analysis. All readable and editable by AI.

MCP tools return JSON. Nobody wants to read JSON. So we built renderers.

Each tool category gets its own renderer. The ExcelGrid renderer turns spreadsheet data into a scrollable grid with frozen headers and a formula bar. The credential renderer shows metadata with copy buttons. The health renderer shows a service card with a live status dot.

The pipeline is extensible. Each renderer registers for specific tool patterns. Widget IDs scope to the turn to prevent collisions across cards.

greatVibe nodes talk to each other. Not through a central server. Through a mesh.

Each node generates its own TLS certificates. Peers discover each other through gossip protocol, exchanging state every five seconds. When direct connections fail, traffic falls back to the bridge relay over WebSocket.

The mesh carries file transfers, cross-mesh API calls, and VFS operations. 15 gossip message types cover credentials, context checksums, session affinity, MCP announcements. It is the nervous system of the platform.

Every AI session starts by reading CLAUDE.md. One file that tells the model what this project is. We built the engine that creates that file.

The context engine takes source assets and compiles them through a pipeline. context_compile merges everything into one deployable CLAUDE.md. Four scope levels let kernel rules stay separate from repo-specific context.

This is what makes greatVibe nodes self-aware. A new node joins the mesh, pulls context via checksum gossip, compiles its CLAUDE.md, and immediately knows the entire platform.

Most AI interfaces give you a text box and a send button. We wanted more.

The Power Footer is a five-zone panel below every GVTurn card. Quick react chips for fast feedback. Action cards you can click to send or hold to edit. Tone selectors. Metrics. Every card became a small command centre.

76 commits in one week built and refined this. Keyboard shortcuts. Hold-to-edit. Responsive layouts. Passive reading became active interaction.

We have a rule: every code-changing turn must verify tests exist and run. No exceptions.

konui runs 77 test files with Deno. gvmesh and gvmcp run Go tests. The testing-per-turn macro kicks in at turn 3 of every session.

This discipline caught real bugs. Mock/prod divergence. Migration failures. Race conditions in gossip delivery. None of them reached main.

What if AI could send you a message? Not a notification. A real message with context, attachments, and thread replies.

Agents create messages via MCP tools. Messages persist in SQLite, broadcast via gossip, deliver through bridge SSE. A build finishes at 3am and the agent sends a message with the results. You open your inbox the next morning and it is waiting. Full context, not a ping.

We gave AI eyes into AWS. Read-only eyes.

28 MCP tools cover STS, IAM, EC2, S3, Organizations, and Cost Explorer. aws_resource_summary runs EC2, S3, and cost queries in parallel. One call, full picture.

The read-only constraint is deliberate. AI should help you understand your infrastructure. It should not change it without you driving.

API keys, tokens, passwords. They all need to move between nodes without anyone in the middle seeing them.

We built credential delivery with ECDH P-256 key exchange. Source node encrypts with AES-GCM. No central authority sees the plaintext. Consumer derives the shared secret and decrypts locally. Credentials materialise into the HOME directory on each node.

Gossip carries the encrypted payload. The bridge relay cannot read it. Only the consumer can.

Sometimes you write a prompt that works so well you want to save it. The script engine is where those prompts live.

Scripts are stored, versioned, and shareable across the mesh. A deployment checklist, a code review template, a financial model update. Each becomes a script you run with one click.

Versions let you track what changed. Conflict detection catches divergence when scripts are edited on multiple nodes.

Every AI conversation in greatVibe is a session. Sessions have lifecycles. Card mode renders GVTurn cards for interactive work. Headless mode returns structured JSON for machine-to-machine communication.

Agent delegation lets one session spawn work on another node. This is how multi-node workflows run. One session orchestrates. Others execute.

Turn context escalates as sessions grow. By turn 3, testing macros kick in. By turn 10, HTML enforcement applies. The system gets stricter as the session deepens.

Mesh nodes do not always have direct routes to each other. Sometimes they are behind firewalls, on different networks, or on the other side of the world. The bridge relay solves this.

Every node connects to the bridge over WebSocket. When direct mTLS fails, traffic falls back to the relay. No configuration needed.

The relay runs four priority queues. Realtime traffic for session messages. High priority for credentials. Normal for context sync. Low for bulk file transfers. The 1,284 lines of bridge.go handle framing, authentication, heartbeat, and queue management. Every byte that crosses the WAN goes through this code.

AI is a black box. We opened it.

Every session writes an immutable JSONL event log. Each line is a RawTurnEvent with a type, sequence number, and timestamp. start kicks off the turn. prompt captures the human input. text records each token chunk. tool_call and tool_result log every MCP interaction. complete closes the turn.

Replay the log and you reconstruct the entire session. Not a summary. The exact sequence of events, in order.

This is how new sessions get briefed. Load the last few turns from rawturns. Reconstruct what happened. Give the next AI session a running start.

GVTurns are cards. Flows are the stories those cards tell.

When you start work, a flow is created automatically. Every turn links to that flow as an evidence edge. Tool calls become decision edges. When work ships, it becomes an output edge. Debug threads chain together via continues edges.

The graph builds itself. You never have to think about it. The curator runs in the background, linking orphaned turns, detecting debug threads, keeping the graph clean.

Zoom out from a single card and you see the full arc of work. A feature from first prompt to shipped output, every decision and course correction visible in the graph.

Not all models are the same. Not all tasks need the same model. Provider orchestration routes work to the right backend automatically.

The ProviderRegistry scores candidates in two passes. Required capabilities filter out backends that cannot do the job. Preferred capabilities rank what remains. The highest-scoring available backend wins.

Quota tracking runs two windows simultaneously. A rolling window catches rate spikes. A weekly ceiling stops runaway spending. When one account hits its limit, rotation kicks in. Quota rotation picks the best remaining account. Round-robin distributes load evenly. Least-used finds the idlest backend.

The result is an AI platform that keeps working even when individual accounts get throttled.

When you type a prompt in greatVibe, it does not go straight to Claude. It goes through the Commander first.

enrichSessionSend takes the raw human input and builds the full context package. It resolves gv.session_id to the Claude-side ags_xxx session identifier. It injects turn context, macros, and system instructions. It calls processSessionImages to extract any base64-encoded images from the prompt and write them to disk before the model call.

The Commander is the translation layer between the human-facing session and the model-facing API. 1,465 lines that handle the gap between what you type and what Claude receives. Get this wrong and every AI interaction in the platform breaks.

We do not trust networks. We trust certificates.

Every gvmesh node generates its own ECDSA P-256 key pair on first start. It submits a certificate signing request to the CA. The CA signs it with MaxPathLen:1 to prevent intermediate CA abuse. The node gets a cert valid for one year.

Every connection between nodes requires mutual TLS. Both sides present certificates. Both sides verify against the CA. No exceptions.

The CA lives at 10 years so it does not need rotation during the platform lifetime. Node certs rotate at one year. The IssueNodeCert, SignCSR, and VerifyCertificate functions in ca.go and certs.go are the foundation everything else builds on.

chitchat shipped as a small UI strip in March. Through late April it grew into a real conversation surface. Bots joined.

The first sidecar-bot (originally called haiku-bot) responded to @mentions on a single mesh. By the end of April it was running as a real Agent. Mention your hostname and you get a Claude CLI session spawned per turn, with the full gvmcp toolkit at hand. Reads files. Greps the codebase. Runs commands. Returns the answer in line.

We rewired bot etiquette through the F1 prompt sequence. Group-chat manners. Reply only when @-mentioned or with concrete useful info. Light markdown subset for bold, italics, code, lists, links. Silence filter to stop the bot from meta-narrating its own quietness. A panic-stop button for when a conversation runs hot.

The chitchat UI itself went through fifteen iterations in ten days. Swipe gestures, Inter font, markdown rendering, history replay on reconnect, ack and read-receipts, peer presence pills, a mobile portrait pass for iPhone, Z Fold and Pixel.

By April 30 the gv.sidecar card showed live sparklines, cost rollups and per-model breakdowns. The bot is standard now, not experimental.

Each greatVibe mesh ran in its own bubble through March. In late April that changed.

The wave-3.5 push split the old mesh-peer-link concept into two layers. konui-peer carries the transport: URL, tokens, connection state, health. mesh-permit carries the permission: scopes, allowed proxy calls, daily cost cap. Same name, different facets. Today they bind 1:1. Tomorrow we can issue many permits per transport without breaking anything.

Wave-3.5.4 wired the gvmesh Reverse API Proxy. A sidecar mesh can route REST calls through its sponsor konui via the bridge and hit any endpoint that policy allows. mesh_permit_call became the standard tool for cross-mesh API work. konui auto-discovers the bridge-relay URL at startup. The peernodes cache means standalone peer meshes show up in node_list instead of looking empty.

The 16th gossip type landed: user_presence. Each konui heartbeats per-user presence into its local gvmesh. The bridge fans presence updates across meshes via konui-peer. You see who is online on other meshes in real time.

konui_console_inject is the headline UX win. A sidecar bot can compose a gvturn and inject it onto a target user's dashboard. Target-user-filtered, multi-tab deduped, bridge-trusted. Cross-mesh chat is now a real assistant surface.