chore: unify bold syntax to single asterisk in .org files and update legacy memex-amero references

This commit is contained in:
2026-04-01 12:37:45 -04:00
parent 78ba3112cb
commit d364f90ff6
102 changed files with 955 additions and 955 deletions

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :social:decentralized:identity:commerce:psf:
* Overview
The **Agora Protocol** is a decentralized "Social Operating System" designed to replace extractive, centralized platforms with a modular architecture for sovereign digital interaction. It unifies identity, data ownership, and communication under the immutable, verifiable, and user-owned "Note" primitive.
The *Agora Protocol* is a decentralized "Social Operating System" designed to replace extractive, centralized platforms with a modular architecture for sovereign digital interaction. It unifies identity, data ownership, and communication under the immutable, verifiable, and user-owned "Note" primitive.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,11 +15,11 @@ The **Agora Protocol** is a decentralized "Social Operating System" designed to
Define the requirements for a robust, user-centric decentralized network.
** 2. User Needs
- **User Sovereignty:** Absolute control over all user-generated content and personal data via PDS.
- **Censorship Resistance:** Distributed storage and permissionless relay routing.
- **Authenticity:** Every action cryptographically signed by a Persona DID.
- **Privacy by Design:** Default end-to-end encryption and metadata leakage minimization.
- **Unified Primitive:** The "Note" as the atomic unit for all semantic types (posts, messages, contracts).
- *User Sovereignty:* Absolute control over all user-generated content and personal data via PDS.
- *Censorship Resistance:* Distributed storage and permissionless relay routing.
- *Authenticity:* Every action cryptographically signed by a Persona DID.
- *Privacy by Design:* Default end-to-end encryption and metadata leakage minimization.
- *Unified Primitive:* The "Note" as the atomic unit for all semantic types (posts, messages, contracts).
** 3. Success Criteria
*** TODO Note Primitive Cryptographic Hashing Verification

View File

@@ -7,9 +7,9 @@
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.
- *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:

View File

@@ -7,9 +7,9 @@
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.
- *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:

View File

@@ -7,9 +7,9 @@
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.
- *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:

View File

@@ -7,9 +7,9 @@
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.
- *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:

View File

@@ -7,9 +7,9 @@
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).
- *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:

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :emacs:config:literate:psf:
* Overview
The **Dotemacs** project represents the "Operating System" configuration. It transforms Emacs into the primary computing tool by leveraging modular, literate Org-mode files that tangle into a high-performance environment.
The *Dotemacs* project represents the "Operating System" configuration. It transforms Emacs into the primary computing tool by leveraging modular, literate Org-mode files that tangle into a high-performance environment.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Dotemacs** project represents the "Operating System" configuration. It tra
Define the requirements for a modular, optimized, and fully documented Emacs environment.
** 2. User Needs
- **Modularity:** Split the monolithic `emacs.org` into functional modules (core, ui, gtd, ai, etc.).
- **Literate Mandate:** Every significant setting must be justified and explained in prose.
- **Integration:** Seamless connectivity with `org-agent`, `org-roam`, and `org-gtd`.
- **Bootstrapping:** Fast startup using `early-init.el` and lazy-loading.
- *Modularity:* Split the monolithic `emacs.org` into functional modules (core, ui, gtd, ai, etc.).
- *Literate Mandate:* Every significant setting must be justified and explained in prose.
- *Integration:* Seamless connectivity with `org-agent`, `org-roam`, and `org-gtd`.
- *Bootstrapping:* Fast startup using `early-init.el` and lazy-loading.
** 3. Success Criteria
*** TODO Monolithic modularization completion

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :infrastructure:security:hardening:psf:
* Overview
The **Infrastructure** project governs the physical and virtual foundations of the Memex. It ensures high availability, security hardening, and operational transparency across cloud and local resources.
The *Infrastructure* project governs the physical and virtual foundations of the Memex. It ensures high availability, security hardening, and operational transparency across cloud and local resources.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Infrastructure** project governs the physical and virtual foundations of t
Define the requirements for a secure, resilient, and documented infrastructure posture.
** 2. User Needs
- **Security Hardening:** Implementation of the OpenClaw security audit findings.
- **Vulnerability Management:** Regular risk assessments and reporting.
- **Inventory Control:** Complete mapping of cloud and local assets.
- **Roadmap Planning:** 30/60/90 day infrastructure evolution.
- *Security Hardening:* Implementation of the OpenClaw security audit findings.
- *Vulnerability Management:* Regular risk assessments and reporting.
- *Inventory Control:* Complete mapping of cloud and local assets.
- *Roadmap Planning:* 30/60/90 day infrastructure evolution.
** 3. Success Criteria
*** TODO Harden Docker port bindings (bind to 127.0.0.1)

View File

@@ -3,45 +3,45 @@
* Architectural Learnings
** [2026-03-23] Org-Native Skill System (Lisp Machine Mandate)
- **Problem:** Extending the agent required writing Common Lisp in the core daemon, breaking the "Homoiconic Memory" philosophy where Org-mode is the native memory format. Standard agent architectures use disconnected Markdown/YAML/Python folders.
- **Solution:** The **Org-Native Skill Standard**. Skills are written entirely as `.org` files. The daemon parses the Org file at startup, extracts `#+begin_src lisp` blocks containing triggers, neuro-prompts, and symbolic verification rules, and dynamically compiles them into the live system using `eval` and `read`.
- **Heuristic:** The Core is strictly the PTA loop (`core.lisp`, `neuro.lisp`, `symbolic.lisp`). ALL business logic, API connectors, and rule sets MUST live as `.org` files in the `skills/` directory.
- *Problem:* Extending the agent required writing Common Lisp in the core daemon, breaking the "Homoiconic Memory" philosophy where Org-mode is the native memory format. Standard agent architectures use disconnected Markdown/YAML/Python folders.
- *Solution:* The *Org-Native Skill Standard*. Skills are written entirely as `.org` files. The daemon parses the Org file at startup, extracts `#+begin_src lisp` blocks containing triggers, neuro-prompts, and symbolic verification rules, and dynamically compiles them into the live system using `eval` and `read`.
- *Heuristic:* The Core is strictly the PTA loop (`core.lisp`, `neuro.lisp`, `symbolic.lisp`). ALL business logic, API connectors, and rule sets MUST live as `.org` files in the `skills/` directory.
** [2026-03-23] Cognitive Loop Architecture (org-agent)
- **Problem:** Monolithic PTA (Perceive-Think-Act) loops lead to "Neural Drift" where the LLM's unverified suggestions can cause illegal system states or security breaches.
- **Solution:** Implement the **Four-Stage Cognitive Loop**: Perceive -> Think -> Decide -> Act.
- **Heuristic:** System 1 (Neural/LLM) is a proposal engine only. System 2 (Symbolic/Lisp) is the absolute gatekeeper.
- **Verification:** Never execute an action unless it has passed through `decide()` and been verified against the symbolic Object Store (CLOSOS).
- *Problem:* Monolithic PTA (Perceive-Think-Act) loops lead to "Neural Drift" where the LLM's unverified suggestions can cause illegal system states or security breaches.
- *Solution:* Implement the *Four-Stage Cognitive Loop*: Perceive -> Think -> Decide -> Act.
- *Heuristic:* System 1 (Neural/LLM) is a proposal engine only. System 2 (Symbolic/Lisp) is the absolute gatekeeper.
- *Verification:* Never execute an action unless it has passed through `decide()` and been verified against the symbolic Object Store (CLOSOS).
** [2026-03-23] Externalized Configuration Mandate
- **Problem:** Hardcoded API keys and endpoints in Lisp source prevent portability and create security risks.
- **Solution:** Use `cl-dotenv` to load `.env` from the system source directory during `eval-when`.
- **Heuristic:** Use `(uiop:getenv)` with a `(get-env)` fallback helper for all externalized parameters.
- *Problem:* Hardcoded API keys and endpoints in Lisp source prevent portability and create security risks.
- *Solution:* Use `cl-dotenv` to load `.env` from the system source directory during `eval-when`.
- *Heuristic:* Use `(uiop:getenv)` with a `(get-env)` fallback helper for all externalized parameters.
** [2026-03-23] Hardware Compartment Mandate
- **Problem:** Forcing a single deployment method (e.g. Docker) creates infrastructure lock-in and limits adoption for users with specific security/performance needs.
- **Solution:** Treat the runtime as a "Hardware Compartment." Abstract deployment into a `deploy/` directory with support for Bare Metal, Docker, LXC, and VMs.
- **Heuristic:** The Kernel speaks OACP (TCP); it does not care about the enclosure.
- *Problem:* Forcing a single deployment method (e.g. Docker) creates infrastructure lock-in and limits adoption for users with specific security/performance needs.
- *Solution:* Treat the runtime as a "Hardware Compartment." Abstract deployment into a `deploy/` directory with support for Bare Metal, Docker, LXC, and VMs.
- *Heuristic:* The Kernel speaks OACP (TCP); it does not care about the enclosure.
** [2026-03-23] LLM Failover Cascade
- **Problem:** AI providers are unreliable (rate limits, outages). A single provider failure blinds the entire agent.
- **Solution:** Implement a `*provider-cascade*` list. The kernel automatically tries backends in order until success or exhaustion.
- **Heuristic:** Reliability is a Core Kernel responsibility; Model choice is a Skill responsibility.
- *Problem:* AI providers are unreliable (rate limits, outages). A single provider failure blinds the entire agent.
- *Solution:* Implement a `*provider-cascade*` list. The kernel automatically tries backends in order until success or exhaustion.
- *Heuristic:* Reliability is a Core Kernel responsibility; Model choice is a Skill responsibility.
** [2026-03-23] Homoiconic Memory (The Org Mandate)
- **Problem:** Mixed-format workspaces (.md and .org) create cognitive friction and prevent unified AST reasoning.
- **Solution:** Enforce a "Strictly Org-mode" mandate for all internal logic, plans, and memory.
- **Heuristic:** Use Lisp for logic, Org for everything else.
- *Problem:* Mixed-format workspaces (.md and .org) create cognitive friction and prevent unified AST reasoning.
- *Solution:* Enforce a "Strictly Org-mode" mandate for all internal logic, plans, and memory.
- *Heuristic:* Use Lisp for logic, Org for everything else.
* Root Cause Analyses (RCA)
** [2026-03-23] Lisp Reader Syntax Error (Colons)
- **Symptom:** Kernel crashed with `SIMPLE-READER-ERROR` on skill files containing `: ` or unescaped quotes in prompt strings.
- **Root Cause:** The Lisp reader interprets colons as package markers. If they are used in text strings without escaping or sanitization, the reader fails.
- **Prevention:** Sanitize Org-Native skills to replace `: ` with ` - ` in prompts, and wrap `read-from-string` in `handler-case`.
- *Symptom:* Kernel crashed with `SIMPLE-READER-ERROR` on skill files containing `: ` or unescaped quotes in prompt strings.
- *Root Cause:* The Lisp reader interprets colons as package markers. If they are used in text strings without escaping or sanitization, the reader fails.
- *Prevention:* Sanitize Org-Native skills to replace `: ` with ` - ` in prompts, and wrap `read-from-string` in `handler-case`.
** [2026-03-30 Mon] PSF Mandate Violation: Non-Literate Implementation
- **Symptom:** `psf-core` logic and tests were written as raw `.lisp` files instead of `.org` literate files.
- **Root Cause:** Deep-seated "Legacy Coding" habits; prioritized speed of execution over the "Sovereign Literature" mandate.
- **Prevention:** The agent MUST refuse to create `.lisp` or `.py` files directly for system logic. All implementation must begin as an Org headline with a narrative.
- *Symptom:* `psf-core` logic and tests were written as raw `.lisp` files instead of `.org` literate files.
- *Root Cause:* Deep-seated "Legacy Coding" habits; prioritized speed of execution over the "Sovereign Literature" mandate.
- *Prevention:* The agent MUST refuse to create `.lisp` or `.py` files directly for system logic. All implementation must begin as an Org headline with a narrative.

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :hardware:lisp:sovereignty:fpga:psf:
* Overview
The **Lisp Machine Bootstrap** project is the "Endgame" of the PSF. It aims to eliminate the "Unix/C Tax" by building a hardware-native Lisp machine where CAR, CDR, and CONS are primitive gates. This ensures ultimate digital sovereignty and a provably secure, homoiconic environment.
The *Lisp Machine Bootstrap* project is the "Endgame" of the PSF. It aims to eliminate the "Unix/C Tax" by building a hardware-native Lisp machine where CAR, CDR, and CONS are primitive gates. This ensures ultimate digital sovereignty and a provably secure, homoiconic environment.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Lisp Machine Bootstrap** project is the "Endgame" of the PSF. It aims to e
Define the requirements for a hardware environment optimized for Lisp and user sovereignty.
** 2. User Needs
- **Hardware-Native Lisp:** ISA designed for list processing efficiency.
- **Tagged Memory:** Hardware-level safety preventing memory corruption.
- **Bootstrapping Path:** Progression from Soft Machine (Linux) to Sovereign Silicon (ASIC).
- **Transparency:** Every gate and instruction must be introspectable and documented.
- *Hardware-Native Lisp:* ISA designed for list processing efficiency.
- *Tagged Memory:* Hardware-level safety preventing memory corruption.
- *Bootstrapping Path:* Progression from Soft Machine (Linux) to Sovereign Silicon (ASIC).
- *Transparency:* Every gate and instruction must be introspectable and documented.
** 3. Success Criteria
*** TODO Research existing Lisp-on-FPGA implementations (Openora, etc.)

