jfarcand

The OpenClaw Bridge — Full Walkthrough

Why it exists

OpenClaw is a canonical, filesystem-as-source-of-truth workspace convention for AI agents: you author a directory of Markdown files (AGENTS.md, SOUL.md, USER.md, IDENTITY.md, MEMORY.md, memory/YYYY-MM-DD.md, skills/*) and the runtime boots an agent directly from that directory. No YAML manifest, no code, no custom DSL.

The design goal locked in docs/foundation-primitives.md and CHANGELOG.md: an OpenClaw workspace authored without any Atmosphere extensions must run on Atmosphere without conversion. That zero-config promise is the reason the bridge exists. The alternative — "bring your OpenClaw agent, first translate it to an Atmosphere YAML" — would make Atmosphere yet another proprietary format and kill portability.

Where it lives

jfarcand

routes/chat.rs refactor plan

Current state (2026-04-21, main @ 51002216)

File	Lines	Verdict
crates/pierre-server/src/routes/chat.rs	1290	too big — refactor
crates/pierre-server/src/services/chat_pipeline/mod.rs	945	big but cohesive; small extraction worth doing
crates/pierre-database/src/database/chat.rs	643	borderline; one concern (chat DB) so OK
crates/pierre-database/src/plugins/postgres/chat.rs	506	same as above

jfarcand

Atmosphere AI Foundation — critical review of v0.7 / v0.8 gists vs. last 20 commits on main

Reviews the two announcement gists:

• v0.7 — https://gist.github.com/jfarcand/561e1eb12e39baadf0e255d117c4514e
• v0.8 — https://gist.github.com/jfarcand/bfe31239238f1435e2105614bfefca41

…against the last 20 commits on Atmosphere/atmosphere@main (HEAD 9490afc5ae, tag atmosphere-4.0.38).

No cheerleading.

jfarcand

Atmosphere Agent Framework — Deep Code-Level GAP Analysis

Revision 2 — Professional-Grade Source-Code Deep Dive

Date: July 2025 Scope: Atmosphere 4.0.x vs. 18+ agent frameworks (Python, TypeScript, Java, .NET) + personal agents Method: Line-by-line source code reading of Atmosphere + actual GitHub source of competing frameworks

---

jfarcand

Atmosphere 4.0.36-SNAPSHOT — What's New Since 4.0.35

40 commits, 4.0.36-SNAPSHOT. The release is dominated by the Unified @Agent API close-out — a 6-wave roadmap that wired 12 cross-cutting capabilities across all 7 AI runtimes (Built-in, Spring AI, LangChain4j, Google ADK, JetBrains Koog, Embabel, Microsoft Semantic Kernel).

New Features

Unified @Agent API (Phases 0-12, Waves 1-6, Polish)

HITL (Human-in-the-Loop) Unification — Phase 0

• ApprovalStrategy + ApprovalRegistry + ToolExecutionHelper.executeWithApproval() is now the single approval gate across all runtime bridges

jfarcand

Atmosphere Code Review — Issues Fixed

Two external reviews were conducted on the Atmosphere coordinator module and project documentation. This gist summarizes every issue found and how each was resolved.

---

Review 1: Agent/Fleet/Coordinator Architecture

Source: Architecture Review Gist

jfarcand

Atmosphere AI Framework Abstraction — Implementation Summary

Overview

Atmosphere's unified AI abstraction layer sits between @AiEndpoint handlers and the four supported AI frameworks (Spring AI, LangChain4j, Google ADK, Embabel). It provides:

• Tool Calling SPI — @AiTool annotation → framework-agnostic ToolDefinition → native bridges
• Capability Discovery — AiCapability enum + ModelRouter for smart routing/failover
• Conversation Memory — ConversationPersistence SPI backed by Redis or SQLite

jfarcand

Atmosphere AI Framework Abstraction Analysis

Overview

Atmosphere currently integrates with 4 external AI frameworks plus a built-in OpenAI-compatible client:

Framework	Module	Adapter	Request Type
Built-in OpenAI	modules/ai	BuiltInAiSupport	AiRequest
Spring AI	modules/spring-ai	SpringAiStreamingAdapter	ChatRequest

jfarcand

AI Provider Architecture: Two Separate Systems

1. MCP Sampling (Exploration — Active)

Used during generate_skill BFS/DFS exploration for component classification.

• Code: SamplingBridge.swift / SamplingClassifier
• How it works: Sends sampling/createMessage to the MCP client, which forwards it to whatever LLM the client is using (e.g. Claude via Claude Code)
• No API keys needed — the client's own LLM handles it
• Config: componentDetection in settings.json controls the mode:

jfarcand

Plan: Improve Component Calibration & Chevron Resilience

Context

Testing component detection on the Santé (Health) app reveals three problems:

1. Calibration is misleading — it shows per-row matches but not the post-absorption result. ChefFamille sees value rows ("Bouger", "893 cal") classified separately when in reality BFS absorbs them into the summary-card above. The calibration needs to show what BFS actually sees.
2. Calibration is viewport-only — only analyzes visible elements. ChefFamille wants full-page coverage via scrolling.
3. Distance card misses chevron — OCR inconsistently detects ">" next to "11:33" for one card while 3/4 similar cards get it. The hard row_has_chevron: true constraint causes hard failure.

SAM (Segment Anything Model) was considered for bounding-box detection but rejected — too heavy (50-500MB). The existing absorption mechanism (absorbs_below_within_pt: 80) already handles bounding-box suppression correctly; the calibration tool just doesn't show it.