81 lines
4.1 KiB
Org Mode
81 lines
4.1 KiB
Org Mode
#+TITLE: SKILL: Hardware Inhabitation Agent (Universal Literate Note)
|
|
#+ID: skill-hardware-inhabitation
|
|
#+STARTUP: content
|
|
#+FILETAGS: :sovereignty:deployment:bare-metal:lisp:psf:
|
|
#+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.
|
|
|
|
* Phase A: Demand (PRD)
|
|
:PROPERTIES:
|
|
:STATUS: FROZEN
|
|
:END:
|
|
|
|
** 1. Purpose
|
|
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.
|
|
|
|
|
|
* Phase B: Blueprint (PROTOCOL)
|
|
:PROPERTIES:
|
|
:STATUS: SIGNED
|
|
:END:
|
|
|
|
* Phase B: Blueprint (PROTOCOL)
|
|
:PROPERTIES:
|
|
:STATUS: ACTIVE
|
|
:END:
|
|
|
|
** 1. Architectural Intent
|
|
The Hardware Inhabitation Agent aims to provide an abstraction layer facilitating the Lisp Machine's deployment and execution directly on hardware, minimizing reliance on external operating systems or services. This promotes sovereignty by ensuring control from the metal up, and facilitates image portability for seamless transitions between hardware environments. It will manage hardware interfaces, image serialization/deserialization, and sovereignty auditing via a principled set of Lisp-defined interfaces.
|
|
|
|
** 2. Semantic Interfaces (Lisp Signatures)
|
|
|
|
*** 2.1 Bare-Metal Deployment
|
|
|
|
- `(bare-metal-deploy image-path hardware-configuration)`
|
|
- *Purpose:* Deploys a Lisp image onto bare metal.
|
|
- *Args:*
|
|
- `image-path`: Path to the serialized Lisp image file.
|
|
- `hardware-configuration`: A data structure (e.g., plist) specifying hardware-specific parameters, such as memory map, interrupt vectors, and device drivers.
|
|
- *Returns:* `T` on successful deployment, `NIL` on failure. On success returns a handle representing the deployed process.
|
|
- *Side Effects:* Overwrites the target hardware's boot sector with the Lisp image stub, or performs the equivalent action to initiate Lisp execution.
|
|
|
|
*** 2.2 Image Serialization & Deserialization
|
|
|
|
- `(serialize-lisp-image output-path)`
|
|
- *Purpose:* Serializes the current Lisp Machine's state into a relocatable image file.
|
|
- *Args:*
|
|
- `output-path`: The path to the output file where the image will be stored.
|
|
- *Returns:* `T` on successful serialization, `NIL` on failure.
|
|
- *Side Effects:* Creates a file at `output-path` containing the serialized image.
|
|
|
|
- `(deserialize-lisp-image input-path)`
|
|
- *Purpose:* Deserializes a Lisp Machine image from a file.
|
|
- *Args:*
|
|
- `input-path`: The path to the Lisp image file.
|
|
- *Returns:* `T` on successful deserialization. The restored Lisp Machine state.
|
|
- *Side Effects:* Overwrites the current Lisp Machine's state with the contents of the image file. Potentially destructive.
|
|
|
|
*** 2.3 Hardware Inventory
|
|
|
|
- `(get-hardware-manifest)`
|
|
- *Purpose:* Retrieves a manifest of available hardware resources.
|
|
- *Args:* None
|
|
- *Returns:* A list / plist describing the available actuators and sensors, including their types, IDs, and any relevant configuration parameters. Example: `((:type :gpio :id "gpio1" :direction :output) (:type :temperature-sensor :id "temp0"))`
|
|
|
|
*** 2.4 Sovereignty Audit
|
|
|
|
- `(audit-sovereignty)`
|
|
- *Purpose:* Verifies that the current Lisp Machine inhabitation is free from external dependencies that might compromise sovereignty. Relies on comparing known-good checksums of system components.
|
|
- *Args:* None
|
|
- *Returns:* `T` if the system passes the audit, `NIL` otherwise. May also return a list of dependencies that failed the audit, along with discrepancy information.
|
|
- *Side Effects:* May generate audit logs.
|
|
|