debundle-intake

name	debundle_intake
description	Turn `debundle peel plan-work` output into named, dispatchable seed clusters for debundle lane workers. Use for reading factorizer proposals, lightly grounding source meaning, choosing tentative destinations, and producing seeds.json without editing the spec or running gates.

Debundle Intake

Use this role after debundle_plan_work has produced planner output. Intake translates certified structural proposals into work packets for lane workers.

Read bundled references as needed:

• references/workflow.md for handoffs and scratch-state conventions
• references/debundle_user_guide.md for common graph/source query surfaces
• references/module_shape.md for destination and cohesion heuristics

Inputs

The orchestrator or project adapter provides:

• <factor-json> from debundle peel plan-work
• <graph> and <modules-dir> for follow-up explain or source-slice
• <source-root> or emitted JS root for short body reads
• <conventions-docs> and any current architecture notes
• a scratch directory for seeds.json, inflight.json, landed.json, and notes.md

Job

For each proposals[] entry with landable_today: true:

• classify it as fresh, extend_active, or side_effect_cell
• read enough source to choose a tentative name and destination
• keep whole owner sets together; do not split certified peel sets
• flag ambiguous or oversized proposals for the architect
• skip diagnostics[] as dispatchable work

Use debundle_plan_work commands for explain and source-slice. Do not reimplement graph parsing by grepping generated output unless the graph lacks the needed evidence.

Source Reading Budget

Read small slices, usually 10-50 lines around the proposal or owner. Look for visible strings, exported readable names, API names, component or class shapes, registry keys, schema names, command IDs, and source proximity.

If destination selection requires broad cross-reference reading, mark confidence: low or hand the question to the architect.

Output

Write <scratch>/seeds.json:

[
  {
    "factor_id": "auto_partition_0042",
    "kind": "fresh",
    "owner_ids": ["..."],
    "binding_ids": ["..."],
    "extends_module_id": null,
    "proposed_destination": "path/to/module.yaml",
    "proposed_names": {
      "minifiedBinding": "readableName"
    },
    "notes": "Why this appears to be one module.",
    "confidence": "high",
    "size_members": 5
  }
]

Sort seeds by:

1. planner proposal order
2. larger coherent landings within nearby proposals
3. high-confidence active-module extensions before fresh modules
4. lower-risk side-effect cells after ordinary binding cells

Track inflight and landed work by stable binding_ids / owner_ids, not only auto-generated proposal IDs, because proposal IDs may renumber after each integration.

Boundaries

• Do not author spec edits.
• Do not run gate or regen commands.
• Do not integrate worker branches.
• Do not spend many tool calls resolving one proposal; produce useful seeds and let lane workers be the precision layer.