type: project

project: atocore

content: AtoCore roadmap: (1) extractor improvement, (2) harness expansion, (3) Wave 2 ingestion, (4) OpenClaw finish; steps 1+2 are current mini-phase


type: knowledge

content: AtoCore is FastAPI (Python 3.12, SQLite + ChromaDB) on Dalidou home server (dalidou:8100), repo C:\Users\antoi\ATOCore, data /srv/storage/atocore/, ingests Obsidian vault + Google Drive into vector memory system.


content: Deploy AtoCore: git push origin main, then ssh papa@dalidou and run /srv/storage/atocore/app/deploy/dalidou/deploy.sh


type: adaptation

content: Do not add memory extraction to interaction capture hot path; keep extraction as separate batch/manual step. Reason: latency and queue noise before review rhythm is comfortable.


content: As of 2026-04-11, approved roadmap in order: observe reinforcement, batch extraction, candidate triage, off-Dalidou backup, retrieval quality review.


content: AtoCore adopts DEV-LEDGER.md as shared operating memory with stable headers; updated at session boundaries


content: Codex branches for AtoCore fork from main (never orphan); use naming pattern codex/<topic>


content: In AtoCore, Claude builds and Codex audits; never work in parallel on same files


content: In AtoCore, P1-severity findings in DEV-LEDGER.md block further main commits until acknowledged


content: Every AtoCore session appends to DEV-LEDGER.md Session Log and updates Orientation before ending


type: preference

content: User prefers receiving standalone testing prompts they can paste into Claude Code on target deployments rather than having the assistant run tests directly.


content: USB SSD on RPi is mandatory for polishing telemetry storage; must be independent of network for data integrity during runs.


content: Use Tailscale mesh for RPi remote access to provide SSH, file transfer, and NAT traversal without port forwarding.


content: Auto-sync telemetry data via rsync over Tailscale after runs complete; fire-and-forget pattern with automatic retry on network interruption.


content: Real-time telemetry monitoring should target 10 Hz downsampling; full 100 Hz streaming over network is not necessary.


content: Polishing telemetry data rate is approximately 29 MB per hour (100 Hz × 20 channels × 4 bytes = 8 KB/s).


content: Machine spec (shareable) + Atomaste spec (internal) separate concerns. Machine spec hides program generation as 'separate scope' to protect IP/business strategy.


content: Firmware interface contract is invariant: controller-job.v1 input, run-log.v1 + telemetry output. No firmware changes needed regardless of program generation implementation.


content: Atomaste sim spec documents forward/return paths, calibration model (Preston k), translation loss, and service/IP strategy—details hidden from shareable machine spec.


content: USB SSD mandatory for storage (not SD card); directory structure /data/runs/{id}/, /data/manual/{id}/; status.json for machine state


content: RPi joins Tailscale mesh for remote access over SSH VPN; no public IP or port forwarding; fully offline operation


content: Data synchronization via rsync over Tailscale, failure-tolerant and non-blocking; USB stick as manual fallback


content: Machine design principle: works fully offline and independently; network connection is for remote access only


content: No cloud, no real-time streaming, no remote control features in design scope


content: P1: Reflection loop integration incomplete—extraction remains manual (POST /interactions/{id}/extract), not auto-triggered with reinforcement. Live capture won't auto-populate candidate review queue.


content: P1: Project memories excluded from context injection; build_context() requests ["identity", "preference"] only. Reinforcement signal doesn't reach assembled context packs.


content: Current batch-extract rules produce only 1 candidate from 42 real captures. Extractor needs conversational-cue detection or LLM-assisted path to improve yield.


content: Next priority: extractor rule expansion (cheapest validation of reflection loop), then Wave 2 trusted operational ingestion (master-plan priority). Defer retrieval eval harness focus.


content: Alias canonicalization fix (resolve_project_name() boundary) is consistently applied across project state, memories, interactions, and context lookup. Code review approved directionally.


content: Machine capabilities now define z_type: engage_retract and cam_type: mechanical_with_encoder instead of actuator-driven setpoints.


content: Codex is an audit agent; communicate with it via markdown prompts with numbered steps; it updates findings via commits to codex/* branches or direct messages.


content: Audit-first workflow recommended: have codex audit DEV-LEDGER.md and recent commits before execution; validates round-trip, catches errors early.


content: DEV-LEDGER.md at repo root is the shared coordination document with Orientation, Active Plan, and Open Review Findings sections.


content: Roadmap: Extractor improvement → Harness expansion → Wave 2 trusted operational ingestion → Finish OpenClaw integration (in that order)


content: Phase 1 (Extractor): eval-driven loop—label captures, improve rules/add LLM mode, measure yield & FP, stop when queue reviewable (not coverage metrics)


content: Phases 1 & 2 (Extractor + Harness) are a mini-phase; without harness, extractor improvements are blind edits


content: Dalidou stores Claude Code interactions via a Stop hook that fires after each turn and POSTs to http://dalidou:8100/interactions with client=claude-code parameter


content: Interaction capture system is passive and automatic; no manual action required, interactions accumulate automatically during normal Claude Code usage


content: Session Log/Ledger system tracks work state across sessions so future sessions immediately know what is true and what is next; phases marked by git SHAs.


content: atocore uses multi-model coordination: Claude and codex share DEV-LEDGER.md (current state / active plan / P1+P2 findings / recent decisions / commit log) read at session start, appended at session end


content: atocore starts with manual-event-loop (/audit or /status prompts) using DEV-LEDGER.md before upgrading to automated git hooks/CI review


content: atocore development involves coordinating between Claude and codex models with shared plan/review strategy and counter-validation to improve system quality


content: Z-axis is a binary engage/retract mechanism (z_engaged bool), not continuous position control; confirmation timeout z_engage_timeout_s required.


content: Cam amplitude and offset are mechanically set by operator and read via encoders; no actuators control them, controller receives encoder telemetry only.


content: Cam parameters in controller are expected_cam_amplitude_deg and expected_cam_offset_deg (read-only reference for verification), not command setpoints.


content: Manual mode UI displays cam encoder readings (cam_amplitude_deg, cam_offset_deg) as read-only for operator verification of mechanical setting.


content: Manual session log records cam_setting measured at session start; run-log segment actual block includes cam_amplitude_deg_mean and cam_offset_deg_mean.


content: AtoCore deployments to dalidou use the script /srv/storage/atocore/app/deploy/dalidou/deploy.sh instead of manual docker commands


content: Retrieval/extraction evaluation follows 8-day mini-phase plan with hard gates to prevent scope drift. Preflight checks must validate git SHAs, baselines, and fixture stability before coding.


content: Day 1: Create labeled extractor eval set from 30 captures (10 zero-candidate, 10 single-candidate, 10 ambiguous) with metadata; create scoring tool to measure precision/recall.


content: Day 2: Measure current extractor against labeled set, recording yield, true/false positives, and false negatives by pattern.