Compare commits

23 Commits

Author SHA1 Message Date
44a1b43cba release(opencortex): bump submodule to v0.2.0 2026-05-01 21:51:48 -04:00
cb783530e5 refactor(gtd): move OpenCortex tasks to project-local TODO.org
- Slim gtd.org by linking to projects/opencortex/TODO.org
- gtd.org reduced from 1615 to 822 lines (-793)
- OpenCortex tasks now live in projects/opencortex/TODO.org
- Add projects/opencortex/TODO.org to org-agenda-files

Engineering Core and personal tasks remain in gtd.org
2026-05-01 21:46:04 -04:00
0168281c8c fix(opencortex): update submodule with final TUI and harness stability fixes 2026-05-01 18:16:55 -04:00
bef72ed55f refactor(opencortex): update submodule to include harness fixes and mandate centralization 2026-05-01 12:43:25 -04:00
a9be1d99b3 feat(opencortex): tmux TUI testing, unified LLM backend, daemon fixes
Submodule update includes:
- feat(tui): background reader thread, error handling, TERM guard
- feat(llm): unified OpenAI-compatible backend (Ollama/OpenRouter/OpenAI/Anthropic/Groq/Gemini)
- fix(loop): correct .env loading path (.config/opencortex)
- fix(daemon): restart with updated XDG harness files
- fix(reason): add generate-tool-belt-prompt, policy explanation, deterministic gate
2026-04-30 19:58:02 -04:00
d5b62ee642 feat(tui): add background reader, error handling, connection state 2026-04-30 19:53:02 -04:00
f858b86b64 docs(AGENTS): add utils-lisp mandate for Lisp structural operations
- NEW: REPL-first workflow requirement
- NEW: Must use utils-lisp functions for any .lisp work
- NEW: Never use edit tool on .lisp files directly
- NEW: Post-task verification: REPL verified + utils-lisp used
2026-04-30 11:17:45 -04:00
15e45e57e8 refactor: portable tangling with %%SKILLS_DIR%% placeholder 2026-04-30 11:14:32 -04:00
d68bdb2d2f fix: add in-package to REPL skill org 2026-04-30 11:11:41 -04:00
1886b7ed5d refactor: absolute XDG paths for skill tangling 2026-04-30 11:09:48 -04:00
622b85dd94 refactor: XDG tangle paths for skills
- Skills now tangle to $OC_DATA_DIR/skills/ (XDG)
- Removed manually-created .lisp files from repo
2026-04-30 11:09:23 -04:00
4b04266c16 fix(opencortex): harness compile errors resolved
- FIX: copy-org-object -> deep-copy-org-object (struct conflict)
- FIX: malformed char= syntax in reason.lisp
2026-04-30 10:58:23 -04:00
1adc80bcfb docs(gtd): add REPL skill to v0.2.0 roadmap
- Added org-skill-repl as DONE under INTERACTIVE REFINEMENT
- Enables REPL-first workflow with literate reflection in org
2026-04-30 10:54:18 -04:00
213c9f8c90 feat(skills): add org-skill-repl for persistent Lisp evaluation
Enables agent to:
- Evaluate Lisp code with result/output/error separation
- Inspect variables and functions
- List bound variables in package
- Load files into image
- Supports REPL-first workflow with literate reflection in org
2026-04-30 10:54:08 -04:00
492c84f881 chore(memex): add chat notes and lisp check file 2026-04-30 10:52:48 -04:00
cf5f0d13d0 feat(opencortex): v0.2.0 skills consolidation
- NEW: org-skill-utils-lisp (3-phase validation, sandboxed eval, AST tools)
- NEW: org-skill-utils-org (org headline manipulation, property management)
- DELETE: org-skill-lisp-utils, org-skill-emacs-edit (merged)
- ADD: opencortex setup wizard, opencortex doctor command
- ADD: Native TUI with Croatoan
- HARDEN: Skill loader, package jailing fixes
2026-04-30 10:52:27 -04:00
dfa13d359c docs(gtd): seal v0.2.0 roadmap milestones 2026-04-28 19:51:01 -04:00
42e5c9060e docs(inbox): clear release notes 2026-04-28 19:48:59 -04:00
0121082bc6 feat(chaos): seal v0.2.0 with Tier 2/3 validation and TUI fixes 2026-04-28 19:48:59 -04:00
6f548aa7ac fix: resolve TUI syntax errors and color constants 2026-04-28 14:45:11 -04:00
315ef305e9 chore: complete scorched earth bootstrap and seal v0.2.0-pre fixes 2026-04-28 14:08:25 -04:00
aa70766a4f docs(gtd): mark chaos bugfixes as done and update submodule ref 2026-04-28 14:03:03 -04:00
a842f10b35 chore(opencortex): update submodule to latest fix for v0.2.0 2026-04-28 10:46:31 -04:00
10 changed files with 1078 additions and 770 deletions

View File

@@ -105,7 +105,15 @@ This agent MUST verify these conditions before, during, and after each task. Vio
### During Task (Literate Programming)
- [ ] **Org-only edits** — Edit only `.org` files, never generated `.lisp` directly
- [ ] **REPL-first workflow** — Explore in REPL before writing code
- [ ] **Utils-lisp for structural ops** — Use these functions for any .lisp work:
- `utils-lisp-structural-extract` — Extract function definitions
- `utils-lisp-structural-inject` — Inject forms into definitions
- `utils-lisp-structural-wrap` — Wrap code in let/progn
- `utils-lisp-validate` — Validate code before commit
- `repl-eval` — Test code in REPL
- `repl-inspect` — Inspect variables/functions
- [ ] **Never use edit tool on .lisp** — Only edit .org files; never touch generated .lisp directly
- [ ] **One function per block** — Each `#+begin_src` block contains exactly one definition
- [ ] **Prose before code** — Every block preceded by explanatory text
- [ ] **Prose includes**: What the function does, arguments, return value, rationale
@@ -114,6 +122,8 @@ This agent MUST verify these conditions before, during, and after each task. Vio
### After Task (Validation)
- [ ] **REPL verified** — Code tested in REPL before commit (not just text edit)
- [ ] **Utils-lisp used** — Confirmed structural operations went through utils-lisp
- [ ] **Tests pass** — Run full test suite; 100% pass required
- [ ] **Chaos tier 1** — Deterministic regression tests pass
- [ ] **No artifacts** — No orphaned `.bak`, `.log`, `.tmp`, or untracked test files

18
check.lisp Normal file
View File

@@ -0,0 +1,18 @@
(handler-case
(with-open-file (s "/home/user/memex/projects/opencortex/skills/org-skill-config-manager.org")
(loop for line = (read-line s nil)
while line
do (when (search "#+begin_src lisp" line)
(let ((block ""))
(loop for l = (read-line s nil)
while (and l (not (search "#+end_src" l)))
do (setf block (concatenate 'string block l (string #\Newline))))
(handler-case
(with-input-from-string (in block)
(loop for form = (read in nil :eof)
until (eq form :eof)))
(error (c)
(format t "Error in block beginning with ~a: ~a~%"
(subseq block 0 (min 30 (length block)))
c)))))))
(error (c) (format t "General error: ~a~%" c)))

772
gtd.org
View File

@@ -34,770 +34,14 @@
:END:
** NEXT OpenCortex v1.0
:PROPERTIES:
:ID: proj-opencortex-v1-0
:Engineering-STATE: D: BUILD
:CREATED: [2026-03-09 Mon 14:23]
:END:
OpenCortex: A Neurosymbolic AI Agent.
*** PHASE: AUTONOMOUS MVP (v0.1.0 Released)
:PROPERTIES:
:ID: proj-mvp-v0-1-0
:END:
The "Zero-to-One" release. The agent must be mathematically secure, CLI-first, and capable of autonomous Memex maintenance.
**** DONE 1. Harness Hardening (The Final Audit)
***** DONE Audit remaining core skills (`org-skill-policy.org`, `org-skill-bouncer.org`) to the new Literate Granularity standard.
***** DONE Implement Verification Lock: Ensure `MANDATORY_SKILLS` pass `validate-lisp-syntax` before boot proceeds.
***** DONE Logging & Transparency: Ensure `context-get-system-logs` is utilized by the Reason engine to explain blocked actions.
**** DONE 2. The Autonomous Scribe & Gardener (The Primary Value Prop)
***** DONE Implement `org-skill-scribe.org`: Background worker that distills daily chronological logs into structured Zettelkasten notes.
***** DONE Implement `org-skill-gardener.org`: Heartbeat-driven skill that autonomously flags orphaned nodes and repairs broken links.
**** DONE 3. The Zero-to-One Experience (setup.org)
***** DONE Consolidate installation instructions, `onboard.sh`, and `Dockerfile` into a single, literate `setup.org` file.
***** DONE Ensure the setup process interactively builds the `.env` and verifies SBCL/Quicklisp dependencies.
**** DONE 4. CLI-First Actuation
CLOSED: [2026-04-14 Tue 09:40]
***** DONE Verified the `cli` actuator and inbound gateway handle standard I/O interaction gracefully via a stateful `socat` connection.
*** PHASE: PUBLICATION & VERIFICATION (v0.1.0 Post-Release)
:PROPERTIES:
:ID: proj-pub-v0-1-0
:END:
Ensuring the system is ready for the world through collaborative testing, documentation, and licensing.
**** DONE 1. Collaborative End-to-End Testing [2026-04-21 Tue]
CLOSED: [2026-04-21 Tue 17:30]
***** DONE Verified stable foundation at commit `cab0e5a`.
***** DONE Verified boot sequence and bidirectional connectivity.
**** DONE 2. Semantic Reorganization & System Stabilization [2026-04-21 Tue]
CLOSED: [2026-04-21 Tue 18:30]
***** DONE Rename directories: harness/, library/, environment/, infrastructure/.
***** DONE Consolidate Probabilistic engine into reason.lisp.
***** DONE Embed bidirectional CLI logic into opencortex.sh.
***** DONE Stabilize skill engine: 12/12 skills loaded with package jailing.
***** DONE Cleanup legacy documentation and deployment artifacts.
**** DONE 2. Comprehensive Documentation <2026-04-14 Tue>
CLOSED: [2026-04-20 Mon 18:00]
***** DONE Draft `USER_MANUAL.org`: Focus on CLI interaction, installation, and Memex structure.
***** DONE Draft `CONTRIBUTING.org`: Explain Literate Granularity and Skill creation standards.
**** DONE 3. License & Legal Finalization <2026-04-14 Tue>
CLOSED: [2026-04-17 Fri 11:25]
***** DONE Assign the AGPLv3 open-source license.
***** DONE Implement a broad Contributor License Agreement (CLA) process.
***** DONE Update `LICENSE` and `CHANGELOG` accordingly.
**** TODO 4. GitHub Migration & Repository Setup <2026-04-14 Tue>
***** TODO Migrate primary remote to GitHub and configure canonical repository.
***** TODO Set repository topics, badges, issue templates, and CI/CD foundations.
**** TODO 5. Marketing & Social Media Launch <2026-04-14 Tue>
***** TODO Execute PR plan (Reddit, Hacker News, X/Twitter).
***** TODO Create a short, high-quality terminal demo GIF/video of the TUI interaction.
*** PHASE: INTERACTIVE REFINEMENT (v0.2.0 Target)
:PROPERTIES:
:ID: proj-refinement-v0-2-0
:END:
Elevating the user interface from raw shell piping to a high-fidelity, native Lisp experience. Priority: Self-editing is the foundation of all future growth. Full org-mode manipulation makes the agent a true Emacs citizen.
Roadmap basis: Evolutionary roadmap from README.org. Working backwards from SOTA parity.
**** DONE 0. Autonomous Self-Editing Foundation
***** DONE org-skill-lisp-repair (Lisp syntax repair)
- Deterministic: auto-balance parens via paren-counting
- Probabilistic: LLM generates surgical fix on =:syntax-error= events
- Memory rollback on failure
DONE: Now in org-skill-lisp-utils (merged from contrib)
***** DONE org-skill-emacs-edit (full org-mode manipulation)
- Read org buffers, parse AST via org-element
- Create/update/delete headlines, set properties, manage TODO states
- Handle =id:= links and internal links
- Pure Lisp implementation (no Emacs subprocess)
***** DONE Expose Structural AST Editing Tools
- Wrap org-skill-emacs-edit into def-cognitive-tool definitions
- Force LLM to use semantic node updates instead of regex file I/O
***** DONE Implement Reflection Loops
- Feed rejection traces (syntax errors, policy blocks) back to LLM to trigger self-correction
***** DONE Harden Actuators
- Fix path-traversal vulnerabilities in file I/O tools (e.g. :write-file)
- Enforce Merkle-snapshots on all state-modifying actions
***** DONE Implement tool permission tiers (ask/allow/deny)
- Per-tool permission plist stored in org-object
- =generate-tool-belt-prompt= filters denied tools before LLM sees them
- Ask-tier prompts user before execution
***** DONE Implement skill hot-reload (=:reload-skill= tool)
- Swap compiled skill files without breaking active sockets
- Reload skill into jailed package namespace
- DONE: Added :reload-skill, :read-file, :write-file, :replace-string tools
- DONE: Fixed ASDF compilation bug (position tracking issue with :serial t)
- DONE: Added explicit :depends-on declarations to opencortex.asd
**** DONE Engineering Process Improvements [2026-04-23 Wed]
***** DONE Fix ASDF compilation bug (position tracking at byte 16834)
- Root cause: Duplicate proto-get, bt: prefix issues, :serial t position cache
- Fix: Removed duplicate, fixed bt:->bordeaux-threads, explicit dependencies
- Added eval-when wrapper for new tools (good Lisp practice)
***** DONE Add test-first methodology to engineering standards
- Rule 10: Test-first - design tests before coding, run chaos testing
- Rule 11: Org as thinking medium - document investigations in prose
- Rule 12: Engineering decision audit trail - document root cause, tradeoffs
- Added to opencortex-contrib/skills/org-skill-engineering-standards.org
***** DONE Perform comprehensive architectural review and evolution strategy [2026-04-27 Mon]
- Identified hidden gaps: Org-mode round-trip, sandboxing vulnerabilities, and GC scaling.
- Defined "Structural AST Editing" and "Reflection Loops" as core strategic requirements.
- Captured findings in [[file:notes/opencortex-architectural-evolution.org][opencortex-architectural-evolution.org]].
***** DONE Fix API drift in opencortex-contrib [2026-04-27 Mon]
- Standardized legacy keywords (:neuro/:symbolic) to new harness standard (:probabilistic/:deterministic).
- Updated 16 skills in opencortex-contrib for kernel compatibility.
**** DONE 4. Core Skills Consolidation [2026-04-23 Thu]
- Merged lisp-validator + lisp-repair → org-skill-lisp-utils.org
- Added lisp utilities: count-char, deterministic-repair, neural-repair
- Added validation: structural, syntactic, semantic checks
- Moved org-skill-self-fix from contrib → core
- Moved org-skill-engineering-standards from contrib → core
- Deleted old org-skill-lisp-validator.org
**** TODO 5. Advanced CLI Onboarding Experience
***** TODO Implement interactive Lisp CLI wizard (=opencortex setup=)
***** TODO Implement =opencortex link <gateway>= for Telegram/Signal bot connection
***** TODO Implement =opencortex doctor= for environment health and API key validation
***** TODO Implement =opencortex install <skill>= for dynamic skill downloading
**** TODO 1. Common Lisp TUI Implementation
***** TODO Integrate =croatoan= for native terminal rendering
***** TODO Implement scrollable history viewport for chat and thought streams
***** TODO Implement fixed bottom input box with multi-line support and command history
***** TODO Implement persistent status bar for background workers (Scribe/Gardener)
***** TODO Support syntax highlighting for Lisp code blocks and Org-mode syntax
**** TODO 2. Slash Commands & Interactive Control
***** TODO Implement =/help= command for system overview
***** TODO Implement =/exit= and =/clear= commands
***** TODO Implement =/skill-load <name>= for dynamic hot-reloading
***** TODO Implement =/status=, =/config=, =/search=, =/commit= slash commands
**** TODO 3. Direct Lisp-to-Terminal Actuation
***** TODO Refactor the =:cli= actuator to use native TUI rendering
*** PHASE: EVENT ORCHESTRATION + HITL (v0.3.0)
:PROPERTIES:
:ID: proj-orchestration-v0-3-0
:END:
Unified control plane: hooks + cron + routing in one skill. Deep project understanding.
**** TODO 0. Event Orchestrator (unified hooks+cron+routing)
***** TODO Integrate contrib org-skill-event-orchestrator
- Merge *hook-registry* + *cron-registry* + complexity classifier
- Hooks via =#+HOOK:= Org-mode properties
- Three complexity tiers: =:REFLEX= (no LLM), =:COGNITION= (light LLM), =:REASONING= (full LLM)
- Hook into heartbeat for cron processing
**** TODO 1. Context Manager (project scoping)
***** TODO Integrate contrib org-skill-context-manager
- Stack-based context with =push-context= / =pop-context=
- Path resolution relative to current context
- Memory scope: =:scope= property on org-objects (memex/session/project)
- Implement lazy-loading proxies for large-scale memory traversal (offload cold nodes to disk)
**** TODO 2. Model-Tier Routing (cost optimization)
***** TODO Extend =*model-selector-fn= for complexity-based routing
- Heartbeats → smallest model
- User input → medium model
- Complex reasoning → large model
- Source: GBrain sub-agent model routing
**** TODO 3. Memory Scope Segmentation
***** TODO Extend org-object with =:scope= property
- =:memex= (permanent knowledge)
- =:session= (ephemeral context)
- =:project= (scoped to current work)
- Scope-aware retrieval in memory.lisp
**** TODO 4. Asynchronous Embedding Gateway
***** TODO Implement provider-agnostic org-skill-embedding-gateway
- Support Ollama, llama.cpp, and OpenAI based on .env config
- Implement lazy-loading: edits mark nodes as =:vector :pending=
- Background worker thread batches pending nodes and updates Merkle tree silently
**** TODO 4. Slash Commands (TUI ergonomics)
***** TODO M-x style command palette
***** TODO /- prefix for command mode
***** TODO Commands defined in Org-mode
*** PHASE: LONG-HORIZON PLANNING + GIT WORKFLOWS (v0.4.0)
:PROPERTIES:
:ID: proj-planning-v0-4-0
:END:
Multi-step task mastery, structured tracking with failure handling and course correction.
**** TODO 0. Long-Horizon Planning (task tree DAG)
***** TODO Implement org-skill-long-horizon
- Decompose complex tasks into Org-mode headline trees
- Terminal states: =:todo==:next-action==:in-progress==:done= / =:blocked= / =:stuck=
- Parent summarises child results
- Branch pruning when paths fail
- Source: Claude Code ULTRAPLAN (reimplemented in Lisp)
**** TODO 1. Git Steward (version control integration)
***** TODO Integrate contrib org-skill-git-steward
- Status, diff, commit, push, branch operations
- Policy: commit-before-modify gate (from contrib engineering-standards)
- Log commits to memory
**** TODO 2. TDD Runner Integration
***** TODO Integrate contrib org-skill-tdd-runner
- Run FiveAM tests on file save
- Inject =:test-failure= event on red
- Hook into self-fix for auto-repair proposals
**** TODO 3. Deep Emacs Integration
***** TODO Full org-agenda awareness
- Navigate, clock time, refile, archive
- Uses org-element + org-id
*** PHASE: INTERACTIVE ACTUATION & ENVIRONMENT STEWARDSHIP (v0.5.0)
:PROPERTIES:
:ID: proj-actuation-v0-5-0
:END:
Interactive terminal sessions and autonomous dependency management.
**** TODO 0. Interactive PTY Actuator
***** TODO Stream long-running process output to the context window (e.g., `npm run dev`, REPLs)
***** TODO Implement async interrupt control (Ctrl+C emulation)
**** TODO 1. The Environment Steward
***** TODO Autonomously detect missing dependencies (e.g., "Command not found")
***** TODO Propose an installation command and retry the failed action
*** PHASE: CREATOR + ARCHITECT + GTD (v0.6.0)
:PROPERTIES:
:ID: proj-creator-v0-5-0
:END:
Agent bootstraps itself: creates skills autonomously, designs projects from PRDs, tracks work.
**** TODO 0. Skill Creator (autonomous skill generation)
***** TODO Integrate contrib org-skill-creator
- LLM drafts complete skill org-file from natural language
- Mandatory: syntax validation → jail-load → test → register
**** TODO 1. Architect Agent (PRD → PROTOCOL)
***** TODO Integrate contrib org-skill-architect
- Scan =:STATUS: FROZEN= PRDs
- Generate Phase B PROTOCOL from Phase A
- Write to same file
**** TODO 2. GTD Integration (project tracking)
***** TODO Integrate contrib org-skill-gtd
- Full GTD cycle: capture, clarify, organize, reflect, engage
- org-gtd v4.0 DAG (=:TRIGGER:=, =:BLOCKER:=)
**** TODO 3. Consensus Loop (multi-model agreement)
***** TODO Integrate contrib org-skill-consensus
- Run multiple providers for critical decisions
- Compare results, detect disagreements
- Confidence scoring
**** TODO 4. Web Research (Playwright browsing)
***** TODO Integrate contrib org-skill-playwright + org-skill-web-research
- Headless Chromium via Python bridge
- Text extraction and screenshots
- Gemini Web UI automation
**** TODO 5. Memex Management (PARA lifecycle)
***** TODO Integrate contrib org-skill-memex + org-skill-workspace-manager
- Archive DONE tasks, suggest refiling
- Detect orphaned nodes
- PARA/Zettelkasten maintenance
*** PHASE: VISUAL GROUNDING & MCP BRIDGE (v0.7.0)
:PROPERTIES:
:ID: proj-vision-v0-7-0
:END:
Multimodal visual interaction and ecosystem-wide tool compatibility.
**** TODO 0. Computer Use / Vision
***** TODO Allow the agent to request host OS or browser screenshots
***** TODO Analyze UI and issue precise X/Y coordinate click/type commands via an X11/Wayland bridge
**** TODO 1. MCP Gateway Bridge
***** TODO Build a Lisp-native client for the Model Context Protocol
***** TODO Connect OpenCortex to external tools and data sources
*** PHASE: THE EVALUATION HARNESS (v0.8.0)
:PROPERTIES:
:ID: proj-eval-v0-8-0
:END:
Automated benchmarking to mathematically prove the agent's reasoning capabilities.
**** TODO 0. SWE-Bench Harness
***** TODO Automated pipeline that clones repositories and feeds GitHub issues
***** TODO Track multi-step resolution trajectory, run tests, and score success
*** PHASE: SOTA PARITY (v1.0.0)
:PROPERTIES:
:ID: proj-sota-v1-0-0
:END:
Feature-complete agent competitive with commercial agents. All borrowed concepts reimplemented in pure Lisp.
All features from v0.2.0 through v0.8.0 combined, verified, and tested end-to-end.
| Area | Parity Target |
|------|--------------|
| Self-improvement | Claude Code self-debug |
| Planning | ULTRAPLAN equivalent |
| Tool ecosystem | 10+ cognitive tools |
| Context window | Semantic search + scope segmentation |
| Safety | 6 Policy invariants + formal verification |
| Multi-step tasks | Task trees with terminal states |
| Code editing | Full file read/write via org manipulation |
| Memory | Vector recall in org-object |
| Emacs integration | Full org-mode control (exceeds Claude Code) |
| Autonomy | 100% local capable (exceeds Claude Code) |
*** PHASE: LISP MACHINE EMERGENCE (v2.0.0)
:PROPERTIES:
:ID: proj-lisp-v2-0-0
:END:
From Lisp-using agent to true Lisp machine. Agent IS the Emacs process.
**** TODO Lish: Lisp editor as Org-mode IDE
- Org-babel for interactive Lisp evaluation
- Full REPL in TUI
- No bridge needed — direct memory access
**** TODO Lish: Shell replacement
- Lisp-based shell that speaks plists
- Org-mode buffers as file system
- No bash dependency
*** PHASE: NEUROSYMBOLIC MATURITY (v3.0.0)
:PROPERTIES:
:ID: proj-neuro-v3-0-0
:END:
Deterministic planner takes the wheel. LLM relegated to semantic translation.
**** TODO Deterministic planner
- Planner as pure Lisp function
- No LLM needed for scheduling
- Generates task graphs without probabilistic inference
**** TODO Self-correcting gates
- Gates learn from false positives (user override patterns)
- Adaptive threshold adjustment
*** PHASE: AI STACK INTERNALIZED (v4.0.0)
:PROPERTIES:
:ID: proj-ai-v4-0-0
:END:
The agent understands its own weights. No external inference.
**** TODO Llama.cpp in Lisp
- FFI binding to llama.cpp
- No Python subprocess
- Pure Common Lisp inference
**** TODO Weights as sexps
- Neural weights represented as Lisp data structures
- Homoiconic model introspection
*** PHASE: TRUE AGENCY (v5.0.0)
:PROPERTIES:
:ID: proj-agency-v5-0-0
:END:
World models, temporal reasoning, goal persistence across restarts.
**** TODO World models
- Agent builds predictive models of user behavior
- Project dynamics awareness
- System state forecasting
**** TODO Temporal reasoning
- Scheduling and deadline awareness
- Elapsed duration tracking
- Calendar integration
**** TODO Goal persistence
- Goals survive restarts
- Long-term projects tracked in org-objects
- Cross-session continuity
*** PHASE: EVOLUTIONARY ROADMAP (Previous — Superseded by Critical Analysis)
:PROPERTIES:
:ID: proj-old-roadmap
:END:
Superseded by the critical analysis-informed roadmap above (v0.2.0 through v5.0.0). This section kept for historical reference.
**** TODO v0.1.0: The Autonomous Foundation (Current Release) — Now COMPLETE
**** TODO v1.0.0 (Phase 2.5): The Verified Wrapper (SOTA Parity) — Now v1.0.0
**** TODO v2.0.0 (Phase 3): Cannibalizing the Toolchain — Now v2.0.0
**** TODO v3.0.0 (Phase 4): True Symbolic Determinism — Now v3.0.0
*** PHASE: FOUNDATION (Complete)
**** DONE Draft Swank/Socket communication protocol between CL and Emacs
:PROPERTIES:
:CREATED: [2026-03-22 Sun 14:00]
:ASSIGNED: Agent
:END:
**** DONE Implement core Perceive-Think-Act loop in Common Lisp
:PROPERTIES:
:CREATED: [2026-03-22 Sun 14:00]
:ASSIGNED: Agent
:END:
**** DONE Implement Persistent Object-Store for Org entities in CL
:PROPERTIES:
:CREATED: [2026-03-22 Sun 16:30]
:ASSIGNED: Agent
:END:
**** DONE Implement LLM Connector (Probabilistic Engine) in CL Daemon
:PROPERTIES:
:CREATED: [2026-03-22 Sun 17:30]
:ASSIGNED: Agent
:END:
**** DONE Design Deterministic Engine Heuristics (Lisp logic over Memory)
:PROPERTIES:
:CREATED: [2026-03-22 Sun 17:30]
:END:
**** DONE Achieve Phase 3: The Self-Editing Kernel
:PROPERTIES:
:CREATED: [2026-03-23 Mon 16:30]
:END:
- Jailing & Sandboxing implemented
- Org-Native Skill Standard established
- Telemetry & Introspection API active
*** PHASE: THE SOVEREIGN BOUNDARY (Core vs Skills Refactor)
:PROPERTIES:
:ID: proj-autonomous-boundary
:END:
Slim down the opencortex microharness by moving non-essential cognitive functions to hot-reloadable user-space skills.
**** DONE Extract LLM Provider Routing to a Skill (neuro.lisp)
**** DONE Extract Vector Embedding Algorithms to a Skill (embedding.lisp)
CLOSED: [2026-04-12 Sun 14:10]
:PROPERTIES:
:ID: extract-embedding-skill
:END:
- Created `org-skill-embedding.org`.
- Moved logic to `src/embedding-logic.lisp` via tangling.
- Updated `system-definition.org`.
**** DONE Extract Sparse Tree Context Pruning Strategies to a Skill (context.lisp)
CLOSED: [2026-04-12 Sun 14:25]
:PROPERTIES:
:ID: extract-context-skill
:END:
- Created `org-skill-peripheral-vision.org`.
- Moved logic to `src/context-logic.lisp` via tangling.
- Updated `system-definition.org`.
**** DONE Implement `org-skill-peripheral-vision` (Moving embedding logic out of core)
CLOSED: [2026-04-12 Sun 14:25]
:PROPERTIES:
:ID: impl-peripheral-vision
:END:
**** DONE Implement communication protocol Schema Validation (Prevent reader macro injection in communication.lisp)
CLOSED: [2026-04-12 Sun 14:45]
:PROPERTIES:
:ID: communication-protocol-schema-validation
:END:
- Created `org-skill-protocol-validator.org`.
- Integrated `validate-communication-protocol-schema` into `communication.org`.
- Added `protocol-validator.lisp` to system definition.
**** DONE Implement Pluggable communication protocol Integrity Hashing (Core interface, Skill-based algorithms)
CLOSED: [2026-04-12 Sun 15:15]
:PROPERTIES:
:ID: communication-protocol-integrity-hashing
:END:
- Integrated HMAC-SHA256 (`ironclad:make-mac`) in `literate/communication.org`.
**** DONE Implement Native Lisp Merkle-Tree Versioning (Short-term undo buffer in memory.lisp)
CLOSED: [2026-04-12 Sun 19:15]
**** DONE Performance: Implement Copy-on-Write (CoW) or Persistent Data Structures for Memory
CLOSED: [2026-04-12 Sun 19:15]
**** DONE Feature: Implement Latent Reflection (Proactive Gardening) using heartbeat idle cycles
CLOSED: [2026-04-12 Sun 19:15]
**** DONE Simplification: Refactor Cognitive Cycle into a Unified Reactive Signal Pipeline
CLOSED: [2026-04-12 Sun 19:15]
**** DONE Resilience: Implement Micro-Rollbacks for the Immune System
CLOSED: [2026-04-12 Sun 19:15]
**** DONE Implement `org-skill-memory-archivist` (Long-term IPFS checkpointing and P2P sync)
CLOSED: [2026-04-12 Sun 19:15]
**** DONE Implement True Lisp Sandboxing (eval-safe mechanism in core and policy in skills)
CLOSED: [2026-04-12 Sun 19:15]
**** DONE Decouple Vendor Logic from Probabilistic Engine (Move Google/Anthropic/OpenAI to Skills)
CLOSED: [2026-04-12 Sun 19:15]
**** DONE Component IV: Comprehensive Core Skill Audit (Review all 39 skills)
CLOSED: [2026-04-12 Sun 19:45]
:PROPERTIES:
:ID: core-skill-audit-task
:END:
**** DONE Consolidation I: Unified LLM Gateway (Anthropic, Gemini, Groq, OpenAI, etc.)
**** DONE Consolidation II: Credentials Vault (Secure Enclave & Masked Logging)
**** DONE Consolidation III: Homoiconic Memory (Unified Grammar, Bridge, & ID Generation)
**** DONE Consolidation IV: State Persistence Layer (Unified Local & IPFS Checkpointing)
**** DONE Consolidation V: Event Orchestrator (Unified Cron, Hooks, & Cognitive Routing)
**** DONE Consolidation VI: Task Orchestrator (Task Integrity, Delegation, & Consensus)
CLOSED: [2026-04-11 Sat 13:45]
:PROPERTIES:
:ID: task-orchestrator-consolidation
:END:
- Implemented Parallel Multi-Backend Consensus in neuro.lisp.
- Implemented Task Integrity (GTD semantics) in symbolic.lisp.
- Integrated Consensus Gate and Delegation hooks in core.lisp.
- Verified with new task-orchestrator-tests.lisp.
**** DONE Implement Unified Envelope Architecture & Channel-Awareness
CLOSED: [2026-04-20 Mon 13:20]
- Removed specialized :CHAT type; reverted to semantic :REQUEST/:EVENT protocol.
- Decoupled routing metadata into a :META envelope (SOURCE, SESSION-ID).
- Updated TUI, Emacs, and CLI gateways to use the unified protocol.
- Verified end-to-end loop with TUI; kernel correctly routes responses back to origin interface.
- Achieved "Equality of Clients" mandate.
**** IN-PROGRESS Full review of opencortex's harness
:PROPERTIES:
:CREATED: [2026-04-13 Mon 13:30]
:ASSIGNED: Agent
:END:
- [X] Audit terminology: Replaced OACP with "communication protocol" workspace-wide.
- [X] Audit boot sequence: Synchronized loader with `org-skill-policy.org`.
- [X] Implement Unified Envelope (Channel-Aware Routing).
- [-] Audit core Perceive-Think-Act loop.
- [X] Verified protocol framing and reader jailing (`*read-eval* nil`).
- [X] Refactored `loop.org` for literate granularity and configuration externalization.
- [X] Improved error handling (restricted rollback) and added graceful shutdown.
- [X] **FIXED:** Implemented symbolic guard check in `act-gate` via Bouncer skill refactoring.
- [X] **FIXED:** Harness `deterministic-verify` now correctly respects skill triggers.
- [X] Ensure alignment with System Policy and Engineering Standards.
- [X] Restored structural integrity by fixing `manifest.org` loading sequence.
**** TODO Wake up the Scribe (Implement autonomous weekly Journal-to-Ledger distillation in org-skill-scribe.org)
**** TODO Implement `org-skill-lisp-repair` (Self-correcting syntax gate for Deterministic Engine)
CLOSED: [2026-04-11 Sat 15:10]
:PROPERTIES:
:ID: lisp-repair-gate
:END:
- Implemented asynchronous, event-driven repair logic.
- Decoupled core from repair logic (emits `:syntax-error` event).
- Proven via lisp-repair-tests.lisp (Asynchronous flow verified).
**** DONE Implement `org-skill-formal-verification` (Prove safety of high-impact actions)
CLOSED: [2026-04-11 Sat 18:15]
:PROPERTIES:
:ID: formal-verification-task
:END:
- Implemented `org-skill-formal-verification.org`.
- Created Lisp-Native Symbolic Prover for security invariants.
- Implemented `path-confinement` invariant (restricted to memex root).
- Implemented `no-network-exfil` invariant (blocking nc, ssh, etc).
- Verified with `formal-verification-tests.lisp`.
*** PHASE: DETERMINISTIC ENGINE REFINEMENT
**** DONE Verify Autonomous Self-Fix Loop
CLOSED: [2026-04-11 Sat 14:20]
:PROPERTIES:
:CREATED: [2026-03-23 Mon 16:30]
:END:
- Proven repair capability via self-fix-tests.lisp.
- Verified surgical code patching and hot-reloading.
- Documentation and RCA complete.
**** DONE Implement "Planning Mode" (Deterministic Engine Bouncer) for Complex Actions
CLOSED: [2026-04-11 Sat 15:30]
:PROPERTIES:
:CREATED: [2026-04-01 Wed 17:00]
:END:
- Implemented `bouncer-check` interceptor in `symbolic.lisp`.
- Created `org-skill-bouncer.org` for flight plan serialization.
- Verified asynchronous Org-native approval loop via `bouncer-tests.lisp`.
**** DONE Implement Authorization Gate (communication protocol) for "Planning Mode"
CLOSED: [2026-04-11 Sat 15:30]
:PROPERTIES:
:CREATED: [2026-04-01 Wed 17:00]
:END:
- Integrated with Org-mode state transitions (`PLAN` -> `APPROVED`).
- Leveraged Memory event bus for asynchronous re-injection.
**** DONE Refactor Architecture Terminology (Associative -> Probabilistic, Deliberate -> Deterministic)
CLOSED: [2026-04-12 Sun 21:00]
:PROPERTIES:
:ID: terminology-refactor-task
:END:
- Updated codebase-wide terminology to use Probabilistic/Deterministic Engines.
- Replaced System 1/2 with Probabilistic/Deterministic Engines respectively.
**** DONE Refactor org-skill-policy.org: Concrete Invariants, Conflict Hierarchy, and Auditable Gate
CLOSED: [2026-04-22 Wed 11:50]
:PROPERTIES:
:ID: policy-refactor-concrete-invariants
:END:
- Added explicit Override Hierarchy (Transparency > Autonomy > Bloat > Mentorship > Sustainability).
- Implemented `policy-check-transparency`: blocks user-facing actions without :explanation.
- Implemented `policy-check-autonomy`: flags proprietary domain references as autonomy debt.
- Implemented `policy-check-bloat`: warns on :create-skill actions exceeding size threshold.
- Implemented `policy-check-mentorship`: blocks high-impact actions missing :mentorship-note.
- Implemented `policy-check-sustainability`: logs cloud-provider usage as sustainability debt.
- Implemented `policy-explain`: formats auditable rationale for every policy decision.
- Implemented `policy-find-engineering-standards-gate`: robust cross-package search for standards skill.
- Hardened `policy-deterministic-gate`: never returns NIL silently; always returns action or auditable log.
- Raised skill priority from 100 to 500 to ensure it runs before other deterministic gates.
**** DONE Add Invariant 6 (Modularity) and Harness Boundary Contract to Policy/Manifest
CLOSED: [2026-04-22 Wed 12:10]
:PROPERTIES:
:ID: policy-modularity-invariant
:END:
- Added Modularity as Invariant 6 in `org-skill-policy.org`: general life principle that complexity must live at the edges.
- Implemented `policy-check-modularity`: blocks modifications to protected core paths unless `:modularity-justification` is provided.
- Defined `*modularity-protected-paths*` as project-configurable variable (defaults: harness/, opencortex.asd).
- Updated Override Hierarchy to include Modularity between Bloat and Mentorship.
- Added Harness Boundary Contract section to `harness/manifest.org` documenting primary boundary files and generated artifacts.
- Converted checkbox sub-tasks to hierarchical TODO headlines in gtd.org per GTD standard.
**** DONE Implement `org-skill-lisp-validator` (3-phase deterministic validation gate)
CLOSED: [2026-04-22 Wed 12:30]
:PROPERTIES:
:ID: lisp-validator-implementation
:END:
- Created 3-phase validation pipeline: Structural (O(n) paren scanner), Syntactic (reader with *read-eval* nil), Semantic (whitelist AST walk).
- Implemented `lisp-validator-validate` returning structured plists for machine parsing.
- Exposed `:validate-lisp` cognitive tool for Probabilistic Engine self-correction.
- Replaced `validate-lisp-syntax` in `harness/skills.org` with delegation to the validator.
- Added mandatory validation rule to Probabilistic Engine system prompt in `harness/reason.org`.
- Fixed paren balance and `return-from` compilation errors in org source; tangled and validated in SBCL.
**** DONE Fix Skill Loader to Respect `:tangle` Blocks and Eliminate Circular Dependency
CLOSED: [2026-04-22 Wed 12:45]
:PROPERTIES:
:ID: skill-loader-tangle-fix
:END:
- Updated `load-skill-from-org` in `harness/skills.org` to only collect blocks with `:tangle` directives pointing to runtime `.lisp` files, excluding `tests/` and `test/` paths.
- Added fallback to `validate-lisp-syntax` so it uses a basic reader check when `lisp-validator-validate` is not yet loaded (breaks circular harness->skill dependency).
- Verified full boot: 13/13 skills loaded successfully into SBCL, including `skill-lisp-validator` at priority 900 and `skill-policy` at priority 500.
*** TRACK: SECURITY & CONTAINMENT (The 5-Vector Bouncer Matrix)
**** DONE Implement Path-Based Scoping for File Writes (DNA/State vs Work)
CLOSED: [2026-04-12 Sun 15:15]
:PROPERTIES:
:ID: path-based-scoping
:END:
- Implemented as `path-confinement` invariant in `org-skill-formal-verification.org`.
**** DONE Implement Network Exfiltration Gate (Intercept generic HTTP requests)
CLOSED: [2026-04-12 Sun 15:15]
:PROPERTIES:
:ID: network-exfiltration-gate
:END:
- Implemented as `no-network-exfil` invariant in `org-skill-formal-verification.org`.
**** TODO Implement Secret Exposure Gate (Intercept reads to .env, keys)
*** TRACK: INTELLIGENCE & ACTUATION (The Engines)
**** DONE Verify individual provider track (Anthropic, Gemini, Groq, OpenAI, OpenRouter, Ollama)
CLOSED: [2026-04-11 Sat 15:45]
:PROPERTIES:
:ID: provider-verification-track
:END:
- Added unit tests for each provider in `llm-gateway-tests.lisp`.
- Mocked `dex:post` to verify JSON payload formatting and response parsing.
- Implemented robust `get-nested` helper to handle various provider structures.
- Integrated `llm-gateway` and `credentials-vault` into `opencortex.asd`.
**** TODO Verify org-skill-shell-actuator formal safety harnesses
**** DONE Build Playwright-Python Bridge for high-fidelity browsing
CLOSED: [2026-04-11 Sat 18:30]
:PROPERTIES:
:ID: playwright-bridge-task
:END:
- Created `scripts/browser-bridge.py` (Playwright wrapper).
- Implemented `org-skill-playwright.org`.
- Registered `:browser` cognitive tool (JS-rendering, text extraction, screenshots).
- Updated `Dockerfile` with Python/Playwright dependencies.
- Verified with `playwright-tests.lisp`.
*** TRACK: COMMUNICATION & INTERFACES
**** DONE Implement org-skill-gateway-telegram
CLOSED: [2026-04-11 Sat 16:15]
:PROPERTIES:
:ID: gateway-telegram-task
:END:
- Implemented `org-skill-gateway-telegram.org`.
- Added automated background polling for Telegram GetUpdates.
- Implemented `:telegram` actuator for outbound responses.
- Refactored `org-skill-chat` to be channel-aware.
- Verified with `gateway-telegram-tests.lisp`.
**** DONE Implement org-skill-gateway-signal
CLOSED: [2026-04-11 Sat 16:50]
:PROPERTIES:
:ID: gateway-signal-task
:END:
- Implemented `org-skill-gateway-signal.org` (signal-cli wrapper).
- Added background polling for `signal-cli receive --json`.
- Implemented `:signal` actuator for outbound responses.
- Updated `org-skill-chat` to support Signal channel.
- Verified with `gateway-signal-tests.lisp`.
**** DONE Implement org-skill-gateway-matrix
CLOSED: [2026-04-11 Sat 17:15]
:PROPERTIES:
:ID: gateway-matrix-task
:END:
- Implemented `org-skill-gateway-matrix.org` (Client-Server API).
- Added background polling for `/sync` with token persistence.
- Implemented `:matrix` actuator for `m.room.message` delivery.
- Updated `org-skill-chat` to support Matrix channel and room IDs.
- Verified with `gateway-matrix-tests.lisp`.
*** TRACK: DEPLOYMENT & INFRASTRUCTURE
**** DONE Create Dockerfile and docker-compose.yml for containerized setup
CLOSED: [2026-04-11 Sat 17:30]
:PROPERTIES:
:ID: docker-infra-task
:END:
- Created `Dockerfile` (Debian-based, SBCL + Quicklisp + signal-cli).
- Created `docker-compose.yml` with host-volume mapping for memex.
- Created `docs/deployment.org` guide.
**** TODO Create Bare Metal installation scripts/playbooks
**** TODO Create LXC (Linux Containers) template/guide
**** TODO Create VM Vagrantfiles/Cloud-init configs
*** TRACK: MAINTENANCE & HYGIENE
**** TODO [RECURRING: Monthly] Review and test Infrastructure Dependency Upgrades
:PROPERTIES:
:ID: monthly-infra-audit
:REPEAT_TO_STATE: TODO
:END:
***** TODO Check for new Debian security patches (`apt-get update` check)
***** TODO Check for new `signal-cli` releases (compare vs v0.14.0)
***** TODO Check for new Quicklisp distribution (monthly snapshot)
***** TODO Verification: Update `Dockerfile`, run `docker-compose build --no-cache`, and execute full test suite
***** TODO If all tests pass, commit updated `Dockerfile` and `.asd` dependencies
*** TRACK: COMMUNITY & DOCS
**** TODO Write Quickstart Guide
**** TODO Write Skill Creation Guide
**** TODO Write Architecture Deep-Dive
**** TODO Clean up GitHub repository structure and add CI/CD
**** TODO Create Marketing Material (Landing page copy, diagrams)
**** TODO Draft Release Plan checklist
*** SUB-PROJECT: THE BOOT SEQUENCE (skills.lisp)
:PROPERTIES:
:ID: proj-skill-boot-sequence
:END:
**** DONE Refactor `skills.lisp` into a Micro-Loader (Harness)
CLOSED: [2026-04-12 Sun 19:10]
**** DONE Implement Topological Sort based on `#+DEPENDS_ON:` tags
CLOSED: [2026-04-12 Sun 15:15]
:PROPERTIES:
:ID: topological-sort-skills
:END:
- Implemented in `literate/skills.org`.
**** DONE Enforce `org-skill-system-invariants` as the mandatory Gateway Skill (Loaded first)
CLOSED: [2026-04-12 Sun 15:15]
:PROPERTIES:
:ID: enforce-mandatory-skill
:END:
- Enforced in `initialize-all-skills` in `literate/skills.org`.
**** DONE Formalize the "Minimal Boot Set" (Router, Vision, Steward, Actuator)
CLOSED: [2026-04-12 Sun 19:10]
- Verified during the Minimal Boot Set Verification phase.
:PROPERTIES:
:ID: proj-opencortex-v1-0
:Engineering-STATE: D: BUILD
:CREATED: [2026-03-09 Mon 14:23]
:END:
OpenCortex: A Neurosymbolic AI Agent.
Full project tasks: [[file:projects/opencortex/TODO.org][OpenCortex TODO.org]]
** NEXT Engineering Core: Role Automation
:PROPERTIES:

View File

@@ -311,3 +311,38 @@ This is the inbox. Everything goes in here when you capture it.
:CREATED: [2026-04-27 Mon 09:25]
:END:
* [[https://arxiv.org/abs/2604.22709][[2604.22709] Thinking Without Words: Efficient Latent Reasoning with Abstract Chain-of-Thought]]
:PROPERTIES:
:TITLE: [2604.22709] Thinking Without Words: Efficient Latent Reasoning with Abstract Chain-of-Thought
:URI: https://arxiv.org/abs/2604.22709
:CREATED: [2026-04-28 Tue 09:50]
:END:
* [[https://x.com/i/status/2048587253145108626][鸟哥 | 蓝鸟会🕊️ on X: "吓到我了! GitHub上有个工具叫GhostTrack输入一个手机号能直接扫出这人在哪些平台注册过账号还能查IP定位、运营商信息。 克隆代码跑脚本5分钟搞定门槛低得离谱。你以为自己在网上隐身呢 早被扒得透透的了。信息安全这事,真得重视起来。 🔗 https://t.co/yVGCsmsjyi https://t.co/UyhOY6wHq6" / X]]
:PROPERTIES:
:TITLE: 鸟哥 | 蓝鸟会🕊️ on X: "吓到我了! GitHub上有个工具叫GhostTrack输入一个手机号能直接扫出这人在哪些平台注册过账号还能查IP定位、运营商信息。 克隆代码跑脚本5分钟搞定门槛低得离谱。你以为自己在网上隐身呢 早被扒得透透的了。信息安全这事,真得重视起来。 🔗 https://t.co/yVGCsmsjyi https://t.co/UyhOY6wHq6" / X
:URI: https://x.com/i/status/2048587253145108626
:CREATED: [2026-04-28 Tue 09:50]
:END:
* [[https://uxdesign.cc/where-should-ai-sit-in-your-ui-1710a258390e][Where should AI sit in your UI?. Mapping emerging AI UI patterns and how… | by Sharang Sharma | UX Collective]]
:PROPERTIES:
:TITLE: Where should AI sit in your UI?. Mapping emerging AI UI patterns and how… | by Sharang Sharma | UX Collective
:URI: https://uxdesign.cc/where-should-ai-sit-in-your-ui-1710a258390e
:CREATED: [2026-04-28 Tue 09:50]
:END:
* [[https://x.com/i/status/2049011134426906635][Shakker on X: "OpenClaw's first output dropped from 1s to 43ms. Plugin bootstrap went from 265ms to 8ms. Provider capability resolution from 49ms to 1.5ms. Config validation from 62ms to 5ms. For most of OpenClaw's history, the plugin system was carrying core, instead of the other way around." / X]]
:PROPERTIES:
:TITLE: Shakker on X: "OpenClaw's first output dropped from 1s to 43ms. Plugin bootstrap went from 265ms to 8ms. Provider capability resolution from 49ms to 1.5ms. Config validation from 62ms to 5ms. For most of OpenClaw's history, the plugin system was carrying core, instead of the other way around." / X
:URI: https://x.com/i/status/2049011134426906635
:CREATED: [2026-04-28 Tue 09:51]
:END:
* [[https://github.com/lithos-ai/motus][lithos-ai/motus: The open-source agent-serving project]]
:PROPERTIES:
:TITLE: lithos-ai/motus: The open-source agent-serving project
:URI: https://github.com/lithos-ai/motus
:CREATED: [2026-04-28 Tue 09:51]
:END:

View File

@@ -0,0 +1 @@
user@amr.154851:1777155215

1
notes/.#gemini-vision.org Symbolic link
View File

@@ -0,0 +1 @@
user@amr.154851:1777155215

760
notes/chats-with-gemini.org Normal file
View File

@@ -0,0 +1,760 @@
#+TITLE: Chats with Gemini
#+AUTHOR: Amero
#+FILETAGS: :gemini:ai:research:
#+STARTUP: content
* Chat 1: REPL Agents Advantages
Source: https://gemini.google.com/share/5fc668800a27
Date: April 22, 2026
Summary of key concepts discussed:
** Core Insight: REPL as "Active" Memory**
A REPL-based agent doesn't just "read" context—it treats the codebase as a searchable variable. It can programmatically explore, test, and verify, rather than passively predicting what might work.
*** Benefits for AI Agents
1. *Context Optimization*: Instead of stuffing 10,000 files into context, the agent runs scripts to fetch only what's needed. Keeps active context lean (2k-4k tokens) instead of bloated.
2. *Verification over Hallucination*: The agent can actually run code it writes. If the REPL returns an error, it sees it immediately and fixes it. No more "guessing" if the code works.
3. *Recursive Problem Solving*: The agent can spawn "mini-versions" of itself to handle sub-tasks. A main agent identifies 50 files needing change, recursively calls sub-agents for each.
4. *Diffusion-Style Reasoning*: Initialize an answer variable, keep editing it as it explores. "Diffuses" toward correct solution over multiple turns before presenting final result.
5. *VRAM Efficiency*: By keeping context tiny, a 27B model can perform like a much larger model. Its "brainpower" goes to logic, not holding text.
*** Economic Impact
- *Token Costs*: Quadratic in standard chat (re-sending history each turn). Linear/flat in REPL (context stored once). 80-90% reduction for long sessions.
- *VRAM*: Minimal active context = much faster token processing.
- *Hot State*: Variables, file handles, sub-routine results already live. Eliminates pre-fill latency.
- *Tiered Pricing*: Use expensive "brain" for hard decisions, cheap sub-agents for grunt work.
*** Extension to Non-Coding Text Work
1. *World Variable*: Treat manuscript as persistent database variable. Query "what color are John's eyes" without reading whole book. Eliminates context drift.
2. *Recursive Synthesis*: For research, root agent spawns sub-agents to mine themes from massive library stored in REPL variable. Process effectively infinite input.
3. *Consistency REPL*: Maintain "Truth Table" in live memory. Before writing, "evaluates" text against that state. Throws error if contradicts previous definition.
4. *Self-Modifying Voice*: Style guide isn't just a prompt—it's live functions. Tell agent "too formal," it rewrites its own generate-tone function. Every subsequent sentence inherits the fix.
*** Why REPL Agents Aren't Dominating Yet
1. *Security*: Adversarial persistence. In standard chat, poison disappears on new session. In REPL, if attacker modifies a core function, it persists indefinitely. Enterprise sees this as "terrifying."
2. *Lisp Curse*: Python ecosystem is massive (10M developers vs 1 Lisp master). Hiring Lisp maintainers is "key person risk."
3. *Maintenance Tax*: REPL agents fail probabilistically, not deterministically. Can enter logic loops nearly impossible to debug. 3x more efficient but 5x more engineering hours to monitor.
4. *Stakeholder Model*: No solid way to distinguish users. Agent might apply voice/permissions learned from one user to another.
*** State Rot Mitigations
1. *Snapshots*: Baseline save game for instant recovery.
2. *Rollbacks*: Compensation actions that undo specific changes. Shadow/overlay filesystem—changes only become real when verified.
3. *Compaction*: Background scrubber extracts only new facts, deletes noise. Moves important facts to vector database, wipes active context.
4. *Courtroom Model*: Multi-agent system. Prosecutor finds contradictions. Jury decides if state is corrupted, forces hard reset.
5. *Lisp Condition Restarts*: Error enters break loop. Presented with recovery paths it can take without losing progress.
6. *Semantic Isolation*: Memory barriers between tasks. Clears previous variables when switching context. Prevents contamination.
7. *Formal Property Verification*: SystemVerilog-style assertions. Updates rejected at hardware level if violate core rules.
*** RLM Paper Reference
Paper: "Recursive Language Models" (arxiv 2512.24601)
- REPL as "Infinite Memory" - treats long prompts as external environment inside Python REPL
- Recursive Decomposition - model writes script to break task, calls smaller instances of itself
- Answer Variable Persistence - diffusion-style reasoning over multiple turns
- Validates that local 8B model with REPL can outperform much larger models
- Conclusion: Inference-time scaling (looping in REPL) more efficient than training-time scaling (bigger model)
** Relevance to OpenCortex
This aligns with OpenCortex's architecture:
- *Lisp REPL*: OpenCortex runs in Common Lisp, naturally homoiconic. Code is data—agent can modify its own skills.
- *Metabolic Loop*: Perceive → Reason → Act pipeline mirrors RLM's "crawl and verify" approach.
- *Memory Rollback*: Transactional state management prevents state rot.
- *Skills as Org-mode*: Structured, queryable, hot-reloadable. Similar to "world variable" concept.
- *v0.2.0 Self-Editing*: Direct implementation of "agent modifies its own brain" concept.
- *v0.3.0 Event Orchestration*: Three tiers (:REFLEX, :COGNITION, :REASONING) echo RLM's recursive decomposition.
** Opportunities for OpenCortex
1. Implement explicit "recursive sub-agent" pattern for complex tasks.
2. Add "compaction" event for long-running sessions—extract facts to Org-mode, clear live context.
3. Explore "courtroom" model: secondary skill that verifies primary skill's logic for contradictions.
4. Document performance gains from REPL approach vs standard chat agents.
5. Consider formal property verification for critical skill invariants.
* Chat 2: OpenCortex v1.0.0 Roadmap Review
Source: https://gemini.google.com/share/bb714c13acab
Date: April 28, 2026
** Gemini's Assessment of OpenCortex
*** Strengths
1. *Homoiconicity*: Lisp code is nested lists (data). Agent can natively read, write, evaluate its own logic at runtime without complex AST parsers.
2. *Probabilistic-Deterministic Loop*: LLM as semantic "guessing" engine, intercepted by deterministic Lisp "Bouncer." Formal verification before execution—solves hallucination-execution danger.
3. *Org-mode as Unified AST*: Humans and machines read/write same format. Eliminates translation layer between human notes (Markdown) and machine data (JSON).
*** Roadmap Opinion
- *Short-term (v0.1-v1.0)*: Pragmatic. Self-editing (v0.2), TDD auto-repair, GTD workflows—perfect for Emacs ecosystem.
- *Mid-term (v2.0-v3.0)*: Paradigm shift. Agent becomes Emacs process (Lisp Machine Emergence). Deterministic planner relegates LLM to semantic translation—future-proofs against model degradation.
- *Long-term (v4.0-v5.0)*: Borderline fundamental AI research. Llama.cpp FFI, persistent world models.
*** Trade-offs
- *Extreme Niche*: Pure Common Lisp + Emacs = massive barrier to entry.
- *Maintenance Burden*: No Python AI ecosystem (LangChain, LlamaIndex)—must build everything manually in Lisp.
** Gaps in Roadmap & Escape from Niche
*** Identified Gaps
1. *First Five Minutes*: No standalone binary or one-click Docker. Setup requires highly technical user.
2. *Evaluation/Benchmarking*: No mechanism to measure "SOTA Parity." Needs integration with SWE-bench, WebArena.
3. *Observability*: No visual tracing tool, GUI dashboard. Reading thousands of Plists isn't true observability.
4. *Interoperability*: Assumes single user. No multi-agent collaboration, OAuth, webhooks.
5. *Prompt Injection Sandboxing*: What if hostile webpage says "ignore previous instructions"? Need dedicated security milestone for sandboxing eval.
*** Strategies to Escape Niche
1. *Bridge to PKMs*: Market as "AI Engine for Logseq." Build bidirectional sync for Obsidian (Markdown ↔ Org-mode).
2. *Shift Marketing*: From "Tech Stack" (Common Lisp + Org-mode) to "Outcomes" (hallucination-proof, 100% local, self-correcting).
3. *Standalone Binary*: Use SBCL's save-lisp-and-die to compile single executable. Spin up local web server. User runs =./opencortex start= without knowing it's Lisp.
4. *Batteries-Included Workflows*: Ship pre-built skills. "Drop PDF → auto-summarize." "Connect calendar → resolve conflicts."
5. *Extension API*: Offer gRPC/REST API so developers write skills in Python/Go/TypeScript. Lisp kernel as unbreakable OS, users write "apps."
** Cutting Edge GUI for AI Agents
*** Paradigm A: Visual Canvas (Consumers)
- *Artifact Model*: Side-by-side workspace. Converse on left, agent builds/edits on massive visual canvas on right.
- *A2UI (Agent-to-User Interface)*: Agent streams declarative JSON. Client reads and renders pre-approved UI components natively. Eliminates injection attacks.
*** Paradigm B: Terminal/CLI (Developers)
- Claude Code, OpenClaw prove Unix Terminal is ultimate zero-overhead interface.
- Direct native access to file system, compiler, git without Electron wrappers.
** Python/JSON Skills Bridge with Cannibalization
*** The Idea
User writes quick Python/JSON skill → executes immediately → system auto-cannibalizes into pure Lisp/Org-mode file.
*** Why It Works
- Zero-friction onboarding: Developers use tools they know (Python, LangChain).
- Purity preserved: Python is temporary. Agent extracts logic, rewrites to Org Lisp, deletes Python.
- Evolutionary architecture: LLM compiles Python into Lisp.
*** The Traps
1. *Translation Hallucination*: Python relies on C-bound libraries (Pandas, NumPy). Cannot translate to pure Lisp without writing matrix math from scratch.
2. *Security*: Automatically executing translated Lisp is massive vulnerability. Must have strict sandbox during cannibalization.
*** Correct Execution
- Enforce strict JSON schema for Python skill.
- Ignore Python execution logic, read only JSON schema.
- Use JSON map to construct Lisp defskill macro and Org properties.
** MCP for Integrations, Skills for Local Processing
*** Architecture Split
- *MCP for External*: External API calls (Slack, GitHub, DBs). Standard JSON-RPC via stdio or SSE. Keeps kernel pristine.
- *Native Skills for Local*: Heavy iterative processing (PDF vectorizing). Operates in same memory space as brain. Zero-latency.
- *Security*: External API calls isolated behind MCP. If API fails, MCP server handles error, Lisp kernel registers :blocked/:failed.
** Bouncer Engine - Deterministic Safety
The one feature that makes users switch from OpenClaw: *Provable Execution Safety*.
- *OpenClaw*: LLM gets Node.js runtime. If it hallucinates command, pushes .env to GitHub, little stops it.
- *OpenCortex*: LLM is sandboxed. Can only generate request as Lisp Property List. Bouncer intercepts, formally verifies against invariants before execution.
** Bouncer Learning on the Job
Static Bouncer = straitjacket. Must learn symbolically, not probabilistically.
1. *HITL Exception*: When LLM proposes unrecognized action, Bouncer suspends thread, writes to Org-mode. Human reviews, changes BLOCKED to APPROVED.
2. *Lisp Rule Synthesis*: When human approves, system triggers Rule Synthesis. Reads AST of approved command, generalizes parameters, compiles new safety rule at runtime.
3. *Shadow Mode*: Runs in "trial run" mode. Simulates execution in virtualized environment. Observes side effects. If safe, teaches itself pattern is approved.
4. *Formal Property Verification*: SystemVerilog-style assertions. Before committing state, must pass logical rules. Updates rejected at hardware level.
** GUI Timing: Before v1.0 or Between v1.0-v2.0?
Before v1.0 = Throwaway code trap. Would build Web GUI (React/Vue), but v2.0 cannibalizes Emacs into Lisp browser—that Web GUI becomes dead weight.
Between v1.0-v2.0 = Correct. v1.0 is SOTA Parity (cognitive engine bulletproof). Emacs/CLI are testing grounds. After v1.0, agent helps build its own interface.
** Lisp Browser Choice: McCLIM vs SDL2 vs WebView vs Qt
- *McCLIM*: Lisp Machine purist. Complete GUI framework. Feels like living inside program. Steep learning curve, "dated" look.
- *SDL2*: Total pixel control. High performance. Reinvents wheels (scrolling, fonts). Good for bespoke editor like Lem, nightmare for browser.
- *WebView*: Pragmatist. Lisp backend + browser engine frontend. JSON-RPC bridge. Best of both—CSS/HTML for UI, Lisp for logic. But C++ dependency, memory overhead.
- *Qt/QML*: Cross-platform native. Qt Quick (QML) is declarative—matches Lisp generation model. Touch-native for mobile. EQL5 (Embedded Common Lisp + Qt) compiles Lisp into Qt binary. No IPC overhead.
*** Decision: Qt/QML for mobile portability.
** Milestones Before v1.0.0
1. *v0.5.0*: Learning Loop—Symbolic Induction: Convert successful LLM chat sequences into reusable Lisp functions.
2. *v0.7.0*: Unified Gateway—Channel Agnostic Layer. MCP Host protocol to wrap Telegram/Signal/Slack.
3. *v0.9.0*: Agentic Governance—Formal Audit Logs. Every action cryptographically signed in Org-mode for replay.
4. *Additional*:
- Sandboxing & Formal Verification Harness
- Observability & Tracing (Thought Trace Visualizer)
- Persistence & Recovery (Atomic Snapshots)
- MCP Host Implementation
- Evaluation Suite (Agent Benchmarks)
** Comparing to Hermes and OpenClaw
- *OpenClaw*: Swiss Army Knife gateway. Massive npm plugins. Python-based. Probabilistic execution—dangerous for safety.
- *Hermes*: Self-Improving Partner. Pattern extraction. MIT License.
OpenCortex advantage:
- Deterministic Bouncer = mathematically incapable of bypassing safety invariants
- Zero-dependency deployment (single SBCL binary)
- Homoiconic skills vs brittle JS/TS plugins
** MCP Approach: Own Lisp Native or OpenClaw's?
Build own. Why:
- OpenClaw = Node.js runtime. Forces V8 alongside Lisp image. Performance tax, bloat.
- Native Lisp MCP Host: In-process integration, no serialization overhead. Deterministic security inserted at protocol layer. Structural introspection—can inspect Lisp heap.
Strategy: "Native Host, Universal Client." Connect to existing MCP servers (Go/Python/TS) without writing own tools. Get ecosystem compatibility while keeping orchestration pure Lisp.
** Comparing to Motus
- *Motus*: Python agentic runtime. High-performance serving, parallelism, production-scale resilience. Focuses on infrastructure, not brain.
- *openCortex*: Lisp Machine OS.
Borrow from Motus:
- Task DAG Manager: Lisp-native dependency graph, automatic parallelism and async execution.
- Declarative Guardrails: Use Lisp Types and Condition Systems instead of Pydantic.
- Observability: Agent outputs Trace-Tree in S-expressions, render in WebView/Qt.
** Docker Compose Implementation
Game-changer. Already solved environmental configuration friction.
Use for "Agent-as-a-Service":
- Unix Domain Socket or stdio pipe from sidecar (Nginx/Go) to Lisp process.
- Map ~/memex/ directory as Docker Volume—agent always edits same Org files whether in Docker or native.
** Relevance to OpenCortex
This chat directly informs several roadmap items:
- *v0.3.0 HITL*: Implements Bouncer learning with symbolic rule synthesis
- *v0.4.0 Git Workflows*: Addresses observability and tracing
- *v0.5.0 Interactive Actuation*: Memory snapshots and persistence
- *v0.7.0 MCP Bridge*: Native Lisp MCP Host implementation
- *v2.0.0 Lisp Machine*: Qt/QML frontend, cannibalize Emacs
** Action Items from This Chat
1. Prioritize Docker persistence layer—demonstrate resume-on-crash
2. Build native Lisp MCP Host rather than wrapping OpenClaw
3. Consider Qt/QML (not WebView) for v2.0 GUI—better mobile support
4. Add "Symbolic Induction" to v0.5.0—auto-generate Lisp functions from successful sessions
5. Add "Formal Audit Logs" to roadmap—cryptographic signing of decisions
6. Market "hallucination-proof" not "Common Lisp"
* Chat 3: OpenCortex v2.0.0 - The Lisp Browser Project
Source: https://gemini.google.com/share/17770a813c33
Date: January 17, 2026 (content), April 28, 2026 (publication)
** Project Vision
A Common Lisp-based web engine that treats the internet as manipulatable data structures rather than static pixels. Entirely keyboard-driven, introspectable, modifiable at runtime.
Core Architecture: Lisp as the Kernel (Parent Process), WebKit as display server (Sub-process).
- *Lisp Machine approach*: Browser inside Lisp, not Lisp inside browser
- *Shared State*: Full access to filesystem, org-gtd files, system processes
- *Unified Control*: Treat web page like text file—run Lisp macro over every link
** The Engine Dilemma
Two paths:
1. *FFI Route*: Wrap WebKitGTK or QtWebEngine (modern web compatibility)
2. *Headless Orchestrator*: Lisp drives headless Chromium via Chrome DevTools Protocol
Decision: Use WebKitGTK via cl-webkit bindings for Phase 1.
** The "Emacs-Like" Editor Core
- Buffer Management: Every tab is a buffer.
- Minibuffer: Command line at bottom for Lisp functions, history, buffer switching.
- Self-Documentation: describe-key, describe-command for introspection.
** The Browser vs. Lisp Machine Distinction
*Browser inside Lisp* (Project Paradigmatic):
- Lisp is Parent Process, owns window, memory, input loop
- WebKit is merely a library rendering pixels inside a Lisp buffer
- Can redefine functions while browsing without restart
*Lisp inside browser* (Extension):
- Browser is authority, sandbox restricts capabilities
** Performance vs. Chrome
- *Rendering*: WebKit vs Blink—5-10% slower on JS-heavy sites, imperceptible for 95% of web.
- *Memory*: Single Lisp Image manages UI/hooks vs Chrome's massive per-tab processes. Can keep 50+ buffers with lower RAM than 20 Chrome tabs.
- *Latency*: SBCL compiles to machine code. Keybinding lookup in microseconds—faster than 16ms window for 60fps.
- *Input Loop*: GDK events intercepted before reaching WebKit—browser can't "steal" shortcuts.
Performance Guardrails:
- Lazy Buffer Loading: Buffers remain dormant until switched to.
- Native Key Handling: Keybindings in Lisp core—even if page is frozen, browser commands work.
- Direct DOM Extraction: WebKit C-API for fast data extraction.
** Pure Lisp Parser vs. Hybrid
*Pure Lisp (Option A)*:
- HTML5 Parser: 2-3 months for spec-compliant parser (agents helpful)
- CSS Layout Engine: 12-18 months (agents medium—debugging needs human eyes)
- JavaScript Engine: Multiple years (recommend embedding QuickJS or using bridge)
*Hybrid (Option B)* - Recommended:
- Network: dexador (Pure Lisp)
- HTML Parsing: Plump (Pure Lisp)
- Layout: Wrap Yoga (C-based Flexbox) via FFI
- JavaScript: Embed QuickJS
"Erosion" Roadmap (B → A):
1. *Stage 1*: UI & Logic (Qt for window → develop CL-OpenGL layer → swap to Pure Lisp UI)
2. *Stage 2*: DOM (WebKit holds DOM → Lisp builds own S-Expression DOM → WebKit only for "Painting" pixels)
3. *Stage 3*: Layout (WebKit calculates → Agent writes CL layout engine → WebKit turned off)
** GUI Choice: Qt vs. GTK
*Decision: Qt/QML via EQL5*
- *Mobile*: GTK doesn't run natively on iOS/Android. Qt is industry standard for cross-platform C++.
- *Performance*: Qt handles low-level graphics acceleration (RHI) better for mobile fluidity.
- *EQL5*: Exposes full Qt C++ API from Lisp. Access mobile sensors (GPS, Camera) from Lisp without C++.
** Bootstrapping Phases
- *Phase 1 (M1-2)*: Core loop (SBCL), minibuffer, command processor, "Hello World" window
- *Phase 2 (M3-4)*: Buffer logic, keybinding engine, PTY shell bridge—"Ghost Editor"
- *Phase 3 (M5-7)*: Integrate cl-webkit, web-buffer class, input interceptor
- *Phase 4 (M8-10)*: Mobile port via EQL5/LispWorks, gesture mapping, Remote IPC
- *Phase 5 (M11+)*: Org-mode integration, Extension API
** Emacs Ecosystem Integration
*Ambassador IPC Bridge*: RPC layer using EPC to call Emacs functions.
- *Phase I (Parasite)*: RPC Bridge—Browser calls Emacs for all logic (Org capture, Magit)
- *Phase II (Interpreter)*: Build ELisp compatibility layer in CL to run some packages natively
- *Phase III (Successor)*: Native CL versions read/write same file formats—total independence
Handling key packages:
- *Org-Mode*: Use cl-org-mode to read/write .org files directly. Keep Emacs UI for heavy editing.
- *Magit*: Spawn Emacs buffer in UI frame via XEmbed—looks integrated, runs original package.
- *LSP*: Write Native CL LSP Client—gives editor intelligence without Emacs dependency.
** Mobile UI Density Strategy
- *Tiling Layout*: Semantic stacking. 80-90% primary buffer, 10% contextual slits at edges.
- *Translucent Minibuffer*: Modal overlay over website content.
- *Z-Axis Hierarchy*: Foreground (Minibuffer), Active (Browser/Editor toggled via gesture), Background (CLI continuous), Persistent (Header with memory/GTD/battery).
- *Lisp-Gesture System*: Two-finger tap = M-x, edge-swipe left = prev-buffer, edge-swipe up = focus CLI.
** App Store Strategy
- *iOS*: "Educational/Developer Tool" loophole (Guideline 4.7). No JIT compilation (interpreted Lisp only).
- *Android*: F-Droid for unrestricted version, Play Store with sandboxed version.
- *Security*: "Safety Bridge"—Lisp code can manipulate browser/files but cannot touch hardware without standard permission pop-up.
** IPC: The Trinity Integration
- *Lisp-Signal Architecture*: Global Event Bus using Observer Pattern. Signals carry P-Lists. Asynchronous or Blocking.
- *Browser → Editor*: page-load-complete signal → org-gtd module listens → auto-captures title/metadata.
- *CLI → Browser*: file-system-change signal → local file hot-reload without manual refresh.
- *Editor → CLI*: eval-in-shell signal → execute code → return output to Minibuffer.
- *Remote IPC*: Swank for mobile-to-PC. "Push" state from PC, deserialize on Mobile.
** Action Items from This Chat
1. Start with Qt/QML (EQL5) for UI—abandon GTK research
2. Implement "Bridge-First" architecture to enable future "Pure Lisp" erosion
3. Phase 1 starts with Minibuffer & Buffer Management, not browser
4. Use EPC to bridge to Emacs packages (Org, Magit) initially, rewrite later
5. Mobile version follows desktop—same Lisp core, gesture-based input
6. Build "Lisp-Gesture" system for mobile command mapping
* Chat 4: OpenCortex v3.0.0 - Neuro-Symbolic & EGGROLL
Source: https://gemini.google.com/share/f0bbf4b6c488
Date: April 26, 2026 (content), April 28, 2026 (publication)
** EGGROLL Paper Implications
Paper: "Evolution Strategies at the Hyperscale" (EGGROLL - Evolution Guided GeneRal Optimisation via Low-rank Learning)
Key implications:
1. *Backprop-free*: Uses Evolution Strategies to perturb parameters and select best versions. Removes memory overhead of storing activations.
2. *Inference-Speed Training*: Low-rank perturbations (like LoRA) enable 100x speedup vs standard ES.
3. *Low-Precision Training*: Robust to noise—demonstrated stable training with pure int8. Enables "integer-only" LLMs.
4. *Non-Differentiable Objectives*: Treats model as black box. Can optimize any reward signal, even noisy/outcome-only.
5. *New Architectures*: Successfully trained RWKV-7 (recurrent model) in integer formats—architectures previously "un-trainable."
Training vs Inference:
- EGGROLL is for training, but enables better inference via integer-only models
- 50-80% memory savings, 100x speedup vs previous ES
- Competitive with GRPO (DeepSeek) for reasoning tasks
Hardware Impact:
- Don't need expensive H100s—works on cheaper hardware with lower VRAM
- Doesn't require ASICs—but is "dream algorithm" for integer-only ASICs
- Compatible with current Transformer ASICs (TPUs, Groq)—just "easier" math
- Future ASICs will strip out high-precision units, making them cheaper
Nvidia's Strategy:
- Jevons Paradox: Making training cheaper leads to more consumption (larger models)
- Owns the "Post-Backprop" software stack via CUDA
- Shifts to FP4/FP2 chips—EGGROLL thrives on low precision
** Why EGGROLL Doesn't Work Well with Symbolic AI
1. *Smoothness vs Brittleness*: Neural networks are continuous—small changes = small effects. Symbolic logic is brittle—change one symbol = total nonsense.
2. *Parameter Space vs Combinatorial Space*: EGGROLL works in continuous parameter space. Symbolic AI lives in combinatorial space (Rubik's cube)—random mutations mostly produce garbage.
3. *Low-Rank Mismatch*: Assumes redundancy in weights. Symbolic logic—every symbol is vital. No redundancy to compress.
4. *Needle-in-Haystack*: Symbolic often has ONE correct answer. ES is "blind" search—almost impossible to find that one needle.
** Neuro-Symbolic is the Future
- 10-80-10 Architecture: 10% Neural (Input) → 80% Symbolic (Reasoning) → 10% Neural (Output)
- EGGROLL optimizes the "10%" parts (neural translator) while Symbolic middle does the hard logic
- Outcome-based rewards work perfectly with EGGROLL—binary feedback from symbolic checkers
** Building the Symbolic Part
Why it has been a challenge:
- Knowledge Engineering Bottleneck: Manual rule writing was slow, expensive, brittle
- Combinatorial Explosion: More rules = exponential interactions = "spaghetti code"
How it's unlocked:
- LLMs as "Auto-Formalizers": Translate messy text into formal logic (Prolog, Lean)
- Self-Correction Loop: AI generates symbolic rule → compiler checks → AI refines
- Program Synthesis: LLM writes code, symbolic compiler verifies, AI learns from errors
Five Components:
1. *Knowledge Representation*: Knowledge Graphs (Neo4j), Ontologies, Digital Twins
2. *Formal Logic Engine*: Constraint Solvers, Business Logic (If-Then)
3. *Inference & Planning*: Symbolic Planners, Deductive Reasoning, MCTS
4. *Neuro-Symbolic Interface*: Semantic Parsers, Grounding Layer
5. *Verifier & Reward Loop*: Formal Verifiers, Outcome-Based Rewards (where EGGROLL shines)
** Bootstrapping a Neuro-Symbolic System
Architectural Blueprint (Self-Evolving 10-80-10):
1. *Phase 1 (Scaffolding)*: Use LLM as "Knowledge Engineer"—feeds unstructured data, outputs Knowledge Graph + Formal Rules (Prolog/Lean)
2. *Phase 2 (Execution Stack)*: Neural First-Mile (translate input) → Symbolic Middle-Mile (run against Knowledge Graph) → Neural Last-Mile (format output)
3. *Phase 3 (Learning Loop)*: System encounters rule failure → Optimization Agent proposes patch → EGGROLL trains agent based on Symbolic Verifier's fitness signal
4. *Phase 4 (Hardware)*: Run on Int8/Int4 precision—EGGROLL for training, Logic ASIC for symbolic core
** The "Seed" Explained
- Seed = Unstructured domain knowledge (PDFs, logs, manuals)
- Feed to: Extraction Pipeline (LLamaIndex + high-reasoning LLM as Auto-Formalizer)
- Output: Structured Knowledge Graph + Formal Rules
Who builds the symbolic engine:
- Assemble from open-source: Knowledge Graph (VivaceGraph), Solver (Z3), Logic (Prolog/Datalog)
- Program Synthesis: LLM writes specific code for business rules
- Don't build low-level—build on existing libraries
** Lisp for Neuro-Symbolic
Open-Source Lisp Stack:
- Compiler: SBCL (fast, symbolic manipulation)
- Knowledge Store: VivaceGraph v3 (Lisp-native graph database + Prolog)
- Reasoner: Screamer (non-deterministic backtracking)
- Formal Judge: ACL2 (theorem prover, BSD licensed)
- Glue: Mark Watson's 2026 examples for LLM-Lisp bridge
Why Lisp wins:
- Homoiconicity: AI can write Lisp easily—syntax is just parentheses
- Code as Data: Can inspect and modify running logic
- DSL Creation: Write macros to create domain-specific languages
- 100% auditable: (macroexpand) any rule to see exactly how it works
"Stitching" not "Building":
- Use VivaceGraph for storage, Screamer for constraint checking, ACL2 for formal proofs
- Neural model outputs S-expressions → Lisp parses → Symbolic checks → EGGROLL trains neural to produce better S-expressions
- EGGROLL can be used via Py4CL2 bridge or implemented in Lisp with MGL-MAT
Prolog in Lisp:
- Norvig's PAIP contains classic mini-Prolog in Lisp
- VivaceGraph v3 has Prolog-like query language built-in
- cl-prolog2 bridges to external SWI-Prolog
DSL Approach:
- Don't build new engine—build new DSL (Domain Specific Language)
- Lisp macros transform human-readable rules into Prolog queries
- Bootstrap: Use LLM to write first draft of Lisp-DSL rules from seed data
** Action Items from This Chat
1. Use VivaceGraph v3 + Screamer + ACL2 as the open-source Lisp symbolic stack
2. Implement 10-80-10 architecture: Neural Input → Symbolic Reasoning → Neural Output
3. Bridge EGGROLL via Py4CL2 or implement low-rank evolution in Lisp with MGL-MAT
4. Build DSL for domain-specific rules—don't write low-level engine from scratch
5. Use LLM as Auto-Formalizer to bootstrap Knowledge Graph from seed data
6. Prioritize integer-only (int8) deployment for cost efficiency
* Chat 5: OpenCortex v4.0.0 - Lisp Machines, FPGA & AI
Source: https://gemini.google.com/share/fcb2b654d77c
Date: December 25, 2025 (content), April 28, 2026 (publication)
** Lisp Machines vs ASICs
Technically, Lisp machines are not ASICs. They are computers with Application-Specific Instruction Set Processors (ASIPs).
- *ASIC*: Fixed, hardwired logic (one task). Cannot be reprogrammed.
- *Lisp Machine*: General-purpose CPU with custom silicon (Symbolics Ivory, TI Explorer) optimized for Lisp—programmable but Lisp-specific.
The "middle ground": Lisp CPUs were custom silicon designed to run Lisp with hardware support for tagged architecture, garbage collection, and fast function calls.
** Emacs as Virtual Lisp Machine
Emacs mimics Lisp Machine architecture entirely in software:
- Full visibility/introspection—M-x find-function to inspect any command
- Single address space (Lisp Heap)—one bug can crash everything
- The "C Substrate" problem: C code is the "floor" below the Lisp layer
** Best Lisp? Common Lisp, Scheme, Emacs Lisp, Clojure
Common Lisp is the standard. Emacs Lisp reinforces the "Lisp Machine" environment. Clojure runs on JVM but offers immutability. The choice depends on deployment context.
** Why Emacs Core Written in C?
1. *Bootstrap Problem*: Can't run Lisp without a Lisp interpreter. Hardware understood Lisp natively; Unix didn't.
2. *Performance*: 1980s hardware too slow for interpreted Lisp. C allowed direct memory manipulation (gap buffers).
3. *Portability*: C compilers existed everywhere; Lisp implementations were fragmented.
Today, Lem (Common Lisp editor) proves pure Lisp is viable on modern hardware.
** The Turtles All The Way Down Paradox
The "bottom turtle" is always Hardware ISA (x86/ARM). Even writing "Pure Lisp" from editor to binary, you're still standing on architecture designed by hardware engineers.
*Ken Thompson's "Reflections on Trusting Trust"*: A C compiler can embed a backdoor that survives compilation of "clean" source code. You can never truly know the bottom turtle.
** Stage0 Project
A project to create a fully bootstrap-able system starting from 500 bytes of manually written hex code to reach Lisp without "trusting" a C compiler.
- 500 Bytes Hex → Hex Assembler → M1 Macro Assembler → Lisp Interpreter → Self-Hosting Lisp
** RISC-V: C-Like?
RISC-V is currently "C-like" because designed for C efficiency:
- Linear memory (C arrays/pointers)
- Lack of "Tags" (software must check types manually)
- Standard RISC-V doesn't inherently differentiate number vs address
Exception: J-Extension (Dynamically Translated Languages)—would add hardware tagging and GC hooks.
** Building a Modern Lisp Machine
1. *Hardware*: RISC-V core + Custom Lisp extensions (J-extension philosophy)
- Tagged Architecture: Top 4-8 bits of every memory word = Type Tag
- Zero-overhead Type Checking: Hardware checks tags in parallel with ALU operations
- Trap on type mismatch
2. *Memory*: NVRAM for Single Address Space Storage
- Persistent Heap: Everything in one giant pool of permanent memory
- No "Booting": Turn on, state is exactly where you left it
3. *Garbage Collection*: Dedicated Bus Master (Scavenger)
- Background cleaning while main CPU runs code
- No "GC Pause"
4. *Development Environment*: Everything is a pointer, everything inspectable. No binary blobs.
** Why Not Build This Today?
- *C Trap*: Most software (browsers, drivers) is C/C++. Porting is monumental.
- *Economies of Scale*: Intel/Apple spend billions. Custom Lisp chip would be 10x slower at raw math.
- *Isolation*: Single bug in Lisp script could corrupt entire hardware state.
Modern solution: Formal Verification (Proof-Carrying Code, Capability-Based Security) instead of walls.
** FPGA Path to Build It
Hardware: Terasic DE10-Nano (learning), Xilinx KCU105 (full PCIe).
1. Learn Verilog, build Type Checker module
2. Modify RISC-V core (VexRiscv) to add tagged ALU
3. Implement PCIe umbilical cord (DMA/P2P communication)
4. Self-hosting: Boot Lisp core, control hardware directly
** AI + Lisp Machines: The "Infinite Self-Refactoring" Machine
- AI can observe bottlenecks, rewrite functions, compile, swap while running
- Natural Language OS: "I want a button that summarizes emails" → AI writes Lisp code, injects into memory
- *Isolation Paradox*: More dangerous or safer? Hardware enforces types—can't overwrite random memory. Reversibility—can roll back. Auditability—exact code diffs.
** Why Lisp is "Ideal" AI Language
Homoiconicity (Code is Data). AI can generate a list, manipulate it, execute it. Not just passenger but architect—can create data structures on the fly. This is how biological brains work.
** Why Nobody Builds Lisp Machines Today
1. *Commodity CPU Steamroller*: Generic Intel chips became so fast through brute force they simulated Lisp Machines faster than real ones.
2. *C Ecosystem*: Network effect—libraries, drivers all in C/C++. Lisp is a "walled garden."
3. *AI Winter*: AI was Symbolic (Lisp), now is Connectionist (Statistical/Neural). GPUs (matrix math) beat Lisp (symbolic logic).
Future: May see "Lisp Accelerators" return if Neuro-symbolic AI trend continues.
** Clojure & Julia: Lisp-ish Successors Without Hardware
- *Clojure*: Runs on JVM. Gives "Code as Data." Solves isolation with immutable data.
- *Julia*: Not Lisp but uses Homoiconicity. Metaprogramming + JIT compilation.
** Can AI Refactor Linux to Lisp?
Extremely difficult (10/10 difficulty):
1. *Paradigm Mismatch*: Translating C to Lisp is like translating manual to poetry. Literal translation = "Lisp code that thinks it's C"—slow, ugly, loses introspection.
2. *Liveness Gap*: Source code vs Running Program are different in Linux. In Lisp Machine, they are same.
3. *Device Driver Nightmare*: Millions of lines of C for hardware. Lisp prefers "Pure Functions."
AI-Native Path: Build new Lisp system rather than refactor old. "Micro-Lisp Machine" first: Small AI-generated Lisp kernel on RISC-V FPGA, expand on demand.
** PCIe Card Lisp Machine (Practical Path)
- *Host*: Intel/AMD CPU runs Linux/Windows—handles "dirty" work
- *Lisp Card*: FPGA with dedicated RAM, tagged-architecture CPU
- *Memory Mapping*: Card can see host's memory. Lisp environment reaches out, inspects data.
- *Safety*: If Lisp crashes, Host stays alive. Reset card, reload.
Hardware exists: Terasic DE10-Nano, Xilinx KCU105, LiteFury.
** Phase Migration: Host → Lisp
1. *Parasitic*: Lisp card as co-processor. Host as I/O server.
2. *Functional Hijacking*: Lisp UI runs on card, displays through PC. AI indexes Linux files into Lisp objects.
3. *Driver Cannibalization*: Point AI at C drivers, ask to generate native Lisp drivers. PCIe Passthrough for hardware control.
4. *Self-Hosting*: Replace Linux bootloader with Stage0 Lisp. Cut umbilical cord.
** Performance for AI Inference
Lisp Machine handles inference differently:
- *Speed*: Tagged architecture eliminates "forgetting what data is." Zero-copy inference—weights exist as permanent Lisp objects.
- *Can it handle modern LLM*: 64-bit tagged Lisp core can handle models like Llama 3 8B. But GPU better at Matrix Multiplication, Lisp better at Reasoning. Hybrid system: GPU calculates "next token," Lisp acts as Hardware-Level Guardrail.
- *Inference as Continuous Interaction*: Not one-way (prompt → answer). AI infers new function, injects into OS kernel. "Inference" becomes performing logical operation.
** VSA: Vector Symbolic Architecture
VSA bridges symbolic logic (Lisp) and high-dimensional vector space (LLMs).
- Every concept = Hypervector (1,000-10,000 dimensions)
- Operations (bind, bundle, permutations) = simple XOR/Shift—easy for hardware
- Hardware Benefit: No complex matrix math, just simple boolean operations
** Moving to ASIC (The Ultimate Leap)
- *Speed*: 3-5x higher clock frequency (100MHz FPGA → 500MHz-1GHz ASIC)
- *Energy*: 10x more efficient—no programmable overhead
- *Cost*: For mass production, significantly cheaper—more logic in smaller space
Scale:
- *Tiny Tapeout* (~$500-1,000): Simple 8-bit Lisp toy processor
- *Shuttle* (~$10k-20k): Tagged RISC-V with ~100-300MHz
- *Industrial* (~$10M-100M+): 5nm process, competes with modern CPU
** Lisp ASIC Doesn't Exist
No mass-produced Lisp ASIC in 2026. Closest: CHERI-RISC-V (capability hardware enhanced).
To make one, you use RISC-V as skeleton and add custom extensions:
- Custom Tagged Instructions (TADD, LISP.CAR, LISP.CDR)
- Hardware Write-Barriers
- Vector Symbolic Hooks
Not "C-like" if you add the extensions—uses RISC-V "carrier" but gives it "Lisp muscles."
** Python/JSON LLMs → S-expressions
Improves performance because:
- *JSON Tax*: Must parse strings, allocate objects, validate. S-expressions are native tree structures—memory map directly into heap, load time near-zero.
- *S-expressions as Native ASTs*: Direct tree-walk. Hardware tree-walker traverses nested S-expressions at bus clock speed.
- *llama.lisp*: Written in Common Lisp. Use macros to generate optimal kernels, refactor before machine code generated.
- *Hardware-Level Inference*: Recursion is atomic hardware operation on tagged machine. Not fighting Python interpreter.
** Why "Pure Lisp Models" is Bad Idea
1. *Data Representation*: 70B params = 70B weights. Tag every weight = 50% memory waste. Represent as tree = 400% overhead (pointers).
2. *Cache Locality*: LLMs need Streamed Linear Access (chunk → parallel math). Lisp machines are "Pointer Chasers." Bottlenecked by memory traversal.
3. *Semantic Gap*: Weights are statistical noise, not symbolic. No semantic meaning in single weight that S-expression captures better than raw byte.
4. *Ecosystem Isolation*: AI research moves at speed of Python/C++. Can't use billions in optimized kernels.
** The "Best of Both Worlds" Approach
*Use Lisp as Sovereign Governor, not as Math Engine:*
1. *Macro-Tags*: Tag the Tensor as single Lisp object, not individual weights. Hardware checks tag once, then gives Pointer to Tenstorrent p150. 100% safety with 0% overhead during math.
2. *S-Expressions as Universal Compiler (DSL)*: Describe LLM layer as Lisp list: (layer :type 'transformer :heads 32 :dim 4096). Compile time generates exact machine code for p150's cores. Python interprets every time; Lisp compiles once.
3. *Liveness as Debugging Tool*: Pause LLM mid-inference. Inspect Hidden States as Lisp variables. Modify vector, change sampling parameter, resume. Live surgery on cognition.
4. *Hardware-Enforced Safety*: AI-generated Lisp function runs on FPGA. Tagged hardware physically cannot access memory outside allowed heap. Security-by-Physics not Sandbox.
** Action Items from This Chat**
1. Don't store weights as Lisp objects—use Macro-Tags (pointer to flat binary)
2. Build DSL in Common Lisp for LLM architecture description
3. Use REPL to interact with AI's internal state mid-inference
4. Run AI-generated code on tagged FPGA for hardware-enforced safety
5. Start with VexRiscv on FPGA to validate tagged architecture before ASIC
6. Target TinyTapeout for first "Lisp Tag Coprocessor" silicon

238
notes/gemini-vision.org Normal file
View File

@@ -0,0 +1,238 @@
#+TITLE: The OpenCortex Vision — A Strategic Blueprint
#+AUTHOR: Amero
#+FILETAGS: :strategy:roadmap:vision:
#+STARTUP: content
* The Vision: A Neuro-Symbolic Lisp Machine
OpenCortex is not merely another AI agent. It is an attempt to build something deeper — a sovereign computing environment where the agent and its operator share the same language, the same data structures, and the same memory. It is a return to the dream of the Lisp Machine, updated for the age of neural networks.
The core insight from months of discussion with Gemini is this: the future of personal AI is not about bigger models, but about smarter architecture. We do not need an AI that guesses. We need an AI that reasons — backed by hardware that enforces safety, and software that grants its operator absolute sovereignty over their data.
This document captures the philosophical foundations, technical architecture, and strategic roadmap that emerged from those conversations. It is written for the engineer who will build it, the user who will trust it, and the future historian who will ask: "Why didn't the world run on Lisp?"
* Philosophy: Why This Matters
** The Sovereignty Imperative
Every other AI agent runs on a stack of dependencies — Python packages, npm modules, pip installs, conda environments. When the maintainer walks away, the stack rots. When the company shuts down, your data dies in their database.
OpenCortex is different. It runs on SBCL alone. The kernel is Lisp. The skills are Lisp. The memory lives in Org-mode files you already own. There is no database to migrate, no schema to update, no lock-in to escape. Your data is a folder of text files. It survives app updates, platform switches, and decades of use.
This is not nostalgia. This is engineering pragmatism. The simplest stack is the most maintainable stack.
** The Deterministic Safety Promise
Modern AI agents are terrifying. They pipe LLM output directly into your terminal. If the model hallucinates, it can delete your files or push secrets to GitHub. Safety is added as an afterthought — a wrapper around a dangerous core.
OpenCortex splits the brain into two parts:
1. The Creative Brain (LLM): Understands your notes, suggests actions, generates code.
2. The Strict Guard (Lisp): Before the AI is allowed to touch a file or run a command, a mathematically strict set of rules intercepts the proposal. It verifies the action is safe and permitted. If the AI hallucinates, the guard blocks it.
This is not "guardrails" in the marketing sense. This is hardware-level type checking — impossible to bypass, because the logic is embedded in the execution path.
** The Homoiconic Advantage
Lisp is the only major language where code and data have the same representation. In Python, the AST is a foreign object — the agent can inspect it, but not treat it as something it owns. In Lisp, the agent can read its own code the same way it reads a text file. It can parse its skills, understand their structure, and modify them at runtime.
This is not a party trick. This is the foundation for a self-improving agent. The agent can fix its own bugs, refine its own strategies, and grow more capable without human intervention.
** The Neuro-Symbolic Synthesis
Pure neural AI is a black box. Pure symbolic AI is a straitjacket. The future is both together — a hybrid where the neural engine handles pattern recognition and the symbolic engine handles reasoning.
The 10-80-10 Architecture:
- 10% Neural (Input): A fast model translates messy human language into a structured query.
- 80% Symbolic (Reasoning): A rigid logic engine runs against a Knowledge Graph, checking consistency, enforcing rules, verifying truth.
- 10% Neural (Output): A model turns cold facts back into warm, natural language.
This is not theoretical. It is the architecture of the human brain — System 1 (neural intuition) and System 2 (symbolic reasoning) — rendered in silicon and Lisp.
* Bits Leading to v1.0.0
Before we achieve SOTA parity, we must lay the groundwork. These are the incremental improvements that make the later versions possible.
** Self-Editing and Self-Improving
The agent must be able to modify its own code. Not just fix syntax errors — but learn from outcomes. When the agent encounters a failure, it should analyze why, update its strategy, and try again.
Key implementations:
- Paren-balancing for syntax errors (deterministic)
- LLM-guided surgical fixes (probabilistic)
- Memory snapshots before every edit for safe rollback
- Hot-reload skills without restarting the agent
This is the foundation of autonomy. An agent that cannot edit itself is a tool. An agent that can is a partner.
** The Symbolic Bouncer
The Bouncer is not a static wall. It is a learning system.
1. HITL Exception: When the LLM proposes an unrecognized action, the Bouncer suspends the thread and writes to Org-mode. A human reviews, changes BLOCKED to APPROVED.
2. Lisp Rule Synthesis: When approved, the system generalizes the parameters, compiles a new safety rule, and applies it to future requests.
3. Shadow Mode: The Bouncer runs in "trial mode" — simulating execution, observing side effects, teaching itself patterns.
4. Formal Property Verification: SystemVerilog-style assertions ensure updates are rejected at the hardware level if they violate core invariants.
** Memory Safety
State rot is the enemy of long-running agents. We implement:
- Atomic snapshots for instant recovery
- Transactional rollbacks for safe undo
- Compaction events that extract facts to Org-mode and wipe active context
- Semantic isolation between tasks to prevent contamination
** The MCP Strategy
We do not wrap OpenClaw. We build a native Lisp MCP Host.
The rationale: OpenClaw forces a Node.js runtime alongside the Lisp image. That's performance tax and bloat. A native host runs in the same memory space — no serialization, no IPC overhead, direct structural introspection.
Strategy: "Native Host, Universal Client" — connect to existing MCP servers without rebuilding their tools. Get ecosystem compatibility while keeping orchestration pure Lisp.
* v1.0.0: SOTA Parity
The goal: An agent competitive with commercial agents — Claude, Cursor, ChatGPT.
This is not about matching features. It's about proving the architecture works. The cognitive engine must be bulletproof. The safety invariants must hold under pressure. The agent must be able to:
- Handle multi-step engineering tasks
- Use tools reliably
- Maintain context across sessions
- Recover from errors gracefully
- Pass standardized benchmarks (SWE-bench, etc.)
The "parity" is not in the brand — it's in the capability.
* v2.0.0: Lisp Tools and GUI
Once the brain is proven, we give it a face.
** The Qt/QML Decision
We do not use WebView. It introduces a C++ dependency and memory overhead. We use Qt via EQL5 — a bridge that compiles Lisp directly into Qt binaries.
Why Qt/QML:
- Cross-platform native (Desktop + Mobile)
- Declarative — matches Lisp generation model
- Touch-native for mobile
- No IPC overhead (Lisp compiles to binary)
This is the "thin GUI" layer. It displays what the Lisp brain produces. It does not contain business logic.
** The Emacs Cannibalization
v2.0.0 is when OpenCortex begins to replace Emacs, not just run inside it. The agent becomes the process. The TUI evolves into a full interface. Org-mode buffers become the display layer for the agent's thoughts.
The "cannibalization" is not hostile. It's evolution. Emacs was always a Lisp Machine — we are completing its metamorphosis.
** Marketing Phrase
"OpenCortex isn't an app you run. It's an OS you live in."
* v3.0.0: The Symbolic Engine
This is where the neuro-symbolic architecture becomes real.
** The Knowledge Graph
We integrate VivaceGraph — a Lisp-native graph database with built-in Prolog. This is not an external database we connect to. It's part of the address space.
The symbolic engine maintains:
- Facts and relationships (Knowledge Graph)
- Rules and constraints (Prolog)
- Formal proofs (ACL2)
When the neural engine generates a response, the symbolic engine verifies it. When the neural engine claims something is true, the symbolic engine checks the chain of reasoning.
** The DSL Approach
We do not build a new engine. We build domain-specific languages.
Using Lisp macros, we create languages for specific domains:
- Legal compliance rules
- Medical protocols
- Financial constraints
- Project management workflows
The LLM bootstraps these DSLs — reading seed data, generating first drafts, refining with human feedback.
** Marketing Phrase
"OpenCortex doesn't just answer your questions. It proves its answers are correct."
* v4.0.0: The Lisp Machine
This is the final form. A computer where every level — from hardware to application — speaks Lisp.
** The Tagged Architecture
We move from simulation to silicon.
Using RISC-V as a carrier, we add custom extensions:
- Tagged memory (top 8 bits of every word = type)
- Hardware-enforced type checking (zero-overhead)
- Trap on type mismatch
This is not emulation. This is a CPU that understands Lisp at the gate level.
** The Hybrid Path
We don't build a Lisp Machine in isolation. We pair it with a neural accelerator.
The Tenstorrent p150 (664 TFLOPS) handles the heavy matrix math. The FPGA/ASIC handles the symbolic reasoning. They share a memory space. The Lisp core governs what the neural engine can and cannot do.
This is "Lisp as Governor" — not as the math engine, but as the orchestrator of computation.
** The FPGA Path
Before ASIC, we prototype on FPGA:
- Xilinx KCU105 for full PCIe integration
- Terasic DE10-Nano for learning
The journey: Verilog → RISC-V core → Tagged ALU → PCIe bridge → Self-hosting Lisp
** Marketing Phrase
"The first computer since the Symbolics that truly belongs to you."
* Cross-Cutting Themes
** The Technical Principles
1. *Lisp as Governor*: Use Lisp for orchestration, safety, introspection. Let specialized hardware handle dense math.
2. *Macro-Tags over Full Tags*: Tag tensors, not individual weights. 100% type safety with 0% memory overhead.
3. *S-expressions as Compiler Input*: Use Lisp for architecture description. Generate optimized code for target hardware.
4. *Hardware-Enforced Safety*: Tagged memory at silicon level — impossible to bypass.
5. *Hybrid Architecture*: Neural for intuition, Symbolic for reasoning, Lisp for governance. Each does what it does best.
** The Competitive Differentiators
| Feature | OpenCortex | Others |
|---------|-----------|--------|
| Language | Pure Common Lisp | Python/TypeScript |
| Memory | Org-mode files | SQLite/ChromaDB |
| Self-Modification | Native | Unsupported |
| Safety | Deterministic Bouncer | Probabilistic guardrails |
| Dependencies | SBCL only | pip/npm/conda |
| Data Ownership | 100% yours | Vendor lock-in |
** The Philosophical Stance
We are not building a chatbot. We are not building a copilot. We are building a sovereign computing environment — a digital home where your thoughts, your data, and your agent live together in plain text files you own.
The industry builds AI that runs in the cloud, on someone else's hardware, with someone else's models. We build AI that runs on your machine, in your language, governed by your rules.
This is not a product. It is a philosophy made manifest in code.
* References
- [[file:chats-with-gemini.org][Full Chat Transcripts]]
- [[file:../projects/opencortex/README.org][OpenCortex README]]
- [[file:../projects/opencortex/docs/ROADMAP.org][OpenCortex Roadmap]]

View File

@@ -15,10 +15,11 @@ Basic agenda settings
Agenda files
#+begin_src elisp
(setq org-agenda-files (list
(concat org-directory "/inbox.org")
(concat org-directory "/gtd.org")
(concat org-directory "/org-gtd-tasks.org")
)
(concat org-directory "/inbox.org")
(concat org-directory "/gtd.org")
(concat org-directory "/org-gtd-tasks.org")
(concat org-directory "/projects/opencortex/TODO.org")
)
)
#+end_src