Scribo (AetherOS): Difference between revisions

Jump to navigation Jump to search
AdminIsidore (talk | contribs)
Created page with "{{Scribo Version|1.1.0}} {{Project Status|Alpha}} '''Scribo''' is a command-line utility designed to intelligently and automatically apply code changes from a revised file to an original source file. It streamlines the development workflow by eliminating the tedious and error-prone task of manual code merging for discrete revisions. It was co-developed by Isidore Lands and the AetherOS architect, Alex. The system is architected as a "diff-and-appl..."
 
AdminIsidore (talk | contribs)
No edit summary
 
Line 1: Line 1:
{{Scribo Version|1.1.0}}
{{Scribo Version|3.0.0}}
{{Project Status|Alpha}}
{{Project Status|Beta}}
'''Scribo''' is a command-line utility designed to intelligently and automatically apply code changes from a revised file to an original source file. It streamlines the development workflow by eliminating the tedious and error-prone task of manual code merging for discrete revisions. It was co-developed by [[User:Isidore Lands|Isidore Lands]] and the AetherOS architect, Alex.
'''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]].


The system is architected as a "diff-and-apply" toolset, consisting of a patch generation script and a background watcher that applies patches automatically.
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.


== Architecture and Philosophy ==
== Architecture and Philosophy ==
The core philosophy of Scribo is to make the revision process invisible and robust. A developer should only need to be concerned with writing the code, not the mechanics of integrating it. Scribo achieves this by:
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:
*   '''Formalizing the Patch:''' Creating self-contained patch files that include all necessary metadata, eliminating ambiguity.
* '''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.
*   '''Automating the Application:''' Using a background file system watcher to apply these patches the moment they are created.
* '''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.
*   '''Ensuring Code Quality:''' Automatically running formatters and linters (like Black and Ruff) on every patched file.
* '''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.
*   '''Learning from Failure:''' Establishing a quarantine system for failed patches, which form the basis of a regression testing suite.
* '''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 ==
The Scribo suite is composed of several specialized tools that form the automation pipeline:
* '''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.
* '''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 the newly patched file.
* '''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 and does not conflict with project-specific dependencies.
Scribo is designed as a global command-line tool using `pipx` to ensure it operates in an isolated environment.


=== Prerequisites ===
=== Prerequisites ===
*   Python 3.8+
* Python 3.8+
*   [[https://pypa.github.io/pipx/ pipx]]
* [[https://pypa.github.io/pipx/ pipx]]
*   [[https://git-scm.com/ Git]]
* [[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 ===
1. Clone the repository from GitHub:
# 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
cd scribo/coniunctor
</code>
</code>


2. Use `pipx` to install the package from the local directory. This will build the tool and make the `scribo-diff` and `scribo-watcher` commands globally available.
# Use `pipx` to install the package. This builds the tool and makes the `compara` and `speculator` commands globally available.
<code>
<code>
pipx install .
pipx install .
</code>
</code>


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


== Operation ==
== Operation ==
The standard workflow involves two components: the patch generator (`scribo-diff`) and the background watcher (`scribo-watcher`).
The standard workflow involves running the `speculator` daemon as a background service and using `compara` to generate patches.
 
=== 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.
 
1. Create the service file at `~/.config/systemd/user/scriptor.service`:
<code>
[Unit]
Description=Scriptor Speculator Daemon
After=network.target
 
[Service]
ExecStart=%h/.local/bin/speculator
Restart=on-failure
RestartSec=5s
 
[Install]
WantedBy=default.target
</code>


=== Step 1: Run the Watcher ===
2. Enable and start the service:
In a dedicated terminal, or as a background process (e.g., in `tmux` or `screen`), start the watcher. It will now monitor the inbox for incoming patches.
<code>
<code>
scribo-watcher
systemctl --user daemon-reload
systemctl --user enable --now scriptor.service
</code>
</code>
The watcher will provide real-time feedback as it processes files.
 
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 ===
=== Step 2: Generate a Patch ===
As a developer, you have your original file (e.g., `project/module/guide.py`) and you have created a revised version (e.g., `/tmp/guide_revised.py`).
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:
 
To integrate the changes, run the `scribo-diff` command:
<code>
<code>
scribo-diff project/module/guide.py /tmp/guide_revised.py
compara guide_main.py guide_v4.py
</code>
</code>


'''What this command does:'''
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.
# Calculates the `diff` between the two files.
# Creates a new patch file inside `~/scribo_inbox/`. The patch file is named with a timestamp for easy tracking (e.g., `20250825-171500-guide.patch`).
# Critically, it embeds the absolute path of the '''original''' file inside the patch, so the watcher knows which file to modify.
 
The moment this file is created, the `scribo-watcher` will detect it, apply the patch, run formatters, and clean up. Your work is done.


== Development Journal ==
== Development Journal ==
This section documents the ongoing development, architectural decisions, and future roadmap for Scribo.
=== Version 3.0 (Current) ===
* '''Thematic Rebranding:''' All components were renamed with authentic Latin terms to create a cohesive and memorable toolset.
* '''Architectural Overhaul:''' Implemented a robust producer/consumer model using a queue and a worker thread (`Operarius`) to handle patch processing.
* '''Test-Driven Verification:''' Introduced the '''Probator''' module, which integrates `pytest` directly into the pipeline, enabling automated regression testing for every patch.
* '''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 (Current) ===
=== Version 1.1 ===
*   '''Architecture Refactor:''' Split the original monolithic `patcher` script into a two-part system: `scribo-diff` and `scribo-watcher`. This enables true background automation and a more robust workflow.
* '''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.
* '''Formalized Patch Format:''' Patches now contain a metadata header specifying the target file path.
*   '''Quarantine System:''' Added logic for the watcher to move failing patches to a `~/scribo_inbox/quarantine/` directory for later analysis.
* '''Quarantine System:''' Added logic to move failing patches to a quarantine directory.


=== Roadmap (Future Development) ===
=== Roadmap (Future Development) ===
*   '''Test Harness Implementation:''' Develop a `pytest` suite that automatically discovers and runs tests against patches in the `quarantine/` directory. This will form the core of the "self-learning" capability, ensuring that once a bug is fixed, it never returns.
* '''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.
'''Conflict Resolution UI:''' For patches that cannot be applied cleanly, develop a simple TUI (Text-based User Interface) that presents the conflicting hunks to the user for manual resolution, similar to `git mergetool`.
* '''Plugin System:''' Allow for custom post-verification scripts (e.g., trigger notifications, deploy to staging).
*   '''Plugin System:''' Allow for custom post-patch scripts. For instance, a user might want to run project-specific tests or trigger a notification after a successful patch.
* '''Remote Inbox:''' Explore options for using a message queue (like RabbitMQ or Redis) as an inbox for distributed development workflows.
*   '''Remote Inbox:''' Explore options for using a shared directory (e.g., on a NAS) or a simple message queue as an inbox, allowing for distributed development workflows.


== 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]]