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>
2.5 KiB
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, andpipeline_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.