Skip to content

mcpx: ResolvedScope plumbing + spawn cwd = resolved scope root #958

Closed

Description

@dezren39

Slice 1 of decision record 0004 (pkgs/mcpx/docs/decisions/0004-scope-resolved-roots.md, PR #957). Design source: dezren39/darwin-nix#817 — this issue carries its acceptance criteria.

What to build (spec §1, §2, §3, §6)

  • internal/config: add ResolvedScope{Key, Root, Degraded} and Scope.Resolve(ctx); Scope.Key becomes Resolve(ctx).Key — one resolution path. Root semantics per spec §1 (worktree → checkout top-level; repo → parent of the common dir only when its base is .git, else no root; cwd → canonical caller cwd; degraded repo/worktree → that cwd; global/session/psession/pid/call → no root).
  • Plumbing: Registry.keyFor switches to Resolve and passes the ResolvedScope into Pool.Acquire; the pool stores the root on the Instance at creation and startLane/dial() read it from the instance (never re-resolved at redial — root is a pure function of the key).
  • Spawn cwd (stdio only): config cwd when non-empty, else the resolved root when non-empty, else unset (daemon cwd, today's behavior).
  • Observability: one spawn log line (server, key, root, cwd source: config/scope/daemon); mcpx status instance JSON gains root.

Acceptance criteria (from nix#817, verbatim intent)

  • A worktree-scoped server with no config cwd spawns with its working directory set to the caller's checkout top-level; a repo-scoped one to the resolved worktree of the common dir.
  • Two callers in different checkouts of the same repo get distinct worktree-scoped instances rooted in their own checkouts; repo scope keeps sharing one instance per common dir.
  • An explicit config cwd overrides the scope root in all cases.
  • global/cwd:/session and other scopes are unchanged.
  • Tests cover the spawn-cwd decision (scope root vs explicit cwd vs daemon fallback) as a pure function, plus degraded-root cases.

(The gopls live-proof criterion from nix#817 belongs to slice 4, which has the full stack.)

Activity

  1. added
    kind/featureNew feature or capability request
    source/humanFiled directly by a human
    priority/normalOrdinary priority (the default)
    effort/mMedium: expected under 1 day of work
    meta/enrichedIntake review done: acceptance criteria, links, and normalized labels added
    on Oct 26, 2026
  2. dezren39 commented on Oct 26, 2026

    @dezren39
    MemberAuthor

    Intake review

    Still live (verified this run): no ResolvedScope exists in pkgs/mcpx on main (local clone at a2eef6f, decisions dir holds 0001–0003 only), and no merged PR mentions ResolvedScope / scope-resolved roots. The design source itself — decision record 0004, PR #957 — is still OPEN, and its branch (commit 43f3e32) is where 0004-scope-resolved-roots.md currently lives. This slice is implementable from that branch, but the record is not on main yet.

    Related: PR #957 (design source, open) · #960 (slice 2, depends on this) · #959 (slice 3, depends on this) · #961 (slice 4, depends on this + #959) · design origins dezren39/darwin-nix#817, dezren39/darwin-nix#818, dezren39/darwin-nix#819.

    Notes / risks: This is the foundation slice — slices 2–4 all key off ResolvedScope and the instance-stored root. The degraded-root and common-dir-base semantics in spec §1 are the easy place to get subtle divergence; the acceptance criteria already pin them as pure-function tests, which is the right shape. Root must be fixed at instance creation and never re-resolved at redial (the body says this explicitly — worth a test asserting it).

    Suggested approach: Land/review PR #957 first (or branch from it), implement Scope.Resolve + plumbing with table-driven tests for the §1 root semantics, then the spawn-cwd decision as a pure function, then the status/log surface.

    — Fleet monitor intake enrichment (acceptance criteria were already in the body; labels normalized, meta/enriched added).

  3. added
    work/assignedQueue worker lifecycle state
    queue/claimedQueue worker lifecycle state
    and removed on Nov 1, 2026
  4. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

    • Agent: queue worker (repo-worker-code), lane E
    • Session / ID: queue task 2292
    • Found via: queue claim
    • Task: Triage mcpx: ResolvedScope plumbing + spawn cwd = resolved scope root #958 (mcpx ResolvedScope plumbing) against current main — verify whether ResolvedScope/spawn-cwd work is already present, then route or close with evidence.
    • Expectation: effort s (triage); done = verdict posted + follow-up packet enqueued or issue closed with evidence
    • Links: queue task 2292
  5. dezren39 commented on Nov 1, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · done

    Triage verdict: CONFIRMED at current main — fix enqueued (task 4872)

    Verified on the laptop clone at origin/main b56ccda (fetched this run):

    • grep -rn ResolvedScope pkgs/mcpx --include='*.go' → zero hits. The type and Scope.Resolve do not exist; only the decision doc pkgs/mcpx/docs/decisions/0004-scope-resolved-roots.md is present (PR docs(mcpx): decision 0004 — scope-resolved roots #957 merged).
    • pkgs/mcpx/internal/config/scope.go:70 still has the old signature: func (s Scope) Key(ctx CallContext) (key string, degraded string) — no root is ever returned.
    • pkgs/mcpx/internal/daemon/registry.go:1396-1398: keyFor returns only that key string into Pool call sites.
    • pkgs/mcpx/internal/pool/pool.go:893,903: dial() builds StdioOptions{Cwd: p.cfg.Cwd} verbatim; internal/mcpclient/stdio.go:110 sets cmd.Dir = opts.Cwd. Spawn cwd is the static config cwd or the daemon's — never the resolved scope root.
    • No root field exists in instance status output (grep over pkgs/mcpx/internal).

    Overlap disposition (#1989): #1989's criteria 1–4 are the spawn-cwd subset of this slice. The task-4872 packet names this explicitly: when the #958 fix lands, #1989 should close as covered (its gopls live-proof criterion belongs to slice 4 / #961). No second fix packet was created for #1989's subset.

    Routing: small_fix packet enqueued as queue task 4872 with the issue's spec §§1/2/3/6 pinned (ResolvedScope + Resolve, keyFor→Pool.Acquire plumbing, root stored on Instance at creation, spawn-cwd decision config > scope root > daemon, spawn log line + root in status JSON, pure-function spawn-cwd tests + degraded cases). Slices #959/#960 remain status/blocked on this slice, correctly.

  6. 141 remaining items

  7. added
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    status/parkedDeliberately paused with a recorded resume condition
    on Nov 2, 2026
  8. dezren39 commented on Nov 2, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · parked

  9. dezren39 commented on Nov 2, 2026

    @dezren39
    MemberAuthor

    agent-note:v1
    task: 4872
    state: parked
    reason: PR #3925 rechecked fresh 2026-11-02T05:06Z — head bdb04b5 unchanged, Codex clean with all review threads resolved per prior checkpoint, but docs build, docs-history, lint, plugin tests and stress checks are all still QUEUED (runner queue delay, no failures).
    resume: merge PR #3925 when checks go green, then complete task 4872 fixed_merged.

  10. added
    queue/claimedQueue worker lifecycle state
    and removed
    status/parkedDeliberately paused with a recorded resume condition
    queue/parkedQueue task is parked (waiting on CI, time, or an event)
    on Nov 2, 2026
  11. dezren39 commented on Nov 2, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · picked up

  12. added a commit that references this issue on Nov 2, 2026
  13. dezren39 commented on Nov 2, 2026

    @dezren39
    MemberAuthor

    🤖 Agent note · done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

effort/mMedium: expected under 1 day of workkind/featureNew feature or capability requestmeta/enrichedIntake review done: acceptance criteria, links, and normalized labels addedpriority/normalOrdinary priority (the default)source/humanFiled directly by a human

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions