Ghost-ALICE OS
Keep the user's goal, repair affected work, and connect each claim to its original evidence.
bash install.sh --addon autopilotRun from the cloned repository. The installer detects available agent platforms. See OS-native commands and platform options.
Core + Ghost-ALICE Autopilot 0.5.1
This documentation describes Core and Ghost-ALICE Autopilot 0.5.1. A local installation is separate from a published release. Ghost-ALICE Autopilot 0.5.1 requires Core 0.5.1 or later.
Core operation
The response model compares the objective with original sources and selects needed work and verification depth. Judgment focus can be micro, meso, macro or meta; verification depth is a separate choice.
flowchart TD
U["User objective and authorization"] --> M["Response model"]
O["Original sources and tool observations"] --> M
M --> V["Compare each claim with originals"]
V --> W["Compare the whole answer with the objective"]
W --> R{"Completion claim or requested authenticated review"}
R -->|Required| C["Core authenticates records and source bindings"]
C --> M
R -->|Routine explanation| M
M --> H["Native host displays the answer"]
H --> U
Necessary long originals and answers remain available. Ghost-ALICE handoffs carry the current conclusion, unresolved conditions and original location needed for the next decision. The model retrieves the original when required. Earlier native messages can still enter subsequent requests; an installed adapter applies supported content selections. Original retention, handoff selection and actual request changes are separate.
When evidence conflicts with a required result, the response model selects a needed correction or investigation. It exposes unresolved conditions and reuses unchanged evidence at its original verification time.
How installing Autopilot extends Core
Autopilot applies Core-authenticated proof separately from selecting current necessary continuation. It checks the approved task, boundary, dependencies and prerequisites, then sends only needed next information and original references. An unmet criterion alone creates no request. A request to the native host and actual execution are separate observations. Installation grants no run authority.
flowchart TD C["Core-authenticated proof"] --> A["Autopilot applies proof and selects eligible continuation"] F["Core-authenticated current necessity and next information"] --> A U["Approved task, boundary, dependencies and prerequisites"] --> A A -->|Necessary ready authorized work| H["Request continuation from the native host"] H --> M["Response model performs authorized work"] A -->|No eligible current work| E["No continuation request"]
Documentation
Practical commands live in repository guides; Wiki provides onboarding and background. English and Korean pages describe the same behavior.
Installation and updates
Platform selection, official/custom addons and managed installation.
Troubleshooting
Status, doctor, pending merges and hook loading.
Uninstall
Remove owned install surfaces while preserving user files.
Session contracts
Intent, work selection, completion evidence and response scope.
Platform compatibility
Installer entrypoints and current platform boundaries.
Skill catalog
Available workflows and their owning references.
Strict audit records access metadata. Skill-evolution reports improvement candidates; applying them requires authorized work. Merge-companion handles preserved local edits.