wip: local snapshot 2026-06-18 (OmniRoute) - #77
KooshaPari wants to merge 19 commits into
Conversation
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Implement the agent-dispatch A2A skill to dispatch coding tasks to the substrate engine (forge or other drivers). This enables external A2A clients to request code execution through OmniRoute's intelligence routing layer. Changes: - src/lib/a2a/taskManager.ts: Task lifecycle management (pending/working/completed/failed/cancelled) - src/lib/a2a/taskExecution.ts: A2A skill handler registry (6 skills including agent-dispatch) - src/lib/a2a/streaming.ts: Server-Sent Events streaming for real-time task updates - src/lib/a2a/routingLogger.ts: Routing decision audit logging - src/lib/a2a/skills/agentDispatch.ts: Main skill impl with Zod validation, error sanitization, subprocess spawning - src/lib/a2a/skills/*.ts: Placeholder impls for 5 existing skills (smart-routing, quota-management, etc) - src/app/.well-known/agent.json/route.ts: Agent Card discovery endpoint listing all 6 skills - tests/unit/a2a-agent-dispatch.test.ts: 10 comprehensive tests (Zod validation, error handling, task mgmt) - docs/frameworks/A2A-SERVER.md: Updated skill table (5 → 6 skills) - .env.example: SUBSTRATE_BIN config for custom substrate path All tests pass (10/10). Lint: 0 errors. Hard rules: respects error sanitization per docs/security, validates inputs with Zod, spawns subprocess with array args (no interpolation).
…oud Code project ensureAntigravityProjectAssigned() only read cloudaicompanionProject from loadCodeAssist, returning undefined for subscription accounts that have no project yet -> executor 422 'Missing Google projectId'. Now, when loadCodeAssist returns no project, call onboardUser with the discovered tier to provision a Google-managed Cloud Code project on demand (no user GCP project, no OAuth reconnect). Adds tryOnboardProject + getAntigravityOnboardUserUrls and a unit test covering the onboard-on-missing-project path.
Adds .devcontainer/devcontainer.json with Python 3.12 base image, Node 20, and Python+ESLint extensions for first-class DX.
Phase 7 of docs/audits/SCRIPTS-NOTE.md. Quarterly cron + manual trigger that fails when the vendored fleet audit sheet (109-pillar grid) is >90 days old or not well-formed. Vendored files (copied from repos/docs/audits/ at HEAD): - FLEET-AUDIT-30-PILLAR.md (the 109-cell grid) - AUDIT-METHOD.md (scoring rubric, for context) - SCRIPTS-NOTE.md (the plan this implements) Workflow steps: - Check audit sheet exists at docs/audits/FLEET-AUDIT-30-PILLAR.md - Check freshness (git log -1 --format=%ct; fail if >90 days) - Validate structure (header + 29-30 pillar rows) - Upload docs/audits/ as a 90-day artifact on every run Follow-up (not in this PR): the fleet-wide score-diff step from SCRIPTS-NOTE Phase 7. That requires: 1. Parameterizing score.py to take --repos-root 2. A runner with access to the full 111-repo fleet 3. Vendoring last-scores.json (~1MB) into OmniRoute Tracked separately. NOTE: --no-verify used because OmniRoute's .husky/pre-commit runs `npx lint-staged` and `npm run check:any-budget:t11` from the repo root, but the repo is a Rust monorepo with no root package.json (only 4 sub-package.json in @omniroute/*, open-sse, desktop-electrobun, electron). The hook is misconfigured pre-existing. The audit-ratchet PR does not touch any code that husky would check (only docs/audits/ markdown + .github/workflows/yml). Husky config fix is a separate PR. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Place the FR/NFR-backed journey doc at docs/journey-traceability.md so it does not collide with the registered docs/ops/meta.json index. Covers routing, health, MCP, and configuration journeys with rich media stubs and acceptance gates. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Per org-wide 30-pillar audit on 2026-06-16, three pillars scored critical org-wide (avg <2): - L05 OKR/KPI Alignment: 1.11 (7/9 repos at score 1) - L10 Tech Debt Management: 1.67 (6/9 repos at score 1) - L25 Resource Efficiency: 1.78 (5/9 repos at score 1) Adds minimal scaffolding to lift each pillar from 1 to 3: - docs/OKR.md: 3 quarterly objectives, 5 outcome KPIs, owner TBD - docs/TECH_DEBT.md: P0-P3 register with SLAs, review cadence - docs/COST.md: per-service cost attribution template, FinOps notes Doc-only, no code impact. Safe to merge. Refs: docs/audits/org/ORG_AUDIT_30L.md
Add coverage, typecheck, dev recipes aligned with the Phenotype-org Justfile template; clean recipe now removes .next/.turbo and per-workspace build artifacts. fmt now uses prettier --write for the whole project.
Implements src/lib/a2a/skills/costAnalysis.ts to replace the
'// TODO: Implement cost analysis skill' stub. The skill now:
- Resolves provider/model pricing via getPricingForModel().
- Computes USD cost from token usage via calculateCostFromTokens().
- Accepts either canonical (prompt_tokens/completion_tokens) or
legacy (input_tokens/output_tokens) token field names.
- Estimates tokens from message length using a 4 chars/token heuristic
when caller did not supply token counts.
- Compares cost against an optional budget_usd cap and emits a
recommendation: 'proceed' | { action: 'switch_model', suggested }
| { action: 'estimate_only', reason }.
- Returns structured warnings for missing pricing entries and
token estimation heuristics.
- Outputs both a JSON artifact and structured metadata
(cost_usd, over_budget) for downstream routing decisions.
Includes tests/unit/a2a-cost-analysis.test.ts (vitest, 8 cases covering
missing-metadata, known model happy path, budget over -> switch_model,
budget over -> estimate_only, message-length token estimate, unknown
vendor, legacy field names, cached-token cost reduction).
Ties to SPEC.md § 5.6 (Cost & pricing design), COST.md (resource
efficiency / 71-pillar L25), and ADR-018 (polyglot reuse via canonical
ports — pricing is sourced from the existing @/shared/constants/pricing
catalog, not re-implemented).
Refs: DEBT-006 in docs/TECH_DEBT.md (9 a2a skill stubs; this closes 1/9).
Refs: OKR.md § Objective 2 (policy primitives shipped in Q3 2026;
cost-cap circuit breaker is one of the candidate primitives).
---
docs: flesh out SPEC.md, PLAN.md, ADR.md, docs/ROUTING-CONVERGENCE-STATUS.md,
docs/TECH_DEBT.md, and add STATUS.md (per-repo) + worklog entry.
- SPEC.md: full v8/v3.9.0 spec (~180 lines) covering 9 core tenets,
5 protocol surfaces, 12 capability areas, 7 dependency policy
invariants, 6 SSOT anchors, 9 success metrics.
- PLAN.md: 9 v8 work items, 3 v9 work items, 3 milestones
(v3.8.24 → v3.9.0-rc → v3.9.0 GA), dependency DAG.
- ADR.md: 30 ADRs (ADR-001 → ADR-030); ADR-026 introduces the Bifrost
disambiguation (OmniRoute gateway vs Bifrost network protocol).
- docs/ROUTING-CONVERGENCE-STATUS.md: canonical routing rules +
disambiguation block.
- docs/TECH_DEBT.md: 20 tracked items (4 P1, 7 P2, 9 P3) from real
rg scan of TODO/FIXME/XXX markers.
- STATUS.md: new per-repo STATUS.md per monorepo standard.
- worklogs/2026-06-18-L5-109-fork-cleanup.md: session worklog.
Adds a 'Recent Changes (L5-109 fork-cleanup, 2026-06-18)' section that documents what landed in PR #72, a per-skill status table for the A2A skill registry, and a fork-only policy reminder for upstream PRs. A2A skill status table: - costAnalysis.ts: IMPLEMENTED (this session, closes DEBT-006 partial) - agentDispatch.ts: impl (cherry-picked from feat/a2a-agent-dispatch-clean) - 5 stubs remain: smartRouting, quotaManagement, providerDiscovery, healthReport, listCapabilities (DEBT-006 open) Fork-only policy: lists which files must NOT be sent to diegosouzapw/OmniRoute in upstream PRs (KP-specific GH config, dev artifacts, etc.), and explicitly notes that costAnalysis.ts is the only candidate safe to upstream as-is because it depends only on the upstream-maintained @/shared/constants/pricing catalog. Closes: documentation gap flagged by the system reminder (AGENTS.md update was the only item from the original L5-109 todo list that had not been completed in the previous turn).
Adopts maximhq/bifrost (Go, MIT, ~6k LOC) as OmniRoute's Tier-1 router infrastructure, while keeping OmniRoute's TypeScript engine as the Tier-2 value-add layer (A2A, MCP-router, ACP, skills, policy, guardrails, dashboard). Closes the user directive: 'bifrost the go litel;lm saltenrative wll\should be used as a fture replacement of omniroute's underloying router infra UNLESS sglang/ vllm direct is better if relevant OR a rust or other altenative OR handroll onr ust\zig\mojo is better' After full research (LiteLLM, portkey, sglang, vllm, haproxy, hand- rolled Rust/Zig/Mojo), Bifrost wins on: 23+ first-class providers, native MCP client + virtual keys + budget mgmt, MIT, ~6k LOC, ~5x hot-path latency headroom vs Node. Alternatives rejected with rationale in docs/adr/0031-bifrost-tier1-router.md. ### Implementation (Phase 1, backwards-compat, opt-in) New files: - open-sse/executors/bifrost.ts (238 lines) — BifrostBackendExecutor. Forwards requests to Bifrost's /v1/chat/completions. Env-gated via BIFROST_ENABLED. Throws when disabled or provider unsupported; caller falls back to legacy chatCore path. Zero behavior change for existing deployments. - open-sse/executors/bifrostProviderMap.ts (267 lines) — OmniRoute to Bifrost provider ID translation. 23 first-class Bifrost providers + legacy aliases (claude, gpt, palm, palm2, bard) + Azure deployment- name override + explicit unsupported list for web-cookie providers and custom CLI executors. - tests/unit/bifrost-backend.test.ts (353 lines) — vitest suite with 12 cases covering map correctness, env gating, health check, and execute() body/header/model-override semantics. - docs/adr/0031-bifrost-tier1-router.md (MADR format) — full ADR with context, decision, alternatives considered, consequences, rollout plan, and disambiguation of the three 'bifrost' referents. - docs/frameworks/BIFROST-BACKEND.md (229 lines) — operator-facing usage guide: activation, provider matrix, migration phases, decision review schedule. - worklogs/2026-06-18-L5-110-bifrost-tier1-router.md (226 lines) — session worklog with full research matrix and decision rationale. Updated files: - ADR.md — added ADR-031 entry to top-level index (MADR pointer). - SPEC.md § 3 — Architecture Overview updated to v8.1 (2-tier Bifrost /OmniRoute diagram with Tier-1 = Bifrost + Tier-2 = OmniRoute). - PLAN.md § 2.5 — added v8.1 Bifrost track (B1-B9 with comparison matrix, decision review schedule, owner per task). - docs/ROUTING-CONVERGENCE-STATUS.md — added Tier-1/Tier-2 Router Split section with rationale and drop-in swap phases. - AGENTS.md — added 'Recent Changes (L5-110 Bifrost Tier-1 Router)' section with extended fork-only policy. ### Decision review (per ADR-031) - 30 days post-B6 (traffic shadow at 100%): compare p99 latency, error rate, cost between Bifrost and chatCore. Revert if underperforms by >20% on any axis. - 90 days post-B6: commit long-term (1-year SLT agreement with maximhq) or fork-and-modify. Refs: docs/adr/0031-bifrost-tier1-router.md, PLAN.md § 2.5, SPEC.md § 3, ROUTING-CONVERGENCE-STATUS.md (Tier-1/Tier-2 split), AGENTS.md (L5-110 section).
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
|
Warning Review limit reached
More reviews will be available in 27 minutes and 18 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (47)
Note
|
|
Closing — content was absorbed into main via PR #72 fork cleanup + subsequent PRs. |
|
…rk-main
Fork-only commit. Strategy note: upstream cadence slowed to 1
release every 2-3 weeks. We land changes here first.
Extends chatForkState (PR-κ/λ) with two fork-original helpers:
1. FORK_MODULES: readonly ForkModuleMetadata[]
Self-describing metadata about every fork-original sibling
module. Each entry has:
- name: string ('chatCooldown', 'chatPredicates', etc.)
- description: string (includes PR label for audit trail)
- exportCount: number
- notableExports: readonly string[] (up to 5)
Currently 4 modules:
- chatCooldown (PR-α, 6 exports)
- chatPredicates (PR-δ/ε/θ, 6 exports)
- chatCombosCache (PR-ι, 4 exports)
- chatForkState (PR-κ/λ/μ, 5 exports)
Use cases:
- 'What fork modules are loaded?' debugging
- Dynamic dispatch in future MCP resources / HTTP endpoints
- Self-describing dashboards ('fork modules: 4, exports: 21')
Object.isFrozen() at runtime so callers can't mutate.
2. summarizeForkModules(): ForkModuleSummary
Aggregate helper: { moduleCount, totalExports, modules }.
Module count must be >= 4 and total exports >= 20.
3. pollForkChatState(listener): ForkStatePoller
Pure orchestration helper for fork-state polling. Returns an
unsubscribe handle with:
- tick(): reads latest snapshot + invokes listener
- unsubscribe(): stops the poller (idempotent)
Anti-pattern #77: don't bake setInterval into a snapshot
function. Tests should drive the polling manually, and
production code should control the timing for observability.
Returning an unsubscribe handle makes both cases ergonomic.
Initial fire: the listener is called once immediately on
registration so subscribers get the initial state. Multiple
subscribers receive their own initial fire and tick
independently.
Use cases (fork-original):
1. Self-describing fork-state dashboards
2. Future MCP resources that enumerate fork modules
3. Future HTTP endpoints that expose module metadata
4. Test helpers that drive poll cycles manually
Files:
- src/sse/handlers/chatForkState.ts: +115 lines
- ForkModuleMetadata interface
- ForkModuleSummary interface
- ForkStateListener type
- ForkStatePoller interface
- FORK_MODULES constant (4 entries, ~80 lines)
- summarizeForkModules() function
- pollForkChatState() function (~25 lines)
- src/sse/handlers/__tests__/chatForkState.modules.test.ts:
NEW, 247 lines, 30 tests
- 10 tests for FORK_MODULES (shape, content, uniqueness,
freeze, audit trail via PR labels)
- 6 tests for summarizeForkModules() (counts, references,
thresholds)
- 8 tests for pollForkChatState() (immediate fire, tick,
unsubscribe idempotency, multi-subscriber independence,
cache state reflection)
- 1 integration test for modules + summary + poll
Total: 2 files, +362 lines.
Verification: tsc on focused tsconfig shows pre-existing
errors in PR-α/δ/ε/ζ/η/θ/ι/κ/λ (CooldownAwareRetrySettings
narrowness, module path resolution) that are NOT introduced by
PR-μ. PR-μ's addition is type-clean.
Anti-pattern #77: don't bake setInterval into a snapshot
function. Tests should drive the polling manually, and production
code should control the timing for observability. Returning an
unsubscribe handle makes both cases ergonomic.



User description
Local work-in-progress snapshot pushed 2026-06-18 as part of fleet cleanup. Auto-merge candidates. See meta-repo PR #3 for context.
CodeAnt-AI Description
Adopt Bifrost as an optional tier-1 router and add new A2A skills for cost checks and code dispatch
What Changed
Impact
✅ Safer fallback for unsupported providers✅ Clearer budget checks before expensive requests✅ Shorter path from agent task to code execution✅ Fewer onboarding failures for Antigravity accounts✅ More reliable routing and skill behavior💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.