os-me: run learning in a background agent after predict; stop queue starvation #959

New issue

Open

opened 2026-10-06 00:18:49 +00:00 by jared · 0 comments

jared commented

2026-10-06 00:18:49 +00:00

Owner

Problem

The os-me learning step runs inside the predict fork (Store ENTRY.md step 6). The fork returns its answer as its last message, so Jared waits for learning before he sees a Prediction. To bound that wait, learning/loop.md learns from one quiet session per run. The review-log for 2026-10-05 shows this cap starving newer queue entries all day: the same three unanswered sessions were re-read on every run and newer sessions never got a turn. bin/queue next always returns the oldest quiet session, so the loop has no way to skip a session it has already found to have no JARED: reply.

Reproduce

n/a: design change. Evidence is in ~/dev/os-me-store/learning/review-log.md, rows dated 2026-10-05 that say "The cap still starves".

Approach

In plugins/os-me/skills/predict/SKILL.md, the fork runs predict only and returns. The skill then dispatches learning as a second agent in the background.
Remove the one-session-per-run cap from Store learning/loop.md once learning runs in the background.
Give bin/queue a way to mark a session as checked-with-no-reply so bin/queue next skips it until new invocations arrive for it. The loop then processes the queue oldest-first without re-reading.
Store REQUESTS.md item 3 is marked in progress 2026-10-05; close it when done.

Required work: none beyond the acceptance criteria.

Orchestrator work: Store edits in ~/dev/os-me-store (loop.md, ENTRY.md, REQUESTS.md). Jared ruled 2026-10-05 that Store rule changes need no ADR.

Acceptance criteria

Given /os-me:predict is run, when the Prediction is shown, then the learning step has not yet run in the foreground and runs after in a background agent.
Given a quiet session with no JARED: reply, when the learning loop checks it once, then later runs do not re-read it until new invocations are added for it.
Given several quiet sessions with replies, when the learning loop runs, then it learns from all of them oldest-first, with no per-run cap.

Origin

Trigger: review of the os-me Store cap rules in session b6efb439; the review-log rows dated 2026-10-05 name the starvation.
Improvised this session: none. An agent drafted a skip rule in loop.md; it was reverted because nothing records that a session was already checked.
Chain: newer sessions never learned from ← one-session-per-run cap in loop.md step 1 ← learning runs in the predict fork, ENTRY.md step 6 ← DESIGN (Store REQUESTS.md item 3, ADR-0272).
Root candidate: this ticket.
Where: plugins/os-me/skills/predict/SKILL.md; ~/dev/os-me-store/bin/queue; ~/dev/os-me-store/learning/loop.md
Session: b6efb439-8cdb-41a4-8410-31654f2488f4
Transcript: /home/jared/.claude/projects/-home-jared-dev-cc-os/b6efb439-8cdb-41a4-8410-31654f2488f4.jsonl

## Problem The os-me learning step runs inside the predict fork (Store `ENTRY.md` step 6). The fork returns its answer as its last message, so Jared waits for learning before he sees a Prediction. To bound that wait, `learning/loop.md` learns from one quiet session per run. The review-log for 2026-10-05 shows this cap starving newer queue entries all day: the same three unanswered sessions were re-read on every run and newer sessions never got a turn. `bin/queue next` always returns the oldest quiet session, so the loop has no way to skip a session it has already found to have no `JARED:` reply. ## Reproduce n/a: design change. Evidence is in `~/dev/os-me-store/learning/review-log.md`, rows dated 2026-10-05 that say "The cap still starves". ## Approach 1. In `plugins/os-me/skills/predict/SKILL.md`, the fork runs predict only and returns. The skill then dispatches learning as a second agent in the background. 2. Remove the one-session-per-run cap from Store `learning/loop.md` once learning runs in the background. 3. Give `bin/queue` a way to mark a session as checked-with-no-reply so `bin/queue next` skips it until new invocations arrive for it. The loop then processes the queue oldest-first without re-reading. 4. Store `REQUESTS.md` item 3 is marked in progress 2026-10-05; close it when done. Required work: none beyond the acceptance criteria. Orchestrator work: Store edits in `~/dev/os-me-store` (loop.md, ENTRY.md, REQUESTS.md). Jared ruled 2026-10-05 that Store rule changes need no ADR. ## Acceptance criteria 1. Given `/os-me:predict` is run, when the Prediction is shown, then the learning step has not yet run in the foreground and runs after in a background agent. 2. Given a quiet session with no `JARED:` reply, when the learning loop checks it once, then later runs do not re-read it until new invocations are added for it. 3. Given several quiet sessions with replies, when the learning loop runs, then it learns from all of them oldest-first, with no per-run cap. ## Origin - Trigger: review of the os-me Store cap rules in session b6efb439; the review-log rows dated 2026-10-05 name the starvation. - Improvised this session: none. An agent drafted a skip rule in loop.md; it was reverted because nothing records that a session was already checked. - Chain: newer sessions never learned from ← one-session-per-run cap in loop.md step 1 ← learning runs in the predict fork, ENTRY.md step 6 ← DESIGN (Store REQUESTS.md item 3, ADR-0272). - Root candidate: this ticket. - Where: plugins/os-me/skills/predict/SKILL.md; ~/dev/os-me-store/bin/queue; ~/dev/os-me-store/learning/loop.md - Session: b6efb439-8cdb-41a4-8410-31654f2488f4 - Transcript: /home/jared/.claude/projects/-home-jared-dev-cc-os/b6efb439-8cdb-41a4-8410-31654f2488f4.jsonl

jared added the

project/cc-os

filed-by/agent

labels

2026-10-06 00:18:49 +00:00

jared added the

category/umbrella

label

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

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