|
oc_chat
|
Functions | |
| dict | make_error (str kind, str code, str severity, str message, str source="orchestrator") |
| dict | make_violation (str rule_id, str file, str|None nodeid, str severity, str message) |
| tuple[int, str] | compute_exit_and_status (*, bool fatal_config, bool interrupted, bool orchestrator_error, bool error_violations, bool failed_or_timeout) |
Variables | |
| str | SCHEMA_STAMP = "oct-test/v0.4" |
| dict | SUPPORTED_FEATURES |
| tuple | REQUIRED_FIELD_PATHS |
| dict | IMPLEMENTATION_ERROR_CODES |
| tuple | STATUSES |
Report-layer constants and pure mappings for the §20 stand-in (Plan 184).
Purpose
-------
Pin everything the spec-10 section 11 and section 20.3 report
contract fixes at the data level: the ``oct-test/v0.4`` schema stamp,
the pinned ``supported_features`` values VERBATIM, the required-field
path list, the documented 9xxx implementation-code catalog (section
12.4 requires the implementation to document its extension codes in
its own catalog — this module IS that catalog), and the section-4
exit-code precedence.
Responsibilities
----------------
- ``SCHEMA_STAMP`` / ``SUPPORTED_FEATURES`` / ``REQUIRED_FIELD_PATHS``.
- ``IMPLEMENTATION_ERROR_CODES`` — every 9xxx code the stand-in emits.
- ``make_error`` / ``make_violation`` — the §11 pinned entry shapes.
- ``compute_exit_and_status`` — §4 precedence (4 over 3 over 2 over 1
over 0) with the §12.3 interrupted-status carve-out.
Diagnostics
-----------
Domain: OC_TESTING
Levels:
L2 — lifecycle events
L3 — semantic details
L4 — deep tracing
Contracts
---------
- ``supported_features`` values are the §20.3 pinned set verbatim; a
serial stand-in reports ``workers_auto: "deferred"``. Since Plan 240
the stand-in can also DISTRIBUTE, and ADR-T-11's v0.3 amendment
(readiness audit A-19) makes that one value run-dependent —
``"deferred"`` when serial, ``"enforced"`` when the run resolved
``auto`` and distributed. This constant stays the SERIAL baseline;
``runner._features_for`` applies the parallel value per run, so the
pinned dict below is still exactly what a serial report carries.
- Timeout counts drive the ``failed`` status class (§11 status rule):
``failed`` exactly when ``summary.failed + summary.timeout > 0``.
Dependencies
------------
- oc_diagnostics (structured debug logging via _dbg)
| tuple[int, str] oc_chat.testing.report.compute_exit_and_status | ( | * | , |
| bool | fatal_config, | ||
| bool | interrupted, | ||
| bool | orchestrator_error, | ||
| bool | error_violations, | ||
| bool | failed_or_timeout ) |
| dict oc_chat.testing.report.make_error | ( | str | kind, |
| str | code, | ||
| str | severity, | ||
| str | message, | ||
| str | source = "orchestrator" ) |
| dict oc_chat.testing.report.make_violation | ( | str | rule_id, |
| str | file, | ||
| str | None | nodeid, | ||
| str | severity, | ||
| str | message ) |
| tuple oc_chat.testing.report.REQUIRED_FIELD_PATHS |
| tuple oc_chat.testing.report.STATUSES |
| dict oc_chat.testing.report.SUPPORTED_FEATURES |