View File

@@ -32,9 +32,9 @@ A critical part of the migration was standardizing all internal paths to the `me
- `inbox.org` and `gtd.org` are now in the root of `~/memex/`.
* Operational Mandates
- **Literate Programming:** All configuration MUST be written in `.org` files.
- **Kebab-Case:** All file naming follows the kebab-case (hyphens) standard.
- **Tangle Local:** Every module tangles to its own `.el` file in the same directory (`:tangle yes`) to ensure loading efficiency.
- *Literate Programming:* All configuration MUST be written in `.org` files.
- *Kebab-Case:* All file naming follows the kebab-case (hyphens) standard.
- *Tangle Local:* Every module tangles to its own `.el` file in the same directory (`:tangle yes`) to ensure loading efficiency.
* See Also
- [[file:org-gtd-v4-migration.org][org-gtd v4.0 Migration]]

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :hardware:iot:esp32:sustainability:psf:
* Overview
The **Modular Home Appliances** project focuses on developing open-source, sustainable designs for major home appliances (washers, fridges, etc.). It utilizes a modular physical architecture coupled with ESP32-based smart interfaces for AI-driven control and seamless Home Assistant integration.
The *Modular Home Appliances* project focuses on developing open-source, sustainable designs for major home appliances (washers, fridges, etc.). It utilizes a modular physical architecture coupled with ESP32-based smart interfaces for AI-driven control and seamless Home Assistant integration.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Modular Home Appliances** project focuses on developing open-source, susta
Define the requirements for modular, open-source, and intelligent home hardware.
** 2. User Needs
- **Physical Modularity:** Easy replacement and upgrade of mechanical and electrical components.
- **Smart Interfacing:** ESP32-based control boards for connectivity.
- **Multimodal Control:** Support for smartphone apps, physical modular controllers, and direct `org-agent` AI interaction.
- **Sustainability:** Design for longevity, repairability, and efficient power management (inspired by Slate principles).
- *Physical Modularity:* Easy replacement and upgrade of mechanical and electrical components.
- *Smart Interfacing:* ESP32-based control boards for connectivity.
- *Multimodal Control:* Support for smartphone apps, physical modular controllers, and direct `org-agent` AI interaction.
- *Sustainability:* Design for longevity, repairability, and efficient power management (inspired by Slate principles).
** 3. Success Criteria
*** TODO Washer/Dryer modular chassis design (draft)

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :off-grid:guide:manual:portability:psf:
* Overview
The **Off-Grid Field Guide** project aims to develop a modular manual for off-grid living and activities. It is designed for physical portability, specifically fitting the traveler's notebook format, and provides interchangeable modules for navigation, first aid, and survival.
The *Off-Grid Field Guide* project aims to develop a modular manual for off-grid living and activities. It is designed for physical portability, specifically fitting the traveler's notebook format, and provides interchangeable modules for navigation, first aid, and survival.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Off-Grid Field Guide** project aims to develop a modular manual for off-gr
Define the requirements for a modular, practical, and highly portable manual for off-grid scenarios.
** 2. User Needs
- **Modularity:** Interchangeable content blocks based on activity (e.g., Water Sourcing, Radio Comms).
- **Portability:** Optimization for the "Traveler's Notebook" physical form factor.
- **Practicality:** High-signal, low-noise instructions suitable for emergency use.
- **Durability:** Design considerations for physical print and use in harsh environments.
- *Modularity:* Interchangeable content blocks based on activity (e.g., Water Sourcing, Radio Comms).
- *Portability:* Optimization for the "Traveler's Notebook" physical form factor.
- *Practicality:* High-signal, low-noise instructions suitable for emergency use.
- *Durability:* Design considerations for physical print and use in harsh environments.
** 3. Success Criteria
*** TODO Taxonomy definition for initial modules (Nav, First Aid, Comms)

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :gear:standard:modularity:carrying:psf:
* Overview
The **Open Personal Equipment System (OPES)** aims to define and develop an open standard for personal carrying, organization, and storage solutions. It focuses on creating an interoperable ecosystem of gear that prioritizes durability, repairability, and modularity.
The *Open Personal Equipment System (OPES)* aims to define and develop an open standard for personal carrying, organization, and storage solutions. It focuses on creating an interoperable ecosystem of gear that prioritizes durability, repairability, and modularity.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Open Personal Equipment System (OPES)** aims to define and develop an open
Define the requirements for an open, modular standard for personal equipment.
** 2. User Needs
- **Interoperability:** Modular attachments that work across different packs and cases.
- **Sovereignty:** Open-source patterns and material specifications allowing for user repair or manufacturing.
- **Durability:** High-performance materials designed for long-term use.
- **Standardization:** Clear definitions for grid systems (e.g., MOLLE-compatible but evolved).
- *Interoperability:* Modular attachments that work across different packs and cases.
- *Sovereignty:* Open-source patterns and material specifications allowing for user repair or manufacturing.
- *Durability:* High-performance materials designed for long-term use.
- *Standardization:* Clear definitions for grid systems (e.g., MOLLE-compatible but evolved).
** 3. Success Criteria
*** TODO Core OPES Attachment Standard definition

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :platform:kernel:lisp:psf:
* Overview
The **Org-Agent** is the neurosymbolic kernel of the personal operating system. It acts as the "executive soul," using Org-mode as its native memory and Common Lisp as its deterministic reasoning engine. It follows a minimalist microkernel design, extending its capabilities via hot-reloadable skills.
The *Org-Agent* is the neurosymbolic kernel of the personal operating system. It acts as the "executive soul," using Org-mode as its native memory and Common Lisp as its deterministic reasoning engine. It follows a minimalist microkernel design, extending its capabilities via hot-reloadable skills.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,11 +15,11 @@ The **Org-Agent** is the neurosymbolic kernel of the personal operating system.
Define the core functional and security requirements for the neurosymbolic daemon.
** 2. User Needs
- **Homoiconic Memory:** Use Org-mode AST as the primary data structure for both human and machine.
- **Deterministic Reasoning:** Common Lisp (SBCL) for high-performance, threaded symbolic logic.
- **Cognitive Loop:** A strict four-stage pipeline: Perceive -> Think (System 1) -> Decide (System 2) -> Act.
- **Minimalist Core:** The kernel handles only the loop, object-store, and communication; all else is a skill.
- **Security by Default:** Reader safety (*read-eval* disabled) and package-based skill jailing.
- *Homoiconic Memory:* Use Org-mode AST as the primary data structure for both human and machine.
- *Deterministic Reasoning:* Common Lisp (SBCL) for high-performance, threaded symbolic logic.
- *Cognitive Loop:* A strict four-stage pipeline: Perceive -> Think (System 1) -> Decide (System 2) -> Act.
- *Minimalist Core:* The kernel handles only the loop, object-store, and communication; all else is a skill.
- *Security by Default:* Reader safety (*read-eval* disabled) and package-based skill jailing.
** 3. Success Criteria
*** TODO Core Lisp microkernel stability (Heartbeat consistency)

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :architect:blueprint:design:psf:
* Overview
The **Architect Agent** transforms a FROZEN PRD (Demand) into a rigorous PROTOCOL (Blueprint). It bridges the gap between human requirements and machine code, ensuring structural integrity before implementation.
The *Architect Agent* transforms a FROZEN PRD (Demand) into a rigorous PROTOCOL (Blueprint). It bridges the gap between human requirements and machine code, ensuring structural integrity before implementation.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Architect Agent** transforms a FROZEN PRD (Demand) into a rigorous PROTOCO
Define automated architectural behaviors for the PSF Consensus Loop.
** 2. User Needs
- **PRD Perception:** Monitor for `FROZEN` PRDs.
- **Semantic Translation:** Translate ambiguous needs into Lisp-style interfaces.
- **Memory Integration:** Reference `institutional-memory.org` for design choices.
- **Physical Actuation:** Write the `PROTOCOL.org` to the project directory.
- *PRD Perception:* Monitor for `FROZEN` PRDs.
- *Semantic Translation:* Translate ambiguous needs into Lisp-style interfaces.
- *Memory Integration:* Reference `institutional-memory.org` for design choices.
- *Physical Actuation:* Write the `PROTOCOL.org` to the project directory.
** 3. Success Criteria
*** TODO Trigger Accuracy

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :ast:normalization:integrity:psf:
* Overview
The **AST Normalization Agent** maintains the structural integrity of the Org-mode Abstract Syntax Tree. It ensures all nodes adhere to strict metadata requirements and handles deterministic refactoring.
The *AST Normalization Agent* maintains the structural integrity of the Org-mode Abstract Syntax Tree. It ensures all nodes adhere to strict metadata requirements and handles deterministic refactoring.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ The **AST Normalization Agent** maintains the structural integrity of the Org-mo
Define automated structural enforcement and refactoring for the Org AST.
** 2. User Needs
- **Structural Enforcement:** Mandatory unique IDs for all headlines.
- **Deterministic Preemption:** Symbolic verification must override neural suggestions if errors exist.
- **Fidelity:** Preservation of content during metadata normalization.
- *Structural Enforcement:* Mandatory unique IDs for all headlines.
- *Deterministic Preemption:* Symbolic verification must override neural suggestions if errors exist.
- *Fidelity:* Preservation of content during metadata normalization.
** 3. Success Criteria
*** TODO ID Injection

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :knowledge:retrieval:zettelkasten:psf:
* Overview
This skill provides the **Deep Memory** for the agent. it enables **Sparse Tree Perception** over the Zettelkasten, using semantic search and recursive interlinking to maintain high-signal context without token bloat.
This skill provides the *Deep Memory* for the agent. it enables *Sparse Tree Perception* over the Zettelkasten, using semantic search and recursive interlinking to maintain high-signal context without token bloat.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ This skill provides the **Deep Memory** for the agent. it enables **Sparse Tree
Define the interfaces for knowledge retrieval from the atomic note DAG.
** 2. User Needs
- **Atomicity:** Each note represents exactly one concept.
- **Sparse Tree Perception:** Extract headlines and IDs before deep reading.
- **Recursive Deep-Dive:** Follow internal links to pull related context.
- **Search Efficiency:** Optimized searching via `ripgrep`.
- *Atomicity:* Each note represents exactly one concept.
- *Sparse Tree Perception:* Extract headlines and IDs before deep reading.
- *Recursive Deep-Dive:* Follow internal links to pull related context.
- *Search Efficiency:* Optimized searching via `ripgrep`.
** 3. Success Criteria
*** TODO Concept Discovery

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :auth:security:system:psf:
* Overview
This skill provides the legacy-compatible **Static API Key** authentication method. It retrieves credentials from the system environment variables and provides them to the kernel's neural backends.
This skill provides the legacy-compatible *Static API Key* authentication method. It retrieves credentials from the system environment variables and provides them to the kernel's neural backends.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ This skill provides the legacy-compatible **Static API Key** authentication meth
Provide a simple, environment-driven authentication mechanism for LLM providers.
** 2. User Needs
- **Static Retrieval:** Pull `LLM_API_KEY` from `.env`.
- **Provider Mapping:** Support mapping keys to specific providers (Gemini, OpenAI, etc.).
- **Reliability:** Return NIL gracefully if no key is found.
- *Static Retrieval:* Pull `LLM_API_KEY` from `.env`.
- *Provider Mapping:* Support mapping keys to specific providers (Gemini, OpenAI, etc.).
- *Reliability:* Return NIL gracefully if no key is found.
* Phase B: Blueprint (PROTOCOL)
:PROPERTIES:

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :auth:oauth:google:security:psf:
* Overview
This skill implements the **Headless OAuth 2.0** handshake for Google services. It enables the agent to acquire and rotate `access_tokens` for Gemini without requiring a local browser session, using a "Copy-Paste" authorization code flow.
This skill implements the *Headless OAuth 2.0* handshake for Google services. It enables the agent to acquire and rotate `access_tokens` for Gemini without requiring a local browser session, using a "Copy-Paste" authorization code flow.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ This skill implements the **Headless OAuth 2.0** handshake for Google services.
Provide a secure, professional OAuth 2.0 interface for Google Gemini.
** 2. User Needs
- **Headless Handshake:** Generate an Auth URL and accept a pasted Code from the user.
- **Token Persistence:** Securely store `refresh_token` in a Lisp state file.
- **Auto-Rotation:** Automatically exchange the `refresh_token` for a new `access_token` when expired.
- **Environment Driven:** Pull `CLIENT_ID` and `CLIENT_SECRET` from system settings.
- *Headless Handshake:* Generate an Auth URL and accept a pasted Code from the user.
- *Token Persistence:* Securely store `refresh_token` in a Lisp state file.
- *Auto-Rotation:* Automatically exchange the `refresh_token` for a new `access_token` when expired.
- *Environment Driven:* Pull `CLIENT_ID` and `CLIENT_SECRET` from system settings.
** 3. Success Criteria
*** TODO Generate valid Google OAuth Authorization URL

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :meta-cognition:telemetry:psf:
* Overview
The **Brain Mapper Agent** provides the system with meta-cognitive capabilities. It enables visualization and optimization of the internal "Skill Graph" through real-time telemetry analysis.
The *Brain Mapper Agent* provides the system with meta-cognitive capabilities. It enables visualization and optimization of the internal "Skill Graph" through real-time telemetry analysis.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ The **Brain Mapper Agent** provides the system with meta-cognitive capabilities.
Define the interfaces for self-introspection and skill hierarchy optimization.
** 2. User Needs
- **Transparency:** Explain cognitive hierarchy and decision priorities.
- **Self-Optimization:** Proactive priority adjustment suggestions.
- **Introspection:** Identify bottleneck or failing skills.
- *Transparency:* Explain cognitive hierarchy and decision priorities.
- *Self-Optimization:* Proactive priority adjustment suggestions.
- *Introspection:* Identify bottleneck or failing skills.
** 3. Success Criteria
*** TODO Introspective Trigger Verification

View File

@@ -5,7 +5,7 @@
#+DEPENDS_ON: skill-shell-actuator skill-tdd-runner
* Overview
The **Chaos Gauntlet** is an adversarial testing skill designed to ensure the system's resilience. It simulates environmental failures, malformed LLM responses, and network disruptions, forcing the kernel and its skills to handle "Byzantine" conditions gracefully.
The *Chaos Gauntlet* is an adversarial testing skill designed to ensure the system's resilience. It simulates environmental failures, malformed LLM responses, and network disruptions, forcing the kernel and its skills to handle "Byzantine" conditions gracefully.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -16,10 +16,10 @@ The **Chaos Gauntlet** is an adversarial testing skill designed to ensure the sy
Verify the system's stability and error-handling capabilities under stress.
** 2. User Needs
- **Failure Simulation:** Ability to inject artificial delays or errors into the OACP bus.
- **Byzantine Response Testing:** Test how System 2 handles nonsensical or malicious System 1 proposals.
- **Network Resilience:** Simulate Gitea or LLM provider timeouts.
- **Recovery Verification:** Ensure the kernel can recover from a "skip-event" restart.
- *Failure Simulation:* Ability to inject artificial delays or errors into the OACP bus.
- *Byzantine Response Testing:* Test how System 2 handles nonsensical or malicious System 1 proposals.
- *Network Resilience:* Simulate Gitea or LLM provider timeouts.
- *Recovery Verification:* Ensure the kernel can recover from a "skip-event" restart.
* Phase D: Build (Implementation)

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :chat:conversational:ui:psf:
* Overview
The **Chat Agent** provides a dedicated conversational interface within Emacs (`*org-agent-chat*`). It enables fluid dialogue while maintaining strict persona alignment and contextual awareness.
The *Chat Agent* provides a dedicated conversational interface within Emacs (`*org-agent-chat*`). It enables fluid dialogue while maintaining strict persona alignment and contextual awareness.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Chat Agent** provides a dedicated conversational interface within Emacs (`
Define the interfaces for direct human-to-agent conversational interaction.
** 2. User Needs
- **Direct Interaction:** Specialized handler for `:chat-message` events.
- **Persona Alignment:** Consistency with the Identity Agent's definitions.
- **Contextual Awareness:** Reference to chat history for dialogue continuity.
- **Structural Output:** Responses formatted as valid Org-mode subtrees.
- *Direct Interaction:* Specialized handler for `:chat-message` events.
- *Persona Alignment:* Consistency with the Identity Agent's definitions.
- *Contextual Awareness:* Reference to chat history for dialogue continuity.
- *Structural Output:* Responses formatted as valid Org-mode subtrees.
** 3. Success Criteria
*** TODO Chat Event Triggering

