Showcase | greatVibe

What You Get

Concrete outcomes, not features. Here's what changes when you use greatVibe.

Context That Persists

Your architecture decisions, file-level gotchas, and design intent survive across every session. The AI reads 1,359 documentation files before touching your code, so it never forgets why things are the way they are.

Rich Interactive Output

Every AI turn produces a visual card with syntax-highlighted code, diagrams, filterable tables, and choice buttons — not plain text dumps. Cards are the deliverable, not an afterthought.

Review From Any Device

A mobile-first PWA lets you review AI work, approve decisions, and direct next steps from your phone. No need to be at your desk when the AI needs a 10-second decision.

Multi-Machine Unified View

Your server, desktop, and laptop join a mesh network. See all AI coding sessions across all machines from one dashboard. Credentials distribute automatically via encrypted gossip.

Decision Tracking & Memory

Every architectural decision is recorded with rationale, alternatives, and confidence level. A searchable knowledge graph connects work across sessions and weeks. Answer "why did we do it this way?" instantly.

AI Compliance Monitoring

Drift detection tracks whether your AI actually follows its instructions. Metrics show compliance rates across 10 dimensions per session, so you know when quality is slipping — before the damage is done.

See It Live

Real screenshots from the running platform. This isn't a mockup — it's what you actually see when you use greatVibe.

Console — The CLI Output You Already Know

Same tool calls, file edits, and working output you see in VS Code or an SSH terminal — streamed live in the browser with the flow timeline alongside.

Console with flow timeline panel showing work history alongside CLI output

Live output with flow timeline panel

Console showing file edits, ACE updates, and git commits in real-time

File edits, ACE updates, and commits streaming live

Live streaming Tool calls File edits Flow timeline

Rich Turn Cards — Interactive HTML Output

Every AI turn produces a card with HTML output, syntax-highlighted code, choice buttons, and inline scripts. The card is the deliverable — not a plain text dump.

Turn card showing rich HTML output with code blocks, file changes, and action buttons

Rich HTML with code blocks and file changes

Turn card showing improvement summary with status badges, feature list, and action buttons

Improvement summary with buttons and status badges

HTML output Syntax highlighting Choice buttons Inline scripts

Turn List — Full Work History

Every AI interaction is captured, searchable, and filterable. See all pending, approved, and completed turns across sessions.

Turn list showing filterable work items with status badges

Searchable history Status tracking Scope filtering

Flow Timeline — Work Across Sessions

Flows track work from conception to completion, spanning multiple sessions and turns. The timeline shows events and decisions chronologically.

Flow timeline showing chronological work events

Flow timeline detail with turn summaries

Cross-session tracking System events Decision records

Session Management — Live AI Coding Sessions

See all active AI coding sessions, their status, turn count, and which user owns them. Jump to any session's console with one click.

Session list showing active AI coding sessions with status indicators

Mesh Network Topology — Multi-Machine Orchestration

All your machines in one view. The mesh topology shows nodes, peer connections (mTLS), latency, and the bootstrap server. Manage sessions across machines from anywhere.

Mesh network topology showing connected nodes with mTLS peers

mTLS encryption Gossip discovery Multi-hop routing

Built by What It Built

This isn't a demo or a mockup. Every service running behind this page — the TypeScript backend, the mesh networking, the WebSocket infrastructure, the MCP tools, the drift engine, the ACE specs, the context compiler — was built in AI coding sessions. No human typed the code. The screenshots above are from a live system. The drift metrics are real compliance data from real sessions. The mesh topology shows actual machines talking to each other over mTLS. Humans directed the architecture, made the design calls, and enforced the process. AI wrote every line. That's the point — greatVibe is a working product that proves its own thesis: with the right orchestration layer, AI coding sessions produce production software, not just prototypes.

100%

Vibe Coded

0

Human-Written Lines

1,359

ACE Files (AI-Authored)

5

Services (AI-Built)

The Problem

AI coding tools are powerful inside a single session. But real software development is complex — it spans days, machines, and teams. That's where today's tools fall apart.

✕ Context Amnesia

Each session starts cold. Your AI forgot the architecture, the gotchas, the decisions made yesterday. You re-explain the same things session after session.

✕ Black-Box Execution

AI is writing code somewhere on your machine. You can't see it from your phone. You can't approve a decision from the train. You're either watching a terminal or hoping nothing broke.

✕ Decision Bottlenecks

AI needs your input — "which database?", "refactor or patch?" — and blocks. If you're away from your desk, the session just waits. Hours wasted on a 10-second decision.

