Team command validation and remote profiles

GitHub पर स्रोत देखें

The development branch separately provides a Team workstream HTTP/MCP service. It authenticates queries, sessions, claims, caller-managed execution and authorized recovery in PostgreSQL. Operator access provisioning uses a separate schema-owner CLI. The legacy command limitations below still apply; personal MCP and remote-profile commands do not route to that service.

The public Team command path does not yet implement authenticated HTTP/MCP transport, credential loading, queuing or domain dispatch. awr team command and awr-server command return Unsupported for a valid command; they never report accepted=true, replay status or cached results. Missing/offline remotes cannot fall back to personal SQLite authority. awr team capabilities describes local protocol metadata, explicitly reports local=true, submitted=false and command_transport=false, and does not contact a server.

The shared pure parser currently recognizes capabilities and work.claim. Only capabilities are locally executable. Claim has a validation schema, not a remote dispatch target. Other operations, including execution.cancel and source.activate, return Unsupported online and offline. PostgreSQL store APIs are separate from this wire entry. Future adapters must register an operation's schema, read/write policy and actual dispatch before announcing support.

Received envelopes must be JSON objects with explicit protocol_version, nonempty request_id and op. Receivers never invent these fields. Only version 1 (integer or canonical decimal string) is supported; conversion never truncates. args must be an object. Claim requires nonempty string work_id, scope_id, session_id, expected_contract_hash, and an unsigned expected_work_version (integer or canonical decimal string; decimal strings preserve all 64 bits). Unknown argument fields are rejected. Business preconditions remain the domain store's responsibility. Capabilities permit only empty args, or omitted args.

For local integration testing, the server skeleton offers an explicit validator:

awr-server validate-command --op work.claim \
  --tenant-id tenant-a --project-id project-a --actor-id actor-a --client-id client-a \
  --body '{"protocol_version":1,"request_id":"example","op":"work.claim","args":{"work_id":"work-a","scope_id":"main","session_id":"session-a","expected_work_version":"1","expected_contract_hash":"example-hash"}}'

This performs no database/network operation and returns validation_only=true, submitted=false, authenticated=false, and the separately supplied context. Those local flags are test context, not authentication credentials. Request identity declarations cannot override any tenant, project, actor or client field. awr_team::execute also checks retained declarations against its supplied context; a future authenticated adapter must obtain that context independently of the body. The http, mcp, cli labels in pure-function tests are not three live transports. Personal awr-mcp has no Team command dispatch tool; its shared MCP service remains independent of this Team skeleton.

awr remote stores an endpoint, project key and credential environment name, using TOML serialization. Profiles are validated on both save and load. Endpoints must be absolute HTTPS URLs, or HTTP URLs on localhost/loopback IPv4/IPv6. Database schemes, user/password information, query strings and fragments are rejected; credentials belong in the referenced environment, not the URL. Output independently replaces invalid endpoints with a placeholder, and TOML parse errors never echo configuration contents. Valid Unicode project keys roundtrip through add/inspect. Profiles must explicitly declare supported protocol_version = 1.

These command-validation checks do not establish authenticated network isolation, PostgreSQL authorization, business acceptance or release readiness.

Team MCP business action permissions (AWR-TMCP-010)

This section freezes the Team MCP business permission contract. It is separate from the command-envelope validation above. Enforcement at live MCP/HTTP/PG domain entry points is AWR-TMCP-011 (shared authorize_command / authorize_query decision). This section freezes types, fixtures and rules; the live gate maps current workstream commands onto these actions and refuses planning/access/audit ops for roles that lack them.

Role templates

TemplateMeaning
readerRead authorized work and context
developerClaim, maintain own session/execution, propose planning changes, submit delivery
maintainerEdit/approve/publish planning drafts and finalize delivery
project_adminManage project membership/grants and read project audit export

review.decide is not part of any template. It requires an explicit independent-review add-on for an eligible non-reader member. Project admins have no bypass.

Action matrix

Unknown actions default to deny. Action names are proposed business semantics; they are not necessarily current CLI/MCP command names.

Fixtures: tests/fixtures/team-mcp/role_action_matrix.json.

Actionreaderdevelopermaintainerproject_admin
work.readyesyesyesyes
session.maintain_own—yesyesyes
claim.manage_own—yesyesyes
execution.request_and_report_own—yesyesyes
planning.propose—yesyesyes
planning.edit_draft——yesyes
planning.approve——yesyes
planning.publish——yesyes
delivery.submit_and_request_review—yesyesyes
review.decide—add-onadd-onadd-on
delivery.finalize——yesyes
access.manage_project———yes
audit.read_project———yes

Authority scope

An allow decision requires an AuthorityScope that binds all of:

  • tenant_id / project_id (required)
  • optional workstream_id and optional work_ids set
  • person_id, optional execution_identity, client_id
  • allowed_actions, optional independent-review flag
  • policy_version, expiry (not_after_unix_ms) and revocation

Role display names, tool discovery/visibility lists and model self-reports cannot authorize any action by themselves (deny_role_name_only, deny_tool_visibility_only, deny_model_self_report_only).

Project admin authority is project-scoped: it does not grant other projects, database_owner, schema migration, trusted executor attestation, execution reconciliation, arbitrary source filesystem control or tenant-wide recovery.

Legacy migration preview

Coarse legacy roles reader / reviewer / worker / admin and grants read / write / manage produce a preview only (preview_legacy_migration). Effective actions are the intersection of legacy membership and client grant templates (never a union); missing either side contributes no actions from that side. Newly introduced privileges (planning.*, access.manage_project, review.decide) are always withheld, independent of which grant branch is supplied. Person links without verified evidence stay unknown and grant nothing.

Fixtures: tests/fixtures/team-mcp/migration_preview.json and tests/fixtures/team-mcp/allow_deny_pairs.json.