Files
RaresKeYandStressTestor 7026cf40b5 docs: bootstrap specs ground truth (#5794)
* docs(specs): restore bootstrap after dev rewrite

* docs(specs): remove runtime inventory snapshot

* docs(specs): reconcile current dev truth

* docs(specs): document scheduled task actions as an owner-attribution source

Owner Attribution covered cookie, bearer-token and internal-loopback
requests. Scheduled task actions are a fourth source and behave
differently: _execute_action passes owner=task.owner off the stored
ScheduledTask row, so no request and no resolved principal are in
flight, and route-level require_user() never runs.

Webhook triggers are the sharp case. They are unauthenticated by
design with the token as the only credential and execute under the
stored task.owner.

Paths cite routes/task/task_routes.py, the canonical location after
the task subpackage move (#6081); routes/task_routes.py on current dev
is the backward-compat shim.

* docs(specs): add chained tasks to the trigger list, refresh dev stamp

Review feedback from RaresKeY on the previous commit.

"Every trigger path" was too broad: success-chained tasks are another
path into _execute_action. Added them with their own citation, and
noted that chaining additionally requires the target task to share
task.owner and rejects cycles, which is stricter than the trigger-side
checks. Softened the lead-in to "these trigger paths".

Line 56 still pointed at routes/task_routes.py for webhook credential
validation. That path is the backward-compat shim on current dev after
the task subpackage move (#6081); repointed to the canonical
routes/task/task_routes.py.

Stamp moved to dev@2a6b09b. Inspection backing that bump was scoped:
every file path cited in this spec was mechanically checked to resolve
on 2a6b09b, and every file:line in the Owner Attribution additions was
read against it. Behavioral claims elsewhere in the file were not
re-audited.

* docs(specs): correct SECURE_COOKIES description to match current behavior

Third of the stale details RaresKeY enumerated. The cookie section
described SECURE_COOKIES as purely opt-in, which stopped being true.

_secure_cookie() (routes/auth_routes.py:89) treats an explicit true or
false as authoritative and derives the Secure attribute from the
request otherwise, including when the variable is unset and when
docker-compose injects it present-but-empty. Either the connection
scheme or the first X-Forwarded-Proto hop being https is enough.

* docs(specs): refresh current dev truth

---------

Co-authored-by: StressTestor <212606152+StressTestor@users.noreply.github.com>
2026-08-25 14:18:44 +02:00

4.5 KiB

Provider Capability Specs

Last updated: dev@e71f8ce | 2026-08-25

Scope

This directory maps serving-provider observations and current model-catalog normalization into the canonical layer defined by model-capability-canonical.md. It records current Odysseus implementation evidence, merged fixes, reproducible user observations, and provider documentation without treating any single source as global model truth.

General To Specific Resolution

Read specs in this order:

  1. openai-compatible.md for the conservative general identity-only reader;
  2. the serving-provider file for native endpoints, headers, request/response observations, and catalog fields;
  3. model-quirks.md for model-specific observations.

Provider files document transport; runtime adapters still own it. Model quirks record only deviations and are not a second runtime matcher. Shared model facts must not be copied into every provider file. An OpenAI-compatible provider is not OpenAI: an explicitly supplied vendor string is preserved even when it uses the generic reader.

Current reader dispatch does not infer a provider from payload shape. It uses an explicit vendor, then endpoint kind, label-bounded hostname matches, and common local-port hints. The port hints map 11434 to Ollama, 1234 to LM Studio, 8000 to vLLM, and 30000 to SGLang. Those hints are normalization behavior, not endpoint trust.

Provider Map

Implemented canonical readers

  • openai.md: identity-only Models API plus Chat/Responses dialects.
  • openai-compatible.md: generic compatible catalog and runtime dialect boundaries.
  • openrouter.md: rich architecture, modalities, parameters, and limits.
  • google.md: native paginated Gemini Models API and GenerateContent.
  • ollama.md: /api/tags, /api/show, native chat, and OpenAI compatibility.
  • lm-studio.md: native v1 catalog/chat, explicit v0 compatibility, and OpenAI compatibility.
  • llama-cpp.md: /props, /slots, OpenAI/Responses/Anthropic surfaces.

Placeholder identities using the generic reader

  • anthropic.md: identity-only Models API and native Messages runtime adapter.
  • vllm.md: common-port identity hint; deployment capability remains unknown.
  • sglang.md: common-port identity hint; parser/config-dependent capability remains unknown.
  • hugging-face.md: Hub observations and download/fit metadata without a canonical reader.

Provider observations without a dedicated canonical reader

  • mistral.md: rich model cards, reasoning controls, and structured runtime content.
  • github-copilot.md: account model-list observations and required runtime headers.
  • chatgpt-subscription.md: Codex model identity and Responses event shape.
  • cohere.md: native endpoint/catalog observations; not currently normalized.

Other provider identity and general/identity-only observations

Other local/proxy serving identities

Provider Spec Template

Each provider file records:

  • provider identity and API dialects;
  • latest observed native catalog endpoint/envelope and capability-bearing fields;
  • whether current source has a dedicated reader or only generic fallback;
  • observed request, tool, text, reasoning, and control paths owned by runtime adapters rather than the catalog reader;
  • what remains per-model/unknown;
  • Odysseus evidence and regressions;
  • fallback/safety behavior and current gaps.

Marketing capability lists and curated picker lists may guide research but do not automatically become model claims. Provider-returned false values can be negative evidence only at the same provider/endpoint/model scope.