Positional user-N evidence ids are unstable in the audit log
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- security
Research direction
Start at the evidence builder in index.ts around line 1410 and inspect how real OMP sessions and tests populate message.id or entry.id. Check how those evidence IDs are written to decisions.jsonl by #77; done means fallback IDs remain stable for the same entry without hashing message text, with tests covering any real-session fallback case.
Written by the indexing model from the issue text.
Description
When a user message has no message.id or entry.id, the evidence builder gives it a positional id, user-${index} (index.ts:1410). As the branch grows, the same id names a different message. #77 writes these ids to decisions.jsonl for auditing, and a positional id can't identify a message without the exact branch it was built from.
Real OMP sessions probably always carry an entry id, so this may only affect tests. Check that first. If real sessions can hit it, use a stable id instead, for example a hash of the entry's timestamp and role. Never hash the message text.
Found by the review gate on #77. It predates that PR.
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 1
- Avg merge
- 3h 35m
- Merged PRs (30d)
- 50
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from STRML/omp-classifier
-
Decide whether a coordinator may lift a headless worker's refusal (the trust boundary #68 defers)Openenhancement ready-for-human
Difficulty 5/5 Over a week Newbie friendliness 25/100
STRML/omp-classifier#142 ·
Maintainers usually reply within 1 day
-
enhancement ready-for-human
Difficulty 4/5 3-5 days Newbie friendliness 45/100
STRML/omp-classifier#116 · 8 comments ·
Maintainers usually reply within 1 day
-
enhancement ready-for-human
Difficulty 5/5 Over a week Newbie friendliness 35/100
STRML/omp-classifier#13 · 6 comments ·
Maintainers usually reply within 1 day
All issues in STRML/omp-classifier
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
platformatic/mcp#208 ·
Maintainers usually reply within 1 day
-
🐛 bug
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
margelo/react-native-vision-camera#4211 ·
Maintainers usually reply within 4 days