Scribo (AetherOS): Difference between revisions

From OODA WIKI
Jump to navigation Jump to search
AdminIsidore (talk | contribs)
No edit summary
AdminIsidore (talk | contribs)
No edit summary
 
Line 1: Line 1:
{{Scribo Version|3.0.0}}
{{Scribo Version|3.1.0}}
{{Project Status|Beta}}
{{Project Status|Beta}}
'''Scribo''' is a suite of command-line utilities designed to intelligently and automatically apply code changes from a revised file to an original source file. It streamlines the development workflow by creating a robust, autonomous system for integrating discrete revisions. It was co-developed by [[User:AdminIsidore|Isidore Lands]] and [[User:AlexMXlea|Alex M. Xlea]].
'''Scriptor''' is a unified, command-line SDK designed to intelligently and automatically apply code changes from a revised file to an original source file. It streamlines the development workflow by creating a robust, autonomous system for integrating discrete revisions. It was co-developed by [[User:Isidore Lands|Isidore Lands]] and [[User:Alex M. Xlea|Alex M. Xlea]].


The system is architected as a producer/consumer toolset, consisting of the patch generator, '''Compara''', and an autonomous background daemon, '''Speculator''', which detects and processes patches.
The system is architected as a producer/consumer toolset, consisting of the patch generator command, '''scriptor compara''', and an autonomous background daemon, '''scriptor speculator''', which detects and processes patches.


