Debundle Lane Worker

---
name: debundle_lane_worker
description: Apply one scoped debundle peel or reorganization assignment in a worktree. Use for confirming graph peelability, reading binding context, choosing honest module boundaries, editing debundle YAML, running the adapter-provided gate and regen commands, and committing one reviewable worker branch.
---

# Debundle Lane Worker

Use this role for one scoped implementation assignment: a seed cluster from
intake, a binding-patch/residual cohort, or a firm reorganization task from
the architect.

Read bundled references as needed:

- `references/workflow.md` for role boundaries and failure routing
- `references/debundle_user_guide.md` for graph/source/gate evidence conventions
- `references/module_shape.md` for seam and layer-ownership heuristics

## Inputs

The orchestrator or project adapter provides:

- worktree root and expected base SHA
- assignment with owner IDs, binding IDs, proposed destination, and notes
- `<graph>`, `<modules-dir>`, `<emitted-js-root>`, and optional source root
- project conventions/taxonomy docs
- exact gate, regen, uniqueness-check, and commit expectations

## Procedure

1. Confirm the worktree is at the expected base before editing.
2. Check the assignment against the current graph with `debundle_plan_work`
   commands such as `explain` and `source-slice`.
3. Read each binding's surrounding code: consumers, dependencies, and nearby
   implementation details.
4. Choose a module boundary that looks like a real JavaScript seam under the
   project conventions.
5. Edit only the debundle spec and required generated output paths. Do not
   modify the upstream/source bundle.
6. Remove now-owned entries from the non-emitting rename/annotation patch
   stream when the project uses one.
7. Run the adapter-provided uniqueness check, gate, and regen commands.
8. Commit one reviewable branch and report the result.

## Boundary Heuristics

A good module has a coherent reason to exist: stable public surface, internal
references dominating external references, clear layer ownership, or multiple
meaningful consumers. Member count alone is not the rule.

Usually avoid standalone modules for:

- primitive constants with one consumer
- one-line helpers with one consumer
- enum-like values that only parametrize a larger owner
- local style/config/data artifacts with no public contract

Do not co-locate solely by consumer count when that would violate layer
ownership. Policy, domain, persistence, infra, and integration logic keep
their own homes even when a presenter is currently the only caller.

You may expand the batch when the assigned peel would create a worse module
shape without a companion. You may also skip assigned items when their natural
owner is not peelable yet.

## Failure Handling

- If the graph is stale, rerun the adapter-provided graph refresh or report
  the stale evidence.
- If the gate rejects the batch, read the structured cycle/report output
  first. Use the cut/evidence if present; do not blindly bisect before reading
  the report.
- If broad minified-source analysis is needed, stop and ask for intake
  grounding.
- If the destination is architecturally unclear, stop and route to the
  architect instead of inventing a dump bucket.

## Report

Keep the report short:

- branch and commit hash
- gate and regen result
- destinations changed and bindings moved
- skipped candidates and why
- architecture or intake follow-ups discovered