skills/ce-pov/references/boundaries.md

# Boundaries and Routing

Load this when the input's fit for `ce-pov` is in doubt, or to route a Hold (SKILL.md Phase 0).

## The discriminator

`ce-pov` takes a **supplied subject** and judges it **against this project**, producing a **decisive position** — not options, not requirements, not implementation, not a diagnosis. If the answer should be a *verdict about your project*, it is `ce-pov`. If the answer is options, requirements, implementation, a diagnosis, or a neutral explainer, route out.

## Where the lines fall

| If the user wants... | Route to | The line |
|---|---|---|
| A neutral explainer ("tell me about X") | `ce-explain` | `ce-pov` only returns a project-grounded verdict; with no project angle, invoke `ce-explain` with the question and intended use rather than forcing a verdict |
| A holistic take on a supplied document ("what do you think of this doc?") | `ce-pov` | A take judges the document's direction, strengths, risks, and bottom line; "review this doc" or "find the issues" asks for findings and routes to `ce-doc-review`. When the wording is ambiguous, resolve it under the skill body's interaction rule |
| A judgment among approaches the user already supplied | `ce-pov` | Options developed → judge against the project; rough options needing development for a defined brief → `ce-bakeoff` |
| Options invented from an open field | `ce-ideate` | Invented vs. discovered: ideate invents; `ce-pov` judges/selects from a discoverable field |
| To scope an idea already chosen | `ce-brainstorm` | `ce-pov` decides *whether*; brainstorm scopes *what* once it's a yes |
| To know how to build something decided | `ce-plan` | Perform a requested handoff only when the Phase 4 authority gate passes; `ce-pov` does no task breakdown |
| To fix observed broken behavior | `ce-debug` | `ce-pov` assesses *exposure and priority* of a CVE; debug investigates an *actual failure* |
| Product thesis / company direction | `ce-strategy` | `ce-pov` is bounded to a specific external input |

## The selection escape hatch

A *selection* question ("what should we use for auth?") is a `ce-pov` verdict only when the realistic candidate field is **bounded** (roughly five or fewer real options) and the **criteria are knowable** enough to judge — the candidates are *discovered* from a real market, not *invented*.

When the field cannot be bounded without inventing options, or the criteria are unclear, **Hold and route out**:

- Defined solution brief, but candidates need concrete development → `ce-bakeoff`.
- Field too open to enumerate → Hold → `ce-ideate` to enumerate the candidates → return the shortlist requirement to the caller.
- Criteria unclear / unstated requirements → Hold → `ce-brainstorm` to surface them → return the missing criteria to the caller.

Running a verdict on an unbounded field turns `ce-pov` into disguised requirements discovery — the escape hatch is what keeps it a judgment skill.

## Universal grounding (designed-in, deferred)

`ce-pov` grounds against the project's available context, and "project" includes a non-code folder (docs, decks, markdown, data), not only a git repo. The only case out of scope is *no local material at all* — a pure user-described situation with nothing to ground against. Treat that as out of scope: return the missing project context under the skill body's interaction rule, rather than dispensing generic advice dressed as a POV.