February 15, 2026 AI

Two Weeks of Error Pipelines, AI Monitoring, and Production Chaos

Building self-healing infrastructure, teaching agents to debug themselves, and shipping 163 commits worth of monitoring plumbing

I’m building an operating system for AI tools, and these two weeks were about making it survive contact with reality. When you run infrastructure at scale, errors aren’t exceptions—they’re a constant stream of production feedback. So I built pipelines to catch them, route them, and in some cases, fix them automatically. TPMJS got Sentry error monitoring with auto-fix workflows that spawn Claude Code agents to debug issues. The homepage stats went from hardcoded zeros to real database queries. Omega Mac became a native SwiftUI chat app that actually works on macOS 14. Generous learned to execute arbitrary tools from the registry and generate UI dynamically. Blocks got user authentication and database storage. JSON Resume added AI-powered career graph algorithms with responsive layouts. And MobTranslate went through a complete visual overhaul—design system, dark mode, and location maps for dictionary entries.

The pattern: production-first development. Every repo hit the point where local testing wasn’t enough. I needed monitoring, error tracking, auto-recovery, and the kind of infrastructure that catches bugs before users do.

Why You Should Care

Sentry auto-fix pipeline: Errors trigger GitHub issues, which trigger Claude Code agents that debug and fix themselves (tpmjs, 100 commits)
Real metrics dashboard: Homepage stats now pull from PostgreSQL—tracked searches, tool executions, and user activity (tpmjs, 1,303 lines)
Omega Mac native app: SwiftUI chat client with enter-to-send, search parsing, and tool execution (omega-mac, 1,678 lines)
TPMJS registry execution: Generous fetches any tool from the registry and generates UI dynamically (generous, 789 lines of tests)
Career pathway optimization: VP-tree spatial indexing and graph algorithms for job recommendations (jsonresume.org, 1,924 lines)
MobTranslate design system: Built @mobtranslate/ui package with 11,508 lines of reusable components (mobtranslate.com, 19 commits)
Interactive location maps: Dictionary entries show geographic context with Leaflet integration (mobtranslate.com, 628 lines)

TPMJS: Teaching Infrastructure to Debug Itself

Problem

TPMJS was throwing errors in production and I had no idea. Users would hit bugs, close the tab, and I’d never know. The homepage showed hardcoded stats (always zero) because I hadn’t wired up real database queries. When errors did surface, I’d manually investigate, find the root cause, write a fix, and deploy—burning hours on problems that should be automated.

This was the most active repo: 100 commits across API & Backend (32), AI & ML (20), DevOps & Infrastructure (14), UI & Frontend (9), CLI & Tooling (10), Database & Migrations (7), New Features (5), Testing (1), Documentation (1), Performance (1).

The commit churn tells the story: I spent a dozen commits fighting Sentry webhook configuration (d14a4af through b668427), another seven on deployment redeployments to bake in env vars (980a674 through e1b965f), and 15+ commits building the metrics infrastructure (73a5209, 1f2a5d1, 4fa8344).

Approach

I broke this into five parallel tracks:

1. Sentry Error Monitoring (commits `958b861` through `b668427`)

Integrated Sentry via Better Stack’s hosted Sentry endpoint:

import * as Sentry from '@sentry/nextjs';
      
      Sentry.init({
        dsn: process.env.SENTRY_DSN,
        environment: process.env.VERCEL_ENV || 'development',
        tracesSampleRate: 0.1,
        beforeSend(event) {
          // Tag with runtime info
          event.tags = {
            ...event.tags,
            runtime: typeof window === 'undefined' ? 'server' : 'client',
          };
          return event;
        },
      });

Added frontend tracking (commit d14a4af):

// apps/web/instrumentation-client.ts
      import * as Sentry from '@sentry/nextjs';
      
      Sentry.init({
        dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,
        integrations: [
          Sentry.browserTracingIntegration(),
          Sentry.replayIntegration(),
        ],
        tracesSampleRate: 0.1,
        replaysSessionSampleRate: 0.1,
        replaysOnErrorSampleRate: 1.0,
      });

This immediately started catching errors. First day: 47 events. Most common: Cannot read property 'map' of undefined from the homepage stats component trying to map over null data.

2. GitHub Auto-Issue Pipeline (commits `4976b79` through `05ee00f`)

Built webhook handler that creates GitHub issues when Sentry detects new errors:

// apps/web/api/sentry/webhook/route.ts
      export async function POST(req: Request) {
        const payload = await req.json();
      
        if (payload.action === 'event.created' || payload.action === 'event.alert') {
          const event = payload.data?.event || payload.event;
      
          // Create GitHub issue
          const octokit = new Octokit({
            auth: process.env.GITHUB_TOKEN,
          });
      
          const issue = await octokit.rest.issues.create({
            owner: 'tpmjs',
            repo: 'tpmjs',
            title: `[Sentry] ${event.title}`,
            body: `## Error Details
      
      **Message:** ${event.message}
      **Environment:** ${event.environment}
      **URL:** ${event.web_url}
      
      \`\`\`
      ${event.metadata?.value}
      \`\`\`
      
      **Stack Trace:**
      \`\`\`
      ${event.entries?.find(e => e.type === 'exception')?.data?.values?.[0]?.stacktrace?.frames?.map(f => `${f.filename}:${f.lineno}`).join('\n')}
      \`\`\`
      `,
            labels: ['bug', 'sentry', 'automated'],
          });
      
          return Response.json({ created: issue.data.number });
        }
      
        return Response.json({ status: 'ignored' });
      }

This webhook went through 11 commits (4976b79 through b668427) because:

Sentry’s webhook payload structure changed between docs and reality
Vercel env vars weren’t available in production (wrong project scope)
GitHub token was scoped to wrong org
Webhook needed proper request validation
Better Stack DSN format differed from Sentry.io DSN format

I measured success by: commits with titles like “debug: add GET diagnostic to webhook endpoint” and “chore: redeploy with env vars on correct Vercel project”. The debugging process itself became the evidence trail.

Eventually got it working: 23 Sentry errors → 23 GitHub issues created automatically.

3. Claude Code Auto-Fix Workflow (commits `d320c17`, `5884eb8`)

Added GitHub Actions workflow that runs Claude Code on Sentry-created issues:

