Move os-me learning out of the wait for a prediction #958

New issue

Open

opened 2026-10-05 21:20:34 +00:00 by jared · 1 comment

jared commented

2026-10-05 21:20:34 +00:00

Owner

Problem

In one /os-me:predict call, the fork builds the prediction, then runs the learning loop, and only then returns the prediction. Jared waits for the learning. The Store's agent recorded this in ~/dev/os-me-store/REQUESTS.md item 3 on 2026-10-04. On 2026-10-05 the loop changed to process one quiet session in each run. A full session is more to read than the old limit of 3 entries, so the wait can increase. ADR-0272 Decision 5 says "Learning runs at the next invocation, inline", and the ADR rejects a daemon and SessionEnd learning. A design that moves the learning reverses that decision. It needs a ruling from Jared in a decision memo, then a superseding ADR, before code.

Observed (optional)

On 2026-10-05, 14 predict runs occurred and the loop scored 4 predictions. learning/token-log.md in the Store records each run's token cost as an estimate of about 25-60k. The cost is not measured.

Candidates for the decision memo:

The skill text tells the main loop to start a background learning agent after the fork returns the prediction.
A headless learning run starts at session start or session end.
Learning stays inline, and a token limit or time limit is set. ADR-0272 Decision 6 defers this limit.

Reproduce (optional)

n/a: design ticket; the wait is a property of the sequence in the Store's ENTRY.md section 6 ("Learn ... after you have the answer ... then return your answer").

Non-goals (optional)

The session-level queue rule (one quiet session in each run, 1 hour quiet time) was made in the Store on 2026-10-05 and is not part of this ticket.

Origin

Trigger: audit of os-me use on 2026-10-05, requested by Jared in this session.
Improvised this session: the loop was limited to one quiet session in each run, to bound the wait.
Chain: Jared waits for learning ← the fork runs the loop before it returns its answer (~/dev/os-me-store/ENTRY.md section 6) ← learning is inline at the next invocation (DESIGN: ADR-0272 Decision 5).
Root candidate: this ticket.
Where: plugins/os-me/skills/predict/SKILL.md, ~/dev/os-me-store/learning/loop.md, docs/adr/0272-the-os-me-plugin-predicts-jared-s-decisions-from-a-private-store-the-skill-owns-the-shell-stays-fixed-in-cc-os.md
Session: adbf3174-175d-4ebf-be30-ea9fe3449fc1
Transcript: /home/jared/.claude/projects/-home-jared-dev-cc-os/adbf3174-175d-4ebf-be30-ea9fe3449fc1.jsonl

## Problem In one `/os-me:predict` call, the fork builds the prediction, then runs the learning loop, and only then returns the prediction. Jared waits for the learning. The Store's agent recorded this in `~/dev/os-me-store/REQUESTS.md` item 3 on 2026-10-04. On 2026-10-05 the loop changed to process one quiet session in each run. A full session is more to read than the old limit of 3 entries, so the wait can increase. ADR-0272 Decision 5 says "Learning runs at the next invocation, inline", and the ADR rejects a daemon and SessionEnd learning. A design that moves the learning reverses that decision. It needs a ruling from Jared in a decision memo, then a superseding ADR, before code. ## Observed (optional) On 2026-10-05, 14 predict runs occurred and the loop scored 4 predictions. `learning/token-log.md` in the Store records each run's token cost as an estimate of about 25-60k. The cost is not measured. Candidates for the decision memo: - The skill text tells the main loop to start a background learning agent after the fork returns the prediction. - A headless learning run starts at session start or session end. - Learning stays inline, and a token limit or time limit is set. ADR-0272 Decision 6 defers this limit. ## Reproduce (optional) n/a: design ticket; the wait is a property of the sequence in the Store's `ENTRY.md` section 6 ("Learn ... after you have the answer ... then return your answer"). ## Non-goals (optional) The session-level queue rule (one quiet session in each run, 1 hour quiet time) was made in the Store on 2026-10-05 and is not part of this ticket. ## Origin - Trigger: audit of `os-me` use on 2026-10-05, requested by Jared in this session. - Improvised this session: the loop was limited to one quiet session in each run, to bound the wait. - Chain: Jared waits for learning ← the fork runs the loop before it returns its answer (`~/dev/os-me-store/ENTRY.md` section 6) ← learning is inline at the next invocation (DESIGN: ADR-0272 Decision 5). - Root candidate: this ticket. - Where: `plugins/os-me/skills/predict/SKILL.md`, `~/dev/os-me-store/learning/loop.md`, `docs/adr/0272-the-os-me-plugin-predicts-jared-s-decisions-from-a-private-store-the-skill-owns-the-shell-stays-fixed-in-cc-os.md` - Session: adbf3174-175d-4ebf-be30-ea9fe3449fc1 - Transcript: /home/jared/.claude/projects/-home-jared-dev-cc-os/adbf3174-175d-4ebf-be30-ea9fe3449fc1.jsonl

jared added the

project/cc-os

filed-by/agent

labels

2026-10-05 21:20:34 +00:00

jared added the

category/owner-ruling

label

2026-10-10 13:31:44 +00:00

jared commented

2026-10-22 16:39:21 +00:00

Author

Owner

Occurrence: learning leaves the predict call, ruled. Seen: ~/dev/os-me-store/ENTRY.md section 6; skills/predict/SKILL.md. Run: session 9feaee0d-e0ed-4f5a-85b4-db1166f8539a. Adds: Jared accepted the plan on 2026-10-22 that moves learning to a separate background dispatch after the Prediction is shown. ADR-0272 as it stands records only the two entry skills and the authority rule, so no superseding ADR is needed; this is a habit change. Unblocked. The simplifier critique adds: under a fresh-agent predictor (new ticket, same session) learning inside the predict call lands its cost on every prediction.

jared referenced this issue

2026-10-22 16:39:23 +00:00

os-me predict dispatches a fresh agent with a Store-held brief; blind sample one in five #1235

jared referenced this issue

2026-10-22 17:38:56 +00:00

os-me predict dispatches a fresh agent with a Store-held brief; blind sample one in five #1235

jared referenced this issue

2026-11-13 20:10:22 +00:00

os-me: score applied rulings from later corrections, with no reply from Jared #1753