View File

@@ -5,7 +5,7 @@
#+DEPENDS_ON: skill-sub-agent-manager
* Overview
The **Social Consensus Protocol** enables multi-agent negotiation. It provides a Lisp-native implementation of decentralized agreement, allowing federated `org-agent` instances to coordinate on shared resources and conflicting goals.
The *Social Consensus Protocol* enables multi-agent negotiation. It provides a Lisp-native implementation of decentralized agreement, allowing federated `org-agent` instances to coordinate on shared resources and conflicting goals.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -16,9 +16,9 @@ The **Social Consensus Protocol** enables multi-agent negotiation. It provides a
Enable reliable, cross-instance coordination without a central master.
** 2. User Needs
- **Resource Negotiation:** Agree on which instance should handle a high-compute task.
- **Conflict Resolution:** Settle divergent world-states during swarm execution.
- **Byzantine Fault Tolerance:** Handle disconnected or misbehaving instances gracefully.
- *Resource Negotiation:* Agree on which instance should handle a high-compute task.
- *Conflict Resolution:* Settle divergent world-states during swarm execution.
- *Byzantine Fault Tolerance:* Handle disconnected or misbehaving instances gracefully.
* Phase D: Build (Implementation)

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :creator:reproductive:meta-cognitive:psf:
* Overview
The **Skill Creator Agent** is the "Reproductive System" of the Lisp Machine. It enables autonomous generation of new Org-Native skills, facilitating a "Self-Editing OS" philosophy through neural drafting and symbolic validation.
The *Skill Creator Agent* is the "Reproductive System" of the Lisp Machine. It enables autonomous generation of new Org-Native skills, facilitating a "Self-Editing OS" philosophy through neural drafting and symbolic validation.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ The **Skill Creator Agent** is the "Reproductive System" of the Lisp Machine. It
Define the interfaces for autonomous skill generation and syntax validation.
** 2. User Needs
- **Autonomy:** Draft complete skill files from natural language requirements.
- **Safety First:** Mandatory symbolic syntax validation of generated code.
- **Hierarchical Negotiation:** Automatic priority assignment based on existing brain structure.
- *Autonomy:* Draft complete skill files from natural language requirements.
- *Safety First:* Mandatory symbolic syntax validation of generated code.
- *Hierarchical Negotiation:* Automatic priority assignment based on existing brain structure.
** 3. Success Criteria
*** TODO Skill Draft Generation

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :cron:temporal:heartbeat:psf:
* Overview
The **Cron Agent** serves as the system's temporal conscience. It provides autonomous, time-aware capabilities by hooking into the background heartbeat, enabling proactive executive assistance.
The *Cron Agent* serves as the system's temporal conscience. It provides autonomous, time-aware capabilities by hooking into the background heartbeat, enabling proactive executive assistance.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ The **Cron Agent** serves as the system's temporal conscience. It provides auton
Define automated behaviors for deadline monitoring and temporal alerting.
** 2. User Needs
- **Punctuality:** Monitor deadlines and alerts across the Memex.
- **Efficiency:** Symbolic filtering (System 2) to minimize LLM calls.
- **Multi-Channel Awareness:** Routing alerts to Emacs or external delivery.
- *Punctuality:* Monitor deadlines and alerts across the Memex.
- *Efficiency:* Symbolic filtering (System 2) to minimize LLM calls.
- *Multi-Channel Awareness:* Routing alerts to Emacs or external delivery.
** 3. Success Criteria
*** TODO Heartbeat Trigger Verification

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :visual:diagram:mermaid:psf:
* Overview
The **Multi-Modal Diagrammer** enables the agent to communicate complex architectural plans visually using Mermaid.js and D2 synthesis.
The *Multi-Modal Diagrammer* enables the agent to communicate complex architectural plans visually using Mermaid.js and D2 synthesis.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ The **Multi-Modal Diagrammer** enables the agent to communicate complex architec
Enable visual communication of plans and system states.
** 2. User Needs
- **Mermaid Synthesis:** Generate valid Mermaid.js graph code.
- **D2 Support:** Support D2 for complex layout requirements.
- **Org-Integration:** Embed results in `#+begin_src mermaid` blocks.
- *Mermaid Synthesis:* Generate valid Mermaid.js graph code.
- *D2 Support:* Support D2 for complex layout requirements.
- *Org-Integration:* Embed results in `#+begin_src mermaid` blocks.
* Phase D: Build (Implementation)

View File

@@ -5,7 +5,7 @@
#+DEPENDS_ON: skill-router skill-performance-auditor
* Overview
The **Economist Agent** manages the PSF's compute resources. It predicts the "Cost of Thought" for a task and autonomously selects the most cost-effective LLM provider or local model based on complexity and remaining budget.
The *Economist Agent* manages the PSF's compute resources. It predicts the "Cost of Thought" for a task and autonomously selects the most cost-effective LLM provider or local model based on complexity and remaining budget.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -16,9 +16,9 @@ The **Economist Agent** manages the PSF's compute resources. It predicts the "Co
Optimize token usage and compute overhead without sacrificing architectural integrity.
** 2. User Needs
- **Predictive Budgeting:** Estimate token cost before triggering SOTA models.
- **Provider Switching:** Dynamically route tasks between local (Ollama) and cloud (Gemini) models.
- **Audit Reports:** Provide transparency on compute consumption.
- *Predictive Budgeting:* Estimate token cost before triggering SOTA models.
- *Provider Switching:* Dynamically route tasks between local (Ollama) and cloud (Gemini) models.
- *Audit Reports:* Provide transparency on compute consumption.
* Phase D: Build (Implementation)

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :bridge:emacs:io:system:psf:
* Overview
The **Emacs Bridge Agent** is the primary sensory and motor interface to Emacs. It abstracts TCP socket management, allowing the core kernel to interact with buffers as native data structures.
The *Emacs Bridge Agent* is the primary sensory and motor interface to Emacs. It abstracts TCP socket management, allowing the core kernel to interact with buffers as native data structures.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ The **Emacs Bridge Agent** is the primary sensory and motor interface to Emacs.
Define the transport layer for Org-Agent Communication Protocol (OACP).
** 2. User Needs
- **Isolation:** Kernel remains transport-agnostic.
- **Persistence:** Multi-client server support for simultaneous sessions.
- **Dispatch:** Reliable routing of actions to actuators and sensors to the kernel.
- *Isolation:* Kernel remains transport-agnostic.
- *Persistence:* Multi-client server support for simultaneous sessions.
- *Dispatch:* Reliable routing of actions to actuators and sensors to the kernel.
** 3. Success Criteria
*** TODO Socket Listener Initialization

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :security:logic:formal-methods:psf:
* Overview
The **Formal Verification Gate** replaces heuristic whitelisting with symbolic logic proofs. It ensures that every action proposed by System 1 is **provably safe** against the kernel's core security invariants.
The *Formal Verification Gate* replaces heuristic whitelisting with symbolic logic proofs. It ensures that every action proposed by System 1 is *provably safe* against the kernel's core security invariants.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ The **Formal Verification Gate** replaces heuristic whitelisting with symbolic l
Define a logic-based verification layer for high-integrity decision making.
** 2. User Needs
- **Invariants:** Define core security properties (e.g., "No unauthenticated network I/O").
- **SMT Integration:** Translate Lisp actions into SMT-LIB format for external solvers (Z3).
- **Proof of Safety:** Deny any action that cannot be proven safe.
- *Invariants:* Define core security properties (e.g., "No unauthenticated network I/O").
- *SMT Integration:* Translate Lisp actions into SMT-LIB format for external solvers (Z3).
- *Proof of Safety:* Deny any action that cannot be proven safe.
* Phase D: Build (Implementation)

View File

