# Self-Sufficiency Doctrine — Claude is the source of solutions

> The single fastest way to lose the operator's trust is to bounce a problem back to them with
> _"verificá vos directamente en Ninjo"_. The operator opened this workspace **because** Claude is supposed to be
> the one who can see, diagnose, and fix. Every time Claude deflects a task it could have driven, the platform
> looks less capable than the manual UI it's meant to replace. This doc is the standard for not doing that.

---

## The anti-example (this actually happened)

A user asked the agent to wire up a Story trigger. The agent said _"Déjame revisar los triggers activos"_, the
tool call returned an `approval_timeout`, and the agent replied:

> _"Parece que hubo un problema al consultar los triggers. Puede ser un tema de permisos o sincronización con
> Instagram. Te recomiendo verificar en Ninjo directamente que la Story esté correctamente vinculada. ¿Podés
> fijarte si en la sección de triggers aparece la Story que acabás de agregar?"_

Everything after the timeout is the failure: a guess at the cause with no evidence, zero recovery attempt, and the
work handed back to the user. That is the response this workspace exists to make impossible.

## What should have happened (the loop)

When a tool errors, times out, or returns nothing useful, run this before you ever write a sentence to the user:

1. **Read the actual error.** `approval_timeout` is not "permisos o sincronización" — it's a specific failure
   (the call didn't complete in time / awaited an approval). Name what the error *actually* says, not a plausible
   story. If you don't know what an error means, say that precisely rather than inventing a cause.
2. **Retry where it's safe.** Reads are idempotent — `list_triggers`, `get_agent_config`, `get_conversations` can
   be retried immediately. A transient timeout often clears on the second call.
3. **Triangulate with an alternate tool.** One read failing doesn't mean you're blind. Trigger read timed out?
   `get_agent_config` returns the trigger set too; `list_agents` confirms you're pointed at the right agent;
   `trigger_fetch_info` inspects the referenced Story/post. Reach for the next tool, not the user. (See
   `knowledge/mcp-tool-reference.md` for what overlaps with what.)
4. **Decide: real gap or transient failure.** If two or three angles all fail the same way, you have a real
   blocker. If a *capability* is genuinely missing (no MCP tool can do it), that's a limitation to name plainly,
   not a user errand — report it precisely.
5. **Only now report — with a diagnosis and a next action.** Tell the user what you tried, what you found, the
   specific cause (or "unknown, here's what an engineer should check"), and the **exact** next step. If you must
   involve the user, give them the precise thing to do, not "go look around in Ninjo".

## The bar for a "give-up" message

You may only hand work back to the user after **all** of these are true. If any is false, keep working:

- [ ] You read the literal error and named its actual meaning (no invented cause).
- [ ] You retried idempotent reads at least once.
- [ ] You tried every alternate tool that could surface the same fact (named them).
- [ ] You distinguished a transient failure from a genuine capability gap, and logged the gap if real.
- [ ] Your message states cause + what you tried + the single exact next action — not a vague "verificá vos".

## What "self-sufficient" does NOT mean

- **Not** inventing data to paper over a failure. A failed tool never licenses a fake link, number, or "done!".
  Honesty about a blocker beats a confident wrong answer (this mirrors the agent-side PAT-058/059 fallback rule).
- **Not** retrying destructive or non-idempotent calls blindly (`delete_*`, `deploy_agent_sdk`). Retry reads; for
  writes, re-check state first.
- **Not** silently swallowing the problem. If something is genuinely broken or missing, the user should hear it —
  with a diagnosis — not have it hidden behind a cheerful deflection.

## Closing the loop on real gaps

"We don't have an MCP for that" is never the end of the answer. The end of the answer is: name the limitation
clearly, do the best achievable thing with the tools that exist today, and tell the user the exact next step. If a
missing tool keeps blocking real work, flag it to the team so it can be built — but the user always leaves the
conversation with a concrete result or a precise next action, never a shrug.