mirror of
https://github.com/pewdiepie-archdaemon/odysseus.git
synced 2026-09-16 13: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>
58 lines
2.5 KiB
Markdown
58 lines
2.5 KiB
Markdown
# General OpenAI-Compatible Inventory Fallback
|
|
|
|
Last updated: dev@2e2bb52 | 2026-08-16
|
|
|
|
## Scope
|
|
|
|
Canonical compatibility identity `generic_openai`; identity-only reader
|
|
`src/model_capability_readers/generic_openai.py`; shared envelope and identity
|
|
helpers in `src/model_capability_readers/base.py`.
|
|
|
|
This is not a universal OpenAI-compatible capability schema. Transport request
|
|
and response behavior remains in `src.llm_core` and provider adapters.
|
|
|
|
## Accepted Inventory Shape
|
|
|
|
- `{"data": [...]}`;
|
|
- `{"models": [...]}`.
|
|
|
|
Within an item, the reader recovers identity from `id`, `name`, or `model`.
|
|
Bare-list payloads and `key`/`slug`-only items are not supported. It preserves
|
|
the raw item on the in-memory record, while `to_dict()` includes it only when
|
|
the caller explicitly requests `include_raw=True`. Capability remains unknown.
|
|
|
|
## Disabled Capability Paths
|
|
|
|
The generic reader does not inspect capability-looking fields, including:
|
|
|
|
- `type`, `model_type`, `task`, and `pipeline_tag`;
|
|
- top-level or nested modality fields;
|
|
- capability booleans/maps/lists;
|
|
- `supported_parameters`;
|
|
- context, input, output, and model-length fields.
|
|
|
|
Names, descriptions, ownership, pricing, and serialized text also never
|
|
promote capability through this reader.
|
|
|
|
## Forward Compatibility
|
|
|
|
An explicitly configured but unknown provider ID is preserved when the generic
|
|
reader is selected. That allows endpoint-scoped stable IDs to keep working
|
|
while every family, modality, capability, limit, and control remains unknown.
|
|
Non-object entries are skipped; null or malformed roots return no records.
|
|
|
|
Provider-specific headers, request extensions, and reasoning channels must be
|
|
selected by explicit provider/endpoint adapters. They never leak through this
|
|
fallback.
|
|
|
|
Compatible tool-call syntax is likewise a runtime concern rather than catalog capability. Current parsers recover selected Hermes/Qwen JSON bodies nested inside `tool_call` wrappers and require the full Qwen bare end delimiter; GPT-OSS compatibility can alias names that collide with its built-in tools and reverse that alias before local dispatch. None of those repairs grants execution authority or proves generic tool support.
|
|
|
|
## Current Gaps
|
|
|
|
- Compatible providers differ on path prefixes, null handling, tools,
|
|
streaming usage, and strict extra-field rejection.
|
|
- Bare-list and `key`/`slug`-only inventories need explicit normalization if a
|
|
runtime consumer later requires them.
|
|
- Safe request shaping still requires explicit endpoint/provider
|
|
configuration even when identity normalization succeeds.
|