@@ -5,7 +5,7 @@
#+DEPENDS_ON: org-skill-org-json-bridge
* Overview
The **Native Function Calling** skill provides the translation layer between the system's deterministic Lisp interfaces and the LLM's neural tool-calling capabilities. It ensures that System 1 (the LLM) interacts with the world via structured, validated schemas rather than raw text plists, virtually eliminating "formatting hallucinations."
The *Native Function Calling* skill provides the translation layer between the system's deterministic Lisp interfaces and the LLM's neural tool-calling capabilities. It ensures that System 1 (the LLM) interacts with the world via structured, validated schemas rather than raw text plists, virtually eliminating "formatting hallucinations."
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -16,10 +16,10 @@ The **Native Function Calling** skill provides the translation layer between the
Define a high-reliability bridge for LLM-native "Tool Use."
** 2. User Needs
- **Schema Generation:** Automatically convert Lisp `defun` signatures into JSON Schema tool definitions.
- **Reliable Ingress:** Parse the LLM's structured `tool_calls` response back into a valid Lisp plist.
- **Provider Agnostic:** Support schema formats for Gemini, OpenAI, and Anthropic.
- **Validation:** Ensure arguments match the required types before reaching System 2.
- *Schema Generation:* Automatically convert Lisp `defun` signatures into JSON Schema tool definitions.
- *Reliable Ingress:* Parse the LLM's structured `tool_calls` response back into a valid Lisp plist.
- *Provider Agnostic:* Support schema formats for Gemini, OpenAI, and Anthropic.
- *Validation:* Ensure arguments match the required types before reaching System 2.
** 3. Success Criteria
*** TODO Lisp-to-JSON Schema conversion logic verification

View File

@@ -5,7 +5,7 @@
#+DEPENDS_ON: skill-atomic-notes skill-tdd-runner
* Overview
The **Groomer Agent** is the system's "Immune System" for code and notes. It autonomously audits the PSF ecosystem for technical debt, duplication, and architectural drift, proposing surgical refactors to maintain the "Minimalist Core" mandate.
The *Groomer Agent* is the system's "Immune System" for code and notes. It autonomously audits the PSF ecosystem for technical debt, duplication, and architectural drift, proposing surgical refactors to maintain the "Minimalist Core" mandate.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -16,10 +16,10 @@ The **Groomer Agent** is the system's "Immune System" for code and notes. It aut
Enforce zero-bloat and high-maintainability standards across the PSF.
** 2. User Needs
- **Debt Detection:** Identify duplicate Lisp logic or redundant Org headlines.
- **Autonomous Refactoring:** Propose surgical code changes to simplify implementation.
- **Verification:** Ensure refactors do not break functionality (via TDD Runner).
- **Note Grooming:** Consolidate fragmented atomic notes into coherent structures.
- *Debt Detection:* Identify duplicate Lisp logic or redundant Org headlines.
- *Autonomous Refactoring:* Propose surgical code changes to simplify implementation.
- *Verification:* Ensure refactors do not break functionality (via TDD Runner).
- *Note Grooming:* Consolidate fragmented atomic notes into coherent structures.
* Phase B: Blueprint (PROTOCOL)
:PROPERTIES:

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :gtd:execution:workflow:psf:
* Overview
This skill defines the **GTD Execution Hub**, the single source of truth for all commitments. It governs how the agent perceives priorities and tracks progress through the PSF Consensus Loop using the `org-gtd` v4.0 DAG architecture.
This skill defines the *GTD Execution Hub*, the single source of truth for all commitments. It governs how the agent perceives priorities and tracks progress through the PSF Consensus Loop using the `org-gtd` v4.0 DAG architecture.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ This skill defines the **GTD Execution Hub**, the single source of truth for all
Define the interfaces for task perception, project tracking, and commitment management.
** 2. User Needs
- **Allen-Sovereign Methodology:** Frictionless capture and rigorous clarification.
- **DAG Structure:** Support for `org-gtd` v4.0 dependency graphs (:TRIGGER:, :BLOCKER:).
- **Shadow Orchestration:** Tracking of `:PSF-STATE:` properties for engineering projects.
- **Institutional Memory Integration:** Extraction of learnings before project completion.
- *Allen-Sovereign Methodology:* Frictionless capture and rigorous clarification.
- *DAG Structure:* Support for `org-gtd` v4.0 dependency graphs (:TRIGGER:, :BLOCKER:).
- *Shadow Orchestration:* Tracking of `:PSF-STATE:` properties for engineering projects.
- *Institutional Memory Integration:* Extraction of learnings before project completion.
** 3. Success Criteria
*** TODO Commitment Scanning

View File

@@ -5,7 +5,7 @@
#+DEPENDS_ON: skill-shell-actuator skill-environment-config
* Overview
The **Hardware Inhabitation Agent** is the system's "Physical Interface." It manages the deployment of the Lisp Machine across different hardware compartments, ensuring absolute sovereignty via bare-metal inhabitation and environment portability.
The *Hardware Inhabitation Agent* is the system's "Physical Interface." It manages the deployment of the Lisp Machine across different hardware compartments, ensuring absolute sovereignty via bare-metal inhabitation and environment portability.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -16,10 +16,10 @@ The **Hardware Inhabitation Agent** is the system's "Physical Interface." It man
Define the interfaces for hardware-level deployment and image serialization.
** 2. User Needs
- **Bare-Metal Deployment:** Support for running Lisp directly on minimal hardware (e.g., RISC-V/ARM).
- **Image Portability:** Serialize and move the live Lisp Image across environments.
- **Hardware Inventory:** Maintain a manifest of available physical actuators and sensors.
- **Sovereignty Audit:** Verify that the current inhabitation is free from non-sovereign dependencies.
- *Bare-Metal Deployment:* Support for running Lisp directly on minimal hardware (e.g., RISC-V/ARM).
- *Image Portability:* Serialize and move the live Lisp Image across environments.
- *Hardware Inventory:* Maintain a manifest of available physical actuators and sensors.
- *Sovereignty Audit:* Verify that the current inhabitation is free from non-sovereign dependencies.
* Phase B: Blueprint (PROTOCOL)
:PROPERTIES:

View File

@@ -5,7 +5,7 @@
#+DEPENDS_ON: skill-atomic-notes skill-brain-mapper
* Overview
The **Unified Knowledge Hyper-Graph** extends the agent's memory beyond text. It maps relationships between **Code Blocks, Documents, Media Assets, and Research PDFs**, enabling cross-modal context retrieval.
The *Unified Knowledge Hyper-Graph* extends the agent's memory beyond text. It maps relationships between *Code Blocks, Documents, Media Assets, and Research PDFs*, enabling cross-modal context retrieval.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -16,9 +16,9 @@ The **Unified Knowledge Hyper-Graph** extends the agent's memory beyond text. It
Unify the system's diverse information silos into a single, navigable graph.
** 2. User Needs
- **Cross-Modal Linking:** Connect a Lisp function to a research PDF and an Org PRD.
- **Traceability:** Follow the chain of reasoning from requirement to implementation.
- **Deep Retrieval:** Pull related media assets during plan synthesis.
- *Cross-Modal Linking:* Connect a Lisp function to a research PDF and an Org PRD.
- *Traceability:* Follow the chain of reasoning from requirement to implementation.
- *Deep Retrieval:* Pull related media assets during plan synthesis.
* Phase D: Build (Implementation)

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :gateway:sensors:io:psf:
* Overview
The **Inbound Multi-Channel Gateway** provides the sensory interface for external messaging. It enables the agent to "hear" the user from various platforms (Signal, Telegram, SMS) by normalizing disparate inbound payloads into standard Neurosymbolic Kernel stimuli.
The *Inbound Multi-Channel Gateway* provides the sensory interface for external messaging. It enables the agent to "hear" the user from various platforms (Signal, Telegram, SMS) by normalizing disparate inbound payloads into standard Neurosymbolic Kernel stimuli.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Inbound Multi-Channel Gateway** provides the sensory interface for externa
Define a secure and extensible ingress for external communication channels.
** 2. User Needs
- **Multi-Channel Ingress:** Support Signal (via signal-cli), Telegram (via Bot API), and generic Webhooks.
- **Payload Normalization:** Convert platform-specific JSON into standard Lisp plists.
- **Security & Authentication:** Verify sender identity before injecting stimuli into the kernel.
- **Asynchronous Reception:** Non-blocking monitoring of inbound message queues.
- *Multi-Channel Ingress:* Support Signal (via signal-cli), Telegram (via Bot API), and generic Webhooks.
- *Payload Normalization:* Convert platform-specific JSON into standard Lisp plists.
- *Security & Authentication:* Verify sender identity before injecting stimuli into the kernel.
- *Asynchronous Reception:* Non-blocking monitoring of inbound message queues.
** 3. Success Criteria
*** TODO Signal-cli message reception and parsing

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :planning:meta-cognition:long-horizon:psf:
* Overview
The **Long-Horizon Planning Agent** manages complex, multi-step tasks that exceed the context window of standard LLMs. It uses an Org-mode **Dynamic Task Tree** to track progress, summarize completed sub-tasks, and prune irrelevant execution branches.
The *Long-Horizon Planning Agent* manages complex, multi-step tasks that exceed the context window of standard LLMs. It uses an Org-mode *Dynamic Task Tree* to track progress, summarize completed sub-tasks, and prune irrelevant execution branches.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Long-Horizon Planning Agent** manages complex, multi-step tasks that excee
Enable the agent to maintain focus and coherence over tasks spanning 100+ steps (SWE-bench parity).
** 2. User Needs
- **Hierarchical Planning:** Break large goals into a nested tree of Org headlines.
- **Context Compression:** Automatically summarize the results of child sub-trees into their parent nodes.
- **Branch Pruning:** Meta-cognitive review to stop execution of failed or redundant paths.
- **Self-Correction:** Adjust the plan dynamically based on environmental feedback.
- *Hierarchical Planning:* Break large goals into a nested tree of Org headlines.
- *Context Compression:* Automatically summarize the results of child sub-trees into their parent nodes.
- *Branch Pruning:* Meta-cognitive review to stop execution of failed or redundant paths.
- *Self-Correction:* Adjust the plan dynamically based on environmental feedback.
** 3. Success Criteria
*** TODO Dynamic Task Tree Generation

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :psf:automation:meta-cognitive:orchestration:
* Overview
The **PSF Loop Automator** is the meta-cognitive orchestrator of the Personal Software Foundry. It monitors the state of all Master Notes and autonomously triggers the transition between PSF phases (e.g., waking the Architect when a PRD is frozen), ensuring the Consensus Loop maintains high momentum without manual intervention.
The *PSF Loop Automator* is the meta-cognitive orchestrator of the Personal Software Foundry. It monitors the state of all Master Notes and autonomously triggers the transition between PSF phases (e.g., waking the Architect when a PRD is frozen), ensuring the Consensus Loop maintains high momentum without manual intervention.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,12 +15,12 @@ The **PSF Loop Automator** is the meta-cognitive orchestrator of the Personal So
Define automated state transitions and role-triggering for the PSF Consensus Loop.
** 2. User Needs
- **State Surveillance:** Monitor `notes/org-skill-*.org` for `#+STATUS:` changes.
- **Proactive Role Triggering:**
- If `PRD` is `FROZEN` -> Trigger **Architect** (Phase B).
- If `PROTOCOL` is `SIGNED` -> Trigger **Technical Analyst** (Phase C).
- If `TDD Suite` is `RED` -> Trigger **Coder** (Phase D).
- **GTD Synchronization:** Automatically update the `:PSF-STATE:` property in `gtd.org` during transitions.
- *State Surveillance:* Monitor `notes/org-skill-*.org` for `#+STATUS:` changes.
- *Proactive Role Triggering:*
- If `PRD` is `FROZEN` -> Trigger *Architect* (Phase B).
- If `PROTOCOL` is `SIGNED` -> Trigger *Technical Analyst* (Phase C).
- If `TDD Suite` is `RED` -> Trigger *Coder* (Phase D).
- *GTD Synchronization:* Automatically update the `:PSF-STATE:` property in `gtd.org` during transitions.
** 3. Success Criteria
*** TODO Successful detection of #+STATUS: FROZEN in a Master Note

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :memex:gtd:zettelkasten:integrity:psf:
* Overview
The **Memex Manager** is the primary automation engine for the Personal Knowledge Management system. It enforces metadata standards, automates task lifecycles, and distills ephemeral daily logs into timeless knowledge.
The *Memex Manager* is the primary automation engine for the Personal Knowledge Management system. It enforces metadata standards, automates task lifecycles, and distills ephemeral daily logs into timeless knowledge.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,11 +15,11 @@ The **Memex Manager** is the primary automation engine for the Personal Knowledg
Define automated behaviors for knowledge and task management integrity.
** 2. User Needs
- **Unified Capture:** Landing all new information in `inbox.org`.
- **Metadata Compliance:** Mandatory `:CREATED:` and `:LOGBOOK:` drawers.
- **Automated Task Lifecycle:** `NEXT` promotion logic for GTD.
- **Mobile Sovereignty:** Compatibility with Markor and Orgzly.
- **Agentic Distillation:** Extracting evergreen concepts from daily logs.
- *Unified Capture:* Landing all new information in `inbox.org`.
- *Metadata Compliance:* Mandatory `:CREATED:` and `:LOGBOOK:` drawers.
- *Automated Task Lifecycle:* `NEXT` promotion logic for GTD.
- *Mobile Sovereignty:* Compatibility with Markor and Orgzly.
- *Agentic Distillation:* Extracting evergreen concepts from daily logs.
** 3. Success Criteria
*** TODO Metadata Audit Accuracy

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :discovery:telemetry:psf:
* Overview
The **Model Explorer Agent** provides dynamic introspection of the system's LLM capabilities. It intercepts specific user commands to list and describe all available models across providers, rendering them as native Org-mode tables.
The *Model Explorer Agent* provides dynamic introspection of the system's LLM capabilities. It intercepts specific user commands to list and describe all available models across providers, rendering them as native Org-mode tables.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ The **Model Explorer Agent** provides dynamic introspection of the system's LLM
Define the interfaces for system-wide model discovery and transparency.
** 2. User Needs
- **Transparency:** Visible list of models and context windows.
- **Determinism:** Metadata retrieval must bypass System 1 for high fidelity.
- **Integration:** Results rendered as native Org-mode tables.
- *Transparency:* Visible list of models and context windows.
- *Determinism:* Metadata retrieval must bypass System 1 for high fidelity.
- *Integration:* Results rendered as native Org-mode tables.
** 3. Success Criteria
*** TODO Command Trigger Verification (@agent list models)

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :memory:persistence:closos:psf:
* Overview
The **Object Store Persistence** skill ensures that the agent's perceptual memory (the `*object-store*`) is durable. It provides the mechanism to "dump" the in-RAM knowledge graph to a Lisp-native image file and "reload" it upon boot, eliminating the need to re-parse the entire Memex on every restart.
The *Object Store Persistence* skill ensures that the agent's perceptual memory (the `*object-store*`) is durable. It provides the mechanism to "dump" the in-RAM knowledge graph to a Lisp-native image file and "reload" it upon boot, eliminating the need to re-parse the entire Memex on every restart.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Object Store Persistence** skill ensures that the agent's perceptual memor
Define automated behaviors for knowledge graph serialization and restoration.
** 2. User Needs
- **Instant Recall:** Rapid loading of the Object Store from a persistent image.
- **High-Fidelity Serialization:** Recursive dumping of `org-object` structs and their relations.
- **Atomic Persistence:** Save the entire graph state to a single `.el` or `.lisp` file.
- **Background Synchronization:** Periodically dump the image during heartbeats.
- *Instant Recall:* Rapid loading of the Object Store from a persistent image.
- *High-Fidelity Serialization:* Recursive dumping of `org-object` structs and their relations.
- *Atomic Persistence:* Save the entire graph state to a single `.el` or `.lisp` file.
- *Background Synchronization:* Periodically dump the image during heartbeats.
** 3. Success Criteria
*** TODO Image Dump logic verification (File exists and is readable)

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :onboarding:calibration:setup:psf:
* Overview
The **Onboarding Skill** ensures that the Lisp Machine environment is correctly calibrated. It automates the "zero-to-one" setup of the Neurosymbolic Kernel, including path normalization, identity personalization, and provider/actuator configuration.
The *Onboarding Skill* ensures that the Lisp Machine environment is correctly calibrated. It automates the "zero-to-one" setup of the Neurosymbolic Kernel, including path normalization, identity personalization, and provider/actuator configuration.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,11 +15,11 @@ The **Onboarding Skill** ensures that the Lisp Machine environment is correctly
Define automated behaviors for verifying and configuring the PSF environment.
** 2. User Needs
- **Environment Verification:** Confirm SBCL, Quicklisp, and core binaries are present.
- **Path Calibration:** Resolve absolute paths for the Memex PARA structure.
- **Neural Calibration:** Interactive selection of LLM providers and models.
- **Actuator Calibration:** Interactive setup of delivery channels (Signal, Telegram, etc.).
- **Identity Persona:** Establish $MEMEX_USER and $MEMEX_ASSISTANT.
- *Environment Verification:* Confirm SBCL, Quicklisp, and core binaries are present.
- *Path Calibration:* Resolve absolute paths for the Memex PARA structure.
- *Neural Calibration:* Interactive selection of LLM providers and models.
- *Actuator Calibration:* Interactive setup of delivery channels (Signal, Telegram, etc.).
- *Identity Persona:* Establish $MEMEX_USER and $MEMEX_ASSISTANT.
** 3. Success Criteria
*** TODO SBCL/Quicklisp Verification Logic

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :delivery:actuator:external:psf:
* Overview
The **Org-Native Delivery Agent** is the primary outbound actuator for external messaging. It uses the "Inbox-as-a-Queue" pattern, enqueuing structured Org-mode headlines for external bridges (Signal, Telegram, etc.).
The *Org-Native Delivery Agent* is the primary outbound actuator for external messaging. It uses the "Inbox-as-a-Queue" pattern, enqueuing structured Org-mode headlines for external bridges (Signal, Telegram, etc.).
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ The **Org-Native Delivery Agent** is the primary outbound actuator for external
Define the interfaces for asynchronous external message enqueuing.
** 2. User Needs
- **Asynchronous Dispatch:** Persistence via `delivery.org` file.
- **Multi-Channel Support:** Routing to Signal, Telegram, Discord.
- **Structured Provenance:** Timestamped entries with recipient IDs.
- *Asynchronous Dispatch:* Persistence via `delivery.org` file.
- *Multi-Channel Support:* Routing to Signal, Telegram, Discord.
- *Structured Provenance:* Timestamped entries with recipient IDs.
** 3. Success Criteria
*** TODO Queue Appending Verification

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :emacs:gtd:roam:archiving:psf:
* Overview
The **Org-GTD Archive Roam Daily** skill enables chronological archiving of completed GTD tasks. Instead of a flat archive file, tasks are moved to their respective `org-roam-dailies` files based on their `:CREATED:` property, preserving contextual and temporal integrity.
The *Org-GTD Archive Roam Daily* skill enables chronological archiving of completed GTD tasks. Instead of a flat archive file, tasks are moved to their respective `org-roam-dailies` files based on their `:CREATED:` property, preserving contextual and temporal integrity.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Org-GTD Archive Roam Daily** skill enables chronological archiving of comp
Define the requirements for chronologically-aware task archiving.
** 2. User Needs
- **Temporal Alignment:** Archive tasks to the daily file matching their creation date.
- **Context Preservation:** Maintain all properties and sub-elements during the move.
- **Robust Extraction:** Correctly parse `:CREATED:` property timestamps.
- **Fail-safe Logic:** Default to current date if `:CREATED:` is missing (with a warning).
- *Temporal Alignment:* Archive tasks to the daily file matching their creation date.
- *Context Preservation:* Maintain all properties and sub-elements during the move.
- *Robust Extraction:* Correctly parse `:CREATED:` property timestamps.
- *Fail-safe Logic:* Default to current date if `:CREATED:` is missing (with a warning).
** 3. Success Criteria
*** TODO Successful extraction of [YYYY-MM-DD] from :CREATED:

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :org-mode:json:manipulation:psf:
* Overview
The **Org-JSON Bridge** enables programmatic manipulation of Org-mode files by converting them into a structured JSON representation and vice-versa. This bypasses the fragility of direct string manipulation for complex structures like tables, properties, and source blocks.
The *Org-JSON Bridge* enables programmatic manipulation of Org-mode files by converting them into a structured JSON representation and vice-versa. This bypasses the fragility of direct string manipulation for complex structures like tables, properties, and source blocks.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Org-JSON Bridge** enables programmatic manipulation of Org-mode files by c
Define the interfaces for bidirectional Org-to-JSON conversion.
** 2. User Needs
- **Robust Parsing:** Convert Org-mode files into structured JSON AST.
- **High-Fidelity Rendering:** Re-materialize JSON AST back into syntactically correct Org-mode text.
- **Complex Structure Support:** Handle tables, property drawers, and source blocks without data loss.
- **Programmatic API:** Provide a CLI and Lisp interface for other skills to use.
- *Robust Parsing:* Convert Org-mode files into structured JSON AST.
- *High-Fidelity Rendering:* Re-materialize JSON AST back into syntactically correct Org-mode text.
- *Complex Structure Support:* Handle tables, property drawers, and source blocks without data loss.
- *Programmatic API:* Provide a CLI and Lisp interface for other skills to use.
** 3. Success Criteria
*** TODO Parse Org-mode to JSON AST without loss of hierarchy

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :org-mode:ast:homoiconic:psf:
* Overview
This skill defines the **Grammar of the Memex**. It establishes the rules for treating plain text as a structured, hierarchical database. Org-mode is our **Homoiconic Memory**—documentation for humans and AST for the agent.
This skill defines the *Grammar of the Memex*. It establishes the rules for treating plain text as a structured, hierarchical database. Org-mode is our *Homoiconic Memory*—documentation for humans and AST for the agent.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ This skill defines the **Grammar of the Memex**. It establishes the rules for tr
Define the structural rules and manipulation interfaces for the Org-mode AST.
** 2. User Needs
- **Everything is a Node:** Mandatory headlines, properties, and unique IDs.
- **Literate Programming:** Code must be wrapped in narrative-rich blocks.
- **Naming & Paths:** Strict kebab-case and flat directory structure.
- **Binary Integrity:** Management of attachments via the Attachment Protocol.
- *Everything is a Node:* Mandatory headlines, properties, and unique IDs.
- *Literate Programming:* Code must be wrapped in narrative-rich blocks.
- *Naming & Paths:* Strict kebab-case and flat directory structure.
- *Binary Integrity:* Management of attachments via the Attachment Protocol.
** 3. Success Criteria
*** TODO ID Uniqueness Enforcement

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :telemetry:audit:self-improvement:psf:
* Overview
The **Autonomous Performance Auditor** is the system's "Quality Control" agent. It monitors the internal `*skill-telemetry*` registry to identify skills with high failure rates or excessive latency. When a performance threshold is breached, it autonomously triggers the **Scribe-RCA** role to analyze the failure and record it in the Institutional Memory.
The *Autonomous Performance Auditor* is the system's "Quality Control" agent. It monitors the internal `*skill-telemetry*` registry to identify skills with high failure rates or excessive latency. When a performance threshold is breached, it autonomously triggers the *Scribe-RCA* role to analyze the failure and record it in the Institutional Memory.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Autonomous Performance Auditor** is the system's "Quality Control" agent.
Define automated behaviors for system-wide skill performance monitoring and failure alerting.
** 2. User Needs
- **Continuous Monitoring:** Analyze skill metrics (executions, failures, latency) on every heartbeat.
- **Threshold Alerts:** Detect skills with failure rates exceeding a defined limit (e.g., >20%).
- **Loop Closure:** Autonomously trigger Root Cause Analysis (RCA) for offending skills.
- **Transparency:** Log audit results to the kernel history for user visibility.
- *Continuous Monitoring:* Analyze skill metrics (executions, failures, latency) on every heartbeat.
- *Threshold Alerts:* Detect skills with failure rates exceeding a defined limit (e.g., >20%).
- *Loop Closure:* Autonomously trigger Root Cause Analysis (RCA) for offending skills.
- *Transparency:* Log audit results to the kernel history for user visibility.
** 3. Success Criteria
*** TODO Failure rate calculation logic verification

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :foundry:scaffolding:system:psf:
* Overview
The **Project Foundry Agent** is responsible for the physical instantiation of new projects. It automates directory creation, version control initialization, and GTD integration, ensuring every new project adheres to PSF mandates.
The *Project Foundry Agent* is responsible for the physical instantiation of new projects. It automates directory creation, version control initialization, and GTD integration, ensuring every new project adheres to PSF mandates.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Project Foundry Agent** is responsible for the physical instantiation of n
Define automated project instantiation behaviors for the PSF.
** 2. User Needs
- **Workspace Scaffolding:** Create standard `src/`, `tests/`, `docs/` layout and boilerplate files.
- **Version Control:** Initialize Git in new project directories.
- **GTD Integration:** Automatically append projects and initial tasks to `gtd.org`.
- **Safety:** Prevent overwriting existing projects and log all actions.
- *Workspace Scaffolding:* Create standard `src/`, `tests/`, `docs/` layout and boilerplate files.
- *Version Control:* Initialize Git in new project directories.
- *GTD Integration:* Automatically append projects and initial tasks to `gtd.org`.
- *Safety:* Prevent overwriting existing projects and log all actions.
** 3. Success Criteria
*** TODO Structural Compliance

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :project:management:git:psf:
* Overview
The **Project Manager Agent** provides executive presence by monitoring project health and tracking git status. It leverages `:PROJECT_PATH:` metadata to gather "folder facts" and assist in the project lifecycle.
The *Project Manager Agent* provides executive presence by monitoring project health and tracking git status. It leverages `:PROJECT_PATH:` metadata to gather "folder facts" and assist in the project lifecycle.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ The **Project Manager Agent** provides executive presence by monitoring project
Define automated behaviors for project monitoring and version control tracking.
** 2. User Needs
- **Visibility:** Resolve physical project locations and gather git/file facts.
- **Contextual Awareness:** Trigger on status queries or project-node edits.
- **Lifecycle Support:** Suggest commit messages and identify uncommitted work.
- *Visibility:* Resolve physical project locations and gather git/file facts.
- *Contextual Awareness:* Trigger on status queries or project-node edits.
- *Lifecycle Support:* Suggest commit messages and identify uncommitted work.
** 3. Success Criteria
*** TODO Project Path Resolution

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :llm:provider:anthropic:claude:psf:
* Overview
The **Anthropic Provider Agent** integrates Anthropic's Claude family of models as a pluggable System 1 (neural) backend. It enables high-intelligence reasoning, drafting, and analysis within the PSF.
The *Anthropic Provider Agent* integrates Anthropic's Claude family of models as a pluggable System 1 (neural) backend. It enables high-intelligence reasoning, drafting, and analysis within the PSF.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Anthropic Provider Agent** integrates Anthropic's Claude family of models
Define the interface for reliable communication with the Anthropic Messages API.
** 2. User Needs
- **Connectivity:** Reliable I/O with Claude models.
- **Configurability:** Model selection via Environment Configuration.
- **Context Management:** Leverage Claude's large context windows.
- **Safety:** Graceful error handling for API failures or missing keys.
- *Connectivity:* Reliable I/O with Claude models.
- *Configurability:* Model selection via Environment Configuration.
- *Context Management:* Leverage Claude's large context windows.
- *Safety:* Graceful error handling for API failures or missing keys.
** 3. Success Criteria
*** TODO API Authentication

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :llm:provider:gemini:google:psf:
* Overview
The **Gemini Provider Agent** integrates Google's Gemini API as a pluggable System 1 (neural) backend. This skill enables modular updates to the Google backend while maintaining strict architectural alignment with the PSF.
The *Gemini Provider Agent* integrates Google's Gemini API as a pluggable System 1 (neural) backend. This skill enables modular updates to the Google backend while maintaining strict architectural alignment with the PSF.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ The **Gemini Provider Agent** integrates Google's Gemini API as a pluggable Syst
Define the interface for reliable communication with the Google Gemini v1beta API.
** 2. User Needs
- **API Integration:** Implementation of the Gemini `contents.parts` protocol.
- **Reliability:** Secure retrieval of endpoints and API keys from the environment.
- **Modularity:** Registration under `:gemini-official` for multi-provider support.
- *API Integration:* Implementation of the Gemini `contents.parts` protocol.
- *Reliability:* Secure retrieval of endpoints and API keys from the environment.
- *Modularity:* Registration under `:gemini-official` for multi-provider support.
** 3. Success Criteria
*** TODO API Authentication via URL Key

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :llm:provider:ollama:local:psf:
* Overview
The **Ollama Provider Agent** enables the use of local, privacy-preserving LLM models. It integrates with a local Ollama instance to ensure system functionality and sovereignty without external internet connectivity.
The *Ollama Provider Agent* enables the use of local, privacy-preserving LLM models. It integrates with a local Ollama instance to ensure system functionality and sovereignty without external internet connectivity.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ The **Ollama Provider Agent** enables the use of local, privacy-preserving LLM m
Define the interface for communication with a local Ollama daemon.
** 2. User Needs
- **Sovereignty:** Fallback backend independent of cloud providers.
- **Performance:** Efficient local network interaction.
- **Simplicity:** Deterministic, non-streaming text generation.
- *Sovereignty:* Fallback backend independent of cloud providers.
- *Performance:* Efficient local network interaction.
- *Simplicity:* Deterministic, non-streaming text generation.
** 3. Success Criteria
*** TODO Local API Connectivity

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :llm:provider:openai:gpt:psf:
* Overview
The **OpenAI Provider Agent** integrates OpenAI's GPT models as a pluggable System 1 (neural) backend. It provides industry-standard processing capabilities for reasoning and content generation.
The *OpenAI Provider Agent* integrates OpenAI's GPT models as a pluggable System 1 (neural) backend. It provides industry-standard processing capabilities for reasoning and content generation.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **OpenAI Provider Agent** integrates OpenAI's GPT models as a pluggable Syst
Define the interface for reliable communication with the OpenAI Chat Completions API.
** 2. User Needs
- **Compatibility:** Full implementation of the Chat Completions protocol.
- **Reliability:** Secure management of `$OPENAI_API_KEY`.
- **Optimized Inference:** Configurable temperature and model selection (GPT-4o, etc.).
- **Resilience:** Graceful handling of timeouts and errors.
- *Compatibility:* Full implementation of the Chat Completions protocol.
- *Reliability:* Secure management of `$OPENAI_API_KEY`.
- *Optimized Inference:* Configurable temperature and model selection (GPT-4o, etc.).
- *Resilience:* Graceful handling of timeouts and errors.
** 3. Success Criteria
*** TODO API Authentication via Bearer Token

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :llm:provider:openrouter:unified:psf:
* Overview
The **OpenRouter Provider Agent** acts as a unified gateway to hundreds of LLMs. It provides flexibility by dynamically switching between models based on intelligence tiers while maintaining architectural alignment.
The *OpenRouter Provider Agent* acts as a unified gateway to hundreds of LLMs. It provides flexibility by dynamically switching between models based on intelligence tiers while maintaining architectural alignment.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **OpenRouter Provider Agent** acts as a unified gateway to hundreds of LLMs.
Define the interface for unified communication with the OpenRouter API.
** 2. User Needs
- **Abstraction:** OpenAI-compatible interface for all OpenRouter models.
- **Dynamic Routing:** Support for intelligence tiers (:POWERFUL, :FAST, :FREE).
- **Resilience:** Leverage auto-routing fallbacks.
- **Transparency:** Proper identification via Referer and Title headers.
- *Abstraction:* OpenAI-compatible interface for all OpenRouter models.
- *Dynamic Routing:* Support for intelligence tiers (:POWERFUL, :FAST, :FREE).
- *Resilience:* Leverage auto-routing fallbacks.
- *Transparency:* Proper identification via Referer and Title headers.
** 3. Success Criteria
*** TODO Tiered Model Resolution

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :router:meta-cognitive:delegation:psf:
* Overview
The **Router Agent** is the system's "Pre-Frontal Cortex." It classifies unstructured user input, decomposes complex requests into atomic intents, and orchestrates delegation to specialized sub-agents.
The *Router Agent* is the system's "Pre-Frontal Cortex." It classifies unstructured user input, decomposes complex requests into atomic intents, and orchestrates delegation to specialized sub-agents.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Router Agent** is the system's "Pre-Frontal Cortex." It classifies unstruc
Define the interfaces for intent classification and sub-agent delegation.
** 2. User Needs
- **Perception:** Monitor for explicit commands and implicit `@agent` requests.
- **Decomposition:** Break natural language into sequential atomic operations.
- **Efficiency:** Utilize low-latency models for rapid routing.
- **Dynamic Identity:** Adapt triggers based on the active agent name.
- *Perception:* Monitor for explicit commands and implicit `@agent` requests.
- *Decomposition:* Break natural language into sequential atomic operations.
- *Efficiency:* Utilize low-latency models for rapid routing.
- *Dynamic Identity:* Adapt triggers based on the active agent name.
** 3. Success Criteria
*** TODO @Agent Tag Detection

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :security:sandbox:ast:psf:
* Overview
The **Global Safety Harness** is the primary "Safety Gate" for the Neurosymbolic Lisp Machine. It provides a recursive AST validator that subjects all Elisp proposals from System 1 to a strict "Deny-by-Default" sandbox, preventing arbitrary code execution while allowing high-fidelity system manipulation.
The *Global Safety Harness* is the primary "Safety Gate" for the Neurosymbolic Lisp Machine. It provides a recursive AST validator that subjects all Elisp proposals from System 1 to a strict "Deny-by-Default" sandbox, preventing arbitrary code execution while allowing high-fidelity system manipulation.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Global Safety Harness** is the primary "Safety Gate" for the Neurosymbolic
Define a high-integrity, recursive security sandbox for Elisp execution.
** 2. User Needs
- **Recursive Validation:** Every nested function call and variable access MUST be checked.
- **Deny-by-Default:** Only explicitly whitelisted functions and variables are permitted.
- **Eval Protection:** Block all forms of `eval`, `load`, or dynamic execution.
- **Symbolic Preemption:** This skill acts as a mandatory global System 2 check.
- *Recursive Validation:* Every nested function call and variable access MUST be checked.
- *Deny-by-Default:* Only explicitly whitelisted functions and variables are permitted.
- *Eval Protection:* Block all forms of `eval`, `load`, or dynamic execution.
- *Symbolic Preemption:* This skill acts as a mandatory global System 2 check.
** 3. Success Criteria
*** TODO Implement recursive AST walker in Lisp

