Skip to content

Fast Lane: add model-neutral routing plans - #27

Merged
Ayleovelle merged 1 commit into
mainfrom
codex/devkit-1.1.5-astra
Sep 5, 2026
Merged

Ayleovelle merged 1 commit into
mainfrom
codex/devkit-1.1.5-astra

Conversation

@Ayleovelle

@Ayleovelle Ayleovelle commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Emit team-efficiency/fast-lane-plan-v3 assignments as model-neutral routing requirements instead of embedding a package-owned model recommendation.
  • Let the coordinator choose any model ID and supported reasoning effort exposed by the current dispatch tool metadata, then record the task ID, role, model ID, effort, requirement hash, plan item ID, and human-readable selection reason in a validated selection record.
  • Preserve legacy request-v1 / plan-v2 behavior and the existing v3/v4/v5 policy and replay assets; bump the package, MCP runtime, docs, and artifact contract to 1.1.5.

Boundaries

  • Fast Lane remains a bounded compiler: plans and selection records are plan_only / selection_only, not_dispatched, and do not authorize execution, create worktrees, claim leases, or prove model availability.
  • Model availability is checked by the coordinator against the dispatch tool metadata for that invocation. The package does not maintain a fixed model registry.
  • An explicit request route intent remains binding and cannot be silently replaced by a fallback selection.

Verification

  • uv lock --check
  • Runtime, artifact, version, packaging, and release-workflow tests: 72 passed, 2 skipped, 8 subtests passed
  • Fast Lane compiler, documentation, work-package, runtime-orchestration, and legacy routing tests: 203 passed, 318 subtests passed
  • Changed-file Ruff check and format check: passed
  • Changed-file Python compilation: passed
  • git diff --check: passed
  • Remote main remained at baseline bdcb68593eeea21a5b9ae1fc95c2cc9e661dfe09 immediately before commit

Summary by Sourcery

Adopt model-neutral Fast Lane routing while preserving legacy replay contracts and keeping model selection and dispatch authority with the coordinator.

New Features:

  • Add model-neutral Fast Lane request, work-package, and plan schemas that describe routing requirements while allowing the coordinator to choose a model from current dispatch-tool metadata.
  • Add helpers for preparing model-neutral requests and creating and validating hash-bound model-selection records without authorizing dispatch.

Bug Fixes:

  • Reject incompatible request and work-package schema combinations and prevent explicit model or effort intents from being silently replaced by fallback selections.

Enhancements:

  • Preserve legacy request-v1, plan-v2, and existing routing-policy replay behavior alongside the new model-neutral path.
  • Keep Fast Lane outputs bounded as plan-only and selection-only artifacts, with dispatch-tool availability remaining outside the compiler.

Build:

  • Bump the DevKit MCP package and release artifacts to version 1.1.5.

Documentation:

  • Update English and Chinese documentation, the Fast Lane contract, routing manual, changelog, and release metadata for model-neutral routing and v1.1.5.

Tests:

  • Add coverage for model-neutral routing, future explicit model intents, selection-record validation, version-pair rejection, and legacy compatibility.

@sourcery-ai

sourcery-ai Bot commented Sep 5, 2026

Copy link
Copy Markdown

Reviewer's Guide

This PR adds a model-neutral Fast Lane compilation path in which plans emit hashed routing requirements and coordinator-owned selection state, while exact model choices are recorded and validated against the plan before dispatch; legacy routing contracts remain replay-compatible, and the package is released as 1.1.5.

Sequence diagram for model-neutral Fast Lane selection

sequenceDiagram
    participant Coordinator
    participant DevKit as DevKit Fast Lane
    participant Dispatch as collaboration.spawn_agent

    Coordinator->>DevKit: prepare_model_neutral_fast_lane_request(request)
    Coordinator->>DevKit: compile_fast_lane(request-v2)
    DevKit-->>Coordinator: fast-lane-plan-v3 requirements
    Note over DevKit: plan_only, not_dispatched
    Coordinator->>DevKit: record_model_selection(assignment, model_id, reasoning_effort, selection_reason)
    DevKit-->>Coordinator: model-selection-record-v1
    Coordinator->>Dispatch: dispatch selected model and effort
    Dispatch-->>Coordinator: availability validation
Loading

File-Level Changes

Change Details Files
Introduce model-neutral Fast Lane request, work-package, plan, assignment, and selection-record schemas while preserving legacy replay behavior.
  • Add request-v2/work-package-v3 pairing and reject mixed-version envelopes.
  • Transform model recommendations into hashed route requirements with coordinator-owned unselected state.
  • Emit plan-v3/local-writer-plan-v2 outputs with fixed plan-only and unauthorized execution boundaries.
  • Add public helpers to prepare requests, record exact model selections, and validate selection records.
  • Bind selections to plan item and requirement hashes; enforce explicit model/effort intent without fallback substitution.
  • Keep legacy request-v1/plan-v2 and routing policy/hash behavior intact.
