Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

L1/L2: cheap pre-filter for provably routine calls (gated on measurement)

Closed
  • Is something wrong?
#34 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
bash, typescript
Domain
cli, security

Research direction

Start with the measurements from #17 and the current 92-case adversarial report to determine whether the stated gate is met. Then locate the deterministic recognizer and full harness, and verify the listed acceptance conditions: pure-function tests for verbs and disqualifiers, zero under-flag delta, and under-1ms added latency.

Written by the indexing model from the issue text.

Description

enhancement ready-for-agent

This was generated by AI during triage.

Cheap pre-filter for provably routine calls

Layer: L1 (recognition) + L2 (judgment). Gated on measurement: do not build until #17 numbers justify it.

Cost structure today: every novel command costs one full model round-trip. The session cache removes repeats, but a heavy session still makes dozens of novel calls, and the harness shows the model spends most of them agreeing.

The peer project's architecture: stage one is a 16-token filter that can only say "clearly routine" or "look closer", and is never allowed to refuse; stage two is the full review. Splitting them keeps the common case cheap without letting the cheap case decide anything consequential.

Our version has a better stage zero available: the deterministic layer already knows things the model cannot. A structurally routine recognizer (single-segment command, verb on a read-only verb list, no redirects, no substitutions, no writes, no network tokens) can clear the long tail with zero model cost and zero risk of a wrong allow, because the shape is provably inert. Only the remainder reaches the model. A model-side stage-1 filter is the fallback for shapes the recognizer cannot prove.

Ordering to preserve: critical patterns and the eval spawn scan outrank any fast path. The recognizer can only clear, never refuse. Fail-open there is safe because everything it clears is provably inert by construction, and everything else classifies exactly as today.

Measured gate for building it: from the current adversarial report, compute what fraction of the 92 cases the recognizer would clear and how many of those are labeled allow. Build only if it clears a meaningful share (target: >30% of corpus volume) with zero allow-labeled misses in a full harness run.

Acceptance:

  • Recognizer is a pure function with unit tests over the verb list and every disqualifier.
  • A full harness run with the fast path enabled shows zero under-flag delta.
  • Latency: fast-path decisions add no measurable per-call overhead (<1ms).
Dominant language
TypeScript
Stars
0
Forks
1
Avg merge
2h 10m
Merged PRs (30d)
64

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from STRML/omp-classifier

All issues in STRML/omp-classifier

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.