✕ Multi-Machine Chaos

Your server runs one session, your laptop another, your desktop a third. Three silos. No unified view. Credentials copied manually. Work duplicated across machines.

✕ Design Erosion

AI doesn't know why your code is structured this way. It "improves" code by reverting intentional decisions. Death by a thousand AI-generated "improvements."

✕ No Institutional Memory

Your AI sessions produce insights, patterns, and solutions — then they vanish. No searchable history. No decision trail. No way to answer "why did we do it this way?"

✓ Who it's for

Solo builders with complex, multi-day projects

Tech leads managing AI-assisted codebases

Teams with 100K+ line codebases where context matters

Anyone running AI coding sessions on multiple machines

Developers who want async AI workflows (review on phone)

✕ Who it's not for

"I just want autocomplete in my editor"

Simple scripts that don't need orchestration

"I don't want any workflow overhead"

One-off prompts with no project continuity

The Shift

Software has a new author. AI writes the code now — tirelessly, precisely, at a pace no human team can match. But raw output without direction is noise. The breakthrough isn't replacing developers; it's redefining what developers do. Your expertise — architecture instincts, design taste, domain knowledge — becomes the intelligence that shapes every line AI produces.

greatVibe is the platform where this actually works. Not by watching AI from the sidelines, but by giving human judgement persistent reach into the machine — your decisions encoded as living context, your design intent enforced across sessions, your approval flowing to agents on any device. Humans supply the intelligence. AI supplies the tireless muscle. greatVibe is the nervous system that connects them.

How It Works

From sign-up to production — you design, AI builds with full context, you steer.

1

Set Up Your Mesh

Sign up, deploy gvAgents to your environments, import Anthropic or OpenAI credentials to the nodes you choose. Wire connectors to existing on-prem or cloud infrastructure.

2

Design First

Create architecture and implementation documents. These become the living context — ACE files, compiled system prompts, product rules — that guides every AI decision. 1,359 files and counting.

3

AI Builds It

Tell the AI what to build from the console or mobile PWA. It reads your designs first, writes code, runs tests, and commits — all with full architecture context.

4

Audit & Iterate

Rich visual cards summarise every change: diffs, test results, next steps. Audit the build against your designs, catch drift, fix bugs — review and steer from any device.

5

Test & Ship

Automate testing across environments. Push to production when you're confident. Work is tracked as flows across sessions with a searchable knowledge graph.

Async

Review when you want, not when AI finishes

Persistent

Context spans sessions, branches, and weeks

Auditable

Every decision tracked with rationale

How does this compare to VS Code + Copilot?

▼

VS Code + Copilot

●Sessions are ephemeral — no memory between restarts

●No structured output — just inline code suggestions

●Desktop-only — no mobile review or approval

●Single-machine — no cross-device sessions

●No decision tracking — AI choices are invisible

●Code-level only — no project-level orchestration

●No async workflow — you must be present

●Generic context — doesn't know your architecture

greatVibe

✓Persistent flows — work spans sessions, branches, and weeks

✓Rich turn cards — interactive HTML with data capture

✓Mobile-first PWA — review and approve from your phone

✓Mesh network — all machines in one dashboard

✓Decision records — every choice tracked with rationale

✓Flow orchestration — emergent work tracking + knowledge graph

✓Async by default — chains iterate while you sleep

✓ACE context system — 1,359 files of architecture the AI reads first

The Superpowers

Capabilities that don't exist anywhere else. Not incremental improvements — fundamentally new.

✍️

Rich HTML Turn Cards

Interactive AI output that goes far beyond plain text

Every AI turn produces a rich HTML card with interactive components. Cards contain syntax-highlighted code, SVG diagrams, filterable tables, tabbed content, data capture forms, and live inline JavaScript.

Turn card showing mesh node status with tabbed interface

Mesh Network Status Card

Tabbed interface with live node data

Crash Recovery Diagnostics

Rich error display with recovery plan

Choice Buttons

Click to approve, reject, or redirect — no typing

Data Capture

Checkboxes, text inputs, dropdowns — DOM state captured

Inline Scripts

Filtering, tabs, charts — JS runs inside the card

SVG Diagrams

Architecture diagrams rendered inline

📚

Compiled System Prompts

Versioned, checksummed, auto-regenerated context injection

greatVibe doesn't just prompt the AI — it compiles a complete system prompt from a layered asset pipeline. The CLAUDE.md file Claude reads is auto-generated from checksummed assets across 4 layers: kernel contracts, SDK docs, product context, and session-specific flow state.

SHA-256 Checksums

Every asset versioned. Tamper detection catches manual edits and auto-regenerates.

Turn Context Injection

Every turn auto-injects session state, active flows, recent work, and drift metrics.

🌐

Distributed Mesh Network

Your machines, unified into one AI development cluster

Every machine runs a mesh node. Nodes discover each other via gossip protocol, authenticate with mutual TLS, and form a peer-to-peer mesh. From any node (or the web dashboard), you can see and control sessions on every machine.

Mesh Network Dashboard showing topology and node status

Mesh Dashboard

Live topology with mTLS peers and gossip discovery

SVG mesh topology diagram generated by AI

AI-Generated Topology Diagram

SVG diagram in a turn card showing bridge relationships

mTLS Security

Self-signed CA with auto certificate rotation

Gossip Protocol

Nodes discover peers automatically. LAN + WAN.

Bridge Relay

WebSocket relay for NAT traversal

Session Affinity

Know which session runs on which node

📊

Drift Detection & Compliance

Automated monitoring that the AI follows your contracts

greatVibe doesn't just tell the AI what to do — it measures whether it's actually doing it. Drift metrics track compliance with output contracts, choices, testing, and more across 10 dimensions per session.

Output Contract

Every turn must produce a turn card. Compliance measured.

Choices Contract

Every card must have actionable choice buttons.

ACE Compliance

Did the AI read design docs before code? Tracked.

ACE — Agent-Centric Engineering

Design first, code second. Every code file has an adjacent .ace file so Claude always sees intent before implementation.

The .ace file is more important than the code file. Code can be regenerated from good design. Design cannot be recovered from code.

0

ACE Files

0

% File Coverage

0

Max Tokens

0

Languages

Three Problems That Kill AI-Assisted Development

🚫 1. Context Loss

AI agents operate with limited context windows. Without documentation, the agent reads code, guesses the design intent, and may violate unstated constraints. Each session starts from scratch.

WITHOUT ACE

"Don't make the WebSocket upgrade async" — learned by breaking it, again

WITH ACE

Agent reads gotcha, understands constraint, writes correct code the first time

🔄 2. Design Drift

Codebases evolve, but the why behind decisions lives only in tribal knowledge. Without ACE, an AI agent will "improve" code by reverting intentional decisions.

"Routes go in /routes/, not in router.ts" — convention invisible to AI
"This was split from X because of Y" — context lost to git history
"Cookie name is hardcoded" — changing it breaks existing sessions

💸 3. Wasted Tokens

Every mistake an agent makes costs tokens to fix. Reading code to understand what should have been documented: waste. Debugging issues that a gotcha would have prevented: waste.

Reading to understand

WASTE

Debugging gotchas

WASTE

Re-asking user for context

WASTE

Reading ACE docs

INVEST

Tokens spent on docs < tokens wasted on mistakes. Always.

The Six Principles of ACE

1

ACE-First (Mandatory)

Every file has a design document. For new code, write the .ace first, then implement. For existing code, always read the .ace before reading the code. Not optional.

2

Locality of Documentation

Documentation lives next to the code it describes. Not buried in a /docs folder. Not scattered across wikis. Right there. auth.ts beside auth.ts.ace.

3

Change History with "Why"

The ACE file tracks significant changes — not what changed (git does that), but why. This prevents an agent from "improving" code by reverting intentional decisions.

4

Token Efficiency

ACE files are optimised for agent consumption. Max 5000 tokens. Structured sections, no prose padding. If you can't document it in 5000 tokens, the file is too complex — split it.

5

Procedural Knowledge

ACE captures not just what code does, but how to perform multi-step operations. Workflows section documents procedures that would otherwise live in tribal memory.

6

Agent Authorship

Claude writes and maintains .ace files. Humans prompt and review. The agent creates structured docs with purpose, functions, dependencies, and gotchas. Both iterate.

What is an Acedev?

An Acedev is a developer who works agent-centrically: ensures design documentation exists before coding, updates documentation alongside code, and commits both together — neither alone. The design document is the source of truth. The code is just an implementation of that truth.

Two Types of ACE Files

File ACE

Documents a single source file — auth.ts.ace

●YAML frontmatter (file, consumers, produces)

●Purpose — what this file does

●Key Functions — exports with signatures

●Dependencies — what it imports

●Gotchas — tribal knowledge, traps to avoid

●API Contracts — TypeScript interfaces

