mirror of
https://github.com/pewdiepie-archdaemon/odysseus.git
synced 2026-09-14 12:12:20 +02:00
RaresKeYandStressTestor
7026cf40b5
* 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>
47 lines
2.0 KiB
Markdown
47 lines
2.0 KiB
Markdown
# Mistral Provider Shape
|
|
|
|
Last updated: dev@2e2bb52 | 2026-08-16
|
|
|
|
## Scope
|
|
|
|
Canonical provider ID `mistral`; OpenAI-compatible chat with Mistral response
|
|
extensions and runtime handling in `src/llm_core.py`. There is no dedicated
|
|
Mistral canonical reader on current `dev`.
|
|
|
|
## Catalog Shape
|
|
|
|
`GET /v1/models` returns `data[]` cards with `id`, `root`, aliases,
|
|
`max_context_length`, and `capabilities` booleans including
|
|
`completion_chat`, `completion_fim`, `function_calling`, `vision`,
|
|
`classification`, and lifecycle/fine-tuning fields. These are candidate fields
|
|
for a future dedicated reader:
|
|
|
|
- chat/FIM or classification family;
|
|
- vision input;
|
|
- function calling;
|
|
- explicitly reported reasoning/structured output when present;
|
|
- context limit and root family.
|
|
|
|
Fine-tuning availability and archived status are not inference capabilities.
|
|
The current generic reader retains identity/raw data only and does not map any
|
|
of these fields. Different Mistral models retain independent identities.
|
|
|
|
## Request And Response Shape
|
|
|
|
Reasoning-capable models accept graded `reasoning_effort`. Mistral can return `content` as typed blocks: a `thinking` block containing text fragments plus a normal `text` block. Runtime normalizes those blocks for async utility calls as well as chat/stream paths, keeping reasoning and visible text separate instead of stringifying the list or scanning text tags (#4698, #5882).
|
|
|
|
## Fallback And Safety
|
|
|
|
Runtime `llm_core` detects label-bounded Mistral hosts for request/response
|
|
handling. The canonical registry has no Mistral host or rich-payload detector;
|
|
an explicitly supplied `mistral` vendor falls back to generic identity. A
|
|
Mistral model served through another engine uses that serving engine's dialect.
|
|
|
|
## Current Gaps
|
|
|
|
- Catalog reasoning fields vary across model-card generations; absent remains
|
|
unknown.
|
|
- Mistral catalog capability fields are not normalized by current `dev`.
|
|
- Runtime thinking-family selection still uses names and should migrate to
|
|
structured root/capability identity.
|