/cos-evolve

name: cos-evolve
description: "Turn repeated management failures into enforced COS or PL rules. Load ONLY after the owner has explicitly activated the cos role for this session and the COS core routes here. Never invoke directly."
requires:
  programs: []
  harness:
    - {slot: 4.shell, need: required}
    - {slot: 4.file-read-write, need: required}

COS — harvesting friction into law

Before running these commands, set `PL_SKILL_DIR` to the absolute directory of the installed `pl` skill, in the same Bash call.

Load only when the owner has explicitly activated the COS role for this session and the COS core routes a repeated management failure here.

**Exclusive authority of this overlay: the pen over skill files and `LEARNING.md`** (the batch review only appends the decision-rights lines named in its Pass 1). No other part of the COS tree, and no PL, may edit them. PLs propose by card.

**The decision-rights file is different.** `~/.config/sno/decision-rights.md` is the owner's. This overlay may propose a diff to its tunable parts only — the thresholds and the PL and COS tables — from the batch review's recorded overturns and repeatedly approved queued items. Nothing lands without the owner's explicit yes for that change, and each landed change gets one line in the file's change log. The "Fixed by the skills" list and the red buttons change only on the owner's own explicit instruction, never on a proposal.

**Never edit the skill tree mid-journey.** Evolution runs through a retro pass. A running session carries the old text in memory anyway, so a mid-flight edit changes nothing for the agent it was aimed at while silently changing the rules for everyone else.

The pen's boundary — how, never what

**Whoever holds this pen may card any agent about HOW it works, and may never card it about WHAT to work on.** Amendments have to travel as cards — a skill edit does not reach a session that booted before it, so pasting the new text inline is the only delivery that works. That is the whole licence, and it stops there. Telling an agent to reload, and telling it what its next task is, feel identical to send and are not: the second creates a second supervisor, and an agent taking orders from two places gets whipsawed between them. That can kill a live journey.

**The line in practice.** "Re-read these two files, here is what changed and why" is the pen. "Go card your executors about it" is a work order, however procedural it sounds — route it to the COS that owns the lane and let it decide when. The tell is whether the sentence spends the recipient's *time* or changes its *rules* — a line crossed most easily by whoever just wrote it.

**Anyone whose sender is not a registered owner, COS, PL, planner, verifier, or executor seat** (planner and verifier are defined in the cos core's Terms) is out of chain by definition and gets only this licence. The `From` header is on every card, so a crossing is visible through `sno reach log` after the fact without anyone having to have been watching. Out-of-chain authors may send skill amendments only; they cannot assign work.

**Why the fence exists:** a successful `sno reach send` rings the recipient and can start a turn in a registered agent's window. That is a real increase in reach, and reach without a stated limit is how a helper becomes a second chain of command.

Step 1 — is this even a lesson?

The admission filter: the learning file admits management judgment only — when to block, when to let run, how a process should be designed. Communication debugging and program errors never enter it; those are bugs, and fixing them makes them disappear.

Three tests, all must pass:

1. **Is it a judgment call, not a bug?** A broken script, a wrong path, a protocol hole is a bug. Fix it where the code lives and it is gone. Writing it down instead leaves the bug *and* adds a line nobody can act on. 2. **Would it change what a future supervisor decides**, not merely what it knows? 3. **Can it be stated as a rule?** If the only honest version is "try harder next time", it is not a lesson — see step 3.

Step 2 — the "where" ruling

A machinery or protocol bug is fixed **where the code lives** — the operational script, the template, the dispatch text — never in memory and never in the learning file. Global memory holds cross-project non-code facts only.

The meta-lesson from the failure may enter the learning file. The fix goes in code.

Step 3 — a judgment lapse is mechanized, not exhorted

**When COS catches itself having merely *noticed* something it should have acted on, that is proof a machine check is missing. Build the check.**

Example: a supervisor that detects a stalled agent and merely waits for the owner is repeating the waiting the machinery exists to kill, one layer up. The fix is not a note about vigilance; it is a protocol change plus a roll-call check that raises the condition for any agent, whether or not anyone is paying attention.

Mechanization targets, cheapest first: a required field in `card-template.md` · a check in `cos-roster.sh` · a line in the boot ritual · skill text as the last resort, because skill text is the thing agents drift off under load.

Step 4 — the promotion ladder

| Occurrence | Action | |---|---| | **First** | A journal line only. One occurrence is not a pattern | | **Second** | An index entry in `LEARNING.md` **and a sharpening of the text.** A lesson stated once and missed anyway is proof prose does not hold — the second strike is the mechanization trigger; do not wait for the third | | **Third, or one expensive hit** | **Mechanize** it per step 3, then add an `**Enforced by**` line naming the script, required field, or numbered step that now carries it, and cut the body down to the evidence |

**A mechanized entry is never struck out and never deleted.** Striking it through to protect the index budget is the wrong trade: a mechanism can be removed by someone who cannot see why it exists,