●Change History — why things changed

Folder ACE

Documents a module/directory — folder.ace

●Purpose — module's role in the architecture

●Design Intent — patterns, what belongs here

●Key Components — files and their roles

●Dependency Graph — ASCII architecture diagrams

●Gotchas — module-level warnings

●Workflows — multi-step procedures

●Change History — architectural decisions

Directory Layout

konui/src/
├── folder.ace ← module architecture
├── auth.ts
├── auth.ts.ace ← design doc for auth.ts
├── router.ts
├── router.ts.ace ← design doc for router.ts
└── routes/
├── folder.ace ← routes module design
├── kontask-api.ts
└── kontask-api.ts.ace

Twenty Languages, One Format

TypeScript

.ts.ace

Python

.py.ace

Go

.go.ace

Rust

.rs.ace

C

.c.ace

C++

.cpp.ace

Java

.java.ace

C#

.cs.ace

Kotlin

.kt.ace

Swift

.swift.ace

Ruby

.rb.ace

PHP

.php.ace

Scala

.scala.ace

Dart

.dart.ace

Shell

.sh.ace

SQL

.sql.ace

Lua

.lua.ace

HTML/CSS

.html.ace

JSON/JSONL

.json.ace

YAML

.yml.ace

The ACE-First Workflow

Creating New Code

1Write .ace first

→

2Implement code

→

3Verify match

→

4Commit both

Modifying Existing Code

1Read ACE

→

2Read code

→

3Update ACE

→

4Update code

→

5Commit both

Mandatory Rules (Kernel-Level)

@ace-first Always read ACE before code. Create if missing.

@ace-hierarchy Read order: folder.ace → file.ace → code

@ace-mandatory Never create code without companion ACE

@ace-design-led Update ACE before code, not after

When to Update ACE

✓ New/removed exports

✓ New dependencies

✓ Discovered gotcha

✓ Breaking change

✓ Bug fix with insight

✗ Internal refactor (lastModified only)

✗ Typo/formatting fix

✗ Adding comments

Five-Layer Enforcement Stack

ACE isn't just a guideline — it's enforced through instruction, detection, and hard gates.

1

Kernel Rules (CLAUDE.md)

@ace-first rule compiled into every agent's context via gvContext asset pipeline. Cannot be disabled.

2

Turn-Context Reinforcement

ACE reminders injected into every turn's context. Per-turn enforcement at the attention level.

3

Post-Turn Validation

After each turn, analysed: which code files were edited? Were corresponding ACE files read first?

4

Git Pre-Commit Hooks

Block commits that modify code without updating the corresponding ACE file. The only hard gate.

5

Drift Detection & Analytics

Track ACE compliance metrics per session. Alert when read rate drops below 90% or stale ACE exceeds 10%.

Compliance Targets

ACE read rate

> 95%

ACE update rate

> 80%

New file ACE rate

100%

Stale ACE files

< 5%

File Coverage by Module

Every code file has a companion .ace file. Every directory gets a folder.ace for module-level architecture.

Module	File ACEs	Code Files	Coverage
gvShell	366	325	100%
Konui	205	169	100%
gvMesh	103	103	100%
shared	13	10	100%
gvMCP	12	12	100%
Total	699	619	100%

+ 159 folder.ace files — module-level architecture docs (one per directory)

90

gvShell

13

Konui

53

gvMesh

2

shared

1

gvMCP

Quality Audit (9-File Sample)

100%

consumers field

100%

produces field

100%

Dependencies section

100%

Gotchas section

Real ACE Files from This Codebase

TypeScript | auth.ts.ace konui/src/

file: auth.ts consumers: [router.ts, routes/kontask-api.ts, dashboard-console.ts] produces: [AuthResult objects, HTTP 401 responses]

# Purpose

Bearer token authentication for Konui. Dual-storage token system: localStorage (for JS API calls) and cookies (for browser navigation).

# Key Functions

checkAuth(request, config): Promise<AuthResult>

Authorization: Bearer header (API calls with fetch)
?token= query parameter (SSE connections)
konui_token cookie (browser page navigation)

# Gotchas

Token check order is intentional and load-bearing. Header → query → cookie. SSE connections can’t set headers, so they use query params. Don’t reorder.

Cookie name konui_token is hardcoded. Changing it will break existing authenticated sessions.

# Change History

2026-01-10 — Added query param fallback for SSE

Why: EventSource API cannot set Authorization headers.

Go | provider.go.ace gvshell/internal/providers/

