Legacy Local Registry and Pilot

This page documents substantial legacy and compatibility code that remains in the repository. It is useful for tests, migration, operator tooling, and provenance, but it is not the current participant architecture. Current participant work uses the stateless four-tool workflow-engine protocol described in Four-Tool Workflow Protocol.

Legacy MCP profiles and tools

src/rimthan_workflow_mcp/server.py switches on McpScope.profile. Only workflow-engine uses WorkflowEngineQueryModule. All other profiles use RimthanMcpQueryModule from query_module.py and operator_tool_contracts from tool_contracts.py.

Non-workflow-engine profiles include:

• operator
• remote-operator
• pilot-tour

Their read-only tools are:

Tool	Query path	Purpose
rimthan.resolve_workflow	RimthanMcpQueryModule.resolve_workflow -> WorkflowResolver.resolve	Resolve legacy modules from a structured project state.
rimthan.explain_draft	resolver + ResearchDecisionParticipantPresenter.present_state	Convert a draft state and approved pilot contract into participant-safe copy.
rimthan.validate_pilot_contract	pilot.validate_pilot_contract	Validate a supervised pilot contract; does not approve it.
rimthan.verify_current_project	ProjectSnapshotReader + ReadinessVerifier.verify_project_snapshot	Verify readiness evidence in a configured materialized local project.
rimthan.explain_current_project	ResearchDecisionParticipantPresenter.present_project	Present verified local project status to a participant.

tests/test_mcp.py::test_operator_protocol_exposes_five_closed_read_only_tools proves this legacy/operator surface exposes five closed read-only tools with read-only and closed-world annotations. The checked-in Codex MCP config test asserts the local catalogue is portable and does not include --project-root by default.

Legacy prompts and resources

prompts.py keeps prompt catalogues separate:

• workflow-engine has rimthan.start_workflow.
• remote-operator has rimthan.review_pilot_contract.
• operator has rimthan.start_project_interview and rimthan.review_project_status.
• pilot-tour only exposes rimthan.start_project_interview.

ImmutableResourceCatalogue similarly exposes legacy module instructions, module metadata, presentation bundles, packaged schema resources, starter interview material, and pilot templates only outside workflow-engine profile. Workflow-engine resources intentionally omit those legacy URIs.

Legacy resolver and materializer

WorkflowResolver in src/rimthan_workflow_registry/resolver.py selects module-graph modules from a project-state document. It validates state consistency, blocks resolution before CONTRACT_CONFIRMED, evaluates install_when predicates, closes dependencies, rejects duplicate module versions, topologically orders selected modules, and returns omissions and blockers.

ProjectMaterializer writes a resolved module set into an explicit project root. It requires initial revision 1 at CONTRACT_CONFIRMED, rejects symlink roots, writes canonical context/project-state.json, installs immutable module module.json and instructions.md bytes, optionally installs a presentation bundle, writes context/workflow.lock.json, initializes context/workflow-progress.jsonl, and reports written/unchanged paths. It is path-confined and collision-aware, but it is a local materializer, not part of the current remote participant workflow.

Local progress and revision management

ProgressLedger owns append-only context/workflow-progress.jsonl. It validates canonical event schema, byte limits, project identity/revision, sequence, previous-event hash, and workflow state history. It can append, verify, inspect, and recover from truncated suffixes.

ProjectRevisionManager performs crash-recoverable compare-and-swap updates of project-state.json, workflow.lock.json, installed modules/presentation, and a progress event. It writes a durable pending transaction under the project context, fsyncs, then rolls it forward. recover() completes a pending transaction or reports a clean state.

These local files are separate from workflow-engine checkpoints. The current participant protocol writes only .rimthan/workflow-session.json as a harness-owned checkpoint and does not use the local materializer.

Participant presenter and pilot code

ResearchDecisionParticipantPresenter translates verified legacy project state and presentation bundles into participant-safe views. It validates pilot contract approval, data classification, allowed surfaces, route, resolution/project revision matching, and readiness status before rendering copy.

src/rimthan_workflow_registry/pilot.py contains supervised pilot contract, evidence, evaluation, and acceptance verification. Pilot tools are kept to prove human usefulness and historical acceptance. They do not authorize workflow-engine participant execution.

ReadinessVerifier validates readiness evidence, approvals, and required evidence for a materialized project. The operator MCP tools can expose this read-only result when a project root is configured.

Research renderer

src/rimthan_research_runner/renderer.py renders research-artifact JSON into deterministic, script-free static HTML. ResearchArtifactRenderer.render validates the artifact schema and semantics, escapes content, sorts sources, includes a canonical artifact digest, and avoids JavaScript. The rimthan-research-render CLI wraps it. This is a legacy artifact renderer and not a semantic validator runner.

CLI surface

rimthan_workflow_registry.cli exposes local commands such as:

• validate, resolve, get-module, materialize;
• verify, record-event, verify-progress, update-state, recover-revision;
• verify-release, get-schema, get-starter;
• pilot contract/session/evidence/evaluation/acceptance commands.

These commands are valuable for tests and local workflows. Do not infer that participant projects must install or run them under the current workflow-engine profile.

Tests

Representative legacy coverage:

• tests/test_mcp.py: operator/remote/pilot MCP tools, resources, prompts, HTTP staging adapter behavior.
• tests/test_resolver.py: module selection, dependencies, blockers.
• tests/test_materializer.py: path confinement, immutable writes, lock generation.
• tests/test_progress.py and tests/test_revision.py: progress hash chain and crash-recoverable revision transactions.
• tests/test_participant.py: participant-safe presentation and data-policy gates.
• tests/test_pilot.py: pilot contract/session/evaluation/acceptance behavior.
• tests/test_research_renderer.py and tests/test_research_workflow_e2e.py: deterministic research rendering and local workflow fixtures.

Boundary rule

When changing legacy code, preserve compatibility and tests, but do not let legacy local-runtime assumptions leak into the current participant contract. If a change affects runtime participant behavior, verify it against Participant Architecture, Resources, Prompts, and Host Adapters, and tests/test_workflow_engine.py.