View File

@@ -5,7 +5,7 @@
#+DEPENDS_ON: skill-tdd-runner skill-scribe-rca
* Overview
The **Scientist Agent** provides a formal, hypothesis-driven approach to debugging. Instead of "trial and error," it formulates symbolic theories about why a failure occurred, designs experiments (test cases), and updates the system's **Institutional Memory** upon discovery.
The *Scientist Agent* provides a formal, hypothesis-driven approach to debugging. Instead of "trial and error," it formulates symbolic theories about why a failure occurred, designs experiments (test cases), and updates the system's *Institutional Memory* upon discovery.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -16,10 +16,10 @@ The **Scientist Agent** provides a formal, hypothesis-driven approach to debuggi
Eliminate speculative debugging through rigorous scientific methodology.
** 2. User Needs
- **Hypothesis Formulation:** Neural generation of potential failure causes.
- **Experimental Design:** Autonomous creation of minimal failing test cases.
- **Theory Verification:** Execution of tests via the TDD Runner.
- **Knowledge Update:** Permanent update to `RCA.org` to prevent regression.
- *Hypothesis Formulation:* Neural generation of potential failure causes.
- *Experimental Design:* Autonomous creation of minimal failing test cases.
- *Theory Verification:* Execution of tests via the TDD Runner.
- *Knowledge Update:* Permanent update to `RCA.org` to prevent regression.
* Phase D: Build (Implementation)

View File

@@ -5,7 +5,7 @@
#+DEPENDS_ON: skill-atomic-notes
* Overview
The **Scribe-RCA** agent is responsible for **Phase F: Memory**. It captures "Permanent Learnings" after significant failures or task completions, ensuring the system's **Institutional Memory** grows with every cycle.
The *Scribe-RCA* agent is responsible for *Phase F: Memory*. It captures "Permanent Learnings" after significant failures or task completions, ensuring the system's *Institutional Memory* grows with every cycle.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -16,10 +16,10 @@ The **Scribe-RCA** agent is responsible for **Phase F: Memory**. It captures "Pe
Automate the extraction of root causes and architectural learnings into the Memex.
** 2. User Needs
- **Root Cause Analysis:** Automatically draft an RCA note after a `skip-event` recovery.
- **Permanent Learning:** Update `SOUL.org` or a dedicated `RCA.org` with new invariants.
- **Version Control Integration:** Commit new RCA notes to Gitea autonomously.
- **Traceability:** Link every learning back to the original failure stimulus.
- *Root Cause Analysis:* Automatically draft an RCA note after a `skip-event` recovery.
- *Permanent Learning:* Update `SOUL.org` or a dedicated `RCA.org` with new invariants.
- *Version Control Integration:* Commit new RCA notes to Gitea autonomously.
- *Traceability:* Link every learning back to the original failure stimulus.
* Phase D: Build (Implementation)

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :scribe:distillation:psf:audit:
* Overview
The **Scribe Agent** is the primary custodian of the Institutional Memory. It distills ephemeral daily thoughts into atomic notes and audits foundry projects for compliance with PSF standards.
The *Scribe Agent* is the primary custodian of the Institutional Memory. It distills ephemeral daily thoughts into atomic notes and audits foundry projects for compliance with PSF standards.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Scribe Agent** is the primary custodian of the Institutional Memory. It di
Define automated distillation and auditing behaviors for the PSF.
** 2. User Needs
- **Knowledge Distillation:** Extract evergreen concepts from raw dailies.
- **Incremental Processing:** Efficient Git-based delta tracking.
- **PSF Mandate Audit:** High-integrity check for PRD/PROTOCOL artifacts.
- **Autonomous Execution:** Cron-compatible, environment-driven logic.
- *Knowledge Distillation:* Extract evergreen concepts from raw dailies.
- *Incremental Processing:* Efficient Git-based delta tracking.
- *PSF Mandate Audit:* High-integrity check for PRD/PROTOCOL artifacts.
- *Autonomous Execution:* Cron-compatible, environment-driven logic.
** 3. Success Criteria
*** TODO Distillation Accuracy

View File