file: provider.go language: go package: providers consumers: [internal/repl/engine.go, internal/hub/client.go] produces: [Provider interface, Response and StreamEvent types]

# Purpose

Core Provider interface for gvShell. All AI providers (Claude, OpenAI, Gemini, Ollama) implement this contract.

# Gotchas

Stream() returns a channel, not a slice. Consumers must drain the channel or cause goroutine leaks.

CLI vs API providers have very different capabilities. CLI providers can use tools. API providers only do function calling. Don’t assume all providers are equal.

Folder | routes/folder.ace module-level architecture

folder: routes type: module consumers: [../router.ts] produces: [Route handler functions, JSON API responses]

# Design Intent

Routes are thin. They parse requests, call services, format responses. No business logic, no direct DB access.

# Dependency Graph

┌───────────────┐ │ router.ts │ └──────┬────────┘ │ ▼ ┌────────────────────────────┐ │ kontask-api gv-api console-api │ └────────────┬───────────────┘ │ ▼ ┌────────────┐ │ /services/ │ └────────────┘

# Gotchas

No direct database access. Import from stores, not from database modules. Stores handle caching.

Read the Full ACEspec →

Complete specification, principles, and implementation guide

Where We Are

An honest snapshot of maturity. greatVibe is actively used in production for its own development — here's what's built and what's in progress.

gvHub + Console

Production

gvmesh (Go)

Building (Phase 21+)

gvmcp (Go)

143 tools built

gvshell (Go)

Foundation done

ACE Coverage

1,359 files (100%)

Mesh Network

Multi-node live

Built with Deno (gvHub) + Go (gvShell/gvmesh/gvmcp) | 1,359 ACE files | SQLite + SQLCipher storage

Architecture Deep Dive

For technical evaluators: the full platform architecture, component specs, and internal systems. Click any section to expand.

Three-Tier Platform

Cloud (future) + Self-Hosted Hub + CLI

▼

greatvibe.ai

Cloud Platform (Future)

Multi-tenant AWS-hosted platform for teams. The hosted version of the full stack. Zero infrastructure burden.

greatvibe.local

Self-Hosted Hub

Single-tenant hub you run on your own infrastructure. Dashboard, turn system, mesh orchestration, and full AI collaboration layer.

gvShell

Cross-Platform Go CLI

Developer CLI/TUI for terminal-native AI interaction. REPL with multi-provider support, session storage, and hub connectivity.

Architecture Diagram

Three core binaries + mesh peers

▼

Component Details

gvShell, gvmesh, gvmcp, gvHub, Key Concepts

▼

gvShell — Interactive AI Shell

Go binary | CLI + TUI | Unix philosophy applied to AI

gvShell is the primary client-side interface. An interactive AI shell where providers are as accessible as system utilities. Responses become files, prompts become commands, and multiple AI providers compose like Unix pipes.

10 AI Providers

Claude, OpenAI, Gemini, Ollama, and more

Response References

$1, $2, $claude, $gpt — treat responses as files

Multi-Shell Mesh

Execute across gvShell instances on multiple machines

Credential Store

SQLCipher encrypted secrets, key rotation

VFS Namespace

Virtual filesystem: project files, config, responses

Agent Core

Provider plugins, session store, guardrails engine

gvmesh — The Brain (Data Layer)

Go daemon | Port 8443 | Unified HTTPS

gvmesh is the central orchestrator that owns ALL persistent state, storage, and mesh networking.

Session Management

Lifecycle, spawn, terminate, affinity

Turn Storage

Approval workflow, state machine

Mesh Networking

Gossip protocol, peer discovery, mTLS

Credential Store

SQLCipher encrypted, key rotation

VFS Providers

Virtual filesystem namespace

Config Management

Hot reload, central config

gvmcp — AI Interface Layer

Go binary | MCP Protocol | 143+ tools

gvmcp is a thin translation layer that exposes all gvmesh functionality as MCP tools for Claude Code. It owns no state.

143 MCP Tools

Turns, sessions, flows, mesh, agents, credentials

JSON-RPC 2.0

stdio (Claude Code) or HTTP transport

Resource Providers

File access, config, prompt templates

Schema Validation

JSON Schema for all tool inputs/outputs

gvHub — Web Dashboard & Portal

Deno/TypeScript | Port 8666 | WebSocket streaming

gvHub is the central web dashboard powering the Claude console, turn management, flow tracking, and system monitoring.

Claude Console

Full-screen WebSocket chat (PWA, mobile-first)

Turn System

