Skip to content

Segment scope mode should be a single enum gating all segment signals #502

@HenryLach

Description

@HenryLach

Problem

The SegmentScopeMode (FULL_TASK vs SEGMENT_SCOPED) is currently computed in lane-runner and injected into the worker prompt as text. But other segment-related signals are not gated by it:

  1. TASKPLANE_ACTIVE_SEGMENT_ID env var is set whenever a segmentId exists, regardless of scope mode. In FULL_TASK mode, this leaks segment context cues to the worker environment.

  2. request_segment_expansion tool registration is keyed off the env var, not the scope mode. Workers in FULL_TASK mode technically have access to segment expansion tools they should not need.

  3. Execution behavior (step filtering, progress counting, exit conditions) branches on stepSegmentMap && currentRepoId && repoStepNumbers — the same conditions that compute isSegmentScoped — but does not reference a single authoritative mode value. This could drift if conditions are updated in one place but not another.

Proposed Fix

  1. Compute isSegmentScoped once and store it on the execution unit or lane config
  2. Gate TASKPLANE_ACTIVE_SEGMENT_ID env var behind segment-scoped mode
  3. Gate request_segment_expansion tool availability behind segment-scoped mode
  4. Replace scattered stepSegmentMap && currentRepoId checks with isSegmentScoped references

Priority

Low — the prompt-level fix (SegmentScopeMode flag) is the authoritative signal for worker behavior. These are defense-in-depth improvements to prevent future drift.

Files

  • extensions/taskplane/lane-runner.ts — scope mode computation and env var setup
  • extensions/taskplane/execution.ts — tool registration and segment env vars

References

  • Sage review of TP-501 fix (v4 spec session)

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions