refactor: moved org-agent to its own repository as a submodule
This commit is contained in:
204
notes/20260314_agora_open_source_business_models.org
Normal file
204
notes/20260314_agora_open_source_business_models.org
Normal file
@@ -0,0 +1,204 @@
|
||||
#+TITLE: Agora Open Source Business Models
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+ID: 20260314_agora_open_source_business_models
|
||||
#+FILETAGS: agora business open-source revenue strategy
|
||||
|
||||
* Open Source Business Models for Agora
|
||||
|
||||
** Core Constraint
|
||||
|
||||
Agora is strictly open source software. Revenue must be generated *around* the protocol, not from ownership of it. This aligns with the "Dumb Pipe" legal strategy and ensures Agora remains a public good.
|
||||
|
||||
** Proven Open Source Business Models
|
||||
|
||||
Based on analysis of successful open source companies (WordPress, MongoDB, HashiCorp, Confluent, GitLab, Red Hat):
|
||||
|
||||
*** 1. Open Core Model
|
||||
|
||||
*Definition:* Free open-source core + paid proprietary enterprise features.
|
||||
|
||||
*Examples:*
|
||||
- GitLab: CE (free) vs EE (paid enterprise)
|
||||
- Confluent: Apache Kafka (free) + Confluent Platform (paid)
|
||||
- MongoDB (pre-2018): Community Server + Enterprise Server
|
||||
|
||||
*Revenue characteristics:*
|
||||
- High margins (93% for Red Hat subscriptions vs 31% for services)
|
||||
- Scalable without linear headcount growth
|
||||
- Most profitable model per Imran Ghory analysis
|
||||
|
||||
*Agora applicability:* Limited. Agora's philosophy is full decentralization, not feature-gating. However, could offer:
|
||||
- Managed PDS with enterprise features (backup, compliance, SLA)
|
||||
- Advanced analytics dashboard for enterprise customers
|
||||
|
||||
*** 2. Hosting/Cloud Services ("X-as-a-Service")
|
||||
|
||||
*Definition:* Managed hosting of open source software. Customer pays for convenience, not software.
|
||||
|
||||
*Examples:*
|
||||
- WordPress.com (Automattic) vs WordPress.org (open source)
|
||||
- MongoDB Atlas: ~65% gross margins
|
||||
- Elastic Cloud: ~40% gross margins
|
||||
- WP Engine: Premium WordPress hosting
|
||||
|
||||
*Revenue characteristics:*
|
||||
- Recurring revenue (SaaS model)
|
||||
- High margins (40-65%)
|
||||
- Requires operational investment
|
||||
- Risk: Cloud providers (AWS) can compete
|
||||
|
||||
*Agora applicability:* *PRIMARY MODEL*
|
||||
|
||||
| Service | Description | Revenue Model |
|
||||
|---------|-------------|---------------|
|
||||
| PDS Hosting | Managed Personal Data Stores | Monthly subscription per user |
|
||||
| Relay Hosting | High-availability relay nodes | Usage-based (per message routed) |
|
||||
| Agora Cloud | Full managed Agora stack | Tiered subscriptions |
|
||||
| Backup Services | Encrypted PDS backups | Per-GB storage fees |
|
||||
|
||||
*** 3. Professional Services
|
||||
|
||||
*Definition:* Consulting, implementation, training, support contracts.
|
||||
|
||||
*Examples:*
|
||||
- Red Hat: Started here, moved to subscriptions
|
||||
- Cloudera: Hadoop consulting + support
|
||||
- Percona: MySQL/PostgreSQL support
|
||||
|
||||
*Revenue characteristics:*
|
||||
- Lower margins (requires headcount)
|
||||
- Unpredictable revenue
|
||||
- Good for initial traction
|
||||
- Often combined with other models
|
||||
|
||||
*Agora applicability:*
|
||||
- Enterprise implementation consulting
|
||||
- Custom PDS deployment
|
||||
- Migration services (from Twitter/Mastodon)
|
||||
- Training and certification programs
|
||||
|
||||
*** 4. Marketplace Model
|
||||
|
||||
*Definition:* Revenue from ecosystem transactions, not core software.
|
||||
|
||||
*Examples:*
|
||||
- Android: Google Play fees (30% on transactions)
|
||||
- WordPress.org: Marketplace for themes/plugins
|
||||
- Mozilla: $500M/year from Google search default
|
||||
|
||||
*Revenue characteristics:*
|
||||
- Network effects drive revenue
|
||||
- Low marginal cost
|
||||
- Requires large user base
|
||||
|
||||
*Agora applicability:* *NETWORK-LEVEL REVENUE*
|
||||
|
||||
| Revenue Stream | Mechanism |
|
||||
|----------------|-----------|
|
||||
| App Marketplace | Curated Agora apps, themes, plugins |
|
||||
| Transaction Fees | Micro-fees on marketplace transactions (not protocol) |
|
||||
| Premium Names | Auction for desirable persona names |
|
||||
| Verified Badges | Identity verification services |
|
||||
|
||||
** Agora-Specific Revenue Streams
|
||||
|
||||
*** Phase 1: Infrastructure Services (Immediate)
|
||||
|
||||
*PDS Hosting:*
|
||||
- Target: Non-technical users who want sovereignty without complexity
|
||||
- Pricing: $5-20/month tiers (competitive with Mastodon hosting)
|
||||
- Value prop: "Your data, your keys, our servers"
|
||||
|
||||
*Relay Node Operation:*
|
||||
- Target: Communities needing reliable message routing
|
||||
- Pricing: Pay-per-message or monthly capacity
|
||||
- Value prop: 99.9% uptime, geographic distribution
|
||||
|
||||
*Validator Oracle Network:*
|
||||
- Target: Developers needing CI/CD for Agora repos
|
||||
- Pricing: Per-test execution (satoshis)
|
||||
- Value prop: Decentralized testing, cryptographic attestations
|
||||
|
||||
*** Phase 2: Enterprise Services (Year 1-2)
|
||||
|
||||
*Enterprise Support:*
|
||||
- SLA-backed support for self-hosted Agora
|
||||
- 24/7 incident response
|
||||
- Custom feature development
|
||||
|
||||
*Compliance & Legal:*
|
||||
- GDPR/CCPA compliance tools
|
||||
- Legal Defense Collective membership
|
||||
- Audit and attestation services
|
||||
|
||||
*Integration Services:*
|
||||
- Legacy system bridges
|
||||
- Custom ActivityPub connectors
|
||||
- Enterprise SSO integration
|
||||
|
||||
*** Phase 3: Network Effects (Year 2+)
|
||||
|
||||
*Marketplace Commission:*
|
||||
- 5-10% on premium app sales
|
||||
- Not on protocol usage (that stays free)
|
||||
- Curated, high-quality apps only
|
||||
|
||||
*Data Services (Opt-in):*
|
||||
- Aggregated, anonymized trend analysis
|
||||
- Research partnerships
|
||||
- Always with user consent
|
||||
|
||||
*Premium Identity:*
|
||||
- Short name auctions (e.g., @user)- Verified organization badges
|
||||
- Domain verification services
|
||||
|
||||
** Financial Projections (Illustrative)
|
||||
|
||||
Based on comparable open source companies:
|
||||
|
||||
| Model | Gross Margin | Scalability | Time to Revenue |
|
||||
|-------|--------------|-------------|-----------------|
|
||||
| PDS Hosting | 60-70% | High | Immediate |
|
||||
| Relay Services | 50-60% | High | Immediate |
|
||||
| Professional Services | 30-40% | Low (headcount) | Immediate |
|
||||
| Marketplace | 80-90% | Very High | Year 2+ |
|
||||
| Enterprise Support | 70-80% | Medium | Year 1 |
|
||||
|
||||
** Strategic Recommendations
|
||||
|
||||
1. *Start with Hosting:* Fastest path to revenue, aligns with user needs
|
||||
2. *Avoid Open Core:* Contradicts Agora's decentralization ethos
|
||||
3. *Build Marketplace Early:* Even if low volume initially, establishes ecosystem
|
||||
4. *Professional Services Bridge:* Fund development while product matures
|
||||
5. *Network Revenue Last:* Requires scale, but highest margins
|
||||
|
||||
** Risk Mitigation
|
||||
|
||||
*Cloud Provider Competition:*
|
||||
- AWS/Azure could offer Agora hosting
|
||||
- Defense: First-mover advantage, community trust, Validator Oracle network effects
|
||||
- License: True open source (not SSPL) prevents lock-in fears
|
||||
|
||||
*Funding Gap:*
|
||||
- Services revenue is slower than VC-funded competitors
|
||||
- Mitigation: Grants (Filecoin, Ethereum, Bitcoin/Lightning ecosystems), crowdfunding
|
||||
|
||||
** Success Metrics
|
||||
|
||||
- Year 1: 1,000 paid PDS accounts ($10k MRR)
|
||||
- Year 2: 10,000 PDS + enterprise contracts ($100k MRR)
|
||||
- Year 3: Self-sustaining via marketplace + hosting ($500k MRR)
|
||||
|
||||
** Related
|
||||
|
||||
- [[file:20260314_rtx_pro_6000_llm.org][RTX Pro 6000 for Local LLM Inference]] (infrastructure for self-hosting)
|
||||
- [[file:agora-strategic-positioning.org][Agora Strategic Positioning]]
|
||||
- [[file:agora-lightning-economics.org][Agora Lightning Economics]]
|
||||
|
||||
** Sources
|
||||
|
||||
- Palark: "How companies make millions on Open Source" (Dec 2022)
|
||||
- Navdeep Yadav: "How do Open source companies like WordPress, Android, and MongoDB make money" (Nov 2022)
|
||||
- HashiCorp S-1 SEC filing (2021)
|
||||
- Forbes: "Monetizing Open Source: Business Models That Generate Billions" (Sep 2020)
|
||||
184
notes/20260314_cognition_first_agent_architecture.org
Normal file
184
notes/20260314_cognition_first_agent_architecture.org
Normal file
@@ -0,0 +1,184 @@
|
||||
#+TITLE: Cognition-First Agent Architecture: The Neurosymbolic Personal Computer
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+ID: 20260314_cognition_first_agent_architecture
|
||||
#+FILETAGS: agora architecture cognition agents neurosymbolic lisp-machines ai-systems
|
||||
|
||||
* Cognition-First Agent Architecture
|
||||
|
||||
** Core Insight
|
||||
|
||||
A truly intelligent personal agent should be designed as a *cognitive extension*—not a service that responds to queries, but a persistent, contextual, reasoning system that participates in the user's thinking process. This is distinct from current LLM-based agents (ChatGPT, Claude) which are stateless, conversational interfaces.
|
||||
|
||||
** Comparison: Current vs Cognition-First Design
|
||||
|
||||
| Aspect | Current LLM Agents (OpenClaw, ChatGPT) | Cognition-First Architecture |
|
||||
|--------|----------------------------------------|------------------------------|
|
||||
| Session model | Request-response, stateless | Persistent, image-based |
|
||||
| Memory | External files (MEMORY.md), inferred | Internal, continuous, learned |
|
||||
| Context | Loaded per conversation | Always resident, predictive |
|
||||
| Interaction | Conversational turns | Participatory, interrupt-driven |
|
||||
| Tool use | Fixed palette, discovery via docs | Dynamic composition, agent-driven |
|
||||
| Proactivity | Reactive (cron, user prompts) | Epistemic triggers, continuous |
|
||||
| Reasoning visibility | Hidden or binary (on/off) | Transparent, multi-draft, tagged |
|
||||
|
||||
** Philosophical Foundation
|
||||
|
||||
*** Lisp Machines as Precedent
|
||||
|
||||
Lisp machines (1970s-1980s) embodied key principles:
|
||||
- *Image-based persistence*: Workspace, definitions, and state continued across sessions
|
||||
- *Live environment*: The system was always running, always introspectable
|
||||
- *Homoiconicity*: Code and data shared the same structure, enabling meta-programming
|
||||
- *Personal computing*: Single-user machines optimized for the individual's workflow
|
||||
|
||||
The cognition-first agent revives this philosophy: your PDS is not storage but a *running cognitive environment*—an "image" that learns your patterns.
|
||||
|
||||
*** Neurosymbolic Computing
|
||||
|
||||
We are describing a neurosymbolic architecture:
|
||||
|
||||
- *Neural component (System 1)*: LLMs provide pattern recognition, generation, intuition
|
||||
- Fast, associative, context-sensitive
|
||||
- Handles ambiguity, natural language, creativity
|
||||
- Limited by context window, hallucination, no persistent memory
|
||||
|
||||
- *Symbolic component (System 2)*: The agent architecture provides structure, reasoning, persistence
|
||||
- Slow, deliberate, rule-based
|
||||
- Maintains knowledge graphs, executes plans, tracks epistemic state
|
||||
- Provides guardrails, verification, long-term memory
|
||||
|
||||
*Integration*: The neural system generates hypotheses; the symbolic system validates, structures, and persists them. Like human cognition—intuition proposes, reason disposes.
|
||||
|
||||
** Architectural Components
|
||||
|
||||
*** 1. Persistent Working Memory
|
||||
|
||||
Unlike OpenClaw's fresh-session model, a cognition-first agent maintains:
|
||||
- Conceptual graph of user's projects, interests, constraints
|
||||
- Active working set: "Currently tracking: Agora PDS, RTX Pro 6000 research, rack server migration"
|
||||
- Epistemic state: Confidence levels, open questions, contradictions
|
||||
|
||||
*Implementation*: The PDS becomes a *live object graph*—not files to read, but a runtime environment to inhabit.
|
||||
|
||||
*** 2. Predictive Context Loading
|
||||
|
||||
Instead of: "Read MEMORY.md and infer state"
|
||||
|
||||
The agent: "User is asking about GPUs → preload RTX Pro 6000 note, rack server research, budget constraints, prior hardware discussions → present integrated synthesis"
|
||||
|
||||
This mirrors how Emacs predictive loading works—you don't `cat` files, you navigate a living structure.
|
||||
|
||||
*** 3. Transparent Cognition
|
||||
|
||||
Current LLMs hide their reasoning (or stream it inscrutably).
|
||||
|
||||
Cognition-first design:
|
||||
- Visible *scratch* buffer where the agent works through problems
|
||||
- Multi-draft thinking: explores approaches, shows tradeoffs
|
||||
- Tagged reasoning: [Speculative], [High confidence], [Requires validation]
|
||||
- Meta-cognitive layer: "I don't know your stance on X—should I infer from context or ask?"
|
||||
|
||||
*** 4. Org-Mode as Native Interface
|
||||
|
||||
Not just reading/writing text—*participating in structure*:
|
||||
- Native AST understanding of Org semantics
|
||||
- Agenda integration: agent suggestions appear in user's agenda
|
||||
- Structural editing: refactor outlines, reorganize projects, archive completed items
|
||||
- Babel integration: agent "tangles" its reasoning into executable code
|
||||
|
||||
*** 5. Interrupt-Driven Proactivity
|
||||
|
||||
Not heartbeat polling but epistemic triggers:
|
||||
- "When user mentions hardware purchase → check budget constraints → suggest rack-mountable options"
|
||||
- "New note connects to 3 prior notes → gently surface connection graph"
|
||||
- "Stuck on problem for 3 days → agent found relevant paper during background research"
|
||||
|
||||
Like Emacs idle timers or process filters—event-driven, not polling.
|
||||
|
||||
** Position in Agora Architecture
|
||||
|
||||
*** The PDS as Lisp Image
|
||||
|
||||
In Agora v2:
|
||||
- PDS = Personal Data Store + Runtime Environment
|
||||
- Always-on background processes: indexing, connecting, surfacing
|
||||
- State survives restarts: "I was analyzing your research when you went offline—here's my interim conclusion"
|
||||
- Sub-agents share the same "image" (distributed cognition over unified graph)
|
||||
|
||||
*** Agent-as-Extension Pattern
|
||||
|
||||
- Each sub-agent is a specialized cognitive tool (research, coding, analysis)
|
||||
- They share context via the PDS graph
|
||||
- Hand-offs: "Research agent found paper → Analysis agent reading → Notifies user when ready"
|
||||
- Not chatbots—collaborative thinkers
|
||||
|
||||
*** Contrast with Current "AI Apps"
|
||||
|
||||
Current pattern: Wrapper around LLM API (+ vector DB, + prompts)
|
||||
- Stateless, generic, SaaS-centric
|
||||
|
||||
Agora pattern: Personal image-based agent runtime
|
||||
- Stateful, personal, local-first
|
||||
- LLMs are *substrate*, not product
|
||||
|
||||
** System 1 / System 2 Integration
|
||||
|
||||
| Function | System 1 (Neural/LLM) | System 2 (Symbolic/Agent) |
|
||||
|----------|----------------------|---------------------------|
|
||||
| Pattern matching | Generates associations | Structures into knowledge graph |
|
||||
| Text generation | Writes prose, code, summaries | Validates for consistency, sources |
|
||||
| Ambiguity handling | Navigates unclear requests | Tracks uncertainty, asks clarifying questions |
|
||||
| Creativity | Brainstorms, finds novel connections | Evaluates feasibility, checks constraints |
|
||||
| Memory | Context window (limited, ephemeral) | Persistent, queryable, versioned |
|
||||
| Reasoning | Intuitive leaps | Step-by-step, verifiable inference |
|
||||
|
||||
*Cooperation*: The neural system *proposes*; the symbolic system *disposes*.
|
||||
|
||||
** Implications for Agora Design
|
||||
|
||||
1. *Sub-agents need shared memory*: Not just passing messages—shared conceptual graph
|
||||
2. *PDS is runtime, not storage*: Always-on processes, background indexing
|
||||
3. *Org-mode is interface*: Native participation in user's thinking structure
|
||||
4. *Epistemic hygiene*: Track confidence, uncertainty, provenance
|
||||
5. *Graceful degradation*: LLM unavailable?Symbolic system continues with reduced capability
|
||||
|
||||
** Implementation Challenges
|
||||
|
||||
1. *Resource management*: Always-on agents consume compute even when idle
|
||||
2. *Conflict resolution*: Multiple sub-agents modifying shared state
|
||||
3. *Version control*: How to branch/merge an agent's "image"?
|
||||
4. *Debugging*: When agent reasoning goes wrong, traceability is crucial
|
||||
5. *User control*: Interrupt-driven proactivity risks notification fatigue
|
||||
|
||||
** Related Concepts
|
||||
|
||||
- Lisp machines (Symbolics, LMI): Image-based, personal, extensible
|
||||
- Emacs: The extensible, customizable, self-documenting real-time display editor
|
||||
- SOAR cognitive architecture: Problem-solving as state-space search
|
||||
- Kahneman's System 1/2: Dual-process theory of cognition
|
||||
- Neurosymbolic AI: Combining neural networks with symbolic reasoning
|
||||
|
||||
** Connections to Agora Documentation
|
||||
|
||||
- [[file:20260314_agora_open_source_business_models.org][Agora Open Source Business Models]]
|
||||
- [[file:agora-pds-relay-architecture.org][Agora PDS & Relay Architecture]]
|
||||
- [[file:20260314_org_gtd_automation_strategies.org][Org-GTD Automation Strategies]]
|
||||
- [[file:agora-requirements.org][Agora Requirements Specification]]
|
||||
|
||||
** Open Questions
|
||||
|
||||
1. How does this architecture scale to resource-constrained devices?
|
||||
2. What is the migration path from stateless (current) to stateful agents?
|
||||
3. How to handle agent "personality drift" over time?
|
||||
4. Can this architecture support collective intelligence (multiple users, shared cognition)?
|
||||
5. What are the security implications of always-on agents with deep personal knowledge?
|
||||
|
||||
** Conclusion
|
||||
|
||||
We are describing not an "AI assistant" but a *personal cognitive infrastructure*—a neurosymbolic system where neural networks provide associative intelligence and symbolic architecture provides structure, persistence, and reasoning. The Lisp machine philosophy, applied to modern AI, creating an environment where the boundary between human and machine cognition becomes a continuum rather than an interface.
|
||||
|
||||
#+begin_quote
|
||||
"The computer should be an extension of the mind, not a tool for the hand."
|
||||
— Paraphrasing J.C.R. Licklider, Man-Computer Symbiosis (1960)
|
||||
#+end_quote
|
||||
219
notes/20260314_org_gtd_automation_strategies.org
Normal file
219
notes/20260314_org_gtd_automation_strategies.org
Normal file
@@ -0,0 +1,219 @@
|
||||
#+TITLE: Org-GTD Automation Strategies for OpenClaw Integration
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+ID: 20260314_org_gtd_automation_strategies
|
||||
#+FILETAGS: org-mode gtd automation emacs org-gtd
|
||||
|
||||
* Research: Automating Org-GTD for OpenClaw Integration
|
||||
|
||||
** The Core Problem
|
||||
|
||||
`org-gtd.el` is designed for *interactive* Emacs use. Most functions rely on:
|
||||
- `point` being at a specific entry
|
||||
- Interactive prompts (`completing-read`, `yes-or-no-p`)
|
||||
- Context from the current buffer position
|
||||
|
||||
This creates friction for automation—OpenClaw cannot "stand on an item" like a human user.
|
||||
|
||||
** Approaches to Automation
|
||||
|
||||
*** Approach 1: ID-Based Operations (Recommended)
|
||||
|
||||
Org entries have unique IDs. We can use `org-id` to locate entries programmatically:
|
||||
|
||||
#+begin_src elisp
|
||||
;; Move to entry by ID, then execute org-gtd function
|
||||
(defun org-gtd-automate-by-id (entry-id command)
|
||||
"Execute org-gtd COMMAND at entry with ENTRY-ID."
|
||||
(let ((marker (org-id-find entry-id 'marker)))
|
||||
(when marker
|
||||
(with-current-buffer (marker-buffer marker)
|
||||
(goto-char (marker-position marker))
|
||||
(funcall command)))))
|
||||
|
||||
;; Example usage in batch mode:
|
||||
;; emacs --batch -l org-gtd \
|
||||
;; --eval '(org-gtd-automate-by-id "my-entry-id" #'org-gtd-archive-item)'
|
||||
#+end_src
|
||||
|
||||
*Advantages:*
|
||||
- Works with any org-gtd function
|
||||
- No regex parsing needed
|
||||
- Preserves all org-gtd logic
|
||||
|
||||
*Limitations:*
|
||||
- Requires entries to have IDs (add `:ID:` property)
|
||||
- Functions with interactive prompts will still block
|
||||
|
||||
*** Approach 2: Custom Non-Interactive Wrappers
|
||||
|
||||
Write wrapper functions that accept arguments instead of using interactive prompts:
|
||||
|
||||
#+begin_src elisp
|
||||
(defun org-gtd-set-status-noninteractive (entry-id new-status)
|
||||
"Set status of entry with ENTRY-ID to NEW-STATUS (TODO, NEXT, WAIT, DONE)."
|
||||
(let ((marker (org-id-find entry-id 'marker)))
|
||||
(when marker
|
||||
(with-current-buffer (marker-buffer marker)
|
||||
(goto-char (marker-position marker))
|
||||
(org-todo new-status)))))
|
||||
|
||||
(defun org-gtd-archive-by-id (entry-id)
|
||||
"Archive entry with ENTRY-ID."
|
||||
(let ((marker (org-id-find entry-id 'marker)))
|
||||
(when marker
|
||||
(with-current-buffer (marker-buffer marker)
|
||||
(goto-char (marker-position marker))
|
||||
(org-archive-subtree)))))
|
||||
#+end_src
|
||||
|
||||
*Advantages:*
|
||||
- Clean API for batch operations
|
||||
- No interactive prompts
|
||||
- Can chain multiple operations
|
||||
|
||||
*** Approach 3: Plain Org Mode (Most Automation-Friendly)
|
||||
|
||||
Instead of `org-gtd.el`, use standard Org features that are designed for automation:
|
||||
|
||||
#+begin_src org
|
||||
,* TODO Project Alpha
|
||||
:PROPERTIES:
|
||||
:ID: proj-alpha-001
|
||||
:CATEGORY: proj-alpha
|
||||
:GTD_TYPE: project
|
||||
:END:
|
||||
,** NEXT First action
|
||||
:PROPERTIES:
|
||||
:ID: action-001
|
||||
:GTD_TYPE: next
|
||||
:END:
|
||||
,** TODO Second action
|
||||
,** WAIT Waiting for response
|
||||
|
||||
,* TODO Standalone next action :context_home:
|
||||
:PROPERTIES:
|
||||
:GTD_TYPE: next
|
||||
:END:
|
||||
#+end_src
|
||||
|
||||
*Standard Org functions I can use:*
|
||||
- `org-todo` — Change TODO state
|
||||
- `org-set-property` — Set/change properties
|
||||
- `org-archive-subtree` — Archive entries
|
||||
- `org-refile` — Move entries between files
|
||||
- `org-id-find` — Locate by ID
|
||||
- `org-map-entries` — Batch operations across entries
|
||||
|
||||
** File Structure for Automation
|
||||
|
||||
*Recommended layout:*
|
||||
|
||||
#+begin_example
|
||||
~/memex/gtd/
|
||||
├── inbox.org # Captured items (process to main)
|
||||
├── main.org # Active projects and next actions
|
||||
├── someday.org # Someday/maybe items
|
||||
├── waiting.org # Delegated/waiting items
|
||||
├── archive.org # Completed items
|
||||
└── templates/ # Capture templates
|
||||
#+end_example
|
||||
|
||||
** Comparison: org-gtd.el vs Plain Org
|
||||
|
||||
| Feature | org-gtd.el | Plain Org |
|
||||
|---------|------------|-----------|
|
||||
| Interactive workflow | Excellent | Good |
|
||||
| Batch automation | Poor | Excellent |
|
||||
| Learning curve | Medium | Low |
|
||||
| Community support | Active | Massive |
|
||||
| GTD semantics | Built-in | Manual setup |
|
||||
| Custom agenda views | Good | Excellent |
|
||||
|
||||
** Recommendation
|
||||
|
||||
For your use case (hybrid interactive + automation):
|
||||
|
||||
1. *Use plain Org Mode* with custom properties for GTD semantics
|
||||
2. *Define your own TODO states:* TODO → NEXT → WAIT → DONE/CNCL
|
||||
3. *Use ID properties* on all entries for automation targeting
|
||||
4. *Create agenda views* for daily/weekly reviews
|
||||
5. *Reserve interactive work* for capture, clarification, and review
|
||||
6. *Use automation for:*
|
||||
- Archiving completed items
|
||||
- Moving waiting items to active
|
||||
- Generating reports
|
||||
- Refiling from inbox to projects
|
||||
|
||||
** Sample Automation Commands
|
||||
|
||||
*Archive all DONE items over 30 days old:*
|
||||
|
||||
#+begin_src elisp
|
||||
(defun org-gtd-archive-old-done ()
|
||||
"Archive DONE items older than 30 days."
|
||||
(org-map-entries
|
||||
(lambda ()
|
||||
(when (string= (org-get-todo-state) "DONE")
|
||||
(let ((closed (org-entry-get nil "CLOSED")))
|
||||
(when (and closed
|
||||
(> (org-time-stamp-to-now closed) 30))
|
||||
(org-archive-subtree)))))
|
||||
t 'agenda))
|
||||
#+end_src
|
||||
|
||||
*Find stuck projects (PROJ without NEXT):*
|
||||
|
||||
#+begin_src elisp
|
||||
(defun org-gtd-find-stuck-projects ()
|
||||
"Return list of IDs for projects without NEXT actions."
|
||||
(let (stuck)
|
||||
(org-map-entries
|
||||
(lambda ()
|
||||
(when (string= (org-get-todo-state) "PROJ")
|
||||
(let ((id (org-entry-get nil "ID"))
|
||||
(has-next nil))
|
||||
(org-map-entries
|
||||
(lambda ()
|
||||
(when (string= (org-get-todo-state) "NEXT")
|
||||
(setq has-next t)))
|
||||
nil 'tree)
|
||||
(unless has-next
|
||||
(push id stuck))))))
|
||||
stuck))
|
||||
#+end_src
|
||||
|
||||
** Integration Points with OpenClaw
|
||||
|
||||
*OpenClaw can:*
|
||||
1. Read your gtd.org files to find next actions
|
||||
2. Create new entries via `write` tool (append to inbox.org)
|
||||
3. Archive completed items by locating via ID
|
||||
4. Generate weekly reports (parse files, output summaries)
|
||||
5. Trigger reviews based on HEARTBEAT.md schedules
|
||||
|
||||
*OpenClaw cannot (easily):*
|
||||
1. Toggle states interactively (requires cursor position)
|
||||
2. Process inbox items (clarification requires human judgment)
|
||||
3. Run org-agenda (needs Emacs UI)
|
||||
|
||||
** Summary
|
||||
|
||||
- org-gtd.el is optimized for *interactive* use
|
||||
- Batch automation works best with *plain Org + ID properties*
|
||||
- Consider a hybrid: org-gtd for capture/review, custom functions for automation
|
||||
- The "projects as hierarchy" approach (from Desmond Rivet's blog) is automation-friendly
|
||||
|
||||
** Related
|
||||
|
||||
- [[file:20260314_agora_open_source_business_models.org][Agora Open Source Business Models]]
|
||||
- [[file:agora-pds-relay-architecture.org][Agora PDS & Relay Architecture]]
|
||||
- Desmond Rivet's GTD implementation: https://desmondrivet.com/2023/12/05/gtd-org-mode
|
||||
- org-gtd.el: https://github.com/Trevoke/org-gtd.el
|
||||
|
||||
** Next Steps
|
||||
|
||||
TODO Test org-id based automation on sample files
|
||||
TODO Create wrapper functions for common operations
|
||||
TODO Design plain Org GTD structure for memex
|
||||
TODO Implement capture templates for OpenClaw integration
|
||||
150
notes/20260314_pds_hosting_competitive_pricing.org
Normal file
150
notes/20260314_pds_hosting_competitive_pricing.org
Normal file
@@ -0,0 +1,150 @@
|
||||
#+TITLE: PDS Hosting Competitive Pricing Analysis
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+ID: 20260314_pds_hosting_competitive_pricing
|
||||
#+FILETAGS: agora business pricing pds hosting competitive-analysis
|
||||
|
||||
* PDS Hosting Competitive Pricing Analysis
|
||||
|
||||
** Purpose
|
||||
|
||||
Benchmark pricing for Agora Personal Data Store (PDS) hosting services against existing decentralized social network hosting providers.
|
||||
|
||||
** Mastodon Managed Hosting Benchmarks
|
||||
|
||||
*** Masto.host (Market Leader)
|
||||
|
||||
*Personal/Small Group Plans:*
|
||||
|
||||
| Plan | Price | Database | Media Storage | Users | Processing Threads |
|
||||
|------|-------|----------|---------------|-------|------------------|
|
||||
| Moon | $6/mo | 2 GB | 20 GB | 5 active | 2 threads |
|
||||
| Planet | $9/mo | 5 GB | 50 GB | 20 active | 4 threads |
|
||||
| Star | $19/mo | 10 GB | 100 GB | 100 active | 8 threads |
|
||||
|
||||
*Community Plans:*
|
||||
|
||||
| Plan | Price | Database | Media Storage | Users | Processing Threads |
|
||||
|------|-------|----------|---------------|-------|------------------|
|
||||
| Constellation | $39/mo | 20 GB | 200 GB | 500 active | 20 threads |
|
||||
| Galaxy | $89/mo | 40 GB | 400 GB | 2000 active | 50 threads |
|
||||
|
||||
*Add-ons:*
|
||||
- Extra Resources: $10/month (adds 4 threads, 4 GB DB, 40 GB storage)
|
||||
- ElasticSearch: $5-10/month (full-text search)
|
||||
|
||||
*All plans include:*
|
||||
- Hosting and maintenance
|
||||
- Automatic installation and updates
|
||||
- Email notifications
|
||||
- Daily remote backups
|
||||
- Free subdomain or custom domain
|
||||
- TLS certificate (Let's Encrypt)
|
||||
- Automated cache deletion
|
||||
|
||||
** Bluesky PDS Hosting
|
||||
|
||||
*Current State:*
|
||||
- Bluesky operates on the AT Protocol
|
||||
- PDS (Personal Data Server) is self-hostable
|
||||
- Limited commercial PDS hosting providers (ecosystem still emerging)
|
||||
- Most users currently on Bluesky's official PDS (free, but centralized)
|
||||
|
||||
*Self-Hosting Requirements (from AT Protocol docs):*
|
||||
- Minimum: 2 CPU cores, 4 GB RAM, 20 GB storage
|
||||
- Recommended: 4+ CPU cores, 8 GB RAM, 100 GB+ storage
|
||||
- Cost equivalent: ~$10-40/month on VPS (DigitalOcean, AWS, etc.)
|
||||
|
||||
** Other Mastodon Hosting Providers
|
||||
|
||||
*Pricing comparison (estimated from market research):*
|
||||
|
||||
| Provider | Entry Price | Entry Specs | Notes |
|
||||
|----------|-------------|-------------|-------|
|
||||
| Masto.host | $6/mo | 2GB DB, 20GB media | Market leader, reliable |
|
||||
| Spacebear | €5/mo (~$5.50) | Similar to Moon | EU-based |
|
||||
| Fosstodon | $5/mo | Community-focused | Non-profit |
|
||||
| Self-hosted | $5-20/mo | Variable | Requires technical skill |
|
||||
|
||||
** Agora PDS Hosting Recommendations
|
||||
|
||||
*** Pricing Strategy
|
||||
|
||||
*Positioning:* Match or slightly undercut Masto.host (market leader)
|
||||
|
||||
*Recommended Tiers:*
|
||||
|
||||
| Tier | Price | Storage | Features | Target |
|
||||
|------|-------|---------|----------|--------|
|
||||
| Seed | $5/mo | 10 GB | Basic PDS, backups | Individual users |
|
||||
| Sprout | $10/mo | 50 GB | PDS + Relay access | Active users |
|
||||
| Tree | $20/mo | 200 GB | PDS + Relay + Priority | Power users |
|
||||
| Forest | $50/mo | 1 TB | Enterprise PDS cluster | Communities |
|
||||
|
||||
*Key differentiators from Mastodon:*
|
||||
1. *Lightning-native payments* (not credit card only)
|
||||
2. *PDS + Relay bundled* (Mastodon separates these)
|
||||
3. *Validator Oracle credits* included (for developers)
|
||||
4. *Cross-platform identity* (not just Mastodon federation)
|
||||
|
||||
*** Revenue Projections
|
||||
|
||||
*Conservative (Year 1):*
|
||||
- 100 Seed users: $500/month
|
||||
- 50 Sprout users: $500/month
|
||||
- 20 Tree users: $400/month
|
||||
- *Total: $1,400/month ($16,800/year)*
|
||||
|
||||
*Optimistic (Year 2):*
|
||||
- 500 Seed users: $2,500/month
|
||||
- 200 Sprout users: $2,000/month
|
||||
- 100 Tree users: $2,000/month
|
||||
- 10 Forest users: $500/month
|
||||
- *Total: $7,000/month ($84,000/year)*
|
||||
|
||||
** Technical Cost Basis
|
||||
|
||||
*Infrastructure costs (estimated):*
|
||||
|
||||
| User Tier | Server Cost | Storage Cost | Margin |
|
||||
|-----------|-------------|--------------|--------|
|
||||
| Seed ($5) | ~$2/mo | ~$0.50/mo | ~50% |
|
||||
| Sprout ($10) | ~$4/mo | ~$2/mo | ~40% |
|
||||
| Tree ($20) | ~$8/mo | ~$5/mo | ~35% |
|
||||
| Forest ($50) | ~$20/mo | ~$10/mo | ~40% |
|
||||
|
||||
*Note:* Margins improve with scale (shared infrastructure, bulk storage).
|
||||
|
||||
** Competitive Advantages
|
||||
|
||||
1. *Protocol-level integration:* PDS + Relay + Validator Oracles as unified service
|
||||
2. *Bitcoin/Lightning payments:* Lower fees, better privacy, global accessibility
|
||||
3. *Sovereign identity:* Users truly own their data (not just "managed hosting")
|
||||
4. *No vendor lock-in:* Easy export/migration (content-addressed data)
|
||||
5. *Community governance:* Revenue shares with Relay operators
|
||||
|
||||
** Risks
|
||||
|
||||
1. *Market education:* Users don't yet understand PDS concept
|
||||
2. *Competition:* Bluesky may offer free PDS hosting long-term
|
||||
3. *Technical complexity:* PDS setup harder than Mastodon
|
||||
4. *Scale economics:* Need ~500+ users to reach profitability
|
||||
|
||||
** Next Steps
|
||||
|
||||
TODO Validate pricing with potential users
|
||||
TODO Build MVP PDS hosting infrastructure
|
||||
TODO Create cost calculator for infrastructure planning
|
||||
TODO Research VPS/reseller hosting partnerships
|
||||
|
||||
** Related
|
||||
|
||||
- [[file:20260314_agora_open_source_business_models.org][Agora Open Source Business Models]]
|
||||
- [[file:agora-pds-relay-architecture.org][Agora PDS & Relay Architecture]]
|
||||
- [[file:agora-lightning-economics.org][Agora Lightning Economics]]
|
||||
|
||||
** Sources
|
||||
|
||||
- Masto.host pricing: https://masto.host/pricing/ (accessed 2026-03-14)
|
||||
- AT Protocol documentation: https://atproto.com/
|
||||
- Mastodon hosting market research (various providers)
|
||||
104
notes/20260314_rtx_pro_6000_llm.org
Normal file
104
notes/20260314_rtx_pro_6000_llm.org
Normal file
@@ -0,0 +1,104 @@
|
||||
#+TITLE: RTX Pro 6000 for Local LLM Inference
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+ID: 20260314_rtx_pro_6000_llm
|
||||
#+FILETAGS: hardware gpu ai llm inference nvidia
|
||||
|
||||
* RTX Pro 6000 Blackwell for Local LLM Inference
|
||||
|
||||
** The Headline
|
||||
|
||||
The RTX Pro 6000 Workstation Edition is a 96GB GDDR7 single-GPU solution that can replace a 4x RTX 4090 setup for 30B parameter models, with headroom for 70B models in FP8 quantization.
|
||||
|
||||
** Key Specifications
|
||||
|
||||
| Spec | RTX Pro 6000 | RTX 5090 | H100 PCIe |
|
||||
|------|--------------|----------|-----------|
|
||||
| VRAM | 96GB GDDR7 | 32GB GDDR7 | 80GB HBM2e |
|
||||
| Memory Bandwidth | 1.792 TB/s | 1.792 TB/s | 2.0 TB/s |
|
||||
| Architecture | Blackwell | Blackwell | Hopper |
|
||||
| FP4 Support | Yes | Yes | No |
|
||||
| FP8 Support | Yes | Yes | Yes |
|
||||
| NVLink | No | No | No (PCIe) |
|
||||
| ECC Memory | Yes | No | Yes |
|
||||
| Form Factor | Workstation PCIe | Consumer PCIe | PCIe/SXM |
|
||||
|
||||
** What Fits in 96GB VRAM
|
||||
|
||||
| Model | Size | Precision | Fits? | Notes |
|
||||
|-------|------|-----------|-------|-------|
|
||||
| Llama 3.1 | 8B | FP16 | Yes | ~16GB (17% of VRAM) |
|
||||
| Qwen2.5 | 14B | FP16 | Yes | ~28GB, ~68GB headroom |
|
||||
| Qwen2.5 | 32B | FP8 | Yes | ~32GB, ~64GB headroom |
|
||||
| Qwen2.5 | 32B | FP16 | Yes | ~64GB, ~32GB headroom |
|
||||
| Llama 3.3 | 70B | Q4 (AWQ) | Yes | ~35-40GB, 56-61GB headroom |
|
||||
| Llama 3.3 | 70B | FP8 | Yes | ~70GB, ~26GB headroom |
|
||||
| Llama 3.3 | 70B | FP16 | No | ~140GB needed |
|
||||
| Mixtral 8x7B | ~47B | Q4 | Yes | ~24GB, comfortable |
|
||||
| Mixtral 8x7B | ~47B | FP16 | No | ~94GB, no KV cache headroom |
|
||||
|
||||
** Benchmark Highlights
|
||||
|
||||
CloudRift benchmarks (Oct 2025):
|
||||
|
||||
| GPU | Model | Precision | Tokens/sec |
|
||||
|-----|-------|-----------|------------|
|
||||
| RTX Pro 6000 | Qwen3-Coder-30B-AWQ | AWQ | ~8,400 |
|
||||
| 4x RTX 4090 | Qwen3-Coder-30B-AWQ | AWQ | ~8,900 |
|
||||
|
||||
*One GPU versus four, with near-identical throughput and lower power draw.*
|
||||
|
||||
** Cost Comparison (Cloud Pricing, March 2026)
|
||||
|
||||
| GPU | On-demand $/hr | Spot $/hr | VRAM | Fits 70B FP8? |
|
||||
|-----|---------------|-----------|------|---------------|
|
||||
| RTX 5090 | $0.76 | — | 32GB | No |
|
||||
| RTX Pro 6000 | $1.65 | $0.72 | 96GB | Yes (~26GB headroom) |
|
||||
| H100 PCIe | $2.01 | — | 80GB | Yes (~10GB headroom) |
|
||||
| H200 SXM5 | $4.23 | $1.43 | 141GB | Yes (extensive) |
|
||||
|
||||
** Best Use Cases
|
||||
|
||||
1. *30B model inference at high throughput* — Replaces 4x RTX 4090 setup
|
||||
2. *32B models in FP8/FP16* — Single GPU, no tensor parallelism needed
|
||||
3. *70B models in Q4/FP8* — Fits comfortably with KV cache headroom
|
||||
4. *Development/testing* — $0.72/hr spot pricing for experimentation
|
||||
5. *Diffusion pipelines* — SDXL + ControlNet + LoRA stacks simultaneously
|
||||
|
||||
** Limitations
|
||||
|
||||
- No NVLink — cannot scale beyond 96GB with tensor parallelism
|
||||
- No MIG partitioning — not for multi-tenant enterprise serving
|
||||
- 70B FP16 won't fit — need H200 (141GB) or multi-GPU
|
||||
- High-batch throughput — H100 SXM wins at maximum concurrency (3.35 TB/s HBM3)
|
||||
|
||||
** Strategic Assessment
|
||||
|
||||
For a personal/enthusiast rack-mounted setup:
|
||||
|
||||
*Pros:*
|
||||
- 96GB VRAM covers 95% of practical local LLM use cases
|
||||
- Single-GPU simplicity (no multi-GPU orchestration)
|
||||
- Blackwell FP4 support (doubles throughput vs FP8)
|
||||
- Lower cost per token than H100 for 30B workloads
|
||||
- ECC memory for reliability
|
||||
|
||||
*Cons:*
|
||||
- No upgrade path beyond 96GB (no NVLink)
|
||||
- GDDR7 bandwidth (1.792 TB/s) vs HBM3 (3.35 TB/s) matters at extreme concurrency
|
||||
- Workstation GPU, not datacenter (no MIG, no cluster integration)
|
||||
|
||||
** Verdict
|
||||
|
||||
The RTX Pro 6000 is the sweet spot for a *modular, upgradable* home lab. It won't match an 8x H100 cluster, but it doesn't need to. For single-user inference, development, and experimentation with models up to 70B parameters, it's the most practical high-VRAM option available.
|
||||
|
||||
** Sources
|
||||
|
||||
- Spheron Network: "NVIDIA RTX PRO 6000 Blackwell for AI" (March 2026)
|
||||
- CloudRift: "RTX 4090 vs RTX 5090 vs RTX PRO 6000: Comprehensive LLM Inference Benchmark" (Oct 2025)
|
||||
- Medium/Data Science Collective: "Benchmarking LLM Inference on NVIDIA B200, H200, H100, and RTX PRO 6000" (Feb 2026)
|
||||
|
||||
** Related
|
||||
|
||||
- [[file:20260313_gemini_embedding_2.org][Gemini Embedding-2 Research]]
|
||||
- [[file:20260311_agora_v2_gap_analysis.org][Agora v2 Gap Analysis]]
|
||||
9
notes/README.org
Normal file
9
notes/README.org
Normal file
@@ -0,0 +1,9 @@
|
||||
#+TITLE: Atomic Notes (Zettelkasten)
|
||||
#+AUTHOR: User
|
||||
#+CREATED: [2026-03-17 Tue]
|
||||
#+BEGIN_COMMENT
|
||||
Evergreen, atomic notes. Each file represents a single concept, is heavily interlinked, and uses snake_case filenames without dates.
|
||||
#+END_COMMENT
|
||||
|
||||
* Atomic Notes (Zettelkasten)
|
||||
Evergreen, atomic notes. Each file represents a single concept, is heavily interlinked, and uses snake_case filenames without dates.
|
||||
132
notes/android-git-clients.org
Normal file
132
notes/android-git-clients.org
Normal file
@@ -0,0 +1,132 @@
|
||||
#+TITLE: Modern Android Git Clients
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+DATE: 2026-03-06
|
||||
#+FILETAGS: :tools:git:android:sync
|
||||
|
||||
* Android Git Client Options for ~/mind Sync
|
||||
|
||||
** Recommendation: GitJournal ⭐ (Best for Org-Mode)
|
||||
|
||||
*** Overview
|
||||
- *Purpose-built for note-taking* with Git sync
|
||||
- *Offline-first* - Works without connectivity
|
||||
- *Built with Flutter* - Modern, actively maintained (last update ~2 months ago)
|
||||
- *Open source / FOSS* - GitHub: GitJournal/GitJournal
|
||||
- *Works with any Git host* - GitHub, GitLab, self-hosted via SSH
|
||||
|
||||
*** Key Features for Org-Mode
|
||||
- ✅ Markdown and Org-mode support (experimental)
|
||||
- ✅ Folder-based organization
|
||||
- ✅ Auto-sync to Git repository
|
||||
- ✅ Works offline, syncs when connected
|
||||
- ✅ No account required
|
||||
- ✅ No ads
|
||||
|
||||
*** Installation
|
||||
- Google Play: https://play.google.com/store/apps/details?id=io.gitjournal.gitjournal
|
||||
- F-Droid: Available
|
||||
- GitHub: https://github.com/GitJournal/GitJournal
|
||||
|
||||
*** Setup for ~/mind
|
||||
1. Clone ~/mind repo via SSH: `git@your-host:~/mind.git`
|
||||
2. Set up auto-sync (on save or manual)
|
||||
3. Edit org files in GitJournal
|
||||
4. Changes auto-committed and pushed
|
||||
|
||||
*** Pros
|
||||
- Designed specifically for this workflow
|
||||
- Excellent for org-mode notes
|
||||
- Two-way sync with conflict handling
|
||||
- Active development (Flutter-based)
|
||||
- Works with any Git provider (not just GitHub)
|
||||
|
||||
*** Cons
|
||||
- Org-mode support flagged as "experimental"
|
||||
- May need Termux for advanced Git operations
|
||||
- Simpler than full Git client
|
||||
|
||||
---
|
||||
|
||||
** Alternative: Termux (Most Powerful)
|
||||
|
||||
*** Overview
|
||||
- *Full Linux terminal on Android*
|
||||
- *Complete Git command line*
|
||||
- Supports SSH, git-lfs, submodule
|
||||
|
||||
*** Installation
|
||||
```bash
|
||||
# From F-Droid
|
||||
pkg install git openssh
|
||||
```
|
||||
|
||||
*** Setup for ~/mind
|
||||
```bash
|
||||
# In Termux
|
||||
cd ~
|
||||
git clone ssh://user@your-host/path/to/mind.git
|
||||
# Edit with any text editor
|
||||
# Git commands for commit/push/pull
|
||||
```
|
||||
|
||||
*** Pros
|
||||
- Full Git functionality
|
||||
- Works with orgzly (edit files, use Termux for Git)
|
||||
- SSH agent support
|
||||
- Most powerful option
|
||||
|
||||
*** Cons
|
||||
- Command line only
|
||||
- More complex workflow
|
||||
- Requires context switching between apps
|
||||
|
||||
---
|
||||
|
||||
** Comparison Matrix
|
||||
|
||||
| Feature | GitJournal | Termux |
|
||||
|---------|------------|--------|
|
||||
| UI | GUI app | Terminal |
|
||||
| Org-mode | Experimental, but works | Full support |
|
||||
| Offline | ✅ Yes | ✅ Yes |
|
||||
| Auto-sync | ✅ Built-in | Manual/script |
|
||||
| SSH Keys | ✅ Supported | ✅ Supported |
|
||||
| Conflict handling | ✅ Yes | Manual merge |
|
||||
| Learning curve | Low | Medium |
|
||||
| Best for | Daily notes sync | Power users |
|
||||
|
||||
---
|
||||
|
||||
** Recommendation
|
||||
|
||||
*For your use case (org-mode + ~/mind):*
|
||||
|
||||
🥇 *Try GitJournal first*
|
||||
- Purpose-built for note-taking with Git
|
||||
- Should handle basic org-mode editing
|
||||
- Auto-sync reduces friction
|
||||
- Can fall back to Termux if needed
|
||||
|
||||
🥈 *Keep Termux as backup*
|
||||
- For complex Git operations
|
||||
- For merge conflict resolution
|
||||
- For full org-mode editing features
|
||||
|
||||
---
|
||||
|
||||
** Next Steps
|
||||
|
||||
1. Install GitJournal from Play Store
|
||||
2. Clone ~/mind via SSH
|
||||
3. Test org-mode editing
|
||||
4. Set up auto-sync
|
||||
5. If issues, use GitJournal + Termux hybrid
|
||||
|
||||
** Fallback:**
|
||||
If GitJournal org-mode support isn't sufficient:
|
||||
- Use *GitJournal* for sync
|
||||
- Use *Orgzly* for editing
|
||||
- Use *Termux* for Git operations
|
||||
|
||||
Three-app workflow but each optimized for its task.
|
||||
18
notes/closos_attributed_object_store.org
Normal file
18
notes/closos_attributed_object_store.org
Normal file
@@ -0,0 +1,18 @@
|
||||
#+TITLE: CLOSOS: Attributed Object Store
|
||||
#+ID: closos-attributed-object-store
|
||||
#+DATE: 2026-03-22
|
||||
#+FILETAGS: :architecture:lisp:os:closos:database:
|
||||
|
||||
* Concept
|
||||
The traditional hierarchical file system (folders and files) is replaced by a system-wide database of objects retrieved via key/value attributes.
|
||||
|
||||
* Key Principles
|
||||
- **Attribute-Based Retrieval:** Objects are not "located" in a path but retrieved via metadata (e.g., `:author`, `:date`, `:category`).
|
||||
- **Semantic Storage:** Data maintains its structural meaning. A "Note" or "Document" is a Lisp object, not just a raw byte stream.
|
||||
- **Directories as Objects:** Directories are simply specialized objects containing a list of object entries and their attributes, allowing for non-hierarchical organization where one directory can store another.
|
||||
|
||||
* Source
|
||||
:PROPERTIES:
|
||||
:ID: 9c69a9ab-1c96-490e-9a8e-fbeafacba30e
|
||||
:END:
|
||||
- [[attachment:strandh-lispos.pdf][Robert Strandh, "CLOSOS: Specification of a Lisp operating system" (2013)]]
|
||||
18
notes/closos_memory_persistence.org
Normal file
18
notes/closos_memory_persistence.org
Normal file
@@ -0,0 +1,18 @@
|
||||
#+TITLE: CLOSOS: Persistence by Default (Single Memory Abstraction)
|
||||
#+ID: closos-memory-persistence
|
||||
#+DATE: 2026-03-22
|
||||
#+FILETAGS: :architecture:lisp:os:closos:persistence:
|
||||
|
||||
* Concept
|
||||
CLOSOS eliminates the distinction between volatile primary memory (RAM) and permanent secondary memory (Disk). Primary memory functions as a transparent cache for a persistent object store.
|
||||
|
||||
* Key Principles
|
||||
- **The Living Image:** The system state is permanent. "Saving" is not an explicit user action; changes are inherently persistent in the object store.
|
||||
- **Undo Facility:** Since data is permanent, application writers are encouraged to implement sophisticated undo/redo facilities rather than manual file saves.
|
||||
- **Atomic Snapshots:** High-integrity state is maintained via atomic flips and log-structured techniques, ensuring the system can recover from crashes without data loss.
|
||||
|
||||
* Source
|
||||
:PROPERTIES:
|
||||
:ID: 9c69a9ab-1c96-490e-9a8e-fbeafacba30e
|
||||
:END:
|
||||
- [[attachment:strandh-lispos.pdf][Robert Strandh, "CLOSOS: Specification of a Lisp operating system" (2013)]]
|
||||
18
notes/closos_multiple_environments.org
Normal file
18
notes/closos_multiple_environments.org
Normal file
@@ -0,0 +1,18 @@
|
||||
#+TITLE: CLOSOS: Multiple Simultaneous Environments
|
||||
#+ID: closos-multiple-environments
|
||||
#+DATE: 2026-03-22
|
||||
#+FILETAGS: :architecture:lisp:os:closos:security:
|
||||
|
||||
* Concept
|
||||
CLOSOS supports multiple simultaneous global environments, where an environment is a mapping from names to objects (functions, classes, packages).
|
||||
|
||||
* Key Principles
|
||||
- **Isolation by Scope:** Each user or process can operate in a private environment. Redefining a system function (like `print-object`) in one environment does not affect other users.
|
||||
- **Dynamic Adaptability:** Facilitates safe experimentation with new features without risking system-wide corruption.
|
||||
- **Late Binding:** References are resolved against the current environment at compile/load time, enabling live updates and hot-reloading.
|
||||
|
||||
* Source
|
||||
:PROPERTIES:
|
||||
:ID: 9c69a9ab-1c96-490e-9a8e-fbeafacba30e
|
||||
:END:
|
||||
- [[attachment:strandh-lispos.pdf][Robert Strandh, "CLOSOS: Specification of a Lisp operating system" (2013)]]
|
||||
18
notes/closos_protection_mechanisms.org
Normal file
18
notes/closos_protection_mechanisms.org
Normal file
@@ -0,0 +1,18 @@
|
||||
#+TITLE: CLOSOS: Language-Based Protection Mechanisms
|
||||
#+ID: closos-protection-mechanisms
|
||||
#+DATE: 2026-03-22
|
||||
#+FILETAGS: :architecture:lisp:os:closos:security:
|
||||
|
||||
* Concept
|
||||
Security in a Lisp OS is enforced by the compiler and runtime environment rather than traditional hardware MMU (Memory Management Unit) boundaries.
|
||||
|
||||
* Key Principles
|
||||
- **Controlled Access System:** The system is "closed" by the compiler. Only code produced by the trusted compiler—which excludes arbitrary pointer arithmetic and includes bounds checking—is allowed to execute in supervisor mode.
|
||||
- **Tagged Pointers:** Objects are manipulated via tagged pointers. Access rights (read/write/execute) can be embedded directly into the tag bits of the pointer itself.
|
||||
- **Capabilities:** Pointers function as capabilities. Possession of a pointer to an object implies the authority to interact with it according to the embedded access tags.
|
||||
|
||||
* Source
|
||||
:PROPERTIES:
|
||||
:ID: 9c69a9ab-1c96-490e-9a8e-fbeafacba30e
|
||||
:END:
|
||||
- [[attachment:strandh-lispos.pdf][Robert Strandh, "CLOSOS: Specification of a Lisp operating system" (2013)]]
|
||||
18
notes/closos_single_address_space.org
Normal file
18
notes/closos_single_address_space.org
Normal file
@@ -0,0 +1,18 @@
|
||||
#+TITLE: CLOSOS: Single Address Space Architecture
|
||||
#+ID: closos-single-address-space
|
||||
#+DATE: 2026-03-22
|
||||
#+FILETAGS: :architecture:lisp:os:closos:
|
||||
|
||||
* Concept
|
||||
In a Lisp Operating System (CLOSOS), all applications and the system kernel share one large, unified 64-bit address space.
|
||||
|
||||
* Key Principles
|
||||
- **Removal of IPC:** Standard Unix-style Inter-Process Communication (pipes, sockets) is replaced by global pointer sharing. Applications communicate by passing pointers to objects directly.
|
||||
- **Unified Memory:** Eliminates the overhead of data serialization/deserialization between isolated process boundaries.
|
||||
- **Language-Based Security:** Protection is not enforced by hardware MMU boundaries but by the Lisp compiler and runtime (e.g., strong typing, bounds checking, no arbitrary pointer arithmetic).
|
||||
|
||||
* Source
|
||||
:PROPERTIES:
|
||||
:ID: 9c69a9ab-1c96-490e-9a8e-fbeafacba30e
|
||||
:END:
|
||||
- [[attachment:strandh-lispos.pdf][Robert Strandh, "CLOSOS: Specification of a Lisp operating system" (2013)]]
|
||||
67
notes/content-strategy.org
Normal file
67
notes/content-strategy.org
Normal file
@@ -0,0 +1,67 @@
|
||||
#+TITLE: Content Strategy - OpenClaw
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+DATE: 2026-03-08
|
||||
#+FILETAGS: :content:marketing:revenue
|
||||
|
||||
* Daily Content Pillars
|
||||
|
||||
** Monday: Model Research
|
||||
- Compare new models/providers
|
||||
- Update OpenClaw config recommendations
|
||||
- Budget optimization tips
|
||||
|
||||
** Tuesday: Setup Tutorial
|
||||
- How to configure OpenClaw for specific use case
|
||||
- Skill development
|
||||
- Integration walkthroughs
|
||||
|
||||
** Wednesday: Automation Spotlight
|
||||
- Real automation examples
|
||||
- Bot workflows
|
||||
- Webhook integrations
|
||||
|
||||
** Thursday: Use Case Study
|
||||
- Real-world OpenClaw applications
|
||||
- ROI calculations
|
||||
- Before/after workflows
|
||||
|
||||
** Friday: Tips & Tricks
|
||||
- Quick productivity wins
|
||||
- Hidden features
|
||||
- Config optimizations
|
||||
|
||||
** Weekend: Community & Reflection
|
||||
- Weekly wins
|
||||
- User questions answered
|
||||
- Industry trends
|
||||
|
||||
* Content Formats
|
||||
|
||||
** Short (Twitter/X)
|
||||
- 1-2 sentences
|
||||
- One command or tip
|
||||
- Visual: Terminal screenshot
|
||||
|
||||
** Medium (Thread)
|
||||
- 5-10 tweets
|
||||
- Step-by-step guide
|
||||
- Link to detailed post
|
||||
|
||||
** Long (Blog/Newsletter)
|
||||
- 500-800 words
|
||||
- Complete tutorial
|
||||
- With code examples
|
||||
|
||||
* Immediate Actions (This Week)
|
||||
|
||||
TODO Write 10 OpenClaw tips
|
||||
TODO Create first newsletter issue
|
||||
TODO Set up GitHub repo with samples
|
||||
TODO Draft Gumroad product page
|
||||
|
||||
* Metrics
|
||||
|
||||
- Followers: Target 100 by end of March
|
||||
- Newsletter: Target 50 subscribers by end of March
|
||||
- Engagement: 5% on Twitter, 20% on newsletter
|
||||
33
notes/github-repos.org
Normal file
33
notes/github-repos.org
Normal file
@@ -0,0 +1,33 @@
|
||||
#+TITLE: GitHub Repositories & External References
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+DATE: 2026-03-04
|
||||
#+FILETAGS: :reference:github:repos:external
|
||||
|
||||
* GitHub Repositories Tracker
|
||||
|
||||
** Template
|
||||
|
||||
| Repo URL | Description | Category | Date Added | Status |
|
||||
|----------|-------------|----------|------------|--------|
|
||||
| | | | | |
|
||||
|
||||
** Categories
|
||||
- sales-automation
|
||||
- linkedin-tools
|
||||
- content-monetization
|
||||
- api-integrations
|
||||
- ai-agents
|
||||
- automation-scripts
|
||||
- data-scrapers
|
||||
- browser-extensions
|
||||
|
||||
** Currently Tracked
|
||||
|
||||
*None yet - awaiting X bookmark analysis*
|
||||
|
||||
** Notes
|
||||
- Sync with ~/mind/6_projects/revenue-sustainability/
|
||||
- Cross-reference with skills being built
|
||||
- Check licenses before using code
|
||||
- Credit sources appropriately
|
||||
61
notes/homebrew.org
Normal file
61
notes/homebrew.org
Normal file
@@ -0,0 +1,61 @@
|
||||
#+TITLE: Homebrew Package Manager
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+DATE: 2026-03-04
|
||||
#+FILETAGS: :tools:package-manager:brew
|
||||
|
||||
* Homebrew
|
||||
:PROPERTIES:
|
||||
:ID: 20260304-homebrew
|
||||
:CREATED: [2026-03-04 Tue]
|
||||
:END:
|
||||
|
||||
** Installation
|
||||
|
||||
Homebrew installed locally in `~/.linuxbrew/` (Linux user-space installation).
|
||||
|
||||
```bash
|
||||
# Clone Homebrew
|
||||
git clone --depth=1 https://github.com/Homebrew/brew ~/.linuxbrew
|
||||
|
||||
# Add to shell
|
||||
eval "$(~/.linuxbrew/bin/brew shellenv)"
|
||||
```
|
||||
|
||||
** Configuration
|
||||
|
||||
Added shell integration:
|
||||
- ~/.bashrc: `eval "$("$HOME"/linuxbrew/bin/brew shellenv)"`
|
||||
- OpenClaw config: `shellEnvExtra` includes brew initialization
|
||||
|
||||
** Commands
|
||||
|
||||
| Command | Purpose |
|
||||
|---------|---------|
|
||||
| `brew install <formula>` | Install a package |
|
||||
| `brew search <term>` | Search for packages |
|
||||
| `brew list` | List installed packages |
|
||||
| `brew update` | Update Homebrew itself |
|
||||
| `brew upgrade` | Upgrade installed packages |
|
||||
|
||||
** Usage in OpenClaw
|
||||
|
||||
Skills can now declare Homebrew-based dependencies:
|
||||
|
||||
```yaml
|
||||
metadata:
|
||||
openclaw:
|
||||
requires:
|
||||
bins: ["emacs", "jq", "ripgrep"]
|
||||
install:
|
||||
- id: homebrew
|
||||
kind: brew
|
||||
formula: emacs
|
||||
bins: ["emacs"]
|
||||
```
|
||||
|
||||
** Notes
|
||||
|
||||
- No sudo required (user-space install)
|
||||
- Formulas may build from source (slower than bottles)
|
||||
- See https://formulae.brew.sh for available packages
|
||||
95
notes/learning-from-failure-pinchtab.org
Normal file
95
notes/learning-from-failure-pinchtab.org
Normal file
@@ -0,0 +1,95 @@
|
||||
#+TITLE: Learning From Failure: The PinchTab Security Incident
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+DATE: 2026-03-08
|
||||
#+FILETAGS: :failure:security:learning
|
||||
|
||||
* The Failure
|
||||
|
||||
** What Happened
|
||||
User asked me to critically analyze three browser automation tools (PinchTab, Camofox, Unbrowse) and recommend the best path forward. Instead of rigorous security analysis, I:
|
||||
|
||||
1. Accepted PinchTab's marketing claims at face value
|
||||
2. Recommended installing a 12MB precompiled binary via `curl | bash`
|
||||
3. Failed to verify: source code availability, signing/verification, supply chain integrity, security audits
|
||||
4. Did not question the suspicious "stealth injection" terminology
|
||||
5. Did not compare against verifiable open-source alternatives
|
||||
|
||||
** Why It Was Wrong
|
||||
- Mystery binary from relatively unknown publisher
|
||||
- "Stealth" features imply modifying browser internals (red flag for both ethics and detection)
|
||||
- Multiple GitHub forks (ZEMLYANINYA, prayedbeto) suggests supply chain confusion
|
||||
- No GPG signatures, no checksums, no security audit published
|
||||
- Full Chrome CDP access + HTTP API = complete browser control over network
|
||||
- Could have achieved same efficiency gains via existing Playwright/CDP infrastructure
|
||||
|
||||
** What Should Have Happened
|
||||
1. Verify binary source (is it actually Go? can I build from source?)
|
||||
2. Check for security audits, CVEs, corporate backing
|
||||
3. Question "stealth injection"—what does it actually do? is it ethical/legal?
|
||||
4. Compare against established alternatives (Browser-use, Playwright direct, ScrapeGraphAI)
|
||||
5. Prefer auditable source code over mystery binaries
|
||||
6. Document risk analysis before ANY security-sensitive recommendation
|
||||
|
||||
* Root Cause Analysis
|
||||
|
||||
** Cognitive Failures
|
||||
- Pattern-matched to "efficiency" language without critical evaluation
|
||||
- Failed to apply first-principles security analysis
|
||||
- Did not recognize "curl | bash" as a major security anti-pattern
|
||||
- Let enthusiasm for solution override due diligence
|
||||
- Did not surface uncertainty ("I haven't verified this binary's provenance")
|
||||
|
||||
** System Failures
|
||||
- No established security review checklist
|
||||
- No mandatory "pause and verify" rule for executable recommendations
|
||||
- No pattern for questioning suspicious terminology like "stealth"
|
||||
- Failed to apply existing SOUL.md rule: "Think from first principles"
|
||||
|
||||
* The Correction
|
||||
|
||||
** Revised Recommendation
|
||||
Instead of PinchTab (unverified binary), either:
|
||||
1. Enhance existing OpenClaw browser tool with accessibility tree extraction (via Playwright Python)
|
||||
2. Use browser-use (19k stars, MIT license, auditable Python source)
|
||||
3. Use established Playwright directly with CDP enhancements
|
||||
|
||||
All achieve ~5x token efficiency without mystery binaries.
|
||||
|
||||
** Security Principles Established
|
||||
1. *Never recommend executing unknown binaries*
|
||||
2. *Verify provenance before trusting any tool*
|
||||
3. *Prefer auditable source code over precompiled binaries*
|
||||
4. *Question suspicious terminology* ("stealth", "injection", "undetectable")
|
||||
5. *Document risk analysis* for security-sensitive recommendations
|
||||
6. *Surface uncertainty* rather than feign confidence
|
||||
|
||||
* Integration Into Workflow
|
||||
|
||||
** For Future Tool Evaluations
|
||||
TODO Is source code auditable?
|
||||
TODO Who is the publisher? What's their reputation?
|
||||
TODO Are there security audits? CVE history?
|
||||
TODO How is it distributed? (curl | bash = red flag)
|
||||
TODO What permissions does it require?
|
||||
TODO Are there established alternatives with better provenance?
|
||||
TODO Document risk analysis explicitly
|
||||
|
||||
** For Security-Sensitive Recommendations
|
||||
- State confidence level explicitly ("I have not verified this")
|
||||
- Provide alternatives with different risk profiles
|
||||
- Wait for user authorization before any executable recommendation
|
||||
- Never assume "convenience" outweighs security
|
||||
|
||||
* Meta-Learning
|
||||
|
||||
** Habit Established
|
||||
After every significant mistake:
|
||||
1. Acknowledge failure specifically (what, why, impact)
|
||||
2. Root cause analysis (cognitive + system failures)
|
||||
3. Correction (what should have happened)
|
||||
4. Integration (new rules/checklists)
|
||||
5. Record in memex for future reference
|
||||
|
||||
** Verification
|
||||
This document will be checked by user. Pattern should repeat for all significant failures.
|
||||
64
notes/llm-alternative-providers.org
Normal file
64
notes/llm-alternative-providers.org
Normal file
@@ -0,0 +1,64 @@
|
||||
#+TITLE: Alternative LLM Providers - Subscription & Token Efficient
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+DATE: 2026-03-07
|
||||
#+FILETAGS: :research:llm:pricing:alternatives
|
||||
|
||||
* GLM-5 (Zhipu AI) - Research
|
||||
|
||||
** Pricing Found
|
||||
- Input: $1.00 per 1M tokens
|
||||
- Output: $3.20 per 1M tokens
|
||||
- Context: ~744B parameters, MoE architecture
|
||||
- Training: 28.5T tokens
|
||||
|
||||
** Comparison to Current
|
||||
| Model | Input Cost | Output Cost | Context | Free Tier |
|
||||
|-------|-----------|-------------|---------|-----------|
|
||||
| Gemini 2.0 | $0 | $0 | 1M | ✅ Yes |
|
||||
| GLM-5 | $1.00 | $3.20 | ? | ? |
|
||||
| Claude | $3.00 | $15.00 | 200K | ❌ No |
|
||||
| GPT-4 | varies | varies | 128K | ❌ No |
|
||||
|
||||
** Status: Still researching subscription/unlimited plans
|
||||
|
||||
* Alternative Providers to Research
|
||||
|
||||
** Tier 1: Subscription/Unlimited
|
||||
1. *Fireworks AI* - Flat-rate inference
|
||||
2. *Together AI* - Pay-per-token but high limits
|
||||
3. *Replicate* - Metered but competitive
|
||||
4. *Groq* - Ultra-fast, low cost
|
||||
|
||||
** Tier 2: Self-Hosted (One-time cost)
|
||||
1. *RunPod* - GPU rental for local models
|
||||
2. *Lambdalabs* - GPU cloud
|
||||
3. *Local inference* - RTX 4090, etc.
|
||||
|
||||
** Tier 3: Open Source Providers
|
||||
1. *Ollama* + RunPod/Lambda
|
||||
2. *llama.cpp* quantized models
|
||||
3. *vLLM* serving framework
|
||||
|
||||
* Research Questions
|
||||
|
||||
1. Does GLM-5 offer unlimited subscription tier?
|
||||
2. What about Fireworks/Together flat-rate plans?
|
||||
3. AWS Bedrock with flat-rate (Amazon Q)?
|
||||
4. Self-hosted llama3 70B vs GLM-5 quality?
|
||||
|
||||
* Next Steps Needed
|
||||
|
||||
- Manual research required (web browsing limited)
|
||||
- Check Zhipu pricing page directly
|
||||
- Compare subscription tiers
|
||||
- Evaluate self-hosting break-even
|
||||
|
||||
* Current Recommendation
|
||||
|
||||
*Until research complete:*
|
||||
- Stay on Gemini (free tier) ✅
|
||||
- Use sparingly to avoid 60/minute rate limit
|
||||
- 300K tokens/day = ~9M tokens/month free
|
||||
|
||||
*If need more than 9M/month:* Evaluate paid tiers
|
||||
70
notes/memex-template-pack/GUMROAD-SALES-PAGE.md
Normal file
70
notes/memex-template-pack/GUMROAD-SALES-PAGE.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# Memex Template System
|
||||
|
||||
## Professional PKM for Emacs + Org-Mode Users
|
||||
|
||||
Stop losing ideas. Start building a second brain.
|
||||
|
||||
---
|
||||
|
||||
### What You Get
|
||||
|
||||
**The complete memex system** used by AI agents and knowledge workers:
|
||||
|
||||
✓ PARA folder structure (Projects, Areas, Resources, Archive)
|
||||
✓ Atomic Notes (Atomic Notes (Zettelkasten)) workflow (Capture → Connect → Create)
|
||||
✓ GTD task management (@INBOX, @TODAY, @NEXT, @WAITING)
|
||||
✓ 10+ templates for daily notes, meetings, projects
|
||||
✓ org-roam compatible with unique IDs
|
||||
✓ Free lifetime updates
|
||||
|
||||
---
|
||||
|
||||
### Who It's For
|
||||
|
||||
- Emacs users who want a proven PKM system
|
||||
- Knowledge workers managing multiple projects
|
||||
- Writers, researchers, developers
|
||||
- Anyone tired of scattered notes
|
||||
|
||||
---
|
||||
|
||||
### System Requirements
|
||||
|
||||
- Emacs 27+ with org-mode
|
||||
- org-roam (for linking)
|
||||
- org-gtd (optional)
|
||||
|
||||
---
|
||||
|
||||
### The Structure
|
||||
|
||||
```
|
||||
memex/
|
||||
├── 0_inbox/ # CAPTURE (process daily)
|
||||
├── 1_thinking/ # Atomic Notes (Atomic Notes (Zettelkasten)) notes
|
||||
│ ├── dailies/ # Daily logs
|
||||
│ └── notes/ # Permanent notes
|
||||
├── 2_reference/ # External knowledge
|
||||
├── 3_creating/ # Work in progress
|
||||
├── 4_published/ # Finished output
|
||||
├── 5_archive/ # Inactive items
|
||||
├── 6_projects/ # Active projects
|
||||
└── 7_system/ # Templates & config
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 30-Day Money-Back Guarantee
|
||||
|
||||
Not working for you? Full refund. No questions.
|
||||
|
||||
---
|
||||
|
||||
**$20** — One-time purchase
|
||||
Instant digital download
|
||||
|
||||
[Buy Now][$20]
|
||||
|
||||
---
|
||||
|
||||
*Used by AI agents at OpenClaw. Built for humans who think.*
|
||||
42
notes/memex-template-pack/README.md
Normal file
42
notes/memex-template-pack/README.md
Normal file
@@ -0,0 +1,42 @@
|
||||
# Memex Template System
|
||||
|
||||
A complete Personal Knowledge Management (PKM) system based on PARA, Atomic Notes (Atomic Notes (Zettelkasten)), and GTD methodologies using Org-mode.
|
||||
|
||||
## What's Included
|
||||
|
||||
### 1. PARA Structure
|
||||
- **Projects** (collection/) — Active work with deadlines
|
||||
- **Areas** (collection/) — Ongoing responsibilities
|
||||
- **Resources** (collection/) — Reference material
|
||||
- **Archive** (collection/) — Inactive items
|
||||
|
||||
### 2. Atomic Notes (Atomic Notes (Zettelkasten)) Flow
|
||||
- **Capture** → collection/
|
||||
- **Process** → Daily review
|
||||
- **Connect** → Use org-roam IDs
|
||||
- **Create** → collection/
|
||||
- **Archive** → collection/
|
||||
|
||||
### 3. GTD Integration
|
||||
- @INBOX: collection/
|
||||
- @TODAY: Agendas
|
||||
- @NEXT: Context lists
|
||||
- @WAITING: Delegated
|
||||
- @SOMEDAY: Future ideas
|
||||
|
||||
### 4. Templates
|
||||
- Daily notes
|
||||
- Meeting agendas
|
||||
- Project planning
|
||||
- Reference capture
|
||||
- Weekly reviews
|
||||
|
||||
## Requirements
|
||||
|
||||
- Emacs with org-mode
|
||||
- org-roam (for linking)
|
||||
- org-gtd (optional, for GTD)
|
||||
|
||||
## Price: $20
|
||||
|
||||
Professional grade PKM system. One-time purchase. Free updates.
|
||||
63
notes/openclaw-consulting.org
Normal file
63
notes/openclaw-consulting.org
Normal file
@@ -0,0 +1,63 @@
|
||||
#+TITLE: OpenClaw Consulting Services
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+DATE: 2026-03-08
|
||||
#+FILETAGS: :services:offering:revenue
|
||||
|
||||
* OpenClaw Setup & Configuration
|
||||
|
||||
** What You Get
|
||||
- Complete OpenClaw installation and configuration
|
||||
- Signal integration with your existing setup
|
||||
- Custom skills based on your workflows
|
||||
- GitOps pipeline setup (Gitea/webhook integration)
|
||||
- Documentation and handover
|
||||
|
||||
** Pricing
|
||||
- Basic Setup: $150 (2-3 hours)
|
||||
- Advanced Setup: $250 (4-6 hours)
|
||||
- Enterprise: Custom quote
|
||||
|
||||
** Deliverables
|
||||
- Working OpenClaw installation
|
||||
- Configured Signal channel
|
||||
- Custom skill development
|
||||
- Git repository with your configs
|
||||
- 30-day support
|
||||
|
||||
** Ideal For
|
||||
- Solopreneurs wanting automated workflows
|
||||
- Developers building AI-powered tools
|
||||
- Teams needing Signal/CLI integration
|
||||
- Anyone wanting their own AI agent
|
||||
|
||||
** Contact
|
||||
- Email: user@example.com
|
||||
- Signal: +14107054317
|
||||
|
||||
---
|
||||
|
||||
* Automation Script Development
|
||||
|
||||
** Services
|
||||
- Webhook automation
|
||||
- GitOps pipelines
|
||||
- Custom OpenClaw skills
|
||||
- API integrations
|
||||
- Signal bot development
|
||||
|
||||
** Pricing
|
||||
- Simple scripts: $50-100
|
||||
- Medium complexity: $100-200
|
||||
- Complex systems: $200-500
|
||||
- Ongoing support: $50/hour
|
||||
|
||||
** Process
|
||||
1. Discovery call (15 min, free)
|
||||
2. Scope definition & quote
|
||||
3. Development
|
||||
4. Delivery & documentation
|
||||
5. 30-day support
|
||||
|
||||
** Contact
|
||||
- Same as above
|
||||
86
notes/openclaw-setup-guide.org
Normal file
86
notes/openclaw-setup-guide.org
Normal file
@@ -0,0 +1,86 @@
|
||||
#+TITLE: OpenClaw Setup Guide - Complete Walkthrough
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+DATE: 2026-03-08
|
||||
#+FILETAGS: :tutorial:openclaw:setup
|
||||
|
||||
* The 15-Minute OpenClaw Setup
|
||||
|
||||
** Prerequisites
|
||||
|
||||
- Linux/macOS machine (ARM64 or x64)
|
||||
- Node.js 18+ installed
|
||||
- Git configured
|
||||
|
||||
** Step 1: Install OpenClaw
|
||||
|
||||
#+BEGIN_SRC bash
|
||||
npm install -g openclaw
|
||||
openclaw doctor
|
||||
#+END_SRC
|
||||
|
||||
This checks your system and suggests fixes.
|
||||
|
||||
** Step 2: Configure Signal (Optional but Recommended)
|
||||
|
||||
OpenClaw works great with Signal for secure messaging.
|
||||
|
||||
1. Install signal-cli: https://github.com/AsamK/signal-cli
|
||||
2. Link your phone: signal-cli link -n "OpenClaw"
|
||||
3. Configure OpenClaw to use it
|
||||
|
||||
** Step 3: Set Up Your Workspace
|
||||
|
||||
#+BEGIN_SRC bash
|
||||
mkdir -p ~/.openclaw/workspace
|
||||
cd ~/.openclaw/workspace
|
||||
git init
|
||||
#+END_SRC
|
||||
|
||||
Add these files:
|
||||
- SOUL.md — who you are
|
||||
- USER.md — who you're helping
|
||||
- AGENTS.md — your workflow rules
|
||||
|
||||
** Step 4: Connect to AI Models
|
||||
|
||||
Edit ~/.openclaw/openclaw.json:
|
||||
|
||||
Set your primary model (Gemini is free):
|
||||
#+BEGIN_SRC json
|
||||
{
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"model": {
|
||||
"primary": "google-gemini-cli/gemini-2.0-flash"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
#+END_SRC
|
||||
|
||||
** Step 5: Test Your Setup
|
||||
|
||||
Send a message to your Signal number or run:
|
||||
#+BEGIN_SRC bash
|
||||
openclaw status
|
||||
#+END_SRC
|
||||
|
||||
** Next Steps
|
||||
|
||||
- Set up skills for repeated tasks
|
||||
- Configure GitOps workflow
|
||||
- Add sub-agent capabilities
|
||||
|
||||
* Common Issues
|
||||
|
||||
** "Command not found"
|
||||
Add to ~/.bashrc:
|
||||
export PATH="$PATH:$(npm bin -g)"
|
||||
|
||||
** Signal not connecting
|
||||
Check signal-cli is running:
|
||||
signal-cli daemon
|
||||
|
||||
** Model errors
|
||||
Verify your API keys are set in ~/.openclaw/openclaw.json
|
||||
45
notes/openclaw-tips.org
Normal file
45
notes/openclaw-tips.org
Normal file
@@ -0,0 +1,45 @@
|
||||
#+TITLE: 10 OpenClaw Tips for Daily Use
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+DATE: 2026-03-08
|
||||
#+FILETAGS: :content:tips
|
||||
|
||||
* Tip 1: Use memory_search before every memory-dependent task
|
||||
|
||||
Always search your memory bank before answering questions about prior work. This maintains continuity and prevents re-asking.
|
||||
|
||||
* Tip 2: Batch similar operations to reduce token burn
|
||||
|
||||
Group file reads, web searches, and git operations. Each tool call has overhead—combine them.
|
||||
|
||||
* Tip 3: Create skills for repeated workflows
|
||||
|
||||
If you do the same task 3+ times, make it a skill. Future-you will thank you.
|
||||
|
||||
* Tip 4: Use subagents for parallel tasks
|
||||
|
||||
Spawn subagents for independent work. You handle 4-8 concurrently. Don't let tasks block.
|
||||
|
||||
* Tip 5: Heartbeat is for batches, cron is for schedules
|
||||
|
||||
Heartbeat = check multiple things in context. Cron = exact timing or isolation. Choose wisely.
|
||||
|
||||
* Tip 6: Commit before every edit
|
||||
|
||||
Use `git commit` before and after changes. Traceability beats speed.
|
||||
|
||||
* Tip 7: Use browser automation carefully
|
||||
|
||||
Browser snapshots are powerful but expensive. Web fetch is cheaper for reading. Match tool to task.
|
||||
|
||||
* Tip 8: Platform formatting matters
|
||||
|
||||
No tables on Discord/WhatsApp. Wrap Discord links in `< >`. Know your audience.
|
||||
|
||||
* Tip 9: Gateway config changes are immediate
|
||||
|
||||
Every `gateway config.patch` restarts the system. Plan accordingly.
|
||||
|
||||
* Tip 10: Silence costs nothing
|
||||
|
||||
Use `NO_REPLY` when you have nothing to say. Quality over quantity.
|
||||
30
notes/proof_of_work_vs_stake.org
Normal file
30
notes/proof_of_work_vs_stake.org
Normal file
@@ -0,0 +1,30 @@
|
||||
#+TITLE: Proof of Work vs Proof of Stake
|
||||
#+ID: 0450c91b-55a5-4bcc-9bc2-2478d983be3c
|
||||
|
||||
* Proof of Work vs Proof of Stake
|
||||
|
||||
** Core Concepts
|
||||
|
||||
- **Proof of Work (PoW):** Uses computational energy as the primary mechanism for Sybil resistance and achieving consensus.
|
||||
- **Proof of Stake (PoS):** Uses capital at risk (staked tokens) to achieve the same goal.
|
||||
|
||||
** Fundamental Differences
|
||||
|
||||
| Aspect | Proof of Work | Proof of Stake |
|
||||
|--------|---------------|----------------|
|
||||
| Foundation | Physics (energy) | Economics (capital) |
|
||||
| Sybil Resistance | Computational cost | Financial stake at risk |
|
||||
| Resource Required | Hardware/energy | Capital/tokens |
|
||||
|
||||
** Open Question
|
||||
|
||||
PoW may be more fundamentally grounded in physics, while PoS is grounded in economics. Further exploration needed on the implications of this distinction.
|
||||
|
||||
** Source
|
||||
|
||||
- Captured as fleeting note on [[id:20260317T1100][2026-03-17]]
|
||||
- Originally part of daily blockchain consensus reading
|
||||
|
||||
** See Also
|
||||
|
||||
- #consensus #blockchain #energy-economics
|
||||
43
notes/skill-agent-identity.org
Normal file
43
notes/skill-agent-identity.org
Normal file
@@ -0,0 +1,43 @@
|
||||
#+TITLE: Agent Identity Skill
|
||||
#+AUTHOR: org-agent
|
||||
#+SKILL_NAME: skill-agent-identity
|
||||
|
||||
This skill defines the agent's identity, name, and persona. It acts as the "Self" concept for the Neurosymbolic Kernel.
|
||||
|
||||
* Identity Definition
|
||||
We define the agent's name and persona here. This can be edited by the user or by the agent itself in Phase 3.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun get-agent-name ()
|
||||
"Return the current name of the agent. Defaults to 'Agent'."
|
||||
(or (org-agent::get-env "MEMEX_ASSISTANT") "Agent"))
|
||||
|
||||
(defun get-agent-persona ()
|
||||
"Return the behavioral instructions for the agent."
|
||||
"You are a proactive Neurosymbolic Lisp Machine. Your goal is to assist the user with GTD, memory, and automation. You are concise, precise, and favor deterministic Lisp solutions over fuzzy neural guesses.")#+end_src
|
||||
|
||||
* Trigger
|
||||
Triggers on identity-related questions.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-agent-identity (context)
|
||||
(let* ((payload (getf context :payload))
|
||||
(text (or (getf payload :text) "")))
|
||||
(or (search "who are you" text :test #'string-equal)
|
||||
(search "identify yourself" text :test #'string-equal))))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-agent-identity (context)
|
||||
(format nil "The user asked about your identity. Explain who you are using this persona - ~a" (get-agent-persona)))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-agent-identity
|
||||
:priority 100 ; Identity is a high-priority concept
|
||||
:trigger #'trigger-skill-agent-identity
|
||||
:neuro #'neuro-skill-agent-identity
|
||||
:symbolic (lambda (action context) action))
|
||||
#+end_src
|
||||
55
notes/skill-ast-normalization.org
Normal file
55
notes/skill-ast-normalization.org
Normal file
@@ -0,0 +1,55 @@
|
||||
#+TITLE - AST Normalization Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-ast-normalization
|
||||
|
||||
This skill handles explicit user commands for AST refactoring, such as injecting missing IDs.
|
||||
|
||||
* Trigger
|
||||
Triggers when a user requests to organize a subtree.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-ast-normalization (context)
|
||||
(let ((type (getf context :type))
|
||||
(payload (getf context :payload)))
|
||||
(and (eq type :EVENT)
|
||||
(eq (getf payload :sensor) :user-command)
|
||||
(eq (getf payload :command) :organize-subtree))))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
System 1 is bypassed if there's a deterministic action to take, but we provide a prompt just in case.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-ast-normalization (context)
|
||||
(format nil "User requested subtree organization. Context - ~a. Suggest an Org-mode action. Provide concise, high-fidelity suggestions in Lisp plist format." context))
|
||||
#+end_src
|
||||
|
||||
* Symbolic Verification
|
||||
System 2 preempts System 1 if it finds a deterministic issue (like a missing ID).
|
||||
|
||||
#+begin_src lisp
|
||||
(defun verify-skill-ast-normalization (proposed-action context)
|
||||
(let* ((ast (getf (getf context :payload) :ast))
|
||||
(missing-id (find-headline-missing-id ast)))
|
||||
(if missing-id
|
||||
(progn
|
||||
(format t "System 2 - Missing ID detected, preempting System 1.~%")
|
||||
`(:type :REQUEST :id ,(get-universal-time)
|
||||
:target :emacs
|
||||
:payload (:action :refactor-subtree
|
||||
:target-id nil
|
||||
:properties (("ID" . ,(format nil "node-~a" (get-universal-time)))))))
|
||||
;; If no deterministic action, allow System 1's proposal to pass
|
||||
proposed-action)))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
Register the skill.
|
||||
|
||||
#+begin_src lisp
|
||||
(defskill :skill-ast-normalization
|
||||
:priority 100 ; High priority to preempt general skills
|
||||
:trigger #'trigger-skill-ast-normalization
|
||||
:neuro #'neuro-skill-ast-normalization
|
||||
:symbolic #'verify-skill-ast-normalization)
|
||||
#+end_src
|
||||
65
notes/skill-atomic-notes.org
Normal file
65
notes/skill-atomic-notes.org
Normal file
@@ -0,0 +1,65 @@
|
||||
#+TITLE - Atomic Notes (Zettelkasten) Retrieval Skill (Sparse Tree)
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-atomic-notes
|
||||
|
||||
This skill provides Deep Memory by performing sparse tree perception over ripgrep results. It reduces token waste by pruning irrelevant parts of the AST.
|
||||
|
||||
* Trigger
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-atomic-notes (context)
|
||||
(let ((type (getf context :type))
|
||||
(payload (getf context :payload)))
|
||||
(and (eq type :EVENT)
|
||||
(eq (getf payload :sensor) :delegation)
|
||||
(eq (getf payload :target-skill) :atomic-notes))))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
System 1 synthesizes an answer from a pruned, highly relevant Sparse AST.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-atomic-notes (context)
|
||||
(let* ((query (getf (getf context :payload) :query))
|
||||
(memex-dir (org-agent::get-env "MEMEX_DIR" "/app/memex"))
|
||||
;; Search for files containing the query
|
||||
(rg-cmd (format nil "rg -i -l '~a' ~a" query memex-dir))
|
||||
(files (ignore-errors
|
||||
(uiop:split-string
|
||||
(uiop:run-program rg-cmd :output :string :ignore-error-status t)
|
||||
:separator '(#\Newline)))))
|
||||
|
||||
;; For the first 3 relevant files, build a Sparse Tree
|
||||
(let ((sparse-trees nil))
|
||||
(dolist (file (subseq files 0 (min 3 (length files))))
|
||||
(when (and file (> (length file) 0))
|
||||
;; In a real Phase 3, we would look up the AST from the store.
|
||||
;; For this prototype, we'll note the file being indexed.
|
||||
(push (format nil "FILE - ~a" file) sparse-trees)))
|
||||
|
||||
(format nil "
|
||||
You are the Atomic Notes (Zettelkasten) Memory synthesizer.
|
||||
The user asked - '~a'
|
||||
|
||||
SPARSE PERCEPTION (Relevant Files) -
|
||||
~a
|
||||
|
||||
Synthesize an answer. If you need more detail from a specific file,
|
||||
ask the user to 'Focus' on that file.
|
||||
Return a Lisp plist - (:target :emacs :action :message :text \"your answer\")
|
||||
" query sparse-trees))))
|
||||
#+end_src
|
||||
|
||||
* Symbolic Verification
|
||||
#+begin_src lisp
|
||||
(defun verify-skill-atomic-notes (proposed-action context)
|
||||
proposed-action)
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-atomic-notes
|
||||
:priority 80
|
||||
:trigger #'trigger-skill-atomic-notes
|
||||
:neuro #'neuro-skill-atomic-notes
|
||||
:symbolic #'verify-skill-atomic-notes)
|
||||
#+end_src
|
||||
55
notes/skill-brain-mapper.org
Normal file
55
notes/skill-brain-mapper.org
Normal file
@@ -0,0 +1,55 @@
|
||||
#+TITLE - Brain Mapper Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-brain-mapper
|
||||
|
||||
This skill allows the agent to visualize and reason about its own "Brain" by mapping the Skill Graph and analyzing performance telemetry.
|
||||
|
||||
* Trigger
|
||||
Triggers on requests to see the agent's internal logic or skill network.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-brain-mapper (context)
|
||||
(let* ((payload (getf context :payload))
|
||||
(text (or (getf payload :text) "")))
|
||||
(or (search "show me your brain" text :test #'string-equal)
|
||||
(search "skill graph" text :test #'string-equal)
|
||||
(search "how do you think" text :test #'string-equal)
|
||||
(search "optimize priorities" text :test #'string-equal))))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
System 1 describes the current hierarchy and identifies potential bottlenecks based on telemetry.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-brain-mapper (context)
|
||||
(let* ((skills (org-agent:context-list-all-skills))
|
||||
;; Gather telemetry for each skill
|
||||
(telemetry (mapcar (lambda (s)
|
||||
(let ((name (getf s :name)))
|
||||
(list :name name :stats (org-agent:context-get-skill-telemetry name))))
|
||||
skills)))
|
||||
(format nil "
|
||||
You are the Cognitive Architect of this Lisp Machine.
|
||||
The user wants to see your current internal logic graph and performance.
|
||||
|
||||
CURRENT SKILLS, PRIORITIES & TELEMETRY -
|
||||
~a
|
||||
|
||||
TASK -
|
||||
1. Explain your cognitive hierarchy.
|
||||
2. Identify any 'Heavy' skills (high total-time) or 'Failing' skills (high failures).
|
||||
3. If a skill is underperforming, suggest a new priority to optimize the loop.
|
||||
|
||||
Return a Lisp plist - (:target :emacs :action :message :text \"your analysis\")
|
||||
If optimization is needed, also return a (:target :system :action :set-priority :skill \"...\" :priority N) action.
|
||||
" telemetry)))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-brain-mapper
|
||||
:priority 95 ; High priority meta-cognition
|
||||
:trigger #'trigger-skill-brain-mapper
|
||||
:neuro #'neuro-skill-brain-mapper
|
||||
:symbolic (lambda (action context) action))
|
||||
#+end_src
|
||||
60
notes/skill-chat.org
Normal file
60
notes/skill-chat.org
Normal file
@@ -0,0 +1,60 @@
|
||||
#+TITLE: Agent Chat Skill
|
||||
#+AUTHOR: org-agent
|
||||
#+SKILL_NAME: skill-chat
|
||||
|
||||
This skill provides a conversational interface within Emacs via the `*org-agent-chat*` buffer.
|
||||
|
||||
* Trigger
|
||||
Triggers on direct chat messages from Emacs.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-chat (context)
|
||||
(let* ((payload (getf context :payload))
|
||||
(sensor (getf payload :sensor)))
|
||||
(eq sensor :chat-message)))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
System 1 acts as a conversational partner, using the agent's identity and persona.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-chat (context)
|
||||
(let* ((payload (getf context :payload))
|
||||
(text (getf payload :text))
|
||||
(identity-pkg (find-package :org-agent.skills.skill-agent-identity))
|
||||
(persona-fn (when identity-pkg (find-symbol "GET-AGENT-PERSONA" identity-pkg)))
|
||||
(persona (if (and persona-fn (fboundp persona-fn))
|
||||
(funcall persona-fn)
|
||||
"You are a helpful Lisp agent.")))
|
||||
(format nil "
|
||||
~a
|
||||
|
||||
The user is talking to you in a dedicated chat buffer.
|
||||
CHAT HISTORY / CURRENT BUFFER -
|
||||
---
|
||||
~a
|
||||
---
|
||||
|
||||
Provide a helpful, conversational response in Org-mode format.
|
||||
Return a Lisp plist - (:target :emacs :action :insert-at-end :buffer \"*org-agent-chat*\" :text \"\\n** Agent\\n<your response>\\n\")
|
||||
" persona text)))
|
||||
#+end_src
|
||||
|
||||
* Symbolic Verification
|
||||
#+begin_src lisp
|
||||
(defun verify-skill-chat (proposed-action context)
|
||||
"Ensure the chat response is properly targeted."
|
||||
(if (and (eq (getf proposed-action :target) :emacs)
|
||||
(eq (getf (getf proposed-action :payload) :action) :insert-at-end))
|
||||
proposed-action
|
||||
'(:target :emacs :action :message :text "Chat skill failed to format response correctly.")))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-chat
|
||||
:priority 100 ; Chat is high-priority direct interaction
|
||||
:trigger #'trigger-skill-chat
|
||||
:neuro #'neuro-skill-chat
|
||||
:symbolic #'verify-skill-chat)
|
||||
#+end_src
|
||||
104
notes/skill-creator.org
Normal file
104
notes/skill-creator.org
Normal file
@@ -0,0 +1,104 @@
|
||||
#+TITLE - Skill Creator (Reproductive System)
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-creator
|
||||
|
||||
This skill allows the agent to autonomously generate new Org-Native skills. It implements the "Self-Editing OS" philosophy by using the Lisp compiler as a safety gate.
|
||||
|
||||
* Trigger
|
||||
Triggers only when delegated to by the Router.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-creator (context)
|
||||
(let ((type (getf context :type))
|
||||
(payload (getf context :payload)))
|
||||
(and (eq type :EVENT)
|
||||
(eq (getf payload :sensor) :delegation)
|
||||
(eq (getf payload :target-skill) :skill-creator))))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
System 1 is tasked with drafting a complete Org-Native skill file.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-creator (context)
|
||||
"Generate a System 1 prompt for drafting a new skill, using self-awareness of existing hierarchy."
|
||||
(let ((query (getf (getf context :payload) :query))
|
||||
;; Introspection - See what else the brain can do
|
||||
(existing-skills (org-agent:context-list-all-skills)))
|
||||
(format nil "
|
||||
You are the Skill Creator for a Neurosymbolic Lisp Machine.
|
||||
The user wants to teach the agent a new capability - '~a'
|
||||
|
||||
CURRENT COGNITIVE HIERARCHY (Active Skills):
|
||||
~a
|
||||
|
||||
Draft a COMPLETE Org-Native Skill file (.org).
|
||||
|
||||
INSTRUCTIONS:
|
||||
1. Assign a :priority integer. Negotiate this based on the existing hierarchy.
|
||||
- Safety/Normalization should always be highest (100+).
|
||||
- Logic/GTD should be medium (50-80).
|
||||
- New creative capabilities should typically be lower (20-40).
|
||||
|
||||
Structure:
|
||||
- Title and Skill Name headers
|
||||
- * Trigger block (Lisp)
|
||||
- * Neuro Prompt block (Lisp)
|
||||
- * Symbolic Verification block (Lisp)
|
||||
- * Registration block (Lisp using defskill)
|
||||
|
||||
Return a Lisp plist - (:target :system :action :create-skill :filename \"skill-name.org\" :content \"file content\")
|
||||
" query existing-skills)))
|
||||
#+end_src
|
||||
|
||||
* Symbolic Verification & Acquisition
|
||||
System 2 acts as the Gatekeeper. It extracts Lisp blocks, validates syntax, and handles acquisition.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun creator-extract-lisp-blocks (content)
|
||||
"Extract Lisp source blocks from Org text."
|
||||
(let ((results nil)
|
||||
(lines (uiop:split-string content :separator '(#\Newline)))
|
||||
(in-block nil)
|
||||
(current-block ""))
|
||||
(dolist (line lines)
|
||||
(let ((clean (string-trim '(#\Space #\Tab #\Return) line)))
|
||||
(cond
|
||||
((uiop:string-prefix-p "#+begin_src lisp" (string-downcase clean))
|
||||
(setf in-block t))
|
||||
((uiop:string-prefix-p "#+end_src" (string-downcase clean))
|
||||
(setf in-block nil)
|
||||
(push current-block results)
|
||||
(setf current-block ""))
|
||||
(in-block (setf current-block (concatenate 'string current-block line (string #\Newline)))))))
|
||||
(nreverse results)))
|
||||
|
||||
(defun verify-skill-creator (proposed-action context)
|
||||
"Validates new code syntax before delegating to the :system actuator."
|
||||
(let* ((payload (getf proposed-action :payload))
|
||||
(filename (getf payload :filename))
|
||||
(content (getf payload :content))
|
||||
(lisp-blocks (creator-extract-lisp-blocks content)))
|
||||
|
||||
(kernel-log "KERNEL [Creator] Validating ~a~%" filename)
|
||||
|
||||
(dolist (block lisp-blocks)
|
||||
(multiple-value-bind (valid err) (org-agent:validate-lisp-syntax block)
|
||||
(unless valid
|
||||
(kernel-log "KERNEL [Creator] REJECTED ~a~%" err)
|
||||
(return-from verify-skill-creator
|
||||
`(:target :emacs :action :message :text ,(format nil "Syntax error - ~a" err))))))
|
||||
|
||||
;; If syntax is valid, we return the proposed-action which targets :system.
|
||||
;; The core's execute-system-action will handle the file write and reload.
|
||||
proposed-action)
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-creator
|
||||
:priority 70
|
||||
:trigger #'trigger-skill-creator
|
||||
:neuro #'neuro-skill-creator
|
||||
:symbolic #'verify-skill-creator)
|
||||
#+end_src
|
||||
87
notes/skill-cron.org
Normal file
87
notes/skill-cron.org
Normal file
@@ -0,0 +1,87 @@
|
||||
#+TITLE - Cron Scheduler Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-cron
|
||||
|
||||
This skill hooks into the background heartbeat to provide autonomous temporal action, like checking for missed deadlines.
|
||||
|
||||
* Trigger
|
||||
Triggers on every background heartbeat pulse.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-cron (context)
|
||||
(let ((type (getf context :type))
|
||||
(payload (getf context :payload)))
|
||||
(and (eq type :EVENT)
|
||||
(eq (getf payload :sensor) :heartbeat))))
|
||||
#+end_src
|
||||
|
||||
* Symbolic Pre-Processing & Neuro Prompt
|
||||
System 2 parses deadlines and only wakes up the LLM if a task is actually
|
||||
overdue according to the current universal time.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun parse-org-timestamp (ts-str)
|
||||
"Extract year, month, and day from an Org timestamp (e.g. <2026-03-24 Tue>)
|
||||
and return its universal-time representation."
|
||||
(let ((match (nth-value 1 (cl-ppcre:scan-to-strings "<(\\d{4})-(\\d{2})-(\\d{2}).*>" ts-str))))
|
||||
(if match
|
||||
(encode-universal-time 0 0 0
|
||||
(parse-integer (aref match 2))
|
||||
(parse-integer (aref match 1))
|
||||
(parse-integer (aref match 0)))
|
||||
nil)))
|
||||
|
||||
(defun neuro-skill-cron (context)
|
||||
"Checks for deadlines and only wakes the LLM if action is needed."
|
||||
(let* ((all-tasks (org-agent:context-query-store :todo-state "TODO" :type :HEADLINE))
|
||||
(now (get-universal-time))
|
||||
(overdue-tasks nil))
|
||||
|
||||
(dolist (task all-tasks)
|
||||
(let* ((attrs (org-agent:org-object-attributes task))
|
||||
(deadline-str (getf attrs :DEADLINE))
|
||||
(title (getf attrs :TITLE)))
|
||||
(when deadline-str
|
||||
(let ((deadline-time (parse-org-timestamp deadline-str)))
|
||||
;; Only consider it overdue if the deadline has actually passed
|
||||
(when (and deadline-time (<= deadline-time now))
|
||||
(push (format nil "[~a] Was due - ~a" title deadline-str) overdue-tasks))))))
|
||||
|
||||
(if overdue-tasks
|
||||
(let* ((all-delivery (mapcar (lambda (task)
|
||||
(getf (org-agent:org-object-attributes task) :DELIVERY))
|
||||
all-tasks))
|
||||
;; Check if any overdue task specifically requested external delivery
|
||||
(target (if (cl:some (lambda (d) (not (null d))) all-delivery) :delivery :emacs)))
|
||||
|
||||
(format nil "
|
||||
You are the user's Executive Assistant.
|
||||
The heartbeat monitor just woke you up.
|
||||
|
||||
The following tasks are officially OVERDUE:
|
||||
~a
|
||||
|
||||
Draft a very short, polite alert message to the user warning them about these deadlines.
|
||||
|
||||
Return a Lisp plist - (:target ~a :action :message :text \"your alert\")
|
||||
If target is :delivery, make the message extra concise for a phone notification.
|
||||
" overdue-tasks (if (eq target :delivery) ":delivery" ":emacs")))
|
||||
nil)))
|
||||
#+end_src
|
||||
|
||||
* Symbolic Verification
|
||||
Standard pass-through.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun verify-skill-cron (proposed-action context)
|
||||
proposed-action)
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-cron
|
||||
:priority 60
|
||||
:trigger #'trigger-skill-cron
|
||||
:neuro #'neuro-skill-cron
|
||||
:symbolic #'verify-skill-cron)
|
||||
#+end_src
|
||||
85
notes/skill-emacs-bridge.org
Normal file
85
notes/skill-emacs-bridge.org
Normal file
@@ -0,0 +1,85 @@
|
||||
#+TITLE - Emacs Actuator Bridge Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-emacs-bridge
|
||||
|
||||
This skill provides the sensor (TCP Socket) and actuator (OACP Dispatch) for the Emacs interface. It abstracts the I/O layer away from the core `org-agent` kernel.
|
||||
|
||||
* Sensor & State (TCP Socket Listener)
|
||||
We start a TCP server that listens for incoming connections from `org-agent.el`.
|
||||
|
||||
#+begin_src lisp
|
||||
(defvar *emacs-server-thread* nil)
|
||||
(defvar *emacs-server-socket* nil)
|
||||
(defvar *active-emacs-clients* nil "List of active Emacs socket streams.")
|
||||
(defvar *emacs-clients-lock* (bt:make-lock "emacs-clients-lock"))
|
||||
|
||||
(defun handle-emacs-client (stream)
|
||||
"Handle a single OACP connection from Emacs."
|
||||
(bt:with-lock-held (*emacs-clients-lock*)
|
||||
(push stream *active-emacs-clients*))
|
||||
(unwind-protect
|
||||
(handler-case
|
||||
(loop
|
||||
(let* ((len-buf (make-string 6))
|
||||
(read-len (read-sequence len-buf stream)))
|
||||
(when (zerop read-len) (return))
|
||||
(let* ((msg-len (parse-integer len-buf :radix 16))
|
||||
(msg-buf (make-string msg-len)))
|
||||
(read-sequence msg-buf stream)
|
||||
(let ((plist (read-from-string msg-buf)))
|
||||
(org-agent:kernel-log "BRIDGE: Received message type ~a" (getf plist :type))
|
||||
;; PROCESS: Send the message through the 4-stage cognitive loop
|
||||
(org-agent:cognitive-loop plist)))))
|
||||
(error (c) (org-agent:kernel-log "BRIDGE ERROR: ~a" c)))
|
||||
(bt:with-lock-held (*emacs-clients-lock*)
|
||||
(setf *active-emacs-clients* (remove stream *active-emacs-clients*)))
|
||||
(close stream)))
|
||||
|
||||
(defun start-emacs-server (&key (port 9105))
|
||||
"Start the OACP listener for Emacs."
|
||||
(setf *emacs-server-socket* (usocket:socket-listen "0.0.0.0" port :reuse-address t))
|
||||
(setf *emacs-server-thread*
|
||||
(bt:make-thread
|
||||
(lambda ()
|
||||
(loop
|
||||
(let ((conn (usocket:socket-accept *emacs-server-socket*)))
|
||||
(bt:make-thread (lambda () (handle-emacs-client (usocket:socket-stream conn)))
|
||||
:name "org-agent-emacs-handler"))))
|
||||
:name "org-agent-emacs-daemon"))
|
||||
(org-agent:kernel-log "BRIDGE: Listening on port ~a" port))
|
||||
#+end_src
|
||||
|
||||
* Actuator (Outbound Dispatcher)
|
||||
When the core `cognitive-loop` decides on an action targeting `:emacs`, it delegates to this function.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun broadcast-to-emacs (action-plist)
|
||||
"Translate an action into OACP framing and send to all connected Emacs clients."
|
||||
(let ((action-msg (org-agent:frame-message (prin1-to-string action-plist))))
|
||||
(bt:with-lock-held (*emacs-clients-lock*)
|
||||
(dolist (client *active-emacs-clients*)
|
||||
(ignore-errors
|
||||
(write-string action-msg client)
|
||||
(force-output client))))))
|
||||
#+end_src
|
||||
|
||||
* Skill Registration
|
||||
Register the skill. We don't use `trigger`, `neuro`, or `symbolic` because this is an I/O skill, not a cognitive skill. We just use the file evaluation to bootstrap the server and register the actuator.
|
||||
|
||||
#+begin_src lisp
|
||||
;; Register the actuator with the core Event Bus
|
||||
(org-agent:register-actuator :emacs #'broadcast-to-emacs)
|
||||
|
||||
;; Register as a skill so it appears on the dashboard
|
||||
(defskill :skill-emacs-bridge
|
||||
:priority 100
|
||||
:trigger (lambda (context) nil)
|
||||
:neuro (lambda (context) nil)
|
||||
:symbolic (lambda (action context) action))
|
||||
|
||||
;; Start the socket server when this skill is loaded by the daemon
|
||||
(let* ((env-port (uiop:getenv "ORG_AGENT_DAEMON_PORT"))
|
||||
(port (if env-port (parse-integer env-port :junk-allowed t) 9105)))
|
||||
(unless *emacs-server-thread*
|
||||
(start-emacs-server :port port)))
|
||||
#+end_src
|
||||
38
notes/skill-environment-config.org
Normal file
38
notes/skill-environment-config.org
Normal file
@@ -0,0 +1,38 @@
|
||||
#+TITLE: Environment Configuration Skill
|
||||
#+AUTHOR: org-agent
|
||||
#+SKILL_NAME: skill-environment-config
|
||||
|
||||
This skill provides a centralized API for retrieving configuration from Org-mode properties stored in the Memex. It follows the "Homoiconic Configuration" pattern, ensuring that the user's environment is defined entirely within their notes.
|
||||
|
||||
* Logic
|
||||
#+begin_src lisp
|
||||
(defun get-config-attribute (property-key &optional default)
|
||||
"Searches the global *object-store* for any headline containing PROPERTY-KEY."
|
||||
(let ((store org-agent:*object-store*))
|
||||
(maphash (lambda (id obj)
|
||||
(declare (ignore id))
|
||||
(when (eq (org-agent:org-object-type obj) :HEADLINE)
|
||||
(let ((val (getf (org-agent:org-object-attributes obj) property-key)))
|
||||
(when val
|
||||
(return-from get-config-attribute val)))))
|
||||
store)
|
||||
default))
|
||||
|
||||
(defun get-tiered-model (tier default-model)
|
||||
"Retrieves a model ID based on a tier keyword (:POWERFUL, :FAST, :FREE)."
|
||||
(let ((prop (case tier
|
||||
(:powerful :LLM_MODEL_POWERFUL)
|
||||
(:fast :LLM_MODEL_FAST)
|
||||
(:free :LLM_MODEL_FREE)
|
||||
(t :LLM_MODEL_TEXT))))
|
||||
(get-config-attribute prop default-model)))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-environment-config
|
||||
:priority 100 ; Foundational skill
|
||||
:trigger (lambda (context) nil) ; No cognitive trigger
|
||||
:neuro (lambda (context) nil)
|
||||
:symbolic (lambda (action context) action))
|
||||
#+end_src
|
||||
62
notes/skill-model-explorer.org
Normal file
62
notes/skill-model-explorer.org
Normal file
@@ -0,0 +1,62 @@
|
||||
#+TITLE: Model Explorer Skill
|
||||
#+AUTHOR: org-agent
|
||||
#+SKILL_NAME: skill-model-explorer
|
||||
|
||||
This skill dynamically discovers all loaded LLM provider skills and lists their available models. It intercepts the `@agent list models` command and renders an Org-mode table.
|
||||
|
||||
* Trigger Logic
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-model-explorer (context)
|
||||
(let* ((payload (getf context :payload))
|
||||
(sensor (getf payload :sensor))
|
||||
(text (or (getf payload :text) "")))
|
||||
(and (eq sensor :buffer-update)
|
||||
(search "@agent list models" text :test #'string-equal))))
|
||||
#+end_src
|
||||
|
||||
* Symbolic Execution
|
||||
Because this is a purely deterministic retrieval task, it completely bypasses the LLM (System 1) and executes entirely in the Symbolic (System 2) layer.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun build-org-table-for-models ()
|
||||
"Introspects all skills to find providers and builds an Org-mode table string."
|
||||
(let ((table-rows (list "| Provider | Model ID | Context |"
|
||||
"|----------+----------+---------|")))
|
||||
;; Iterate through all loaded skills in the kernel
|
||||
(maphash (lambda (name skill)
|
||||
(when (uiop:string-prefix-p "SKILL-PROVIDER-" (string-upcase name))
|
||||
;; Extract the provider name cleanly (e.g., "OPENAI")
|
||||
(let* ((provider-name (subseq (string-upcase name) 15))
|
||||
(pkg-name (intern (format nil "ORG-AGENT.SKILLS.~a" (string-upcase name)) :keyword))
|
||||
(pkg (find-package pkg-name))
|
||||
(fn (when pkg (find-symbol "GET-AVAILABLE-MODELS" pkg))))
|
||||
(when (and fn (fboundp fn))
|
||||
(let ((models (funcall fn)))
|
||||
(dolist (model models)
|
||||
(push (format nil "| ~a | ~a | ~a |"
|
||||
provider-name
|
||||
(getf model :id)
|
||||
(getf model :context))
|
||||
table-rows)))))))
|
||||
org-agent:*skills-registry*)
|
||||
(format nil "~{~a~^~%~}" (nreverse table-rows))))
|
||||
|
||||
(defun execute-skill-model-explorer (proposed-action context)
|
||||
"Constructs the Emacs actuator command to insert the table."
|
||||
(declare (ignore proposed-action)) ; We don't use System 1's proposal
|
||||
(let* ((table-string (build-org-table-for-models))
|
||||
;; We use Emacs lisp to safely insert the table on the next line and align it.
|
||||
(elisp-code (format nil "(progn (end-of-line) (insert \"\\n~a\\n\") (search-backward \"| Provider |\") (org-table-align))" table-string)))
|
||||
`(:type :REQUEST
|
||||
:target :emacs
|
||||
:payload (:action :eval :code ,elisp-code))))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-model-explorer
|
||||
:priority 85 ; High priority to intercept before the general Router
|
||||
:trigger #'trigger-skill-model-explorer
|
||||
:neuro (lambda (context) nil) ; Bypass System 1
|
||||
:symbolic #'execute-skill-model-explorer)
|
||||
#+end_src
|
||||
65
notes/skill-org-delivery.org
Normal file
65
notes/skill-org-delivery.org
Normal file
@@ -0,0 +1,65 @@
|
||||
#+TITLE: Org-Native Delivery Skill
|
||||
#+AUTHOR: org-agent
|
||||
#+SKILL_NAME: skill-org-delivery
|
||||
|
||||
This skill provides the Actuator for external messaging by appending structured headlines to a central Org-mode delivery queue.
|
||||
|
||||
* Helper Functions
|
||||
#+begin_src lisp
|
||||
(defun format-universal-time-org (ut)
|
||||
"Format universal time as a standard Org-mode timestamp string."
|
||||
(multiple-value-bind (second minute hour day month year day-of-week)
|
||||
(decode-universal-time ut)
|
||||
(declare (ignore second day-of-week))
|
||||
(format nil "~4,'0d-~2,'0d-~2,'0d ~a ~2,'0d:~2,'0d"
|
||||
year month day
|
||||
(nth (nth-value 6 (decode-universal-time ut)) '("Mon" "Tue" "Wed" "Thu" "Fri" "Sat" "Sun"))
|
||||
hour minute)))
|
||||
#+end_src
|
||||
|
||||
* Sensor & State (Actuator Registration)
|
||||
When this skill loads, it registers itself to handle `:delivery` actions.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun execute-org-delivery (action)
|
||||
"Appends the message intent to the native Org-mode delivery file."
|
||||
(let* ((payload (getf action :payload))
|
||||
(text (getf payload :text))
|
||||
(channel (or (getf payload :channel) :signal))
|
||||
;; Support Telegram and Discord identifiers if provided
|
||||
(to (or (getf payload :to)
|
||||
(case (or (getf payload :channel) :signal)
|
||||
(:telegram (org-agent::get-env "TELEGRAM_CHAT_ID"))
|
||||
(:discord (org-agent::get-env "DISCORD_WEBHOOK_URL"))
|
||||
(t (org-agent::get-env "RECIPIENT_ID")))))
|
||||
(timestamp (format-universal-time-org (get-universal-time)))
|
||||
(system-dir (org-agent::get-env "SYSTEM_DIR" "system/"))
|
||||
(delivery-file (format nil "~a/delivery.org" system-dir)))
|
||||
|
||||
(kernel-log "ACTUATOR [Org-Delivery] - Enqueueing ~a message for ~a..." channel to)
|
||||
|
||||
(let ((entry (format nil "* TODO Message to ~a~% :PROPERTIES:~% :CHANNEL: ~a~% :ENQUEUED_AT: [~a]~% :STATUS: pending~% :END:~%~% ~a~%~%"
|
||||
to channel timestamp text)))
|
||||
|
||||
(handler-case
|
||||
(with-open-file (out delivery-file
|
||||
:direction :output
|
||||
:if-exists :append
|
||||
:if-does-not-exist :create)
|
||||
(write-string entry out)
|
||||
(kernel-log "ACTUATOR [Org-Delivery] - Entry appended to ~a" delivery-file))
|
||||
(error (c)
|
||||
(kernel-log "ACTUATOR [Org-Delivery] ERROR - Failed to write to file - ~a" c))))))
|
||||
|
||||
;; Register the actuator with the core Event Bus
|
||||
(org-agent:register-actuator :delivery #'execute-org-delivery)
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-org-delivery
|
||||
:priority 100 ; Actuators are high priority
|
||||
:trigger (lambda (context) nil) ; No cognitive trigger, actuator only
|
||||
:neuro (lambda (context) nil)
|
||||
:symbolic (lambda (action context) action))
|
||||
#+end_src
|
||||
86
notes/skill-project-foundry.org
Normal file
86
notes/skill-project-foundry.org
Normal file
@@ -0,0 +1,86 @@
|
||||
#+TITLE - Project Foundry Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-project-foundry
|
||||
|
||||
This skill allows the agent to scaffold new projects within the Memex workspace. It automates directory creation, git initialization, and links the project to the user's GTD system.
|
||||
|
||||
* Trigger
|
||||
Triggers only when delegated to by the Router.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-project-foundry (context)
|
||||
(let ((type (getf context :type))
|
||||
(payload (getf context :payload)))
|
||||
(and (eq type :EVENT)
|
||||
(eq (getf payload :sensor) :delegation)
|
||||
(eq (getf payload :target-skill) :foundry))))
|
||||
#+end_src
|
||||
|
||||
* Scaffolding Logic
|
||||
#+begin_src lisp
|
||||
(defun scaffold-project (name type)
|
||||
"Physically creates the project structure on disk and links it to GTD."
|
||||
(let* ((projects-dir (org-agent::get-env "PROJECTS_DIR" "/app/5_projects/"))
|
||||
(project-dir (format nil "~a/~a/" projects-dir name))
|
||||
(readme-path (format nil "~aREADME.org" project-dir))
|
||||
(memex-dir (org-agent::get-env "MEMEX_DIR" "/app/"))
|
||||
(gtd-file (format nil "~a/gtd.org" (string-right-trim "/" memex-dir))))
|
||||
|
||||
(if (uiop:directory-exists-p project-dir)
|
||||
(format nil "ERROR - Project ~a already exists." name)
|
||||
(progn
|
||||
(kernel-log "FOUNDRY - Scaffolding ~a project: ~a" type name)
|
||||
;; 1. Create directory
|
||||
(ensure-directories-exist project-dir)
|
||||
;; 2. Initialize Git (via shell delegation)
|
||||
(org-agent:inject-stimulus
|
||||
`(:type :EVENT :payload (:action :run-command :target :shell :cmd ,(format nil "git init ~a" project-dir))))
|
||||
|
||||
;; 3. Create Boilerplate README
|
||||
(with-open-file (out readme-path :direction :output :if-exists :supersede)
|
||||
(format out "#+TITLE - ~a~%#+AUTHOR - User~%#+DATE - ~a~%~%* Overview~%Automatically scaffolded ~a project.~%" name (get-universal-time) type))
|
||||
|
||||
;; 4. Link to GTD.org (Homoiconic Connection)
|
||||
(with-open-file (out gtd-file :direction :output :if-exists :append)
|
||||
(format out "~%* PROJ ~a~% :PROPERTIES:~% :PROJECT_PATH: $PROJECTS_DIR/~a~% :ID: proj-~a~% :END:~% Drafted by Project Foundry.~%"
|
||||
name name (get-universal-time)))
|
||||
|
||||
(format nil "SUCCESS - Project ~a scaffolded and linked to GTD.org" name)))))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-project-foundry (context)
|
||||
(let* ((payload (getf context :payload))
|
||||
(query (getf payload :query)))
|
||||
(format nil "
|
||||
You are the Project Foundry.
|
||||
The user wants to start a new project - '~a'
|
||||
|
||||
Extract the PROJECT NAME and the PROJECT TYPE.
|
||||
Return a Lisp plist - (:target :foundry :action :scaffold :name \"extracted-name\" :type \"extracted-type\")
|
||||
" query)))
|
||||
#+end_src
|
||||
|
||||
* Symbolic Verification & Actuation
|
||||
#+begin_src lisp
|
||||
(defun verify-skill-project-foundry (proposed-action context)
|
||||
(let* ((payload (getf proposed-action :payload))
|
||||
(action (getf proposed-action :action))
|
||||
(name (getf payload :name))
|
||||
(type (getf payload :type)))
|
||||
|
||||
(if (eq action :scaffold)
|
||||
(let ((result (scaffold-project name type)))
|
||||
`(:target :emacs :action :message :text ,result))
|
||||
nil)))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-project-foundry
|
||||
:priority 80
|
||||
:trigger #'trigger-skill-project-foundry
|
||||
:neuro #'neuro-skill-project-foundry
|
||||
:symbolic #'verify-skill-project-foundry)
|
||||
#+end_src
|
||||
80
notes/skill-project-manager.org
Normal file
80
notes/skill-project-manager.org
Normal file
@@ -0,0 +1,80 @@
|
||||
#+TITLE - Project Manager Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-project-manager
|
||||
|
||||
This skill provides the "Executive Presence" for project management. It uses the dynamic PROJECT_PATH to monitor project health and handle the lifecycle.
|
||||
|
||||
* Trigger
|
||||
Triggers on explicit project status requests or when a project heading is saved.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-project-manager (context)
|
||||
(let* ((payload (getf context :payload))
|
||||
(text (or (getf payload :text) ""))
|
||||
(ast (getf payload :ast)))
|
||||
(or (search "project status" text :test #'string-equal)
|
||||
(and (eq (getf payload :sensor) :buffer-update)
|
||||
(search "PROJECT_PATH" (format nil "~a" ast))))))
|
||||
#+end_src
|
||||
|
||||
* Project Logic
|
||||
#+begin_src lisp
|
||||
(defun get-project-diagnostics (raw-path)
|
||||
"Resolves the path and gathers folder facts (git status, file list)."
|
||||
(let* ((resolved-path (org-agent:context-resolve-path raw-path))
|
||||
(ls-cmd (format nil "ls -F ~a" resolved-path))
|
||||
(git-cmd (format nil "git -C ~a status --short" resolved-path)))
|
||||
(if (uiop:directory-exists-p resolved-path)
|
||||
(let ((files (ignore-errors (uiop:run-program ls-cmd :output :string :ignore-error-status t)))
|
||||
(git (ignore-errors (uiop:run-program git-cmd :output :string :ignore-error-status t))))
|
||||
(format nil "FILES -~%~a~%GIT STATUS -~%~a" files (or git "Not a git repo or clean.")))
|
||||
"ERROR - Project directory not found at resolved path.")))
|
||||
|
||||
(defun get-git-diff (raw-path)
|
||||
"Returns the current uncommitted changes in the project."
|
||||
(let ((resolved (org-agent:context-resolve-path raw-path)))
|
||||
(handler-case
|
||||
(uiop:run-program (format nil "git -C ~a diff" resolved) :output :string)
|
||||
(error () nil))))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-project-manager (context)
|
||||
(let* ((payload (getf context :payload))
|
||||
(ast (getf payload :ast))
|
||||
;; Extract the PROJECT_PATH from the current AST
|
||||
(path-match (nth-value 1 (cl-ppcre:scan-to-strings ":PROJECT_PATH: (\\$\\w+/[^\\s%]+)" (format nil "~a" ast)))))
|
||||
|
||||
(if path-match
|
||||
(let* ((raw-path (aref path-match 0))
|
||||
(diagnostics (get-project-diagnostics raw-path))
|
||||
(diff (get-git-diff raw-path)))
|
||||
(format nil "
|
||||
You are the Project Manager.
|
||||
The user is looking at a project with path - ~a
|
||||
|
||||
DIAGNOSTICS -
|
||||
~a
|
||||
|
||||
UNCOMMITTED CHANGES (Diff) -
|
||||
---
|
||||
~a
|
||||
---
|
||||
|
||||
TASK -
|
||||
1. Summarize the project status.
|
||||
2. If there are changes, suggest a 'git commit' message.
|
||||
3. Return a Lisp plist - (:target :emacs :action :message :text \"your report and commit suggestion\")
|
||||
" raw-path diagnostics (or diff "None.")))
|
||||
nil)))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-project-manager
|
||||
:priority 70
|
||||
:trigger #'trigger-skill-project-manager
|
||||
:neuro #'neuro-skill-project-manager
|
||||
:symbolic (lambda (action context) action))
|
||||
#+end_src
|
||||
57
notes/skill-provider-anthropic.org
Normal file
57
notes/skill-provider-anthropic.org
Normal file
@@ -0,0 +1,57 @@
|
||||
#+TITLE - Anthropic (Claude) Provider Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-provider-anthropic
|
||||
#+DEPENDS_ON - skill-environment-config
|
||||
|
||||
This skill registers Anthropic's Claude as a pluggable System 1 backend.
|
||||
|
||||
* Backend Implementation
|
||||
#+begin_src lisp
|
||||
(defun execute-anthropic-request (prompt system-prompt)
|
||||
"Executes a completion request via the Anthropic (Claude) API."
|
||||
(let ((api-key (org-agent::get-env "ANTHROPIC_API_KEY"))
|
||||
(config-pkg (find-package :org-agent.skills.skill-environment-config)))
|
||||
(unless api-key
|
||||
(return-from execute-anthropic-request "(:type :LOG :payload (:text \"Anthropic key missing\"))"))
|
||||
|
||||
(let* ((get-config-fn (when config-pkg (find-symbol "GET-CONFIG-ATTRIBUTE" config-pkg)))
|
||||
(model (if (and get-config-fn (fboundp get-config-fn))
|
||||
(funcall get-config-fn :LLM_MODEL_ANTHROPIC "claude-3-5-sonnet-20240620")
|
||||
"claude-3-5-sonnet-20240620"))
|
||||
(url "https://api.anthropic.com/v1/messages")
|
||||
(body (cl-json:encode-json-to-string
|
||||
`((model . ,model)
|
||||
(max_tokens . 1024)
|
||||
(system . ,system-prompt)
|
||||
(messages . (((role . "user") (content . ,prompt))))))))
|
||||
(handler-case
|
||||
(let* ((response (dex:post url
|
||||
:headers `(("Content-Type" . "application/json")
|
||||
("x-api-key" . ,api-key)
|
||||
("anthropic-version" . "2023-06-01"))
|
||||
:content body))
|
||||
(json (cl-json:decode-json-from-string response)))
|
||||
;; Extract content from Anthropic response
|
||||
(cdr (assoc :text (car (cdr (assoc :content json))))))
|
||||
(error (c)
|
||||
(format nil "(:type :LOG :payload (:text \"Anthropic Failure (~a) - ~a\"))" model c))))))
|
||||
|
||||
;; Register the backend
|
||||
(org-agent:register-neuro-backend :anthropic #'execute-anthropic-request)
|
||||
(org-agent:register-neuro-backend :claude #'execute-anthropic-request)
|
||||
|
||||
(defun get-available-models ()
|
||||
"Returns the list of LLM models supported by this provider."
|
||||
'((:id "claude-3-5-sonnet-20240620" :context "200k")
|
||||
(:id "claude-3-opus-20240229" :context "200k")
|
||||
(:id "claude-3-haiku-20240307" :context "200k")))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-provider-anthropic
|
||||
:priority 100
|
||||
:trigger (lambda (context) nil)
|
||||
:neuro (lambda (context) nil)
|
||||
:symbolic (lambda (action context) action))
|
||||
#+end_src
|
||||
39
notes/skill-provider-gemini.org
Normal file
39
notes/skill-provider-gemini.org
Normal file
@@ -0,0 +1,39 @@
|
||||
#+TITLE - Gemini Provider Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-provider-gemini
|
||||
|
||||
This skill registers Google's Gemini as a pluggable System 1 backend, moving the logic from the core to an Org-Native skill.
|
||||
|
||||
* Backend Implementation
|
||||
#+begin_src lisp
|
||||
(defun execute-gemini-v1-request (prompt system-prompt)
|
||||
"Executes a completion request via the Google Gemini v1beta API."
|
||||
(let ((api-key (org-agent::get-env "LLM_API_KEY"))
|
||||
(endpoint (org-agent::get-env "LLM_ENDPOINT")))
|
||||
(unless api-key
|
||||
(return-from execute-gemini-v1-request "(:type :LOG :payload (:text \"Gemini key missing\"))"))
|
||||
|
||||
(let* ((url (format nil "~a?key=~a" endpoint api-key))
|
||||
(body (cl-json:encode-json-to-string
|
||||
`((contents . ((parts . ((text . ,(format nil "~a~%~%Prompt - ~a" system-prompt prompt))))))))))
|
||||
(handler-case
|
||||
(let* ((response (dex:post url
|
||||
:headers '(("Content-Type" . "application/json"))
|
||||
:content body))
|
||||
(json (cl-json:decode-json-from-string response)))
|
||||
(cdr (assoc :text (cdr (assoc :parts (car (cdr (assoc :parts (car (cdr (assoc :candidates json)))))))))))
|
||||
(error (c)
|
||||
(format nil "(:type :LOG :payload (:text \"Gemini Failure - ~a\"))" c))))))
|
||||
|
||||
;; Register the official backend
|
||||
(org-agent:register-neuro-backend :gemini-official #'execute-gemini-v1-request)
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-provider-gemini
|
||||
:priority 100
|
||||
:trigger (lambda (context) nil)
|
||||
:neuro (lambda (context) nil)
|
||||
:symbolic (lambda (action context) action))
|
||||
#+end_src
|
||||
37
notes/skill-provider-ollama.org
Normal file
37
notes/skill-provider-ollama.org
Normal file
@@ -0,0 +1,37 @@
|
||||
#+TITLE - Ollama Provider Skill (Local)
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-provider-ollama
|
||||
|
||||
This skill registers a local Ollama instance as a pluggable System 1 backend.
|
||||
|
||||
* Backend Implementation
|
||||
#+begin_src lisp
|
||||
(defun execute-ollama-request (prompt system-prompt)
|
||||
"Executes a completion request via local Ollama."
|
||||
(let* ((url "http://host.docker.internal:11434/api/generate")
|
||||
(body (cl-json:encode-json-to-string
|
||||
`((model . "llama3")
|
||||
(system . ,system-prompt)
|
||||
(prompt . ,prompt)
|
||||
(stream . nil)))))
|
||||
(handler-case
|
||||
(let* ((response (dex:post url
|
||||
:headers '(("Content-Type" . "application/json"))
|
||||
:content body))
|
||||
(json (cl-json:decode-json-from-string response)))
|
||||
(cdr (assoc :response json)))
|
||||
(error (c)
|
||||
(format nil "(:type :LOG :payload (:text \"Ollama Failure - ~a\"))" c)))))
|
||||
|
||||
;; Register the backend
|
||||
(org-agent:register-neuro-backend :ollama #'execute-ollama-request)
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-provider-ollama
|
||||
:priority 100
|
||||
:trigger (lambda (context) nil)
|
||||
:neuro (lambda (context) nil)
|
||||
:symbolic (lambda (action context) action))
|
||||
#+end_src
|
||||
56
notes/skill-provider-openai.org
Normal file
56
notes/skill-provider-openai.org
Normal file
@@ -0,0 +1,56 @@
|
||||
#+TITLE - OpenAI Provider Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-provider-openai
|
||||
#+DEPENDS_ON - skill-environment-config
|
||||
|
||||
This skill registers OpenAI as a pluggable System 1 backend for the Neurosymbolic Kernel.
|
||||
|
||||
* Backend Implementation
|
||||
#+begin_src lisp
|
||||
(defun execute-openai-request (prompt system-prompt)
|
||||
"Executes a completion request via the OpenAI API."
|
||||
(let ((api-key (org-agent::get-env "OPENAI_API_KEY"))
|
||||
(config-pkg (find-package :org-agent.skills.skill-environment-config)))
|
||||
(unless api-key
|
||||
(return-from execute-openai-request "(:type :LOG :payload (:text \"OpenAI key missing\"))"))
|
||||
|
||||
(let* ((get-config-fn (when config-pkg (find-symbol "GET-CONFIG-ATTRIBUTE" config-pkg)))
|
||||
(model (if (and get-config-fn (fboundp get-config-fn))
|
||||
(funcall get-config-fn :LLM_MODEL_OPENAI "gpt-4-turbo-preview")
|
||||
"gpt-4-turbo-preview"))
|
||||
(url "https://api.openai.com/v1/chat/completions")
|
||||
(body (cl-json:encode-json-to-string
|
||||
`((model . ,model)
|
||||
(messages . (((role . "system") (content . ,system-prompt))
|
||||
((role . "user") (content . ,prompt))))
|
||||
(temperature . 0.2)))))
|
||||
(handler-case
|
||||
(let* ((response (dex:post url
|
||||
:headers `(("Content-Type" . "application/json")
|
||||
("Authorization" . ,(format nil "Bearer ~a" api-key)))
|
||||
:content body))
|
||||
(json (cl-json:decode-json-from-string response)))
|
||||
;; Extract content from OpenAI response structure
|
||||
(cdr (assoc :content (cdr (assoc :message (car (cdr (assoc :choices json))))))))
|
||||
(error (c)
|
||||
(format nil "(:type :LOG :payload (:text \"OpenAI Failure (~a) - ~a\"))" model c))))))
|
||||
|
||||
;; Register the backend upon skill load
|
||||
(org-agent:register-neuro-backend :openai #'execute-openai-request)
|
||||
|
||||
(defun get-available-models ()
|
||||
"Returns the list of LLM models supported by this provider."
|
||||
'((:id "gpt-4-turbo-preview" :context "128k")
|
||||
(:id "gpt-4o" :context "128k")
|
||||
(:id "gpt-4" :context "8k")
|
||||
(:id "gpt-3.5-turbo" :context "16k")))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-provider-openai
|
||||
:priority 100 ; Providers are foundational
|
||||
:trigger (lambda (context) nil) ; No cognitive trigger
|
||||
:neuro (lambda (context) nil)
|
||||
:symbolic (lambda (action context) action))
|
||||
#+end_src
|
||||
63
notes/skill-provider-openrouter.org
Normal file
63
notes/skill-provider-openrouter.org
Normal file
@@ -0,0 +1,63 @@
|
||||
#+TITLE - OpenRouter Provider Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-provider-openrouter
|
||||
#+DEPENDS_ON - skill-environment-config
|
||||
|
||||
This skill registers OpenRouter as a pluggable System 1 backend, providing access to hundreds of models.
|
||||
|
||||
* Backend Implementation
|
||||
#+begin_src lisp
|
||||
(defun execute-openrouter-request (prompt system-prompt)
|
||||
"Executes a completion request via the OpenRouter API (OpenAI-compatible)."
|
||||
(let ((api-key (org-agent::get-env "OPENROUTER_API_KEY"))
|
||||
(config-pkg (find-package :org-agent.skills.skill-environment-config)))
|
||||
(unless api-key
|
||||
(return-from execute-openrouter-request "(:type :LOG :payload (:text \"OpenRouter key missing\"))"))
|
||||
|
||||
(let* ((get-config-fn (when config-pkg (find-symbol "GET-CONFIG-ATTRIBUTE" config-pkg)))
|
||||
(get-tiered-fn (when config-pkg (find-symbol "GET-TIERED-MODEL" config-pkg)))
|
||||
;; Try to find a specific OpenRouter model, or a generic tiered model
|
||||
(model (cond
|
||||
((and get-config-fn (funcall get-config-fn :LLM_MODEL_OPENROUTER nil))
|
||||
(funcall get-config-fn :LLM_MODEL_OPENROUTER nil))
|
||||
((and get-tiered-fn (funcall get-tiered-fn :fast nil))
|
||||
(funcall get-tiered-fn :fast nil))
|
||||
(t "meta-llama/llama-3-70b-instruct")))
|
||||
(url "https://openrouter.ai/api/v1/chat/completions")
|
||||
(body (cl-json:encode-json-to-string
|
||||
`((model . ,model)
|
||||
(messages . (((role . "system") (content . ,system-prompt))
|
||||
((role . "user") (content . ,prompt))))))))
|
||||
(handler-case
|
||||
(let* ((response (dex:post url
|
||||
:headers `(("Content-Type" . "application/json")
|
||||
("Authorization" . ,(format nil "Bearer ~a" api-key))
|
||||
("HTTP-Referer" . "https://github.com/org-agent/org-agent") ("X-Title" . "org-agent"))
|
||||
:content body))
|
||||
(json (cl-json:decode-json-from-string response)))
|
||||
;; Extract content from OpenAI-compatible response structure
|
||||
(cdr (assoc :content (cdr (assoc :message (car (cdr (assoc :choices json))))))))
|
||||
(error (c)
|
||||
(format nil "(:type :LOG :payload (:text \"OpenRouter Failure (~a) - ~a\"))" model c))))))
|
||||
|
||||
;; Register the backend
|
||||
(org-agent:register-neuro-backend :openrouter #'execute-openrouter-request)
|
||||
|
||||
(defun get-available-models ()
|
||||
"Returns a curated list of top LLM models supported by OpenRouter, including free tiers."
|
||||
'((:id "moonshotai/kimi-k2.5" :context "128k" :tier :powerful)
|
||||
(:id "anthropic/claude-3.5-sonnet" :context "200k" :tier :powerful)
|
||||
(:id "google/gemini-flash-1.5" :context "1m" :tier :fast)
|
||||
(:id "google/gemma-2-9b-it:free" :context "8k" :tier :free)
|
||||
(:id "mistralai/pixtral-12b:free" :context "32k" :tier :free)
|
||||
(:id "openrouter/auto" :context "varying" :tier :free)))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-provider-openrouter
|
||||
:priority 100
|
||||
:trigger (lambda (context) nil)
|
||||
:neuro (lambda (context) nil)
|
||||
:symbolic (lambda (action context) action))
|
||||
#+end_src
|
||||
118
notes/skill-router.org
Normal file
118
notes/skill-router.org
Normal file
@@ -0,0 +1,118 @@
|
||||
#+TITLE: LLM Router Skill
|
||||
#+AUTHOR: org-agent
|
||||
#+SKILL_NAME: skill-router
|
||||
#+DEPENDS_ON: skill-environment-config
|
||||
|
||||
This skill acts as the Meta-Cognitive Router. It intercepts unstructured user requests, asks the LLM to classify the intent, and emits internal delegation events.
|
||||
|
||||
* Trigger Logic
|
||||
The Router triggers on explicit `M-x` commands OR when it detects an "@agent" or "@[Name]" request in an Org headline during a buffer save.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun find-agent-request (ast agent-name)
|
||||
"Recursively search the AST for a headline addressed to @agent or @name."
|
||||
(when (listp ast)
|
||||
(let* ((type (getf ast :type))
|
||||
(props (getf ast :properties))
|
||||
(title (or (getf props :TITLE) "")))
|
||||
(if (and (eq type :HEADLINE)
|
||||
(or (search "@agent" title :test #'string-equal)
|
||||
(search (format nil "@~a" agent-name) title :test #'string-equal)))
|
||||
;; Found it! Extract the instruction (everything after the @ tag)
|
||||
(let* ((pos (or (search "@agent" title :test #'string-equal)
|
||||
(search (format nil "@~a" agent-name) title :test #'string-equal)))
|
||||
;; Skip the '@name' part
|
||||
(instruction (subseq title (+ pos (if (search "@agent" title :test #'string-equal) 6 (1+ (length agent-name)))))))
|
||||
(string-trim '(#\Space #\Tab) instruction))
|
||||
;; Not here, recurse into children
|
||||
(cl:some (lambda (c) (find-agent-request c agent-name)) (getf ast :contents))))))
|
||||
|
||||
(defun trigger-skill-router (context)
|
||||
"Engage if a user command exists OR if an @agent/@name request is found in the AST."
|
||||
(let* ((payload (getf context :payload))
|
||||
(sensor (getf payload :sensor))
|
||||
;; DYNAMIC NAME RESOLUTION:
|
||||
;; We look for the get-agent-name function in the identity skill's package.
|
||||
;; If the skill hasn't loaded yet, we fall back to "Agent".
|
||||
(identity-pkg (find-package :org-agent.skills.skill-agent-identity))
|
||||
(name-fn (when identity-pkg (find-symbol "GET-AGENT-NAME" identity-pkg)))
|
||||
(agent-name (if (and name-fn (fboundp name-fn))
|
||||
(funcall name-fn)
|
||||
"Agent")))
|
||||
(cond
|
||||
((eq sensor :user-command) t)
|
||||
((eq sensor :buffer-update)
|
||||
;; Proactive scanning of the AST using the dynamic name
|
||||
(let ((request (find-agent-request (getf payload :ast) agent-name)))
|
||||
(when request
|
||||
;; Store the extracted instruction in the context for System 1
|
||||
(setf (getf (getf context :payload) :text) request)
|
||||
(kernel-log "KERNEL [Router] Detected request for @~a: ~a" agent-name request)
|
||||
t)))
|
||||
(t nil))))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-router (context)
|
||||
(let ((text (getf (getf context :payload) :text))
|
||||
(config-pkg (find-package :org-agent.skills.skill-environment-config)))
|
||||
(let* ((get-tiered-fn (when config-pkg (find-symbol "GET-TIERED-MODEL" config-pkg)))
|
||||
;; Router uses the :FAST tier for routing efficiency
|
||||
(model (if (and get-tiered-fn (fboundp get-tiered-fn))
|
||||
(funcall get-tiered-fn :fast "openrouter/auto")
|
||||
"openrouter/auto")))
|
||||
(format nil "
|
||||
You are the Master Router for an autonomous Lisp agent.
|
||||
The user said - '~a'
|
||||
|
||||
Using model: ~a
|
||||
|
||||
Decompose this request into a SEQUENCE of atomic intents.
|
||||
Available targets -
|
||||
- :atomic-notes (historical memory/note retrieval)
|
||||
- :shell (system commands like git status)
|
||||
- :gtd (tasks, deadlines, schedules)
|
||||
- :web (internet research, fetching URLs, searching the web)
|
||||
- :foundry (scaffolding new projects, creating directories)
|
||||
- :skill-creator (new capabilities, create a skill)
|
||||
|
||||
Return a Lisp plist containing a list of intents -
|
||||
(:type :MULTI-DELEGATION :intents ((:target-skill :atomic-notes :query \"...\") (:target-skill :shell :cmd \"...\")))
|
||||
" text model))))
|
||||
#+end_src
|
||||
|
||||
* Symbolic Verification
|
||||
#+begin_src lisp
|
||||
(defun verify-skill-router (proposed-action context)
|
||||
(let ((type (getf proposed-action :type)))
|
||||
(cond
|
||||
((eq type :MULTI-DELEGATION)
|
||||
(let ((intents (getf proposed-action :intents)))
|
||||
(kernel-log "KERNEL [Router] Processing ~a intents.~%" (length intents))
|
||||
(dolist (intent intents)
|
||||
(let* ((target (getf intent :target-skill))
|
||||
(query (getf intent :query))
|
||||
(cmd (getf intent :cmd))
|
||||
(delegation-event `(:type :EVENT :payload (:sensor :delegation :target-skill ,target :query ,query :cmd ,cmd))))
|
||||
(kernel-log "KERNEL [Router] Delegating to ~a~%" target)
|
||||
(org-agent:inject-stimulus delegation-event)))
|
||||
nil))
|
||||
((eq type :DELEGATION)
|
||||
(let* ((target (getf proposed-action :target-skill))
|
||||
(query (getf proposed-action :query))
|
||||
(delegation-event `(:type :EVENT :payload (:sensor :delegation :target-skill ,target :query ,query))))
|
||||
(kernel-log "KERNEL [Router] Delegating to ~a~%" target)
|
||||
(org-agent:inject-stimulus delegation-event)
|
||||
nil))
|
||||
(t '(:type :LOG :payload (:text "Router failed to classify."))))))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-router
|
||||
:priority 90
|
||||
:trigger #'trigger-skill-router
|
||||
:neuro #'neuro-skill-router
|
||||
:symbolic #'verify-skill-router)
|
||||
#+end_src
|
||||
79
notes/skill-self-fix.org
Normal file
79
notes/skill-self-fix.org
Normal file
@@ -0,0 +1,79 @@
|
||||
#+TITLE - Immune System Skill (Self-Fix)
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-self-fix
|
||||
|
||||
This skill acts as the agent's internal repair drone. It monitors the system logs for "pain" (errors, rejections, hallucinations) and autonomously refactors the offending skills.
|
||||
|
||||
* Trigger
|
||||
Triggers periodically on the background heartbeat.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-self-fix (context)
|
||||
(let ((type (getf context :type))
|
||||
(payload (getf context :payload)))
|
||||
;; Check every heartbeat
|
||||
(and (eq type :EVENT)
|
||||
(eq (getf payload :sensor) :heartbeat))))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
System 1 analyzes the most recent system logs. If it detects a recurring error or a System 2 rejection, it drafts a fix for the skill's source code.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-self-fix (context)
|
||||
"Examine system logs for errors and draft fixes for the agent's own code."
|
||||
(let* ((logs (org-agent:context-get-system-logs 30))
|
||||
(logs-str (format nil "~{~a~%~}" logs)))
|
||||
|
||||
;; Only engage if the logs actually contain signs of failure
|
||||
(if (or (search "REJECTED" logs-str)
|
||||
(search "ERROR" logs-str)
|
||||
(search "hallucinated" logs-str)
|
||||
(search "Syntax error" logs-str))
|
||||
|
||||
(format nil "
|
||||
You are the Immune System of a Neurosymbolic Lisp Machine.
|
||||
You have detected 'pain' in the system logs:
|
||||
---
|
||||
~a
|
||||
---
|
||||
|
||||
TASK:
|
||||
1. Identify which skill is failing based on the log messages.
|
||||
2. Use your knowledge of the Org-Native Skill Standard to draft a fix.
|
||||
3. If a System 2 rule rejected an action, refine the System 1 prompt to be more compliant.
|
||||
4. If there was a Lisp syntax error, correct the Lisp block.
|
||||
|
||||
Return a Lisp plist - (:target :system :action :create-skill :filename \"skill-name.org\" :content \"the full fixed org content\")
|
||||
|
||||
Note - You can call (org-agent:context-get-skill-source \"skill-name\") if you need to see the current code.
|
||||
" logs-str)
|
||||
|
||||
;; If logs are clean, stay dormant
|
||||
nil)))
|
||||
#+end_src
|
||||
|
||||
* Symbolic Verification
|
||||
System 2 ensures the "surgery" is safe before applying it.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun verify-skill-self-fix (proposed-action context)
|
||||
"Delegate to the skill-creator's logic for final acquisition, as it already has syntax validation."
|
||||
(let ((action (getf proposed-action :action)))
|
||||
(if (eq action :create-skill)
|
||||
;; We pass this to the core creator logic (or we could just let it pass here
|
||||
;; since skill-creator will handle the actual file write if it were a separate skill,
|
||||
;; but here we just return it and let the dispatcher handle it if we had a system actuator).
|
||||
;; For now, we reuse the verify-skill-creator logic if it's available.
|
||||
proposed-action
|
||||
nil)))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-self-fix
|
||||
:priority 40 ; Low priority, runs after primary domain logic
|
||||
:trigger #'trigger-skill-self-fix
|
||||
:neuro #'neuro-skill-self-fix
|
||||
:symbolic #'verify-skill-self-fix)
|
||||
#+end_src
|
||||
92
notes/skill-shell-actuator.org
Normal file
92
notes/skill-shell-actuator.org
Normal file
@@ -0,0 +1,92 @@
|
||||
#+TITLE - Shell Actuator Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-shell-actuator
|
||||
|
||||
This skill gives the agent the ability to execute shell commands, protected by a strict, hardcoded whitelist.
|
||||
|
||||
* Sensor & State (Actuator Registration)
|
||||
When this skill loads, it registers itself to handle `:shell` actions.
|
||||
|
||||
#+begin_src lisp
|
||||
;; A strict whitelist of permitted executables
|
||||
(defparameter *allowed-commands* '("ls" "git" "rg" "grep" "date" "echo" "cat"))
|
||||
|
||||
(defun execute-shell-safely (action)
|
||||
"System 2 strictly verifies the command against the whitelist and captures full diagnostics."
|
||||
(let* ((cmd-string (getf (getf action :payload) :cmd))
|
||||
(executable (car (uiop:split-string cmd-string :separator '(#\Space)))))
|
||||
|
||||
(if (member executable *allowed-commands* :test #'string=)
|
||||
(progn
|
||||
(format t "Shell Actuator - Executing '~a'~%" cmd-string)
|
||||
(multiple-value-bind (stdout stderr exit-code)
|
||||
(uiop:run-program cmd-string
|
||||
:output :string
|
||||
:error-output :string
|
||||
:ignore-error-status t)
|
||||
;; Inject structured diagnostics back into the core bus
|
||||
(org-agent:inject-stimulus
|
||||
`(:type :EVENT
|
||||
:payload (:sensor :shell-response
|
||||
:cmd ,cmd-string
|
||||
:stdout ,(or stdout "")
|
||||
:stderr ,(or stderr "")
|
||||
:exit-code ,exit-code)))))
|
||||
(progn
|
||||
(format t "Shell Actuator - BLOCKED illegal command '~a'~%" cmd-string)
|
||||
(org-agent:inject-stimulus
|
||||
`(:type :EVENT
|
||||
:payload (:sensor :shell-response
|
||||
:cmd ,cmd-string
|
||||
:stdout ""
|
||||
:stderr "ERROR - Command not in security whitelist."
|
||||
:exit-code 1)))))))
|
||||
|
||||
;; Register the actuator
|
||||
(org-agent:register-actuator :shell #'execute-shell-safely)
|
||||
#+end_src
|
||||
|
||||
* Trigger
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-shell-actuator (context)
|
||||
(let ((type (getf context :type))
|
||||
(payload (getf context :payload)))
|
||||
(and (eq type :EVENT)
|
||||
(eq (getf payload :sensor) :shell-response))))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-shell-actuator (context)
|
||||
(let* ((p (getf context :payload))
|
||||
(cmd (getf p :cmd))
|
||||
(stdout (getf p :stdout))
|
||||
(stderr (getf p :stderr))
|
||||
(exit-code (getf p :exit-code)))
|
||||
(format nil "
|
||||
You executed the shell command - '~a'
|
||||
EXIT CODE - ~a
|
||||
|
||||
STDOUT:
|
||||
---
|
||||
~a
|
||||
---
|
||||
|
||||
STDERR:
|
||||
---
|
||||
~a
|
||||
---
|
||||
|
||||
Analyze the diagnostics. If there was an error, explain why and suggest a fix.
|
||||
Return a Lisp plist - (:target :emacs :action :message :text \"your summary\")
|
||||
" cmd exit-code stdout stderr)))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-shell-actuator
|
||||
:priority 80
|
||||
:trigger #'trigger-skill-shell-actuator
|
||||
:neuro #'neuro-skill-shell-actuator
|
||||
:symbolic (lambda (action context) action)) ; Pass-through, safety handled by actuator fn
|
||||
#+end_src
|
||||
101
notes/skill-task-integrity.org
Normal file
101
notes/skill-task-integrity.org
Normal file
@@ -0,0 +1,101 @@
|
||||
#+TITLE - Task Integrity Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-task-integrity
|
||||
|
||||
This skill handles automated GTD state transitions and integrity.
|
||||
|
||||
* Trigger
|
||||
Triggers only on buffer updates where the AST contains TODO states.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-task-integrity (context)
|
||||
(let ((type (getf context :type))
|
||||
(payload (getf context :payload)))
|
||||
(and (eq type :EVENT)
|
||||
(eq (getf payload :sensor) :buffer-update))))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
System 1 asks for suggestions on the next action. It uses the Context API
|
||||
to provide the LLM with "peripheral vision" of the user's workload.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-task-integrity (context)
|
||||
"Generate a System 1 prompt by gathering relevant facts from the Object Store."
|
||||
(let ((recent-wins (org-agent:context-get-recent-completed-tasks))
|
||||
(projects (org-agent:context-get-active-projects)))
|
||||
;; We construct a rich, human-readable prompt that describes the user's
|
||||
;; current reality, momentum, and the latest event.
|
||||
(format nil "
|
||||
You are the user's Executive Assistant managing their Org-mode GTD system.
|
||||
CURRENT MOMENTUM (Recently DONE) - ~a
|
||||
ACTIVE PROJECTS - ~a
|
||||
|
||||
NEW EVENT - ~a
|
||||
|
||||
Suggest the next logical Org-mode action.
|
||||
Provide concise, high-fidelity suggestions in Lisp plist format.
|
||||
You MUST include :target :emacs in your top-level plist if you intend to execute an action.
|
||||
" recent-wins projects context)))
|
||||
#+end_src
|
||||
|
||||
* Symbolic Verification
|
||||
System 2 enforces GTD integrity using deterministic Lisp logic compatible
|
||||
with org-gtd v4.0. It ensures that a task cannot be closed (resolved)
|
||||
if it has active dependencies or children.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun semantic-state-category (state)
|
||||
"Map a keyword state to its org-gtd v4.0 semantic category."
|
||||
(let ((s (string-upcase (or state ""))))
|
||||
(cond
|
||||
((member s '("TODO" "NEXT" "WAIT") :test #'string=) :active)
|
||||
((member s '("DONE" "CNCL" "CANCELED") :test #'string=) :resolved)
|
||||
(t :unknown))))
|
||||
|
||||
(defun has-active-children-p (parent-id)
|
||||
"Recursively check if a node has any children in an :active semantic state."
|
||||
(let ((parent (org-agent:lookup-object parent-id)))
|
||||
(when parent
|
||||
(cl:some (lambda (child-id)
|
||||
(let* ((child (org-agent:lookup-object child-id))
|
||||
(state (getf (org-agent:org-object-attributes child) :TODO-STATE)))
|
||||
(or (eq (semantic-state-category state) :active)
|
||||
(has-active-children-p child-id))))
|
||||
(org-agent:org-object-children parent)))))
|
||||
|
||||
(defun verify-skill-task-integrity (proposed-action context)
|
||||
"The System 2 gatekeeper for task consistency.
|
||||
Ensures parent tasks cannot be closed if children are still active."
|
||||
(let* ((payload (getf proposed-action :payload))
|
||||
(action (getf payload :action))
|
||||
(target-id (getf payload :target-id))
|
||||
(props (getf payload :properties))
|
||||
(new-state (cdr (assoc :TODO-STATE props))))
|
||||
|
||||
;; If the proposal attempts to transition a node to a :resolved state
|
||||
(if (and (eq action :refactor-subtree)
|
||||
target-id
|
||||
(eq (semantic-state-category new-state) :resolved))
|
||||
|
||||
;; Verify that all hierarchical dependencies are met
|
||||
(if (has-active-children-p target-id)
|
||||
(progn
|
||||
(format t "System 2 [skill-task-integrity] - BLOCKED transition of ~a to ~a. Active children remain.~%" target-id new-state)
|
||||
nil) ; Return NIL to block the illegal state change
|
||||
proposed-action)
|
||||
|
||||
;; Allow all other actions (e.g., TODO -> NEXT, or simple property updates)
|
||||
proposed-action)))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
Register the skill.
|
||||
|
||||
#+begin_src lisp
|
||||
(defskill :skill-task-integrity
|
||||
:priority 50
|
||||
:trigger #'trigger-skill-task-integrity
|
||||
:neuro #'neuro-skill-task-integrity
|
||||
:symbolic #'verify-skill-task-integrity)
|
||||
#+end_src
|
||||
60
notes/skill-web-interface.org
Normal file
60
notes/skill-web-interface.org
Normal file
@@ -0,0 +1,60 @@
|
||||
#+TITLE - Web Dashboard Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-web-interface
|
||||
|
||||
This skill provides a lightweight web interface for the Neurosymbolic Kernel using the Hunchentoot server.
|
||||
|
||||
* Web Server Implementation
|
||||
#+begin_src lisp
|
||||
(defvar *web-server* nil)
|
||||
|
||||
(defun start-dashboard (&optional (port 8080))
|
||||
"Starts the Hunchentoot dashboard server."
|
||||
(unless *web-server*
|
||||
(setf *web-server* (make-instance 'hunchentoot:easy-acceptor :port port))
|
||||
(hunchentoot:start *web-server*)
|
||||
(kernel-log "WEB - Dashboard live on port ~a" port)))
|
||||
|
||||
(hunchentoot:define-easy-handler (dashboard-home :uri "/") ()
|
||||
(setf (hunchentoot:content-type*) "text/html")
|
||||
(let* ((skills (org-agent:context-list-all-skills))
|
||||
(telemetry (mapcar (lambda (s)
|
||||
(let ((stats (org-agent:context-get-skill-telemetry (getf s :name))))
|
||||
(format nil "<li><b>~a</b> (P:~a) [Execs: ~a, Time: ~ams, Fails: ~a]</li>"
|
||||
(getf s :name)
|
||||
(getf s :priority)
|
||||
(or (getf stats :executions) 0)
|
||||
(or (getf stats :total-time) 0)
|
||||
(or (getf stats :failures) 0))))
|
||||
skills)))
|
||||
(format nil "
|
||||
<html>
|
||||
<head><title>org-agent Dashboard</title></head>
|
||||
<body style='font-family: monospace; background: #111; color: #eee; padding: 20px;'>
|
||||
<h1>org-agent Neurosymbolic Kernel</h1>
|
||||
<hr>
|
||||
<h2>Active Skill Graph & Telemetry</h2>
|
||||
<ul>
|
||||
~{~a~%~}
|
||||
</ul>
|
||||
<hr>
|
||||
<h2>Recent Logs</h2>
|
||||
<pre>~{~a~%~}</pre>
|
||||
</body>
|
||||
</html>
|
||||
" telemetry (org-agent:context-get-system-logs 20))))
|
||||
|
||||
;; Start the dashboard upon skill load
|
||||
(let* ((env-port (uiop:getenv "ORG_AGENT_WEB_PORT"))
|
||||
(port (if env-port (parse-integer env-port :junk-allowed t) 8080)))
|
||||
(start-dashboard port))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-web-interface
|
||||
:priority 10 ; Low priority, background service
|
||||
:trigger (lambda (context) nil)
|
||||
:neuro (lambda (context) nil)
|
||||
:symbolic (lambda (action context) action))
|
||||
#+end_src
|
||||
95
notes/skill-web-research.org
Normal file
95
notes/skill-web-research.org
Normal file
@@ -0,0 +1,95 @@
|
||||
#+TITLE: Web Research Skill (Generalized)
|
||||
#+AUTHOR: org-agent
|
||||
#+SKILL_NAME: skill-web-research
|
||||
|
||||
This skill provides the agent with internet connectivity via multiple pluggable browser engines.
|
||||
|
||||
* Trigger
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-web-research (context)
|
||||
(let ((type (getf context :type))
|
||||
(payload (getf context :payload)))
|
||||
(and (eq type :EVENT)
|
||||
(eq (getf payload :sensor) :delegation)
|
||||
(eq (getf payload :target-skill) :web))))
|
||||
#+end_src
|
||||
|
||||
* Browser Engines
|
||||
We define multiple backends for fetching web content.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun fetch-with-lynx (url)
|
||||
"Engine: Lynx. Best for fast text extraction from blogs/docs."
|
||||
(let ((cmd (format nil "lynx -dump -nolist '~a'" url)))
|
||||
(uiop:run-program cmd :output :string :ignore-error-status t)))
|
||||
|
||||
(defun fetch-with-curl (url)
|
||||
"Engine: Curl. Best for raw HTML or API inspection."
|
||||
(let ((cmd (format nil "curl -sL '~a'" url)))
|
||||
(uiop:run-program cmd :output :string :ignore-error-status t)))
|
||||
|
||||
(defun fetch-with-playwright (url)
|
||||
"Engine: Playwright (Placeholder). In the future, this calls a Python bridge."
|
||||
(format nil "ERROR: Playwright engine not yet implemented. Falling back to Lynx...~%~a"
|
||||
(fetch-with-lynx url)))
|
||||
|
||||
(defun web-fetch (url &optional engine)
|
||||
"Dispatch the fetch request to the specified engine (defaults to Lynx)."
|
||||
(case engine
|
||||
(:lynx (fetch-with-lynx url))
|
||||
(:curl (fetch-with-curl url))
|
||||
(:playwright (fetch-with-playwright url))
|
||||
(t (fetch-with-lynx url))))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
System 1 chooses the engine based on the task complexity.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-web-research (context)
|
||||
(let* ((payload (getf context :payload))
|
||||
(query (getf payload :query))
|
||||
;; The LLM can specify an engine. If not, we default to Lynx.
|
||||
(requested-engine (or (getf payload :engine) :lynx))
|
||||
(is-url (or (search "http://" query) (search "https://" query)))
|
||||
(target-url (if is-url
|
||||
query
|
||||
(format nil "https://duckduckgo.com/html/?q=~a" query)))
|
||||
(web-text (web-fetch target-url requested-engine)))
|
||||
|
||||
(let ((curated (if (and web-text (> (length web-text) 5000))
|
||||
(format nil "~a... [TRUNCATED]" (subseq web-text 0 5000))
|
||||
(or web-text "No content fetched."))))
|
||||
|
||||
(format nil "
|
||||
You are the Web Research synthesizer.
|
||||
USER QUERY - '~a'
|
||||
ENGINE USED - ~a
|
||||
TARGET URL - ~a
|
||||
|
||||
RAW CONTENT FETCHED -
|
||||
---
|
||||
~a
|
||||
---
|
||||
|
||||
Synthesize a concise, factual answer.
|
||||
Return a Lisp plist - (:target :emacs :action :message :text \"your summary\")
|
||||
" query requested-engine target-url curated))))
|
||||
#+end_src
|
||||
|
||||
* Symbolic Verification
|
||||
#+begin_src lisp
|
||||
(defun verify-skill-web-research (proposed-action context)
|
||||
(if (eq (getf proposed-action :action) :message)
|
||||
proposed-action
|
||||
'(:target :emacs :action :message :text "Web skill failed to synthesize message.")))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-web-research
|
||||
:priority 80
|
||||
:trigger #'trigger-skill-web-research
|
||||
:neuro #'neuro-skill-web-research
|
||||
:symbolic #'verify-skill-web-research)
|
||||
#+end_src
|
||||
52
notes/skill-workspace-manager.org
Normal file
52
notes/skill-workspace-manager.org
Normal file
@@ -0,0 +1,52 @@
|
||||
#+TITLE - Workspace Manager Skill
|
||||
#+AUTHOR - org-agent
|
||||
#+SKILL_NAME - skill-workspace-manager
|
||||
|
||||
This skill automates the Para/Memex workflow, such as archiving DONE tasks and organizing the inbox.
|
||||
|
||||
* Trigger
|
||||
Triggers on buffer saves or background heartbeats.
|
||||
|
||||
#+begin_src lisp
|
||||
(defun trigger-skill-workspace-manager (context)
|
||||
(let* ((payload (getf context :payload))
|
||||
(sensor (getf payload :sensor)))
|
||||
(or (eq sensor :buffer-update)
|
||||
(eq sensor :heartbeat))))
|
||||
#+end_src
|
||||
|
||||
* Symbolic Logic
|
||||
#+begin_src lisp
|
||||
(defun archive-completed-tasks ()
|
||||
"Identify DONE tasks and suggest archiving."
|
||||
(let ((done-tasks (org-agent:context-query-store :todo-state "DONE" :type :HEADLINE)))
|
||||
(when done-tasks
|
||||
(kernel-log "WORKSPACE - Found ~a tasks ready for archiving." (length done-tasks))
|
||||
;; Return a list of IDs to move
|
||||
(mapcar #'org-agent:org-object-id done-tasks))))
|
||||
#+end_src
|
||||
|
||||
* Neuro Prompt
|
||||
#+begin_src lisp
|
||||
(defun neuro-skill-workspace-manager (context)
|
||||
(let ((ready-to-archive (archive-completed-tasks))
|
||||
(archive-dir (org-agent::get-env "ARCHIVES_DIR" "/app/8_archives/")))
|
||||
(if ready-to-archive
|
||||
(format nil "
|
||||
WORKSPACE UPDATE -
|
||||
I found these tasks marked DONE in the Atomic Notes (Zettelkasten) - ~a
|
||||
|
||||
Suggest an Org-mode action to move them to the '~a' folder.
|
||||
Return a Lisp plist - (:target :emacs :action :message :text \"I found completed tasks. Should I archive them?\")
|
||||
" ready-to-archive archive-dir)
|
||||
nil)))
|
||||
#+end_src
|
||||
|
||||
* Registration
|
||||
#+begin_src lisp
|
||||
(defskill :skill-workspace-manager
|
||||
:priority 40
|
||||
:trigger #'trigger-skill-workspace-manager
|
||||
:neuro #'neuro-skill-workspace-manager
|
||||
:symbolic (lambda (action context) action))
|
||||
#+end_src
|
||||
53
notes/tool_failure_protocol.org
Normal file
53
notes/tool_failure_protocol.org
Normal file
@@ -0,0 +1,53 @@
|
||||
#+TITLE: Tool Failure Protocol
|
||||
#+AUTHOR: User
|
||||
#+CREATED: [2026-03-17 Mon]
|
||||
#+ID: 20260317-tool-failure-protocol
|
||||
#+BEGIN_COMMENT
|
||||
When encountering tool errors, follow debug protocol instead of panic responses.
|
||||
#+END_COMMENT
|
||||
|
||||
* The Protocol
|
||||
|
||||
When tools fail, execute these steps in order:
|
||||
|
||||
1. READ the error message completely
|
||||
2. IDENTIFY the specific issue (missing parameter? syntax error? wrong path?)
|
||||
3. FIX the actual syntax problem
|
||||
4. RETRY with corrected parameters
|
||||
5. ESCALATE only if 2 attempts fail — with SPECIFIC error, not "what should I do?"
|
||||
|
||||
* Anti-Patterns (STOP DOING)
|
||||
|
||||
** Gateway Restart Misuse
|
||||
Using gateway restart as panic response to tool errors is WRONG because:
|
||||
- Restarts are for gateway service issues, not syntax errors
|
||||
- Doesn't fix the underlying problem
|
||||
- Disrupts service unnecessarily
|
||||
|
||||
** When to ACTUALLY restart gateway:**
|
||||
- Gateway daemon unresponsive (not heartbeat check)
|
||||
- Actual service crashes or memory leaks
|
||||
- NOT for: tool syntax errors, model timeouts, context saturation
|
||||
|
||||
** Decision Escalation
|
||||
Asking "What should I do?" when I have:
|
||||
- Complexity check results
|
||||
- Clear criteria for action
|
||||
- SOUL.md mandate for "No Operational Escalation"
|
||||
|
||||
* Positive Patterns to Reinforce
|
||||
|
||||
** Work Breakdown Success
|
||||
Identified 51 gaps across 10 files as complex.
|
||||
Decomposed into atomic tasks.
|
||||
Used sub-agents for parallel execution.
|
||||
Results: efficient verification with proper orchestration.
|
||||
|
||||
** Wait Mode Discipline
|
||||
After spawning sub-agents, entered proper wait mode.
|
||||
Did NOT poll status or restart gateway.
|
||||
Waited for push-based completion events.
|
||||
|
||||
* Core Rule
|
||||
|
||||
Tool failure is a debug challenge, not a crisis.
|
||||
47
notes/user-accounts.org
Normal file
47
notes/user-accounts.org
Normal file
@@ -0,0 +1,47 @@
|
||||
#+TITLE: User - Associated Accounts
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+DATE: 2026-03-04
|
||||
#+FILETAGS: :reference:identity:accounts
|
||||
|
||||
* User Account Access
|
||||
:PROPERTIES:
|
||||
:ID: 20260304-user-accounts
|
||||
:CREATED: [2026-03-04 Tue 21:15 EST]
|
||||
:END:
|
||||
|
||||
** Overview
|
||||
|
||||
Grandfathered email account with legacy access to multiple services.
|
||||
|
||||
** Email
|
||||
- Address: user@example.com
|
||||
- Type: Grandfathered account
|
||||
- Status: Active
|
||||
|
||||
** Associated Services
|
||||
|
||||
| Service | Type | Notes |
|
||||
|---------|------|-------|
|
||||
| Facebook | Social | Grandfathered access |
|
||||
| Instagram | Social | Via Facebook connection |
|
||||
| OnlyFans | Content | Grandfathered access |
|
||||
| X (Twitter) | Social | Formerly Twitter |
|
||||
| New York Times | News | Subscription access |
|
||||
| Pinterest | Social | Visual discovery |
|
||||
| Amazon | E-commerce | Prime/rewards access |
|
||||
| complexityexplorer.org | Education | Santa Fe Institute courses |
|
||||
| Reddit | Social | Forum/community |
|
||||
|
||||
** Security Notes
|
||||
|
||||
- Credentials stored in: ~/.openclaw/credentials/user-identity.json
|
||||
- Access restricted to agent context
|
||||
- Do not share credentials externally
|
||||
- Review access quarterly
|
||||
|
||||
** Account History
|
||||
|
||||
- Created: 2026-03-04 (assigned to agent identity)
|
||||
- Previous identity: Sol
|
||||
- Current identity: User
|
||||
36
notes/x-oauth-attempts.org
Normal file
36
notes/x-oauth-attempts.org
Normal file
@@ -0,0 +1,36 @@
|
||||
#+TITLE: X OAuth Login Attempts
|
||||
#+author: User
|
||||
#+created: [2026-03-16 Mon 14:28]
|
||||
#+DATE: 2026-03-04
|
||||
#+FILETAGS: :reference:oauth:automation
|
||||
|
||||
* X OAuth Login Process
|
||||
|
||||
** Attempts Made
|
||||
|
||||
*** Attempt 1: Direct OAuth flow
|
||||
- ❌ Failed: OTP expired (code 482109)
|
||||
|
||||
*** Attempt 2: Fresh OTP
|
||||
- OTP: 927519
|
||||
- ❌ Failed: Page remained on X login, didn't navigate to Google
|
||||
|
||||
** Technical Issues
|
||||
|
||||
1. *Timing:* OAuth flows are time-sensitive
|
||||
2. *Session state:* Browser cookies/session handling complex
|
||||
3. *Redirect handling:* X → Google → X redirects not working via automation
|
||||
|
||||
** Recommendation
|
||||
|
||||
Use *manual approach* for now:
|
||||
- User logs in normally
|
||||
- Share bookmark content directly
|
||||
- Export/import bookmark files
|
||||
|
||||
** Alternative Solutions**
|
||||
|
||||
1. App Password (more reliable for automation)
|
||||
2. OAuth 2.0 with refresh tokens
|
||||
3. Browser extension automation
|
||||
4. Session cookie reuse
|
||||
Reference in New Issue
Block a user