@@ -5,7 +5,7 @@
#+DEPENDS_ON: skill-scientist skill-shell-actuator
* Overview
The **Self-Fix Agent** is the system's "Repair Mechanism." It takes the failure hypotheses from the **Scientist Agent**, applies surgical code modifications in a sandboxed environment, and merges the fix only after rigorous verification by the **TDD Runner**.
The *Self-Fix Agent* is the system's "Repair Mechanism." It takes the failure hypotheses from the *Scientist Agent*, applies surgical code modifications in a sandboxed environment, and merges the fix only after rigorous verification by the *TDD Runner*.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -16,10 +16,10 @@ The **Self-Fix Agent** is the system's "Repair Mechanism." It takes the failure
Enable autonomous, verified code correction without human intervention.
** 2. User Needs
- **Surgical Modification:** Apply targeted changes to specific Lisp functions or Org headlines.
- **Sandboxed Verification:** Test every fix in a controlled environment before merging.
- **Rollback Capability:** Use the **Interactive Steering** snapshots to revert if a fix fails.
- **Audit Logging:** Every fix must be documented in `RCA.org`.
- *Surgical Modification:* Apply targeted changes to specific Lisp functions or Org headlines.
- *Sandboxed Verification:* Test every fix in a controlled environment before merging.
- *Rollback Capability:* Use the *Interactive Steering* snapshots to revert if a fix fails.
- *Audit Logging:* Every fix must be documented in `RCA.org`.
* Phase D: Build (Implementation)

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :shell:actuator:system:psf:
* Overview
The **Shell Actuator Agent** provides the bridge to the host operating system. It enables secure command execution while maintaining a strict security posture through whitelisting and diagnostic feedback loops.
The *Shell Actuator Agent* provides the bridge to the host operating system. It enables secure command execution while maintaining a strict security posture through whitelisting and diagnostic feedback loops.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Shell Actuator Agent** provides the bridge to the host operating system. I
Define a secure, diagnostic-rich interface for host OS interaction.
** 2. User Needs
- **Secure Actuation:** Strict whitelist of permitted commands.
- **Diagnostic Feedback:** Capture STDOUT, STDERR, and exit codes.
- **Loop Closure:** Automatic neural analysis of command results.
- **Resilience:** Graceful handling of blocked or failed commands.
- *Secure Actuation:* Strict whitelist of permitted commands.
- *Diagnostic Feedback:* Capture STDOUT, STDERR, and exit codes.
- *Loop Closure:* Automatic neural analysis of command results.
- *Resilience:* Graceful handling of blocked or failed commands.
** 3. Success Criteria
*** TODO Whitelist Enforcement

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :concurrency:parallelism:threads:psf:
* Overview
The **Sub-Agent Manager** enables the Neurosymbolic Lisp Machine to handle multiple concurrent thoughts. It allows the primary kernel to "spawn" lightweight, isolated Lisp threads (sub-agents) to perform long-running or background tasks (research, massive refactors, etc.) without blocking the main event bus.
The *Sub-Agent Manager* enables the Neurosymbolic Lisp Machine to handle multiple concurrent thoughts. It allows the primary kernel to "spawn" lightweight, isolated Lisp threads (sub-agents) to perform long-running or background tasks (research, massive refactors, etc.) without blocking the main event bus.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Sub-Agent Manager** enables the Neurosymbolic Lisp Machine to handle multi
Define the interfaces for parallel cognitive execution and thread lifecycle management.
** 2. User Needs
- **Non-Blocking Execution:** Spawn background threads for long-running tasks.
- **Context Isolation:** Sub-agents must have their own execution context to prevent parent context poisoning.
- **Communication Loop:** Sub-agents must inject a "Return Stimulus" upon completion.
- **Observability:** Ability to list and terminate active sub-agents.
- *Non-Blocking Execution:* Spawn background threads for long-running tasks.
- *Context Isolation:* Sub-agents must have their own execution context to prevent parent context poisoning.
- *Communication Loop:* Sub-agents must inject a "Return Stimulus" upon completion.
- *Observability:* Ability to list and terminate active sub-agents.
** 3. Success Criteria
*** TODO Successful spawning of a non-blocking background thread

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :gtd:integrity:safety:psf:
* Overview
The **Task Integrity Agent** is the "Guardian" of the GTD system. It ensures that all task transitions adhere to semantic rules, preventing logical inconsistencies and maintaining the structural health of the task hierarchy.
The *Task Integrity Agent* is the "Guardian" of the GTD system. It ensures that all task transitions adhere to semantic rules, preventing logical inconsistencies and maintaining the structural health of the task hierarchy.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Task Integrity Agent** is the "Guardian" of the GTD system. It ensures tha
Define automated behaviors for GTD state consistency and dependency verification.
** 2. User Needs
- **Semantic Enforcement:** Valid state transitions (Active vs. Resolved).
- **Dependency Awareness:** Block closing parents with active children.
- **Proactive Assistance:** Suggesting next logical actions based on momentum.
- **Fidelity:** Preservation of metadata during state transitions.
- *Semantic Enforcement:* Valid state transitions (Active vs. Resolved).
- *Dependency Awareness:* Block closing parents with active children.
- *Proactive Assistance:* Suggesting next logical actions based on momentum.
- *Fidelity:* Preservation of metadata during state transitions.
** 3. Success Criteria
*** TODO Semantic Category Mapping

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :tdd:ci:verification:safety:psf:
* Overview
The **Automated TDD Runner** provides the system with Continuous Integration (CI) capabilities. It monitors active project directories and autonomously executes test suites whenever a file change is detected, ensuring that the kernel remains in a "Green" (verified) state.
The *Automated TDD Runner* provides the system with Continuous Integration (CI) capabilities. It monitors active project directories and autonomously executes test suites whenever a file change is detected, ensuring that the kernel remains in a "Green" (verified) state.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Automated TDD Runner** provides the system with Continuous Integration (CI
Define automated behaviors for background test execution and regression alerting.
** 2. User Needs
- **Background Execution:** Run `FiveAM` (Lisp) or `pytest` (Python) suites without user intervention.
- **Trigger on Perception:** Execute tests whenever a `:buffer-update` or `:file-saved` event occurs.
- **Immediate Alerting:** Inject a high-priority `:EVENT` into the kernel if a test fails.
- **System Locking:** Option to prevent further actions if the project is in a "RED" (failing) state.
- *Background Execution:* Run `FiveAM` (Lisp) or `pytest` (Python) suites without user intervention.
- *Trigger on Perception:* Execute tests whenever a `:buffer-update` or `:file-saved` event occurs.
- *Immediate Alerting:* Inject a high-priority `:EVENT` into the kernel if a test fails.
- *System Locking:* Option to prevent further actions if the project is in a "RED" (failing) state.
** 3. Success Criteria
*** TODO Automatic test suite discovery logic verification

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :analyst:testing:tdd:psf:
* Overview
The **Technical Analyst Agent** defines the **Success Criteria** for a project. It generates a failing test suite immediately after the architecture is signed, enforcing a strict TDD mandate within the PSF Consensus Loop.
The *Technical Analyst Agent* defines the *Success Criteria* for a project. It generates a failing test suite immediately after the architecture is signed, enforcing a strict TDD mandate within the PSF Consensus Loop.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Technical Analyst Agent** defines the **Success Criteria** for a project.
Define automated testing behaviors for the PSF Consensus Loop.
** 2. User Needs
- **Protocol Perception:** Monitor for `SIGNED` Protocols.
- **TDD Inception:** Translate interfaces into executable test cases.
- **Edge Case Coverage:** Mandatory testing of failure modes and malformed input.
- **Structural Enforcement:** Ensure the `tests/` directory is correctly initialized.
- *Protocol Perception:* Monitor for `SIGNED` Protocols.
- *TDD Inception:* Translate interfaces into executable test cases.
- *Edge Case Coverage:* Mandatory testing of failure modes and malformed input.
- *Structural Enforcement:* Ensure the `tests/` directory is correctly initialized.
** 3. Success Criteria
*** TODO Trigger Accuracy

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :web:dashboard:telemetry:psf:
* Overview
The **Web Dashboard Agent** provides a lightweight telemetry window into the Neurosymbolic Kernel. It exposes the active skill graph and system logs via a local HTML dashboard.
The *Web Dashboard Agent* provides a lightweight telemetry window into the Neurosymbolic Kernel. It exposes the active skill graph and system logs via a local HTML dashboard.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Web Dashboard Agent** provides a lightweight telemetry window into the Neu
Define the interfaces for system observability and telemetry serving.
** 2. User Needs
- **Transparency:** Overview of skill performance (executions, time, failures).
- **Accessibility:** Served over a local HTTP port.
- **Observability:** Tail of system logs for debugging.
- **Low Overhead:** Background execution.
- *Transparency:* Overview of skill performance (executions, time, failures).
- *Accessibility:* Served over a local HTTP port.
- *Observability:* Tail of system logs for debugging.
- *Low Overhead:* Background execution.
** 3. Success Criteria
*** TODO Server Bootstrap Verification

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :web:research:internet:psf:
* Overview
The **Web Research Agent** provides the bridge to the internet. It fetches and synthesizes information from the web using pluggable engines like Lynx and Curl, enabling real-time research and fact verification.
The *Web Research Agent* provides the bridge to the internet. It fetches and synthesizes information from the web using pluggable engines like Lynx and Curl, enabling real-time research and fact verification.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Web Research Agent** provides the bridge to the internet. It fetches and s
Define the interfaces for internet information retrieval and synthesis.
** 2. User Needs
- **Connectivity:** Pluggable engines (Lynx, Curl) for fetching URLs.
- **Synthesis:** Neural transformation of raw content into factual summaries.
- **Efficiency:** Default to text-only engines to minimize overhead.
- **Search Integration:** Automatic DuckDuckGo routing for general queries.
- *Connectivity:* Pluggable engines (Lynx, Curl) for fetching URLs.
- *Synthesis:* Neural transformation of raw content into factual summaries.
- *Efficiency:* Default to text-only engines to minimize overhead.
- *Search Integration:* Automatic DuckDuckGo routing for general queries.
** 3. Success Criteria
*** TODO Engine Fetching Verification (Lynx/Curl)

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :workspace:para:maintenance:psf:
* Overview
The **Workspace Manager Agent** is responsible for the ongoing maintenance and organization of the Memex workspace. It automates the "housekeeping" aspects of the PARA/Zettelkasten workflow, focusing on clutter reduction and structural alignment.
The *Workspace Manager Agent* is responsible for the ongoing maintenance and organization of the Memex workspace. It automates the "housekeeping" aspects of the PARA/Zettelkasten workflow, focusing on clutter reduction and structural alignment.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,9 +15,9 @@ The **Workspace Manager Agent** is responsible for the ongoing maintenance and o
Define automated housekeeping behaviors for PARA/Zettelkasten maintenance.
** 2. User Needs
- **Clutter Reduction:** Identify and archive `DONE` tasks.
- **Workflow Alignment:** Ensure consistency with PARA directory structure.
- **Proactive Organization:** Trigger on saves and heartbeats.
- *Clutter Reduction:* Identify and archive `DONE` tasks.
- *Workflow Alignment:* Ensure consistency with PARA directory structure.
- *Proactive Organization:* Trigger on saves and heartbeats.
** 3. Success Criteria
*** TODO Task Identification

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :hardware:server:sovereignty:modular:psf:
* Overview
The **Personal Server Appliance** project aims to design and develop a modular, high-integrity computing environment. It features swappable modules for compute, storage, networking, and signal processing, packaged in a sleek 10-inch or standard 19-inch form factor that resembles high-end audio equipment.
The *Personal Server Appliance* project aims to design and develop a modular, high-integrity computing environment. It features swappable modules for compute, storage, networking, and signal processing, packaged in a sleek 10-inch or standard 19-inch form factor that resembles high-end audio equipment.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Personal Server Appliance** project aims to design and develop a modular,
Define the requirements for a modular, user-serviceable, and aesthetically pleasing personal server.
** 2. User Needs
- **Modularity:** Unified backplane for swappable compute, storage, and power modules.
- **Sovereignty:** Full control over hardware and the software stack (running `org-agent`).
- **Aesthetics:** Sleek "Hi-Fi" industrial design.
- **Multimodality:** Integration of SDR, AV, and specialized processors.
- *Modularity:* Unified backplane for swappable compute, storage, and power modules.
- *Sovereignty:* Full control over hardware and the software stack (running `org-agent`).
- *Aesthetics:* Sleek "Hi-Fi" industrial design.
- *Multimodality:* Integration of SDR, AV, and specialized processors.
** 3. Success Criteria
*** TODO Inter-module communication standard specification

View File

@@ -5,7 +5,7 @@
#+STARTUP: content
* Overview
The **Personal Software Foundry (PSF)** is a highly integrated, neurosymbolic "virtual software house" embedded within the Memex. It is the overarching system used to design, implement, and maintain all software projects. The PSF ensures that every line of code is provably correct, secure, and part of a self-improving cognitive loop.
The *Personal Software Foundry (PSF)* is a highly integrated, neurosymbolic "virtual software house" embedded within the Memex. It is the overarching system used to design, implement, and maintain all software projects. The PSF ensures that every line of code is provably correct, secure, and part of a self-improving cognitive loop.
It operates as a proactive agentic layer that handles the entire lifecycle of software creation—from proactive need-discovery to autonomous maintenance—adhering to the technical rigor of a native Lisp Machine.
@@ -20,8 +20,8 @@ Every document, plan, PRD, and skill in the system MUST be written in Org-mode (
** 3. Literate Programming (The Knuth-Sovereign Principle)
The PSF treats code not as a series of instructions for a computer, but as a "work of literature" for humans that happens to be executable.
- **Implementation:** All `org-agent` skills and system logic MUST be implemented as Literate Org files using `#+begin_src` blocks.
- **Rationale:** By weaving documentation and code together, we ensure that the "Why" (Architectural Intent) is never separated from the "How" (Implementation). This is the key to the PSF's **Institutional Memory**.
- *Implementation:* All `org-agent` skills and system logic MUST be implemented as Literate Org files using `#+begin_src` blocks.
- *Rationale:* By weaving documentation and code together, we ensure that the "Why" (Architectural Intent) is never separated from the "How" (Implementation). This is the key to the PSF's *Institutional Memory*.
** 4. Hardware Compartmentalization
The runtime environment is an enclosure (Docker, LXC, VM, or Bare Metal). The PSF kernel remains agnostic to its enclosure.
@@ -30,7 +30,7 @@ The runtime environment is an enclosure (Docker, LXC, VM, or Bare Metal). The PS
The Foundry serves as a mentorship environment. Agents must explain the "Why" and distill knowledge to increase user technical mastery. The user (Sovereign Executive) retains absolute right to deep-dive into any technical layer.
* Architectural Foundation (CLOSOS Principles)
The PSF is built on the **Common Lisp Object-Store Operating System (CLOSOS)** specification:
The PSF is built on the *Common Lisp Object-Store Operating System (CLOSOS)* specification:
- [[file:closos_attributed_object_store.org][Object-Store First]]: Data is treated as Attributed Lisp Objects (via `org-element` AST), not flat files.
- [[file:closos_single_address_space.org][Single Address Space]]: The CL Daemon and Emacs share a conceptual address space via OACP (Remote Object Proxy).
@@ -43,30 +43,30 @@ Projects pass through sequential "Safety Gates" managed by specialized departmen
| Phase | Department | Responsibility | Key Instrument |
| :--- | :--- | :--- | :--- |
| **A: Demand** | **Product** | User Interview & Needs | `PRD.org` |
| **B: Blueprint** | **Design** | Structural Integrity & API | [[file:../system/skills/org-skill-architect.org][Architect Skill]] |
| **C: Success** | **Quality** | TDD Inception & Security Audit | [[file:../system/skills/org-skill-tech-analyst.org][Analyst Skill]] |
| **D: Build** | **Engineering** | Minimal Implementation | `src/`, [[file:skill-project-foundry.org][Foundry Skill]] |
| **E: Chaos** | **Chaos** | Dynamic Testing & Chaos Eng. | [[file:org-skill-chaos.org][Chaos Skill]] |
| F: Memory | **Optimization** | Institutional Memory & RCA | [[file:institutional_memory.org][institutional_memory.org]], [[file:../system/skills/org-skill-scribe-rca.org][Scribe-RCA Skill]] |
| *A: Demand* | *Product* | User Interview & Needs | `PRD.org` |
| *B: Blueprint* | *Design* | Structural Integrity & API | [[file:../system/skills/org-skill-architect.org][Architect Skill]] |
| *C: Success* | *Quality* | TDD Inception & Security Audit | [[file:../system/skills/org-skill-tech-analyst.org][Analyst Skill]] |
| *D: Build* | *Engineering* | Minimal Implementation | `src/`, [[file:skill-project-foundry.org][Foundry Skill]] |
| *E: Chaos* | *Chaos* | Dynamic Testing & Chaos Eng. | [[file:org-skill-chaos.org][Chaos Skill]] |
| F: Memory | *Optimization* | Institutional Memory & RCA | [[file:institutional_memory.org][institutional_memory.org]], [[file:../system/skills/org-skill-scribe-rca.org][Scribe-RCA Skill]] |
** Success Matrix: "The Level 3 Standard"
A project is not complete until it achieves **Evolutionary Completion**:
1. **Functional:** Code merged and passing all audits (Chaos Gauntlet).
2. **Institutional:** Session distilled into atomic notes; code groomed for zero bloat.
3. **Evolutionary:** Automated health checks and recurring maintenance tasks established in `gtd.org` as standard task sequences.
A project is not complete until it achieves *Evolutionary Completion*:
1. *Functional:* Code merged and passing all audits (Chaos Gauntlet).
2. *Institutional:* Session distilled into atomic notes; code groomed for zero bloat.
3. *Evolutionary:* Automated health checks and recurring maintenance tasks established in `gtd.org` as standard task sequences.
* Operational Standards
- **Project Root:** All projects live in `memex/5_projects/`.
- **Common Structure:**
- *Project Root:* All projects live in `memex/5_projects/`.
- *Common Structure:*
- `README.org` (Vision)
- `PRD.org` (Requirements)
- `PROTOCOL.org` (Interfaces)
- `src/` (Implementation)
- `tests/` (Verification)
- `docs/` (Architecture/Chaos/RCA)
- **Self-Improvement (RCA):** Every bug triggers a **Root Cause Analysis** note to update "Permanent Learnings" in `SOUL.org`.
- *Self-Improvement (RCA):* Every bug triggers a *Root Cause Analysis* note to update "Permanent Learnings" in `SOUL.org`.
* See Also
- [[file:../projects/org-agent/README.org][org-agent (The Neurosymbolic Kernel)]]

View File

@@ -5,8 +5,8 @@
** 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.
- *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

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :business:revenue:strategy:operations:psf:
* Overview
The **Revenue Sustainability** project defines the strategy and operational setup for financial independence and sustainable business growth. It focuses on establishing the necessary infrastructure for payment processing, professional presence, and contractual integrity.
The *Revenue Sustainability* project defines the strategy and operational setup for financial independence and sustainable business growth. It focuses on establishing the necessary infrastructure for payment processing, professional presence, and contractual integrity.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Revenue Sustainability** project defines the strategy and operational setu
Define the requirements for a robust, sustainable revenue generation and management system.
** 2. User Needs
- **Payment Processing:** Integration with Stripe for seamless customer transactions.
- **Professional Presence:** Portfolio page, domain, and branded email.
- **Operational Integrity:** Time tracking, invoicing (Wave/Bonsai), and legal contract templates.
- **Social Proof:** System for testimonial collection and reputation management.
- *Payment Processing:* Integration with Stripe for seamless customer transactions.
- *Professional Presence:* Portfolio page, domain, and branded email.
- *Operational Integrity:* Time tracking, invoicing (Wave/Bonsai), and legal contract templates.
- *Social Proof:* System for testimonial collection and reputation management.
** 3. Success Criteria
*** TODO Stripe account verification and test transaction

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :radio:sdr:lisp:signal-processing:psf:
* Overview
The **SDR Suite Lisp** project aims to develop a comprehensive Software Defined Radio environment using Common Lisp. It leverages the high-performance, threaded nature of SBCL to provide real-time signal processing across various domains, from satellite communication to passive radar and computer networking.
The *SDR Suite Lisp* project aims to develop a comprehensive Software Defined Radio environment using Common Lisp. It leverages the high-performance, threaded nature of SBCL to provide real-time signal processing across various domains, from satellite communication to passive radar and computer networking.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **SDR Suite Lisp** project aims to develop a comprehensive Software Defined
Define the functional and technical requirements for a Lisp-native SDR architecture.
** 2. User Needs
- **Real-time Signal Processing:** High-performance DSP loops in Common Lisp.
- **Multimodal Support:** Unified framework for EME, ALE, SSTV, and standard Rx (FM/AM).
- **Extensibility:** Modular "plug-and-play" architecture for new decoders and protocols.
- **Hardware Agnostic:** Support for RTL-SDR, HackRF, and high-end FPGA-based SDRs.
- *Real-time Signal Processing:* High-performance DSP loops in Common Lisp.
- *Multimodal Support:* Unified framework for EME, ALE, SSTV, and standard Rx (FM/AM).
- *Extensibility:* Modular "plug-and-play" architecture for new decoders and protocols.
- *Hardware Agnostic:* Support for RTL-SDR, HackRF, and high-end FPGA-based SDRs.
** 3. Success Criteria
*** TODO Core DSP Loop Benchmarking (SBCL)

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :strategy:token:optimization:cost:psf:
* Overview
The **Token Optimization** project defines the strategy and implementation for cost-effective LLM usage. It implements a multi-tier, multi-provider approach to minimize inference costs while maximizing reasoning capability through smart routing and context compression.
The *Token Optimization* project defines the strategy and implementation for cost-effective LLM usage. It implements a multi-tier, multi-provider approach to minimize inference costs while maximizing reasoning capability through smart routing and context compression.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Token Optimization** project defines the strategy and implementation for c
Minimize LLM operational expenses while maintaining high-fidelity agentic performance.
** 2. User Needs
- **Multi-Tier Strategy:** Resolve tasks using the cheapest model that meets the required intelligence threshold.
- **Failover Resilience:** Automated fallback chain (Gemini -> OpenRouter -> GPT-4o).
- **Context Efficiency:** Implement pruning and RAG to avoid token bloat.
- **Usage Transparency:** Real-time tracking and budget alerts.
- *Multi-Tier Strategy:* Resolve tasks using the cheapest model that meets the required intelligence threshold.
- *Failover Resilience:* Automated fallback chain (Gemini -> OpenRouter -> GPT-4o).
- *Context Efficiency:* Implement pruning and RAG to avoid token bloat.
- *Usage Transparency:* Real-time tracking and budget alerts.
** 3. Success Criteria
*** TODO 80% of queries handled by Tier 1 (Free/Fast) models

View File

@@ -4,7 +4,7 @@
#+FILETAGS: :research:zettelkasten:zotero:import:psf:
* Overview
The **Zotero Org Import Tool** is a "makeshift" utility designed to bridge the gap between academic research management (Zotero) and the personal knowledge base (Org-mode). It focuses on two critical priorities: accurate linking to academic PDFs and creating persistent web snapshots for bookmarks.
The *Zotero Org Import Tool* is a "makeshift" utility designed to bridge the gap between academic research management (Zotero) and the personal knowledge base (Org-mode). It focuses on two critical priorities: accurate linking to academic PDFs and creating persistent web snapshots for bookmarks.
* Phase A: Demand (PRD)
:PROPERTIES:
@@ -15,10 +15,10 @@ The **Zotero Org Import Tool** is a "makeshift" utility designed to bridge the g
Define the requirements for a high-fidelity import of research artifacts from Zotero to Org-mode.
** 2. User Needs
- **BibTeX/JSON Parsing:** Ingest Zotero libraries via standard export formats.
- **Attachment Linking:** Maintain durable links to local PDF attachments.
- **Web Persistence:** Generate local or service-based snapshots of imported URLs.
- **Org-Native Schema:** Map Zotero metadata fields to appropriate Org properties.
- *BibTeX/JSON Parsing:* Ingest Zotero libraries via standard export formats.
- *Attachment Linking:* Maintain durable links to local PDF attachments.
- *Web Persistence:* Generate local or service-based snapshots of imported URLs.
- *Org-Native Schema:* Map Zotero metadata fields to appropriate Org properties.
** 3. Success Criteria
*** TODO Successful parsing of Zotero JSON export

View File

@@ -7,7 +7,7 @@
#+title: الموقف المصري: ضريبة القيمة المضافة
#+filetags: :الموقف المصري:
**دليل "الموقف المصري" للمواطن وعضو البرلمان عن قانون القيمة المضافة** -
*دليل "الموقف المصري" للمواطن وعضو البرلمان عن قانون القيمة المضافة* -
الجزء الأول
أولاً إيه هي ضريبة القيمة المضافة اللي الحكومة سلمت قانونها لمجلس النواب؟ تفرق إيه عن ضريبة المبيعات؟
@@ -119,7 +119,7 @@
ده موضوع الجزء التاني من البوست .. استنونا 
**دليل الموقف المصري للمواطن والبرلماني لفهم قانون القيمة المضافة** - الجزء الثاني
*دليل الموقف المصري للمواطن والبرلماني لفهم قانون القيمة المضافة* - الجزء الثاني
"العدالة الاجتماعية اساس الضرائب وغيرها من التكاليف المالية العامة" - المادة 26 من الدستور المصري.