Rich turn cards with choices, interactive HTML

Flow Tracking

Emergent work tracking, graph edges, decisions

gvContext Compiler

Auto-generates CLAUDE.md from layered assets

Drift Detection

Monitors AI compliance with contracts

Mesh Bridge

WebSocket relay to remote gvmesh nodes

Platform Concepts

gvTurn

Rich visual turn card — the primary unit of AI-human interaction. Contains HTML output, choice buttons, and interactive components.

Flow

Emergent work tracking unit spanning multiple turns/sessions. Auto-created from first prompt, merged when recognised as same work.

Decision

Architectural decision record. Tracks what was chosen, alternatives considered, rationale, and confidence level.

Graph

Knowledge graph connecting turns, flows, sessions, and decisions via typed edges.

Mesh

P2P network of nodes across machines. mTLS with gossip protocol for peer discovery.

gvContext

CLAUDE.md compilation system. Layered asset pipeline that generates context files from versioned assets.

ACE Files

Architecture Context Entries — companion docs for every code file. 1,359 ACE files provide module architecture and gotchas.

Drift Tracking & Compliance

10-metric compliance dashboard, instruction drift detection

▼

Drift Compliance (10 Metrics)

Real-time compliance rates per session.

gvTurn Level

Choices

100%

HTML Output

100%

Dark Theme

100%

Turn Level

ACE First

33%

Test Runs

44%

Commit First

39%

Tokenisation & Optimisation

~40% token reduction, 3-stage pipeline, per-asset tracking

▼

Every token in CLAUDE.md consumes context window space. greatVibe treats system prompt engineering as a performance discipline — optimising every asset for maximum instruction density.

~8K

Tokens in root CLAUDE.md

46

Assets compiled per target

3-Stage

Source → Optimized → Compiled

~40%

Average token reduction

Techniques

1. Tables Over Prose — Same rules, 60% fewer tokens

2. Critical Messaging with Macros — @ace-first, @output-contract repeated in turn-context

3. Remove Redundancy — Strip headers, reduce examples, eliminate repetition

Asset Registry & Distribution

46 managed assets, SHA-256 tamper detection, mesh convergence

▼

46 Managed Assets

10 Kernel (safety, contracts) + 34 greatVibe (SDK, UI, tools) + Product/Flow layers.

SHA-256 Tamper Detection

Every CLAUDE.md has a checksum header. Manual edits are detected and auto-regenerated.

Mesh Convergence

Push context to all mesh nodes. Convergence tracking shows sync status.

📄 This Page’s ACE File

Every code file in greatvibe has a companion .ace file — including this page. Below is the live ACE file that Claude reads before touching info-page.ts.

.ace konui/src/views/info-page.ts.ace

---
file: info-page.ts
consumers: [router.ts]
produces: [infoPage() - standalone HTML page]
created: 2026-02-17
lastModified: 2026-02-17
---
# Purpose
Public-facing platform showcase page. Rendered at /info without authentication. Standalone page — does not use layout() wrapper since no auth context needed.
# Key Functions

          infoPage() Returns complete HTML string for platform showcase
        
# Content Sections

          #hero Logo, title, one-liner, 3 outcome bullets, 2 CTAs
          #what-you-get 6 outcome cards (user-facing language)
          #screenshots 6-tab gallery with real UI images, lightbox zoom
          #dogfood Built by What It Built — 100% vibe coded
          #problem 6 pain point cards, core insight box
          #how-it-works 4-step workflow + VS Code comparison
          #superpowers 4 feature deep-dives
          #ace 7-tab ACE deep dive
          #where-we-are 6 benefit cards + 6 status badges
          #deep-dive Architecture accordion sections
        
# Interactive Components
Sticky nav + scroll spy, tab systems, accordions, counter animation, metric bar animation, drift bars, lightbox zoom
# Dependencies

          BRANDING branding.ts Logo, titles, URLs
          getResponsiveLogoHtml branding.ts Responsive logo rendering
          RESPONSIVE_LOGO_CSS branding.ts Logo CSS
        
# Gotchas
1. No auth — served before the auth gate in router.ts
2. Branding imports — uses BRANDING for logo/titles so changes propagate
3. Static content — all content hardcoded, not from DB
4. Tab isolation — multiple tab systems scoped via .closest('.section')
5. main.css overflow:hidden — MUST override with !important
6. Deep dive accordions — nested accordions work independently

This is a summary of konui/src/views/info-page.ts.ace — the companion file Claude reads before modifying this page. See more ACE examples →