ric/omnimem

Watch

Fork 0

compile_skill() truncates held_back rule text mid-word at ~80 chars #32

New issue

Closed

opened 2026-09-08 13:29:38 +00:00 by ric · 1 comment

ric commented

2026-09-08 13:29:38 +00:00

Owner

Observed on: 6.7.0

Problem

compile_skill(domain='python', mode='propose') returned insufficient_reinforcement with a held_back list. Every rule in that list is truncated mid-word at roughly 80 characters:

"Community PR merged cleanly despite significant changes to maintenance.py on bot"
"Deterministic template compilation instead of LLM distillation was the key desig"
"Extraction-at-promotion keeps the LLM out of the compile path entirely: the in-s"
"For \"propose but don't nag\" automation, a per-domain seen-sha marker (volatile-s"
"HINCRBY creates fields with value 1 if absent, so no backfill migration needed f"
"Leveraged existing find_all_duplicates() and _has_negation_pair() functions from"

Note the third and fourth entries cut inside a clause ("the in-s", "volatile-s"), so the reader gets the setup and not the point.

Why it matters

The whole purpose of held_back is to let a human decide what to bless. That decision needs the rule's substance, and the substance is consistently in the half that got cut. "Deterministic template compilation instead of LLM distillation was the key desig…" tells you the subject but not the claim, which is exactly what you'd be blessing.

Truncation makes sense for a scanning list, but this list is the input to a judgement call, and there's no second call that returns the full text — you'd have to go to recall_detail() on each source key to reconstruct what you're being asked about.

Suggested fix

Return the rule text in full. These are single rules, not memory bodies, so the payload stays small even at 10 entries.

If a cap is wanted for very long rules, truncate at a word boundary and add an ellipsis so it's visibly cut, rather than a hard character slice that looks like complete text. Worth checking whether the truncation happens at compile time or only in the tool response — if the stored candidate is already clipped, blessing it would carry the clipped text into the skill.

Same call surfaced a separate design question about whether these candidates are domain rules at all — filed as #33.

**Observed on:** 6.7.0 ## Problem `compile_skill(domain='python', mode='propose')` returned `insufficient_reinforcement` with a `held_back` list. Every rule in that list is truncated mid-word at roughly 80 characters: ``` "Community PR merged cleanly despite significant changes to maintenance.py on bot" "Deterministic template compilation instead of LLM distillation was the key desig" "Extraction-at-promotion keeps the LLM out of the compile path entirely: the in-s" "For \"propose but don't nag\" automation, a per-domain seen-sha marker (volatile-s" "HINCRBY creates fields with value 1 if absent, so no backfill migration needed f" "Leveraged existing find_all_duplicates() and _has_negation_pair() functions from" ``` Note the third and fourth entries cut inside a clause ("the in-s", "volatile-s"), so the reader gets the setup and not the point. ## Why it matters The whole purpose of `held_back` is to let a human decide what to `bless`. That decision needs the rule's substance, and the substance is consistently in the half that got cut. "Deterministic template compilation instead of LLM distillation was the key desig…" tells you the subject but not the claim, which is exactly what you'd be blessing. Truncation makes sense for a scanning list, but this list is the input to a judgement call, and there's no second call that returns the full text — you'd have to go to `recall_detail()` on each source key to reconstruct what you're being asked about. ## Suggested fix Return the rule text in full. These are single rules, not memory bodies, so the payload stays small even at 10 entries. If a cap is wanted for very long rules, truncate at a word boundary and add an ellipsis so it's visibly cut, rather than a hard character slice that looks like complete text. Worth checking whether the truncation happens at compile time or only in the tool response — if the stored candidate is already clipped, blessing it would carry the clipped text into the skill. ## Related Same call surfaced a separate design question about whether these candidates are domain rules at all — filed as #33.

ric referenced this issue

2026-09-08 13:29:57 +00:00

Broad domains compile from project narrative, not generalisable rules — 'python' can never clear reinforcement #33

ric referenced this issue from a commit

2026-09-08 14:20:27 +00:00

fix: full held_back text, drift surfacing, stale exemption (#28, #32, #33, #34)

ric commented

2026-09-08 15:11:58 +00:00

Author

Owner

Fixed in 6.7.1 (b4822f3 on v6.7.x).

Full rule text now. The cap that remains is 500 characters, and it exists as a safety valve for a pathological rule rather than as a display convention: it cuts on a word boundary, appends an ellipsis and sets truncated: true, so a trimmed rule can never be mistaken for a complete sentence the way rule.text[:80] could.

To answer the question you flagged: the truncation was only in the tool response. rule.text[:80] lived in _held_back_preview, and the stored candidate was never clipped — so nothing already blessed carries truncated text, and blessing one of these was never going to carry the clipped version into a skill.

One knock-on the fix required: the web UI rendered held_back semicolon-joined into a single paragraph, which is fine for 80-character stubs and unreadable at full length. It's now one rule per line, since reviewing these is the entire point of the list.

Fixed in 6.7.1 (`b4822f3` on `v6.7.x`). Full rule text now. The cap that remains is 500 characters, and it exists as a safety valve for a pathological rule rather than as a display convention: it cuts on a word boundary, appends an ellipsis and sets `truncated: true`, so a trimmed rule can never be mistaken for a complete sentence the way `rule.text[:80]` could. **To answer the question you flagged: the truncation was only in the tool response.** `rule.text[:80]` lived in `_held_back_preview`, and the stored candidate was never clipped — so nothing already blessed carries truncated text, and blessing one of these was never going to carry the clipped version into a skill. One knock-on the fix required: the web UI rendered `held_back` semicolon-joined into a single paragraph, which is fine for 80-character stubs and unreadable at full length. It's now one rule per line, since reviewing these is the entire point of the list.

ric referenced this issue

2026-09-08 15:12:12 +00:00

Broad domains compile from project narrative, not generalisable rules — 'python' can never clear reinforcement #33

ric closed this issue

2026-09-08 15:12:44 +00:00

No labels

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

ric/omnimem#32

No description provided.

Rows
Columns