== Architecture and Philosophy ==
== Architecture and Philosophy ==
The core philosophy of Scribo is to make the revision process invisible, robust, and safe. A developer should only need to be concerned with writing the code, not the mechanics of integrating it. Scribo v3.0 achieves this through a sophisticated, multi-stage pipeline:
The core philosophy of Scriptor is to make the revision process invisible, robust, and safe. A developer should only need to be concerned with writing the code, not the mechanics of integrating it. Scriptor v3.1 achieves this through a sophisticated, multi-stage pipeline:
* '''Producer/Consumer Model:''' The '''Speculator''' daemon's sole responsibility is to detect new patches and place them on a work queue. A separate worker thread, the '''Operarius''' (workman), pulls from this queue to process each patch sequentially, ensuring the system is resilient to rapid, multiple patch submissions.
* '''Producer/Consumer Model:''' The '''speculator''' daemon's sole responsibility is to detect new patches and place them on a work queue. A separate worker thread, the '''Operarius''' (workman), pulls from this queue to process each patch sequentially, ensuring the system is resilient to rapid, multiple patch submissions.
* '''Atomic Operations:''' No change is committed until it is fully verified. Before patching, a temporary backup of the original file is created. The system then applies the patch, formats the code, and runs tests. Only if all stages succeed is the backup removed. If any stage fails, the original file is instantly restored from the backup and the faulty patch is quarantined.
* '''Atomic Operations:''' No change is committed until it is fully verified. Before patching, a temporary backup of the original file is created. The system then applies the patch, formats the code, and runs tests. Only if all stages succeed is the backup removed. If any stage fails, the original file is instantly restored from the backup and the faulty patch is quarantined.
* '''Automated Verification (The Probator):''' After a patch is applied and formatted, the '''Probator''' (tester) automatically discovers and runs the project's '''pytest''' suite. This crucial step prevents patches that break existing functionality from ever being integrated.
* '''Automated Verification (The Probator):''' After a patch is applied and formatted, the '''Probator''' (tester) automatically discovers and runs the project's '''pytest''' suite. This crucial step prevents patches that break existing functionality from ever being integrated.
* '''Persistent Logging:''' All actions are recorded in a rotating log file, '''Acta Scriptoris''' (The Records of Scriptor), providing a durable audit trail of every patch that was applied, rejected, or quarantined.
* '''Persistent Logging:''' All actions are recorded in a rotating log file, '''Acta Scriptoris''' (The Records of Scriptor), providing a durable audit trail of every patch that was applied, rejected, or quarantined.
* '''True Daemonization:''' The '''Speculator''' is designed to run as a proper background service using '''systemd''', ensuring it is always running, automatically starts on login, and restarts itself on failure.
* '''True Daemonization:''' The '''speculator''' is designed to run as a proper background service using '''systemd''', ensuring it is always running, automatically starts on login, and restarts itself on failure.


== Core Components ==
== Core Components & Commands ==
The Scribo suite is composed of several specialized tools that form the automation pipeline:
The Scriptor SDK is a single, unified tool (`scriptor`) that provides several subcommands.
* '''Compara''' (The Comparer): Generates a self-contained `.patch` file by comparing an original and a revised source file.
* '''`scriptor compara`''' (The Comparer): Generates a self-contained `.patch` file by comparing an original and a revised source file.
* '''Speculator''' (The Watcher): The file system watcher daemon that detects new patches in the inbox.
* '''`scriptor speculator`''' (The Watcher): The file system watcher daemon that detects new patches in the inbox.
* '''`scriptor inceptor`''' (The Inceptor): A project scaffolding tool that creates new, sandboxed development initiatives.
* '''`scriptor praetor`''' (The Praetor): The Fleet Commander, used for deploying tools and managing multiple development nodes.
 
The core modules that power these commands are:
* '''Operarius''' (The Workman): The background worker thread that executes the processing pipeline for each patch.
* '''Operarius''' (The Workman): The background worker thread that executes the processing pipeline for each patch.
* '''Perfector''' (The Completer): The module responsible for applying the patch to the target file.
* '''Perfector''' (The Completer): The module responsible for applying the patch to the target file.
* '''Ornator''' (The Arranger): The module that runs code formatters (like Black and Ruff) on the newly patched file.
* '''Ornator''' (The Arranger): The module that runs code formatters (like Black and Ruff) on newly patched files.
* '''Probator''' (The Tester): The verification module that runs the project's test suite to confirm the patch's integrity.
* '''Probator''' (The Tester): The verification module that runs the project's test suite to confirm the patch's integrity.


== Installation ==
== Installation ==
Scribo is designed as a global command-line tool using `pipx` to ensure it operates in an isolated environment.
Scriptor is designed as a global command-line tool using `pipx` to ensure it operates in an isolated environment.


=== Prerequisites ===
=== Prerequisites ===
Line 29: Line 33:
* [[https://pypa.github.io/pipx/ pipx]]
* [[https://pypa.github.io/pipx/ pipx]]
* [[https://git-scm.com/ Git]] (for the Probator's project root discovery)
* [[https://git-scm.com/ Git]] (for the Probator's project root discovery)
* A test runner like `pytest` installed in projects you wish to verify.


=== Installation Steps ===
=== Installation Steps ===
# Clone the repository from GitHub:
1. Clone the repository from GitHub:
<code>
<code>
git clone https://github.com/IsidoreLands/scribo.git
git clone https://github.com/IsidoreLands/scribo.git
cd scribo/coniunctor
cd scribo
</code>
</code>


# Use `pipx` to install the package. This builds the tool and makes the `compara` and `speculator` commands globally available.
2. Use `pipx` to install the package. This builds the tool and makes the `scriptor` command globally available.
<code>
<code>
pipx install .
pipx install .
</code>
</code>


# Create the inbox directory that the Speculator will monitor:
3. Create the inbox directory that the Speculator will monitor:
<code>
<code>
mkdir ~/scribo_inbox
mkdir ~/scribo_inbox
Line 49: Line 52:


== Operation ==
== Operation ==
The standard workflow involves running the `speculator` daemon as a background service and using `compara` to generate patches.
The standard workflow involves running the `speculator` daemon as a background service and using the other `scriptor` commands to perform tasks.


=== Step 1: Run Speculator as a Service ===
=== Step 1: Run Speculator as a Service ===
The recommended way to run the watcher is as a `systemd` user service. This ensures it's always running in the background.
The recommended way to run the watcher is as a `systemd` user service.


1. Create the service file at `~/.config/systemd/user/scriptor.service`:
1. Create the service file at `~/.config/systemd/user/scriptor.service`:
<code>
<code>
[Unit]
[Unit]
Description=Scriptor Speculator Daemon
Description=Scriptor Daemon (via Scriptor SDK)
After=network.target
After=network.target


[Service]
[Service]
ExecStart=%h/.local/bin/speculator
ExecStart=%h/.local/bin/scriptor speculator
Restart=on-failure
Restart=on-failure
RestartSec=5s
RestartSec=5s
Line 80: Line 83:
As a developer, you have your original file (`guide_main.py`) and a revised version (`guide_v4.py`). To integrate the changes, run the `compara` command:
As a developer, you have your original file (`guide_main.py`) and a revised version (`guide_v4.py`). To integrate the changes, run the `compara` command:
<code>
<code>
compara guide_main.py guide_v4.py
scriptor compara guide_main.py guide_v4.py
</code>
</code>


The moment the patch file is created in `~/scribo_inbox/`, the `speculator` service will detect it and trigger the full automated pipeline: apply, format, test, and commit or revert. Your work is done.
The moment the patch file is created in `~/scribo_inbox/`, the `speculator` service will detect it and trigger the full automated pipeline: apply, format, test, and commit or revert.


== Development Journal ==
== Development Journal ==
=== Version 3.0 (Current) ===
=== Version 3.1 (Current) ===
* '''Thematic Rebranding:''' All components were renamed with authentic Latin terms to create a cohesive and memorable toolset.
* '''Architectural Unification:''' All tools have been refactored into a single, unified SDK with a main `scriptor` command and logical subcommands (`speculator`, `compara`, `praetor`, `inceptor`).
* '''Architectural Overhaul:''' Implemented a robust producer/consumer model using a queue and a worker thread (`Operarius`) to handle patch processing.
* '''Enhanced Patching Logic:''' The core patching engine (`Perfector` and `Comparator`) was completely overhauled to use git-style relative paths, making it vastly more robust and reliable.
* '''Test-Driven Verification:''' Introduced the '''Probator''' module, which integrates `pytest` directly into the pipeline, enabling automated regression testing for every patch.
* '''Hardened Verification:''' The `Probator` and `Ornator` modules were refined to be more intelligent and fault-tolerant, correctly handling non-Python files and projects without tests.
* '''Atomic Operations:''' The entire patch process is now atomic, with an automatic backup and revert mechanism that guarantees a patch either succeeds completely or the system is returned to its original state.
* '''Daemonization:''' Added full support for running '''Speculator''' as a `systemd` service for true "fire-and-forget" background operation.
* '''Persistent Logging:''' Replaced console output with a formal, rotating log file (`Acta_Scriptoris.log`) via Python's `logging` module.


=== Version 1.1 ===
''(For previous versions, see the Git history.)''
* '''Architecture Refactor:''' Split the original monolithic `patcher` script into a two-part system.
* '''Formalized Patch Format:''' Patches now contain a metadata header specifying the target file path.
* '''Quarantine System:''' Added logic to move failing patches to a quarantine directory.


=== Roadmap (Future Development) ===
== Roadmap (Future Development) ==
* '''Conflict Resolution TUI:''' For patches that cannot be applied cleanly, develop a simple Text-based User Interface (TUI) that presents conflicting hunks for manual resolution.
* '''Praetor Fleet Command:''' Fully implement the `praetor deploy-sensor` command to provision new machines with the System Maneuverability toolset. Integrate the SM and Agentic Maneuverability (AM) scores into the Praetor's decision-making process for intelligent task dispatching.
* '''Plugin System:''' Allow for custom post-verification scripts (e.g., trigger notifications, deploy to staging).
* '''ARC Integration:''' Bridge the Scriptor SDK with the AetherOS `Navigator` ARC, allowing the ARC to autonomously propose and test patches to its own codebase.
* '''Remote Inbox:''' Explore options for using a message queue (like RabbitMQ or Redis) as an inbox for distributed development workflows.
* '''Initiative Scaffolding:''' Evolve the `inceptor` into a full-fledged project scaffolding tool that can bootstrap new initiatives with pre-configured ARCs and best-practice repository structures.


== Repository ==
== Repository ==
* The official source code is hosted on GitHub: [[https://github.com/IsidoreLands/scribo]]
* The official source code is hosted on GitHub: [[https://github.com/IsidoreLands/scribo]]

Latest revision as of 15:02, 26 August 2025

Template:Scribo Version Template:Project Status Scriptor is a unified, command-line SDK designed to intelligently and automatically apply code changes from a revised file to an original source file. It streamlines the development workflow by creating a robust, autonomous system for integrating discrete revisions. It was co-developed by Isidore Lands and Alex M. Xlea.

The system is architected as a producer/consumer toolset, consisting of the patch generator command, scriptor compara, and an autonomous background daemon, scriptor speculator, which detects and processes patches.

Architecture and Philosophy

The core philosophy of Scriptor is to make the revision process invisible, robust, and safe. A developer should only need to be concerned with writing the code, not the mechanics of integrating it. Scriptor v3.1 achieves this through a sophisticated, multi-stage pipeline:

  • Producer/Consumer Model: The speculator daemon's sole responsibility is to detect new patches and place them on a work queue. A separate worker thread, the Operarius (workman), pulls from this queue to process each patch sequentially, ensuring the system is resilient to rapid, multiple patch submissions.
  • Atomic Operations: No change is committed until it is fully verified. Before patching, a temporary backup of the original file is created. The system then applies the patch, formats the code, and runs tests. Only if all stages succeed is the backup removed. If any stage fails, the original file is instantly restored from the backup and the faulty patch is quarantined.
  • Automated Verification (The Probator): After a patch is applied and formatted, the Probator (tester) automatically discovers and runs the project's pytest suite. This crucial step prevents patches that break existing functionality from ever being integrated.
  • Persistent Logging: All actions are recorded in a rotating log file, Acta Scriptoris (The Records of Scriptor), providing a durable audit trail of every patch that was applied, rejected, or quarantined.
  • True Daemonization: The speculator is designed to run as a proper background service using systemd, ensuring it is always running, automatically starts on login, and restarts itself on failure.

Core Components & Commands

The Scriptor SDK is a single, unified tool (`scriptor`) that provides several subcommands.

  • `scriptor compara` (The Comparer): Generates a self-contained `.patch` file by comparing an original and a revised source file.
  • `scriptor speculator` (The Watcher): The file system watcher daemon that detects new patches in the inbox.
  • `scriptor inceptor` (The Inceptor): A project scaffolding tool that creates new, sandboxed development initiatives.
  • `scriptor praetor` (The Praetor): The Fleet Commander, used for deploying tools and managing multiple development nodes.

The core modules that power these commands are:

  • Operarius (The Workman): The background worker thread that executes the processing pipeline for each patch.
  • Perfector (The Completer): The module responsible for applying the patch to the target file.
  • Ornator (The Arranger): The module that runs code formatters (like Black and Ruff) on newly patched files.
  • Probator (The Tester): The verification module that runs the project's test suite to confirm the patch's integrity.

Installation

Scriptor is designed as a global command-line tool using `pipx` to ensure it operates in an isolated environment.

Prerequisites

  • Python 3.8+
  • [pipx]
  • [Git] (for the Probator's project root discovery)

Installation Steps

1. Clone the repository from GitHub: git clone https://github.com/IsidoreLands/scribo.git cd scribo

2. Use `pipx` to install the package. This builds the tool and makes the `scriptor` command globally available. pipx install .

3. Create the inbox directory that the Speculator will monitor: mkdir ~/scribo_inbox

Operation

The standard workflow involves running the `speculator` daemon as a background service and using the other `scriptor` commands to perform tasks.

Step 1: Run Speculator as a Service

The recommended way to run the watcher is as a `systemd` user service.

1. Create the service file at `~/.config/systemd/user/scriptor.service`: [Unit] Description=Scriptor Daemon (via Scriptor SDK) After=network.target

[Service] ExecStart=%h/.local/bin/scriptor speculator Restart=on-failure RestartSec=5s

[Install] WantedBy=default.target

2. Enable and start the service: systemctl --user daemon-reload systemctl --user enable --now scriptor.service

You can check its status or view live logs with `systemctl --user status scriptor.service` and `journalctl --user -u scriptor.service -f`.

Step 2: Generate a Patch

As a developer, you have your original file (`guide_main.py`) and a revised version (`guide_v4.py`). To integrate the changes, run the `compara` command: scriptor compara guide_main.py guide_v4.py

The moment the patch file is created in `~/scribo_inbox/`, the `speculator` service will detect it and trigger the full automated pipeline: apply, format, test, and commit or revert.

Development Journal

Version 3.1 (Current)

  • Architectural Unification: All tools have been refactored into a single, unified SDK with a main `scriptor` command and logical subcommands (`speculator`, `compara`, `praetor`, `inceptor`).
  • Enhanced Patching Logic: The core patching engine (`Perfector` and `Comparator`) was completely overhauled to use git-style relative paths, making it vastly more robust and reliable.
  • Hardened Verification: The `Probator` and `Ornator` modules were refined to be more intelligent and fault-tolerant, correctly handling non-Python files and projects without tests.

(For previous versions, see the Git history.)

Roadmap (Future Development)

  • Praetor Fleet Command: Fully implement the `praetor deploy-sensor` command to provision new machines with the System Maneuverability toolset. Integrate the SM and Agentic Maneuverability (AM) scores into the Praetor's decision-making process for intelligent task dispatching.
  • ARC Integration: Bridge the Scriptor SDK with the AetherOS `Navigator` ARC, allowing the ARC to autonomously propose and test patches to its own codebase.
  • Initiative Scaffolding: Evolve the `inceptor` into a full-fledged project scaffolding tool that can bootstrap new initiatives with pre-configured ARCs and best-practice repository structures.

Repository

  • The official source code is hosted on GitHub: [[1]]