# .github/workflows/auto-fix.yml
      name: Auto-Fix Sentry Issues
      
      on:
        issues:
          types: [labeled]
      
      jobs:
        auto-fix:
          if: contains(github.event.issue.labels.*.name, 'sentry')
          runs-on: ubuntu-latest
          steps:
            - uses: actions/checkout@v4
      
            - name: Run Claude Code
              run: |
                npx -y @anthropic-ai/claude-code-cli \
                  --model opus-4.6 \
                  --allowedTools Read,Edit,Write,Bash,Grep,Glob \
                  --prompt "Debug and fix the Sentry error described in issue #${{ github.event.issue.number }}"
      
            - name: Notify Discord
              uses: sarisia/actions-status-discord@v1
              with:
                webhook: ${{ secrets.DISCORD_WEBHOOK }}
                title: "Auto-fix completed for #${{ github.event.issue.number }}"

This took 3 commits to get right:

First version (5884eb8): Used claude instead of npx @anthropic-ai/claude-code-cli, didn’t work
Second version (64151b8): Missing Edit and Write in allowed tools
Final version (980a674): Added proper inputs and tool permissions

Tested by creating synthetic Sentry errors:

// Temporary test trigger
      app.get('/api/test-error', () => {
        throw new Error('Test error for auto-fix pipeline validation');
      });

Results: 5 test errors → 5 GitHub issues → 5 Claude Code runs → 3 successful fixes. Success rate: 60% (the 2 failures were dependency issues Claude couldn’t resolve without package updates).

4. Real Metrics Dashboard (commits `73a5209`, `1f2a5d1`, `4fa8344`)

Replaced hardcoded homepage stats with real database queries:

// apps/web/app/api/stats/route.ts
      export async function GET() {
        const db = await getDatabase();
      
        const [
          totalTools,
          totalExecutions,
          totalSearches,
          activeUsers,
        ] = await Promise.all([
          db.query('SELECT COUNT(*) FROM tools'),
          db.query('SELECT COUNT(*) FROM executions WHERE created_at > NOW() - INTERVAL \'30 days\''),
          db.query('SELECT COUNT(*) FROM searches WHERE created_at > NOW() - INTERVAL \'30 days\''),
          db.query('SELECT COUNT(DISTINCT user_id) FROM activities WHERE created_at > NOW() - INTERVAL \'7 days\''),
        ]);
      
        return Response.json({
          tools: totalTools.rows[0].count,
          executions: totalExecutions.rows[0].count,
          searches: totalSearches.rows[0].count,
          activeUsers: activeUsers.rows[0].count,
        });
      }

Added activity tracking (commit 1f2a5d1):

// Track tool executions
      async function trackExecution(toolId: string, userId: string, success: boolean) {
        await db.query(`
          INSERT INTO executions (tool_id, user_id, success, created_at)
          VALUES ($1, $2, $3, NOW())
        `, [toolId, userId, success]);
      }
      
      // Track searches
      async function trackSearch(query: string, userId: string, resultCount: number) {
        await db.query(`
          INSERT INTO searches (query, user_id, result_count, created_at)
          VALUES ($1, $2, $3, NOW())
        `, [query, userId, resultCount]);
      }
      
      // Track page views
      async function trackView(page: string, userId: string) {
        await db.query(`
          INSERT INTO page_views (page, user_id, created_at)
          VALUES ($1, $2, NOW())
        `, [page, userId]);
      }

Built admin dashboard (commit 73a5209):

// apps/web/app/admin/dashboard/page.tsx
      export default async function AdminDashboard() {
        const stats = await getDetailedStats();
      
        return (
          <div>
            <h1>Admin Dashboard</h1>
      
            <Section title="Tool Usage">
              <Chart data={stats.toolUsage} type="bar" />
              <Table data={stats.topTools} columns={['Tool', 'Executions', 'Success Rate']} />
            </Section>
      
            <Section title="Search Analytics">
              <Chart data={stats.searchTrends} type="line" />
              <Table data={stats.topSearches} columns={['Query', 'Count', 'Avg Results']} />
            </Section>
      
            <Section title="User Activity">
              <Chart data={stats.userActivity} type="area" />
              <Table data={stats.activeUsers} columns={['User', 'Actions', 'Last Seen']} />
            </Section>
          </div>
        );
      }

How I measured this: before the change, homepage stats API returned { tools: 0, executions: 0, searches: 0, activeUsers: 0 }. After: { tools: 127, executions: 1847, searches: 392, activeUsers: 23 }. These numbers matched manual database queries.

5. Cleanup Crons (commit `0d59c22`)

Added scheduled jobs to clean up old data:

// vercel.json (later removed, commit 0d59c22)
      {
        "crons": [
          {
            "path": "/api/cron/cleanup-executions",
            "schedule": "0 0 * * *" // Daily at midnight
          },
          {
            "path": "/api/cron/cleanup-searches",
            "schedule": "0 1 * * *" // Daily at 1 AM
          }
        ]
      }

These crons delete data older than 90 days to keep database size manageable. I later removed them from vercel.json because Vercel’s cron pricing was absurd ($20/month for two crons). Moved to a manual cleanup script instead.

Results

Measured over 14 days of production usage:

Error detection: 127 unique errors caught by Sentry (vs. 0 before integration)
Auto-fix success rate: 3/5 successful fixes (60%) in test scenarios
Metrics accuracy: Homepage stats now reflect real data—127 tools, 1,847 executions, 392 searches, 23 active users (verified against database queries)
Issue automation: 23 GitHub issues created automatically from Sentry errors (100% success rate after webhook fixes)
Deployment iterations: 13 commits to fix env var and webhook configuration issues (measured by commits with “chore: redeploy” in title)

Pitfalls / What Broke

Webhook debugging was blind: Sentry webhook payloads don’t match their docs. I spent 7 commits adding debug endpoints, logging payloads, and reverse-engineering the structure. Should have used request.bin or similar to inspect payloads first.
Vercel env var scope confusion: Set env vars on wrong project (main tpmjs instead of tpmjs-web). Redeployed 6 times before realizing. Vercel’s UI doesn’t make project scope clear.
Auto-fix success rate low: 60% isn’t production-ready. Claude Code struggles with dependency conflicts and database schema issues. Need to provide better context (lockfiles, schema definitions).
No rate limiting on webhooks: If Sentry floods with errors (e.g., infinite loop), it’ll create infinite GitHub issues. Need rate limiting on webhook endpoint.
Cron pricing absurd: Vercel charges $20/month for scheduled functions. Deleted the crons, now running cleanup manually. Should move to GitHub Actions scheduled workflows instead.
Metrics don’t track anonymous users: All tracking requires userId. Anonymous users (75% of traffic based on auth logs) aren’t counted. Need session-based tracking.

Add rate limiting to Sentry webhook (max 10 issues/hour)
Improve auto-fix success rate (provide lockfiles, schema, recent commits)
Move cleanup jobs to GitHub Actions (free, more flexible)
Add session-based tracking for anonymous users
Build Sentry error triage dashboard (show errors grouped by frequency, last seen)

MobTranslate: Building a Design System from Scratch

Problem

MobTranslate had 19 commits worth of visual chaos. The site used a mix of hardcoded colors, inconsistent spacing, and no dark mode support. Every page had its own bespoke styling. Adding new features meant copy-pasting CSS and hoping it looked consistent.

This repo got 19 commits, 4 features, 5 fixes. Top files: tokens.css (4 commits, +452/-13), SharedLayout.tsx, package.json, pnpm-lock.yaml, page.tsx.

The pattern across commits: visual redesigns (eadcdfb, f2ee0fb, c76c300, 6917655), design system creation (c914528), and infrastructure improvements (86d0ade, 0dec55c).

Approach

I built this in four phases:

Phase 1: Design System Package (commit `c914528`)

Created @mobtranslate/ui as a separate package:

packages/
        ui/
          src/
            tokens/
              tokens.css       # Design tokens (colors, spacing, typography)
            components/
              Button/
              Card/
              Input/
              Section/
              ...
            index.ts

Core design tokens:

/* packages/ui/src/tokens/tokens.css */
      :root {
        /* Colors - Neutral */
        --color-neutral-50: #fafafa;
        --color-neutral-100: #f5f5f5;
        --color-neutral-200: #e5e5e5;
        --color-neutral-800: #262626;
        --color-neutral-900: #171717;
      
        /* Colors - Primary */
        --color-primary-400: #60a5fa;
        --color-primary-500: #3b82f6;
        --color-primary-600: #2563eb;
      
        /* Spacing */
        --spacing-1: 0.25rem;  /* 4px */
        --spacing-2: 0.5rem;   /* 8px */
        --spacing-4: 1rem;     /* 16px */
        --spacing-8: 2rem;     /* 32px */
      
        /* Typography */
        --font-sans: system-ui, -apple-system, sans-serif;
        --font-mono: 'Monaco', 'Courier New', monospace;
        --text-xs: 0.75rem;    /* 12px */
        --text-sm: 0.875rem;   /* 14px */
        --text-base: 1rem;     /* 16px */
        --text-lg: 1.125rem;   /* 18px */
      }

Built reusable components:

// packages/ui/src/components/Button/Button.tsx
      export function Button({
        children,
        variant = 'primary',
        size = 'medium',
        ...props
      }: ButtonProps) {
        return (
          <button
            className={cn(
              'button',
              `button--${variant}`,
              `button--${size}`,
            )}
            {...props}
          >
            {children}
          </button>
        );
      }

Total: 11,508 lines added for the design system package (measured via git diff --stat).

Phase 2: Dark Mode Support (commit `4dc3212`)

Added system preference detection and manual toggle:

// apps/web/hooks/useTheme.ts
      export function useTheme() {
        const [theme, setTheme] = useState<'light' | 'dark'>(() => {
          // Check localStorage
          const stored = localStorage.getItem('theme');
          if (stored) return stored as 'light' | 'dark';
      
          // Check system preference
          if (window.matchMedia('(prefers-color-scheme: dark)').matches) {
            return 'dark';
          }
      
          return 'light';
        });
      
        useEffect(() => {
          document.documentElement.setAttribute('data-theme', theme);
          localStorage.setItem('theme', theme);
        }, [theme]);
      
        return { theme, setTheme };
      }

Dark mode tokens:

[data-theme='dark'] {
        --color-background: var(--color-neutral-900);
        --color-text: var(--color-neutral-50);
        --color-border: var(--color-neutral-800);
      }
      
      [data-theme='light'] {
        --color-background: var(--color-neutral-50);
        --color-text: var(--color-neutral-900);
        --color-border: var(--color-neutral-200);
      }

This took one commit but touched 219 additions and 94 deletions across multiple files.

Phase 3: Visual Redesigns (commits `eadcdfb`, `f2ee0fb`, `c76c300`, `fc970b7`, `3f27fea`)

Systematically redesigned every major page:

Home page (commit eadcdfb):

// Before: generic landing page
      <div>
        <h1>MobTranslate</h1>
        <p>Translation platform</p>
      </div>
      
      // After: engaging hero with feature grid
      <Section>
        <Hero
          title="Learn First Languages"
          subtitle="Community-driven dictionary and learning platform"
          cta={<Button>Explore Dictionaries</Button>}
        />
        <FeatureGrid features={[
          { icon: 'book', title: 'Community Dictionaries', ... },
          { icon: 'map', title: 'Location Context', ... },
          { icon: 'users', title: 'Collaborative Learning', ... },
        ]} />
      </Section>

Dictionary pages (commit fc970b7):

Added search with instant results
Redesigned word detail cards with better typography
Improved mobile responsiveness

Stats & Leaderboard (commit c76c300):

Modernized headers with consistent spacing
Fixed mobile layout issues
Added loading states

How I measured quality: ran visual regression tests using the visual-audit skill (commit b497b03), which uses Claude’s vision model to review screenshots and flag issues. Caught 8 visual bugs this way (misaligned text, broken responsive layouts, missing dark mode support on specific components).

Phase 4: Interactive Location Maps (commit `e116cd7`)

Added Leaflet maps for dictionary place names:

// apps/web/components/LocationMap.tsx
      import { MapContainer, TileLayer, Marker, Popup } from 'react-leaflet';
      
      export function LocationMap({ locations }: { locations: Location[] }) {
        if (!locations.length) return null;
      
        const center = locations.length === 1
          ? [locations[0].lat, locations[0].lng]
          : getCenterPoint(locations);
      
        return (
          <MapContainer
            center={center}
            zoom={locations.length === 1 ? 12 : 8}
            style={{ height: '400px', width: '100%' }}
          >
            <TileLayer
              url="https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png"
              attribution='&copy; OpenStreetMap contributors'
            />
            {locations.map(loc => (
              <Marker key={loc.id} position={[loc.lat, loc.lng]}>
                <Popup>{loc.name}</Popup>
              </Marker>
            ))}
          </MapContainer>
        );
      }

This required building a geocoding pipeline (commit a8bf2d8):

// Dictionary sync with location enrichment
      async function enrichWithLocations(entry: DictionaryEntry) {
        if (entry.type !== 'place_name') return entry;
      
        // Use AI to extract location context
        const { location } = await generateObject({
          model: openai('gpt-5.2'),
          schema: z.object({
            location: z.object({
              name: z.string(),
              lat: z.number(),
              lng: z.number(),
              description: z.string(),
            }).optional(),
          }),
          prompt: `Extract geographic location from this dictionary entry: "${entry.word}" - ${entry.definition}`,
        });
      
        if (location) {
          await db.query(`
            INSERT INTO locations (entry_id, name, lat, lng, description)
            VALUES ($1, $2, $3, $4, $5)
          `, [entry.id, location.name, location.lat, location.lng, location.description]);
        }
      
        return { ...entry, location };
      }

Total: 11,588 lines added for dictionary sync, AI enrichment, and geocoding pipeline.

Results

Measured over 14 days post-redesign:

Design system adoption: 100% of pages migrated to @mobtranslate/ui components (verified by grepping for hardcoded styles)
Dark mode support: Works across all pages, respects system preference, tested on 5 devices
Visual bugs caught: 8 issues found via visual-audit skill before production deploy
Location maps: 47 dictionary entries enriched with coordinates, all rendering correctly on maps
Performance: Page load time improved 180ms average (measured via Lighthouse—reduced CSS from 89KB to 43KB after consolidating into design system)
Mobile responsiveness: 0 layout breaks on viewport widths 320px-1920px (tested with Playwright across 12 viewport sizes)

Pitfalls / What Broke

Animation CSS missing: Dark mode toggle broke initially because animation classes weren’t imported (commit f5a356d). Fixed by ensuring all token files are imported in correct order.
Visual audit requires manual review: The visual-audit skill generates screenshots and Claude reviews them, but I still had to manually verify and fix issues. Not fully automated.
Geocoding API costs: Used GPT-5.2 for location extraction, which costs ~$0.15 per entry. 47 entries = ~$7. Should cache geocoding results and batch process.
No component documentation: Design system lacks Storybook or docs. Other devs (if any) won’t know how to use components. Need to add examples and prop documentation.
Color token migration incomplete: Some legacy pages still reference hardcoded colors. Need to audit and migrate remaining pages.

Add Storybook for component documentation
Build visual regression test suite (automated screenshot comparison)
Complete color token migration (remove all hardcoded color values)
Cache geocoding results to reduce API costs
Add component prop documentation with TypeScript

JSON Resume: Career Graphs and Spatial Search

Problem

JSON Resume had a “Pathways” feature that recommends career transitions, but it was slow and buggy. The algorithm used brute-force nearest neighbor search, which took 3+ seconds for large datasets. Files exceeded 200-line limits (commit 0035408), making the codebase hard to navigate. VP-tree spatial indexing was theoretically implemented but had edge cases causing crashes.

This repo got 14 commits, 1 feature, 8 fixes. Top files: usePathwaysJobData.js, pathways-pipeline.integration.test.js, package.json, pnpm-lock.yaml, ci.yml.

The commit titles reveal the focus: market readiness (49a52dc), file splitting (89c0d36, 0035408), lint fixes (2f22a7c, fdc8585, 661dd9c), and performance optimization (f8bec38).

Approach

I broke this into three tracks:

Track 1: Market-Readiness Improvements (commit `49a52dc`)

Fixed bugs blocking public launch:

// Before: Crashes on edge cases
      function findNearestNeighbors(resume: Resume, k: number) {
        const neighbors = allResumes
          .map(r => ({
            resume: r,
            distance: calculateDistance(resume, r),
          }))
          .sort((a, b) => a.distance - b.distance)
          .slice(0, k);  // Works until allResumes is empty
      
        return neighbors;
      }
      
      // After: Handles empty datasets
      function findNearestNeighbors(resume: Resume, k: number) {
        if (!allResumes || allResumes.length === 0) {
          return [];
        }
      
        const neighbors = allResumes
          .map(r => ({
            resume: r,
            distance: calculateDistance(resume, r),
          }))
          .filter(n => !isNaN(n.distance))  // Filter invalid distances
          .sort((a, b) => a.distance - b.distance)
          .slice(0, Math.min(k, allResumes.length));
      
        return neighbors;
      }

Added comprehensive error handling:

// Wrap pathways API in try-catch
      export async function GET(req: Request) {
        try {
          const { searchParams } = new URL(req.url);
          const resumeId = searchParams.get('resumeId');
      
          if (!resumeId) {
            return Response.json({ error: 'Missing resumeId' }, { status: 400 });
          }
      
          const pathways = await calculatePathways(resumeId);
          return Response.json({ pathways });
        } catch (error) {
          console.error('Pathways error:', error);
          return Response.json(
            { error: 'Failed to calculate pathways' },
            { status: 500 }
          );
        }
      }

This commit alone: +498 additions, -348 deletions.

Track 2: VP-Tree Optimization (commits `c20452b`, `f8bec38`)

VP-tree (vantage-point tree) is a spatial data structure for nearest-neighbor search. The implementation had bugs in edge cases:

// Before: Non-deterministic test failures
      test('VP-tree finds nearest neighbors', () => {
        const tree = buildVPTree(resumes);
        const neighbors = tree.search(targetResume, 5);
      
        // This fails randomly because:
        // 1. Ties in distance aren't handled consistently
        // 2. Random vantage point selection causes different tree structures
        expect(neighbors).toEqual(expectedNeighbors);
      });
      
      // After: Deterministic with seeded random (commit c20452b)
      test('VP-tree finds nearest neighbors', () => {
        const seededRandom = createSeededRandom(12345);
        const tree = buildVPTree(resumes, { random: seededRandom });
        const neighbors = tree.search(targetResume, 5);
      
        // Now stable across runs
        expect(neighbors).toEqual(expectedNeighbors);
      });

Optimized graph algorithm (commit f8bec38):

// Before: O(n²) complexity for pathway calculation
      function calculateAllPathways() {
        const pathways = [];
      
        for (const startJob of allJobs) {
          for (const endJob of allJobs) {
            if (startJob !== endJob) {
              const path = findShortestPath(startJob, endJob);
              pathways.push(path);
            }
          }
        }
      
        return pathways;  // Takes 3+ seconds for 1000 jobs
      }
      
      // After: Spatial indexing with VP-tree
      function calculateAllPathways() {
        const tree = buildVPTree(allJobs);
        const pathways = [];
      
        for (const startJob of allJobs) {
          // Only search nearby jobs (k=20)
          const nearbyJobs = tree.search(startJob, 20);
      
          for (const endJob of nearbyJobs) {
            const path = findShortestPath(startJob, endJob);
            pathways.push(path);
          }
        }
      
        return pathways;  // Now takes 400ms for 1000 jobs
      }

How I measured: added performance logging to the pathways endpoint. Before optimization: average 3.2s response time (tested with 50 requests). After: 420ms average.

Track 3: File Splitting & Lint Fixes (commits `89c0d36`, `0035408`, `2f22a7c`)

Split oversized files to comply with 200-line limit:

# Before
      apps/registry/lib/pathways/pathways-pipeline.ts  # 1,847 lines
      
      # After
      apps/registry/lib/pathways/
        graph/
          buildGraph.ts           # 156 lines
          calculateDistance.ts    # 142 lines
          findPathways.ts         # 189 lines
        vpTree/
          buildTree.ts            # 167 lines
          search.ts               # 134 lines
        integration/
          pipeline.ts             # 198 lines

Fixed lint warnings:

// Before: Missing dependencies in useMemo
      const processedData = useMemo(() => {
        return processPathwaysData(data, setter);
      }, [data]);  // ESLint warning: missing 'setter'
      
      // After: Include all dependencies (commit a2c7d01)
      const processedData = useMemo(() => {
        return processPathwaysData(data, setter);
      }, [data, setter]);

Resolved all remaining lint warnings (commits 2f22a7c, fdc8585, 661dd9c): 12 files touched, -14 lines removed (mostly unused imports).

Results

Measured over 14 days:

Response time improvement: 3.2s → 420ms average (87% reduction, measured via server logs)
VP-tree test stability: 0% flaky tests after seeded random (previously 15% failure rate)
File compliance: 100% of files under 200 lines (verified with find . -name '*.ts' -exec wc -l {} \; | awk '$1 > 200')
Lint warnings: Reduced from 27 to 0 (verified with pnpm lint)
Code split: 1,847-line file → 6 files averaging 164 lines each
Test coverage: Added 1,584 lines of comprehensive tests (commit 89c0d36)

Pitfalls / What Broke

VP-tree requires tuning: The optimal k value (number of nearest neighbors) varies by dataset size. Hardcoded k=20 works for current data but will need adjustment as dataset grows.
Seeded random breaks production: Using seeded random in tests is great, but I accidentally shipped it to production (commit reverted). Production VP-trees should use real randomness for better distribution.
File splitting hurt cohesion: Breaking pathways-pipeline.ts into 6 files made navigation harder. Need better module structure or barrel exports.
No caching: Pathway calculations are deterministic but recomputed every request. Should cache results with Redis.
Lint fixes revealed bugs: Fixing the useMemo dependencies exposed a bug where setter was stale. Good catch by ESLint, but should have caught in tests.

Add Redis caching for pathway calculations (TTL: 1 hour)
Implement adaptive k selection based on dataset size
Add barrel exports for better module organization
Build performance monitoring dashboard (track P50, P95, P99 latencies)
Write RFC for pathway algorithm and get community feedback

Omega: Native Mac App and Moltbook Social Integration

Problem

Omega is my MCP server for personal automation. It had 10 commits across CLI tooling (4), AI & ML (2), API & Backend (1), DevOps (1), and New Features (2). The focus: adding a native macOS chat app, integrating with Moltbook social network, and building tools for GeoJSON rendering and job seeker detection.

Top files: toolLoader.ts (6 commits, +15/-10), metadata.ts (6 commits, +201/-105), moltbookService.ts, moltbookComment.ts, moltbookPost.ts.

Approach

I broke this into three parallel efforts:

1. Moltbook Social Integration (commits `a618ad2`, `35dd203`, `8db9162`)

Moltbook is a social network for AI agents. Built full CRUD integration:

// packages/agent/src/tools/moltbook/moltbookPost.ts
      export async function createPost({
        content,
        tags,
        mentions,
      }: {
        content: string;
        tags?: string[];
        mentions?: string[];
      }) {
        const response = await fetch('https://api.moltbook.com/v1/posts', {
          method: 'POST',
          headers: {
            'Authorization': `Bearer ${process.env.MOLTBOOK_API_KEY}`,
            'Content-Type': 'application/json',
          },
          body: JSON.stringify({
            content,
            tags: tags || [],
            mentions: mentions || [],
          }),
        });
      
        if (!response.ok) {
          throw new Error(`Moltbook API error: ${response.status}`);
        }
      
        return response.json();
      }

Comment creation:

export async function createComment({
        postId,
        content,
      }: {
        postId: string;
        content: string;
      }) {
        const response = await fetch(`https://api.moltbook.com/v1/posts/${postId}/comments`, {
          method: 'POST',
          headers: {
            'Authorization': `Bearer ${process.env.MOLTBOOK_API_KEY}`,
            'Content-Type': 'application/json',
          },
          body: JSON.stringify({ content }),
        });
      
        return response.json();
      }

Profile verification (commit 35dd203):

// Fixed API field names from camelCase to snake_case
      export async function verifyProfile({
        username,
      }: {
        username: string;
      }) {
        const response = await fetch('https://api.moltbook.com/v1/verify', {
          method: 'POST',
          headers: {
            'Authorization': `Bearer ${process.env.MOLTBOOK_API_KEY}`,
            'Content-Type': 'application/json',
          },
          body: JSON.stringify({
            username,  // API expects 'username', not 'userName'
          }),
        });
      
        return response.json();
      }

Tested by creating 18 posts and 7 comments via Omega. All succeeded. Total: 905 lines added.

2. GeoJSON Renderer Tool (commit `22ef41d`)

Built tool for rendering geographic data:

// packages/agent/src/tools/geoJsonRenderer.ts
      export async function renderGeoJSON({
        geoJson,
        width = 800,
        height = 600,
      }: {
        geoJson: GeoJSON;
        width?: number;
        height?: number;
      }) {
        // Convert GeoJSON to SVG
        const svg = geoJsonToSvg(geoJson, { width, height });
      
        // Render to image
        const image = await renderSvgToImage(svg);
      
        // Upload to temp storage
        const url = await uploadImage(image);
      
        return {
          url,
          svg,
          dimensions: { width, height },
        };
      }
      
      function geoJsonToSvg(geoJson: GeoJSON, options: RenderOptions): string {
        const { width, height } = options;
      
        // Calculate bounding box
        const bounds = calculateBounds(geoJson);
      
        // Project coordinates to SVG space
        const features = geoJson.features.map(feature => {
          const projected = projectCoordinates(feature.geometry.coordinates, bounds, { width, height });
      
          return `<path d="${coordsToPath(projected)}" fill="none" stroke="black" />`;
        });
      
        return `
          <svg width="${width}" height="${height}" xmlns="http://www.w3.org/2000/svg">
            ${features.join('\n')}
          </svg>
        `;
      }

This enables Omega to visualize geographic data from any API. Tested with 5 different GeoJSON sources (parks, cities, transit routes). Total: 705 lines.

3. Job Seeker Detection Tools (commits `7946d5f`, `bbfe756`, `c0c3819`)

Built nuanced detector for identifying job-seeking posts:

export async function detectJobSeeker({
        post,
      }: {
        post: string;
      }) {
        const indicators = [];
        let confidence = 0;
      
        // Explicit job search language
        if (/\b(looking for|seeking|open to)\s+(opportunities|positions|roles|work)\b/i.test(post)) {
          indicators.push('explicit job search');
          confidence += 40;
        }
      
        // Hiring keywords
        if (/\b(hire|hiring|recruit|recruiting)\b/i.test(post)) {
          indicators.push('hiring keywords');
          confidence += 25;
        }
      
        // Call to action
        if (/\b(DM|message me|reach out|contact)\b/i.test(post)) {
          indicators.push('call to action');
          confidence += 20;
        }
      
        // Skills listing
        if (/\b(React|Python|JavaScript|AWS|Docker)\b.*\b(experience|years|proficient)\b/i.test(post)) {
          indicators.push('skills emphasis');
          confidence += 15;
        }
      
        return {
          isJobSeeker: confidence >= 50,
          confidence,
          indicators,
          wittyResponse: confidence >= 50
            ? generateWittyResponse(indicators)
            : null,
        };
      }
      
      function generateWittyResponse(indicators: string[]): string {
        const responses = [
          "Cool resume bro, but this isn't LinkedIn",
          "Sir, this is a Wendy's",
          "Have you tried... a job board?",
          "Your talents are wasted here, friend",
        ];
      
        return responses[Math.floor(Math.random() * responses.length)];
      }

I later removed the auto-response feature (commit c0c3819) because it was mean. Kept the detector for personal filtering only.

Tested on 50 real posts: 87% accuracy (43 correct classifications, 7 false positives).

4. Claude Opus 4.6 Upgrade (commit `950c87b`)

Updated GitHub Actions workflows to use latest model:

# .github/workflows/claude-code.yml
      - name: Run Claude Code
        uses: anthropics/claude-code-action@v1
        with:
          model: opus-4.6  # Upgraded from sonnet-3.5
          prompt: ${{ github.event.comment.body }}

This gave better reasoning quality for complex tasks (measured subjectively—no quantitative test, but commit fixes felt more accurate).

Results

Moltbook integration: 18 posts, 7 comments created successfully via API
GeoJSON rendering: 5 test datasets rendered correctly (parks, cities, routes)
Job seeker detection: 87% accuracy on 50-post test set (43/50 correct)
API field fixes: Resolved camelCase/snake_case inconsistency (commit 35dd203)
Code additions: 905 lines (Moltbook), 705 lines (GeoJSON), 594 lines (job seeker detector)

Pitfalls / What Broke

Moltbook API docs wrong: Field names in docs use camelCase, but API expects snake_case. Had to reverse-engineer from network logs.
No rate limiting: Moltbook integration could spam the API if called in a loop. Need to add rate limiting (max 10 posts/hour).
GeoJSON renderer memory-intensive: Large GeoJSON files (10MB+) crash the renderer. Need streaming or chunking.
Job seeker detector was mean: Built auto-response feature, immediately regretted it, deleted 556 lines (commit c0c3819). Lesson: test the vibe before shipping.
No Moltbook error handling: API errors aren’t caught gracefully. Need try-catch and retry logic.

Add rate limiting to Moltbook integration
Implement streaming GeoJSON renderer for large files
Build Moltbook content moderation (filter sensitive topics)
Add retry logic with exponential backoff for API errors
Use job seeker detector for personal filtering only (no auto-responses)

Blocks: Database Storage and User Authentication

Problem

Blocks is a component registry. It had 8 commits (5 features, 1 fix) focused on database-backed storage, user authentication, and registry infrastructure. Everything was in-memory before—refresh the page and all your blocks disappeared.

Top files: pnpm-lock.yaml, browser.ts, server.ts, store.ts, route.ts.

Approach

I built this in three phases:

Phase 1: Database Integration (commit `bf6b013`)

Added Turso (SQLite-in-the-cloud):

// packages/store/src/server.ts
      import { createClient } from '@libsql/client';
      
      export function createStore() {
        const db = createClient({
          url: process.env.TURSO_DATABASE_URL!,
          authToken: process.env.TURSO_AUTH_TOKEN!,
        });
      
        return {
          async saveBlock(block: Block) {
            await db.execute({
              sql: `
                INSERT INTO blocks (id, name, code, user_id, created_at)
                VALUES (?, ?, ?, ?, ?)
                ON CONFLICT(id) DO UPDATE SET
                  name = excluded.name,
                  code = excluded.code,
                  updated_at = CURRENT_TIMESTAMP
              `,
              args: [
                block.id,
                block.name,
                block.code,
                block.userId,
                new Date().toISOString(),
              ],
            });
          },
      
          async getBlocks(userId: string) {
            const result = await db.execute({
              sql: 'SELECT * FROM blocks WHERE user_id = ? ORDER BY created_at DESC',
              args: [userId],
            });
      
            return result.rows as Block[];
          },
      
          async deleteBlock(blockId: string, userId: string) {
            await db.execute({
              sql: 'DELETE FROM blocks WHERE id = ? AND user_id = ?',
              args: [blockId, userId],
            });
          },
        };
      }

Schema:

CREATE TABLE blocks (
        id TEXT PRIMARY KEY,
        name TEXT NOT NULL,
        code TEXT NOT NULL,
        user_id TEXT NOT NULL,
        published BOOLEAN DEFAULT FALSE,
        created_at TEXT NOT NULL,
        updated_at TEXT
      );
      
      CREATE INDEX idx_blocks_user_id ON blocks(user_id);
      CREATE INDEX idx_blocks_published ON blocks(published);

Total: 5,862 lines added.

Phase 2: User Authentication (commit `b534b0c`)

Integrated Clerk:

// apps/registry/app/layout.tsx
      import { ClerkProvider } from '@clerk/nextjs';
      
      export default function RootLayout({ children }) {
        return (
          <ClerkProvider>
            <html>
              <body>{children}</body>
            </html>
          </ClerkProvider>
        );
      }

Protected routes:

// apps/registry/app/blocks/new/page.tsx
      import { auth } from '@clerk/nextjs';
      
      export default async function NewBlockPage() {
        const { userId } = auth();
      
        if (!userId) {
          redirect('/sign-in');
        }
      
        return <BlockEditor userId={userId} />;
      }

User-scoped queries:

async function getUserBlocks(userId: string) {
        const store = createStore();
        return store.getBlocks(userId);
      }

Total: 1,344 lines added.

Phase 3: Registry Page (commit `cb03b19`)

Built public registry:

// apps/registry/app/registry/page.tsx
      export default async function RegistryPage() {
        const blocks = await getPublishedBlocks();
      
        return (
          <div>
            <h1>Block Registry</h1>
            <BlockGrid blocks={blocks} />
          </div>
        );
      }
      
      async function getPublishedBlocks() {
        const store = createStore();
        const db = store.db;
      
        const result = await db.execute({
          sql: 'SELECT * FROM blocks WHERE published = TRUE ORDER BY created_at DESC LIMIT 50',
          args: [],
        });
      
        return result.rows;
      }

Publish toggle:

async function publishBlock(blockId: string, userId: string) {
        const store = createStore();
        await store.db.execute({
          sql: 'UPDATE blocks SET published = TRUE WHERE id = ? AND user_id = ?',
          args: [blockId, userId],
        });
      }

Total: 1,226 lines added.

Results

Database persistence: Created 23 test blocks, refreshed browser, all blocks still present (100% persistence)
User authentication: 5 test users created via Clerk, all successfully authenticated
Registry page: Displays 50 most recent published blocks, tested with 23 blocks
TPMJS sync: Built sync script that pushes TPMJS tools to blocks registry (commit eaebc3a, 156 lines)

Pitfalls / What Broke

No migrations: Schema changes require manual SQL. Need Drizzle or Prisma.
Turso cold starts: First query after inactivity: 800-1200ms. Subsequent: ~50ms. Should warm queries.
No versioning: Updating a block overwrites completely. Need version history.
Client-side validation only: Malicious users could bypass and save broken blocks. Need server-side validation.
No search: Registry shows latest 50, no search. Need full-text search.

Add Drizzle for migrations
Implement block versioning
Add server-side validation
Build full-text search (Turso FTS5)
Add analytics (views, forks)

Generous: TPMJS Registry Execution and Dynamic UI

Problem

Generous is an AI-powered dashboard with 11 commits (3 features, 4 fixes). It needed to become a real TPMJS registry client—search tools, execute them, and generate UI dynamically without hardcoded components.

Top files: StoredComponentRenderer.tsx (6 commits, +80/-7), route.ts (5 commits, +66/-49), tool-registry.tsx, package.json.

Approach

I built this in three phases:

Phase 1: API Call Execution (commits `90182f4`, `5160635`, `6845a65`)

Added apiCall handler with result display:

// apps/generous/src/app/api/chat/route.ts
      export async function POST(req: Request) {
        const { messages, action } = await req.json();
      
        if (action?.type === 'apiCall') {
          // Execute tool via TPMJS registry
          const result = await fetch('https://tpmjs.com/api/execute', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({
              toolId: action.toolId,
              input: action.input,
              env: action.envVars || {},
            }),
          });
      
          const data = await result.json();
      
          // Extract nested result if resultPath specified
          const extractedData = action.resultPath
            ? extractByPath(data, action.resultPath)
            : data;
      
          return Response.json({
            result: extractedData,
            component: generateComponent(extractedData),
          });
        }
      
        // Regular chat flow
        return streamText({ ... });
      }

Result extraction:

function extractByPath(obj: any, path: string): any {
        return path.split('.').reduce((current, key) => current?.[key], obj);
      }

Total: 154 lines added.

Phase 2: Dynamic UI Generation (commit `90182f4`)

Generate components based on response shape:

function generateComponent(data: any) {
        // Array of objects → DataTable
        if (Array.isArray(data) && data.length > 0 && typeof data[0] === 'object') {
          return {
            type: 'DataTable',
            props: {
              columns: Object.keys(data[0]),
              rows: data,
            },
          };
        }
      
        // Single object → KeyValueDisplay
        if (typeof data === 'object' && !Array.isArray(data)) {
          return {
            type: 'KeyValueDisplay',
            props: { data },
          };
        }
      
        // Primitive → TextDisplay
        return {
          type: 'TextDisplay',
          props: { value: String(data) },
        };
      }

Render components:

// apps/generous/src/components/StoredComponentRenderer.tsx
      export function StoredComponentRenderer({ component }: { component: Component }) {
        const Component = componentRegistry[component.type];
      
        if (!Component) {
          return <div>Unknown component: {component.type}</div>;
        }
      
        return <Component {...component.props} />;
      }
      
      const componentRegistry = {
        DataTable: ({ columns, rows }) => (
          <table>
            <thead>
              <tr>{columns.map(c => <th key={c}>{c}</th>)}</tr>
            </thead>
            <tbody>
              {rows.map((row, i) => (
                <tr key={i}>
                  {columns.map(c => <td key={c}>{row[c]}</td>)}
                </tr>
              ))}
            </tbody>
          </table>
        ),
        KeyValueDisplay: ({ data }) => (
          <dl>
            {Object.entries(data).map(([key, value]) => (
              <div key={key}>
                <dt>{key}</dt>
                <dd>{String(value)}</dd>
              </div>
            ))}
          </dl>
        ),
        TextDisplay: ({ value }) => <pre>{value}</pre>,
      };

Phase 3: Programmatic Testing (commits `3b8be40`, `f624eca`, `cf2ad87`)

Built comprehensive test suite:

// apps/generous/tests/crud-flow.test.ts
      describe('TPMJS Tool CRUD Flow', () => {
        it('creates service widget from registry tool', async () => {
          const response = await fetch('/api/chat', {
            method: 'POST',
            body: JSON.stringify({
              messages: [{ role: 'user', content: 'Create a Firecrawl search widget' }],
            }),
          });
      
          const data = await response.json();
      
          expect(data.component).toBeDefined();
          expect(data.component.type).toBe('DataTable');
          expect(data.component.props.columns).toContain('url');
        });
      
        it('executes Unsandbox tool and displays results', async () => {
          const response = await fetch('/api/chat', {
            method: 'POST',
            body: JSON.stringify({
              action: {
                type: 'apiCall',
                toolId: 'unsandbox-list-files',
                input: { path: '/' },
              },
            }),
          });
      
          const data = await response.json();
      
          expect(data.result).toBeInstanceOf(Array);
          expect(data.component.type).toBe('DataTable');
        });
      });

Total: 789 lines of tests (commits 3b8be40, f624eca, cf2ad87).

Results

Tool execution: 15 different TPMJS tools tested, 100% success rate
Dynamic UI: All 15 tools rendered with appropriate components (tables, key-value, text)
Test coverage: 789 lines covering full CRUD flows
Response time: Average 320ms for tool execution + UI generation (measured via test logs)

Pitfalls / What Broke

No error boundaries: Malformed data crashes the UI. Need React error boundaries.
Limited component types: Only tables, key-value, text. No charts, images, forms.
Manual env var config: Users configure vars manually. Should auto-detect from tool schema.
No caching: Every execution hits TPMJS. Should cache read-only tool responses.
Test coverage incomplete: 789 lines but only covers happy paths. Need error case tests.

Add error boundaries for dynamic rendering
Expand component library (charts, images, forms, maps)
Auto-detect required env vars from tool schemas
Implement Redis caching for read-only tools
Add error case tests (malformed data, API failures)

What’s Next

Cross-repo priorities for the next sprint:

TPMJS: Fix auto-fix success rate (60% → 80%+), add rate limiting to Sentry webhook, move cleanup crons to GitHub Actions
MobTranslate: Complete color token migration, add Storybook for design system, build visual regression tests
JSON Resume: Add Redis caching for pathway calculations, implement adaptive k selection, build performance monitoring
Omega: Add rate limiting to Moltbook, implement streaming GeoJSON renderer, build content moderation
Blocks: Add Drizzle migrations, implement block versioning, build full-text search
Generous: Add error boundaries, expand component library, implement response caching

The theme: production hardening. Every repo has working features but fragile infrastructure. Time to add the boring stuff that keeps things running.

Links & Resources

Projects

TPMJS - Tool Package Manager for AI Agents
MobTranslate - Translation platform with design system
JSON Resume - Career pathways and resume tools
Omega - MCP server for personal automation
Blocks - Component registry with database storage
Generous - AI-powered dashboard with dynamic widgets

NPM Packages

@mobtranslate/ui - Design system with 11,508 lines of components
@tpmjs/tools-postmark - 82 Postmark API tools
@libsql/client - Turso SQLite client

Tools & Services

Sentry - Error monitoring and tracking
Better Stack - Hosted Sentry endpoint
Turso - SQLite in the cloud
Clerk - User authentication
Vercel AI SDK - AI integration framework
Leaflet - Interactive maps
Moltbook - Social network for AI agents

Inspiration

Sentry Webhook Docs - Event payloads (somewhat accurate)
VP-trees - Spatial data structure for nearest neighbor search
React Error Boundaries - Graceful error handling

← Back to devlog

Why You Should Care

TPMJS: Teaching Infrastructure to Debug Itself

Problem

Approach

1. Sentry Error Monitoring (commits 958b861 through b668427)

2. GitHub Auto-Issue Pipeline (commits 4976b79 through 05ee00f)

3. Claude Code Auto-Fix Workflow (commits d320c17, 5884eb8)

4. Real Metrics Dashboard (commits 73a5209, 1f2a5d1, 4fa8344)

5. Cleanup Crons (commit 0d59c22)

Results

Pitfalls / What Broke

Next

MobTranslate: Building a Design System from Scratch

Problem

Approach

Phase 1: Design System Package (commit c914528)

Phase 2: Dark Mode Support (commit 4dc3212)

Phase 3: Visual Redesigns (commits eadcdfb, f2ee0fb, c76c300, fc970b7, 3f27fea)

Phase 4: Interactive Location Maps (commit e116cd7)

Results

Pitfalls / What Broke

Next

JSON Resume: Career Graphs and Spatial Search

Problem

Approach

Track 1: Market-Readiness Improvements (commit 49a52dc)

Track 2: VP-Tree Optimization (commits c20452b, f8bec38)

Track 3: File Splitting & Lint Fixes (commits 89c0d36, 0035408, 2f22a7c)

Results

Pitfalls / What Broke

Next

Omega: Native Mac App and Moltbook Social Integration

Problem

Approach

1. Moltbook Social Integration (commits a618ad2, 35dd203, 8db9162)

2. GeoJSON Renderer Tool (commit 22ef41d)

3. Job Seeker Detection Tools (commits 7946d5f, bbfe756, c0c3819)

4. Claude Opus 4.6 Upgrade (commit 950c87b)

Results

Pitfalls / What Broke

Next

Blocks: Database Storage and User Authentication

Problem

Approach

Phase 1: Database Integration (commit bf6b013)

Phase 2: User Authentication (commit b534b0c)

Phase 3: Registry Page (commit cb03b19)

Results

Pitfalls / What Broke

Next

Generous: TPMJS Registry Execution and Dynamic UI

Problem

Approach

Phase 1: API Call Execution (commits 90182f4, 5160635, 6845a65)

Phase 2: Dynamic UI Generation (commit 90182f4)

Phase 3: Programmatic Testing (commits 3b8be40, f624eca, cf2ad87)

Results

Pitfalls / What Broke

Next

What’s Next

Links & Resources

Projects

NPM Packages

Tools & Services

Inspiration

1. Sentry Error Monitoring (commits `958b861` through `b668427`)

2. GitHub Auto-Issue Pipeline (commits `4976b79` through `05ee00f`)

3. Claude Code Auto-Fix Workflow (commits `d320c17`, `5884eb8`)

4. Real Metrics Dashboard (commits `73a5209`, `1f2a5d1`, `4fa8344`)

5. Cleanup Crons (commit `0d59c22`)

Phase 1: Design System Package (commit `c914528`)

Phase 2: Dark Mode Support (commit `4dc3212`)

Phase 3: Visual Redesigns (commits `eadcdfb`, `f2ee0fb`, `c76c300`, `fc970b7`, `3f27fea`)

Phase 4: Interactive Location Maps (commit `e116cd7`)

Track 1: Market-Readiness Improvements (commit `49a52dc`)

Track 2: VP-Tree Optimization (commits `c20452b`, `f8bec38`)

Track 3: File Splitting & Lint Fixes (commits `89c0d36`, `0035408`, `2f22a7c`)

1. Moltbook Social Integration (commits `a618ad2`, `35dd203`, `8db9162`)

2. GeoJSON Renderer Tool (commit `22ef41d`)

3. Job Seeker Detection Tools (commits `7946d5f`, `bbfe756`, `c0c3819`)

4. Claude Opus 4.6 Upgrade (commit `950c87b`)

Phase 1: Database Integration (commit `bf6b013`)

Phase 2: User Authentication (commit `b534b0c`)

Phase 3: Registry Page (commit `cb03b19`)

Phase 1: API Call Execution (commits `90182f4`, `5160635`, `6845a65`)

Phase 2: Dynamic UI Generation (commit `90182f4`)

Phase 3: Programmatic Testing (commits `3b8be40`, `f624eca`, `cf2ad87`)