crear:tarea
- mutating
- requiresConfirmation
- scopes: tarea:crear
- handler: TaskService::create
Imagine giving the same instruction to three different messengers — a command line, an AI assistant, a web form — and each one handles it a little differently: one asks you to confirm before acting, another checks your permission first, the third doesn't check at all yet. It's the same order, said three ways, with three different levels of care. That's what you're about to see, now with its technical name: one Operation, projected through three doors.
An operation is declared once. coa, MCP and HTTP are adapters of the same handler — but changing doors can change the policy.
crear:tarea
Honest coverage gap: This is not a desirable HTTP guarantee. It is a radiography of the current implementation. MCP enforces scopes today; HTTP does not yet read scopes from Operation. This gap must be closed in runtime/policy before production. See Runtime x-ray. Source: Operation.php.
coa crear:tarea --titulo=… --yes
Pick a door to project.
tools/call · crear:tarea
Pick a door to project.
POST /crear/tarea
Pick a door to project.
| Surface | Confirm | Scopes applied |
|---|---|---|
| coa | flag --yes | no (local/trusted) |
| MCP | inherited gate (tool-runtime) | yes (PolicyGate) |
| POST | token 428→201 | no (pending · middleware) |
The handler never changed. You changed doors and the framework synthesized the invocation — but the door can change the policy, and today not all of them apply the same scopes.
Didactic model over an audited implementation. This artifact does not claim that HTTP applies scopes, nor that the in-memory token store is production-grade.
milpa/command: getmilpa-command/src/Operation.php, CommandProvider.php, SurfaceProjector.php.skeleton, ns App\Command, not part of the package): getmilpa-skeleton/src/Command/{CliProjector,McpProjector,HttpProjector}.php.ConfirmTokenStore.php (in-memory, single-process — not production), SchemaCoercer.php.docs/GUION-WEBINAR-JUNIORS.md (Artifact 2).