Repository navigation
fix(OMN-14000): migrate 6 nodes' handler_routing to the nested contract schema - #1631
Conversation
…ct schema Ratchet burn-down batch #1 (missing_handler_routing, the ratchet-canary's #1 target). The arch_handler_contract_compliance gate (onex_change_control/src/onex_change_control/scanners/handler_contract_compliance.py) only recognizes the nested `handler_routing.handlers[].handler.{name,module}` schema; these 6 nodes were still on the legacy flat `handler_class`/ `handler_module` string schema and false-flagged as missing_handler_routing. Adds the nested `handler:` block (and `routing_strategy: operation_match` where absent) as a purely additive sibling to each existing handlers[] entry — every existing key/value/comment is preserved unchanged, nothing removed. Nodes: node_adr_canary_orchestrator, node_adr_document_ingestion_effect, node_kb_adr_publisher, node_kreuzberg_parse_effect, node_memory_lifecycle_orchestrator (3 handler entries), node_persona_lifecycle_orchestrator (2 handler entries). 4 of these 6 fixes (kb_adr_publisher, kreuzberg_parse_effect, memory_lifecycle_orchestrator, persona_lifecycle_orchestrator) were generated by the LOCAL delegate tier (Qwen3.6-35B-A3B via `.201`, `onex delegate --task-type document`) — 4/4 first-try, gate-verified, no cloud escalation. This is the flagship local-first proof for the ratchet burn-down lane (OMN-14000): mechanical, self-grading-oracle tech debt reduced by a local model, not a frontier one. Gate-verified: `python -m onex_change_control.validators.arch_handler_contract_compliance --repo-root omnimarket` — Compliant 336 -> 344 (+8 handler files), New violations 95 -> 87 (-8), Total handlers unchanged at 431. No new violations introduced. OMN-14000
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 51 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
✅ Architectural Review — PASSEDErrors: 0 What this checks
No architectural violations found. Powered by node_pr_review_bot |
✅ PR Review Bot — CLEANFindings: 0
Verdict semantics
Powered by node_pr_review_bot — Qwen3-Coder-30B reviewer + DeepSeek-R1 judge (OMN-7963) |
…baseline gate state-coverage-gate (scripts/validate_state_coverage.py, OMN-13781) grandfathers pre-existing uncovered declared-event-topic debt via scripts/validation/state_coverage_baseline.txt, but revokes the grandfather clause in --strict mode for any node DIRECTLY TOUCHED by a diff. All 4 of node_adr_canary_orchestrator, node_adr_document_ingestion_effect, node_memory_lifecycle_orchestrator, and node_persona_lifecycle_orchestrator are pre-listed in that baseline with genuinely uncovered output topics (unrelated to handler_routing) — touching their contract.yaml for the missing_handler_routing fix un-grandfathers that separate debt and fails CI. Fixing that properly means adding real test coverage for those declared topics — out of scope for a small, revertible ratchet-type batch (touches a DIFFERENT ratchet: declared-state test coverage, not handler_routing). Revert these 4 back to the legacy flat handler_routing schema for this PR; keep only node_kb_adr_publisher and node_kreuzberg_parse_effect, which have no state-coverage-baseline coupling and gate-verify clean on their own. Filed OMN-14009 to track the 4 deferred nodes + the general coupling risk for future missing_handler_routing batches.
|
| Verdict | Meaning | Blocks merge? |
|---|---|---|
passed |
No critical/error findings | No |
blocked |
CRITICAL or ERROR findings found | Yes |
degraded |
All models unavailable (infra) | No (pilot) |
Powered by omniintelligence.review_pairing.cli_review — node-based adversarial review via HandlerLlmCliSubprocess (OMN-8524)
Summary
Ratchet burn-down batch #1 (
missing_handler_routing, the ratchet-canary's #1 target, epic OMN-13976 WS-M). Thearch_handler_contract_compliancegate only recognizes the nestedhandler_routing.handlers[].handler.{name,module}schema; these nodes were still on the legacy flathandler_class/handler_modulestring schema and false-flagged asmissing_handler_routing.Adds the nested
handler:block (androuting_strategy: operation_matchwhere absent) as a purely additive sibling to each existinghandlers[]entry — every existing key/value/comment is preserved unchanged, nothing removed or reordered.Nodes (final scope, see note below):
node_kb_adr_publisher,node_kreuzberg_parse_effect.Scope note — 4 nodes deferred (state-coverage-gate coupling)
This batch originally also fixed
node_adr_canary_orchestrator,node_adr_document_ingestion_effect,node_memory_lifecycle_orchestrator, andnode_persona_lifecycle_orchestrator. All 4 are pre-listed inscripts/validation/state_coverage_baseline.txtwith genuinely uncovered declared output topics (unrelated to handler_routing) —state-coverage-gate's--strictmode un-grandfathers that debt for any node directly touched by a diff, so touching theircontract.yamlfor the handler_routing fix failed CI on an unrelated, pre-existing gap. Reverted those 4 out of this PR to keep it small/single-ratchet-type; filed OMN-14009 to track the deferred fix (needs real test-coverage work, not mechanical) + the general coupling risk for futuremissing_handler_routingbatches.Local-first dogfood proof
Both fixes in this PR were generated by the local delegate tier (Qwen3.6-35B-A3B via
.201,onex delegate --task-type document) — 2/2 first-try, gate-verified, no cloud escalation. This is a flagship proof for the local-first ratchet burn-down lane (OMN-14000): mechanical, self-grading-oracle tech debt reduced by a local model, not a frontier one. Each generated YAML block was verified byte-for-byte correct (preserved every existing field, comment, and value) before being applied.Verification
python -m onex_change_control.validators.arch_handler_contract_compliance --repo-root omnimarket->Total handlers: 431 / Compliant: 336 / New violations: 95Total handlers: 431 / Compliant: 338 / New violations: 93— +2 compliant, -2 violations, zero new violations introduced.tests/nodes/node_kreuzberg_parse_effect/,tests/integration/node_kb_adr_publisher/— 15 passed.ruff format --checkclean,ruff checkclean,mypy --strictclean (2693 files), fullpytest tests/ -v(no-k): 12116 passed, 5 failed + 1 error — pre-existing, infra-dependent (Postgres/Kafka unavailable locally), same as origin/dev baseline.OMN-14000
Evidence-Source: OCC#3643
Evidence-Ticket: OMN-14000