Intake: choosing the route (LFG step 1)

Read this before choosing the route. It defines the routes, their precedence when more than one matches, what each child skill is invoked with, how its return is read, which routes end the run at the child's result, and what is never a work source. The body's work-source and stop clauses still apply; this file supplies what they cannot decide alone.

What the session identifies

The work source starts from what the invocation and the conversation carry: a feature description, an issue reference, a plan path, a plan ce-plan wrote earlier in this session, a brainstorm artifact, or a handoff the user resumed. A file that exists in the plans directory but that nothing in the session names is not identified. ce-work's blank-invocation intake discovers the newest plan on disk; lfg never invokes ce-work blank, so that path is unreachable from here. When nothing identifiable was given, the route is the plan route with an empty description, which ce-plan answers by asking what to plan when a human is present and by returning blocked when none is.

Routes, in precedence order

Classify from the request and bounded inline reads of what it names, only as far as needed to choose. Grounding depth belongs to the child skills: ce-plan and ce-brainstorm already read the repository and call ce-explain on their own condition. Take the first route that matches.

1. Plan path. The request asks for a plan to be carried out or continued, and names it: a unified plan artifact path, a brainstorm artifact, or a plan ce-plan already wrote this session. A request that only mentions a plan while asking for something else (explain <plan path>, is this plan sound?) is routed by what it asks for, not by the path it carries.
2. A requirements-only artifact, or a path to a plan from an earlier session: invoke ce-plan with it, prefixed by the settled-decisions brief references/plan-brief.md defines. ce-plan enriches or resumes it, checks drift and settled-decision conflicts, and reports it this run. That reported path is the work source.
3. An implementation-ready plan ce-plan wrote in this session: the work source is that plan; step 2 invokes ce-work on it directly. ce-work's intake verifies readiness and prerequisites by content and returns blocked when the plan is not sufficient, which stops the run.
4. Defect. A concrete report of failing or wrong behavior that the request asks to have fixed. A request for the diagnosis alone (explain why this test fails, diagnose #123) is route 5, and ce-debug invoked there under its own contract ends the run with the diagnosis. Whether the failure reproduces is ce-debug's question, not intake's; an intermittent or environment-specific failure is still a defect. It usually arrives as an issue reference (ESP-1234, #123, an issue URL), a stack trace, a failing test path, or a description of broken behavior. A reference alone is not proof: read enough of the ticket to see that it describes a defect; a ticket describing a feature takes route 1 or 6. Invoke ce-debug with mode:return-to-caller <bug>, passing the reference through unchanged so ce-debug treats it as the issue of record. Read references/debug-return.md before reading its return; that file is the gate. Only a fixed return is a work source, and steps 3 onward run from it in place of a plan.
5. Judgment on the way to a change. The request asks for a change to the code and that change depends on a decision the user did not settle: adopting or replacing a named external technology, choosing among supplied approaches, a "should we" attached to a build. A request that asks only for the judgment (should we adopt Redis?, with nothing to build) is route 5, and the run ends with the verdict. Invoke ce-pov with the question and the decision it informs. Adopt, Trial, or a position that supports the request continues to route 4 or 6 with the verdict carried as cited evidence in the brief's direction and open areas, never as a settled decision. Reject, Hold, Not-our-problem, a position against the request, or a Blocked result stops the run with the verdict and its evidence.
6. Product shape unsettled. More than one product behavior is a plausible reading, or a product question no evidence settles. When a human is present (a person can answer in this session: the run is not headless and carries no mode:pipeline; how the host asks, a question tool or numbered chat options, does not matter), invoke ce-brainstorm with mode:return-to-caller <feature description>. Its return carries status, result_kind, artifact_path, brief, resolve_before_planning, and, when a grounding scout ran, grounding_path; pass that path to ce-plan on either continuation so planning starts from the verified evidence. A non-empty resolve_before_planning stops the run with those items. An artifact result enters route 1 as a requirements-only artifact. A brief result enters route 6 as the feature description, with its key_decisions carried in the settled-decisions brief. When no human is present, take route 6: ce-plan in pipeline mode records an unresolved product fork as an explicit assumption in the plan, which the PR body then carries.
7. A result that is not a code change. Match the request to the Compound Engineering skill whose description owns that result, and invoke it with the request as given. Examples: explain the architecture of X is ce-explain; a throwaway prototype to settle how something should work, look, or feel is ce-prototype; a judgment with nothing to build is ce-pov; an open field of ideas is ce-ideate; a session handoff is ce-handoff. The examples are not the list; the host's skill catalog is. When no Compound Engineering skill owns the result, say so and end. A prototype exists to be experienced by a person, so that route runs only when a human is present (the same condition route 4 uses); headless, stop and say the prototype needs a person rather than invoking a skill that must refuse. That invocation is the whole run: end with its result, with no branch, no work source, none of the steps after intake, and no DONE promise, which belongs to the code-change steps. Invoking means running that skill's own procedure from its file; answering in its place, however well, is not the route. The prototype ends the run only when the prototype is what was asked for. When the request also asks for the winner built, the choices ce-prototype returns to its caller are user-directed decisions: carry them in the brief and continue to route 6 with the request. A question that arrived with an issue reference or a plan path is still a question, and route 1 already excludes it; the route is decided by what is asked for, not by what is attached.
8. Plan. Everything else that changes the code. Invoke ce-plan with the feature request, sanitized per references/stage-routing.md when a routing directive was present, and the settled-decisions brief when the conversation carries settled decisions. The plan_model:<alias> carrier rides beside the request when a planning-stage directive resolved. ce-plan's reported plan is the work source once it passes the readiness check in references/plan-brief.md.

When unsure between two routes, take the one that asks more of the evidence: brainstorm over plan when a human is present, ce-pov before either when a change hangs on an unsettled judgment, ce-debug when the report is concrete and asks for a fix, and a prototype only when the request asks for one rather than for the thing itself.

What every child receives, and what none receives

Every child skill receives only its own input: the sanitized request or path, the brief when one exists, and the carrier its stage accepts. No child receives the routing directive as product content. On route 3, ce-pov's verdict reaches ce-plan as evidence, not as a session-settled: decision, because the settled-decisions design allows only user-directed and user-approved provenance and an agent never settles its own recommendation.

Recording the route

Narrate the chosen route in one line before invoking the child, naming the request shape that decided it. On the task surface references/task-visibility.md defines, a route not taken is not listed; the chosen route's child skill owns the surface while it runs.