Resources, Prompts, and Host Adapters

The workflow-engine MCP serves workflow content as immutable Resources and uses prompts only for bootstrap guidance. It does not grant host capabilities. Host-specific mechanics are encoded as versioned host-adapter registry assets and validated against the harness's declared capabilities and attestations.

Resource catalogue

ImmutableResourceCatalogue in src/rimthan_workflow_mcp/resources.py builds a deterministic URI map from the verified McpScope.registry. For workflow-engine profile it serves:

• release summary: rimthan://registry/{release}/summary;
• manifest: rimthan://registry/{release}/manifest;
• workflow definitions: rimthan://registry/{release}/workflows/{workflow_id}/{version}/definition;
• workflow steps: rimthan://registry/{release}/workflows/{workflow_id}/{version}/steps/{step_id};
• registry assets: rimthan://registry/{release}/assets/{kind}/{asset_id}/{version}/content;
• validator definitions: rimthan://registry/{release}/validators/{validator_id}/{version};
• versioned schemas: rimthan://registry/{release}/schemas/{schema_id}/{version};
• bootstrap entrypoint: rimthan://bootstrap/agent-entrypoint.

The workflow-engine profile deliberately omits legacy rimthan://schemas/{schema_name}, starter-project, pilot template, module instruction, module metadata, and presentation resources. tests/test_workflow_engine.py::test_mcp_workflow_engine_profile_exposes_four_tools_and_exact_resources asserts workflow-engine resources include workflow definitions and validation schemas but no /modules/, /presentation/, rimthan://starter/project-interview, or pilot templates.

Resources are private-cache scoped. The profile also exposes five resource templates: workflow-definition, workflow-step, workflow-asset-content, validator-definition, and workflow-versioned-schema. server._McpStateProvider.for_resource routes release-specific URIs to the pinned release scope, so a checkpoint or link can read an older immutable release after the active channel changes. tests/test_workflow_engine.py::test_mcp_workflow_engine_profile_exposes_four_tools_and_exact_resources is the combined regression for the four-tool list, private resource/template cache scope, bootstrap text, exact workflow templates, and legacy resource exclusion.

Prompts and bootstrap

src/rimthan_workflow_mcp/prompts.py separates workflow-engine prompts from legacy profiles. The workflow-engine profile lists one prompt, rimthan.start_workflow, and the same host-neutral bootstrap paragraph is served as rimthan://bootstrap/agent-entrypoint. The paragraph is maintained in docs/operations/workflow-engine-bootstrap.md and instructs the harness to:

1. connect to the organization-provided remote MCP endpoint without installing participant-local Rimthan software;
2. verify server identity and exactly the four workflow tools;
3. start the research workflow with only real host capabilities;
4. obey pinned host adapter assets;
5. create only declared project-relative files;
6. run each semantic validator as a separate native subagent with declared read-only inputs;
7. submit complete structured report sets;
8. persist .rimthan/workflow-session.json for Git handoff;
9. treat system, user, repository, and host policy as higher authority.

Host adapter assets

A host adapter is a registry-asset with kind: "host-adapter", compatible harnesses, content instructions, and for versions 1.1.0 and newer a typed adapter_contract. rimthan_workflow_registry.workflow_engine._validate_adapter_contract verifies that project-local path templates contain exactly one {asset_id} placeholder, have no unresolved placeholders, are relative normalized POSIX paths, and do not target reserved roots such as .git, .hg, .svn, or .rimthan.

The shipped workflow names four harnesses in tool schemas and adapter tests:

Harness	Adapter stance	Project-local paths when allowed
codex	Use remote MCP directly, preserve exact assets, run validators as separate native subagents.	.agents/skills/<asset-id>/SKILL.md and .codex/agents/<asset-id>.toml for optional materialization.
claude-code	Use native HTTP MCP registration and isolated subagents with configured tools.	.claude/skills/<asset-id>/SKILL.md, .claude/agents/<asset-id>.md, .claude/commands/<asset-id>.md.
cowork	Dynamic delivery by default until a real Cowork staging run proves isolation and report control.	No project-local convention assumed.
buzz	No support inferred from the local Buzz relay CLI; requires actual Buzz agent harness evidence.	Dynamic delivery only until a safe format is documented.

tests/test_workflow_engine.py::test_every_named_host_has_one_pinned_fail_closed_adapter asserts every named host has one pinned adapter. test_legacy_adapter_without_typed_contract_loads_but_cannot_start preserves compatibility for old adapter assets while keeping new starts fail-closed when a typed contract is required.

Capability and attestation binding

rimthan.start_workflow binds a host declaration into the checkpoint: harness, adapter ID/version, host capabilities, and validator capabilities. Later validation calls must match those checkpoint-bound capabilities. The tool schema permits host capabilities such as mcp.tools, mcp.resources, mcp.prompts, native-subagents, scoped-inputs, read-only-capabilities, structured-reports, and project-local-assets; validator capabilities include workspace.read, web.read, browser.read, git.read, and database.read.

Start-time blockers are deliberately explicit. _host_blockers can return unsupported_harness, unsupported_host_adapter, host_adapter_asset_missing, host_adapter_contract_unavailable, host_adapter_binding_mismatch, missing_host_capability, missing_validator_capability, and repository_policy_conflict. It rejects missing adapter ID/version, an adapter not compatible with the declared harness, a version 1.1.0 or newer host adapter without a typed contract, absent required workflow capabilities, absent required validator capabilities, and any repository policy conflict before the harness writes setup files.

The active step payload returns the selected host adapter asset, each host asset contract, and allowed delivery modes. Project-local delivery is available only when the adapter contract permits that asset kind and the host declared project-local-assets; otherwise the harness must use dynamic-context delivery or fail closed.

prepare_step_validation enforces two attestation types:

• host_attestation is accepted only for setup-workspace. It proves required prompt/skill/subagent/adapter delivery, exact asset digests, declared delivery mode, project-local path when applicable, no host-asset path collisions, host capabilities, validator capabilities, selected harness, adapter ID, and adapter version. Delivery mismatches and capability/adapter binding mismatches are deterministic failures.
• output_attestation is accepted only for non-setup steps. It proves the harness read back the declared output path, bound the right artifact ID, owner step, media type, schema digest when JSON, maximum bytes, symlink-free path status, and strict write policy (create-owned, create-or-replace-owned, create-or-verify-owned, or must-exist).

Setup may not use output_attestation, and non-setup steps may not use host_attestation. test_setup_attestation_binds_capabilities_and_project_local_paths covers setup binding; test_repository_policy_conflict_blocks_before_setup_write proves repository policy conflicts block before setup writes.

Acceptance boundary

The adapters are published contracts, not proof that every host passed live acceptance. docs/operations/workflow-engine-bootstrap.md records the host matrix. Codex has a complete scripted staging loop, but fresh-host one-paste, actual native-subagent isolation, per-user auth, independently authenticated handoff, and real participant usefulness remain release gates. Claude Code, Cowork, and Buzz have stronger pending acceptance boundaries.

When extending host support, update these surfaces together:

1. registry asset in the workflow-engine draft;
2. adapter contract validation if new delivery modes are added;
3. host enum in workflow_engine_tool_contracts if a new harness name is public;
4. start/preparation tests proving fail-closed behavior;
5. operations host matrix and acceptance evidence.

Focused validation

• Resources and prompt surface: uv run pytest tests/test_workflow_engine.py -k exact_resources
• Host adapters: uv run pytest tests/test_workflow_engine.py -k adapter
• Setup attestation and repository policy: uv run pytest tests/test_workflow_engine.py -k "setup_attestation or repository_policy"