feat(omni-core): extend omni-core with PR1 changes (squash recommended)

[KooshaPari]

Summary

Extended omni-core work captured from ~/CodeProjects/Phenotype/repos/OmniRoute-superroot-recovery/feat/pr1-extend-omni-core (3224 commits ahead of origin/koosha:feat/pr1-extend-omni-core at time of push).

⚠️ IMPORTANT

This branch accumulated 3224 local commits of in-progress work. It is NOT ready to merge as-is. Before merging upstream, the maintainer should:

1. Identify the actual PR-ready changes vs noise
2. Squash to 1-3 commits with clean messages
3. Review for security (one commit may have included secrets — redaction done in the most recent captured commit)
4. Verify CI passes against the current upstream main

What's likely in here

The branch was a long-running local WIP on the superroot-recovery snapshot. Contents include:

• Omni-core extensions (request/response models)
• Many in-progress experiments (some committed by automation)
• Dependency updates
• Test additions

Recommendation

Do NOT merge as-is. Suggested next steps:

1. git log --first-parent main..feat/pr1-extend-omni-core | head -50 — see the commit graph
2. git rebase -i main — interactively squash to the meaningful commits
3. cargo test — verify the slimmed-down branch passes
4. Open a follow-up PR with the squashed version

Why this PR exists

Pushed as a preservation/snapshot — the local clone's main remote was misconfigured to point at plain KooshaPari/OmniRoute (not OmniRoute-superroot-recovery which doesn't exist). To preserve the work for future rebase/recovery, it was force-pushed to the user's fork, then a PR was opened to the upstream repo for transparency.

Files in the snapshot

Total files changed in the most recent captures: 79 files.

Refs: sweep 2026-07-15 / cleanup audit

[gemini-code-assist]

Code Review

This pull request restructures the repository into a monorepo containing a SvelteKit 2/Svelte 5 frontend (apps/web), a Hono 4/tRPC 11 backend-for-frontend (apps/bff), and a Tauri 2 native desktop shell (apps/desktop), alongside updating various configuration, CI/CD, and documentation files. The code review identified several critical issues in the new implementation: a header forwarding bug in the proxy route that causes client-side decoding failures; unhandled custom SSE events in the health dashboard; a heartbeat interval leak in Hono's streaming API due to overwritten onAbort callbacks; a potential socket binding failure on unclean shutdowns; hanging promises in the kbridge client during clean peer closures; fragile stream chunk parsing in the playground; and a missing POST /flags endpoint required by the frontend.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

When proxying requests using fetch, the runtime automatically decompresses the response body by default. However, copying all headers directly from the upstream response forwards the original content-encoding (e.g., gzip) and content-length headers. This causes clients to receive uncompressed data but expect compressed data, leading to decoding errors (such as ERR_CONTENT_DECODING_FAILED in browsers). We should delete these headers from the forwarded response.

  try {
    const upstream = await fetch(upstreamUrl, init);
    const responseHeaders = new Headers(upstream.headers);
    responseHeaders.delete('content-encoding');
    responseHeaders.delete('content-length');
    responseHeaders.delete('transfer-encoding');
    responseHeaders.set('x-proxied-by', 'argismonitor-bff');
    return new Response(upstream.body, { status: upstream.status, headers: responseHeaders });
  } catch (err) {

[gemini-code-assist]

The server dispatches SSE messages with a custom event name (event: 'health'). In the Server-Sent Events standard, custom events do not trigger the default onmessage handler on the client. Instead, you must register a listener for that specific event name using addEventListener('health', ...). Otherwise, the stream will never display any messages.

      eventSource.addEventListener('health', (e) => {
        try {
          const parsed = JSON.parse(e.data);
          events = [...events.slice(-99), parsed];
        } catch {
          // ignore non-JSON
        }
      });

[gemini-code-assist]

In Hono's streaming API, stream.onAbort accepts only a single callback. Calling it multiple times overwrites the previous handler. Here, the second call stream.onAbort(() => resolve()) overwrites the first call stream.onAbort(() => clearInterval(interval)), causing the heartbeat interval to leak and run indefinitely after a client disconnects. We should combine both actions into a single onAbort callback.

      await new Promise<void>((resolve) => {
        const interval = setInterval(() => {
          send('info', 'heartbeat @ ' + new Date().toLocaleTimeString()).catch(() => {});
        }, 5000);
        stream.onAbort(() => {
          clearInterval(interval);
          resolve();
        });
      });

[gemini-code-assist]

When starting a Unix domain socket server, if the socket file already exists on disk (e.g., from a previous crash or unclean shutdown), binding to it will fail with EADDRINUSE. It is standard practice to check if the socket file exists and unlink it before calling Bun.serve.

import { serve } from '@hono/node-server';
import { existsSync, unlinkSync } from 'node:fs';
import app from './index';

const port = Number(process.env.PORT ?? 4322);
const socketPath = process.env.OMNIROUTE_BFF_SOCKET;

serve({ fetch: app.fetch, port }, (info) => {
  console.log('argismonitor BFF listening on http://localhost:' + info.port);
});

if (socketPath) {
  if (typeof Bun !== 'undefined' && typeof Bun.serve === 'function') {
    if (existsSync(socketPath)) {
      try {
        unlinkSync(socketPath);
      } catch (err) {
        console.error('Failed to unlink existing socket at ' + socketPath + ':', err);
      }
    }
    Bun.serve({
      unix: socketPath,
      fetch: app.fetch,
    });
    console.log('argismonitor BFF also listening on Unix socket ' + socketPath);
  } else {
    console.error(
      'OMNIROUTE_BFF_SOCKET=' + socketPath + ' requested but Bun runtime not detected. ' +
      'Unix sockets in this BFF require bun. Falling back to TCP only.'
    );
  }
}

[gemini-code-assist]

If the socket connection is closed cleanly by the peer (e.g., the gateway daemon restarts), the 'close' event is emitted but 'error' is not. In this case, any pending promises in inflight will hang indefinitely. We should handle the 'close' event to reject any remaining inflight promises.

  s.on('close', (hadError) => {
    socket = null;
    if (!hadError) {
      const err = new Error('kbridge connection closed cleanly by peer');
      for (const [id, p] of inflight) p.reject(err);
      inflight.clear();
    }
  });

[gemini-code-assist]

Splitting the stream chunk directly by \n assumes that chunks align perfectly with line boundaries. In TCP/HTTP streaming, chunks can be split arbitrarily, meaning a chunk can end in the middle of a line. This leads to JSON parsing errors on partial lines. We should maintain a buffer to accumulate chunks and only split/process complete lines.

      let buffer = '';
      while (true) {
        const { done, value } = await reader.read();
        if (done) break;
        buffer += decoder.decode(value, { stream: true });
        const lines = buffer.split('\n');
        buffer = lines.pop() ?? '';
        for (const line of lines) {
          const trimmed = line.trim();
          if (trimmed.startsWith('data: ')) {
            const data = trimmed.slice(6);
            if (data === '[DONE]') break;
            try {
              const j = JSON.parse(data);
              if (j.token) response += j.token;
              if (j.tokens) tokens = j.tokens;
              if (j.cost) cost = j.cost;
            } catch {}
          }
        }
      }

[gemini-code-assist]

The frontend's create() function in flags/admin/+page.svelte attempts to create new feature flags by sending a POST request to /api/dashboard/flags. However, the Hono router only defines GET /flags and PUT /flags/:key. We should add a POST /flags endpoint to the router to support flag creation.

[aftabahamad260-code]

f