WayCup Master Architecture

This note codifies the deep structure of the WayCup Engine, serving as the single source of truth for our dual-architecture system and environment philosophy.

🏗️ The Dual-Architecture Definition

WayCup operates on two distinct structural layers to separate physical disk operations from conceptual business knowledge.

1. Disk-Level Scaffolding (The File System)

The physical structure of projects and environments:

1. 00_core: The Engine Room. Global vault, automated agents, skills, and configuration.
2. 01_internal: Business Operations. Internal projects, strategy, and administration.
3. 02_labs: Innovation Hub. Rapid prototyping and R&D for AI workflows.
4. 03_clients: Delivery. Production instances for client environments.
5. 04_archive: History. Immutable logs and historical synthesis.

2. Vault-Level Business Pillars (The RAG Memory)

The logical organization of knowledge within 00_core/vault:

1. 01_Attract: Lead generation, marketing, top-of-funnel strategy.
2. 02_Convert: Sales strategy, proposals, triage calls, objection handling.
3. 03_Serve: Client onboarding, delivery guides, frameworks (FTF), quarterly reviews.
4. 04_Intelligence: Profiles, domains, and specific knowledge bases (e.g., Dog Wizard).

🧠 The Antigravity Tiered Memory Model

Our memory architecture balances high-velocity “vibe coding” with high-signal organizational structure.

• Tier 1 (Consolidated Daily Notes Capture): All daily activity records, engineering logs, and session notes are captured directly in the high-velocity layer:
  • Location: 00_core/vault/Daily Notes/
  • Nomenclature: Strictly named YYYY-MM-DD.md (e.g., 2026-06-27.md).
  • Integrity Rule: Each note is a comprehensive, un-pruned journal of that day’s work.
• Tier 2 (Curated Promotion): The Sweep/Curator Agent periodically scans Tier 1 Daily Notes and promotes distilled insights into the Vault-Level Business Pillars (01_Attract, 02_Convert, 03_Serve, 04_Intelligence).
• Antigravity Rule: Do not delete history from Tier 1. Keep the full representational integrity of each day’s logs intact, allowing downstream agents to extract and compound context dynamically over time.

💻 Environment: The “Separation of Powers” & Thin-Client Philosophy

The Gemini Environment is built on the Separation of Concerns and Separation of Powers between Interface and Computation.

🛡️ Separation of Powers

1. Nix & Infrastructure (~/dotfiles): Nix is strictly restricted to managing immutable packages and infrastructure hooks. It is completely barred from managing mutable file states, tokens, or live configurations. All configuration changes must be applied to the .nix source files in ~/dotfiles/.
2. SSHFS Mount Topology: When operating on the Laptop (TERMINAL), the following zones are active network mounts connected to the Engine:
   • ~/projects/ (All code and vaults)
   • ~/.gemini/ (AI context and shared memory)
   • ~/.config/Antigravity/User/ (Shared IDE UI settings)
   • ~/.config/gcloud/configurations/ (Shared Google Cloud project profiles)
3. SQLite Network-Mount Isolation: To prevent database corruption across the network due to SQLite file-locking issues over SSHFS, the architecture is strictly bifurcated:
   • Mounted (Shared): ~/.config/gcloud/configurations/ contains text files defining projects/regions. Changes here sync instantly across devices.
   • Local (Isolated): active_config and credentials.db (SQLite authentication database) live strictly on the local disk. Never attempt to sync, mount, or use Nix to manage gcloud authentication states. All global GCLOUD_PROJECT overrides have been stripped from shell exports.

🔌 Devices & Sync

• The Remote Control (The Book): Laptop/ChromeOS. Treated as “Glass and Keyboard” via Termius. Pristine, lightweight, easily replaceable.
• The Engine (The Box): Debian 12 machine. The single source of truth for files, AI memory (Vault), and heavy computation. Fully reproducible via Nix & Home Manager.
• Headless Core: Decoupled from GUI dependencies via a 1Password Service Account for 24/7 autonomous access to secrets and SSH keys.
• Asymmetric Sync Protocol (sync-all):
  • On the Engine (The Box): Stashes, commits, and pushes dotfiles to GitHub.
  • On the Terminal (The Book): Acts strictly as a read-only pull client to prevent merge conflicts.

🛠️ Core Governance & Technical Mandates

• Parent/Child Model: WayCup retains reusable “Engines” (IP); clients receive “Instances.”
• TCI-First: Everything must be optimized for Thin Client (Box/Book) parity and remote sync.
• Unified IDE Access: All IDE variants (Classic, Modern) must support TCI callbacks via the tci_ide_launch dispatcher. Typo-resistant aliases (ide-classic, ide-classes) are mandatory for frictionless GTM Engineering. Standard paths:
  • Modern: ~/.local/share/antigravity/modern/antigravity-ide (Agent-Optimized 2.0.x)
  • Classic: ~/.local/share/antigravity/classic/antigravity-ide (Traditional IDE v2.0.1)
• UX Execution (Antigravity): The antigravity UI runs natively in the foreground, clearing its own stale Singleton locks before launch and forcing the terminal tab title to 🌌 Antigravity IDE.
• Google-Native: Priority given to official GCP services and Gemini CLI extensions.
• Thin-Context: Use .geminiignore and modular imports to keep context small and tokens cheap.
• Declarative Context Management: Global AI ignore lists (.cursorignore, .claudeignore, etc.) MUST be managed via Nix in ~/dotfiles/configs/ai-ignores/ to ensure parity across all agents.
• Safety: Zero-tolerance for hardcoded secrets; enforce 1Password CLI (op read) for ephemeral secrets dynamic fetching in-memory. Never write plaintext secrets or API tokens to disk.
• Nomenclature: Industry-standard, unbranded nomenclature for scaffolding and file systems. Clean, descriptive names over “cute” labels. Concise titles, lowercase YAML tags.
• Proactive Sync: Gemini MUST proactively commit and push changes to the relevant Git repositories after any architectural, configuration, or environment changes.