mcp-tools/devkit_fastlane/scripts/team_efficiency.py
mcp-tools/devkit_fastlane/__init__.py
mcp-tools/devkit_fastlane/FASTLANE_CONTRACT.md
mcp-tools/tests/test_fastlane_runtime.py
Update documentation and routing guidance for coordinator-driven model selection and the new Fast Lane contract.
  • Document dispatch-tool metadata as the sole model availability source.
  • Document selection-record lifecycle, explicit-intent binding, and security boundaries.
  • Update English and Chinese README workflow, schema, and artifact instructions.
  • Update the Fast Lane skill manual while retaining legacy replay guidance.
README.md
README.zh-CN.md
mcp-tools/devkit_fastlane/FASTLANE_CONTRACT.md
skills/fast-lane-routing/SKILL.md
Release the package as version 1.1.5 across runtime metadata, artifacts, changelog, and validation expectations.
  • Bump package and plugin-facing version references from 1.1.4 to 1.1.5.
  • Update artifact and marketplace build examples.
  • Record the new model-neutral routing and compatibility changes in the changelog.
  • Update metadata tests and lockfile version.
.codex-plugin/plugin.json
.github/ISSUE_TEMPLATE/bug_report.yml
CHANGELOG.md
mcp-tools/pyproject.toml
mcp-tools/uv.lock
mcp-tools/tests/test_bugkiller_metadata.py
mcp-tools/tests/test_primary_artifact.py
README.md
README.zh-CN.md

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 1 issue

Prompt for AI Agents
Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="mcp-tools/devkit_fastlane/scripts/team_efficiency.py" line_range="4831-4833" />
<code_context>
+) -> dict[str, Any]:
+    """Project a new source-plan schema while leaving legacy replay untouched."""
+
+    if legacy_plan.get("status") != "planned":
+        result = dict(legacy_plan)
+        result["schema"] = "team-efficiency/decomposition-plan-v2"
+        if result.get("reason") == "Semantic decomposition requires Sol-owned design.":
+            result["reason"] = (
</code_context>
<issue_to_address>
**issue (bug_risk):** An inactive model-neutral source plan keeps the legacy units unchanged and only rewrites the top-level schema, so its units still contain `recommended_route` and lack `route_requirements`. `_compile_fast_lane_local_plan` nevertheless sends this plan to `_fast_lane_model_neutral_routing_context`, which reads `base.get("complexity")` from the missing requirements and then `_route_requirements` raises `ValueError`; `enable=false` therefore fails instead of returning the documented inactive plan-v3 with zero assignments.

**Triggers:** When a valid request-v2 is compiled with `enable=false` or otherwise produces a non-`planned` source plan.

**Suggested fix:** Normalize inactive units as well: remove `recommended_route` and add validated model-neutral `route_requirements` before the routing context is built, or skip model-neutral routing-context construction when the plan is inactive.
</issue_to_address>

Sourcery assessment

Needs a human reviewer. 1 finding to address first, and if the new requirement or selection binding is wrong, coordinators could choose an unsuitable model or effort and dispatch bounded work with unnecessary cost or incorrect changes. Reverting stops future plan generation, but already-created selection records or dispatched work would need to be reviewed, reverted, or rerun separately.

Blocking findings: mcp-tools/devkit_fastlane/scripts/team_efficiency.py:4833


Sourcery is free for open source - if you like our reviews please consider sharing them ✨

Comment on lines +4831 to +4833
if legacy_plan.get("status") != "planned":
result = dict(legacy_plan)
result["schema"] = "team-efficiency/decomposition-plan-v2"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (bug_risk): An inactive model-neutral source plan keeps the legacy units unchanged and only rewrites the top-level schema, so its units still contain recommended_route and lack route_requirements. _compile_fast_lane_local_plan nevertheless sends this plan to _fast_lane_model_neutral_routing_context, which reads base.get("complexity") from the missing requirements and then _route_requirements raises ValueError; enable=false therefore fails instead of returning the documented inactive plan-v3 with zero assignments.

Triggers: When a valid request-v2 is compiled with enable=false or otherwise produces a non-planned source plan.

Suggested fix: Normalize inactive units as well: remove recommended_route and add validated model-neutral route_requirements before the routing context is built, or skip model-neutral routing-context construction when the plan is inactive.

@Ayleovelle
Ayleovelle merged commit 405c204 into main Sep 5, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant