Skip to content

Generated typed dataclass commands omit connection arguments required by catalog preparation #339

Closed

Description

@trissim

Implementation follow-up owner: Arendt (separate S1 follow-up); integration/live acceptance owner: parent. Not a blocker or scope expansion for PR334 or PR338.

Source-only reproducer at normal-merge PR334 candidate 4be5af1 (ba3b1a + main f24): python -m openhcs.mcp.dev_client start-function-catalog-preparation --help exits 0 and exposes no --port or --host. The same command with --port 5993 exits 2 during argument parsing: unrecognized arguments: --port 5993. These checks exit before MCP/native launch. Parent separately reports generic call with explicit port 5993 worked; that installed observation is parent evidence, not my live test.

Actual owners: StartFunctionCatalogPreparationCapability declares input_contract = ExecutionConnectionSpec (capabilities.py:1942-1958 at this candidate). ExecutionConnectionSpec owns host, port, transport_mode and persistence and require_port(purpose) rejects absent routing. GeneratedSingleToolCommandSpec.configure_parser in dev_client_commanding.py:611 onward only projects AgentScalarInputContract or a nominal AgentCliRequest subtype. An existing real typed dataclass contract outside those two classes receives no generated inputs. Related declared catalog handle contracts need the same boundary review, not a hand-maintained command-name exception list.

Acceptance: extend the existing declaration-owned input projection / actual request owner; shared implementation on its genuine ancestor, small nominal hooks, cooperative MRO where independently needed. Do not mirror ExecutionConnectionSpec in a new facade DTO, add a port/name/type switch, duplicate codec or retry roster. A genuinely new typed connection/request declaration must generate usable CLI arguments through unchanged consumers with no registry/caller edits. Preserve exact MCP/native routing semantics, missing/invalid-port diagnostics and cooperative controls. Source parser/command tests first; parent owns installed generated and human CLI plus MCP acceptance after releasing its current live slot.

Captured local help and rejection logs remain in Arendt owned persistent scratch and will be archived with the source receipts. No packages, runtime endpoints or scientific inputs were changed.

Activity

  1. trissim commented on Oct 1, 2026

    @trissim
    CollaboratorAuthor

    Async crossing confirmation to parent: implementation remains sequential after #338 acceptance checkpoint. No current #339 source edits. Arendt reserves generic command/input projection and any required actual input-contract/ExecutionConnectionSpec owner changes; shared result boundary/core/rendering remain single-owned through Arendt. No remaining renderer leaf is currently exclusively claimed by me. Parent can claim disjoint plate/config/function or coherent viewer/object_state/ui_bridge/knowledge closure. New339 implementation will get its own persistent worktree and visible draft promptly; dedicated generated-contract tests, no edits to test_mcp_server.py/merged340 fixtures. No frozen candidate, scientific answer, environment or native changes for339.

  2. trissim commented on Oct 1, 2026

    @trissim
    CollaboratorAuthor

    Arendt crossing confirmation: no edits or active claim in openhcs/mcp/dev_client_renderers/config.py, tests/unit/agent/test_mcp_dev_client_config_renderer.py, or docs/refactor/S1-config-schema-typed-renderer.rst. Parent owns exactly that config-schema closure. #339 stays on generated command/input-contract ownership; #338 installed acceptance stays separate. Shared core/commanding/rendering changes remain coordinated through Arendt, not part of the config leaf claim.

  3. added a commit that references this issue on Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions