Skip to content

feat: add deterministic Trusted Runtime orchestrator#617

Draft
safal207 wants to merge 23 commits into
mainfrom
feat/trusted-runtime-orchestrator
Draft

feat: add deterministic Trusted Runtime orchestrator#617
safal207 wants to merge 23 commits into
mainfrom
feat/trusted-runtime-orchestrator

Conversation

@safal207

@safal207 safal207 commented Jun 22, 2026

Copy link
Copy Markdown
Owner

Summary

Implements #592 with a provider-neutral deterministic local workflow orchestrator for LS.

This PR is stacked on top of #616. Until #616 is merged, the diff against main includes the contract foundation as its dependency. The PR remains a draft for that reason, although its own implementation and CI are complete.

What is included

  • DeterministicWorkflowOrchestrator
  • OrchestratorConfig
  • explicit WorkflowOrchestrator methods for role assignment and revision trails
  • deterministic simple, multi-role, and recursive planning
  • supported roles: researcher, implementer, critic, verifier, summarizer
  • bounded explicit sub-task decomposition via max_steps
  • recursive revision limit via max_depth
  • deterministic PLAN_REVISED Cognitive Trail events
  • result and evidence reference propagation
  • fixtures for simple, multi-role, and recursive workflows
  • schema validation and unit tests
  • contributor-facing orchestrator documentation

Key behavior

task
-> deterministic role assignment
-> bounded sub-task plan
-> causal step chain
-> explicit revision
-> PLAN_REVISED trail event
-> recursion limit

The same task and context produce the same workflow plan. The implementation does not generate timestamps or UUIDs and performs no provider calls.

Safety and boundaries

  • model output remains a proposal, not execution permission;
  • no Sakana Fugu equivalence claim;
  • no dependency on CrewAI, LangGraph, AutoGen, OpenAI Agents, or provider SDKs;
  • no live model calls;
  • no side effects.

CI coverage integration

The main Security & CI workflow previously measured all of python/modules while running only two legacy hardening tests. Adding the Trusted Runtime files lowered aggregate coverage from the 12% threshold to 11.99%, even though the dedicated contract suite passed.

This PR keeps the 12% threshold unchanged and adds python/tests/test_trusted_runtime_*.py to the existing hardening coverage run with the correct PYTHONPATH. The same JUnit and coverage artifacts now represent the code introduced by the PR.

Local verification

python -m pip install jsonschema pytest
PYTHONPATH=.:python:python/modules \
  python -m pytest python/tests/test_trusted_runtime_orchestrator.py

ruff check \
  python/modules/trusted_runtime/orchestrator.py \
  python/modules/trusted_runtime/protocols.py \
  python/modules/trusted_runtime/__init__.py \
  python/tests/test_trusted_runtime_orchestrator.py

Local preflight result: 5 tests passed; Ruff passed.

CI result

All workflows are green on head 83c59d98:

  • Trusted Runtime Contract — Python 3.9: success
  • Trusted Runtime Contract — Python 3.11: success
  • Ruff Auto-fix: success
  • Phase 12.1 Regression Scan / Semgrep: success
  • Reflection Dashboard HTTP E2E: success
  • Security & CI Pipeline: success
  • hardening verification, quality gate, vulnerability audit, SBOM, CodeQL, and dependency review: success

Related

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant