Document production autoresearch patterns for ZeroAPI policy tuning

[AytuncYildizli]

Summary

• add a detailed reference doc describing how Mahobrain uses autoresearch across Mahmory, skill routing, and tweet quality
• explain which parts map well to ZeroAPI and which should stay out of scope
• link the new doc from the main README

Why

ZeroAPI already has a clean runtime routing boundary. This doc gives a concrete, production-grounded pattern for how offline policy tuning can evolve threshold and provider-bias logic without coupling runtime routing to a live optimizer.

Testing

• reviewed README link locally
• reviewed new markdown doc locally

[dorukardahan]

Thanks for the reference — taking the autoresearch concept and implementing it directly into the routing policy layer instead of keeping it as a standalone doc.

[dorukardahan]

Hey, sorry for closing this too fast — I misread the intent. You're right that this pattern is directly relevant to ZeroAPI.

While reviewing your doc, I went ahead and made the plugin constants configurable so they can actually be tuned without code changes:

• vision_keywords and risk_levels are now config-driven in zeroapi-config.json (previously hardcoded in TypeScript)
• Added scripts/eval.ts — reads routing logs and reports category distribution, risk rate, provider diversity, and gives tuning suggestions
• Added a "Policy Tuning" section to SKILL.md with the measure → experiment → promote workflow

Your doc would pair well with these changes. Could you trim it down to focus on the parts most relevant to ZeroAPI? Specifically:

1. The skill-routing lane section is the closest sibling to what ZeroAPI does — keep that detailed
2. The framework shape and guardrails sections are useful as-is
3. The tweet-quality and Mahmory internals sections could be shortened or dropped since they're less applicable here
4. The hardcoded date ("On April 10, 2026, the latest Mahmory run completed") should come out

Also if you want, you could reference the new scripts/eval.ts and the tunable config fields in your doc's "What ZeroAPI can borrow" section — since those now exist, it's no longer hypothetical.

Let me know if this works for you or if you'd rather take a different direction.

[dorukardahan]

Update: I also ran this through Codex CLI (codex review --uncommitted) for a second opinion. It caught several real bugs that I've now fixed on main:

Fixed (from Codex review):

• P1: Regex crash on special chars — Category keywords like c++ would crash routing (Invalid regular expression). Now escaped with the same escapeRegex() used for high-risk keywords.
• P1: Config validation — vision_keywords and risk_levels had no runtime validation. A malformed config like vision_keywords: "image" (string instead of array) would crash on .some(). Added type guards in isValidConfig().
• P2: Eval no-override metric — The eval script lumped high-risk blocks, no-keyword-match, and no-switch-needed into one bucket. Now reports them separately so tuning suggestions are accurate.
• P2: Reason field parsing — Changed from \S+ to .+$ so multi-word keywords aren't truncated in the eval report.
• P3: Node formatting — Replaced %-15s %4d (not supported in Node) with proper padStart/padEnd.
• Vision false positives — UI substring matching build a CLI tool → switched to word-boundary regex matching.

All 51 tests pass. The policy tuning infrastructure is ready — your doc would be a great companion to explain the pattern behind it.