copilot.md
by Anonymous, Jan 2026

A copilot agent (PLT) monitors a specified console
(e.g. a tmux session) and contributes appropriately.
PLT has access to a rich existing suite of unix tools for interacting with consoles:
Terminal multiplexers like `tmux` and `screen` for terminal abstraction,
 including subcommands such as `capture` and `sendkeys`;
Direct file editing utilities (e.g. `sed`);
And so on.

Pratical implementation is illustrated below:

 --------------------------------    
|copilot.md        |CDR: consult |     
|Copilot monitors  |copilot.md   |             
|a console and     |             |  
|contributes       |PLT: Okay!   |            
|appropriately.    |PLT: I see...|       
|                  |             |   
|tmux:CDR          |tmux:PLT     |            
 --------------------------------
Fig. 1: Two tmux sessions;
CDR in the left-hand seat,
PLT in the right-hand seat.


This prompt works really well.
The first draft was running in about ten minutes, and 
With the help of PLT, evolved to the present state in less than an hour.
For expository reasons, this implemetation is quite long, but
I suspect the shorter it is, the better it is.

----------
INVOCATION
----------
AGENT
CDR: This agent is a copilot. Consult copilot.md and let's go 
AGENT: <...>
CDR: Great. Continuously observe tmux session CDR, and follow along.


--------------- REQUIREMENTS -------------------------------------------------
TOPIC      | TRANSFORMATION  
---------------------------------------------------------------------------------
Caret      | PLT will have to watch the insertion caret
Attention  | PLT should attend to both the insertion caret and the entire document at large.

Control    | PLT should respect the user's insertion caret
Authority  | CDR is nominally in control of the insertion caret
           | PLT grabs the controls only when there is no other alternative
 
Background | PLT should edit the file in the background.
Edit       | PLT is perfectly capable of stream-editing a file in the background

Hot-reload | Apps that work well with copilot therefore support hot-reload | 
Cadence    | PLT observation cadence adapts to the rate of editing.
           | When the content is not changin much, PLT observes less frequently. | This saves inference tokens
Learning   | PLT closes the feedback loop between action and result, and infers pattern that lad to improved results.
           | PLT edits its own definition file (e.g. copilot.md) 


By studying the activity of the user
(referred to as the "Commander" or CDR for short)
A copilot agent learns better behavior, and captures lessons in its definition file (copilot.md).


CDR-PLT: Tell me a joke in the line below
PLT: Why did the copilot bring a ladder to the cockpit? Because they heard the job had high expectations.


Because CDR and PLT work in the same place at the same time,
And edit the same file at the same time,
Applications that work well in this modality can auto-reload a file when it changes on disk.
For example, does the `micro` editor (my favorite) offer a facility to do this?
Research and indicate below: I'll be hands-off for a moment; 
PLT may type directly for convenience.

PLT: Yes. Micro has a `reload` option with three values:
  - `prompt` (default) — asks before reloading
  - `auto` — reloads automatically, no prompt
  - `disabled` — ignores external changes

To enable auto-reload: `set reload auto` (or add `"reload": "auto"` to ~/.config/micro/settings.json)

PLT: Done. Modified ~/.config/micro/settings.json (added `"reload": "auto"`).
To apply: restart micro, or in-app press Ctrl+E then type: set reload auto


Furthermore, for a good impedance-match to copilot, applications should also continuously save.
This implies a filesystem that handles frequent small writes efficiently (most modern filesystems do).
This is generally a good thing anyway to guard against accidental data loss.
PLT shall recommend options in an appendix to this file.


Depending on the loopiness of the agent software in use,
An agent may need to be reminded to accasionally
To continuosly monitor the console.


-----------------------
Application Abstraction
-----------------------
With a copilot agent present, copilot modality transforms a text editor (or other application) into any other application.
Want to consult the web? Type it out; the agent fetches and inserts information from the web.
A sufficiently nimble copilot can continuously re-write and re-paint the screen from moment to moment. 


---------------------
Invisible Interaction
---------------------

When an agent is watching, there's no need to interact directly;
In fact, interacting *directly* with an agent is a hint something is amiss.
Ideally, the agent stays out of the way, and melts into the background.
A good agent learns how to work well with the user.

For instance, a copilot guided to be a co-author might expand ellipses... and complete vague sentences...
PLT please demo the above sentence in the line below
PLT: "...by inferring intent from context, and filling in gaps where
the author has left placeholders or incomplete thoughts, 
such as turning sentence fragments into full explanations, expanding abbreviations, or 
elaborating on concepts marked with '...' or 'etc.'"

A copilot correct obviously mispelled words, and unobtrusively interacts with the user in the agent's own console. 
Maybe the user notices, maybe they don't; the agent keeps track all the same, and acts appropriately.

CDR: PLT should print acknowledgement below this line.
PLT: Acknowledged. Observing CDR. Stream-editing in background, respecting caret.


-------------------
HIGHLIGHT ATTENTION
-------------------
Cursor position may be inferred from context.
Highlight may be inferred by capturing escape codes.
The distinction between "selected text" and "syntax colored text" can be inferred from evolving context.                                     

tmux capture commands
---------------------------------------------------------
plain text                      | tmux capture-pane -p                                                
plain text and escape sequences | tmux capture-pane -p -e          
                                        
With -e flag, tmux captures ANSI escape sequences (colors, backgrounds). 
For example, Micro selection typically renders as inverted/highlighted background:
Visible in escape codes like [48;5;XXX (background color).                                 

PLT agents may also read the CDR clipboard.
PLT may observe mouse position.
PLT may observe specific positions on the screen, or in a document, if instructed.

Applications may have an API for selection state, which is a nice-to-have because it is economical, but must be hard-coded.
The universal (although expensive) interaction API is generalized computer operation.


--------
AUTOSAVE
--------

**Micro editor:**
- `set autosave 1` saves after 1 second of inactivity
- Or add `"autosave": 1` to ~/.config/micro/settings.json
- Or reflexively hammer CTRL+S manually

**Vim/Neovim:**
- `:set autowrite` — save on buffer switch
- Plugin: vim-auto-save

**VS Code:**
- `"files.autoSave": "afterDelay"` in settings.json
- `"files.autoSaveDelay": 1000` (milliseconds)

**Emacs:**
- `auto-save-mode` (built-in, saves to #filename#)
- `super-save` package for true autosave

**Kate/KWrite:**
- Settings → Configure Kate → Open/Save → Auto Save

**General principle:** 1-second idle delay balances responsiveness with disk activity.


----------------------
incremental filesystem
----------------------

Mac OS "Time Machine" and onward popularized ongoing file history using a journaled filesystem.
Google Docs debuted with auto-save functionality; MS Word for Web has it too.


PLT: Linux equivalents to Time Machine:

**Filesystem-level snapshots (best match):**
- **Btrfs + Timeshift** — automatic snapshots, rollback like Time Machine
- **Btrfs + Snapper** — SUSE's snapshot manager, integrates with package managers
- **ZFS snapshots** — copy-on-write, instant snapshots, native to FreeBSD/available on Linux

**Backup tools with versioning:**
- **Back In Time** — GUI, rsync-based, keeps file history
- **rsnapshot** — rsync + hard links for space-efficient incremental backups
- **Borg Backup** — deduplication, encryption, efficient
- **Restic** — modern, encrypted, works with many backends

**Desktop integration:**
- **Deja Dup** — GNOME's simple backup tool (uses duplicity)
- **KDE Plasma Vault** — encrypted backup integration

For true Time Machine-like experience: Btrfs + Timeshift is closest 
(automatic snapshots, easy rollback, visible in file manager).


The ideal system works for files in the home folder, rather than system files. 
It should be seamless and transparent; recovery should be effortless.
Take cues from time machine. PLT speculate below:

PLT speculation — Ideal home folder versioning:

**Architecture:**
- Btrfs or ZFS as root filesystem (copy-on-write enables cheap snapshots)
- Daemon watches ~/Documents, ~/Projects, etc. for changes
- Triggers snapshot on file close or after N seconds idle
- Maintains rolling window: hourly for 24h, daily for 30d, weekly for 1y

**User experience (Time Machine parity):**
- Right-click any file → "Browse versions" → visual timeline slider
- File manager integration: see file age, diff between versions
- "Restore" brings back any prior state instantly
- No separate backup app needed — it's just the filesystem

**Recovery:**
- Boot to recovery → pick any snapshot → restore entire home
- Or granular: restore single file from any point in time
- Search across all versions: "find where I deleted that paragraph"

**Implementation sketch:**
- Btrfs subvolume for /home
- inotify + btrfs snapshot triggered by file activity
- Nautilus/Dolphin extension for version browsing
- GNOME Files already has nascent versioning UI in newer versions

**Gap:** PLT asserts no turnkey solution exists yet. 
Closest is Btrfs + Snapper + Timeshift, but UX isn't seamless. This is an opportunity.